- Boost - lists.boost.org

www.boost.org has release information for version 1.33.0
by Douglas Gregor 20 Dec '04

20 Dec '04

It looks like the index.htm from the CVS trunk got pushed to the public web site, but the Version 1.33.0 changes did not get removed. Doug

2 1

Re: [boost] [config][gcc 3.4.2] Request for test about functiontemplate ordering
by JOAQUIN LOPEZ MU?Z 20 Dec '04

20 Dec '04

----- Mensaje original ----- De: Martin Wille <mw8329(a)yahoo.com.au> Fecha: Sábado, Diciembre 18, 2004 10:10 pm Asunto: Re: [boost] [config][gcc 3.4.2] Request for test about functiontemplate ordering > JOAQUIN LOPEZ MU?Z wrote: > > Hi, I've got the hunch that GCC 3.4.2 (specifically, > > the mingw version) might have some problems with > > function template ordering. Could somebody with > > access to that compiler please run the code below > > and report the results? Many thanks in advance. > > "bar-specific" for gcc 3.4.0, gcc 3.4.2, gcc 3.4.3, > gcc 3.3.5, gcc 3.2.3, gcc 3.1 on Linux. > Hi Martin. Well, seems my snippet does not capture the problem, but defiintely there's some difference wrt function template ordering handling between GCC 3.3.x and GCC 3.3.4: the issue is shown here: http://tinyurl.com/3nkgw (GCC 3.4.3 on your regression machine) This is a test for serialization capabilities of Boost.MultiIndex, and it works for GCC <3.4.x. In GCC 3.4.4, hoeever, a user-provided overload of boost::serialization::load_construct_data is not picked up. I guess you have the current CVS downloaded at your machine, since you're publishing regressions. Could you please do me a favor? If so, please define BOOST_NO_FUNCTION_TEMPLATE_ORDERING and rerun Boost.MultiIndex test_serialization for GCC 3.4.4. Boost.Serialization has some machinery to overcome fto problems. Thanks! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

#include <...> not in list of dependants
by Roland Schwarz 20 Dec '04

20 Dec '04

Sorry for posting to the developer list. I intended it to go to jamboost but I did not manage to get through. I would be glad if someone could instruct me how to subscribe to the jamboost list. --------------------------------------------------- I observed the following behaviour: When building the library, files that are included by e.g. #include <<boost/config.hpp> obviously are not in the list of dependant files. Consequently when one of such files has been edited no recompilation is beeing triggered. While this behaviour is fine with user programs it is unfortunate when compiling (and working) on the library itself. I even suspect that updating such files from sourceforege will render the following compile meaningless. I tried this on windows with MSVC 7_1. Any hints? Roland

2 1

[config][gcc 3.4.2] Request for test about function template ordering
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

Hi, I've got the hunch that GCC 3.4.2 (specifically, the mingw version) might have some problems with function template ordering. Could somebody with access to that compiler please run the code below and report the results? Many thanks in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo #include <iostream> namespace A { template<typename T,typename Q> void foo(T&,Q&) { std::cout<<"default"<<std::endl; } } struct bar{}; namespace A { template<typename T> void foo(T&,bar&) { std::cout<<"bar-specific"<<std::endl; } } namespace B { inline void f() { int x; bar b; A::foo(x,b); } } int main() { B::f(); return 0; }

3 2

Re: [boost] Re: boost::noncopyable
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Diciembre 19, 2004 2:58 pm Asunto: [boost] Re: boost::noncopyable > JOAQUIN LOPEZ MU?Z wrote: > > >> >> 2.) When should I derive public and when private from > >> boost::noncopyable?> > >> > Given what I said, I think that deriving from boost::noncpyable > >> > must be avoided if multiple inheritance is present and you > >> > expct your class to be allocated on the stack. > >> > >> "Must be avoided" is a bit strong. One extra byte usually > makes no > >> difference for a class that will be allocated on the stack. > > > > My fault: I meant "allocated on the heap". > > But the same argument applies. One extra byte usually makes no > difference. Well, yes, certainly. Possibly, the cases were it matters are not that common. In my work at Boost, I use noncopyable nodes to build data structures, and here deriving from boost::noncopyable is a no-no. In many other situations, as you say, it doesn't make any serious difference. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

serialization: remove_whitespace compilation fix for RW STL
by Graham Bennett 19 Dec '04

19 Dec '04

Hi, I needed to make a change to boost/archive/iterators/remove_whitespace.hpp in boost 1.32.0 to get it to compile using the Roguewave standard library implementation on linux. A patch is attached. The problem is that on glibc 2.2-based systems /usr/include/wctype.h defines the isw... functions as macros. The gcc standard library undefs all these macros but RW does not, and they are not willing to change that. A similar fix was already made in boost/regex/config/cwchar.hpp for 1.31.0. cheers, Graham. -- Graham Bennett

1 0

Two small tools to make things more static
by Stefan Slapeta 19 Dec '04

19 Dec '04

Hi all, there are 2 very small utilities I wrote a long time ago and that I use very often. I wonder if something like this has already been provided somewhere: The first is a small class template static_ which create a singleton of a class "from outside". It can be either instantiated: struct AnyClass { void f() {} }; static_<AnyClass> s; s->f(); ...or used completely statically: static_<AnyClass>::get()->f(); AnyClass must be default constructible; it's guaranteed that all static_<AnyClass> instances will only create one single instance of AnyClass. static_ has a second (defaulted) template parameter to specify an "owner" type. You can specify it if you want a single instance for exactly one owner type; (so, if A and B are classes, static_<AnyClass, A> and static_<AnyClass, B> would produce one static instance for A and one for B). The purpose of the second utility ("call") is to make a "static call" (=call once); it does nothing else then to call a functor in its constructor so that you can write static call c(functor); See attachements! Cheers, Stefan #ifndef STATIC_TOOLS_H_INCLUDED #define STATIC_TOOLS_H_INCLUDED /* Some ideas for static tools ... (c) Stefan Slapeta 2004 */ //////////////////////////////////////// // class template static_ //////////////////////////////////////// template <typename T, typename OwnerT = void> struct static_ { T* operator -> () const { return &member; } static T* get() { return &member; } private: static T member; }; template <typename T, typename OwnerT> T static_<T, OwnerT>::member; //////////////////////////////////////// // class call //////////////////////////////////////// struct call { template <typename T> call(T& t) { t(); } }; #endif /* Some ideas for static tools ... (c) Stefan Slapeta 2004 */ #include "static_tools.h" #include <boost/bind.hpp> #include <iostream> struct Test { void f() { std::cout << "called!" << std::endl; } }; int main() { static_<Test> s; s->f(); static_<Test>::get()->f(); Test t; static call c(boost::bind(Test::f, t)); }

3 2

Re: [boost] Re: boost::noncopyable
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Diciembre 19, 2004 2:10 am Asunto: [boost] Re: boost::noncopyable > Joaquin M Lopez Munoz wrote: > > Dirk Gregorius <dirk <at> dirkgregorius.de> writes: > > > > >> 1.) Are #1 and #2 equivalent? > > > > In a broad sense, yes. The problem is that many compilers > > don't do EBO (empty base optiimzation) in the presence > > of multiple inheritance, which might end up (in #2) > > with sizeof(Implementation) being greater than strictly needed. > > Correct. > > >> 2.) When should I derive public and when private from > boost::noncopyable?> > > Given what I said, I think that deriving from boost::noncpyable > > must be avoided if multiple inheritance is present and you > > expct your class to be allocated on the stack. > > "Must be avoided" is a bit strong. One extra byte usually makes no > difference for a class that will be allocated on the stack. My fault: I meant "allocated on the heap". Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

Hi Peter ----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Sábado, Diciembre 18, 2004 11:15 pm Asunto: Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering > JOAQUIN LOPEZ MU?Z wrote: > > Hi Martin. Well, seems my snippet does not capture > > the problem, but defiintely there's some difference > > wrt function template ordering handling between > > GCC 3.3.x and GCC 3.3.4: the issue is shown > > here: > > > > http://tinyurl.com/3nkgw (GCC 3.4.3 on your regression > > machine) > > > > This is a test for serialization capabilities of > > Boost.MultiIndex, and it works for GCC <3.4.x. > > In GCC 3.4.4, hoeever, a user-provided overload of > > boost::serialization::load_construct_data is not > > picked up. > > It's probably two-phase lookup related; have you tried putting the > user > overload in the user class' namespace, where it belongs? Indeed it is a 2-phase lookup issue, as Robert has pointed out. > > Don't automatically jump to conclusions that partial ordering is > broken; > more often than not, it is the code that is broken. How I wished that was true :) more often than not, making my library work for a wide range of compilers had nothing to do with my code compliance. This particular case is, to my delight, an exception. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

Hi Martin ----- Mensaje original ----- De: Martin Wille <mw8329(a)yahoo.com.au> Fecha: Domingo, Diciembre 19, 2004 1:28 pm Asunto: Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering > > > http://tinyurl.com/3nkgw (GCC 3.4.3 on your regression > > machine) > > > > This is a test for serialization capabilities of > > Boost.MultiIndex, and it works for GCC <3.4.x. > > In GCC 3.4.4, hoeever, a user-provided overload of > > boost::serialization::load_construct_data is not > > picked up. > > > > I guess you have the current CVS downloaded at your > > machine, since you're publishing regressions. > > Could you please do me a favor? If so, please > > define BOOST_NO_FUNCTION_TEMPLATE_ORDERING and rerun > > Boost.MultiIndex test_serialization for GCC 3.4.4. > > Boost.Serialization has some machinery to overcome > > fto problems. > > I feel a bit confused now. There is no gcc 3.4.4, > do you mean 3.4.3? > I'm sorry, I wrote my previous post in a rush and got the version numbers messed up. Yes, I meant 3.4.3, but anyway the problem seems to be solved, or at least identified, please read Robert's answer. Thank you for your help, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0