- Boost - lists.preview.boost.org

typeof or similar
by Steffen Roeber 25 Feb '10

25 Feb '10

Hi, I have 3 classes: 1. class Base { public: virtual Base *createDerived() { return 0; } }; 2. template <class T> class BaseT : public Base { public: virtual Base *createDerived() { return new DerivedT<T>(); //nicht smart, because DerivedT must be known } }; 3. template <class T> class DerivedT : public BaseT<T> { }; So far so good. Or not. But now the problems are starting. Base *base = new BaseT<int>; This object it created at a place that is not known where I want to create: Base *derived = base->createDerived(); //base is a Base * The result is an object that has the same template type as 'base'. Finally I got my desired result, but the problem is the relation downward relation between BaseT and DerivedT. My preferred way would be something like a factory: class Factory { public: template <class T> static Base *createDerived<T>() { return new DerivedT<T>(); } }; But how can I tell the factory which type to be used. Base *derived = Factory::createDerived<sameAsBase> (base); //base is a Base * I think there is no "normal" C++ language support. But Boost has some methods that by-pass some language constraints. I took a loot at something like 'typeof'. But I don't get the things together. Has anybody any idea? Or is it impossible to do this? Kind regards Steffen

4 3

phoenix docs hidden
by Neal Becker 25 Feb '10

25 Feb '10

In 1.42, there is no link at top level docs to phoenix. It's fairly hidden under spirit. Isn't phoenix intended to be used independently?

2 1

[phoenix] typo in docs
by Neal Becker 25 Feb '10

25 Feb '10

In algorithms doc: for_each(r, c) << Shouldn't that say 'foreach(r, f)' to match this: for_each(begin(r), end(r), f)

1 0

[fusion] make_unfused_generic broken
by Rutger ter Borg 25 Feb '10

25 Feb '10

Hello, apparently the header #include <boost/fusion/functional/generation/make_unfused_generic.hpp> got broken somewhere in the upgrade process, including it yields lots of errors. Boost version 1.42. (replaced with make_unfused?) Cheers, Rutger

2 1

Re: [boost] [msm] scalability
by Christophe Henry 25 Feb '10

25 Feb '10

>Sorry for the delay. That is awesome Christoffe! I've turned off /Gm for >all my projects and my state machine now compiles in the 6-sec range, >and Incredibuild is able to keep the entire compile farm running at >capacity. You shaved >30% off my full build times. Great :) In case your state machines grow bigger, you can also give a try with the "faster compile" policy which I will further improve after inclusion. I think we should make /Gm a forbidden option. I will of course write about it in MSM's doc but it would be interesting to see which libraries also profit from disabling this option and we could add the tip to their doc too. Christophe

1 0

Re: [boost] [Review] ITL review starts today, February 18th
by Jeff Flinn 25 Feb '10

25 Feb '10

Hartmut Kaiser wrote: > Hi all, > > The formal review of the Interval Template Library (ITL) starts today, > February 18th, 2010 and will end February 27th, 2010. ITL is being developed by Joachim Faulhaber. > > ------------------------------------------------ > > About the library: > > The Interval Template Library (ITL) is a library of interval containers that > facilitates computations on collections of intervals and associated values. ... Hmm, not much discussion yet. While this is not my review I'll make a few comments. I was able to port at least my necessary portions of split interval map to CodeWarrior 9.4 and was successful in using it to generate a column coverage graph of what is effectively the columns of possibly large sparse matrices. I would have expected the containers to be templated on an interval type, negating the need for run-time determination of boundtype. With the current design, a rather heavy interval is required with it's boundtype data member. My domain type is a simple int, an index into a row of a sparse matrix. Our in-house Interval class is always right_open, so there is only the need for a begin and end value leading to minimal memory usage. The current library design requires me to convert between ITL intervals and my own application's intervals. I'd have like to be able to provide a model of an interval concept that the ITL container would use. I wasn't able to find any description of the class invariants for interval. For example in our own Interval class the upper/end value must be greater than/equal to the lower/begin value which is a precondition to the constructor taking a pair of domain values. We do provide a static makeNormalized method to produce a proper interval when the order of the domain arguments is unknown, which is not very often in our usage so you don't pay that cost. In my case I hadn't the need for 'reversed' intervals, but I could see that being required for some use cases. Does ITL handle that? Along the same lines I've found little need for the mutators. An interval really only needs default and copy constructors, and one taking the upper and lower values. All mutations merely construct a new interval using calculated values and begin/end values from source intervals. Jeff

6 15

Review of Interval Template Library (ITL) for inclusion
by Eric Jonas 25 Feb '10

25 Feb '10

At the outset, I want to say that I enthusiastically support the inclusion of this library in Boost. I also encourage others without a specific application in mind to check out the library, as there are a lot of fun examples that you might later find useful in other coding projects. My Background -------------- My background: I develop combined hardware and software systems for recording from high-throughput neural systems. One of the primary challenges we face with such systems is the aggressive demands that 10 GB/hour of time-series data places on a typical workstation when you want to visualize it -- especially in real time, with appropriate historical context, at multiple zoom levels. I wrestled with this problem for a great deal of time before settling on various rendering and caching mechanisms. But the number one challenge was efficiently representing the temporal regions that had been viewed, those that had been rendered, and those that had been cached. Then I needed to propagate this state information through a complex dataflow pipeline. ITL solved this problem for me, in a way that honestly freed me from having to think about a lot of the unsavory low-level details. Specifics ------------ All of my work has been on Linux with a modern (4.3+) gcc. I have had collaborators build and use the resulting artifacts on OS X. I originally only anticipated needing interval_sets, but interval_maps became extremely useful as I started to keep track of metadata in my timing epochs. The segregation of interval_* and split_interval_*, while not necessary for my application, provides historical context that I can imagine being useful in some scenarios. What is your evaluation of the documentation? --------------------------------------------- I'd say the documentation was "Boost-quality", but some might see that as pejorative :) The tutorial had me up and running quickly, and the extensive examples helped me map my ideas to the library's primitives. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ------------------------------------------------------------------- I have used this library in production code that I have shipped to users, and have been working with it for several months. What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- For my applications, it was crucial -- they would have been far less optimal (both from a software-engineering and asymptotic perspective) without ITL. The examples showcase a wider range of potential applications, especially the use of an example "Project" as a more complex example. Are you knowledgeable about the problem domain? ------------------------------------------------ As a consumer of many boost libraries for many years, from the simple (shared_tr) to more esoteric (variant) to completely crazy (fusion), I feel like I have a good sense of modern C++ API aesthetic. As someone who spends a great deal (too much) of his life working with time-series data structures, I am familiar with many of the underlying algorithms and data-structures. ...Eric Jonas Eric Jonas (jonas(a)mit.edu) PhD Candidate, MIT Brain and Cognitive Sciences

2 1

[math] long double autoconfiguration
by Vladimir Prus 24 Feb '10

24 Feb '10

Hi, at present, Boost.Math library always tries to compile long long versions of the function, unless explicit --disable-long-long is passed by the user. I have just checked in a patch that attempt to automatically determine if long long is available. Attached is a sample output of "bjam --with-math" build. The detection is done by compiling new file named libs/math/src/long_double_check.cpp -- if it compiles, it is assumed long double works. Unfortunately, I don't really know what kind of long double support Boost.Math needs. John, Paul, could either of you add some more content to that file? This change an SVN version of bjam as of today. If you use an older version, nothing should break, but no auto-detection will be performed. Also, if you need to look at compiler messages produced when compiling the test file, look at bin.v2/config.log Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2 Building the Boost C++ Libraries. Configuration checks summary - long double support : yes Component configuration: - date_time : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : not building - math : building - mpi : not building - program_options : not building - python : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - wave : not building ...patience... ...found 1584 targets... The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /home/ghost/Work/Boost/boost-svn The following directory should be added to linker library paths: /home/ghost/Work/Boost/boost-svn/stage/lib

4 5

virtual function templates
by strasser＠uni-bremen.de 24 Feb '10

24 Feb '10

Hi, is there interest in a boost utility to implement (pseudo-) virtual function templates? real virtual function templates are obviously not possible without a JIT-compiler, but if all derived types are known to the base type, something like the following is. I've used a non-generic form of this a couple of times: struct base : enable_vtemplate<derived1,derived2>{ template<class OutputIterator> void f(OutputIterator it){ BOOST_VTEMPLATE(f,(OutputIterator),(it)); it << "not overridden\n"; } BOOST_SUPPORT_VTEMPLATE(); }; struct derived1 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived1\n"; } BOOST_SUPPORT_VTEMPLATE(); }; struct derived2 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived2\n"; } BOOST_SUPPORT_VTEMPLATE(); }; the runtime overhead besides the virtual call is one switch().

6 9

shortest path between vertex A and B
by Alexandre de Morais Amory 24 Feb '10

24 Feb '10

Hi, I am starting to use BGL. I manage to read/write in dot format, add few attribs, etc. my next task is to get the set of vertex in the shortest path between vertex A and B. In a graph like this: a - b b - c c - d assuming 'a' and 'c', the result would be {a,b,c}. I know it sounds silly, but most similar examples I could find are much more complex than this. I guess breadth_first_search would solve the problem, but I am having trouble with the visitor concept... how to implement a visitor to get the set of vertex in the path between two points. Other features of the problem: I am assuming an undirected graph. all edges have unitary distances. If there are multiple shortest paths between A and B, any of the valid solutions can be returned. thanks in advance for any clue ! Regards, Alexandre Amory

2 1

[thread] compile errors on Sandia-intel-10.1/11.0/11.1
by Emil Dotchevski 23 Feb '10

23 Feb '10

The error below is detected building a couple of Boost Exception tests that use Boost Thread. Thanks Noel and Steven for helping diagnose the problem. "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g -inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_POSIX -I".." -c -o "/Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/intel-darwin-11.1/debug/link-static/threading-multi/pthread/thread.o" "../libs/thread/src/pthread/thread.cpp" ../libs/thread/src/pthread/thread.cpp(385): error: identifier "get_nprocs" is undefined return get_nprocs(); ^ Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[Regex & ICU] boost::regex & icu compilation warnings: missing #pragma pack(pop)
by Henry Tan 23 Feb '10

23 Feb '10

Wondering if this is a known issue and there is a solution to fix this build warning when you are compiling boost::regex with ICU library. >warnings in directory d:\ >d:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp(25) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp(187) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp(38) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp(368) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) Cheers, HT

2 1

[exception] help needed diagnosing Sandia-intel-10.1/11.0/11.1 failures
by Emil Dotchevski 23 Feb '10

23 Feb '10

See the following logs, which seem identical, and it isn't clear to me what's wrong: http://tinyurl.com/yzjo8v4 http://tinyurl.com/ygooqj7 http://tinyurl.com/yjp3n68 Ideas? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 3

[thread][config] VC10RC fails compiling when using thread library (BOOST_NO_RVALUE_REFERENCES)
by Hartmut Kaiser 23 Feb '10

23 Feb '10

Hey all, the new 'un-definition' of BOOST_NO_RVALUE_REFERENCES for VC10 breaks compilation of code using the thread library. Is it a problem of VC10 or the thread library? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

7 16

Re: [boost] Boost Graph library - r_c_shortest_paths
by Andrew Sutton 23 Feb '10

23 Feb '10

> I checked the files I sent you and they were the correct versions (all > three code files: the test file, the example file, and > r_c_shortest_paths.hpp). The test and example files both run without any > problems on my system (WIN XP 32 SP 3, MS Visual C++ 2008). > I've finally had some time to go through the resubmission. There are/were a number of issues that need to be addressed. First, property maps, functors, and visitors are virtually always passed by value. If those objects need to maintain complex state between calls, it's typically done by building a functor (visitor, etc) that has a reference to an external state object. I fixed this. Second, I removed the ks_smart_ptr class, which turned out to be not very smart. It only wrapped the pointer, but didn't manage it in any way. I also cleaned up some of the allocation/deallocation code by moving the calls to two new functions create and destroy. Inidentally, valgrind shows that this implementation leaks memory. I put cout's in create and destroy to count allocations and deletions (16646 allocs to 15994 deallocs). My guess is that one of the rarer code paths in the dispatch doesn't actually delete. This needs to be investigated. Third... just a style point... some of the identifiers are a little long. I think the readability could be improved by shortening them. Fourth, and I'm hoping to get Jeremiah's input on this... I'm not a fan of passing vector<vector<>>& or vector<>& as top-level parameters. It might be better to require a template parameter that is essentially a matrix- or vector-like object. That would simplify the call interface and allow a little more freedom w.r.t. parameter types. Thoughts? Fifth... and Final... The interface to the algorithm is changing which can break backwards compatibility. Maybe we need to give the new module a different name. Thoughts? Here's a tarball with the code ready to be dropped into Boost. You should refer to this version since its what I'm going to be merging. http://www.cs.kent.edu/~asutton/rcsp.tar.bz2 Andrew Sutton andrew.n.sutton(a)gmail.com

2 5

Re: [boost] [msm] scalability
by Christophe Henry 22 Feb '10

22 Feb '10

David Abrahams wrote: > The idea would be to do all parts that are “hard on the compiler” > at runtime. I don't see why you should have to sacrifice features. I promised to make an analysis of which feature costs how much compile-time and test your point. I hope to bring a beginning of an answer and hope you will enjoy the trip to VC++ world ;-) I took the iPod example from the last BoostCon and compile it with VC8 and VC9 in Debug and Release. I think it is an interesting example: submachines, orthogonal regions, a good number of states. I also took the MPLLimitTest example (80 transitions, 80 states) to check a wide state machine not factored into any submachines. Both can be found in the sandbox in libs/msm/doc (/iPod or directly for the MPLLimitTest). So, the results: VC9 (Release): 60s VC9(Debug): 79s VC8(Release): 64s VC8(Debug): 183s (!!!) Notice how debug takes so much longer, as rightly noticed by Jeff. Part1: we now move the submachines into different headers, simply included in the main application. Should change nothing, right? First small surprise, it helps VC8 in Debug: VC9 (Release): 65s VC9(Debug): 80s VC8(Release): 68s VC8(Debug): 166s I didn't see why Debug took so much longer, so I played a bit with the compiler options until I found the culprit. If we now deactivate the /Gm option ("Enable minimal rebuild") in Debug (not activated in Release), we now see a big difference: VC9(Debug): 58s VC8(Debug): 62s Waow! 20s better for VC9, 102 for VC8. This could explain Jeff's problems. This is what I call a successful optimization from the compiler to create a minimal rebuild. Now Debug builds are faster than Release (due to shorter link time if you ask). Part2: This is nice but we did not add any new policy for faster compiling yet. I now add one. Unfortunately, reducing the number of template instantiations proved to be a hard business as most of removed instantiations which were "hard on the compiler" were still done somewhere else and VC is clever enough not to repeat itself. On the MPLLimitTest it gives: Before: VC9(Release): 134s VC9(Debug): 135s (without /Gm. Otherwise count 275!) VC8(Release): crash :( (ok this is really a hard test) VC8(Debug): I stopped after the compiler used up 3,5GB of my 4GB... after: VC9(Release): 84s VC9(Debug): 84s VC8(Release): crash :( VC8(Debug): 153s Ok better. It can be also better for the iPod example as the policy allows you to move some of the metaprogramming for submachines to other TUs and compile with 3 cores (one fsm, 2 submachines) using /MP (available on VC8 and VC9). See in the doc the example in iPod/Part2. We now have the following compile time (using 3 cores): VC9(Release): 44s VC9(Debug): 37s VC8(Release): 50s VC8(Debug):40s This looks much better as it allows the clever user to build submachines and enjoy better compile times. For cases where performance is needed, simply omit the submachines' cpp files from build. The trick works using a boost::any to contain the event, thus allowing you to avoid instantiating a process_event inside the main machine process_event. The only feature you lose with this policy is the new possibility to make a derived event fire his basis event's transition (any can recognize only strict types). So this is the current state. But it can be better. We still pay for the instantiation of submachines into the main machine, which still costs you time. I made a test using a proxy for submachines. The proxy containing only a void* to the real submachine, instantiating it is cheap. It's not finished but we now build on 5 cores (the main fsm, 2 for each submachine, 2 submachines). Yes we can now build a submachine on 2 cores :) This gives us the possible future compile-time: VC9(Release): 34s VC9(Debug): 27s VC8(Release): 40s VC8(Debug):30s I hope this will make the compile-time problem more manageable. Again, more to come on this later. Jeff, if you could give it a try, it would be really great! Christophe PS: I am using a Q6600, 4 cores, 2.4GHz, no hyperthreading. We can soon use the new hexacore with hyperthreading :)

2 1

[geometry] Documentation prototype for review
by Mateusz Loskot 22 Feb '10

22 Feb '10

Hi, I'm working on documentation of Boost Geometry based on Quickbook and I've prepared a prototype: http://mateusz.loskot.net/tmp/ggl/qbk/ What I'm doing is manually porting the content from Doxygen-based (http://geometrylibrary.geodan.nl/) plus restructuring, reformatting and completing it with missing details. I'd like to ask everyone who is interested in Boost Geometry library for comments, impressions and suggestions of improvements. Note, nodes marked with (?) are not finished and empty, but included to give impression about the overall structure. I'd be especially interested comments about the structure, if it's accessible to new users and usable for advanced users at the same time. The Reference is one of the most important section I'd like to master, so please share your comments on the form and completeness of the concepts specification, for example: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/geometries/concept… types description, for example: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/geometries/types/p… and functions description: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/arithmetic/add_poi… Thanks in advance for your feedback. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

3 4

[build] summary at end
by Vladimir Prus 22 Feb '10

22 Feb '10

FYI, Previously, I've made the build process to print information as to where the headers and libraries are to be found. However, that was printed at the start of the build, and many used missed that. I've now checked in a patch to print the message at the end of the build (if there are no errors). You need trunk bjam for this to work. Older bjam will not print that message but otherwise work. The sample wording is as follows: The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /home/ghost/Work/Boost/boost-svn The following directory should be added to linker library paths: /home/ghost/Work/Boost/boost-svn/stage/lib Comments are appreciated, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

1 0

[exception][msvc-7.1] regression and use of member template friends
by JOAQUIN M. LOPEZ MUÑOZ 22 Feb '10

22 Feb '10

Hi, In its current state in trunk, boost/exception/exception.hpp is generating regressions with MSVC 7.1 as shown in: http://tinyurl.com/yckdxrc The problem has to do with some (correct) member template friends declarations that MSVC 7.1 is not able to handle. Lines 222 and ff. of boost/exception/exception.hpp read: #if defined(__MWERKS__) && __MWERKS__<=0x3207 public: #else private: template <class E> friend E const & exception_detail::set_info( E const &, throw_function const & ); [...] To solve the problem the nicest solution would be to replace this by: #if defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) public: #else private: template <class E> friend E const & exception_detail::set_info( E const &, throw_function const & ); [...] But exception.hpp, presumably to speed up compilation times, does not include any other header, so seems like including <boost/config.hpp> just to get this macro could be unacceptable. If this is the case, I suggest that the code be changed so as to simply go public and omit the member template friend declarations altogether. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Status of Boost.Polygon
by Anders Dalvander 22 Feb '10

22 Feb '10

According to the announcement (http://comments.gmane.org/gmane.comp.lib.boost.announce/240) Boost.Polygon library was accepted into Boost on 5 November, provided some of the most critical concerns are addressed first. I cannot find it in the 1.42 release of Boost. When can I expect it to exist in a Boost release? Regards, Anders Dalvander

2 1

[getting started] mention boost.build options for abi tages
by Vladimir Prus 21 Feb '10

21 Feb '10

Often, users are asking how they can get "boost_whatever... mt-s ...", or something like that. The attached patch augments with ABI tags table in the getting started guide with corresponding Boost.Build options. Note that I have more suggested changed (in particular to say that naming on Unix is now different), but wanted to split into individual patches for easier review. I've also dropped stlport iostream option, since it's deprecated and in my understanding nobody uses it any longer. OK to commit? Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

2 1

sp_convertible<> on MSVC10
by Zachary Turner 20 Feb '10

20 Feb '10

I'm using 1.42, not trunk, so I don't know if this has already been addressed, but sp_convertible fails with some errors for me. 2>C:\dev\boost\1.42.0\boost/smart_ptr/detail/sp_convertible.hpp(49): error C2070: 'void': illegal sizeof operand 2> C:\dev\boost\1.42.0\boost/smart_ptr/detail/sp_convertible.hpp(68) : see reference to class template instantiation 'boost::detail::sp_convertible<Y,T>' being compiled 2> with 2> [ 2> Y=error_info_tag_t, 2> T=boost::exception_detail::error_info_base 2> ] 2> C:\dev\boost\1.42.0\boost/exception/info.hpp(159) : see reference to class template instantiation 'boost::detail::sp_enable_if_convertible<Y,T>' being compiled 2> with 2> [ 2> Y=error_info_tag_t, 2> T=boost::exception_detail::error_info_base 2> ] 2> C:\dev\boost\1.42.0\boost/exception/detail/exception_ptr.hpp(170) : see reference to function template instantiation 'const E &boost::operator <<<boost::unknown_exception,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 2> with 2> [ 2> E=boost::unknown_exception, 2> Tag=boost::tag_original_exception_type, 2> T=const type_info * 2> ] 2> C:\dev\boost\1.42.0\boost/exception/detail/exception_ptr.hpp(137) : see reference to function template instantiation 'void boost::unknown_exception::add_original_type<std::exception>(const E &)' being compiled 2> with 2> [ 2> E=std::exception 2> ] 2>C:\dev\boost\1.42.0\boost/exception/info.hpp(159): error C2664: 'boost::exception_detail::error_info_container::set' : cannot convert parameter 1 from 'boost::shared_ptr<T>' to 'const boost::shared_ptr<T> &' 2> with 2> [ 2> T=error_info_tag_t 2> ] 2> and 2> [ 2> T=boost::exception_detail::error_info_base 2> ] 2> Reason: cannot convert from 'boost::shared_ptr<T>' to 'const boost::shared_ptr<T>' 2> with 2> [ 2> T=error_info_tag_t 2> ] 2> and 2> [ 2> T=boost::exception_detail::error_info_base 2> ] 2> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called The line it's pointing to is this: enum _vt { value = sizeof( f( static_cast<Y*>(0) ) ) == sizeof(yes) }; and in particular it's having a problem determining the return type of f( static_cast<Y*>(0) ). It's thinking that whatever overload it's finding for f() here returns type void. Which doesn't make sense neither one returns void. Any ideas? Zach

5 8

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 20 Feb '10

20 Feb '10

> > The documentation lists the following sequence for executing a constructor: > > > > 1. Initialize member variables via the constructor member > > initialization list (if such a list is specified). > > 2. Check preconditions (but not invariants). > > 3. Execute constructor body. > > 4. Check invariants. > > 5. Check postconditions. > > > > I believe, one of the reasons for validating arguments of a constuctor > > is to not allow the incorrect values to initialize objest's > > sub-objects (members). I believe the sequence of the first two items > > should be inverse. Am I wrong? > The library follows Eiffel semantics for constructor which is {Default > AND Pre}Body{Post AND Inv} where Default is default initialization of > members (similar to C++ member initialization list). That said, it > would be difficult to implement a different semantics (like the one > you suggest) in C++ because of the lack of delegating constructors. The sole fact that other language implements it this way is not sufficient an argument. I can think of the situation when "Eiffel order" may cause damage that the inverse order might have prevented: Type::Type( int & counter ) precondition{ counter < MAX; } : handle( irreversibleChange(int--) ) { ; } Suppose the constructor of Type is called, and the value of counter is MAX. This value is invalid, but by the time the precondition is checked, the irreversibleChange is executed, and the value of counter is reduced, so the assertion concludes that everything is fine. Now, the argument that it is difficult to implement is convincing; it may be that it is impossible at all. But I would call not having the {Pre->Init} order a limitation of the library. Let me be clear: one tiny limitation in the great library, because out of many attempts to provide contract programming to C++ I have seen, this is the only one that really looks good. Regards, &rzej

2 1

[mpi] Documentation patch
by Number Cruncher 19 Feb '10

19 Feb '10

Attached is a patch (against 1.42) to fix a couple of minor errors with the Doxygen documentation for some headers in the boost/mpi library. The errors relate to Doxygen usage, not content. Simon.

1 0

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 19 Feb '10

19 Feb '10

Hi, two other questions that came to my mind, regarding the library design. (1) Sometimes the assertions execute longer than the function itself. For example: iterator find( iterator begin, iterator end, value v ) precondition { is_sorted( begin, end ); } { return find_sorted( begin, end, v ); } find_sorted has logarithmic complexity, whereas is_sorted has linear one. If I use function find like this: sort( begin, end ); process( find(begin, end, A) ); // call is_sorted process( find(begin, end, B) ); // call is_sorted process( find(begin, end, C) ); // call is_sorted is_sorted is called many a time. Even if I am in debugging mode but use a medium size range, the performance can kill me. I would like to disable checking of this assertion, but at the same time there is no reason to disable others. Would you consider providing a way to selectively disable asserts? some assertion level? (2). Usually public member functions would be used to express DbC assertions. Do you disable assertions in public functions that are called only to evaluate other assertions in order to avoid recursive calls? Regards, &rzej

2 1