April 2004 - Boost - lists.preview.boost.org

[serialization] not so formal review
by Gennadiy Rozental 26 Apr '04

26 Apr '04

Hi, Robert. Unfortunately I was not able to look with proper attention onto your submission during review. One thing I did though: all the major issues I mentioned in my original review looks resolved. I am sure will look into more details later, but for now it is enough for me to cast YES vote. This library cover very important problem domain in software development and I think we all have now solid solution. Thanks and congratulation to Robert for being able to bring it to us. Regards, Gennadiy.

1 0

Serialization Formal Review #2
by Jeff Garland 26 Apr '04

26 Apr '04

All - Today (April 13th) is the start of the formal review of the Serialization library by Robert Ramey. The review will run until Monday April 26th. I will be serving as review manager. Library details are below. I have a number of special requests for this review: 1) This is a large, complex, and important library. Please don't wait till the end of the review period to start your review -- there is no additional room in the review schedule to extend the review period. 2) I am particularly interested in hearing from parties that have tried to extend the library by adding serialization for a new type or by building a new type of archive. The ability to easily extend the library for new types and novel types of archives is critical for this library. 3) If you reviewed the library during the first review, I would like your evaluation of whether the new version of the library addresses your original concerns. Also, if this is a re-review I would appreciate if you could send me a weblink from the mail archive to your original review posting(s). 4) Finally, I would like reviewers to indicate parts of the library that might become standalone boost libraries. While this will have little bearing on the acceptance / rejection of the library it might allow a reduction in the size of the library. As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments ********************************************** Library Details: ********************************************** >From the library synopsis: Here, we use the term "serialization" to mean the reversible deconstruction of an arbitrary set of C++ data structures to a sequence of bytes. Such a system can be used to reconstitute an equivalent structure in another program context. Depending on this context, this might used implement object persistence, remote parameter passing or other facility. In this system we use the term "archive" to refer to a specific rendering of this stream of bytes. This could be a file of binary data, text data, XML, or some other created by the user of this library. The latest package can be found at the following locations: http://www.rrsd.com/boost/index.htm http://groups.yahoo.com/group/boost/files/serialization18.zip Thanks, Jeff

5 6

documentation bug report for boost::random
by Dave Gomboc 25 Apr '04

25 Apr '04

The code sample at the top of the documentation is missing a semicolon. > boost::uniform_int<> six(1,6) // distribution that maps to 1..6 > // see random number distributions Dave

1 0

boost:filesystem::path throws eception on valid path name
by Andreas Pokorny 25 Apr '04

25 Apr '04

Hi, $ cat test.cpp #include <stdexcept> #include <iostream> #include <boost/filesystem/path.hpp> int main() { try { boost::filesystem::path p("/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/"); } catch( std::exception &e ) { std::cout << e.what() << std::endl; } catch(...) { std::cout << "Unknown exception" << std::endl; } } $ g++ test.cpp -o test -lboost_filesystem $ ./test boost::filesystem::path: invalid name "g++-v3" in path: "/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/" Is that supposed to happen? Regards, Andreas Pokorny

2 1

Quick thought on Date-Time
by Daryle Walker 25 Apr '04

25 Apr '04

[NOTE: I haven't worked on this library; I'm just going by the posts I see here.] For this increment/decrement by a month problem, is there any way to store a date with only a month resolution? Nothing smaller will be stored, so day crossovers won't be a problem. Wouldn't something similar have/already-had been done when skipping days but ignoring the exact hour? (Or does every date-time object work at the fractional-second level? If so, maybe that's what needs fixing.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 9

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 11:19 pm Asunto: Re: [boost] [serialization+date_time] Serialization Review: serialization of dates [...] > > #include "boost/archive/basic_archive.hpp" > > #include "boost/serialization/split_free.hpp" > > #include "boost/serialization/string.hpp" > > > > I think the two first are unnecessary (could you > > try this out? thx) > > Actually none of them are necessary. Ah the wonder of templates :-) > Wonderful they are, you're right :) So, I guess this is as good as it can get. Slightly OT: this issue of POI could be taken a little further to allow interoperability between (not necessarily template-based) libraries without the headache of having to include portions of them. This is what I have in mind: suppose a header-based library A provides support for or somehow uses a non-header (i.e. requires linking) library B, like this: // lib A #include <b.hpp> inline foo(){...} // does not depend on B inline bar(){...} // does not depend on B inline mess_with_B(){...} Now, if B is not linked in the project mess_with_B won't compile, so one has to move this function to a separate header that the user will/won't include depending of whether she wishes that functionality. Instead, one can do the following: // lib A #include <b.hpp> inline foo(){...} inline bar(){...} template<typename dummy> inline mess_with_B(dummy* =0){...} Voila, A works even if B is not linked in. If the user has linked B and wants to use mess_with_B, then she just has to call mess_with_B() as usual, template instantiation model will do the rest. Maybe I'm missing something, but I think this approach could be investigated a little further. One good example of use is for interoperability with Boost.Threads, for instance. Totally OT: I've posted a question regarding multi_index and composite keys a few posts ago. You being one of the reviewers, your opinion on that is greatly appreciated :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 9:25 pm Asunto: Re: [boost] [serialization+date_time] Serialization Review: serialization of dates > On Sun, 25 Apr 2004 20:34:34 +0200, JOAQUIN LOPEZ MU?Z wrote > > > Regarding the need to include "greg_serialize.hpp", I think > > a better approach, from the point of view of the user, is > > that serialization support is already embedded into > > "boost/date_time/gregorian/gregorian_types.hpp" and > > automatically provided if one of the archive headers > > > >...snip details... > > > > See what I mean? For this to work with minimum > > overhead, we'd need some forward headers for serialize, > > save, load, etc. to be included by > > "boost/date_time/gregorian/gregorian.hpp". > > Yes, I agree on the user perspecitive. I'm sorry I forgot to say > that in the > first few emails. I did say it here: > http://lists.boost.org/MailArchives/boost/msg63885.php > > > I'm not sure whether this forward headers are already > > provided by Robert's library. > > Why would I need 'forward headers' for this? > Well, since serialization support is entirely contained in function templates, you don't need any actual definition till POI (I might be wrong here, but I guess I'm not.) This can help reduce compilation time if you're not going to serialize dates at all. Matter of fact, seeing the includes in your example #include "boost/archive/basic_archive.hpp" #include "boost/serialization/split_free.hpp" #include "boost/serialization/string.hpp" I think the two first are unnecessary (could you try this out? thx) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[static_assert] Bad compiler message
by Vladimir Prus 25 Apr '04

25 Apr '04

Hello, I've just found out that the following program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT(false); return 0; } compiled with gcc 3.3 produces: sa.cpp:6: error: invalid application of `sizeof' to an incomplete type which is not as nice as sa.cpp:6: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' that gcc 2.95 generates and sa.cpp:6: `sizeof' applied to incomplete type ` boost::STATIC_ASSERTION_FAILURE<false>' That 3.2 generates. The behaviour of 3.4 is the same as for 3.3. So, there are some questions: 1. Should I bug gcc developers about this? 2. Anybody knows another way to force better diagnostic? 3. Is it possible to make regression tests for static_assert always include compiler messages, so that we know the diagnostic is OK? - Volodya

6 7

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 0:37 am Asunto: [boost] [serialization+date_time] Serialization Review: serialization of dates > All - > > Since I'm the review manager I'm not doing a formal review of the > library, but > I thought I'd share some code and a few thoughts. If > serialization is > accepted users people will ask me and other library authors to provide > serialization support for some of the types in their libraries. So > to get a > feel for the difficulty of extending serialization for new types I > wrote the > serialization code for gregorian::date and some example code to > try it out. Regarding the need to include "greg_serialize.hpp", I think a better approach, from the point of view of the user, is that serialization support is already embedded into "boost/date_time/gregorian/gregorian_types.hpp" and automatically provided if one of the archive headers are included by the user program: // case 1 "boost/date_time/gregorian/gregorian.hpp" int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // does not work, text_oarchive not defined. oa << d; } // case 2 "boost/date_time/gregorian/gregorian.hpp" #include <boost/archive/text_oarchive.hpp> int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // OK, no need to include anything else fromd date-time oa << d; } See what I mean? For this to work with minimum overhead, we'd need some forward headers for serialize, save, load, etc. to be included by "boost/date_time/gregorian/gregorian.hpp". I'm not sure whether this forward headers are already provided by Robert's library. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re:Re: [boost] [serialization+date_time] Serialization Review:serialization of dates
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: >Well, I think it belongs in the library supplying the data type not in > serialization. Few reasons for this... ... good reasons listed 4) Many serialization implementations will turn out to be trivial. An example is Thorsten O? pointer container wrapper class which resulted in 6 lines of code. Furthermore these six lines were inline template member functions (two functions 3 lines each) which required no header inclusion at all. In cases such as this, the compiler/runtime cost is zero if the application doesn't use serialization. I believe that this will be a common case for many of the "utility" classes. FWIW - this gets my vote: > So for the particular case I posted I was planning on putting this code in > boost/date_time/gregorian/greg_serialize.hpp > Time could would go into > boost/date_time/posix_time/time_serialize.hpp Considering the above, you might want to think about tweaking date time. By making a default constructor (that initializes as "not a date"), you could implement serialization as template member functions along the lines of the above. In this way adding serialization would: a) no extra compile time overhead b) no extra run-time overhead c) no extra file inclusion d) no extra "conceptual" overhead. That is one would never have to even think about it - it would always be there just lurking waiting to be of service. It would just work when used. Robert Ramey

3 3