- Boost - lists.boost.org

Metrowerks 9.2 approaching 100% on Windows
by Beman Dawes 06 Mar '04

06 Mar '04

The Win32 regression test results now reflect the new Metrowerks 9.2 release. See http://boost.sourceforge.net/regression-logs/ Fails have been reduced to just two: graph adj_list_cc: That's a regression compared to 8.3 and the 9.2 beta that we need to look into. I've emailed Jeremy. type traits is_abstract_test: This is a new test, so it was not tested during the 9.2 beta. I'd appreciate it if the type traits folks would take a look to see if this is a Boost or Metrowerks problem. Anyhow, congratulations to Metrowerks, particularly Howard Hinnant, Andreas Hommel, and Ed Swartz. They put in a lot of effort checking out Boost regression test failures. --Beman

3 3

string algorithms check-in
by Pavol Droba 06 Mar '04

06 Mar '04

Hi All, I have just checked into main the cvs the string algorithm library. Feel free to try it out:) Few comments: - Most of the changes requested during the review are there, except for the documentation issues. Reference should be in sync, since it is doxygen-generated, but it will need some updating too. - The library resides in the directory algorithm/string (i.e. boost/algorithm/string and libs/algorithm/string) - Cummulative includes are located in boost/algorithm/string.hpp and string_regex.hpp - All functions/classes/types are in the namespace boost::algorithm (+ ...::algorithm::detail) - Public interface entities are pulled to the boost namespace via "using directive" - I might have spoiled something during commit, so if you have any problems, let me know ;-/ My questions: - How can I make the library to be part of automatic regression tests? - How can I make the library documentation to be automaticaly generated and accessible from the main docs page? Regards, Pavol

3 4

[boost]Re: Re: [serialization] non-conformance in collection_load_imp.hpp
by Robert Ramey 06 Mar '04

06 Mar '04

Tom Widmer wrote: >On Fri, 5 Mar 2004 07:59:31 -0800, "Robert Ramey" <ramey(a)rrsd.com> >wrote: >>Joaqu?n M? L?pez Mu?oz wrote: >> >>>"serialization/collections_load_imp.hpp" defines a private template >>>class stack_allocate for stack-based reservation of uninitialized >>>memory. To the best of my knowledge, the way it does so is not >>>std-conformant due to alignment issues. >>>Fortunately, (undocumented) "boost/aligned_storage.hpp" provides a >>>template class named aligned_storage which handles the issue, so I >>>guess the problem can be solved by just using this facility instead of >>>stack_allocate. >> >>This has been mentioned before. I was unable to find any information >>other than the code itself which wasn't all that transparent to me. >>And the stack allocate was soooooo simple. Is aligned_storage part of >>boost? Is it documented anywhere? Is it part of any test suite? Has >>it been tested for portability? In general I would prefer a boostified >>component over a homebrew one. I'm really not sure of what the status of >aligned_storage is. >>Also, the nameitself didn't make it clear to me that its intended >>purpose was identical to that implemented by stack_allocate. >It's a fully documented part of Boost type_traits, assuming you are just >after a POD type with a certain alignment: >::boost::alignment_of<T>::value >Identifies the alignment requirements of T. Actually returns a value that >is only guaranteed to be a multiple of the actual alignment requirements of >T. >T must be a complete type. >::boost::type_with_alignment<Align>::type >Attempts to find a built-in or POD type with an alignment that is a >multiple of Align. Neither of the above functions is the on in question. We're talking about aligned_storage here. This exchange illustrates the problem rather nicely. Its not clear to me from the name "aligned_storage" that its meant to do the same job as "stack_allocate" and in fact is easily confused with other boost functions. I've been able to find no documentation nor test nor other information. The only place its used is in variant.hpp but its not mentioned in the documentation of that either. There is no statement in the header itself as to what it does and the code is sufficiently non-trivial that it's not obvious what its supposed to do. The fact that it has a parameter than stack_allocate doesn't need also suggests that it's intended purpose is different from that of stack_allocate. Given all the above, I would be reluctant to replace the 10 transparently correct lines of stack_allocate by inclusion of 138 lines of aligned_storage. Now it's quite possible that stack_allocate is incorrect, non-portable, or in some other way undesirable such that it should be replaced with something else. If this is the case, I would very much like hear about it. Robert Ramey

2 1

Re:[boost] Serialization17 - assert in basic_text_oarchive.hpp
by Robert Ramey 06 Mar '04

06 Mar '04

Jeff Flinn wrote: >My app is hitting the assertion at line 133 in basic_text_oarchive.hpp with >delimiter = 3 when serializing to a text_oarchive. Whoops - I spoke way too soon. Clearly this is something new, I'll look into it. >The assertion occurs during serialization of the count for a shared_ptr. >There is an access violation when attempting to serialize to a >binary_oarchive also. The same assertion or a different one. This sounds like the pointer registration/export issue I alluded to earlier. >XML serialization in both directions works fine. The odd thing is, if I >comment out any usage of xml_oarchive, the assertion is not triggered, and >serialization to both text_oarchive and binary_oarchive succeeds. Odd indeed. Investigate some more. Again, which assertion? >Input from binary/text/xml succeeds in all cases. If it fails to create archive, how do we know input succeeds? Robert Ramey

2 2

Serialization17 - assert in basic_text_oarchive.hpp
by Robert Ramey 05 Mar '04

05 Mar '04

Jeff Flinn wrote: >My app is hitting the assertion at line 133 in basic_text_oarchive.hpp with >delimiter = 3 when serializing to a text_oarchive. The assertion occurs >during serialization of the count for a shared_ptr. There is an access >violation when attempting to serialize to a binary_oarchive also. XML >serialization in both directions works fine. The odd thing is, if I comment >out any usage of xml_oarchive, the assertion is not triggered, and >serialization to both text_oarchive and binary_oarchive succeeds. Input >from binary/text/xml succeeds in all cases. This has been reported recently and addressed in the next version. In the case I know about it occurred with an instance of a derived class serialized though a polymorphic base class pointer which was previously neither "registered" or "exported". This has been addressed by throwing of an exception at an earlier point. This also occurred when using serialization of a derived polymorphic shared pointer though its base class. This sounds like your case. An updated copy of test_shared_ptr shows how this can be addressed. (I'll send you the latest copy) It turns out that my implementation of serialization of shared pointer isn't quite there. It needs a more elegant way to automatically register/export shared_count<P, D> when P is the derived class and we're serializing through a base class pointer. I havn't thought about this because: a) I'm really reluctant to get involved with shared_ptr b) I think other issues will also come up - e.g. exception safety while serialization of shared pointer c) locking during multi-threading d) ? Robert Ramey

1 0

Comment regarding __GNUC__ spoofing
by Beman Dawes 05 Mar '04

05 Mar '04

In discussions with the Intel folks about their spoofing of __GNUC__ on Linux, Clark Nelson pointed out that Boost code should be much more careful about use of any predefined compiler identification macro, because there is nothing to prevent any compiler in the future predefining compiler identification macros used by other compilers. Scary as it is, he is right AFAICS. There are two cases I can see for checking a compiler identification macro: * The code wishes to see if it is safe to use an extension feature such as a pragma or compiler intrinsic provided by the compiler indicated by the macro. This is reasonably safe in that presumably the reason the actual compiler is pretending to be a different compiler is to indicate feature compatibility with the spoofed compiler. * The code wishes to apply a workaround for a bug in the spoofed compiler. This usage is fraught with possible problems. The actual compiler may or may not have the same bug. If not, useful functionality may be needlessly disabled or the workaround may not even work. We deal with _MSC_VER in various compilers by defining BOOST_MSVC if it is actually the Microsoft compiler. We deal with __GNUC__ inconsistently by defining BOOST_INTEL rather than BOOST_GCC. To be consistent and to prevent being blindsided in the future by other compilers deciding to spoof one another's macros, perhaps we should define BOOST_x, where x is the compiler name, for every compiler we have a config for. And then pointing out the problem in our lib guide for developers. --Beman

6 7

Re:[boost] [serialization] non-conformance in collection_load_imp.hpp
by Robert Ramey 05 Mar '04

05 Mar '04

Joaqu?n M? L?pez Mu?oz wrote: >"serialization/collections_load_imp.hpp" defines a private template >class stack_allocate for stack-based reservation of uninitialized >memory. To the best of my knowledge, the way it does so >is not std-conformant due to alignment issues. >Fortunately, (undocumented) "boost/aligned_storage.hpp" provides >a template class named aligned_storage which handles the issue, >so I guess the problem can be solved by just using this >facility instead of stack_allocate. This has been mentioned before. I was unable to find any information other than the code itself which wasn't all that transparent to me. And the stack allocate was soooooo simple. Is aligned_storage part of boost? Is it documented anywhere? Is it part of any test suite? Has it been tested for portability? In general I would prefer a boostified component over a homebrew one. I'm really not sure of what the status of aligned_storage is. Also, the nameitself didn't make it clear to me that its intended purpose was identical to that implemented by stack_allocate. Robert Ramey

2 1

boost isnan/isinf/etc...?
by Matthias Schabel 05 Mar '04

05 Mar '04

For numeric code these functions are indispensible but, since they're C99, they are technically C++ verboten. It seems to me that it would be worthwhile to add them to boost::math - they could probably just be cut-n-pasted from the C99 gcc headers... Matthias ------------------------------------------------------------------------ --------------------------- Matthias Schabel, Ph.D. Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) mschabel at ucair med utah edu

3 2

Re: GUI library - another one
by Robert Ramey 05 Mar '04

05 Mar '04

I believe similar discussions were engaged some time ago and that these discussions resulted in: http://sourceforge.net/projects/notus/ What to the participants in these other discussions have to add? Robert Ramey

5 6

Re: whither the order language
by hartmutkaiser＠t-online.de 05 Mar '04

05 Mar '04

Vesa Karvonen wrote: > Ronald Garcia wrote: > >Where can I find a copy of the Order preprocessor language? The Boost > >files section seems to have examples of its use, as well as a manual, > >but I don't seem to see the implementation. > > I removed the Order interpreter implementation from the files section some > time ago, because it had changed significantly due to the discovery of a > couple of techniques for removing certain practical limitations. The > documentation and examples mostly reflect the current Order interpreter, > but as I have not been working on the implementation for some time, the > interpreter is not ready for publication. If you are really interested, > then I could e-mail you a snapshot of the interpreter. > > The current Order interpreter also uses C99 preprocessor features, namely > variadics and placemarkers, so it is not immediately useful for C++ > programming. The latest GNU CPP and the Wave library are known to be able > to preprocess the Order interpreter. Other preprocessors have not been > tested, but it should be possible to port the interpreter to most (more or > less buggy) preprocessors that support the C99 extensions. Yes, I'm interested in getting the latest version of your Order library, since I'm still using it as one of my test cases for Wave. Could you please send it to me? Regards Hartmut

1 0