- Boost - lists.boost.org

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

[iterators] request for utility iterator
by Thorsten Ottosen 14 Feb '05

14 Feb '05

Hi all, I often want to iterate over just the values of a map or perhaps just the keys of a map. Therefore I would like to see the following iterator adapters in the iterator library: template< class Map > struct map_key_iterator; template< class Map > struct map_value_iterator; template< class Map > struct map_const_value_iterator; I have outlined an implementation in the attached file, but basically it just a wrapper around transform_iterator<typename Map::iterator>. Comments? br Thorsten begin 666 map_value_iterator.cpp M(VEN8VQU9&4@/&)O;W-T+VET97)A=&]R+W1R86YS9F]R;5]I=&5R871O<BYH M<' ^#0H-"G1E;7!L871E/"!C;&%S<R!-87 @/@T*<W1R=6-T('-E;&5C=%]F M:7)S= T*>PT*(" @('1Y<&5D968@='EP96YA;64(a)36%P.CIK97E?='EP928@ M<F5S=6QT7W1Y<&4[#0H@(" @#0H@(" @<F5S=6QT7W1Y<&4@;W!E<F%T;W(H M*2@@8V]N<W0@='EP96YA;64(a)36%P.CIV86QU95]T>7!E)B!R("D@8V]N<W0- M"B @("![#0H@(" @(" @(')E='5R;B!R+F9I<G-T.PT*(" @('T-"GT[#0H- M"G1E;7!L871E/"!C;&%S<R!-87 @/@T*<W1R=6-T('-E;&5C=%]S96-O;F0- M"GL-"B @("!T>7!E9&5F('1Y<&5N86UE($UA<#HZ;6%P<&5D7W1Y<&4F(')E M<W5L=%]T>7!E.PT*(" @( T*(" @(')E<W5L=%]T>7!E(&]P97)A=&]R*"DH M(&-O;G-T('1Y<&5N86UE($UA<#HZ=F%L=65?='EP928@PT*(" @(" @("!R971U<FX@<BYS96-O;F0[#0H@(" @?0T*?3L-"@T* M=&5M<&QA=&4\(&-L87-S($UA<" ^#0IS=')U8W0@;6%P7VME>5]I=&5R871O MPT*<')I=F%T93H-"B @("!T>7!E9&5F(&)O;W-T.CIT<F%N<V9O<FU?:71E M<F%T;W(\('-E;&5C=%]F:7)S=#Q-87 ^+" -"B @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @(" @('1Y<&5N86UE($UA<#HZ8V]N<W1?:71E M<F%T;W(@/@T*(" @(" @("!B87-E.PT*(" @( T*(" @('1Y<&5D968@='EP M96YA;64(a)36%P.CIC;VYS=%]I=&5R871O<B!I=&5R871O<CL-"G!U8FQI8SH- M"B @("!M87!?:V5Y7VET97)A=&]R*"D@.B!B87-E*"D-"B @("![('T-"@T* M(" @(&UA<%]K97E?:71E<F%T;W(H(&ET97)A=&]R('@@*2 Z(&)A<V4H>"D- M"B @("![('T-"@T*(" @(&UA<%]K97E?:71E<F%T;W(F(&]P97)A=&]R/2@@ M:71E<F%T;W(@PT*(" @(" @("!B87-E.CIO<&5R871O<CTH M<BD[#0H@(" @(" @(')E='5R;B J=&AI<SL-"B @("!]#0I].PT*#0H-"G1E M;7!L871E/"!C;&%S<R!-87 @/@T*<W1R=6-T(&UA<%]V86QU95]I=&5R871O M7!E;F%M92!-87 Z.FET97)A=&]R(#X-"GL-"G!R M:79A=&4Z#0H@(" @='EP961E9B!B;V]S=#HZ=')A;G-F;W)M7VET97)A=&]R M/"!S96QE8W1?<V5C;VYD/$UA<#XL( T*(" @(" @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @='EP96YA;64(a)36%P.CII=&5R871O7!E;F%M92!-87 Z.FET97)A M=&]R(&ET97)A=&]R.PT*(" @( T*<'5B;&EC.@T*(" @(&UA<%]V86QU95]I M=&5R871O<B@I(#H@8F%S92@I#0H@(" @>R!]#0H-"B @("!M87!?=F%L=65? M:71E<F%T;W(H(&ET97)A=&]R('@@*2 Z(&)A<V4H>"D-"B @("![('T@(" @ M#0H-"B @("!M87!?=F%L=65?:71E<F%T;W(F(&]P97)A=&]R/2@@:71E<F%T M;W(@PT*(" @(" @("!B87-E.CIO<&5R871O<CTH<BD[#0H@ M(" @(" @(')E='5R;B J=&AI<SL-"B @("!]#0H-"GT[#0H-"@T*=&5M<&QA M=&4\(&-L87-S($UA<" ^#0IS=')U8W0@;6%P7V-O;G-T7W9A;'5E7VET97)A M=&]R(#H@#0H@(" @<'5B;&EC(&)O;W-T.CIT<F%N<V9O<FU?:71E<F%T;W(\ M('-E;&5C=%]S96-O;F0\36%P/BP@#0H@(" @(" @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @('1Y<&5N86UE($UA<#HZ8V]N<W1?:71E<F%T;W(@ M/@T*>PT*<')I=F%T93H-"B @("!T>7!E9&5F(&)O;W-T.CIT<F%N<V9O<FU? M:71E<F%T;W(\('-E;&5C=%]S96-O;F0\36%P/BP@#0H@(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @(" @(" @("!T>7!E;F%M92!-87 Z.F-O;G-T M7VET97)A=&]R(#X-"B @(" @(" @8F%S93L-"B @("!T>7!E9&5F('1Y<&5N M86UE($UA<#HZ8V]N<W1?:71E<F%T;W(@:71E<F%T;W([#0IP=6)L:6,Z#0H@ M(" @;6%P7V-O;G-T7W9A;'5E7VET97)A=&]R*"D@.B!B87-E*"D-"B @("![ M('T-"@T*(" @(&UA<%]C;VYS=%]V86QU95]I=&5R871O<B@@:71E<F%T;W(@ M>" I(#H@8F%S92AX*0T*(" @('L@?0T*#0H@(" @;6%P7V-O;G-T7W9A;'5E M7VET97)A=&]R)B!O<&5R871O<CTH(&ET97)A=&]R('(@*0T*(" @('L-"B @ M(" @(" @8F%S93HZ;W!E<F%T;W(]*'(I.PT*(" @(" @("!R971U<FX@*G1H M:7,[#0H@(" @?0T*?3L-"@T*(VEN8VQU9&4@/&UA<#X-"@T*:6YT(&UA:6XH M*0T*>PT*(" @('1Y<&5D968@<W1D.CIM87 \:6YT+&EN=#X@;6%P.PT*#0H@ M(" @;6%P(&T[#0H@(" @;6%P7VME>5]I=&5R871O<CQM87 ^(&ME>5]B96=I M;B ](&TN8F5G:6XH*3L-"B @("!M87!?=F%L=65?:71E<F%T;W(\;6%P/B!V M86QU95]B96=I;B ](&TN8F5G:6XH*3L-"B @("!M87!?8V]N<W1?=F%L=65? M:71E<F%T;W(\;6%P/B!V86QU95]E;F0@/2!M+F5N9"@I.PT*(" @(" @(" - M"B @("!K97E?8F5G:6XK*SL-"B @("!V86QU95]B96=I;BLK.PT*(" @('9A 3;'5E7V5N9"TM.PT*?0T*#0H-"@`` ` end

1 0

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

13 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. ;) 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. >>> I only looked very briefly, but I don't see how your auto_ptr can be >>> returned from functions. Also, why do you need the m_Owner variable? >> >> Correct me if I'm wrong, but wasn't there a specific reason why the >> STL auto_ptr was made so it couldn't be passed to or returned from a >> function? > > This was true of the initial version. The standard version, which is version 3, > implements a flavor of move semantics (and it doesn't quite work). I'm using the version that comes with Visual C++ 6.0, whatever version that is. >> Anyways, if you want to pass or return the pointer to/from a >> function, just use the .get() or .release() functions. > > But this subverts the resource management system. How? If you pass a pointer to a function, you shouldn't be deleting it inside that function anyways (so pass it with .get()), and if you return a pointer from a function, you can save it in a new AutoPtr so it will get deleted automatically... >> I need the m_Owner variable to tell me if I own the pointer before I >> delete it. > > For auto_ptr, checking that the stored pointer is non-null should be sufficient. I don't set my pointer to NULL when I release() it, I just set m_Owner = false. I've also run some speed comparisons between auto_ptr and AutoPtr and (on Windows at least) they appear to be virtually the same speed when doing the same operations. I'm wondering what the speed comparisons would be between auto_ptr and some of the other smart pointers that you mentioned? Chris Just __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

3 3

[filesystem] Major changes before standardization
by Beman Dawes 13 Feb '05

13 Feb '05

I'm currently working on a major revision of the Boost filesystem library aimed at getting it ready to be proposed to the C++ committee for the next Library TR. The critical technical change required is internationalization. The plan is to provide a templated basic_path class, with typedefs for path and wpath. In other words, an approach very similar to the current std::basic_string, std::string, and std::wstring. Doing this adds a certain amount of complexity compared to the current path class. For example, a path_traits class has to be introduced to give basic_paths on user defined types a way to import the conversions, delimiters, and other traits. To offset the added complexity, I'd like to reduce some of the complexities in the current design: * Eliminate the distinction between native and generic grammars; either would be permitted in all contexts. As well as simplifying the class interface a bit, this will also eliminate a source of user confusion. * Move the name error checking from the basic_path class into stand alone functions. Although the current error checking could be further improved by Peter Dimov's suggested change allowing failure to be treated as either a warning or a hard error, moving it out of the class simplifies the interface, allows full path (rather than name-by-name) error checks, and eases internationalization. The primary downside of these changes will be that users who want path portability checks will have to code calls to checking functions that are currently being called automatically. The internationalization of the library is a big enough change that we will probably want to have at least a mini-review once the changes are complete. Comments? --Beman

12 55

Strange gcc 3.2.2-5.8 behavior
by John Eddy 13 Feb '05

13 Feb '05

The following bit of code gives me an undefined symbol (l1) when using gcc 3.2.2-5.8. Is there something wrong with the code or is there a bug in the compiler or a setting I don't know about, etc? struct S { static const short l1 = 10; }; void go(const short& l) {}; // causes undefined symbol l1 int main(int argc, char* argv[]) { go(S::l1); return 0; } If I do normal, non-in-class-initialization, the problem doesn't appear nor does it appear if I accept the short by value in go. Thanks, John

4 6