- Boost - lists.boost.org

Re: [boost] Re: [indexed_set] volunteers wanted for testing
by JOAQUIN LOPEZ MU?Z 08 Mar '04

08 Mar '04

----- Mensaje original ----- De: Giovanni Bajo <giovannibajo(a)libero.it> Fecha: Viernes, Marzo 5, 2004 4:30 pm Asunto: [boost] Re: [indexed_set] volunteers wanted for testing > Testing on GCC 3.4 uncovers an issue. > > ../../../boost/indexed_set/index.hpp:155: error: there are no > arguments to > `final' that depend on a template parameter, so a declaration of > `final' must > be available > This happens also on all the similar lines in the same class: 161, > 177, 178, > 179. All final* members seem to be inherited from a dependent > base, so they > need to be qualified with "this->" in front of them. The same also > happens in > index_set.hpp, line 133, 459. sequenced_index.hpp: 134, 157, 175, > 176, 177, > 576, 580. > I think there are more occurrence of this but maybe they are not > excercised by > the testes. You're very right. I'll add the missing this->'s. Thanx for the tip. > > test_list_ops.cpp generates an ICE which I already submitted for > analysys. Is there a link in the GCC database that I can track? > All the other tests compile and run succesfully (after the above > fixes).-- > Giovanni Bajo > OK, thank you again. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

GUI library - another one
by David Turner 07 Mar '04

07 Mar '04

Hello It seems that the idea of adding a medium-complexity GUI library to boost is popular, but that there are widely varying opinions on how it should be done. I've written a first draft of a library that fulfils most of my expectations. It's available at http://www.turn.co.za/david/gui. It supports two platforms (Win32 and GTK2), and four user interface elements or widgets (window, label, button, text-entry). The design is such that it is extremely easy to support new platforms or widgets. These are my expectations of how a good C++ GUI library should behave: 1. It should be a consistent yet thin wrapper around the platform's native functionality. 2. It should degrade gracefully in the absence of certain features on the platform. 3. It should be extensible through the factory pattern. 4. It should couple loosely with user code - this means no inheriting from an abstract Window class. 5. It should do what the user (programmer) expects, whenever possible (i.e. no leaky metaphors). 6. Widgets that contain things should behave like containers, whenever this is practical. 7. It should not use device-specific units like pixels, wherever this is practical. and finally 8. It should be extremely easy to use. The library at the link above fulfils most of these requirements. But it's not perfect. There are some interesting design choices. In many respects the most difficult design work is still to be done (list boxes, menus, drawing areas). However, the code that exists has the great advantage of working. I'd like to know what the boost community thinks before proceeding. Regards David Turner

25 103

Boost+python building - Only 1 error to resolve...
by jeuxal_com 07 Mar '04

07 Mar '04

For win2000,msvc (vc6) Got the error (either python22 release or 2.4current source): vc-C++ bin\boost\libs\python\build\boost_python.dll\msvc\debug\inheritance.obj inheritance.cpp C:\Lib\boost_1_31_0\boost/graph/detail/adjacency_list.hpp(1055) : error C2244: 'bidirectional_graph_ move_edge' : unable to resolve function overload C:\Lib\boost_1_31_0\boost/graph/detail/adjacency_list.hpp(1057) : error C2954: template definitions C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2039: 'dm' : is not a member of '_mfi' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2143: syntax error : missing ';' before '<' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2501: 'dm' : missing storage-class or type specif C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : ';' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : '<' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2653: 'T' : is not a class or namespace name C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2645: no qualified name for pointer to member (fo C:\Lib\boost_1_31_0\boost/mem_fn.hpp(320) : error C2143: syntax error : missing ';' before '}' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(320) : fatal error C1506: unrecoverable block scoping error Any idea? Thanks AL Same error compiling with bjam -sBOOST_ROOT=. -sTOOLS="msvc" -sPYTHON_ROOT=C:/python22 or from boost_python.dsw

2 2

Re: Explicit Conversion Operators (N1592)
by David Abrahams 07 Mar '04

07 Mar '04

Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> writes: > To: C++ extensions mailing list > Message c++std-ext-6834 > > David Abrahams writes: >> "Powell, Gary" <powellg(a)amazon.com> writes: >> >>From my reading of this paper, it would appear that this change does >> > that. I also like that the change reuses an existing keyword in what >> > would appear to be a natural extension of its use. i.e. explicit, >> > still means explicit, you have to specify not rely on the default. >> >> I haven't read the paper yet, but IMO a bigger problem is the fact >> that we don't have a single syntax for requesting an explicit >> conversion that will always be "safe". For example: >> >> T(x) // if T is a builtin type this might be a >> // reinterpret_cast >> >> static_cast<T>(x) // might be a downcast > > That's solvable, though: > > template< typename T, typename S > > T explicit_cast(S const& s, typename enable_if< is_class<T> >::type* = 0 ) > { > return T(s); > } > > template< typename T, typename S > > T explicit_cast(S const& s, typename disable_if< is_class<T> >::type* = 0) > { > return static_cast<T>(s); > } This formulation requires T (and S, if you want to pass rvalues) to have an accessible copy ctor. I'm not sure it's better than the formulation in boost/implicit_cast.hpp, which only puts a restriction on T. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

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