- Boost-users - lists.boost.org

Re: ~intrusive_ptr bug? - addRef example
by Gottlob Frege 23 May '05

23 May '05

> Date: Sun, 22 May 2005 00:21:21 +0100 > From: Jean-Fran?ois Brouillet <verec(a)mac.com> > Subject: [Boost-users] Re: ~intrusive_ptr bug? > To: boost-users(a)lists.boost.org > Message-ID: <76267242-0F5F-415A-A5ED-D671F4DE420F(a)mac.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed ... > I fail to see the "generality" in the current design. An example where > it actually makes sense to not "addRef" on ctor but to "remRef" on dtor > would be most welcome. > > > If you're arguing that the design of intrusive_ptr should be changed, > > I don't have such pretensions. I was only suggesting to *rename* the > parameter ``addRef'' into something less confusing because of the > asymmetric behavior. > ... > Many thanks. > -- > JFB > Here's my story: I wrote my own "AutoRefCountPtr" before seeing boost::intrusive_ptr. It is almost exactly the same as intrusive_ptr, including the addRef. Here's why I need the addRef: I'm using a library (DLL) that only exposes abstract classes (in the h file). To get a 'real' object/implementation, I call a function to create an object: CreateFoo(fooparams,..); Internally, this creates a Foo_Implementation, but it is returned to me as a Foo *. Part of Foo's interface is reference counting, via foo->AddRef() and foo->RemoveRef(). So when I'm done with Foo, I call RemoveRef. Note, however, that the Foo * returned from CreateFoo is already addRef'd and ready to go. So I don't need to call AddRef. I could (and did for a while) manage my Foo*'s manually, but after a number of leaks, I gave up and wrote a smart ptr (AutoRefCountPtr) that would RemoveRef automatically when I was done with the pointer. So there's your example. I few other notes: 1. maybe CreateFoo() should have returned a AutoRefCountPtr for me, instead of a 'naked' Foo *. But this is a bit hard, because CreateFoo is inside the DLL, and doesn't really want to pass back any 'real' objects (beside abstract interfaces) because the DLL and the EXE may be built differently, not at the exact same version, etc. 2. maybe the whole system suffered from a fundamental design flaw, and is a bad example. That could be, but nonetheless, it was an essential library, and I didn't really have the option to NOT use it or rewrite it, so an intrusive_ptr like thing was 'real world' helpful, even if only to assist in living with a design flaw. (Not that I think there was a design flaw, but even if there was...) 3. Note that, like intrusive_ptr, my ptr made the initial 'addRef' optional. It needed to be false when you created the object, but if Foo * was passed in as a function argument, that function might wrap it in an intrusive_ptr that DID need to do the initial addref. 4. I called my flag 'addRef'. Is that exactly the same as intrusive_ptr? Note that this still doesn't mean it is a good name - I was the *implementor* and it made sense to me, and was very descriptive for the *implementation*. But maybe it wouldn't make sense for the client/user (which was also me, in my case :-). I suspect boost's 'addRef' was also named from an implementation rather than usage point of view. But I'm still not sure what a better name would be. Maybe "already_pre_addRefd_thanks' or something like that? I do sometimes agree with names that are NOT exactly obvious as long as they are interesting enough that the user is likely to dig a little deeper to find the meaning. But my co-workers often disagree... p.s. I originally made my flag a template parameter, partially because I like this syntax so much: if (AutoRefCountPtr<Foo, false> foo = CreateFoo(blah)) { } instead of if (AutoRefCountPtr foo(CreateFoo(blah), false)) { } which doesn't always compile, because it confuses the compiler, or if (AutoRefCountPtr foo = AutoRefCountPtr(CreateFoo(blah), false)) { } which just isn't as clear as the first way. The problem with making the flag a template param is that AutoRefCountPtr<Foo, false> is not the same type as AutoRefCountPtr<Foo, true> so assignment, etc is a bit tricky. Anyone have a good solution to that? Tony

1 0

a small patch for doc
by Emre Turkay 22 May '05

22 May '05

Attached file is a small patch for libs/algorithms/string/doc/usage.xml file. Emre Turkay 125,126c125,126 < << is_executable("command.com")? "is": "is not" < << "an executable" --- > << (is_executable(str1)? " is": " is not") > << " an executable" 130c130 < char text1[]="hello world!"; --- > char text1[]="hello"; 133c133 < << all( text1, is_lower() )? "is": "is not" --- > << (all( text1, is_lower() )? " is": " is not") 135c135 < << endl; // prints "hello world! is written in the lower case" --- > << endl; // prints "hello is written in the lower case"

3 2

~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