- Boost - lists.boost.org

Re:[boost] serialization request
by Robert Ramey 05 Jun '04

05 Jun '04

Russell Balest wrote > My request is support for xml  in the serialization > xml archive. I believe it currently chokes if I add a comment in an xml > archive. > The application is for QA to compose test objects in xml and then > read them into applications with boost serialization. > It would be nice to annotate the test object 'templates' with comments > so QA can know what values are valid. > Does someone know where in the code I can implement this easily. > I just want to ignore the comments. Hmmm - my question is: What program is generating the XML archive in the first place? It its being generated by something other than the serialization library itself, its not going to be easy to generate such an archive that is guaranteed to be compatible with the C++ data structures of the reading program. (The organization of the data in the C++ program is what dicates the XML schema). At best it would be a maintenance pain in the neck to keep the reading program based on serialization in sync with some other program that doesn't use serialization to generate the XML archive. On the other hand, if the original XML archive is generated by the serialization library and just modified with comments, your request is very easy to accommodate. Just create a use the following in your serialize functions: Template<class Archive> Void serialize(Archive, my_class & t){ std::string comment; ar & BOOST_NVP("comment", comment); ar & BOOST_NVP("myclass_data", t);; } In which case your XML output will look like: ... <comment></comment> <myclass_data>..contents of t</myclass_data> ... After the archive is created you can edit the space between <comment> and </comment> with anything you want - it would be just thrown away. Generally I wouldn't encourage the practice of editing an archive but in this circumstance I could see it as an acceptable practice. But then this raises the question if the comments are so important, why are they being thrown them away? Shouldn't they be data read by the program? Robert Ramey

3 2

Re: Boost Mathematicians
by Michael D. Crawford 05 Jun '04

05 Jun '04

I have a bachelor's degree in physics, with the intention to go back to school and get a PhD someday. One thing I've had in mind for quite some time is to improve the state of high-energy physics software. Maybe it's improved since I was last in school, but when I did my senior thesis in 1993 the software I worked with was an awful mess. At the time I became convinced that bogus results were being published in the peer-reviewed journals because of undetected software bugs. Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com crawford(a)goingware.com Tilting at Windmills for a Better Tomorrow. "I give you this one rule of conduct. Do what you will, but speak out always. Be shunned, be hated, be ridiculed, be scared, be in doubt, but don't be gagged." -- John J. Chapman, "Make a Bonfire of Your Reputations" http://www.goingware.com/reputation/

4 3

Filesystem patch
by John Maddock 05 Jun '04

05 Jun '04

Beman, I'm committing a patch (below) for my last filesystem patch, basically I've found another reason why GetFileAttributes can fail when the file does not exist. John. $ cvs diff -u johnmaddock(a)cvs.sourceforge.net's password: cvs diff: Diffing . Index: operations_posix_windows.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/filesystem/src/operations_posix_windows.cpp, v retrieving revision 1.33 diff -u -r1.33 operations_posix_windows.cpp --- operations_posix_windows.cpp 30 Mar 2004 15:19:58 -0000 1.33 +++ operations_posix_windows.cpp 5 Jun 2004 11:47:23 -0000 @@ -321,10 +321,12 @@ # else if(::GetFileAttributesA( ph.string().c_str() ) == 0xFFFFFFFF) { - if((::GetLastError() == ERROR_FILE_NOT_FOUND) || (::GetLastError() == ERROR_PATH_NOT_FOUND)) + UINT err = ::GetLastError(); + if((err == ERROR_FILE_NOT_FOUND) || (err == ERROR_PATH_NOT_FOUND) || (err == ERROR_INVALID_NAME)) return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) + return true; } return true; # endif

1 0

Recent changes to minimal.hpp break dynamic_bitset and other libraries
by Gennaro Prota 05 Jun '04

05 Jun '04

Sorry for not investigating this myself, but I really don't have time to. It seems that the recent changes to boost/test/minimal.hpp (line 99, invocation of BOOST_READONLY_PROPERTY) cause troubles on IBM AIX. Many library tests seem to fail for that reason: http://boost.sourceforge.net/regression-logs/cs-AIX.html Genny.

2 1

scoped_ptr<T, D>
by Robert Ramey 05 Jun '04

05 Jun '04

Why isn't there a version of boost::scoped_ptr<T> that takes a deleter? That is, why isn't there scoped_ptr<T, D> ? It would be useful to me. Robert Ramey

3 3

FSM idea injetion
by Alexander Nasonov 05 Jun '04

05 Jun '04

Although my idea is supposed to solve multimethod support for dynamic_any it might be useful in FSM library. What I'm trying to build in last two weeks is some sort of typelists for overloaded function set. Each function is identified by overload_id<N> class with unique N. For example: struct read_number_transitions { // Signatures has the form NewState (OldState, Char) Positive operator()(overload_id<0>, StartState, Plus) const; Negative operator()(overload_id<1>, StartState, Minus) const; Positive operator()(overload_id<2>, StartState, Digit) const; Positive operator()(overload_id<3>, Positive, Digit) const; Negative operator()(overload_id<4>, Negative, Digit) const; static std::size_t const max_overload_id = 4; }; This approach has advantage over typelists in some cases because things are right in their places. In the example, every transition, on one hand, is represented by a call operator (this is natural, because transition is a function that takes old state and a char and returns a new state); on the other hand, argument types and return type (a signature) can be retrieved from the call operator. The retrieval is a bit problematic but I'm working on this. The problem is a lack of typeof in C++. If it were available you could write: template<int N, class C, class R, class T> mpl::identity<R(T)> tester(R (C::*)(overload_id<N>, T) const); typedef typeof(tester<0>(&read_number_transitions::operator()))::type sig0; Without typeof you know signature R(T) only inside tester<0>. This means in particular, that, in order to accumulate all signatures you have to call tester<N> recursively: call tester<0> => Positive(StartState, Plus) call tester<1> => Negative(StartState, Minus) call tester<2> => Positive (StartState, Digit) call tester<3> => Positive (Positive, Digit) call tester<4> => Negative (Negative, Digit) For other compile-time algorithms we need something similar. Even worse, often we need chain of algorithms, for example: find a first occurrence of StartState as a first argument, get a return type from that signature, find that type among first arguments and so on. We have to go deeper and deeper. In my stress tests I use 1000 functions. Can you imagine a call stack as deep as 1000 multiplied by a length of algorithms chain? Fortunately, sometimes it's possible to make it plain. 1. Predicates have boolean result, therefore, we can use sizeof/yes_type/no_type to calculate their result: template<class Predicate, int N, class C, class R, class T> typename yes_type_if< Predicate::template apply<R(T)>::type // mpl::apply style >::type tester(R (C::*)(overload_id<N>, T) const); // Example bool const result = sizeof( tester<is_same<Positive(Positive,Digit), _1>, 3>(&read_number_transitions) ) == sizeof(yes_type); I already implemented several variants of *contains* algorithm. You can take a look at g++ 3.4.0 performance here: http://cpp-experiment.sourceforge.net/overloads_contains.png This is a performance plot (in seconds) of various strategies for *contains* algorithm which is applied to a function set of length 1000. Worst case takes 80+ seconds to compile for *one-at-once linear* basic strategy while optimized strategy completes its job in 12 seconds. It's really fast. I doubt that typelist of length 1000 can ever exist without compiler panic ;-) Similar work can be done for find/find_if // returns bool contains<read_number_transitions, Negative(Negative,Digit)>::value; // returns index of Negative(Negative,Digit) find<read_number_transitions, Negative(Negative,Digit)>::value; // returns -1 because int isn't even a signature find_if<read_number_transitions,is_same<int, _1> >::value; 2. Pair comparisons. It's not yet done. The sizeof trick can be modified slightly: template<class Predicate, int N, int M, class C, class R1, class R2, class T1, class T2> typename yes_type_if< Predicate::template apply<R1(T1), R2(T2)>::type >::type tester( R1 (C::*)(overload_id<N>, T1) const, R2 (C::*)(overload_id<M>, T2) const ); Suppose, you have this cool type: typedef is_base_and_derived< function_arg<1, _1>, // first argument of signature _1 function_arg<1, _2> // first argument of signature _2 > cool; Then you can check whether a first argument of overload N is a base of a first argument of overload M: bool const result = sizeof( tester<cool,N,M>(&read_number_transitions, &read_number_transitions) ) == 1; -- Alexander Nasonov

2 3

default version of STLport
by Gennadiy Rozental 05 Jun '04

05 Jun '04

Why don't we switch to 4.6.2 as default version of STLport? Which version is used in regression tests? Gennadiy.

1 0

Re: [boost] Re: iostreams library review
by slavek.f.kuzniar＠jpmorgan.com 05 Jun '04

05 Jun '04

I downloaded the library from the yahoo link you mentioned in the review request. When trying to use 'filtered_stream' I ran into some compilation issues (RedHat 9, g++ 3.3) and before looking into it I wanted to know the review status. Knowing that the library is in the review pipeline I will give it another try. Some time ago I developed simple iostream adapter 'library' that allows to wrap IO device (sockets, pipes, etc) in std::[i,o,io]stream that is very similar to your sink/source technique. One difference is that the adapter is a template class parameterized by the source/sink types. Since your library offers this functionality (plus much more) I am very pleased it will become part of boost soon. technews@kangarool ogic.com To: boost(a)lists.boost.org Sent by: cc: boost-bounces@list Subject: [boost] Re: iostreams library review s.boost.org 05/29/04 06:41 PM Please respond to boost <slavek.f.kuzniar(a)jpmorgan.com> wrote in message news:OFF5E3130C.48F086BB-ON85256EA2.004FA2A3@ny.jpmorgan.com... > On Boost mailing archives I found a review request for Iostreams Library > by Jonathan Turkanis. I did not see any follow-up and the library is not > part of latest release so I suspect the review did not happen. Anyone knows > what is the fate of this library? Thanks for your interest! The previous version available at http://www.xmission.com/~turkanis/iostreams/. I've since made some major simplifications and improvements, and am scrambing to update the docs. It now contains support for memory-mapped files (from Craig Henderson) and for compression and decompression in the zlib, gzip and bzip2 formats. Jonathan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.

3 9

Re: [boost] Re: New utility at boost/detail/allocator.hpp
by JOAQUIN LOPEZ MU?Z 04 Jun '04

04 Jun '04

----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Viernes, Junio 4, 2004 8:39 pm Asunto: Re: [boost] Re: New utility at boost/detail/allocator.hpp > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > > Rob Stewart <stewart <at> sig.com> writes: > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > > > > > > > For these reasons, I think allocator_rebind is not an > > > > appropriate name. Anyone suggesting a better name than > > > > allocator_helper? (Andreas? you wanted to use this stuff) > > > > > > Why not simply allocator_utilities.hpp? > > > > Yes, sounds good. Same name for the namespace > > (boost::detail::allocator_utilities)? Isn't it > > a little long? > > Any reason why the ns can't be "allocator?" This code will > coexist with any allocator library that may appear, I should > think, and these should interoperate with such a library; it > might even become part of such a library. I can't see a problem > with them sharing a ns. (That also suggests that the directory > for the header is boost/allocator/detail.) > That's too bold IMHO. We don't even know how a potential future allocator library might look like to impose it to receive this: more than a bequest to that library, this stuff could be an inconvenient burden. So, I propose boost/detail/allocator_utilities.hpp boost::detail::allocator Later on, we're still free to move (or alias) this into boost::allocator if it fits into that future allocator lib. What do you think? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] static sized strings
by Reece Dunn 04 Jun '04

04 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Martin wrote: > > >2. Substrings > > >------------- > > >One of the applications I can see for fixed_string is when you want to > > >avoid > > >dynamic allocation but still want to use the std::string interface and > > >algorithms. In that perspective it seems strange that substr returns a > > >std::string instead of a fixed_string. > >Agreed. I agree too. It is just that the current implementation cannot create an instance of boost::char_string (because of the ABC - necessary to allow operations on variable-capacity strings). Also, you cannot get at the fixed_string type/length at compile time so it is not possible to derive the *return type* at compile time. > > This is related to the above problem. You cannot create an instance of > > boost::char_string, etc. and as such cannot implement substr in the >usual > > way (this is the proplem I was having with operator+). The solution >would be > > to defione an alternate substr function in fixed_string, but this would >not > > solve the problem for boost::char_string, etc. > > > > The alternative would be to use a ranged string (pointer to the >fixed_string > > buffer and length), but the problem with this is null-termination. > > > > I do not see an easy way around this without removing the ABC design, >since > > it is not possible to do fixed_string< length() > or something similar. > >Couldn't substr() be a pure virtual function in char_string that >deferred to the derived class to create a copy of itself? The >derived class can just create a duplicate of itself, including >the current capacity. That capacity is guarranteed to be >sufficient to hold any substring requested. The return type cannot be boost::fixed_string_base because of the whole ABC issue. Therefore, the return type needs to be a reference or a pointer. It is possible to do this, and have: class fixed_string { inline fixed_string_base & substr_( size_type pos, size_type n ) { return( this_type( *this, pos, n )); } }; This is problematic because of returning the address of a temporary - and leads to unpredictable output. I am looking for a better solution to this. I am also thinking about how to remove the ABC from the implementation using a technique pointed out by someone on this thread (can't remember who): class fs_base { size_t len; szie_t capacity; // needed for buffer-safe operations CharT str[ 1 ]; // string manipulation functions fs_base( size_t c ): capacity( c ){} }; template< size_t n > class fixed_string: public fs_base { CharT data[ n ]; fixed_string(): fs_base( n ){} }; I'll need to look into this, to see what effect this will have, to see if it is a possible replacement for the ABC. What do other people think? Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 3