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

Scoped_ptr + deleter
by Sohail Somani 24 May '05

24 May '05

Why doesn't scoped_ptr have an additional template parameter to accept a deleter? Thanks Sohail

3 2

RE: [Boost-users] Scoped_ptr + deleter
by Sohail Somani 23 May '05

23 May '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Caleb Epstein > Sent: Monday, May 23, 2005 2:32 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Scoped_ptr + deleter > > > On 5/23/05, Sohail Somani <s.somani(a)fincad.com> wrote: > > Why doesn't scoped_ptr have an additional template > parameter to accept > > a deleter? > > Because that would make it larger than sizeof (T*). I > believe the general consensus on this is to use shared_ptr or > perhaps the upcoming policy_ptr. I also meant to mention that shared_ptr seems a little bit of overkill for wanting to use what is essentially scoped_ptr + a pointer to a deallocation function. Perhaps policy_ptr will be interesting.

1 0

shared pointer and WinCE
by Walter Fettich 23 May '05

23 May '05

Hello I'm having a problem when using shared pointers in Embedded Visual C++ .Net STLPort. When trying to compile I always get the error 'bad_alloc' : is not a member of 'stlp_std' in the file boost/detail/shared_count.hpp Do you know of any solution or what I can do to fix it? The macro BOOST_NO_EXCEPTIONS is defined. Is it a problem in STLPort or Boost? If I remove the namespace identifier then I get an "undeclarer identifier" error. If anyone has a working example of using STLPort and Boost shared pointers with Embedded Visual C++ 4 please post it. Thank You.

3 2

Minor Boost.Optional Documentation Nit
by Stuart Dootson 23 May '05

23 May '05

The Boost.Optional documentation (specifically, near http://www.boost.org/libs/optional/doc/optional.html#bool) says that Boost.Tribool isn't part of Boost - given that tribool debuted in Boost 1.32.0, I guess that's incorrect now... Stuart Dootson

2 1

Question
by Sliwa, Przemyslaw (London) 23 May '05

23 May '05

Guys, I was just wondering if it is possible to install just a part of the boost library? The current version is a bit "big" and there are certain libs which I o not need. Thanks for help, Pshemek -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

2 1

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