May 2004 - Boost - lists.preview.boost.org

[assert_no_intrinsic_wchar_t] What the...?
by David Abrahams 20 May '04

20 May '04

The logic used here seems to be completely and totally broken. Was it even tested? config/compiler/intel.hpp first says: #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else ... #endif So if I have intel6, BOOST_NO_INTRINSIC_WCHAR_T is now set. Then config/compiler/intel.hpp goes on to say: #if defined(BOOST_NO_INTRINSIC_WCHAR_T) #include <cwchar> template< typename T > struct assert_no_intrinsic_wchar_t; template<> struct assert_no_intrinsic_wchar_t<wchar_t> { typedef void type; }; // if you see an error here then you need to unset BOOST_NO_INTRINSIC_WCHAR_T: typedef assert_no_intrinsic_wchar_t<unsigned short>::type assert_no_intrinsic_wchar_t_; #else ... #endif So, if I get the error, how exactly am I supposed to "unset BOOST_NO_INTRINSIC_WCHAR_T" before the error occurs? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 11

seiralization of shared_ptr
by Robert Ramey 20 May '04

20 May '04

Some time ago the question was raised on this list as to why it was necessary to access share_count in order to implement serialization of shared_ptr. At the time I didn't have an answer. So I went back and tried to re-implement it and have come to the following point beyond which I can't proceed without manipulating shared_count directly. ///////////////////////////////////////////////////////////// // implement serialization for shared_ptr<T> template<class Archive, class T> inline void save( Archive & ar, const shared_ptr<T> & t, const unsigned int /* file_version */ ){ ar << boost::serialization::make_nvp("px", t.get()); } template<class Archive, class T> inline void load( Archive & ar, shared_ptr<T> & t, const unsigned int /* file_version */ ){ // object tracking guarantees that pointers are not replicated // on loading. T * t_new; ar >> boost::serialization::make_nvp("px", t_new); // if its not the first time, it should be equal to the current pointer assert(0 == t.use_count() || t.get() == t_new); // assign new pointer or bump reference count as appropriate // ???? - what goes here? } Can anybody tell me "what goes here?" Robert Ramey

3 2

Is there interest in a decimal floating-point class?
by Richard Kaiser 20 May '04

20 May '04

I want to ask the boost community if there is interest in a decimal floating-point class implementing one or more of the decimal floating-point types that are intended to become part of a future C and C++ standard. This class would be a wrapper class around Mike Cowlishaws decNumber C library. You can take a look at my first preliminary version (it is just a first try, the design is far from perfect, it is incomplete, its notation is inconsistent and not according to boost conventions) at http://www.rkaiser.de/rkaiser/DecFPClass/DecFPClass.html Most of its operators work as they should do, and most of Mikes testcases pass successfully. The function DecimalFloat_Testcases("d:\\cpp.boo\\decnumber\\decnumberclass\\decTest\\") in my test program test_rk reads all the testcases from Mikes decTest files and logs each testcase in a file (bcb files were created with Borland C++Builder 6, gcc with MinGW g++, and msc with MS Visual Studio .Net). With “grep "###number" *.log” you get the summary lines: File abs.decTest_bcb.log: ###number of tests passed=87 failed=2 File abs.decTest_gcc.log: ###number of tests passed=87 failed=2 File abs.decTest_msc.log: ###number of tests passed=87 failed=2 File add.decTest_bcb.log: ###number of tests passed=773 failed=45 File add.decTest_gcc.log: ###number of tests passed=773 failed=46 File add.decTest_msc.log: ###number of tests passed=773 failed=45 ... If the boost community is interested, if I find enough time, and if everything works as intended, the resulting classes would be a reference implementation for the new standard decimal floating point types, or at least a close one. I posted this request already some days ago, but by mistake I have posted it as a reply to a message it did not belong to. Sorry. Richard Kaiser

1 0

RE: [boost] basic_string interface generator
by Reece Dunn 20 May '04

20 May '04

Darryl Green wrote: > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Reece Dunn > > > > Is there any interest in the ability to generate a > > basic_string compliant > > interface from a base set of functions in a similar way that > > the iterator > > adaptors work? > >Yes, though I'm not sure yet that the flex_string policy based approach >wouldn't work just as well. I guess if this capability is at least an >implementation detail of your fixed_string you can easily make it >available for review/comparison. If you do, I will certainly give it a >go and post a review of that feature (I'm interested in fixed_string >anyway). I am working on it now. It is available in the sandbox (boost/fixed_string/detail/basic_string_impl.hpp) along with an experimental implementation of fixed_string (boost/fixed_string/fixed_string.hpp). Note that the current implementation is still available as char_string.hpp. Comments and feedback are always welcome. NOTE: This is still very much a work-in-progress. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

1 0

Fwd: Bug#245390: libboost-graph-dev: A different example in the boost dist doesn't compile
by Domenico Andreoli 20 May '04

20 May '04

hi, as most of you have already understood, today is the debian bugs reporting day :) here we have another report, #245390 [0]. it is easily reproducible alson on a i386 box. anybody has already seen it? thanks domenico [0] http://bugs.debian.org/245390 ----- Forwarded message from Bogdan Oporowski <bogdan(a)math.lsu.edu> ----- Date: Thu, 22 Apr 2004 16:44:37 -0500 From: Bogdan Oporowski <bogdan(a)math.lsu.edu> To: Debian Bug Tracking System <submit(a)bugs.debian.org> Reply-To: Bogdan Oporowski <bogdan(a)math.lsu.edu>, 245390(a)bugs.debian.org Subject: Bug#245390: libboost-graph-dev: A different example in the boost dist doesn't compile Package: libboost-graph-dev Version: 1.31.0-4 Severity: normal This example is isomorphism.cpp, and gives: /usr/include/boost/graph/isomorphism.hpp:111: error: invalid conversion from ` void* const' to `int' as the final message in a huge error. I can attach the entire error if you need it, but otherwise don't want to waste a lot of space if you can reproduce it locally. ----- End forwarded message ----- -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

2 3

Regex Token Iterator Warning
by Stephan T. Lavavej 20 May '04

20 May '04

John Maddock, I love regex_token_iterator's vector<int> constructor - it fits my needs perfectly! However, my use of it is generating a trivial warning that should be fixed. Using Boost CVS 20040427, in boost/regex/v4/regex_token_iterator.hpp, the member flags is declared on Line 59: match_flag_type flags; And the member subs is declared on Line 62: std::vector<int> subs; However, they are initialized in a different order in the constructor on Lines 67-68: regex_token_iterator_implementation(const regex_type* p, BidirectionalIterator last, const std::vector<int>& v, match_flag_type f) : end(last), pre(p), subs(v), flags(f){} This upsets my ninja warning options on gcc 3.3.3, since members should appear in an initialization list in the same order that they are declared, for safety reasons. There may be other initialization order warnings lurking in the code that my program does not yet trigger. I am always impressed with your prompt attention to my regex issues; thanks again for the hard work! Stephan T. Lavavej http://nuwen.net

2 1

Sleep(1) in spinlock in lwm_win32.hpp
by Aaron W. LaFramboise 20 May '04

20 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I was doing some research on implementing fast mutexes in Windows for GCC, and in the course of doing various sorts of benchmarks, I came across something very disturbing. I've noticed a lot of discussion of the Windows spinlocks before, but I don't think this came up. By default on Windows when using lightweight mutexes, Boost acquires and releases a spinlock using this code: ~ explicit scoped_lock(lightweight_mutex & m): m_(m) ~ { ~ while( InterlockedExchange(&m_.l_, 1) ) ~ { ~ // Note: changed to Sleep(1) from Sleep(0). ~ // According to MSDN, Sleep(0) will never yield ~ // to a lower-priority thread, whereas Sleep(1) ~ // will. Performance seems not to be affected. ~ Sleep(1); ~ } ~ } ~ ~scoped_lock() ~ { ~ InterlockedExchange(&m_.l_, 0); ~ // Note: adding a yield here will make ~ // the spinlock more fair and will increase the overall ~ // performance of some applications substantially in ~ // high contention situations, but will penalize the ~ // low contention / single thread case up to 5x ~ } First, I verified the claim that Sleep(1) yields to low-priority threads, and this is, in fact, true. However, when benchmarking, I noticed that it in fact sleeps slightly more than 10ms by default on Windows XP! Other platforms seem to have similar results. This is a very long time. Using timeBeginPeriod(), it is possible to lower this to 1ms, but in no case when Sleep has a positive parameter will Windows sleep for a period shorter than this. Unfortunately, timeBeginPeriod() is part of of mmsystem and on every compiler I am familiar with, requires linking against an additional import library, winmm. This may or may not be a big deal. In any case, the present code seems very suboptimal, and in some situations, it could be ridiculously slow, compared to the standard Windows synchronization primatives it is working so hard to avoid. I would suggest that if there were another Boost release that included this code, the situation involving this spinlock would need to be documented somewhere obvious. I think, though, that we could trivially improve this code without too much effort and without compromising its goals. In particular, the loop could spin for a while using Sleep(0), which is orders of magnitude faster, before falling back to Sleep(1)--presumably because a thread of lower priority holds the lock. This should eliminate 90% of the practical problem, but definitely is not a perminant solution. Aaron W. LaFramboise -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFArHA7lp/lhnWsM8QRAganAJ9tW7F8axtjSeTqp9ZDmXKuNb2a3QCgl1ZO 4CMavVQnkH7DNtZmd4Fitgw= =te8D -----END PGP SIGNATURE-----

1 0

RE: [boost] Re: static sized strings
by Reece Dunn 20 May '04

20 May '04

John Nagle wrote: > With no base class for all fixed_string types, though, >there's no way to pass fixed_string objects around, short >of templating every function that uses them. > > A base class seems to be needed. Otherwise, there's >no direct replacement for "char *" arguments. I have uploaded an initial version of this. I wanted to wait before I approached the base class concept for two main reasons: (a) I wanted to move the interface closer to that of std::basic_string and (b) I wasn't sure how to implement it as a template on character type. The interface names have been moved to the corresponding basic_string/STL names (assign, append, etc.). The approach I have used for the base classes retains the template on character type, using MPL machinery to select the appropriate base class. Note that this is not perfect, since I still need a constraint to limit CharT to char and wchar_t, or provide an additional template parameter that defaults to the MPL machinery, allowing you to provide your own interface for custom string types. > Here's a simple test program. It should be possible >to do the common operations done here. That doesn't >seem possible with the latest version in the Boost >sandbox. This should work with the appropriate name changes: boost::char_string is now boost::fixed_string (although it still currently resides in fixed_string/char_string.hpp); boost::char_string_base is boost::char_string for readability; boost::wchar_string_base is boost::wchar_string for readability; Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2

RE: [boost] basic_string interface generator
by Darryl Green 20 May '04

20 May '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Reece Dunn > > Is there any interest in the ability to generate a > basic_string compliant > interface from a base set of functions in a similar way that > the iterator > adaptors work? Yes, though I'm not sure yet that the flex_string policy based approach wouldn't work just as well. I guess if this capability is at least an implementation detail of your fixed_string you can easily make it available for review/comparison. If you do, I will certainly give it a go and post a review of that feature (I'm interested in fixed_string anyway). Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0

RE: [boost] seiralization of shared_ptr
by Rozental, Gennadiy 19 May '04

19 May '04

> Some time ago the question was raised on this list as to why > it was necessary to access share_count in order to implement > serialization of shared_ptr. At the time I didn't have an answer. > > So I went back and tried to re-implement it and have come to > the following point beyond which I can't proceed without > manipulating shared_count directly. > > ///////////////////////////////////////////////////////////// > // implement serialization for shared_ptr<T> > > template<class Archive, class T> > inline void save( > Archive & ar, > const shared_ptr<T> & t, > const unsigned int /* file_version */ > ){ > ar << boost::serialization::make_nvp("px", t.get()); > } > template<class Archive, class T> > inline void load( > Archive & ar, > shared_ptr<T> & t, > const unsigned int /* file_version */ > ){ > // object tracking guarantees that pointers are not replicated > // on loading. > T * t_new; > ar >> boost::serialization::make_nvp("px", t_new); > // if its not the first time, it should be equal to the current pointer > assert(0 == t.use_count() || t.get() == t_new); > // assign new pointer or bump reference count as appropriate > // ???? - what goes here? > } > > Can anybody tell me "what goes here?" > > Robert Ramey I don't see problem where you see it. I ses problem in different place. How is it possible that t.use_count() != 0? My understanding that before loading all data is empty and you never actually load the same variable twice. struct A { shared_ptr<int> member; load(...) { ar >> member; } }; A a1, a2 ar >> a1; ar >> a2; Now the real problem lies IMO in a fact that you need to keep map raw ptr -> corresponding shared_ptr. IOW when you got raw ptr and you need to create shared ptr for it you need to figure out somehow whether you already did it. If yes you need to make a copy to that shared_ptr. If not create new and register it. Gennadiy.

1 0