- Boost - lists.boost.org

a question about "typeof"
by Arkadiy Vertleyb 21 Apr '04

21 Apr '04

Hi all, A couple of questions regarding typeof: 1) Is it going to be in the next C++ standard? 2) Is there any estimate when it is going to happen? I assume that quite a few Boost libraries could largely benefit from this operator. Spirit documentation even contains a section on typeof and how the syntax could be improved with it. I recently had a need to determine a type of a Lambda functor (but got away with Boost.Function with some performance expences). Also Joaquin recently raised a similar question. Our RTL syntax would also benefit a lot if this facility was available. About one and a half year ago Steve Dewhurst published three articles on this subject in CUJ. The idea was to encode the type as an integer using bitwise operations. This integer could be than "returned" from the function, this crossing the boundaries between a type and a value, and then decoded into the original type. I wonder if this or any other technique is currently being considered by anyone to be added to Boost or we are just waiting until the real typeof is available? I have been experimenting with this, and came up with a very simple trick that allows to use a static list of integers, like mpl::vector_c, instead of bitwise operations, to encode the type, and pass this list across the function boundaries. I think, if nothing else, this is much simpler than bitwise operations. Everything else is pretty much like in Steve's approach. Based on this it seems to be pretty simple to encode/decode types to implement typeof-like facilities for some specific (or maybe not so specific) cases. Has anybody already done something similar, and/or is this of any interest? If there is an interest I am ready to provide explanation, code, etc. Regards, Arkadiy

5 5

gcc-3.4 release imminent
by Neal D. Becker 21 Apr '04

21 Apr '04

gcc-3.4 is now frozen. I wonder if anyone is testing boost compat? I have tried compiling some of my code using gcc version 3.4.0 20040327 (Red Hat Linux 3.4.0-0.9). There are usually a LOT of errors. gcc-3.4 doesn't seem to like boost iterator adaptor stuff, in particular. Also lambda. Many errors are of this nature: src/c_to_r.hpp:83: error: there are no arguments to `base_reference' that depend on a template parameter, so a declaration of `base_reference' must be available

5 7

Re: [boost] Re: serialization: review
by Robert Ramey 21 Apr '04

21 Apr '04

Thorsten Ottosen wrote: > Robert Ramey wrote:(> |) > | I don't understand the need for this. Given that mammal is an abstract > | base class with no state variables of its own, it needs no serialization > | at all. > Ok, but could I have implemented it by having just one function in the > abstract base class which seriaized by calling virtual functions, eg, > name() and age()? I believe you could. In fact I believe that in some cases not yet encountered ( runtime plug-ins ) it will be necessary. This is still an unresolved area > | Just declare it as abstract using BOOST_IS_ABSTRACT(mammal). Only the > | serialization of the derived classes need be specified. > Can BOOST_IS_ABSTRACT be avoided? Maybe some type-traits can figure this > out? Is_abstract is in the new type traits. It fails on lots of compilers. Also it was in a state of flux at the time of the release of 1.31. I expect that a) is_abstract get fixed up best it can b) and have an implementation that is benign for compilers that don't support it c) and that we'll continue to specialize it for serialization code that needs to be compiled on less-conforming compilers. (this is all BOOST_IS_ABSTRACT does.) In > struct whale : public mammal > { > friend class boost::serialization::access; > whale(); > whale( const std::string& name, unsigned age ); > virtual const std::string& name() const; > virtual unsigned age() const; > private: > template<class Archive> > void serialize(Archive &ar, const unsigned int version){ > ar & boost::serialization::base_object<mammal>(*this); > ar & name_ & age_ ; > } > std::string name_; > unsigned age_; > }; > can the line "ar & boost::serialization::base_object<mammal>( *this )" > be put in a base-class like this > mammal::serialize( Archive& ar, unsigned version ) { > ar & boost::serialization::base_object<mammal>(*this); > do_serialize( ar, version ); > // virtual function that does the rest > } > to remove some redundancy? The intention of base_object is really to cast to the base class (and register the base/derived relationship). So it its out of place here. The real issue is do_serialize. Is that supposed to be a virtual function? With a templated argument? Maybe you want to consider this question a little bit more. > | I would love to hear more about this. I would hope that it would easy > | to be totally successful. > it is now given you showed me how :-) In effect, once the container > supports serialization, a class can be supported in four lines. If you > have not got an example of class hierarchies, then maybe it should be > added. The tutorial contains an example essentially identical to your mammals, whales and apes example. Under case studies there's a discussion of the implementation of serialization for shared_ptr which is almost exactly analogous to your vector_ptr case. Also, there some discussion in the documentation regarding serializaition of templates. > | > I would like to see the focus shift from vector<T*> towards vector< > | > shared_ptr<T> > and ptr_vector<T>. using T* array[sz] or vector<T*> > | > is inherently unsafe if the pointers are heap-allocated. > | > | I believe that enforcing this is outside my role as a library creator. > ok, but I think you at least should point out very clearly the problems in > it. Some non-experienced programmer might do what he sees in > documentation; therefore examples should encourage good style. Well, here is one programmer that needs to be better sold on this. Honestly, I don't think the serialization tutorial is the place to do it. > | 3. const members uses a const-cast to re-init them. AFAICT, this is > | undefined behavior (cmp 7.1.5.1). I guess the need for serialization > | is just another reason for not having const members. Hmmm - what does re-init mean in this context? > | > this has come up from time to time. I've tried to promote the view > | > that const members shouldn't be serialized but I couldn't convince > | > everyone. > | > I consider it outside my role as a library developer to try to > | > enforce this. > my point was that the examples given give undefined behavior so that > solution cannot be used. Which example gives undefined behavior? > no, but maybe with this > | stl::archive_input_seq<Archive, std::vector>, > | stl::reserve_imp<std::vector> > by arranging the order of the template parameters. > | Isn't a little bit of redundancy OK giving the alternative of having > | to keep the details of deducibility in one's brain? > but you already know the types that will be deduced from the outer > function. OK, could we agree to disagree on this and forget about it? > | > 18. implementation of save_collection(). you cannot use unsigned int > | > count portably. > | > | I don't see this. > | > | > Instead you should use the new collection traits (reviewed after > | > this review) as follows: > | > | > typename boost::size_type_of< Collection >::type count = size( s ); > | > | > then the code will also work for iterator views and arrays. Similar > | > comments apply to load_collection_impl.hpp > | > | I wanted to make the library buildable under 1.31 . > ok, then do > typename Collection::size_type count = s.size(); > but don't assume Collection::size_type will be unsigned int. I'm not assuming that. I'm assuming that it will be convertible to an unsigned int and that an unsigned int will be large enough to hold any number of elements in an collection. Of course THAT might be rash assumption. BTW where is the namespace Collection defined in 1.31 ? Robert Ramey

2 1

RE: [boost] Re: date-generators (was Date-Time)
by Hurd, Matthew 20 Apr '04

20 Apr '04

> Jeff Garland > > > Cyrille Dupuydauby wrote > > Totally agree with that, business related apps need > holidays and business > > days. But holidays determination should be easily localizable. > > It isn't just by locale, the application needs to determine > holidays. For > example, while there are some holidays in the US that > everyone agrees on, but > lots of companies use a couple floating holidays every year. > They typically > will tack one say a Friday after a July 4th on a Thursday to > give employees a > 4 day weekend. So any calculation of business days needs to > be capable of > handling these application specific cases. Yep. And just to emphasise the point you just made... Some jurisdications might have a business day with respect to some activity but not others. For example, an exchange might have a trading day but not a settlement day. A foreign exchange contract might be written in NY effective on a Sydney holiday but the settlement date might depend on the union of holidays between Sydney and NY. All this indicates is that a calendar can be completely arbitrary and that different calendars can apply to the same business at the same point in time for the same jurisdiction for different parts of the same transaction. Like me, the world has warts ;-) Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RE: [boost] Re: Date-Time
by Powell, Gary 20 Apr '04

20 Apr '04

>Ummm, OK, you made it work, but why? Why would you want to be >able to call add_month() on a date and have it always represent >the day before the last day of the month? date d = August 30; // add six months. add_month(d); // September 30; add_month(d); // October 31? add_month(d); // November 30 add_month(d); // December 31? add_month(d); // January 30 add_month(d); // February 28/29 add_month(d); // March 28? 29? 30? 31? Just looking this there is no way to predict which day of the month the last call is going to be. I'd find it surprising that (d + year) != (12 * months) + d; I think you are looking for a simplistic function for a complex problem. IMO its a trap for the unwary and should be called out as such. I can see the need for LAST, but my contention is that its not enough information to do the least surprising thing. The easiest way to resolve this is to either write a FAQ, and or have a dumb rounding month adding function that can screw up the dates for those times when "meet you next month" is the right answer. Yours, -Gary-

4 9

Re: numeric_cast
by Dill, John 20 Apr '04

20 Apr '04

"Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404201905.i3KJ55e08992(a)lawrencewelk.systems.susq.com>... > From: "Dill, John" <john-dill(a)uiowa.edu> > > > > I am wondering about the use-case of numeric_cast in this sample. > > > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); > > char schar_value = 0; > > > > try { > > schar_value = boost::numeric_cast<char>( uchar_max ); > > } > > catch ( boost::bad_numeric_cast ) > > { std::cout << "Overflow occurred..." << std::endl; } > > > > When I execute this sample, I don't get the exception. What's > > the background on this behavior? I'm using gcc 3.3.1. > > Your char is unsigned. I'd like to know why conceptually the exception isn't thrown. Why is it beneficial to have unsigned T to signed T overflows not be detected? It is not just char, but short, int, and long as well. If this was the intended behavior, then what is the reasoning behind it? Thanks, John

2 1

Re:Re: Re: Re: [boost] Re: [serialization] + [boost.python serialization of python object
by Robert Ramey 20 Apr '04

20 Apr '04

Ralf W. Grosse-Kunstleve wrote: > FWIW: For the serialization of C++ arrays wrapped as Python objects (via > Python's pickle) I implemented a small "library" (it really is just one > header file) for converting integers and floating-point numbers to a > pseudo text format. In principle it works just like the conversion to > base-10 numbers, but uses base-256 instead. I.e. the result looks like a > binary format, but it is as machine-independent as a text format. The > serialized strings are smaller than regular text format, but larger than > raw binary format. > Integers are serialized like this: > NXX...X ... This is interesting. I made an example as part of the library called:demo_portable_binary or which attempted to handle issues such as endianness and size. I bailed at floating point because of the concern for handling things like conversion between 80 bit IEEE float and 64 proprietary floats. And then I was just making as sketch to inspire someone to implement XDR which I presumed had some sort of way of handling this. (I still don't know how other formats handle this) I like your method. I may steal it yet. Robert Ramey

1 0

Re: Re: Re: [boost] Re: [serialization] + [boost.python serialization of python object
by Robert Ramey 20 Apr '04

20 Apr '04

> Ralf W. Grosse-Kunstleve wrote: > Interesting. If I serialize and deserialize std::vector<double> as a text > archive but on the same machine, will I always get back exactly the same > bit patterns for the double values? The text archive uses a stream manipulator to set the precision of the output to capture all the precision in the double. It uses the numeric<limits> to determine this. So I can't say it will be exactly the same bit stream but it will be close to the original number. If you want to guarantee the exact representation you can either use the included native binary archive or serialize the data element (double) as a (non-portable) binary object. Robert Ramey

2 1

Re:Re: [boost] Re: Re: Serialization Formal Review #2
by Robert Ramey 20 Apr '04

20 Apr '04

Matthias Troyer >On Apr 17, 2004, at 8:13 AM, Robert Ramey wrote: >> Matthias Troyer wrote: >>> 2. which functions do I need to implement in my archive class to skip >>> writing the standard preamble that your archives write? Is it just >>> the init function or are there more functions? >> >> Depending on the implementation traits for each class, there may be a >> preamble written by the serialization library. This contains >> information such as version number, class id info, perhaps export key, >> etc required by the s library to reconstruct a faithful reproduction >> of the original data. >> If there is a preamble, there is no information in that can be >> discarded and still reproduce the original data. >I was wondering about the preamble written at the start of the archive, not >the per-class information. An archive preamble is entirely optional. The common_?archive base class includes the init function which all the included archives call in their constructor. There is no requirement to call this function however in the constructors of your own archives. Robert Ramey

1 0

Formal review: serialization
by Vladimir Prus 20 Apr '04

20 Apr '04

Here's my review of the library. It's based on reading docs and source for several hours, as well as using almost every previous version of the library on my project. I think the library should be accepted. I voted "no" the previous time, but I think library was considerably improved. I'd also like to thank Robert for pushing this effort forward! Detailed comments are below. Some of them are marked as "critical" -- it means I believe they should be addressed before the library is added to official distribution. ** General issues ** -- (critical) The primary issue with the library is lack of reference documentation -- exact description of semantics for every method (preferrable in C++ std style) and overview for all important classes. The library is non-trivial, and without such documentation user will have to experiment to find out that exact semantic. Better internal docs (comments) are also needed. For example, I'm looking at save_access::end_preamble and don't know what it does. Comment for basic_oarchive::end_preamble says what this method is for, but does not say when this method is called, which makes it hard to do anything. Again, implementation is non-trivial. Lack of comments make it somewhat dangerous to use the library -- if I hit a bug while Robert is on vacation, I'm not sure I'll be able to quickly fix it locally. As an illustraction, I've already had a couple of bugs each costing several hours to debug. -- (critical) While BOOST_CLASS_EXPORT is a big step forward, I think it can be further improved. Now, if I export a class I need to include some archive headers before invoking BOOST_CLASS_EXPORT. The class can be only serialized to archives which were included. This means that to really export a class, I need to include *all* archive headers. That's not good. What I suggest is - create new class 'polymorphic_archive', which will have virtual functions for saving/loading and create templated 'polymorphic_wrapper', which can be used to add this polymorphic interface to existing archive. - always register all exported classes with polymorphic archive. When serializing in a specific archive, check if class is registered with that archive. If not, serialize it via polymprphic wrapper. In fact, I'd be willing to help with polymorphic archive implementation, but some changes inside serialization library will be required. -- (critical) I suspect BOOST_CLASS_EXPORT does not play nice with templates. Say I'm implementing RPC system: class function_call_base { virtual ~function_call_base() {} } ; template<class Arg> class function_call1 : public function_call_base {}; // in some code rpc_server s; s.register("foo", &foo); function_call_base* c; while(archive >> c) (*c)(); The idea is the caller will serialize instances of function_call1 and the callee will deserialize it and call the proper function. To make this work, we have to BOOST_CLASS_EXPORT all used instantinations of function_call1. We can assume that all functions (and therefore all argument types) are passed to the 'register' function and can function can invoke BOOST_CLASS_EXPORT. Now the problem: BOOST_CLASS_EXPORT can be used only at top-level of a translation unit. There's not way 'register' and automatically export a class. The solution I'd like is: template<class T> class export_class { public: static void instantiate(); }; So that the object of this type can be created anywhere. -- One usage of the serialization library I have in mind is taking "debug dumps" for an application. After the run, a separate tool can be used to look at those dumps. The size of data can potentially be rather large (e.g. 100*640*480 or maybe more), so I'd rather not to load all data, but build some index. So the question is: how is it possible to access specific part of archive without reading it all. I understand it's not possible in general, but in some cases (e.g. BOOST_CLASS_EXPORT for everything) it should work. -- The documentation of 'make_binary_object' is very incomplete and does not tell the exact semantic. As far as I can tell, the function can be only used to load/store objects which have fixed size and will crash when saving/loading new[]-d array -- which seemed an obvious use-case for me. I would suggest that we have two functions: make_pod_wrapper -- which is templated, has one parameter -- object, and stores sizeof(T) bytes. Another name -- make_static_array_wrapper. make_dynarray_wrapper -- which can be used to store/load arrays allocated by new[] -- The library requires exact match between static types for saving and loading. For example: D* d = new D; ia << d; B* b = new B; ia >> b; does not work. Moreover, it does not work even if 'D' is BOOST_CLASS_EXPORT-ed. I'd suggest that this case should work, since it's very easy to save derived classes using pointer to derived class, without casting to base class. -- It appears that XML archive require member/variable names in all cases. I'm not sure that's reasonable -- given that the library requires exact correspondence between loading and saving order even for XML archives. It would load archive back even if I change all the names manually in XML file right? Then why requiring names? -- I have some concerns about XML archives. The point of XML, in general is that it's somewhat readable by humans, and readable by other applications written using different libraries or in different languages. However, when I look at: <c2 class_id_reference="1" object_id="_2"> <i>10</i> <j>4</j> <base object_id="_3"></base> </c2> it's not clear if any of those benefits are there. This actually corresponds to a class "C". To find out this, one has to find "class_id" attribute with value of "1" somewhere above. If the above was: <C name="c" ...> finding all "C" elements would be trivial with XPath, or even with more simple methods. As it stands now, even finding all instances of "C" is hard. There may be a number of similiar issues. If the goal is to produce XML which can be processed by other programs, then at least the class name should become element name. -- I believe that library should not change codecvt facet of the stream. There are two reasons. First, if user has already imbued some facet (say utf-8), he might have good reasons to do so (say, he believes utf-8 is the most space-efficient for his data). So the serializaton library should not silently change codecvt to ucs-2. Second, the whole locale stuff is complex, and it's not even clear if it's possible to change codecvt facet on the fly, and when the change will take effect, and so on. I believe requiring user to 'imbue' proper facet himself is better than some unexpected internal effects. -- I've tried to play with "implementation level" and created the example at http://zigzag.cs.msu.su:7813/tracking.cpp It stores a pointer to a single class with two data members and a single base class. I get the following archive content. 1 1 C 0 10 4 1 0 1 Is seems too much for a class with implementation level of "object serializable". 10 and 4 is the data itself. "1 C" is probably class name, but what other data is? ** Implementation issues ** -- I suggest that all MPL expressions in the library are refactored for better readability. For example, the expression in save_non_pointer_type::invoke is 28 lines long. I think it should be possible to extract some of the subexressions and create a typedef with good name -- looks like instantination of those expression in all cases should not cause compile errors. ** Custom archive creation ** I've tried to create a custom archive class (in fact, polymorphic_oarchive), and got some comments. - Documentation says the derived class must provide operator<< and method 'load'. It also says there common_iarchive::operator<<. I wonder why the derived class should provide operator<<. Can't base operator call 'load' directly? - Even if not, why derived operator<< should have return * This(); not plain "return *this"? After all, we're in most derived object - It's needed to add friend class boost::serialization::load_access; to class declaration. However, it's not stated where this type is declared, and in fact in declared in *internal* header boost/archive/detail/iserializer.hpp And, finally, the right syntax seems to be: friend class boost::archive::load_access; (Note the namespace!) - The example uses: boost::serialization::load(* This(), t); Again, what header is this function in? The answer is that it's in the same header as above, and the line should be: boost::archive::load(* This(), t); - The documentation should really state the minimal set of 'load'/'save' overloads which will make archive usable. For example, it's probably not necessary to provide separate overload for 'bool', right? - (critical) It should be explained how the newly-created class can be tested. As it stands, one should either do superficial tests or try to integrate the new archive into existing tests. As for latter -- I don't know how to do that, and also, I think it's not necessary to run all the tests with the new archive. For example, serialization of vector and map is not likely to be broken with the new type. What I'm looking for is a test which saves/loads all possible types and verifies results. ** Various comments ** -- The BOOST_CLASS_EXPORT macros defines an explicit instantiation of a function. gcc rejests this when BOOST_CLASS_EXPORT is used inside some namespace. I've asked on comp.std.c++: http://groups.google.com/groups?q=Explicit+instantiation&hl=en&lr=&ie=UTF-8… 40zigzag.lvk.cs.msu.su&rnum=3 and got a reply directing me to: http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#275 Which means gcc is mostly right. So, the macro should either be changed somehow, or at least the restriction should bes documented -- using BOOST_CLASS_EXPORT outside of any namespaces is OK. -- Docs and code use "const unsigned long int version" everywhere. Is that really necessary, as opposed to "unsigned version"? -- The library saves char* as arrays of integers. The rationale section says: input of char * and wchar_t * could be altered to create a buffer overrun and potential security problem. I don't understand this point at all. How storing the elements as integer values helps with the buffer overrun? Moreover, library stores char* internally (e.g. for archive signature). What if that string is modified? Will that cause buffer overrun? -- The following program (yes, of two lines), causes a compile error: #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/export.hpp> It's because export.hpp uses 'instantiate_pointer_iserializer' but does not include the header where that class is defined. 'text_oarchive.hpp' does not include it either. The error goes away if I include #include <boost/archive/text_iarchive.hpp> but a better diagnostic is desirable. - Volodya

1 0