May 2005 - Boost-users - lists.preview.boost.org

~intrusive_ptr bug?
by Jean-François Brouillet 22 May '05

22 May '05

As observed in another thread, the intrusive_ptr destructor in boost 1.32 does not honor its own status as defined in the constructor with respect to the addRef boolean. This snippet shows the problem: X * x = new X ; { intrusive_ptr<X> p(x, false) ; } // Here, x has been destroyed! Is this a bug, or some requirement (that I couldn't find) that if you ever pass "false" to the constructor, then that intrusive_ptr is assumed to never go out of scope? The fix would be simple: ... bool strong ; intrusive_ptr(T * p, bool add_ref = true): p_(p), strong(add_ref) { if(p_ != 0 && add_ref) intrusive_ptr_add_ref(p_); } ... ~intrusive_ptr() { if(p_ != 0 && strong) intrusive_ptr_release(p_); } though it is less clear whether it would break some assumption I'm not privy to. Also, the above "fix" would increase the stack storage from the typical 4 bytes to probably 8 (due to alignment) just to store an additional bit. Obviously, a less portable implementation could get away with storing the bool as the low order bit of p_, masking it off when required ... Should I go ahead an implement this fix with the knowledge that a future revision of boost will include it, or is there any other consideration that render this fix unlikely to make it into an official release ? BTW: I did check the "unit tests" for intrusive_ptr at: http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/ smart_ptr/test/intrusive_ptr_test.cpp and this case is clearly not accounted for. -- Jean-François Brouillet verec(a)mac.com

3 10

stringification
by Cory Nelson 22 May '05

22 May '05

Doesn't have to do with boost but this seems like the croud that would know how to do this. I have the code: #ifdef _WIN32_WINNT #ifdef _WIN64 #define BUILDTYPE 3000000 #else #define BUILDTYPE 1000000 #endif #else #define BUILDTYPE 2000000 #endif #define BUILDDATE 50521 #define BUILDNUM (BUILDTYPE+BUILDDATE) and would like to stringify the value of BUILDNUM into say "2050521" in the preprocessor. Is there a way to do this (in vc7.1)? -- Cory Nelson http://www.int64.org

2 1

Installation building errors on win with vc71stlport
by Jacques-Andre Boulay 21 May '05

21 May '05

Hi, I'm trying to install Boost on windows xp with stlport and Visual Studio .Net 2003. When building it with "bjam "-sTOOLS=vc-7_1-stlport" install" I'm obtaining errors that seems like: vc-C++ bin\boost\libs\date_time\build\boost_date_time.dll\vc-7_1-stlport\debug\threading-multi\greg_month.obj greg_month.cpp C:\Documents and Settings\BOUJAC00\Bureau\boost_1_32_0\boost\lexical_cast.hpp(150) : error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'boost::date_time::date_names_put<Config,charT,OutputIterator>::string_type' (or there is no acceptable conversion) with [ Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=std::ostreambuf_iterator<wchar_t,std::char_traits<wchar_t>> ] The log of the build is include in log2.txt. Somebody have an idea of what I'm doing wrong? Thanks in advance JA

2 1

[serialization] trouble with vc71, debug build
by Zrubavel Zodikovich 21 May '05

21 May '05

I'm having trouble with debug builds of the boost serialization (1.32) library. The release configuration works fine, but debug build crashes with access violation on binary_iarchive instantiation. call stack is attached. Any suggestions ? msvcp71.dll!std::locale::locale(const std::locale & _Right={...}) Line 235 + 0x7 C++ msvcp71.dll!std::ios_base::getloc() Line 382 + 0xf C++ msvcp71.dll!std::num_put<char,std::ostreambuf_iterator<char,std::char_traits<char> > >::_Iput(std::ostreambuf_iterator<char,std::char_traits<char> > _Dest={...}, std::ios_base & _Iosbase={...}, char _Fill='�', char * _Buf=0x02b3ec18, unsigned int _Count=8) Line 1193 + 0xf C++ msvcp71.dll!std::num_put<char,std::ostreambuf_iterator<char,std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char,std::char_traits<char> > _Dest={...}, std::ios_base & _Iosbase={...}, char _Fill='�', const void * _Val=0x00000005) Line 1032 C++ msvcp71d.dll!std::codecvt_base::always_noconv() Line 566 C++ msvcp71d.dll!std::basic_filebuf<char,std::char_traits<char> >::_Initcvt(std::codecvt<char,char,int> * _Newpcvt=0x027538a0) Line 483 + 0x8 C++ msvcp71d.dll!std::basic_filebuf<char,std::char_traits<char> >::imbue(const std::locale & _Loc={...}) Line 413 C++ msvcp71.dll!std::basic_streambuf<unsigned short,std::char_traits<unsigned short> >::pubimbue(const std::locale & _Newlocale={...}) Line 79 C++ msvcp71.dll!std::basic_ios<unsigned short,std::char_traits<unsigned short> >::imbue(const std::locale & _Loc={...}) Line 96 + 0xc C++ ImageTransformTest.dll!boost::archive::basic_binary_iprimitive<boost::archive::binary_iarchive,std::basic_istream<char,std::char_traits<char> > >::basic_binary_iprimitive<boost::archive::binary_iarchive,std::basic_istream<char,std::char_traits<char> > >(std::basic_istream<char,std::char_traits<char> > & is_={...}, bool no_codecvt=false) Line 139 + 0x25 C++ ImageTransformTest.dll!boost::archive::binary_iarchive_impl<boost::archive::binary_iarchive>::binary_iarchive_impl<boost::archive::binary_iarchive>(std::basic_istream<char,std::char_traits<char> > & is={...}, unsigned int flags=0) Line 56 + 0x35 C++ ImageTransformTest.dll!boost::archive::binary_iarchive::binary_iarchive(std::basic_istream<char,std::char_traits<char> > & is={...}, unsigned int flags=0) Line 78 + 0x17 C++

2 1

Re: [Boost-users] Question about template optimization
by Gottlob Frege 21 May '05

21 May '05

> Date: Wed, 18 May 2005 17:32:49 -0700 > From: "Elisha Berns" <e.berns(a)computer.org> > Subject: [Boost-users] Question about template optimization > To: "Boost" <boost-users(a)lists.boost.org> > Message-ID: <000001c55c0a$4966cf30$651aa8c0@INSPIRATION> > Content-Type: text/plain; charset="us-ascii" > > I need help with this one, even though it's a pure C++ question, it's > about template optimization: > > If a template class has methods that DO NOT depend on or use the type > parameter(s) of the template will the code for the methods nevertheless > get instantiated separately for each unique instance of the template > class? For example, if there are 20 unique types used to declare 20 > instances of template class X, do those methods get implemented 20 > different times, needlessly, and cause a big code bloat? > what about 'non-dependent' methods with local statics: template <typename T> class C { int fooCount() { static int foo = 0; return ++foo; } }; C<int> a; C<long> b; int fooA = a.fooCount(); int fooB = b.fooCount(); what is the value of fooB? If there was only 1 implementation of fooCount() I would expect fooB == 2. However, I think you will find fooB == 1. I suppose a compiler could still make the code common, but with separate static foo's, but then in general, there is nothing stopping a compiler from looking at 2 unrelated functions and saying, 'hey, lots of the code here looks the same; I should just refactor some of it out and remove some code bloat'. Not sure much of that ever happens. Reality is that once upon a time there were compiler switches for size vs speed, but speed won. > Even if most compilers are smart about this kind of thing, is it still > better practice to separate from the template class (or method) all of > the code that does not use the template type parameters? > Short answer: I suspect code bloat happens, and you should keep non-dependent code out of your templates if you care about it enough. > Thanks, > > Elisha Berns > e.berns(a)computer.org > > Tony

3 2

Gcc hangs when compiling serialization/xml_grammar.cpp on mac
by Bo Peng 20 May '05

20 May '05

Dear list, This problem has been discussed: seralization library can not be built under mac because gcc will hang when compiling xml_grammar.cpp (See the attached email from this list). Has anyone investigated this issue? Thanks. Bo -------------------------------------------------------------------------------------------------------------- On 4/18/05, Tom Denniston <tom.denniston at gmail.com> wrote: > That works, all the targets seem to compile except one (see below). > It seems to just hang. Is this the one you were having trouble with. > what surprises me is that I have 1 GB of ram and still have the > problem. > > The ouput I am seeing is below: > > Tom-Dennistons-Computer:/development/libraries/boost_1_32_0 > tomdenniston$ /development/bjam-3.1.10-1/bjam -sTOOLS=darwin > -sPYTHON_VERSION=2.3 > ...found 8239 targets... > ...updating 261 targets... > darwin-C++-action > bin/boost/libs/serialization/build/libboost_serialization.a/darwin/release/xml_grammar.o That's the one. Perhaps it's not a memory problem but rather a compiler bug? I haven't ever bothered to dig into it because I am not using the serialization library. As I said before, I usually restrict the build to just the libraries that I need. It saves time and space. -Patrick

1 0

Intefaces (BIL) IDL formating
by Tim Michals 20 May '05

20 May '05

What I'm setting up is a formatting API for logging and want to pass parameters like printf is doing. "Jonathan Turkanis" <technews(a)kangaroologic.com> wrote in message news:d6fsoa$5c4$1@sea.gmane.org... > Tim Michals wrote: > > I'm trying to figure out how would you format the IDL function for a > > general function like printf? > > > > For example > > the function is printf( const char *fmt, ...) > > > > How you format the IDL function? > > BOOST_IDL_FN1(formatMsg, const char *fmt) > > Function with variable numbers of arguments, and non-member functions, aren't > (yet) supported. In fact, supporting functions with variable number of arguments > never occurred to me. Also, when non-member functions are supported, they will > have to have at least one parameter type related to the interface being defined. > > What's your intended use? > > Best, > Jonathan

1 0

[BGL] combining kdtree-style operations
by martin f krafft 20 May '05

20 May '05

I am looking at a complex project I am about to implement with BGL. Among regular graph operations, we need each vertex/edge to be located in Cartesian space (a Coordinate property will do) and for any point P in this Cartesian space (which may coincide with a vertex or edge) determine the set of geographically close vertices/edges (within the sphere of radius r, centred at P). Thus, the result set is essentially completely independent of the graph's structure, only dependent on the Coordinate property of the graph elements. The classic algorithm for this type of problem is the KD-Tree, a structure optimised for spatial lookups in K-dimensional space. It uses the same technique as a binary search, but at each level, the next dimension is compared... until K, at which point the iteration starts again from 0. Bentley, J. L., Multidimensional binary search trees used for associative searching, Communications of the ACM, v.18 n.9, p.509-517, Sept. 1975 A demo for 2 dimensional search: http://www.rolemaker.dk/nonRoleMaker/uni/algogem/kdtree.htm I have written a nice, flexible STL-container-style KDTree implementation: http://freshmeat.net/projects/libkdtree This uses its own tree implementation along with bidirectional iterators. Since it stores edges and vertices in the same data structure, it does not really make for a good base container for the BGL. It would be possible to use separate trees for edges and vertices, but another problem makes that really difficult: changes to the Cartesian coordinates basically require the object to be removed and reinserted into the tree, and erasure does not work reliably currently (I have not found a viable update strategy). Now I am faced with the task of combining that with the BGL. Thus, I am weighing options: - does anyone work with KD Trees and the BGL who'd be willing to share experiences with me? In particular, I wonder whether it is possible * to use the same data structures for both, such that I do not have to store multiple pointers for my objects, one in the graph and one in the KD tree? * to implement KD trees with BGL? - would this library be a candidate for Boost and/or the BGL? I realise that it's way too STL-centric right now (I somehow got a kick out of using the same variable naming scheme as the SGI STL implementation, which was made by people with obvious psychiatric needs (</humour>). Basically, between its current version and a final version ("1.0"), the following needs to be done: * clean up the source code to make it less cryptic (1 day) * figure out how to implement erase-and-optimise efficiently (1 week) * figure out a way to make the coordinates mutable so that the tree can accomodate moving objects (although it's probably not the best container for e.g. particle systems). * push decisions down into policies (it already uses comparator and allocator policies). So this email does two things: If you are familiar with KD trees and the BGL, please give me some insight into your approach. If you are interested in the KD tree implementation and think that it would be a good candidate for boost, consider helping out to attack the TODO list, and if only with conceptual discussion. Thanks for your time and patience. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus(a)madduck.net "half a bee, philosophically, must ipso facto half not be." -- monty python

3 6

Confusion with demo.cpp from Serialization doc
by Peter Broadwell 20 May '05

20 May '05

When I seemingly successfully compile: http://boost.org/libs/serialization/example/demo.cpp a sample of several aspects of the Boost Serialization library, I get something close to what I expect, but it is missing the names of the drivers in the restored schedule (output below). In debugging the code it seems the file_version argument to the serialize call is always 0, despite the macro BOOST_CLASS_VERSION to set it to 2 being evaluated at compile time. I am running: - gentoo linux, 2005.0, 2.6.11-gentoo-r6 - i686-pc-linux-gnu-3.4.3-20050110 - dev-libs/boost-1.32.0 Any clues where to look for the culprit, or is this the expected behavior? ;;peter > original schedule > 6:24 bob > 0x0x806b0b0 34º135'52.56" 134º22'78.3" 24th Street and 10th Avenue > 0x0x806b120 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 0x0x806b168 35º136'15.456" 133º32'15.3" White House > 9:57 bob > 0x0x806b0b0 34º135'52.56" 134º22'78.3" 24th Street and 10th Avenue > 0x0x806b120 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 0x0x806b168 35º136'15.456" 133º32'15.3" White House > 11:2 alice > 0x0x806b0b0 34º135'52.56" 134º22'78.3" 24th Street and 10th Avenue > 0x0x806b120 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 0x0x806b168 35º136'15.456" 133º32'15.3" White House > 7:17 ted > 0x0x806b1b8 35º134'48.789" 133º32'16.23" Lincoln Memorial > 0x0x806b168 35º136'15.456" 133º32'15.3" White House > 0x0x806b120 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 9:38 ted > 0x0x806b1b8 35º134'48.789" 133º32'16.23" Lincoln Memorial > 0x0x806b168 35º136'15.456" 133º32'15.3" White House > 0x0x806b120 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 11:47 alice > 0x0x806b1b8 35º134'48.789" 133º32'16.23" Lincoln Memorial > 0x0x806b168 35º136'15.456" 133º32'15.3" White House > 0x0x806b120 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > restored schedule > 6:24 > 0x0x806d7b0 34º135'52.56" 134º22'78.3" 24th Street and 10th Avenue > 0x0x806dce8 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 0x0x806dd58 35º136'15.456" 133º32'15.3" White House > 9:57 > 0x0x806d7b0 34º135'52.56" 134º22'78.3" 24th Street and 10th Avenue > 0x0x806dce8 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 0x0x806dd58 35º136'15.456" 133º32'15.3" White House > 11:2 > 0x0x806d7b0 34º135'52.56" 134º22'78.3" 24th Street and 10th Avenue > 0x0x806dce8 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 0x0x806dd58 35º136'15.456" 133º32'15.3" White House > 7:17 > 0x0x806dcc0 35º134'48.789" 133º32'16.23" Lincoln Memorial > 0x0x806dd58 35º136'15.456" 133º32'15.3" White House > 0x0x806dce8 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 9:38 > 0x0x806dcc0 35º134'48.789" 133º32'16.23" Lincoln Memorial > 0x0x806dd58 35º136'15.456" 133º32'15.3" White House > 0x0x806dce8 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane > 11:47 > 0x0x806dcc0 35º134'48.789" 133º32'16.23" Lincoln Memorial > 0x0x806dd58 35º136'15.456" 133º32'15.3" White House > 0x0x806dce8 35º137'23.456" 133º35'54.12" State street and Cathedral Vista Lane

1 0

Re: pimpl and Qt
by gruenedd＠idmt.fraunhofer.de 19 May '05

19 May '05

> 1. Global namespace pollution. That can be easily fixed, by making > FooPrivate innter class of Foo. I don't think that a struct supplied with and named like the class followed by Private is a pollution, and it matches the naming conventions in Qt3. You can make it an inner class, but what i tried to point out is that you have to make the type public, because the generated code from moc needs access to that structure in cases. I gave that hint, that beginners avoid this issue from the beginning. > 2. High danger of unexpected behaviour if implementation of assignment > and copy contrsuctor is omitted or incorrect. If you forget to > implement copy operator and then .... I leaved that out. Of course you can use copy constructors and stuff or you favorite smartpointer, or both or whatever one prefer... --David

1 0