- Boost - lists.boost.org

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

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

19 Dec '04

Hi Robert ----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Domingo, Diciembre 19, 2004 0:20 am Asunto: [boost] Re: [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering > This is an issue regading two-phase lookup which was implemented > for the > first time in gcc 3.4+ > > Its discussed in the serialization documentation under "Namespaces > for free > function overrides" > That's it! Thank you very much for the pointer, I'll change my stuff according to that. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

typeof and ODR
by Arkadiy Vertleyb 18 Dec '04

18 Dec '04

Hi all, Does anybody have an access to an EDG-based compiler, and willing to help me to figure out whether a certain typeof test reports an ODR violation? I would very much appreciate this... Thanks in advance, Arkadiy

4 8

std::string <-> std::wstring conversion
by Stefan Slapeta 18 Dec '04

18 Dec '04

Hi all, there have been many discussions (and proposals) on this topic in the last years, but was there any result and is there _anything_ in boost today that can be used to convert between std::string and std::wstring? Stefan

8 15

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 17 Dec '04

17 Dec '04

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >I noticed that Boost.Filesystem doesn't use readdir_r to iterate over >directories, even if it is available, making that non-thread-safe. >There is a comment to this effect in operations_posix_windows.cpp. > >I've attached a patch that I believe will allow it to detect whether >readdir_r is available and to use it iff it is. I have only tested this >on Linux with g++ 3.3, but I tried deliberately breaking the declaration >of readdir_r and verified that the code continues to work without it. I started to look at this in detail this afternoon. Using overload resolution to adjust to feature absence is an interesting technique, and new to me. But is it really needed? POSIX specifies a feature test macro, _POSIX_THREAD_SAFE_FUNCTIONS, which would seem to be sufficient. Was there a reason you didn't use it? Is it not reliable on some systems? Thanks, --Beman

1 0

Re: [boost] Re: [multi_index] announce: added serialization support
by JOAQUIN LOPEZ MU?Z 17 Dec '04

17 Dec '04

----- Mensaje original ----- De: Bruno Martínez Aguerre <br1(a)internet.com.uy> Fecha: Jueves, Diciembre 16, 2004 9:50 pm Asunto: [boost] Re: [multi_index] announce: added serialization support > Can serialization for iterator types be added? > Ummm... yes, this can be done. It'd be trivial except that it interacts badly with Boost.MultiIndex safe mode. Let me think it over, I guess I can have something done after Xmas. Do you have the actual need to serialize iterators or is this more of an academic request? Have you tried the serialization capabilities in some compiler? Did you find any problem? Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2