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

[iterator + lambda] transform_iterator and lambda expression
by Vladimir Prus 04 Jun '04

04 Jun '04

I'm again trying to use FP in C++, and having problems. What I wanted to do was: for_each(predecesor(v, g), /* BLL expression */ ); where predecessor(..) returns a pair of 'transform_iterator' instances. The simplest example which illustrates the problem is: struct functor { typedef int result_type; int operator()(int i) const { return i+1; }; }; transform_iterator<functor, vector<int>::iterator> it(v.begin()); (cout << _1)(*it); This does not compile, because operator* of transform_iterator return rvalue which can't be bound to non-const reference that operator() of the lambda expression accepts. Of all workarounds suggsted on BLL docs, only break_const is applicable to my case (I want to pass non-const references to the lambda, so const_parameters won't do), and break_const is scary. It looks like a serious problem with using FP, so I wonder what can be done. Maybe, transform_iterator should have yet another template parameter telling if it should store a value internally, and return reference (i.e. lvalue) in that case? It need not be enabled by default, but functions like my 'predecessor' above would make use of that extra template parameter. - Volodya

4 8

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

04 Jun '04

Virendra Verma wrote: > 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

2 1

transform_iterator( Iterator const& x ) ???
by David Abrahams 04 Jun '04

04 Jun '04

I'm not sure why I never saw this on the list, but since I saw the moderation request and I figure you deserve a reply... boost-owner(a)lists.boost.org writes: > From: "Sascha" <vudu(a)gmx.net> > Subject: boost::transform_iterator( Iterator const& x ) ??? > To: <boost(a)lists.boost.org> > Date: Thu, 3 Jun 2004 00:22:18 +0200 > > hi > > a simple question about the construction of > boost::transform_iterator. > > currently there are two ctors implemented: > > transform_iterator(); > transform_iterator(Iterator const& x, UnaryFunction f); > > why does boost::transform_iterator(Iterator const& x) not exist leaving > the function object default constructed? Are you looking at the source code or the documentation? Oh, I see you're doing as you should and looking at the documentation! Well it turns out that the source code actually contains this constructor: explicit transform_iterator(Iterator const& x) : super_t(x) { // don't provide this constructor if UnaryFunction is a // function pointer type, since it will be 0. Too dangerous. BOOST_STATIC_ASSERT(is_class<UnaryFunction>::value); } > can I add it without getting in trouble? No, but we can fix the documentation ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[Boost-bugs] [ boost-Bugs-966496 ] [BGL] Asymmetry between read_graphviz() and write_graphviz()
by SourceForge.net 04 Jun '04

04 Jun '04

Bugs item #966496, was opened at 2004-06-04 06:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=966496&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: [BGL] Asymmetry between read_graphviz() and write_graphviz() Initial Comment: During some experiments with the BGL-GraphViz interface, I observed a significant asymmetry between a given DOT graph input with boost::read_graphviz() and output with boost::write_graphviz() (without changing any attributes). Given the input DOT file <metro.dot> (which is, of course, much longer with the full set of information), the elementary BGL program <metro.cxx> transforms this into the output DOT file <metro_boost.dot> (the three files are attached to this submission). It seems that somewhere on the way, the graph and node (and edge) attributes get clobbered. Note that even the graph name "metro" gets replaced by the name of the (last) subgraph "ligne_1", and /all/ node attributes get mixed up. This seems to be somewhat similar to the recent edge-related problem posted by Hideaki Hiraki to the boost-users list. I have not (yet) tried to mess with the graphviz parser code, so I am asking here for help. Thanks. Greetings, Andreas <andreas dot scherer at rb-its dot de> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=966496&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

BOOST_NO_STDC_NAMESPACE and LIBCOMO
by Robert Ramey 04 Jun '04

04 Jun '04

Commeau I'm building with como-win32 with the libcomo library. It seems that BOOST_NO_STDC_NAMESPACE is set to true with this combination and that it should be set to false for this combination. Robert Ramey

3 2

RE: [boost] Re: Re: Re: Boost Mathematicians
by Hurd, Matthew 04 Jun '04

04 Jun '04

> Behalf Of Thorsten Ottosen > > > "Hurd, Matthew" <hurdm(a)sig.com> wrote in message <snip> > See Type-Based Alias Analysis: > > http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm?temp=fXniOPb1aS Thanks for the link. > > I my suggestion for Design by Contract I mentioned that aliasing (or lack of > it) > could be expressed by a function precondition: > > void foo( T* l, T* r, size_t sz ) > precondition() { > std::less<T*>( l + sz, r ) || std::less<T*>( r + sz, l ); > }; That's ok for simple contiguous spaces but it becomes intractable with complex object collections, but then perhaps the efficiency probably ain't so important as you've lost the locality anyway. > | You still need to wrap as you can't hope, nor should you try, to offer > | all algorithms from all languages. > > probably not. But simply wrapping stuff is not always an option. For eaxample, > in the > statistics lib I'm working on, I need to invert matrices. If I write wrappers, > I will > probably only be ably to support float,double,complex leaving out higher > precsion > datatypes. Yup. Generic interface first. Implementation with ublas where possible. Other generic implementations. Specialize for performance I guess. I haven't looked at uBLAs for a while but there was an interface to ATLAS for performance and also a partial wrapper for LAPACK. Not sure if the use of ATLAS or otherwise is or can be made to be automatic at compile time, but this would give us most of what we need. Generic implementations with pluggable special high performance specializations wherever possible. Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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] Proposed Boost Library for Data Series Analysis
by Hurd, Matthew 04 Jun '04

04 Jun '04

> Behalf Of Tom Brinkman > Sounds very powerful. Is there any additional web > information to help me incorporate > these ideas. Not that I know of, but it isn't overly original in approach. Most interactive tools, such as a spreadsheet, will have something like a DAG structure at their core to represent a model-view type dependency thingo. Wish I had more time to play with this stuff... Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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] [assignment library post review]
by Rozental, Gennadiy 04 Jun '04

04 Jun '04

> The post review version can be downloaded from > http://tinyurl.com/38c7d Could you please clean archive from garbage in test directory. Gennadiy.

2 1

RE: [boost] [assignment library post review]
by Max Khesin 04 Jun '04

04 Jun '04

Thorsten, link's dead. > -----Original Message----- > From: Thorsten Ottosen [mailto:nesotto@cs.auc.dk] > Sent: Thursday, June 03, 2004 1:08 PM > To: boost(a)lists.boost.org > Subject: [boost] [assignment library post review] > > > Dear All, > > The post review version can be downloaded from > > http://tinyurl.com/38c7d This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

Proposed Boost Library for Data Series Analysis
by Tom Brinkman 04 Jun '04

04 Jun '04

I've created a library for data series calculation and analysis. I've received permission to open-source the library and I would like to submit it for review to the boost if there is sufficient interest. Simple Example 1: Calculate the 10-day simple-moving-average of the 15 exponential-moving-average. (Demonstrates: boost::algorithm::compose). std::vector<double> v1; v1 += 3,4,4,6,7,8,4,7,8,3,2,3,2,5; typedef boost::algorithm::compose<double, boost::function<double (double)>, boost::function<double (double)> > COMPOSE; std::vector<double> v; std::transform(v1.begin(), v1.end(), std::back_inserter(v), COMPOSE(moving_average(15), exponential_moving_average(10))); Simple Example 2 (contrived): * Add 100 to the results from above. * then divide by 100, * then subtract by 100, * then multiply by 100. std::vector<double> v1; v1 += 3,4,4,6,7,8,4,7,8,3,2,3,2,5; typedef boost::algorithm::compose<double, boost::function<double (double)>, boost::function<double (double), boost::function<double (double), boost::function<double (double)> > COMPOSE2; std::vector<double> v2; std::transform(v.begin(), v.end(), std::back_inserter(v2), COMPOSE2(_1 += 100, _1 /= 100, _1 -= 100, _1 *= 100)); Here is a paritial list of functors currently provided by the library. Many additional functors have been written but are fairly specific to our problem domain. moving_average triangle_moving_average rate_of_change momentum vertical_horizontal_filter volatility weighted_moving_average exponential_moving_average variable_moving_average accumulate_n relative_strengh_index cumulative_sum max_numeric_limit variance standard_deviation correlation z_score Please tell me if there is any interest in this library. I will boostify it and submit it for review if there is sufficient interest. Regards, Tom Brinkman __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

5 4

boost/format/format_class.hpp workaround for aC++
by DY, JERRY U (SBCSI) 03 Jun '04

03 Jun '04

Would the experts let me know if there's a better way of accomplishing the same effect below? I have modified boost/format/format_class.hpp and added a line 93 (See attached) && !BOOST_WORKAROUND( __HP_aCC, != 0) <<format_class.hpp>> Thanks! -Jerry

1 0

RE: [boost] [assignment library post review]
by Rozental, Gennadiy 03 Jun '04

03 Jun '04

> The post review version can be downloaded from > > http://tinyurl.com/38c7d Does not work Gennadiy

1 0

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

03 Jun '04

Martin wrote: >I have tested the sandbox version of the static sized strings. It works >fine >but there are a few inconveniences that I want to point out. I have been writing a series of test cases (boost-sandbox/libs/test) and fixing several bugs. Have you tried these? Also, what compiler(s) are you using? >1. The abstract base class. >--------------------------- >Having an ABC to handle fixed strings of various lengths is a good idea but >it >is not very practical. I understand that the main purpose is to allow fixed >strings to be passed to functions without using templates. > >int countwords(const boost::char_string & str); > >unfortunatly the ABC makes it difficult to pass anything but fixed strings. >If >you want to pass a string literal, a character array or a std::string you >must >create a temporary fixed_string<>. > >countwords(boost::fixed_string<20>("The quick brown fox")); This is an unfortunate side-affect of using the ABC technique that affects John's implementation as well. Your proposed solution looks interesting, but I don't know how practical it will be for the string manipulation operations (w.r.t. buffer safety). Rob proposed a "make_string" function, which would simplify this a little. >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. 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. >3. resize >--------- >Still missing a method to update the length to reflect the current string >length. I think a resize without arguments would be a good solution. > >boost::fixed_string str<10> >strtime(str.buffer()); >str.resize(); I'll add this soon. I have mainly been focusing on getting documentation and the test cases up. >4. operator[] >------------------------- >I don't have the standard basic_string interface available but I am pretty >sure that operator[] doesn't throw an exception if the argument is outside >max_size(). This is a deviation from the standard. If i > capacity() then the index will be out of the string buffer range and a buffer overrun can occur. This generates an exception to prevent the overrun. I should add this to the docs. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

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

03 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Rob Stewart wrote: > > >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > John Nagle wrote: > > [snip] > > I think you misunderstand what I am trying to say. See my comments >below. > >Actually, I think you misunderstood my points. ok. > > [1] You need to specify the size of the buffer. You cannot declare an >object > > of type fixed_string_base (as it is abstract), you can only have >references > > and pointers to it so you can operate on variable-capacity strings. > >Ah, but you missed that I was declaring a fixed_string_base, >where string capacity is not known. I was relying on >make_fixed_string() to deduce the array length and create an >appropriate fixed_string for it. I didn't miss it, just misunderstood what you intended. > > [2] This is the point that we are discussing. Should this line be: > > > > fixed_string< LENGTH > t; > > > > as will work with the current sandbox implementation (my suggestion #2), >or > > should it be: > > > > fixed_string< LENGTH + 1 > t; > >And that's exactly my point. It should be the former as shown by >my equivalencies. > > > Different programmers favour the different semantics, so I ask: why not > > parameterise it, providing a default behaviour. > >I'm not so sure they do and I'm not sure you need to allow for >it. If you do, I suspect you'll encourage off-by-one mistakes. >Granted, those mistakes won't result in overruns, but they will >be annoying. Furthermore that will result in different >fixed_string types; will you provide for conversions among them? >(That is, for example, from a fixed_string that adds one to the >capacity to one that doesn't?) It is the former in the implementation I have, but if you have char data[ 100 ]; // manipulate and use the data buffer in this example, the buffer is 100 characters, but only 99 are writable, with the 100th being a null character (assuming this is a C-style string). Using the current implementation, this would lead to fixed_string< 100 > data; having an extra character. This would transfer to the other model. > > >(I know there is no make_fixed_string() -- yet -- but such a > > >facility would be appropriate.) > > > > Er... the fixed_string constructors! When you declare the object, you >should > > know the size of the buffer you are using, e.g.: > > > > fixed_string< 100 > data; > >The problem is that you don't know the length of the string. >That is, with this code: > > char s[] = "1234"; > >s is a fixed size array of char with five elements. The >programmer didn't have to write: > > char s[5] = "1234"; > >Instead, the compiler figured out the length. > >That's what I'm trying to provide an equivalence for: > > fixed_string_base & s = make_fixed_string("1234"); > >With that approach, the client doesn't need to precompute the >length of the literal and can rely on the compiler (and template >magic) to deduce it and use it to create a fixed_string<5>. > >I've shown returning by value (with the temporary bound to the >reference s), but it could return a smart pointer just as well. Your original example didn't have fixed_string_base as a reference. It should be easy to implement a make_fixed_string function. > > >I think this clearer reveals that fixed_string's size parameter > ^^^^^^^ >That should have been "clearly." > > > >should specify the number of characters. Remember, one can use > > >boost::array to manage a fixed size, non-string buffer. If > > >buffer overrun protection is insufficient in boost::array, that > > >should be fixed (or a new class should be added to Boost). Thus, > > >fixed_string can ignore that usage. I am not disputing this. The question is, is the null terminator counted as a character. For the example you show, it is, but for buffers (see the example above) it isn't. I haven't got a conversion between the two models because I am only implementing the one model at the moment, but conversion would be automatic because the functions that take strings as arguments take fixed_string_base & arguments, so they should be usable regardless, consider: boost::fixed_string< 20 > str1( "This is a long string!" ); boost::fixed_string< 10 > str2; str2.assign( str1 ); This will work (cutting the string short in str2) even though the strings are of different capacities. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

3 5

A question on serialization library
by Virendra Verma 03 Jun '04

03 Jun '04

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?

1 0

Re:[boost] NEW lib: Named Variable - safe & convenient output of expressions together with their name
by Robert Ramey 03 Jun '04

03 Jun '04

M G wrote: > the "Named Variable Lib" is a lightweight macro & > template library which allows you to write: This looks equivalent to the Name-Value Pair implemented as part of the serialization library already accepted into boost. It not documented separately as other candidates for separate boost components are - maybe it should have been. I don't see this as a problem. The one in the serialization library only has the functionality required to support serialization and I have often expressed the desire that appropriate pieces be moved out of the serialization library and into boost generally - along with the responsibilities of maintenance, documentation, testing, etc. So please look at the serialization library one and see if you can reconcile all of this. Robert Ramey

1 0

Bug, signals, use of default Combiner
by Ville Varis 03 Jun '04

03 Jun '04

Hi, The next piece of code fails with assertion when calling signals without any connections attached to it. <code> #include <boost/signal.hpp> void test_signaling() { ::boost::signal0<int> sig; /* Next call asserts in boost/last_value.hpp line 29 assert(first != last); */ sig(); } </code> This is due to usage of default Combiner boost::last_value<R>. The problem occures when using non-void return values in signals. I use boost version 1.30.0 but I didn't noticed any changes for this in version 1.31.0. Quick workaround is to use other Combiner as default, where this problem is removed. for example <code> ... last_value .... T operator()(InputIterator first, InputIterator last) const { if (first == last) return T(); ... </code> best regards, Ville Varis ville.varis(a)bonum.biz mail.bonum.biz

2 1

[Boost-bugs] [ boost-Support Requests-965747 ] problem with debug builds on Solaris
by SourceForge.net 03 Jun '04

03 Jun '04

Support Requests item #965747, was opened at 2004-06-03 06:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=965747&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem with debug builds on Solaris Initial Comment: When I build an application with -g option (Solaris, Forte compiler), I get undefined symbol errors when it tries to link with Boost. I've tried rebuilding boost with -g, but get undefined sybols at link time from within boost - failing to find symbols in other parts of boost. Without -g option everything is fine Boost version 1.28.0 dlowry_uk(a)yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=965747&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

NEW lib: Named Variable - safe & convenient output of expressions together with their name
by M G 03 Jun '04

03 Jun '04

Greetings BOOST developers, the "Named Variable Lib" is a lightweight macro & template library which allows you to write: os << NV(character) << NV(std_string); os << NV(array_char_text) << NV(array_char_null); os << NV(p_float)<< NVP(p_float); p_float = 0; os << NVP(p_float); os << NV(the_answer_over_pi); os << NVB(((p_device==0) || f > 1.2) && name=="rsd0a"); to get e.g. character='A' std_string="test" array_char_text[]="text" array_char_null=NULL p_float=0012FD9C *p_float=1.234 p_float=NULL the_answer_over_pi=13.36901522 (((p_device_name==0) || f > 1.2) && name=="rsd0a")=1 written to the std::ostream os (" << std::endl" in C++ source omitted for better readability). Its main goal is to standardize the 5 macros NV,NVP,NVB,NVM,NVMP to let one output variable/expression together with their names conveniently (just one very short macro per expression) and safely (e.g. prevents os << "x1=" << x2;). Apart from that the NV concept could be used for other applications, where one needs a variable/expression and its name as a string. For more info & download of the library goto http://groups.yahoo.com/group/boost/files/Named%20Variable/ Feel free to try & comment ;-) Markus __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

weak_ptr doc problem
by Daniel Wallin 03 Jun '04

03 Jun '04

The weak_ptr docs says this: weak_ptr(); Effects: Constructs an **empty** weak_ptr. Postconditions: use_count() == 0. long use_count() const; Returns: if *this is **empty**, an unspecified nonnegative value; otherwise, the number of shared_ptr objects that share ownership with *this. use_count() seems underspecified and contradicts weak_ptr(). It should return exactly 0 when *this is empty. -- Daniel Wallin

2 1

RE: [boost] Proposed Boost Library for Data Series Analysis
by Tom Brinkman 03 Jun '04

03 Jun '04

Response to Matthew Hurd post: >> Efficiency is often paramount with these types of apps. Being able to do finite difference approaches, backwards and forwards, and in absolute terms is important (often you only want the latest data point). Agreed. >> You have the incremental case covered in your notes. Being able to calculate it at a point in an absolute sense, optional caching of results, working with series of unknown lengths and accuracy / validity enabling would be nice too. Agreed. >> By accuracy / validity enabling I mean, for say, your example of a 5 step moving average, it is not valid for the first four points as these are not an accurate average, so there is a length modification for the result. The value for the first four elements is invalid. The user has to adjust for this when they iterate over the returned vector. Example: (three day moving average) std::vector<double> out; std::transform(in.begin(), in.end(), std::back_inserter(out), moving_average(3)); out[0] = NA out[1] = NA out[2] = NA out[3] = NA std::transform(out.begin()+4, out.end(), std::cout << _1 << "\n"); >> Another simple example would be an exponential moving average where the number of significant digits required will determine how far back you need to go in the series. At another level, quality of service for some functors, the fast or accurate spectrum, is often appropriate. >> Perhaps expression templates might help here. Compile time results for validity calcs for series of known lengths would be helpful where possible. Agreed. Expression templates could be used very effecitively here. I will look into this. >> It would be nice if the algorithms could be simply specified, similar to your approach, and then "mounted" into the appropriate framework. Perhaps SFINAE or another technique could be used to determine an algorithm's capabilities. That is, the framework could juggle the most appropriate methods to use based on the results required. E.g. use incremental if you can otherwise absolute. >> Based on what I've done the past you also end up wanting arbitrary n-dimensional structures with other data types flowing through as well. Being able to associate ids/names with data items and keeping them associated through sorting/ranking. E.g. tag the series with data codes, rank them, and you can get the code for the best. You also want grouping n dimensional constructs and splitting dimensions and "slicing" operators that operate across the current dimension, which, with the appropriate framework, are one in the same. E.g. choose the minimum or sum the results of a bunch of functions. >> Then soon you want to split the computation amongst processors and machines and you want treat the computation as a dataflow graph and parallelise it some way, which I did a few years ago with BGL's precursor the GGCL. A topological sort gets you most of the way there... Also, you can then use things like Metis to partition your computation graph in nice ways. >> I think a way approach it would be an expression template approach with some adaptability in terms of absolute and incremental analytics with some accuracy (at least something like the number of points being chewed up and not valid or some such). Everything else could come on top of this. Sounds very powerful. Is there any additional web information to help me incorporate these ideas. >> You need to ensure that you can easily reuse code out there. No one wants to spend their life writing the zillions of numerical algorithms already out there. If you want a vector ARMA model, there are only a couple out there I think, and they are in FORTRAN, for example, wrap it, don't write it, I'd hope. Agreed. Thank you for your comments and spending the time to look at the library. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

Re: Boost Mathematicians
by Tom Brinkman 03 Jun '04

03 Jun '04

http://mathworld.wolfram.com/ Tens of thousands of visitors view MathWorld each day, and thousands of denizens of the mathematical and internet communities have contributed material over the last five years. As a result of this collaboration, MathWorld has grown to become the web's most extensive single source of educational and reference material about mathematics. If you havn't checked out this site you should take a quick look. I propose that we utilize the MathWorld community as the primary resource for ideas about our boost::math::algorithm library. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

static sized strings
by Martin 03 Jun '04

03 Jun '04

I have tested the sandbox version of the static sized strings. It works fine but there are a few inconveniences that I want to point out. 1. The abstract base class. --------------------------- Having an ABC to handle fixed strings of various lengths is a good idea but it is not very practical. I understand that the main purpose is to allow fixed strings to be passed to functions without using templates. int countwords(const boost::char_string & str); unfortunatly the ABC makes it difficult to pass anything but fixed strings. If you want to pass a string literal, a character array or a std::string you must create a temporary fixed_string<>. countwords(boost::fixed_string<20>("The quick brown fox")); Don't really have a good solution but maybe the base class could use an external buffer with constructors from char* and std::string. class char_string { const char* const extbuf; size_t len; protected: char_string() : extbuf(NULL) {} // not used since derived implements its own buffer public: char_string(const char* c) : extbuf(c), len(strlen(c)) {} char_string(const std::string& str) : extbuf(str.c_str()), len(str.length()) {} ... // virtual basic_string interface } Don't know how to handle non-const char[]. 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. 3. resize --------- Still missing a method to update the length to reflect the current string length. I think a resize without arguments would be a good solution. boost::fixed_string str<10> strtime(str.buffer()); str.resize(); 4. operator[] ------------------------- I don't have the standard basic_string interface available but I am pretty sure that operator[] doesn't throw an exception if the argument is outside max_size(). I also looked at the alternative fixed_string implemenatation but since that version doesn't have full std::string interface I didn't test it. I am not sure I like the lazy length calculation for two reasons. - In my view, strlen is normally a "cheap" operation comparable to a function call. If the lazy evaluation prevents a function from being inlined, the benefit is lost. - It is tricky to detect when the length is invalid. With the current implementation, I can't say if the length is valid or not after "str[4] = str [5]" since that depends on the order of evaluation of "str[4]" and "str[5]".

1 0

RE: [boost] Re: Re: Boost Mathematicians
by Hurd, Matthew 03 Jun '04

03 Jun '04

> Behalf Of Thorsten Ottosen > Sent: Thursday, 3 June 2004 4:25 PM > > > "Reid Sweatman" <drunkardswalk(a)earthlink.net> wrote in message > > | Oddly enough, scientists is usually pretty > | conservative folk; they like what they know. > > Is that so odd? Yesterday I talked with a matematician here in Sydney about > Fortran. > He uses Fortran because it is good enough for what he is doing. It would > probably take quite some > time for him to learn C++, so why should he? > > br > > Thorsten There is an often seen misconception that C/C++ should be as fast as it gets as the programming model is close to the instruction model of the machine. In practice FORTRAN is usually faster. At one level, in C++ this slowness this is usually because of temporaries and expression templates and modern optimizing compilers can often mitigate this for typical math calcs. Other abstraction penalties apply. Another level is the fundamental differences in aliasing between the language definitions. FORTRAN as a language does not allow aliasing ambiguities which makes the optimizers job a lot easier and the code can be a lot faster. C/C++ assumes aliasing potential which makes optimizing very hard. A C/C++ compiler may allow aliasing to be disabled for a section of code or for the whole program, but you need to be confident in what you are doing. Very clever global analysis is needed to cure the aliasing problem, and given the potential for run time gymnastics, it may not be possible at all. Have a look at these benchmarks judging Todd V's blitz to FORTRAN: http://www.oonumerics.org/blitz/benchmarks/ Boost's equivalent to Blitz++ is uBLAs. More discussion on C++ versus FORTRAN speed can be found here: http://osl.iu.edu/~tveldhui/papers/iscope97/ I do think it is worthwhile writing C++ to do this stuff as the abstraction is much better for the library client IMO. At some levels the implementation may be tougher for the library writer, as some of the optimizer gymnastics ends up in the expression templates, but given the right framework it may be simply extensible and suitable for even relatively unsophisticated mathematicians to contribute library components. You still need to wrap as you can't hope, nor should you try, to offer all algorithms from all languages. Another lobbed $0.005, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna Sydney _______________ 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.

2 1

[test] [minmax] failure on gcc 2.95
by Vladimir Prus 03 Jun '04

03 Jun '04

As shown in http://tinyurl.com/3xdyq, Boost.Test fails to build on gcc 2.95 with stlport. The error message is: /boost/head-regression/boost/boost/minmax.hpp: In function `const size_t & boost::std_min<size_t>(const size_t &, const size_t &)': /boost/head-regression/boost/libs/test/build/../src/test_tools.cpp:375: instantiated from here /boost/head-regression/boost/boost/minmax.hpp:26: `min' undeclared (first use this function) Is it possible that authors of either Boost.Test or boost/minmax.hpp take care of this error? Thanks, Volodya

1 0

Borland settings different between Boost and IDE ?
by Nicola Musatti 03 Jun '04

03 Jun '04

Hallo, is it possible that Boost libraries use a different setting for enum handling than the BCB IDE default one? I'm having problems which seem related to enums and the inclusion of some Boost headers in precompiled headers. Cheers, Nicola Musatti

2 2

[program_options] Darwin failure help?
by Vladimir Prus 03 Jun '04

03 Jun '04

The program options library now fails a single test on Darwin, with this output: ../libs/program_options/test/parsers_test.cpp(205): fatal error in "call_test_main": test p.options.size() == 1 failed *** 1 failure detected in test case "call_test_main" The code in question is: putenv("PO_TEST_FOO=1"); parsed_options p = parse_environment(desc, "PO_TEST_"); BOOST_REQUIRE(p.options.size() == 1); So, it seems that after "putenv", the string is is not available in the 'environ' variable. The variable is declared like this: #if defined(__APPLE__) && defined(__DYNAMIC__) #include <crt_externs.h> static char** environ = *_NSGetEnviron(); #else extern char** environ; #endif The Darwin-specific conditinal was sent by Michael LaSpina, so I don't know what it really does, and so don't know why the test fails. I'd appreciate any suggestions. Thanks in advance, Volodya

2 2

RE: [boost] Proposed Boost Library for Data Series Analysis
by Hurd, Matthew 02 Jun '04

02 Jun '04

> -----Original Message----- > Behalf Of Tom Brinkman > Subject: [boost] Proposed Boost Library for Data Series Analysis > > I placed a small tutorial and motivating example for > the proposed boost::data_series library. > > http://groups.yahoo.com/group/boost/files/data_series/ > > Working examples for you to criticize will be added > within the week. Cute code. Nice job. Efficiency is often paramount with these types of apps. Being able to do finite difference approaches, backwards and forwards, and in absolute terms is important (often you only want the latest data point). You have the incremental case covered in your notes. Being able to calculate it at a point in an absolute sense, optional caching of results, working with series of unknown lengths and accuracy / validity enabling would be nice too. By accuracy / validity enabling I mean, for say, your example of a 5 step moving average, it is not valid for the first four points as these are not an accurate average, so there is a length modification for the result. Another simple example would be an exponential moving average where the number of significant digits required will determine how far back you need to go in the series. At another level, quality of service for some functors, the fast or accurate spectrum, is often appropriate. Perhaps expression templates might help here. Compile time results for validity calcs for series of known lengths would be helpful where possible. It would be nice if the algorithms could be simply specified, similar to your approach, and then "mounted" into the appropriate framework. Perhaps SFINAE or another technique could be used to determine an algorithm's capabilities. That is, the framework could juggle the most appropriate methods to use based on the results required. E.g. use incremental if you can otherwise absolute. Based on what I've done the past you also end up wanting arbitrary n-dimensional structures with other data types flowing through as well. Being able to associate ids/names with data items and keeping them associated through sorting/ranking. E.g. tag the series with data codes, rank them, and you can get the code for the best. You also want grouping n dimensional constructs and splitting dimensions and "slicing" operators that operate across the current dimension, which, with the appropriate framework, are one in the same. E.g. choose the minimum or sum the results of a bunch of functions. Then soon you want to split the computation amongst processors and machines and you want treat the computation as a dataflow graph and parallelise it some way, which I did a few years ago with BGL's precursor the GGCL. A topological sort gets you most of the way there... Also, you can then use things like Metis to partition your computation graph in nice ways. I think a way approach it would be an expression template approach with some adaptability in terms of absolute and incremental analytics with some accuracy (at least something like the number of points being chewed up and not valid or some such). Everything else could come on top of this. You need to ensure that you can easily reuse code out there. No one wants to spend their life writing the zillions of numerical algorithms already out there. If you want a vector ARMA model, there are only a couple out there I think, and they are in FORTRAN, for example, wrap it, don't write it, I'd hope. You end up with run time versus compile time issues. People want to interact with this kind of stuff. However, my take on that now is do it at compile time and include the compiler as part of your interactive tools set if need be :-) Anyhow, it is nice to see a start on this. Good luck. $0.005, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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: Re: iostreams library review
by Robert Ramey 02 Jun '04

02 Jun '04

>> Question, have you tried to combine the streaming with boost >> serialization? > I think Robert Ramey has already done the work to combine serialization > with iostreams, since his archive types are constructible from arbitrary > streams -- that means it's already possible to create archives based on > streams from the iostreams library, e.g. memory-mapped file streams. > There may be other interactions I haven't considered. I've only read the > documentation; I haven't actually tried to use the serialization library > yet. The serialization library archives use streams and make no special assumptions regarding them. It works with all the streams I've happened to try. I will be taking a close look at the iostreams library proposal. In the course of implementing the serialization library I've had to become much more familiar with locales, facets, codecvt, element types, EOF, etc than I wanted to. Oh - and that fact that different versions of the standard library have myriad minor quirks that have to be considered. This was necessary in order to avoid dependence on the stream in the wrong way. I'm very interested in this but have come to the conclusion that there might be more here than meets the eye. - Of course that's why we have the review process. Robert Ramey

2 1

boost::optional - Include none.hpp instead of none_t.hpp?
by Schalk_Cronje＠NAI.com 02 Jun '04

02 Jun '04

Was it intentional to include none_t.hpp instead of none.hpp in boost/optional.hpp? Otherwise it seems that the user must resort to including boost/detail/none.hpp

3 3

thread, line endings
by Janusz Piwowarski 02 Jun '04

02 Jun '04

Hello In files: libs/thread/src/mutex.cpp libs/thread/src/recursive_mutex.cpp libs/thread/src/mutex.inl boost/thread/mutex.hpp boost/thread/recursive_mutex.hpp there is CR+CR+LF used as line separator. Also, in recursive_mutex constructor if defined(BOOST_HAS_WINTHREADS) m_critical_section should be initialized before m_count (it's compiler warning) Regards, Janusz

3 4

New utility at boost/detail/allocator.hpp
by Joaquín Mª López Muñoz 02 Jun '04

02 Jun '04

Hi all, As requested by some at the mailing list, I've migrated allocator.hpp from boost/multi_index/detail/ to boost/detail/ (with some obvious namespace changes.) I'd like to remark the following: * This allocator.hpp has nothing to do with a header of the same name who was sitting there and John Maddock kindly removed a few days ago. * The header provides some utilities to do rebinding of allocators even in MSVC++ 6.0 (where the std syntax for rebind does not work), and also exposes a tiny wrapper over defective std::allocators, providing some missing template members to make them std compliant. * I'd appreciate if those of you who were originally interested in using this header can do some sanity checks to make sure everything works for you (it does for Boost.MultiIndex). We have some room for improvements and fixes until Boost 1.32 is branched for release. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

RE: [boost] Re: Re: BOOST_READONLY_PROPERTY macro
by Rozental, Gennadiy 02 Jun '04

02 Jun '04

> Can you just please tell me what BOOST_READONLY_PROPERTY ( > bool, (epv) ) > will become once it is preprocessed ? Something like this: class readonly_property123 : public boost::unit_test::readonly_property<bool> { typedef boost::unit_test::readonly_property<bool> base; friend class epv; // <-- here BOOST_PP is used typedef base::write_param_t write_param_t; public: readonly_property123() {} explicit readonly_property123( write_param_t init_v ) : base( init_v ) {} } > > P.S. Paul should know the answer > I don't think Paul knows about _all_ libraries that _use_ the > PP library. This has something to do with specific compiler bug in regards of PP.

1 0

Test failure for basic_cstring_test
by Martin Wille 02 Jun '04

02 Jun '04

Hello, basic_cstring_test fails on gcc-3.2.3 in a way that causes the test post processing to fail, too. The basic_cstring_test related lines from the log file are appended to this message. The full log for gcc-3.2.3-linux can be found at http://tinyurl.com/34ltq Regression log post processing fails with this message: **** exception(205): std::exception: boost::filesystem::path: invalid name "basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):.." in path: "bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):../libs/test/test" ******** errors detected; see standard output for details ******** Regards, m gcc-C++-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o /boost/head-regression/boost/boost/test/test_tools.hpp: In function `bool boost::test_tools::detail::equal_and_continue_impl(const Left&, const Right&, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const char>, unsigned int, boost::unit_test::log_level, unsigned int) [with Left = size_t, Right = int]': ../libs/test/test/basic_cstring_test.cpp:82: instantiated from `void constructors_test(CharT*) [with CharT = wchar_t]' ../libs/test/test/basic_cstring_test.cpp:124: instantiated from `static void meta_constructors_test::execute(T*) [with T = wchar_t]' /boost/head-regression/boost/boost/test/test_case_template.hpp:60: instantiated from `void boost::unit_test::detail::test_case_template_instance<TestCaseTemplate, TestType>::do_run() [with TestCaseTemplate = meta_constructors_test, TestType = wchar_t]' /boost/head-regression/boost/boost/utility/value_init.hpp:49: instantiated from here /boost/head-regression/boost/boost/test/test_tools.hpp:430: warning: comparison between signed and unsigned integer expressions gcc-Link-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x657): In function `void find_test<char const>(char const*)': ../libs/test/test/basic_cstring_test.cpp:470: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):../libs/test/test/basic_cstring_test.cpp:368: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x8ac):../libs/test/test/basic_cstring_test.cpp:432: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0xa1a):../libs/test/test/basic_cstring_test.cpp:433: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0xb93):../libs/test/test/basic_cstring_test.cpp:480: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z16data_access_testIhEvPT_+0xb8): In function `void data_access_test<unsigned char>(unsigned char*)': /boost/head-regression/boost/boost/test/detail/basic_cstring/basic_cstring.hpp:539: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z16data_access_testIhEvPT_+0x1e7): In function `void data_access_test<unsigned char>(unsigned char*)': /boost/head-regression/boost/boost/test/test_tools.hpp:446: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z14asignment_testIhEvPT_+0xea):/usr/local/gcc-3.2.3/include/c++/3.2.3/bits/basic_string.tcc:155: more undefined references to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' follow ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0x757): In function `void find_test<char const>(char const*)': ../libs/test/test/basic_cstring_test.cpp:368: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0x8ac):../libs/test/test/basic_cstring_test.cpp:432: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0xa1a):../libs/test/test/basic_cstring_test.cpp:433: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0xb93):../libs/test/test/basic_cstring_test.cpp:480: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z23constructors_const_testIKhEvPT_+0x114): In function `void constructors_const_test<unsigned char const>(unsigned char const*)': ../libs/test/test/basic_cstring_test.cpp:195: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z20asignment_const_testIKhEvPT_+0x11f): In function `void asignment_const_test<unsigned char const>(unsigned char const*)': /usr/local/gcc-3.2.3/include/c++/3.2.3/bits/basic_string.tcc:160: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z20asignment_const_testIKhEvPT_+0x258):../libs/test/test/basic_cstring_test.cpp:353: more undefined references to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' follow ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhEC1EPh+0x37): In function `boost::unit_test::basic_cstring<unsigned char>::basic_cstring[in-charge](unsigned char*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:150: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testltIhEEbRKNS0_13basic_cstringIT_EES6_+0x7c): In function `bool boost::unit_test::operator< <unsigned char>(boost::unit_test::basic_cstring<unsigned char> const&, boost::unit_test::basic_cstring<unsigned char> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/compare.hpp:51: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIhE4findES2_+0xab): In function `boost::unit_test::basic_cstring<unsigned char>::find(boost::unit_test::basic_cstring<unsigned char>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhE10trim_rightES2_+0x8d): In function `boost::unit_test::basic_cstring<unsigned char>::trim_right(boost::unit_test::basic_cstring<unsigned char>)': ../libs/test/test/basic_cstring_test.cpp:260: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhE9trim_leftES2_+0x8b): In function `boost::unit_test::basic_cstring<unsigned char>::trim_left(boost::unit_test::basic_cstring<unsigned char>)': /boost/head-regression/boost/boost/detail/shared_count.hpp:345: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIhE5rfindES2_+0xab): In function `boost::unit_test::basic_cstring<unsigned char>::rfind(boost::unit_test::basic_cstring<unsigned char>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhEC1EPS2_+0x37): In function `boost::unit_test::basic_cstring<unsigned char const>::basic_cstring[in-charge](unsigned char const*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:150: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEEC1EPKhRKS1_+0x13): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::basic_string[in-charge](unsigned char const*, std::allocator<unsigned char> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/basic_cstring.hpp:531: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testltIKhEEbRKNS0_13basic_cstringIT_EES7_+0x7c): In function `bool boost::unit_test::operator< <unsigned char const>(boost::unit_test::basic_cstring<unsigned char const> const&, boost::unit_test::basic_cstring<unsigned char const> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/compare.hpp:51: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIKhE4findES3_+0xab): In function `boost::unit_test::basic_cstring<unsigned char const>::find(boost::unit_test::basic_cstring<unsigned char const>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhE10trim_rightES3_+0x8d): In function `boost::unit_test::basic_cstring<unsigned char const>::trim_right(boost::unit_test::basic_cstring<unsigned char const>)': ../libs/test/test/basic_cstring_test.cpp:260: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhE9trim_leftES3_+0x8b): In function `boost::unit_test::basic_cstring<unsigned char const>::trim_left(boost::unit_test::basic_cstring<unsigned char const>)': /boost/head-regression/boost/boost/detail/shared_count.hpp:345: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIKhE5rfindES3_+0xab): In function `boost::unit_test::basic_cstring<unsigned char const>::rfind(boost::unit_test::basic_cstring<unsigned char const>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testeqIhhEEbRKNS0_13basic_cstringIT_EERKNS2_IT0_EE+0x5c): In function `bool boost::unit_test::operator==<unsigned char, unsigned char>(boost::unit_test::basic_cstring<unsigned char> const&, boost::unit_test::basic_cstring<unsigned char> const&)': /boost/head-regression/boost/boost/test/test_tools.hpp:434: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNKSbIhSt11char_traitsIhESaIhEE5c_strEv+0x2e): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::c_str() const': /usr/local/gcc-3.2.3/include/c++/3.2.3/bits/stl_algobase.h:240: undefined reference to `std::char_traits<unsigned char>::assign(unsigned char&, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testeqIKhS2_EEbRKNS0_13basic_cstringIT_EERKNS3_IT0_EE+0x5c): In function `bool boost::unit_test::operator==<unsigned char const, unsigned char const>(boost::unit_test::basic_cstring<unsigned char const> const&, boost::unit_test::basic_cstring<unsigned char const> const&)': /boost/head-regression/boost/boost/test/test_tools.hpp:434: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEE13_S_copy_charsEPhPKhS5_+0x20): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::_S_copy_chars(unsigned char*, unsigned char const*, unsigned char const*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:100: undefined reference to `std::char_traits<unsigned char>::copy(unsigned char*, unsigned char const*, unsigned)' collect2: ld returned 1 exit status set -e LD_LIBRARY_PATH=/usr/local/gcc-3.2.3/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH "/usr/local/gcc-3.2.3/bin/g++wrap" --limit-memory=600 --limit-cpu=1800 -g -o "../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test" -L"../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug" -L"/usr/local/gcc-3.2.3/lib" "../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug/libboost_unit_test_framework.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug/libboost_unit_test_framework.a" -Wl,-rpath-link,. ...failed gcc-Link-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test... ...skipped <@boost!libs!test!test/basic_cstring_test.test/gcc-3.2.3-linux/debug>basic_cstring_test.run for lack of <@boost!libs!test!test/basic_cstring_test.test/gcc-3.2.3-linux/debug>basic_cstring_test...

4 6

port of library to vacpp (item 2)
by Toon Knapen 02 Jun '04

02 Jun '04

I stumble on another problem when trying to compile the test library with IBM/VisualAge (vacpp). Apparantly vacpp has a problem on lines 97,98 and 99 of boost/test/detail/basic_cstring/basic_cstring.hpp. Basically the problem is this: this file declares a class template < class CharT > class basic_string { public: typedef basic_string<CharT> self_type ; self_type& trim_left(self_type exclusions = self_type() ) ; // line 97 } ; If I now remove the default initializer, vacpp does not choke anymore (same situation on lines 98 and 99). I tried to isolate this problem in small test but in a small test vacpp seems to deal with the situation just fine. Thus AFAICT this is a compiler-bug but would anyone mind if I remove the default initializers or just remove them in the vacpp compilation to get one step closer to running the regression tests on vacpp again.

5 8

Proposed Boost Library for Data Series Analysis
by Tom Brinkman 02 Jun '04

02 Jun '04

I placed a small tutorial and motivating example for the proposed boost::data_series library. http://groups.yahoo.com/group/boost/files/data_series/ Working examples for you to criticize will be added within the week. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

RE: [boost] Re: BOOST_READONLY_PROPERTY macro
by Rozental, Gennadiy 02 Jun '04

02 Jun '04

> > BOOST_CLASS_PROPERTY is used like this: > > > > BOOST_CLASS_PROPERTY( int, (class1)(class2)...(classN) ) property; > > How is that relevant? Sorry supposed to be BOOST_READONLY_PROPERTY in both places. Gennadiy.

3 3

RE: [boost] Re: iostreams library review
by Brian Braatz 02 Jun '04

02 Jun '04

"""""""" > what is the fate of this library? Thanks for your interest! The previous version available at http://www.xmission.com/~turkanis/iostreams/. """""""""" 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. """""""""" A quick look your page is very interesting. (looks very cool) I was thinking (also) along the same lines for some work I am currently doing, but you beat me to it. Question, have you tried to combine the streaming with boost serialization?

2 1

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

01 Jun '04

Rob Stewart wrote: >Subject: Re: [boost] Re: static sized strings >Date: Tue, 1 Jun 2004 17:13:38 -0400 (EDT) > >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > John Nagle wrote: > > > I've done some cleanup on my version of fixed_string at > > > http://www.animats.com/source > > >[snip] > > > We're approaching convergence on this. > > > > We are both working on variations of the same idea. As such, I have >fixed > > several errors in my code making it operate better as a basic_string > > interface and have seperated the safe_string.hpp file into the >appropriate > > headers (fsstring.hpp for string.h, fsstdio.hpp for stdio.h and >fswchar.hpp > > for wchar.h). I have also posted BoostBook format documentation to the >libs > > section. > > > > However, we are still no closer to deciding which implementation to >choose. > > We can either: > > [1] Choose one implementation and drop the other (possibly collaborate); > > [2] Continue both and put them against each other to see which is >better; > > [3] Drop both and develop one together from scratch. > > > > Option [3] is not viable, since a lot of the hard work has already been >done > > (size issues, etc.). I would like the implementation we use to be mine >and > > I'm sure John feels the same way about his. I am also getting to the >stage > > where I am considering putting mine up for review (once I get the tests > > written). > >John hasn't fleshed out his design quite as completely as you >have yours, but he's close. John just raised a new point: >accessing the N + 1'st element. That may not have been apparent >had he not been working on his own version -- or have you already >dealt with that? -- so both implementations remain useful. My s[ i ] throws if i > capacity() which shouldn't cause a problem. s.at( i ) throws if i > length(). >I laid out a plan previously for how to judge between the >implementations. I suggest waiting to have either reviewed until >you can both run your code through the same tests -- with and >without errors -- to see if there is a clear winner. Sure. I have been writing tests for my library (boost-sandbox/fixed_string/test/*.cpp) with a BBv2 file to do the testing. I have the C-style functions test cases posted and have made a start with the basic_string cases [21.3.1-4]. There still need to be tests for when the operations will cause buffer overflow on unprotected code, and generate exceptions for functions like s.at( i ), but I am waiting until I have written the basic test cases. The tests currently use my naming conventions, but I am sure they can be adapted for John's versions as well for comparisons. I could also implement bench marcking tests for performance analysis. >Another possible means to judge between the two is to find >real-world C code using strings, that compiles with a C++ >compiler. Then, each library author can translate the code >according to the needs of the libraries. Diffs will reveal the >extent of the changes needed, and copious notes could illustrate >common mistakes made and error messages encountered during the >translation. That information can clarify which design makes the >translation of C string code into fixed_string code easiest >(performance will have already been ascertained, so needn't be >reassessed). That would be a good idea. >If that doesn't reveal a clear winner, I've a suggestion for >breaking the tie: I can pass the options through a coworker of >mine. He was a C programmer for a very long time and has been >writing C++ code for less time. He still thinks like a C >programmer in a lot of ways, so he might have insights we're >missing. Also a good idea. Regards, Reece _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

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

01 Jun '04

John Nagle wrote: > I've done some cleanup on my version of fixed_string at > http://www.animats.com/source >[snip] > We're approaching convergence on this. We are both working on variations of the same idea. As such, I have fixed several errors in my code making it operate better as a basic_string interface and have seperated the safe_string.hpp file into the appropriate headers (fsstring.hpp for string.h, fsstdio.hpp for stdio.h and fswchar.hpp for wchar.h). I have also posted BoostBook format documentation to the libs section. However, we are still no closer to deciding which implementation to choose. We can either: [1] Choose one implementation and drop the other (possibly collaborate); [2] Continue both and put them against each other to see which is better; [3] Drop both and develop one together from scratch. Option [3] is not viable, since a lot of the hard work has already been done (size issues, etc.). I would like the implementation we use to be mine and I'm sure John feels the same way about his. I am also getting to the stage where I am considering putting mine up for review (once I get the tests written). What do other people think? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: [boost] Re: [prereview request][fsm]
by eegg＠comcast.net 01 Jun '04

01 Jun '04

--- Rob Stewart <stewart(a)sig.com> wrote: > From: "E. Gladyshev" <eegg(a)comcast.net> > > From: "Rob Stewart" <stewart(a)sig.com> > > > From: "E. Gladyshev" <eegg(a)comcast.net> > > > > From: "Rob Stewart" <stewart(a)sig.com> > > [...] > > 1. Some platforms pose non-C++ exceptions as normal C++ exception. > > You don't always want those platfrom specific exceptions trigger > > a whole bunch of stuff in your program. > > The only platform I know of that does that is Windows/MSVC It makes it pretty common, doesn't it. :) > you can handle structured exceptions specially. Perhaps it > means that boost::fsm needs to provide a means to install an > exception handler for those exceptions not already recognized by > the library: > > try { throw; } > catch (...) { boost::fsm::detail::handle_exception(); } > > void boost::fsm::detail::handle_exception() > { > try { throw; } > catch (type1 const &) { ... }; > catch (type2 const &) { ... }; > catch (type3 const &) { ... }; > catch (...) { user_handler(); } > } > where user_handler is a pointer to function that's initialized to > std::unexpected() and can be overridden by the library user. Adding user_handler() doesn't stop stack unwinding. I think you are missing the point. The issue is not in how to process SEH exceptions (or any other unhandled exception) the issue is in how not to trigger stack unwinding (for all exceptions) and still be able discriminate user exception types generically in FSM. Your solution doesn't solve this problem. > > It may also be that SEH can be configured to intervene before a > C++ exception is generated by the RTL so those never become C++ > exceptions that can muck up the works. It is not trivial... but it is out of the FSM topic. > > 2. Your design assumes that all possible exceptions are known > > and you handle them. So any unhandled exception is a bug. > > Not quite. What I was showing would rethrow any unknown > exception, leaving to clients to determine how to handle it. > > > It is not safe to trigger stack unwinding in a buggy environment. > > If you say so. Every application and platform with which I work > is buggy and yet I manage to use exceptions and stack unwinding > works. What do you mean by "stack unwinding works". Do you mean that even if the exception is caused by a bug, stack unwinding didn't make things worse or less safer? Well, it's a long shot... [...] > This is just another case of things not being as pretty > as one might like but that doesn't mean stack unwinding is > faulty. Sorry, who said that stack unwinding is faulty? Eugene

5 8

Re: [boost] [Serialization] Errors when compiling using GCC 3.4
by Robert Ramey 01 Jun '04

01 Jun '04

Allen Yao wrote: > I just updated my gcc from 3.3.3 to 3.4, and found that the > serialization17 and serialization18 cannot compile. There are many error > messages, some of them seem to caused by lack of "typename", others are > very strange, for example, about using boost::noncopyable. > Does someone try serialization library on GCC 3.4? Can it be compiled? > I suspect I am missing something. Otherwise, I would like to try to "fix" > the "bugs" myself. Hmmm, I just checked. I'm currently using gcc 3.3.1 ? Should I upgrade to gcc 3.4.? I seem to recall information on the list that suggested it would be better to wait a little bit. If upgrading is a good thing - now is a good time for me to do it as I'm just finalizing all the changes for next version and just starting the "torture test torture" procedure of reconciliation of compiler quirks. Robert Ramey

4 5

BOOST_READONLY_PROPERTY macro
by Toon Knapen 01 Jun '04

01 Jun '04

This is the next item in the continuing sage about porting the test-library to IBM/VisualAge. The use of the BOOST_READONLY_PROPERTY macro results in error messages (see attached file) when compiling the test library with vacpp. I tried to have a look at this macro but it is not documented anywhere (neither in the source files where the macro is defined) and thus I would appreciate help from someone more knowledgeable about the test and preprocessor library. Additionally I would like to remark again that the test tools should not have too many dependencies. If the test tools depend on almost all boost libraries, there's no use in having test tools that verify if all libraries compile, is there ? toon ...found 838 targets... ...updating 273 targets... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_tools.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_tools.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_tools.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_log.o xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_monitor.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_monitor.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_monitor.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_result.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_result.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_result.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_suite.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_suite.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_suite.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/supplied_log_formatters.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/supplied_log_formatters.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/supplied_log_formatters.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_main.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_main.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_main.o... ...skipped <@boost!libs!test!build/libboost_test_exec_monitor.so/vacpp/debug>libboost_test_exec_monitor-xlc-d-1_31.so for lack of <@boost!libs!test!build/libboost_test_exec_monitor.so/vacpp/debug>test_tools.o... ...skipped <@boost!libs!test!build!stage!lib>libboost_test_exec_monitor-xlc-d-1_31.so for lack of <@boost!libs!test!build/libboost_test_exec_monitor.so/vacpp/debug>libboost_test_exec_monitor-xlc-d-1_31.so... MkDir1 /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/execution_monitor.o xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/test_tools.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -O3 -qstrict -qinline -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/test_tools.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/test_tools.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/unit_test_parameters.o

3 2

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

01 Jun '04

Sorry if this is a repost - I am almost sure my last post did not reached out. Rob Stewart wrote: > meaning "arbitrary value." However, "indeterminate" leaves no > doubt as to the meaning of the value and doesn't depend upon > one's experience with electronics. Another possibility would be I agree. Although I see the highest potential of the library in EDA applications, the meaning of the value should not depend on any problem domain - like electronics. I guess I was little bit biased here by my problem domain. > As I've already rejected the "x" notion, that leaves > "unknown_bool" or, by extension, "indeterminate_bool." While > these names suggest that there is an unknown or indeterminate > Boolean value, they don't suggest to me a type that includes > true, false, *and* unknown/indeterminate. "tribool," OTOH, I disagree. IMHO, The name unknown_bool hints that in addition to the 2 traditional values of bool, there is also an unknown bool. I am not a native user of the English language, but this is what the name unknown_bool hints *me*. Haim -- _____________________________________________________ Haim Cohen Software Engineer haim.cohen(a)analog.com / haimcohen2002(a)hotmail.com Analog Devices

1 0

[Formal review request] policy_ptr
by David B. Held 01 Jun '04

01 Jun '04

I am formally requesting that policy_ptr be added to the review queue. The version to be reviewed is different from the version currently in the sandbox, but will be available long before the current queue is exhausted. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004

3 3

Boost Software License & GPL
by Alex Vinokur 01 Jun '04

01 Jun '04

<QUOTE from http://www.boost.org/more/lib_guide.htm#License> License requirements The preferred way to meet the license requirements is to use the Boost Software License. See license information. If for any reason you do not intend to use the Boost Software License, please discuss the issues on the Boost developers mailing list first. </QUOTE> I am thinking of submission some software to Boost. However I put this software in several sites under GPL. Boost requires Boost Software License. How to solve this problem? -- Alex Vinokur mailto:alexvn@connect.to http://mathforum.org/library/view/10978.html

3 3