- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1242266 ] Move comments in BOOST_STATIC_CONSTANT
by SourceForge.net 22 Jul '05

22 Jul '05

Bugs item #1242266, was opened at 2005-07-21 05:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1242266&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: type_traits Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: Move comments in BOOST_STATIC_CONSTANT Initial Comment: There appears to be some comments in one of the macro function calls of BOOST_STATIC_CONSTANT (line 124 of "type_traits/is_enum.hpp): BOOST_STATIC_CONSTANT(bool, selector = (::boost::type_traits::ice_or< ::boost::is_arithmetic<T>::value , ::boost::is_reference<T>::value , is_class_or_union<T>::value // However, not doing this on non-conforming compilers prevents // a dependency recursion. >::value)); This is not incorrect but it expands to incorrect code in case you run the Visual Studio.NET 2002/2003/2005 C++ compiler with the compiler options "/E /C". The result after preprocessing is: // However, not doing this on non-conforming compilers prevents// a dependency recursion.enum { selector = (::boost::type_traits::ice_or< ::boost::is_arithmetic<T>::v alue , ::boost::is_reference<T>::value , is_class_or_union<T>::value >::value) }; which obviously hides the definition of "selector"! Since we are performing code checking on the preprocessed file our code checker is unable to check C++ files that contain "is_enum.hpp". This is clearly a bug in the Visual Studio C++ compiler, but my hopes are that the comments can be moved in Boost, e.g. towards the start of the macro function call or the end. This will solve the problem of being able to code check this file. It might solve problems with other preprocessors as well. In case you need further details, contact me at Paul.Jansen(a)tiobe.com. Regards, Paul Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1242266&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

[serialization] bug in latest change to boost/serialization/base_object.hpp
by JOAQUIN LOPEZ MU?Z 22 Jul '05

22 Jul '05

Hello, A change to boost/serialization/base_object.hpp made 10 hrs ago is currently breaking virtually every Boost.MultiIndex test in every platform: as of now, already four engines are showing the problem, see for instance http://tinyurlcom/ccaqx. More will come. The bug is silly enough, some names are not declared but used when boost/serialization/base_object.hpp is included without having previously included any of boost/archive/*.hpp. Please somebody fix this, currently I don't have CVS access, can't do it myself. I don't want to sound harsh, but it is my humble opinion that this kind of trivial bugs should be checked against before commiting to the CVS. For the record, a similar problem (undeclared stuff if no archive header is included) popped up some weeks ago in exactly the same fashion, current vacpp results (not updated since quite some time) are a sad memory of that bug, see http://tinyurl.com/7tyda. This would be trivially detected before commiting if only a test would be added to Boost.Serialization testsuite that merely included serialization headers but no archive headers. No current test is doing that (except mine :) which is a serious hole wrt to source code coverage, as we're seeing now. Anyway, now it's too close to 1.33, maybe this suggestion could be taken into consideration after release. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[serialization] Building for Borland problem
by Edward Diener 22 Jul '05

22 Jul '05

I downloaded the standalone Spirit 1.62 and put it in a directory of my machine. I set SPIRIT_ROOT to that directory in my environment. I then used bjam to build my Boost libraries for Borland and Bcb6. The serialization build reports errors from the spirit/core/config.hpp in my Boost 1.32 directory tree that my compiler is not supported. Of course I was expecting it to pick up Spirit files from my SPIRIT_ROOT directory tree. Why is this not working correctly ?

1 0

random_test regressions (and some solutions)
by John Maddock 22 Jul '05

22 Jul '05

I've tracked down the cause of the random_test failures with some Win32 compilers (Borland and Intel 8 and 9 certainly). Within the test, the random number generator gets passed around by value when constructing a variate_generator. However there are a couple of generators that contain large arrays of long's (the mersenne twister is the first to be tested that has this problem). It's reasonably well known that on Windows, copying large arrays on the stack can overrun Window's stack protection and growth mechanism, resulting in the program trying to write to an invalid address. For the Borland compiler, adding: <linkflags>-lS:8000000 <linkflags>-lSc:8000000 Fixes the regression. For Intel adding: <linkflags>-STACK:8000000:8000000 Works most of the time, but seems to be a bit capricious (it appears you have to delete all temporary linker files before attempting the link, otherwise strange things happen). I'm not even sure if this is the right fix: should we really be passing such large arrays around on the stack in the first place? John.

2 2

[Boost-bugs] [ boost-Bugs-1242857 ] Can't delete automatically in circularly included object.
by SourceForge.net 22 Jul '05

22 Jul '05

Bugs item #1242857, was opened at 2005-07-22 00:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1242857&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: Can't delete automatically in circularly included object. Initial Comment: hi,all: I am a chinese student.Please forgive me because of my poor english. I found an error on smart pointer shared_ptr when i add an shared_ptr object to itself. The code is below.Class StatusBase is a subclass of Status.There is a method name addEventResult in class StatusBase. As you can see, EventResult is an object which made up of object Status( StatusBase actually because of Status is an abstract class ),Action and Event.In the case, I try to let them passed in share_ptr wrpper whenever in constructor or normal method.As my opinion,I think that will not be error and when I exit my program it will free the memory for me automatically. But in fact it will not. shared_ptr<Status> A( new Status() ); shared_ptr<Event> B( new Event() ); shared_ptr<Action> C( new Action() ); shared_ptr<EventResult> ABC( new EventResult( A, B, C ) ); //the row below will result the object A can't be released, so as to the object ABC , B and C A.addEventResult( ABC ); //next is about the decleartion of StatusBase and EventResult. For class Event and Action, it is the history. class StatusBase : public Status //{{{ { public: StatusBase(){} virtual ~StatusBase(){} public: int getEventResultCount() const ; boost::shared_ptr<EventResult> getEventResult( int index ) const ; void addEventResult( const boost::shared_ptr<EventResult>& v ) ; private: std::vector< boost::shared_ptr<EventResult> > events ; }; //}}} class EventResult : public pqkit::Object //{{{ { public: EventResult( const boost::shared_ptr<Event>& e, const boost::shared_ptr<Action>& a, const boost::shared_ptr<Status>& s ) : event(e),action (a),newStatus(s){} virtual ~EventResult() {} public: virtual const std::string toString() const { return Object::toString() ; } virtual const pqkit::Class getClass() const { return pqkit::Class("EventResult","inhert:Object->EventResult"); } boost::shared_ptr<Event> getEvent() const { return event; } boost::shared_ptr<Action> getAction() const { return action; } boost::shared_ptr<Status> getNewStatus() const { return newStatus; } private: boost::shared_ptr<Event> event ; boost::shared_ptr<Action> action ; boost::shared_ptr<Status> newStatus ; }; //}}} yours JinheZeng at GDUT from China. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1242857&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Random] Mersenne Twister initialization problem [PATCH]
by Tiago de Paula Peixoto 21 Jul '05

21 Jul '05

Hi. The Mersenne Twister RNG was updated by the original author in 2002, because of a small problem in the seeding procedure, which was that the most significant bit of the seed was not well reflected to the state vector. Read http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html for more details. The version implemented in Boost is the original 1998 one, which contains the problem. The attached patch implements the new seeding procedure, which uses something different than the linear congruential RNG to initialize the state vector. I haven't identified the new procedure to match any generator already implemented in Boost, so I just wrote it there (please correct me if I'm wrong). I have compared the output to the official implementation output, and it's identical. If the patch is OK, could it be applied? Thanks. -- Tiago de Paula Peixoto <tiago(a)forked.de>

4 5

enable_if for partial specialization of fnc
by Neal Becker 21 Jul '05

21 Jul '05

I have a question on usage of enable_if for faking partial specialization of function templates. Suppose I have a func F that has a general implementation, and a partial specialization for std::complex<T>. The obvious way to do this is to forward to a class member: template<typename T> struct F_impl { void DoF (); }; template<typename T> struct F_impl<std::complex<T> >{ void DoF (); }; template<typename T> void F () { F_impl<T>(); } Alternatively, I can define is_cmplx: template<typename T> struct is_cmplx { static const bool value = false; }; template<typename FLT> struct is_cmplx<std::complex<FLT> > { static const bool value = true; }; And use enable_if/disable_if. Both work. My question is, why would I prefer one over the other approach?

2 1

Links to deprecated and outdated mailing archives
by Pavel Chikulaev 21 Jul '05

21 Jul '05

Hi all, There is a link to deprecated mail archive MailMan Archive http://lists.boost.org/MailArchives/boost/ (That page explicitly says that it's deprecated and there is no new messages since 2 April 2005) at http://boost-consulting.com/boost/more/mailing_lists.htm#main. Also page http://www.mail-archive.com/boost%40lists.boost.org/ mentioned at the same page at boost.org doesn't seem up to date (Last message dated 4 September 2003). These links should be removed isn't it? And search from the home page at doesn't look working good - it seems like it actually searching all the archives (they should be identical isn't?) and sometimes a search lead to these archives. This should be changed IMO. -- Pavel Chikulaev

1 0

Re: [boost] singleton_ptr
by cedric.venet 21 Jul '05

21 Jul '05

> > > > struct MySingletonCategory; > > > > // must provide specializations in singleton namespace > > namespace boost { namespace singleton { > > > > // the following specifies that multi threading will be used for > > singletons which use MySingletonCategory > > template < > > > struct threading_policy < MySingletonCategory > > > { > > typedef multi_threaded type; > > }; > > This should be called *trait* not a policy. Policy is type orthogonal. And > btw I don't think traits-based solution will work here. I most definitely > may want different threading policies for the same singleton type in > different circumstances. > why not simply pass the category as a template parameter: struct MyCategory ; namespace boost { namespace singleton { template < > struct threading_policy < MyCategory > { typedef multi_threaded type; }; } } // close namespace void test ( ) { singleton_ptr < MySingletonType,MyCategory > ptr; } you can have the same category for many type but also many category for one type. if you really want no policy in the type declaration, you can provide a default who would search for a type declared category as in your code (I am not very understandable I think, perhaps the following code while be more explicit): struct defaultcategory; tempate< class T, class category_param = defaultcategory > class singleton_ptr { typedef mpl::if< mpl::IsSame<category_param,defaultcategory>, category<T>::type, category_param>::type the_category; ... }; the syntaxe is perhaps not correct but it's the principe who count. so you can use: struct another_type; template<> category<another_type> { typedef MT_category type; }; int main() { singleton_ptr<MyType> a_defaut_singleton; singleton_ptr<another_type> a_MT_singleton; singleton_ptr<MyType,MT_category> another_MT_singleton; } perhaps it don't work, or it's stupid, but perhaps it can help you. And sorry for my poor english. you can also want to read the papers here: http://www.prakinf.tu-ilmenau.de/~czarn/cpe2000/ --(space [webmail cut my space :( ) Cédric Venet ECP student Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn)

2 1

[Threads] incorrect citation
by David Abrahams 21 Jul '05

21 Jul '05

"Concurrent Programming Concepts" is incorrectly cited as having been published in 1983. It was '73. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0