- Boost - lists.boost.org

Const-incorrect constructor inprogram_options::basic_command_line_parser?
by Lars Iversen 16 Feb '05

16 Feb '05

I assume that the constructor for program_options::basic_command_line_parser (and function program_options::parse_command_line) in boost/boost/boost/program_options/parsers.hpp revision 1.11 could accept pointers to const char instead of non-const pointers?! Regards, Lars

3 3

Smart mutex pointer?
by Raz 15 Feb '05

15 Feb '05

Why doesn't Boost have any smart pointers that automatically lock a class when a member is used? The code isn't that hard. #include <iostream> struct Dummy { int a; } class Lock { private: Dummy &_d; public: Lock( Dummy &d ) : _d(d) { std::cout << "Locked." << std::endl; } ~Lock( void ) { std::cout << "Unlocked." << std::endl; } Dummy *operator->( void ) { return &_d; } }; class Ref { private: Dummy &_d; public: Ref( Dummy &d ) : _d(d) { } Lock operator->(void) { return Lock(_d); } }; int main( void ) { Dummy d; Ref x(d); x->a = 1; std::cout << x->a << std::endl; } I get: Locked Unlocked Locked 1 Unlocked on my system (g++ 3.3.3 and g++ 3.4.0). Has there been any reason not to do this? -- ------------------------------------------- Dan Day http://razzerblog.blogspot.com

3 5

overloads-20050207.tar.gz
by Alexander Nasonov 15 Feb '05

15 Feb '05

https://sourceforge.net/project/shownotes.php?release_id=303009 This package has been tested on gcc 3.4 and linux-intel 8.0. Two kinds of overload sets are currently implemented: natural sets and range sets, that is, overloads::set<X> and overloads::set<X, mpl::range_c<int,1,3> > where X is (I call its concept OverloadsHolder, feel free to suggest better name): struct X { void operator()(overloads::id<1>, int, char) const; // void(int,char) bool operator()(overloads::id<2>, long) const; // bool(long) }; mpl::end for natural set is not constant time but fast. The following MPL algorithms work: - has_key - order - find - size - empty - equal

4 33

Re: std::map per-node overhead (Was: [boost] Re: shared_ptr doubts)
by JOAQUIN LOPEZ MU?Z 15 Feb '05

15 Feb '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Martes, Febrero 15, 2005 8:41 pm Asunto: std::map per-node overhead (Was: [boost] Re: shared_ptr doubts) > David Abrahams wrote: > > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > >> On Feb 15, 2005, at 9:49 AM, David Abrahams wrote: > >> > >>> You don't need any storage for rebalancing. Typical map nodes > have>>> 3 pointers: parent, left child, and right child. > >> > >> If it is a red-black tree, you need to store the color of each > node.>> This information requires 1 bit, which can easily be > padded to a > >> word. > > > > Oh, I didn't understand that he meant color info. I guess that is > > only for rebalancing, isn't it? > > > > /me crawls back under rock > > > >> If it is a AVL tree, each node needs to store its tilt. This > >> information requires 2 bits. > >> > >> Or is there a new technique I'm about to learn about? :-) > > > > /me burrows several inches down into dirt under rock > > You could have pretended that you had in mind an implementation > where > pointers are always even and one of the least-significant bits is > used as a > color bit. ;-) > > Are there std::maps that store a next and previous pointer to > optimize > traversal at the expense of per-node overhead? > > (Of course my original point was that most people don't care about > the > per-node overhead and those that do just use a different data > structure.) I'm pretty certain no commercial STL implementation exists that does this, precisely because of the overhead. Users might not care, but implementors surely do. Incidentally, a multi_index_container with an ordered index and a sequenced index pretty much mimics the kind of data structure you've got in mind. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo.

1 0

Re: [boost] Re: Re: Re: Querying the Interest in a new AutoPtr class?
by Chris Just 15 Feb '05

15 Feb '05

Jonathan Turkanis wrote: >>>> I wanted to create a very simple AutoPtr that was essentially the >>>> same as the STL auto_ptr (and backwards compatible with it). >>> >>> Unfortunately, you haven't (see below). Furthermore, auto_ptr is >>> widely recognized as unsafe because it is too easy to transfer >>> ownership unintentionally. >> >> Of course you can unintentionally transfer ownership if you don't >> know what you're doing. ;) > > The problem is that the code which transfers ownership appears innocuous on the > surface, because auto_ptr allows transfer of ownership with the same syntax > ordinarily used for copying: > > void f() > { > auto_ptr<int> ptr(new int); > auto_ptr<int> ptr2(ptr); // ptr is now empty. > } Why would anyone in their right mind do that? >> I believe that's why you're not supposed to pass an auto_ptr to a >> function -- instead you pass the pointer itself with .get(). You >> can't stop everyone from shooting themselves in the foot. > > Declaring a function to take an argument of type auto_ptr<...> is one way to > signal that ownership is being transfered to the function. It also ensures that > the managed object will be deleted, unless the function takes explicit steps to > cause a leak. Passing raw pointers defeats this system. Yes, this is true if you're calling a function that you wrote and compiled yourself, but if you're calling a 3rd party API that you didn't compile yourself, that can be dangerous (or so I've been told). >> How? If you pass a pointer to a function, you shouldn't be deleting >> it inside that function anyways (so pass it with .get()), > > What if you want to transfer ownership to the function, as is often the case? Then pass ptr.release() to the function. >> and if you >> return a pointer from a function, you can save it in a new AutoPtr so >> it will get deleted automatically... > > This depends on the calling code to do the right thing. If you return an > auto_ptr, the managed object will be freed even if the calling code choses to > ignore the return value. I agree, if it's your own code, return an auto_ptr, but if you're an API, you must return a raw pointer. >> I don't set my pointer to NULL when I release() it, I just set >> m_Owner = false. > > This behavior is not compatible with std::auto_ptr. I could change it to set the pointer to NULL, but this is what Microsoft's auto_ptr does, and it looked safer. > move_ptr has the same overhead as auto_ptr. Thanks, when I get some time I'll take a look at those. As you might infer from some of my comments, I'm dealing mostly with API component code myself, which integrates some older sub components, so I have no choice but to pass raw pointers most of the time. Chris Just __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

Re: Re: Re: Re: Re: Querying the Interest in a new AutoPtr class
by Chris Just 15 Feb '05

15 Feb '05

Jonathan Turkanis wrote: >> I'm not an expert with compilers so I'll tell you how it was >> explained to me. Different compilers could take the same C++ code >> and compile it into different machine code, causing function pointers >> to shift. When you pass an object that was compiled on one machine >> to a function that was compiled on another machine, you can't be sure >> that the object will be deleted properly. > > I guess you're talking about passing objects between modules compiled with > compilers having incompatible ABIs. In general this is a recipe for disaster. If > you restrict yourself to a C language interface you often have more flexibility, > but in that case you can't use smart pointers. > > Is this what you mean? Yes, that's exactly what I mean, and probably explained a little better too. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

find the subexpression that matched
by Lorenzo Bettini 15 Feb '05

15 Feb '05

Hi is there an immediate way to access the sub-expression that matched instead of checking each "what" as in the following? for (unsigned int i = 1; i < what.size(); ++i) { if (what[i].matched) { thanks in advance Lorenzo

4 9

[iostreams] Link errors on msvc-stlport with dynamic runtime
by Jonathan Turkanis 15 Feb '05

15 Feb '05

Hi, Three iostreams tests are failing with the toolset msvc-stlport. All the unresolved symbols are specializations of standard library function templates. In the first case, the template argument is a user-defined type, but in all the other cases the template arguments are built-in types or standard library classes. The middle two look a bit suspicious, since debug and non-debug stuff is mixed together. I don't know anything about what functions STLPort defines in DLLs, so any help would be appreciated. Jonathan ---------------- Unresolved symbols (abbreviated): code_converter_test.cpp 1. __declspec(dllimport) public: __thiscall locale(locale const&, stateless_null_padded_codecvt*) 2. __declspec(dllimport) basic_string<unsigned short>::insert( struct _STL::_DBG_iter<class _STL::_Nondebug_string<unsigned short> >, unsigned short const*, unsigned short const*) newline_filter_test.cpp 3. __declspec(dllimport) basic_string<char>::insert( struct _STL::_DBG_iter<_STL::_Nondebug_string<char> >, char const*, char const*) wide_stream_test.cpp 4. __declspec(dllimport) basic_string<unsigned short>::basic_string( basic_string<unsigned short>::_DBG_iter<class _STL::__vector<unsigned short> >, basic_string<unsigned short>::_DBG_iter<class _STL::__vector<unsigned short> )

3 6

Re: [boost] Re: Re: Re: Re: Querying the Interest in a new AutoPtr class?
by Chris Just 15 Feb '05

15 Feb '05

Jonathan Turkanis wrote: >>> Declaring a function to take an argument of type auto_ptr<...> is >>> one way to signal that ownership is being transfered to the >>> function. It also ensures that the managed object will be deleted, >>> unless the function takes explicit steps to cause a leak. Passing >>> raw pointers defeats this system. >> >> Yes, this is true if you're calling a function that you wrote and >> compiled yourself, but if you're calling a 3rd party API that you >> didn't compile yourself, that can be dangerous (or so I've been told). > > Dangeous how? Actually the opposite is true: if you declare such a function to > take a raw pointer, I'm not an expert with compilers so I'll tell you how it was explained to me. Different compilers could take the same C++ code and compile it into different machine code, causing function pointers to shift. When you pass an object that was compiled on one machine to a function that was compiled on another machine, you can't be sure that the object will be deleted properly. > callers might think they still own the pointer after calling > the function, or the function might not clean up the resource properly. That's what documentation is for. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

2 1

wave use to clarify PP usage
by Larry Evans 14 Feb '05

14 Feb '05

Does anyone have a tool that would clarify what's happening with some PP macros in, for example: boost/spirit/fusion/sequence/tuple.hpp For example, could wave be used to sort-of trace through the macro expansions to make the code easier to understand. For instance, I'm guessing that: BOOST_PP_REPEAT_FROM_TO( 2, FUSION_MAX_TUPLE_SIZE, FUSION_TUPLE_CONSTRUCTOR, _) does for 2 to FUSION_MAX_TUPLE_SIZE what: explicit tuple(typename detail::call_param<T0>::type _0) : base_type(_0) {} Does for a 1 argument CTOR. I could run it through cpp, but if there are several nested macro calls, it probably wouldn't help much in understand what's going on. TIA.

3 2