- Boost - lists.boost.org

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

boost::rtl / rel where can I get some more infos
by Vinzenz Feenstra 14 Feb '05

14 Feb '05

Hi Arkadiy a friend told me about boost::rtl/rel, so I was wondering where I can get some more infos about it, it sounds quite interessting. BR Vinzenz

5 18

serialization - questionable basic_xml_oarchive dtor
by Sergey Skorniakov 14 Feb '05

14 Feb '05

Hello, All! I think that basic_xml_oarchive destructor can be more safe if uncaught_exception examination will be added, because put sometimes can throw exceptions: template<class Archive> basic_xml_oarchive<Archive>::~basic_xml_oarchive(){ if(!header) return; if (!std::uncaught_exception()) this->This()->put("</boost_serialization>\n"); } With best regards, Sergey.

2 2

[shared_ptr] Optimization suggestion
by Don G 14 Feb '05

14 Feb '05

Hi All, For my own work in the thread-safe smart pointer arena, I have used a technique to reduce the number of mutex objects from one per object, yet minimize induced contention. The basic idea is a static pool of mutexes indexed by hashed pointers. Or in pseudo code: mutex & get_object_mutex (const void * p) // see below { const size_t pool_size = 127; static mutex pool[mutex_pool_size]; unsigned long ul = reinterpret_cast<unsigned long>(p); unsigned long hash = ...; // munge ul in some clever way return pool[ hash % pool_size ]; } class foo { public: void bar () { #ifdef BOOST_HAS_THREADS mutex::scoped_lock guard(get_object_mutex(this)); #endif // ... do something ... } }; This is a tad simplified. For example, I used my Singleton template to manage the pool, but the idea is the same. Instead of allocating one mutex per object that might need one, allocate a pool of them and hash the object's pointer so that all references to the same object use the same mutex. Has anyone considered using this technique in shared_count? The extra contention could be controlled by the sizeof the pool, and it would be a big savings where lots of objects are used. It would also be better than the lightweight_mutex used on some platforms (such as Windows) to achieve similar savings. At least that would be so if the mutex used where a CRITICAL_SECTION and not a kernel mutex. Best, Don ===== __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

singleton allocators
by Jason Hise 14 Feb '05

14 Feb '05

In my code, I use the term allocator for policies that mirror the Loki singleton creator policies. For example, my dynamic_allocator class maps almost directly to Alexandrescu's CreateUsingNew policy. It has been suggested that allocator is a misleading term, because users will think that such classes were meant to work with the allocator policy used in the standard containers. Is the term allocator really that misleading? Should I make the massive change in my code to refer to these classes as creators? -Jason

2 1