February 2005 - Boost - lists.preview.boost.org

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

Re: [iostreams] Link errors on msvc-stlport with dynamic runtime
by François Dumont 14 Feb '05

14 Feb '05

This is a MSVC6 bug. When you export a class from a dll the linker try to find all class methods within the import library and of course fails for the template methods. Latest STLport library, the 5.0 beta you can get from CVS using STLPORT_5_0 branch, has a workaround for the std::locale and std::basic_string classes so your library should build fine with this version. Moreover it would be very usefull if boost was using the STLport 5.0 beta library for its unit tests with some platform/compilers. If you are interesting don't hesitate to contact me for information on STLport new features and modifications. Bests > > Message: 10 > Date: Sun, 13 Feb 2005 23:18:19 -0800 > From: "Robert Ramey" <ramey(a)rrsd.com> > Subject: [boost] Re: [iostreams] Link errors on msvc-stlport with > dynamic runtime > To: boost(a)lists.boost.org > Message-ID: <cupj7f$j2b$1(a)sea.gmane.org> > > I have had the exact same problem when building the serialization library > and have found no way around it. I tried definine the template > instantiation in a separate module but it collided with some msvc problem. > > Robert Ramey > > Jonathan Turkanis wrote: > >> >> 1. __declspec(dllimport) public: __thiscall >> locale(locale const&, stateless_null_padded_codecvt*) >>

1 0

Profiling library design change proposal
by christopher diggins 14 Feb '05

14 Feb '05

Preston brought up a good point earlier about the complexity of having the profile_manager being entirely static. What if instead we created profile_manager variables and passed them to the profiler (if desired) something like: profile_manager pm1("profile-group-1", &cerr /* log to cerr */, false /* don't collect stats */, ...); profile_manager pm2("profile-group-2", null /* don't log */, true /* do collect stats */, ...) ; { profiler p("profileA", pm1); ... } { profiler p("profileB", pm1); ... } { profiler p("profileC", pm2); ... } { profiler p("profileD", pm2); ... } pm1.GenerateReport(cout); pm2.GenerateReport(cout); The profiler would still recieve a profiler_manager type as a type parameter: typedef basic_profiler<profile_manager> profiler; And the profile_manager would also still have its type parameters: typedef basic_profile_manager<string, high_resolution_timer, default_stats_policy, default_logging_policy> profile_manager; Any comments or suggestions? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0