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

transmute_iterator
by Louis Lavery 24 May '05

24 May '05

I'm looking for a transforming iterator. I've looked at the boost transform_iterator but it doesn't quite do what I want. Well, in fact it does a little too much, it passes the dereferenced base iterator to the transform function - I would like it to pass the base iterator itself. The reason being is that the transform function is to return an object containing that base iterator (the object acts much along the lines of a boost graph edge/vertex descriptor). At the moment I've cut and pasted transform_iterator.hpp, renamed it transmute_iterator.hpp and edited it to remove one char (the dereferencing *) just so as I can try things out. Oh, I am slow! I was going to ask if such an iterator could be added to boost lib but have just realised that it is trivial for a transmute_iterator to model a transform_iterator. Hmm, so my question now is - is there some reason why the base iterator is dereferenced before being passed to the function? Wouldn't it be better to let the function decide that? thanks, Louis. BTW, you guys write some really great stuff, it's very much appreciated. And C++ Template Metaprogramming is mind blowing (especially chapters 10++). -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 266.11.12 - Release Date: 17/05/2005

2 2

RE: [Boost-users] Re: Question
by Sliwa, Przemyslaw (London) 24 May '05

24 May '05

I have seen it already, thanks. There is nothing about it how to extract the headers and libs. Should I first compile the whole library and then extract it? Or perhaps first extract and then compile. In the second case I do not get any jam file. Can you help? Thanks Pshemek -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: 23 May 2005 12:10 To: boost-users(a)lists.boost.org Subject: [Boost-users] Re: Question "Sliwa, Przemyslaw (London)" <Przemyslaw_Sliwa(a)ml.com> writes: > 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. See http://www.boost.org/tools/bcp/bcp.html HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- 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

static assertion in date_serialization_demo
by Paolo Coletta 24 May '05

24 May '05

Hi, I've tried to build this simple code using vc 7.1 using namespace boost::gregorian; date d(2004, Apr, 5); std::ofstream ofs("date_demo.txt"); boost::archive::text_oarchive oa(ofs); oa << d; but it fails due to a static assertion. The code is taken from the very first lines of boost_serialization_demo.cpp. It seems to compile with boost 1.32, but seems to fail with current boost. Since this demo is not be included in the jamfile (or I was not able to find it), I built it is using visual studio IDE. The compiler command-line options were: /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc /RTC1 /MLd /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /nologo /c /Wp64 /ZI /TP I also tried to turn on/off the RTTI, but the result did not change. The error I get is d:\PROJECTS\boost\boost\archive\detail\oserializer.hpp(557) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' Am I missing something? Thanks, Paolo

4 4

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