December 2004 - Boost - lists.preview.boost.org

Retry: merging all utf8 files
by Vladimir Prus 22 Dec '04

22 Dec '04

Seems like the discussion about how to merge copies of utf8 code used by serialization and program_options has died. I'd like to revive it again, given that I've recieved yet another patch for that code, and the longer we have two versions, the harder it will be to merge them later. The basic question is whether to have a new compiled library in libs/detail, or just source files which will be included by serialization and program_options. The problem with compiled library is that users will have to know that in addition of -lboost_program_options they'll have to add -lboost_utf8, which is inconvenience. I've mentioned this in http://article.gmane.org/gmane.comp.lib.boost.devel/106047/ The proposed course of action is documented in: http://article.gmane.org/gmane.comp.lib.boost.devel/106122 Now: 1. Are there any objections? 2. Who does it? I can do it soon. Robert, what do you think? - Volodya

3 8

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 21 Dec '04

21 Dec '04

In-Reply-To: <cpsv4p$foa$1(a)sea.gmane.org> michaeltoksvig(a)yahoo.com (michael toksvig) wrote (abridged): > you might consider adding operator[] to point and size > > also, consider defining area in terms of 2 points, and adding > operator[] to that, too I was about to say the same thing :-) I'd go further, and expose the array. class box { point data_[2]; public: point *data() { return data_; } static size_t size() { return 2; } point &operator[]( size_t i ) { assert(i < 2); return data_[i]; } // Maybe begin/end too. const point &top_left() { return data_[0]; } const point &bottom_right() { return data_[1]; } float top() { return data_[0][1]; } float left() { return data_[0][0]; } float bottom() { return data_[1][1]; } float right() { return data_[1][0]; } size extent() const { return bottom_right() - top_left(); } float width() const { return right() - left(); } float height() const { return bottom() - top(); } point centre() const { return top_right() + extent()/2; } // ... void set_top_left( const point &p ); void set_top( float f ); void set_centre( const point &p ); // ... }; This is because you will almost certainly want transforms that act on arrays of points, and it will sometimes be convenient if they can act on rectangles too. I would provide get/set methods which are independent of representation. I'd consider allowing things like ++box.top() too. Currently I think the convenience is not worth the loss of purity. ++box[0][1] should work, though. On naming... I think "area" is the wrong name. To me an area can be any shape, or alternatively, every shape has an area. I would expect circle.area() to return pi*r*r. "Rectangle" is better, but what we actually have here is a special kind of rectangle which is aligned with the axis. A rotated rectangle needs more than 2 points. So conceptually we need two rectangle types. I suggest "rectangle" is reserved for the general case, and the aligned one is called "box". As in "bounding box". It has the benefit of being short. I see no benefit in using "position" instead of the usual "point". "Point" is shorter. It's hard to improve on "size" :-) I would seriously consider replacing float with a typedef, perhaps with another typedef for distances and offsets. Even without type checking, I think using more exact type names helps to clarify thought. [Later...] I've looked at the code in the zip file now. I see it doesn't match the email. It uses a different representation and adds several member functions, although not as many as me. I am surprised to see things like size*size and size/size. I see the design is being driven by the needs of a windowing system, when I am being driven by the needs of a graphics/drawing system. That has led to different results, which I suspect is a bad thing. At any rate, it has convinced me that exposing raw member variables (like area.pos) is a mistake. -- Dave Harris, Nottingham, UK

4 4

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 21 Dec '04

21 Dec '04

In-Reply-To: <cq90bq$r7v$1(a)sea.gmane.org> msclrhd(a)hotmail.com (Reece Dunn) wrote (abridged): > > This is because you will almost certainly want transforms that act on > > arrays of points, and it will sometimes be convenient if they can act > > on rectangles too. > > Translation: a.pos += gui::size( 5, 7 ); > Scaling: a.size += gui::size( 10, 20 ); > Rotation: n/a since you are assuming that each side has an angle of 90 > degrees (allowing for two point representations). I'd expect to have a family of transform objects, and in particular a general 2d affine transform represented by a matrix of 6 numbers, along the lines of: x' = x * a + y * b + c; y' = x * d + y * e * e; which can represent scales, shears, rotations, translations or any combination of them. Rotations come into play even for axis-aligned rectangles, although they may be constrained to 90 degree angles. For example, if I want to print a card that will be folded in half horizontally, the top half must be drawn upside-down relative to the bottom half. We probably want to treat it as 2 pages, draw both pages right-way-up and side-by-side in the UI, and then draw the second page upside-down and above the first one to the printer. This kind of thing is useful for 2D graphics. General affine transforms are powerful abstraction. This is an area where I have experience; my only doubt is whether the windowing system can or should use different conventions to the graphics system. And I think you will eventually want everything to be consistent and uniform. > If you have point high, low; then which corner is "high"? Likewise, > using top_left, bottom_right is bad. The same issue arises using (point, size). Which point? It could reasonably be any of the four corners, or the middle. > Having a (point, size) notation, similar to the Cocoa representation, > you remove the need for platform dependancy (except when mapping > between the native type and the independant type). You still need to know whether: r.pos += gui::size( 0, 1 ); moves the rectangle up or down. So you still need to know whether (0,0) is top-left or bottom-left. You have to pick a convention for axis orientation and stick with it, and translate where the native model differs. The orientation of rectangles drops out of the orientation of the axis. Actually, you can sometimes allow a rectangle to be specified by any pair of (diagonally opposite) points, in effect taking their bounding box. This is what PDF does. Usually, though, you normalise the rectangle so that the first point contains the smaller values and the other the larger. Incidently, the conversion from top-left to bottom-left axis orientation is an example of a general transform. It involves both a scale and a translate. > Also, this representation simplifies translation and scaling > (see above). Not really. You have some transforms applied to one member and other transforms to other members. You have to know whether a transform is a scale or a translate before you can apply it. It's not a regular, uniform system; not simple. Also, the code you show for scaling doesn't actually scale. Let's say I have two rectangles side by side: rect a( point(10, 10), size(10, 10) ); rect b( point(20, 10), size(20, 10) ); I want to scale this to double the size. What do I do? gui::size scale( 10, 10 ); a.size += scale; b.size += scale; But that didn't do the job. It made the rectangles overlap, and b's size didn't double. If we actually want that operation, the (point[2]) code is just as simple; you increment the second point. For most operations it makes no difference; neither representation has an advantage. There are probably operations for which (point,size) is slightly easier, and there are other operations for which (point[2]) is easier. I believe (point[2]) is easier for more of the important ones. Testing for point inclusion, and rectangle union, intersection etc, for example. rect intersection( const rect &lhs, const rect &rhs ) { double x0 = max( lhs.point[0].x, rhs.point[0].x ); double y0 = max( lhs.point[0].y, rhs.point[0].y ); double x1 = min( lhs.point[1].x, rhs.point[1].x ); double y1 = min( lhs.point[1].y, rhs.point[1].y ); return rect( x0, y0, x1, y1 ); } versus: rect intersection( const rect &lhs, const rect &rhs ) { double x0 = max( lhs.pos.x, rhs.pos.x ); double y0 = max( lhs.pos.y, rhs.pos.y ); double x1 = min( lhs.pos.x+lhs.size.dx, rhs.pos.x+rhs.size.dx ); double y1 = min( lhs.pos.y+lhs.size.dy, rhs.pos.y+rhs.size.dy ); return rect( x0, y0, x1-x0, y1-y0 ); } The (point,size) version has 6 extra additions or subtractions. > On review, I have removed size/size, size*size. As for the > representation change: this is an evolving library, but the essence > remains the same, so discussion here is still valid. I do not intend on > posting the full member function list as these e-mails are long enough > already! If you are interested, take a look at the code (as you have > done). I appreciate the feedback. The big questions are, should the underlying representation be exposed in the form of public member variables at all? And, does a windowing library need to pay any attention to the needs of a hypothetical drawing library? My answers are "no" and "yes". -- Dave Harris, Nottingham, UK

1 0

Review Request: BOOST_FOREACH
by Eric Niebler 21 Dec '04

21 Dec '04

BOOST_FOREACH is a macro which makes it simple to iterate over a sequence. It is concise, and clearly expresses the programmer's intentions. For example: short array_short[] = {1,2,3}; BOOST_FOREACH( short & i, array_short ) { ++i; } // array_short contains {2,3,4} here Recent changes I have made to the macro have greatly increased its safety and usefulness. It gracefully handles both L-value and R-value sequence expression, and evaluates its arguments only once. It now works (to a greater or lesser extent) on a wide range of compilers, even VC6. The current implementation, documentation and tests can be found in the Boost Sandbox File Vault. You can download the Zip file here: http://tinyurl.com/57oyp Tinyurl link redirects to: http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&fi… -- Eric Niebler Boost Consulting www.boost-consulting.com

7 7

[integer] Solaris integer_traits.hpp #error and general Solaris wchar_t issues
by Caleb Epstein 21 Dec '04

21 Dec '04

The crc library is failing regression tests on Solaris + gcc 3.3.4 (http://tinyurl.com/6qq3y) because of the #error statement on line 112 of integer_traits.hpp (see below). If one includes <wchar.h> before <boost/integer.hpp>, all is well, but if not an error is triggered. Solaris + gcc seems to be a bit of an oddball platform w/r/t wchar_t. It is natively supported and there is a <wchar.h> header, but enough of the C99 wide-character IO routines are missing that gcc does not provide <cwchar>, std::wstring or other related wide features on this platform. The config library sets BOOST_NO_CWCHAR but in integer_traits.hpp I see: 24 #if !defined(BOOST_NO_INTRINSIC_WCHAR_T) && !defined(BOOST_NO_CWCHAR) 25 #include <wchar.h> 26 #endif There is a <wchar.h> but no <cwchar>. Perhaps there ought to be a config macro BOOST_NO_WCHAR_H that could be used instead of BOOST_NO_CWCHAR in this case, or perhaps just the second part of the #if should be dropped. Here's the section of integer_traits.hpp that is generating the error when <wchar.h> is not first included: 85 #ifndef BOOST_NO_INTRINSIC_WCHAR_T 86 template<> 87 class integer_traits<wchar_t> 88 : public std::numeric_limits<wchar_t>, 89 #if defined(WCHAR_MIN) && defined(WCHAR_MAX) 90 public detail::integer_traits_base<wchar_t, WCHAR_MIN, WCHAR_MAX> 91 #elif defined(__BORLANDC__) || defined(__CYGWIN__) || defined(__MINGW32_ _) || (defined(__BEOS__) && defined(__GNUC__)) 92 // No WCHAR_MIN and WCHAR_MAX, whar_t is short and unsigned: 93 public detail::integer_traits_base<wchar_t, 0, 0xffff> 94 #elif (defined(__sgi) && (!defined(__SGI_STL_PORT) || __SGI_STL_PORT < 0 x400))\ 95 || (defined __APPLE__)\ 96 || (defined(__OpenBSD__) && defined(__GNUC__))\ 97 || (defined(__NetBSD__) && defined(__GNUC__))\ 98 || (defined(__FreeBSD__) && defined(__GNUC__))\ 99 || (defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 3) && !defi ned(__SGI_STL_PORT)) 100 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as int. 101 // - SGI MIPSpro with native library 102 // - gcc 3.x on HP-UX 103 // - Mac OS X with native library 104 // - gcc on FreeBSD, OpenBSD and NetBSD 105 public detail::integer_traits_base<wchar_t, INT_MIN, INT_MAX> 106 #elif defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 2) && !define d(__SGI_STL_PORT) 107 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as unsigne d int. 108 // - gcc 2.95.x on HP-UX 109 // (also, std::numeric_limits<wchar_t> appears to return the wrong v alues). 110 public detail::integer_traits_base<wchar_t, 0, UINT_MAX> 111 #else 112 #error No WCHAR_MIN and WCHAR_MAX present, please adjust integer_traits< > for your compiler. 113 #endif 114 { }; 115 #endif // BOOST_NO_INTRINSIC_WCHAR_T -- Caleb Epstein caleb dot epstein at gmail dot com

2 5

question re autolink
by Robert Ramey 21 Dec '04

21 Dec '04

"These macros will be undef'ed at the end of the header, further this header has no include guards - so be sure to include it only once from your library!" What is the rationale for the above? What happens if its violated. I'm sort of struggling implementind a dll version of the serialization library with autolink. The basic difficulty is that I would like to have the dlls mirror the structure of the the static libraries. That is libboost_serialization.lib libboost_wserializaton.lib depends on theabove wserialization.dll is both autolinked and uses serializaton.dll so Its kind of confusing. Robert Ramey

2 1

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 21 Dec '04

21 Dec '04

In-Reply-To: <877e9a1704121705302ac4bce4(a)mail.gmail.com> > Not sure. In computer graphics you specifically talk about > "axis-aligned bounding boxes". To me, "box" is the 3d version of > "rectangle". "Axis-aligned bounding boxes" reflects the importance of being explicit about whether your rectangles are axis-aligned, so I approve, but it's also a bit of a mouthful. I think a shorter name is needed. Some people use AABB, but I'm not keen on acronyms. I'm not keen on abbreviations, too, otherwise using Rect for the axis-aligned case and Rectangle for the general case might work. "Box" was an arbitrary suggestion, in that it does not say "axis aligned" of itself, but I can't think of anything better. For me, in a graphics application, "box" is a term of art which can be either 2d or 3d. Just as points and offsets can also be 2d or 3d (or 1d or 4d). If we care about conflicts with 3d stuff, then maybe we need to be explicit about this, perhaps by using namespaces. Arguably we shouldn't care, because a windowing system is pretty far away from a 3d graphics drawing system. As I realised towards the end of my previous post, perhaps we shouldn't care about 2d graphics, either. It's not so clear-cut because windowing is also 2d; it's easier to see a continuum between them. -- Dave Harris, Nottingham, UK

2 1

boost::noncopyable
by Dirk Gregorius 21 Dec '04

21 Dec '04

Does inheriting from boost::noncopyable has the same effect like making the copy c'tor and the assignment operator private without implementing them? The authors of the smart_ptr library suggest the following for the use of the smart pointers with interfaces: class Interface { public: virtual void f() = 0; virtual void g() = 0; protected: ~Interface( void ) {}; // non-virtual } // #1 class Implementation : public Interface { public: void f() { /* Implementation */ } void g() { /* Implementation */ } private: // Not to be implemented Implementation( const Implementation& ); Implementation& operator=( const Implementation& ); } Does inheriting from boost::noncopyable has the same effect: // # 2 class Implementation : public Interface, /*public or private*/ boost::noncopyable { public: void f() { /* Implementation */ } void g() { /* Implementation */ } } 1.) Are #1 and #2 equivalent? 2.) When should I derive public and when private from boost::noncopyable? 3.) Is the use of noncopyable correct in this context and what are other scenarios when to use it? Regards, -Dirk

6 9

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

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

thread_pool
by Timothy Ritchey 17 Dec '04

17 Dec '04

I downloaded, and am getting ready to try out the thread_pool.zip implementation off the yahoo groups site by Dave Moore. I noticed that the file drop was dated 2002, and was wondering if there was a latest and greatest in the CVS tree, or whether I should use the implementation in the zip file. Cheers, tim

2 1

[signals] trackable not disconnecting
by Neal Coombes 17 Dec '04

17 Dec '04

I have been experiencing some strange behaviour (on Solaris 2.9 intel) with the signals::trackable object. I'm using it on all my objects that connect to signals and it doesn't seem to disconnect the signals consistently on destroyed objects (these objects are publicly and virtually derived from trackable). I've worked around the problem by manually disconnecting from all signals in the objects destructors. I'm having a very hard time making a small example program to demonstrate this behaviour (but I am working on it :). In the meantime if anyone else has experienced this kind of behaviour or has any information that might help, it would be greatly appreciated. TIA Neal

2 11