- Boost - lists.boost.org

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