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

RE: [boost] Re: regression test tools ported to vacpp
by Rozental, Gennadiy 07 Jun '04

07 Jun '04

> Gennadiy Rozental wrote: > > > "Toon Knapen" <toon.knapen(a)fft.be> wrote in message > > news:40BF16BA.8080009@fft.be... > > > >>The regression test tools are finally ported to vacpp version 6 and > >>the > > > > I just spend half an hour to clean my code after this port. I do > > understand that you just wanted to make it work on your > compiler. But > > lets in a future first discuss it here on a list before you commit > > this kind of modifications. > > > > There was a discussion about all these issues for about a > week now with > clearly marked in the header that it was about the test > library. Since > you only responded to the last of the series of mails, I thought you > were OK with the other modifications. Yes. I was Ok with basic_cstring modification. Not the rest. I was actually hoped you (somebody familiar with PP) find a fix to IBM VA issues with BOOST_PP. As it stands now I simply disable access control for this compiler, what is wrong. > Generally I always contact the developer personally before > commiting a > change. However, I already have tried to contact you privately but I > never got a reply. It could be. I had to abandon three of my accounts lately. One because I moved. One because it's no longer free. One because it became unusable due to spam. Use gennadiy <dot> rozental <at> thomson <dot> com. > Anyway, in the future I will again try to contact you before > committing > soth. > > May I also ask to elaborate on what you found not to be clean > about the > port and how and why you changed these changes. This might be > interesting information for future ports. You couldn't just manually unfold macro definition all over the code. It makes code look like a mess IMO. See, what I did in cvs. Regards, Gennadiy.

1 0

Borland and BOOST_NO_FUNCTION_TEMPLATE_ORDERING
by Robert Ramey 07 Jun '04

07 Jun '04

Using Borland 5.5 I compile the following: #ifdef BOOST_NO_FUNCTION_TEMPLATE_ORDERING #error "NO function template ordering supported" #else #error "YES function template ordering supported" #endif And I get: Fatal F1003 c:\boost_1_31_0\libs\serialization\test\test_zmisc.cpp 4: Error directive: "YES function template ordering supported" Yet C:\boost_1_31_0\more\borland_cpp.html seems to suggest that I should get NO. What am I missing here? Robert Ramey

2 1

RE: [boost] Re: input_iterator_facade (was: Re: [iterator facade] Why isdereference const?)
by Rozental, Gennadiy 07 Jun '04

07 Jun '04

> I guess we're back to your old disagreements about > flexibility. Flexibility is > fine, but it adds complexity, both for implementors and the user, so > flexibility should be added only when absolutely necessary. > The eof_iterator > is intented to be as simple as possible. > > - Volodya Actually after some consideration I incline to agree with you on most points. Look in cvs on how my version looks now. Gennadiy.

2 1

[assign library post review again]
by Thorsten Ottosen 07 Jun '04

07 Jun '04

Dear all, a new zip file can be downloaded in the files section in the assignment folder: http://f3.grp.yahoofs.com/v1/4NHBQHrGLW_kAudslwozEsdMfU_iY8Ja3CZu5N40ZMlffd… or http://tinyurl.com/27ldw We still need to find a name. If nobody else besides Pavel and Tom has an opinion, I will go for Boost.Assignment with a majority vote of 2 to 1. br Thorsten

3 3

Re:[boost] Serializer and when to stop
by Robert Ramey 06 Jun '04

06 Jun '04

Darren Cook wrote: > I'm using boost::serializer between two programs: the first creates the > data then serializes it, the second loads that data in and analyzes it. > When I had just 420 data samples it all worked fine: I create a > vector<Sample> in memory, serialized it and loaded it in the other side. > When I moved to 7000 data samples the first program, the creator, sucked > all the memory from the machine and then some. 7000 samples? That doesn't seem very large in today's environment. I can't see why creating an archive should consume any significant memory at all. Nothing significant is constructed. Perhaps is a bug somewhere. In any case, you do raise in interesting issue which would crop up if serialization were used in something like data logging. > So I moved to serializing each data sample as it was created. > To read it back in I changed my code from this: > std::ifstream input_file(fname,std::ios::binary); > boost::archive::binary_iarchive archive(input_file); > std::vector<Sample> samples; > archive>>samples; > input_file.close(); > Into this: > std::ifstream input_file(fname,std::ios::binary); > boost::archive::binary_iarchive archive(input_file); > std::vector<Sample> samples; > samples.reserve(8000); > while(!input_file.eof()){ > Sample s; > archive>>s; > samples.push_back(s); > } > input_file.close(); > But every time it fails with an assert [1]. This seems to be when it has > reached end of file. I cannot know in advance how many data samples I'll > write to disk, so it seems I have three options: > A: Make a special "zero" version of Sample to mark end of file > B: At end of program 1 write the number of samples to a special file, > and read that in before starting the above loop, so I know when to stop. > C: Alter the serializer class to throw exception instead of an assert; > I can then catch it and carry on. I think I changed the assert/exception to check before loading rather than after for the next version. This would permit your code above to work as you expect. I'll have to double check. > What is the best way? Is adding a terminator byte to boost::serializer an > option (i.e. so I don't have to make a terminator version of each data > structure I want to serialize). > Incidentally my above loop does a copy of each sample as it adds it to > the vector. Is the above code going to be common enough to make it worth > including into boost::serializer as a helper function, which could then > be optimized with in-place construction or something clever like that? > (And then it could handle the termination handling itself as well.) The default implementation of STL collections create a new element on the stack and copy into the collection. Its as clever as I can make it without getting tripped up in things like exception safety, objects without default constructors, etc. Robert Ramey

2 1

Wave/flex_string and replace< InputIterator > bug
by Reece Dunn 05 Jun '04

05 Jun '04

Hi all, I am implementing test cases to validate the implementation of my fixed_string class and basic_string_impl (based on flex_string) and noticed a defect in the implementation of: template< typename InputIterator > inline string_type & replace( iterator i1, iterator i2, InputIterator j1, InputIterator j2 ); It handles the Integral case fine, but when the InputIterators are actually iterators, it asserts false, where the standard dictates it returns: replace( i1, i2, basic_string( j1, j2 )); or equivalent behaviour, e.g. in the implementation I'm using: replace( i1, i2, std::distance( j1, j2 ), char_type()); std::copy( j1, j2, i1 ); Is there any specific reason for this, or is it an implementation bug? Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 2

Re: [Boost-announce] Formal Review Tribool
by Haim Cohen 05 Jun '04

05 Jun '04

Hi, I am happy to contribute my review for the tribool library. I am a software engineer developing EDA (Electronic Design Automation) software, so I think I can contribute my 2 cents to the review of tribool, as I think EDA tools will benefit from this library. I did not compile the library. I have made a quick reading of this library, but an in-depth study of this problem domain before. First of all, my first comment is about the library's name, as well as the class name. In logic circuit simulation, there are 4 values : 0, 1, x ( which is tribool referred to as undetermine ), and z ( represents high impedance - or disconnection, and sometime referred to as "tri state" ). So, I think users will find it quite confusing when they see the 'tri' in the library's name. Since the library implements a logic value which has some value that is unknown, I would suggest 'unknown bool' or 'x bool'. Now to the interface. I think that a macro which enables renaming of the x value should not be supplied. This will make people's code less standard. Same as we all know what 'true' and 'false' mean, we should adopt a unique name for 'unknown yet quite determined logic value'. I think the default 'undetermine' name is not a good name. My suggestions : logic_x, x_value, x_logic, unknwon_bool . I also think the default tribool constructor should create a tribool object which is 'undetermine'. (Not false, as in the documentation) Besides the above, I think the interface of the class is good and succinct. Some point for thought : Users might want arrays of tribools, with all the support of bitwise operations. Is this should be a part of tribool as well ? I do not know. Now I will refer to the implementation. In real-life problems, programs might make a heavy usage of the tribool class for simulations of logic circuits. A logic circuit (at least the combinatoric part) is a DAG where nodes are logic gates, and directed archs are wires. This graph might be the result of a synthesis process, where a high level language for hardware description (e.g Verilog) is compiled into this DAG. Note : This is a very general and simple description of the process. Life are much more difficult. So, outputs will be calculated by performing lexicographic order of the DAG, and calculating from inputs to outputs. I am telling this, to convince that performance is *very* important here. With a quick look at the implementation code, I think that calculating the value using branches (if else) will not result with good performance. Calculations with true/false values only is fast - CPU vendors dedicate special hardware for this, so calculation can be made in one machine cycle. Even bitwise calculation (up to some word width) is done in one machine cycle. Compilers are making use of this, and (hopefully) compiles boolean and bitwise operators to the appropriate instruction. Unfortunately, I did not see any CPU which supports built in true/false/X arithmetic. And even if there are such CPUs available, we will not be able to use it, since boost libraries should be portable. So, it is very tempting to think - how can we implement efficient true/false/X arithmetic using the existing boolean arithmetic ? One tempting idea is to represent true/false/X with some integers, and use bitwise arithmetic to get the right results. It seems there are no such integer values. I think I even managed to proof this. Since there is already a library implementing 4 values logic (0,1,x,z) - which is SystemC - I took a quick look on how they do it with their 4-states logic data type called sc_logic. They use an approach which I think should be also used in tribool. It seems that they maintain lookup tables for each operation: AND, OR, NOT, XOR (!=) and XNOR (==). As the internal representation of tribool is enumerated type, we can use the integer value of this enumerated type to access the lookup tables (primitive 2D fixed-size and fixed-values arrays) and get the result of the calculation. This will be much faster since most CPUs has a special addressing mode for accessing arrays. So, I suggest to change implementation to use class-static fixed array to perform calculations. I know that the spirit of Boost is portability and not performance, but since what is suggested here is actually very similar to a primitive data type which might be heavily used in applications, I think it is important to consider performance as well. I hope this review would be found useful. Haim -- _____________________________________________________ Haim Cohen Software Engineer haim.cohen(a)analog.com / haimcohen2002(a)hotmail.com Analog Devices Israel (972) - 9 - 9715 406

4 4

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

05 Jun '04

Jeff Garland wrote: > > Robert Ramey wrote: > > > > >Russell Balest wrote > > > > > >>Does someone know where in the code I can implement this easily. > > >>I just want to ignore the comments. > > >> > > >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> ... > > > > > > > > > > > Good idea. I'll probably do that. > Another approach would be to preprocess your input files and strip the > added comments using XSLT, perl, or a simple regex program. That way you > don't have to modify the data structures under test. Someone might complain that my original method has 2 inconvenience features a) it requires modification to the serializations b) it includes the (null) comment string place holder in all the archives including the binary one. So another alternative would be to derive from the included xml_?archive classes included in the package and redefine the override for named-value pair so that it inserts/extracts  before or after every tag. This method has the following features: a) doesn't require any kluging up of class serializations b) has the advantage of automatically includes the  for all object instances c) has the disadvantage of automatically includes the  for all object instances d) doesn't add any overhead in other archives. If c) above is intolerable you would have the option of making your own wrapper similar to NVP - (NVT) that you would use in your serializations rather than NVP whenever you wanted a comment place holder. That's really a variation on my first suggestion. Take your pick and good luck Robert Ramey

1 0

question about logging into CVS
by Robert Ramey 05 Jun '04

05 Jun '04

I'm trying to build/update the CVS development tree on my machine and I can't get in. Here is my command line and response. What magic am I missing here? It seemed I had this problem some time ago and it just went away after a time. This time I've tried a few times over the lat 24 hours with always the same result. Robert Ramey cvs -d :pserver:anonymous@cvs.boost.sourceforge.net:/cvsroot/boost login Logging in to :pserver:anonymous@cvs.boost.sourceforge.net:2401:/cvsroot/boost cvs [login aborted]: connect to cvs.boost.sourceforge.net:2401 failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

2 1

Formal Review Tribool
by Thomas Witt 05 Jun '04

05 Jun '04

The review of Douglas Gregor's Tribool library begins now and runs through Saturday, May 29. Here is a short introduction to the library: The 3-state boolean library contains a single class, boost::logic::tribool, along with support functions and operator overloads that implement 3-state boolean logic. The tribool class acts like the built-in bool type, but for 3-state boolean logic. The three states are true, false, and indeterminate, where the first two states are equivalent to those of the C++ bool type and the last state represents an unknown boolean value (that may be true or false, we don't know). When reviewing the library, please remember to include: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. The library is available in the Boost files area as tribool-20031026.tgz Thank you, Thomas Witt -- Thomas Witt witt(a)acm.org

6 6

Re:[boost] Re: Re:A question on serialization library
by Robert Ramey 05 Jun '04

05 Jun '04

Virendra Verma wrote: > Library woundn't care but the user would. For example, how would user > delete or modify the object (pointed by pointer in the class) once > loaded since user has no way of knowing how the object was allocated? My > understanding is that the library creates and owns the object (using some > kind of class factory) when loading from input stream unless user keeps a > common allocator and somehow binds it to library's serializer. > > > If a class has a pointer to an object, how does class know that the > > > pointer was created by library or the class itself before > > > serialization? > > > It doesn't. Why would it need to? > > > Robert Ramey The guiding principle behind saving/loading pointers is that the loaded set of C++ structures is exactly equivalent to the original ones that were saved. So issues regarding pointer ownership don't change. That is, whatever ownership policy that was used when the pointer was saved will be the same one that can be used for the set of C++ structures recovered. The only problem would be where the there are pointers that are not included in the set of serialized data. As long as the serialized set is complete and self-contained there should be no problem. That is, there should be no pointers pointing into the serialized data that are themselves not serialized. Robert Ramey

1 0

boost::ref implicit conversion operator overload problems
by Jonathan Graehl 05 Jun '04

05 Jun '04

If I pass a boost::ref to a template function that calls operator() with one argument, the conversion to T& isn't used to find matching functions. The problem seems to also exist for other overloaded operators. What should I do in this case? I thought the idea was for the ref to be transparent to the template code you pass it to. As a stopgap, I wrote template functions "deref" that must be applied at the calling site (these just cast using unwrap_reference). This code works, but if you remove the "deref", doesn't compile under GCC or visual c++: #include <boost/ref.hpp> #include <cassert> template <class T> inline typename boost::unwrap_reference<T>::type & deref(T& t) { return t; } template <class T> inline const typename boost::unwrap_reference<T>::type & deref(const T& t) { return t; } struct Setter { int i; void operator()(int j) { i=j; } Setter() : i(0) {} Setter(int j) : i(j) {} }; template <class F> void apply1(F f) { deref(f)(1); } int main() { Setter s; apply1(s); assert(s.i == 0); apply1(boost::ref(s)); assert(s.i == 1); }

2 1

bug - function.hpp missing include guard - see sourceforge patch
by Nicolas Desjardins 05 Jun '04

05 Jun '04

Dear Boost Developers, I've submitted a patch to your sourceforge patch section - item # 966723. The patch is also attached to this mail. Summary: function.hpp missing include guard patch function.hpp does not have an #ifndef/#endif include guard. This patch adds #ifndef BOOST_FUNCTION_HPP at the top of the file and #endif at the bottom. Thanks, Nicolas Desjardins Software Developer Orthosoft Inc. *** function.hpp.original 2004-06-04 13:54:25.000000000 -0400 --- function.hpp 2004-06-04 13:53:54.000000000 -0400 *************** *** 10,15 **** --- 10,16 ---- // William Kempf, Jesse Jones and Karl Nelson were all very helpful in the // design of this library. + #ifndef BOOST_FUNCTION_HPP #include <boost/preprocessor/iterate.hpp> #include <boost/detail/workaround.hpp> *************** *** 62,64 **** --- 63,67 ---- # include BOOST_PP_ITERATE() # undef BOOST_PP_ITERATION_PARAMS_1 #endif + + #endif // BOOST_FUNCTION_HPP

2 1

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

more_io_4 in Files area
by Daryle Walker 04 Jun '04

04 Jun '04

The latest version of More-I/O is in our YahooGroups Files area at <http://groups.yahoo.com/group/boost/files/more_io_4.zip>. This should be the version to be used for the upcoming (second) review. I built this version before my recent hard-drive reformat and OS upgrade, and I haven't tested it yet on my new system. Quick portability checks would be appreciated. I noticed that some reviewed libraries put their code up on the (login-free) web space SourceForge reserved for the Sandbox CVS. How is that done? Does an administrator need to give me special access? (I already have read and write access to the CVS part of the Sandbox.) Contents: * I/O Manipulators * expansions of endl The "new line then flush" function was generalized with optional flushing, repeat amounts, and selectable breaking characters. Streams can output characters belonging to their character type, but also of type "char" (no matter what "char_type" is). The "multi_basic_newer" class template works with a specific "char_type", but any "traits_type". The "multi_newer" class works only with "char" values, but any "char_type" and "traits_type". The "multi_newl" works as an easy way to use "multi_newer". And "newl" encapsulates the most common case of "endl" - "flush". * input-oriented variations of endl Instead of writing a new line, these manipulators read (and ignore) lines instead. These work similarly to their output-oriented counterparts: "multi_basic_skipper", "multi_skipper", "multi_skipl", and "skipl". * basic non-oriented The "resetios" manipulator defaults most of a stream's formatting attributes. * complex non-oriented The "basic_ios_form" class template can encapsulate several simultaneous formatting changes in a potentially reusable object. Configurations of such objects can be done in a progressive manner. * Stream-buffer wrappers Creating new stream types generally involving making a custom stream buffer class, then connecting it to a generic stream class shell. The wrappers "basic_wrapping_istream", "basic_wrapping_ostream", and "basic_wrapping_iostream" help with the latter. These are used by all of the streams given later in this library. * Elementary streams * null-stream ("onullstream", etc.) Acts as an infinite character destination and an empty character source, like "/dev/null" * value-stream ("ivaluestream", etc.) Acts as an empty character destination and an infinite character source, like "/dev/zero" (The returned character is configurable.) * Character buffer streams (legacy of strstream) The std::basic_stringstream family works as an modernized substitute for std::strstream most of the time, but it's overkill when the dynamic memory nature isn't needed. The following class templates fill in the missing modes of the (surprisingly overloaded) std::strstream family. * run-time specified character buffer ("pointerstream", etc.) Only uses the character buffer given to it at construction time, gives EOF instead of going to dynamic memory management when full. There is a variant for constant buffers (read-only, of course). These classes are essential when an existing buffer can be used without forcing a copy (e.g. larger than 50% of RAM). * compile-time specified fixed-size character buffer The "basic_array_streambuf" class template uses an internally contained array as the character buffer. More convenient than the previous class when the maximum buffer size is fixed at compile time and there is little need for sharing the buffer. Changes from the last interim version (called "more_io_3b.zip"): * split the manipulator header into several headers * refined the license statements in some already-affected files Changes from the first formal review (called "more_io.zip"): * refined the interface and implementation of array-streams and stream-buffer wrappers (including a wrapping example) * added the null-stream, value-stream, and pointer-stream headers * added generalizations to the new-line and skip-line manipulators * added the non-oriented 'reset' and 'form' manipulators * split the manipulator header into several headers * changed the license statements -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 2

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

04 Jun '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> > Joaquín Mª López Muñoz <joaquin(a)tid.es> writes: [...] > > is in boost::detail::allocator), I don't have any problem with > renaming to > > allocator_helper (it's a better name, actually.) If no one else > objects (which > > I doubt) I'll apply the name change tomorrow. > > I think allocator_rebind would be a much better name than > allocator_helper. > Ummm, the problem with allocator_rebind is that the header contains some other stuff not strictly related to rebinding: * partial_std_allocator_wrapper * construct (allocator-independent construction function) * destroy (allocator-independent destruction function) ?? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5