February 2010 - Boost - lists.preview.boost.org

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

17 Feb '10

> > it is inevitable, etc., but.. read on. I know at least one library in > > Boost that also spoils function declarations in order to provide > > additional functionality: Concept Check library; they may be others > > too (MPL?). > > My suggestion is that if there are (or will be) libraries that require > > spoiling function declarations, they should all provide the same > > "spoiled" syntax. Otherwise I will be always asking "how do I declare > > a function in this library?". It would be very convenient if Boost > > provided one alternative function definition syntax that when used > > would enable all its libraries to work. > > I agree. However, in the past I did look into harmonizing my library > API with the ones of Boost.ConceptCheck and/or Boost.Parameter but it > did not seem feasible... I will double check it. This is not only about clarity. As a super-correct programmer I may want to apply both concept checking and pre-/post-conditions checking to my functions. Perhaps, if the 'compromise' syntax is possible, it requires changing concept-checking library. Regards, &rzej

1 0

[variadic_templates][mpl]interest in compile time matrix multiplication?
by Larry Evans 17 Feb '10

17 Feb '10

For example, with: > ***domain_matrix: > ( 11 12 13 ) > ( 21 22 23 ) the following: > typedef > outer_product_pack > < plus_times_row_column<arg<1>,arg<2> > > >::apply > < domain_matrix > , domain_matrix > >::type > outer_plus_times_rows_rows; > > std::cout<<"***outer_plus_times_rows_rows:\n"; > for_each<outer_plus_times_rows_rows>(printer); produces: > ***outer_plus_times_rows_rows: > ( 434 794 ) > ( 794 1454 ) The plus and times operations can be replaced with any compile-time binary operation. Any interest? -regards, Larry

4 4

[Boost][gsoc]Intrest - big integer library
by Kamil Witecki 17 Feb '10

17 Feb '10

Hello all, I'd like to propose new library for boost - a Big Integer library. Boost has plenty of applications build upon it and some of them has to use integers greater that those ensured by C++ standard. What is more some of them needs even Pythonlike "unbounded" integers. What I am proposing is library implementing cross-platform library supporting such integers working as standard arithmetic type. Is it a good proposal for GSoC project and who would you recommend as a possible mentor for such project? Pozdrawiam, Kamil Witecki.

10 10

[Boost.Preprocessor] FOREACH( MACRO, ... )
by Daniel Larimer 17 Feb '10

17 Feb '10

Is there a reason why Boost.Preprocessor does not have many (any?) utilities for variadic macros? I have implemented a FOREACH( MACRO, ... ) that results in the following expansion MACRO(ARG1) MACRO(ARG2) ... Implemented as such: #define FOREACH_ARRAY( ... ) (PP_NARG(__VA_ARGS__) , ( __VA_ARGS__ ) ) #define FOREACH( A, ... ) BOOST_PP_REPEAT( PP_NARG(__VA_ARGS__), A, FOREACH_ARRAY(__VA_ARGS__) ) #define CASE(z,n,data) case BOOST_PP_ARRAY_ELEM( n, data ): FOREACH( CASE, a, b, c, d, e) case a: case b: case c: case d: case e: Depends upon this macro: #define PP_NARG(...) \ PP_NARG_(__VA_ARGS__,PP_RSEQ_N()) #define PP_NARG_(...) \ PP_ARG_N(__VA_ARGS__) #define PP_ARG_N( \ _1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \ _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \ _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \ _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \ _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \ _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \ _61,_62,_63,N,...) N #define PP_RSEQ_N() \ 63,62,61,60, \ 59,58,57,56,55,54,53,52,51,50, \ 49,48,47,46,45,44,43,42,41,40, \ 39,38,37,36,35,34,33,32,31,30, \ 29,28,27,26,25,24,23,22,21,20, \ 19,18,17,16,15,14,13,12,11,10, \ 9,8,7,6,5,4,3,2,1,0

3 4

[thread] thread_specific_ptr, dangerous conflation of identity and address
by Edd Dawson 16 Feb '10

16 Feb '10

Hi folks, A thread_specific_ptr appears to use its own address as a key. For example, the two tss objects created below will likely share the same key: void f() { thread_specific_ptr<int> ptr; // ... } int main() { f(); f(); } When thread_specific_ptr's destructor is called, it does a reset() which clears the data for the thread doing the destruction. However, data for other threads still remain. I find this asymmetric behaviour a little strange. Why should all threads but one see their old data? The bigger problem though, is that it might not be *their* old data. It can just as easily be someone else's old data due to coincidental alignment of different thread_specific_ptrs on the stack at entirely unrelated points in the program, or even in different libraries that each happen to use boost::thread_specific_ptr! void g() { thread_specific_ptr<float> ptr; // ... } f(); g(); It's easy to see the problem here as the calls are very close to one another. In general, however, this strikes me as being really rather dangerous behaviour. Would it be fair to call it a bug? It seems it is only safe to allocate thread_specific_ptrs in static storage. A complete example is listed at the end. It exhibits the kind of behaviour I'm talking about on my x86 systems, at least. Kind regards, Edd //#define BOOST_ALL_NO_LIB 1 #include <queue> #include <iostream> #include <boost/thread/tss.hpp> #include <boost/thread/thread.hpp> #include <boost/thread/barrier.hpp> #include <boost/thread/condition.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> using namespace boost; typedef function<void ()> task_type; // Simple multi-producer-single-consumer job queue. // Manages its own consumer thread. class jobq { public: jobq() : dying_(false), consumer_(bind(&jobq::work_loop, this)) { } ~jobq() { exit_work_loop(); consumer_.join(); } void add(const task_type &task) { unique_lock<mutex> lk(mtx_); tasks_.push(task); arrival_.notify_one(); } private: void exit_work_loop() { unique_lock<mutex> lk(mtx_); dying_ = true; arrival_.notify_one(); } bool wait_for_task(task_type &task) { unique_lock<mutex> lk(mtx_); while (!dying_ && tasks_.empty()) arrival_.wait(lk); if (dying_) return false; task = tasks_.front(); tasks_.pop(); return true; } void work_loop() { task_type task; while (wait_for_task(task)) task(); } private: bool dying_; std::queue<task_type> tasks_; mutex mtx_; condition arrival_; thread consumer_; }; template<typename T> void access_tsp(thread_specific_ptr<T> &tsp, barrier &b) { if (!tsp.get()) tsp.reset(new T(-1)); else std::cout << "Already initialized to " << *tsp << "!\n"; b.wait(); } template<typename T> void f(jobq &q) { barrier b(2); thread_specific_ptr<T> tsp; q.add(bind(&access_tsp<T>, ref(tsp), ref(b))); b.wait(); // wait until it's safe to destroy tsp } int main() { jobq q; f<int>(q); f<unsigned>(q); return 0; }

4 6

Re: [boost] [Boost][gsoc]Intrest - big integer library
by Kamil Witecki 16 Feb '10

16 Feb '10

I see that even a simple, but robust, implementaion covering each case (possibly some of them awaiting implementations of apropriate policy) would be hard, if not infeasible, to be done in such a short period of time as is given in GSoC. On the other hand I would take a deeper look in that topic and meanwhile look for another proposition. Many thanks for all your answers and clarifiyng all the infarmation and possible problems. Kamil Witecki.

1 0

Re: [boost] boost 1.42 - compile toolsset=intel-linux with fPIC
by "Sören Freudiger" 16 Feb '10

16 Feb '10

okay, I got it. Okay, I never cared about the project-config.jam file (maybe because the user_config file is mentioned after bootsrap.sh). I just put the using intel-linux stuff inside projetc-config: if ! intel-linux in [ feature.values <toolset> ] { using intel-linux : 10.1 : /lrz/sys/intel/icc_101/bin/icpc : <compileflags>"-fPIC" <linkflags>"-fPIC" ; } instead of the user_config. That's it. Don't know why it doesn't work for intel with user_config but for the gcc. However, I hope it'll work.. Thank @all, SirAnn -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0

Re: [boost] boost 1.42 - compile toolsset=intel-linux with fPIC
by "Sören Freudiger" 16 Feb '10

16 Feb '10

@ Normal 0 21 false false false DE X-NONE X-NONE Volodya > Well, just do that in project-config.jam? Or, alternatively, remove project-config.jam -- and have only user-config.jam be used. Okay, but which one is that? (location?) I can see your name in the jam files very often, thus you are to be the one who can help me out, dont' ya? @Dick Normal 0 21 false false false DE X-NONE X-NONE >If you build an executable that will dynamically load (with dlopen) shared libraries, then all of its code, including whatever it gets from static libraries, has to be compiled and linked with -fPIC. >This leads us to compile and link all of our code, including boost libraries, with -fPIC. bullseye! that's the problem that we have.. thus we have to turn on the fPIC option.. But I don't get it work for the intel compiler.... Do you have a solution? -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

3 2

boost 1.42 - compile toolsset=intel-linux with fPIC
by "Sören Freudiger" 16 Feb '10

16 Feb '10

Hello I just try to compile boost 1.42 on the Altix-HPC in Munic. Problem is that I need to compile it with turned on -fPIC cxx-flag. Following steps I'd done: 1. run ./bootstrap.h --prefix=... --with-toolset=intel-linux 2. modify tools/build/v2/user_config.jam: ... using intel-linux : : : <cxxflags>-fPIC ; ... (according to http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.r…) 3. run ./bjam --> error: error: at /home/hlrb2/pr95gi/lu78wol/libs/boost_1_42_0/tools/build/v2/build/project.jam:884 error: duplicate initialization of intel-linux with the following parameters: error: version = <unspecified> error: previous initialization at /home/hlrb2/pr95gi/lu78wol/libs/boost_1_42_0/tools/build/v2/build/project.jam:884 What's the matter? What point did I miss? Please help ;-) SirAnn -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

4 4

Re2: boost 1.42 - compile toolsset=intel-linux with fPIC
by "Sören Freudiger" 16 Feb '10

16 Feb '10

Normal 0 21 false false false DE X-NONE X-NONE > Take a look at project-config.jam -- it already has 'using intel....'. > I suggest you remove whatever setting you've made in tools/build/v2/user-config.jam. But that's especially what I wanna to: add the fPIC flag for the gcc version it works fine!) > Further, why are you even trying to use -fPIC. When building shared libraries, -fPIC is used already. Some of our guys have to link because of certain reasons against the static libs from boost and obtain the error boost should be compiled with turned on fPIC flag... -SirAnn -----Ursprüngliche Nachricht----- Von: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] Im Auftrag von Vladimir Prus Gesendet: Dienstag, 16. Februar 2010 17:18 An: boost(a)lists.boost.org Betreff: Re: [boost] boost 1.42 - compile toolsset=intel-linux with fPIC "Sören Freudiger" wrote: > Hello > I just try to compile boost 1.42 on the Altix-HPC in Munic. Problem is > that I need to compile it with turned on -fPIC cxx-flag. > > Following steps I'd done: > > 1. run ./bootstrap.h --prefix=... --with-toolset=intel-linux 2. modify > tools/build/v2/user_config.jam: > > ... > using intel-linux : : : <cxxflags>-fPIC ; ... > > (according to > http://www.boost.org/boost- build2/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.intel) > > 3. run ./bjam > > --> error: > error: at > /home/hlrb2/pr95gi/lu78wol/libs/boost_1_42_0/tools/build/v2/build/proj > ect.jam:884 > error: duplicate initialization of intel-linux with the following > parameters: > error: version = <unspecified> > error: previous initialization at > /home/hlrb2/pr95gi/lu78wol/libs/boost_1_42_0/tools/build/v2/build/proj > ect.jam:884 > > What's the matter? What point did I miss? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0

[BGL/PM] Composition of two property maps
by Matthias Walter 16 Feb '10

16 Feb '10

Hi, I currently have a function which gets a graph plus an index-map and want's to call a BFS. Therefore it needs to build a color-map which maps vertex_descriptors to colors. As the user already gives a way to map vertex_descriptor to index, I'd like to use this mapping. What I need is a way to define a property map as a composition: composed-map (vertex_descriptor) -> color via color-map (index-map (vertex_descriptor)) -> color whereas index-map (vertex_descriptor) -> index and color-map (index) -> color Of course this should not be too difficult to implement, so I'd just like to ask whether there already exists some kind of implementation, because I neither found a hint by looking in the docs, nor by digging through some of the code. The actual reason I ask is because there might be other ways to come around the problem, e.g. making the color-map itself use vertex_descriptors as keys, so maybe my suggested solution is not the best. best regards Matthias Walter

2 1

C++0x and MSVC 10
by Zachary Turner 16 Feb '10

16 Feb '10

Playing with the release candidate of MSVC 10, and I'm noticing boost 1.42.0 is not using any C++0x features. Has this been discussed before, or is there a reason for this? Taking a peek at boost/config/compiler/visualc.hpp, I see the following: #if _MSC_VER < 1600 #define BOOST_NO_AUTO_DECLARATIONS #define BOOST_NO_AUTO_MULTIDECLARATIONS #define BOOST_NO_DECLTYPE #define BOOST_NO_LAMBDAS #define BOOST_NO_RVALUE_REFERENCES #define BOOST_NO_STATIC_ASSERT #define BOOST_NO_NULLPTR #endif // _MSC_VER < 1600 // C++0x features not supported by any versions #define BOOST_NO_CHAR16_T #define BOOST_NO_CHAR32_T #define BOOST_NO_CONCEPTS #define BOOST_NO_CONSTEXPR #define BOOST_NO_DEFAULTED_FUNCTIONS #define BOOST_NO_DELETED_FUNCTIONS #define BOOST_NO_EXPLICIT_CONVERSION_OPERATORS #define BOOST_NO_EXTERN_TEMPLATE #define BOOST_NO_FUNCTION_TEMPLATE_DEFAULT_ARGS #define BOOST_NO_INITIALIZER_LISTS #define BOOST_NO_RAW_LITERALS #define BOOST_NO_SCOPED_ENUMS #define BOOST_NO_SFINAE_EXPR #define BOOST_NO_TEMPLATE_ALIASES #define BOOST_NO_UNICODE_LITERALS #define BOOST_NO_VARIADIC_TEMPLATES It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following? #if _MSC_VER < 1600 #define BOOST_NO_AUTO_DECLARATIONS #define BOOST_NO_AUTO_MULTIDECLARATIONS #define BOOST_NO_DECLTYPE #define BOOST_NO_LAMBDAS #define BOOST_NO_RVALUE_REFERENCES #define BOOST_NO_STATIC_ASSERT #define BOOST_NO_NULLPTR #else #define BOOST_HAS_AUTO_DECLARATIONS #define BOOST_HAS_AUTO_MULTIDECLARATIONS #define BOOST_HAS_DECLTYPE #define BOOST_HAS_LAMBDAS #define BOOST_HAS_RVALUE_REFERENCES #define BOOST_HAS_STATIC_ASSERT #define BOOST_HAS_NULLPTR #endif // _MSC_VER < 1600 Zach

7 13

boost/cstdint.hpp definition of INTMAX_C conflicts with MPFR
by Vincent Lefevre 16 Feb '10

16 Feb '10

Hi, I'm a MPFR developer and the following problem with Boost has been reported in the MPFR mailing-list. As of Boost 1.42, the macros INTMAX_C and UINTMAX_C (in particular) are always defined, and on a system without <stdint.h> (Microsoft C++ compiler), the build of a program using Boost 1.42 and MPFR failed. The reason is that mpfr.h supports systems with and without intmax_t (so that it does not force <stdint.h> inclusion), thus it must have a way to determine when intmax_t is available, without requiring the user to do anything else than including <stdint.h> first. So, it has several heuristics, one of them being the test of the existence of INTMAX_C and UINTMAX_C. Indeed, in C, which does not have namespaces, it is rather intuitive that the existence of INTMAX_C and UINTMAX_C implies that the corresponding types intmax_t and uintmax_t are available. However, in C++ with Boost, intmax_t and uintmax_t are not necessarily available (in the global namespace). Even though one could specify a macro for MPFR that would allow the user to disable (u)intmax_t support explicitly, I think that Boost's behavior is rather awkward, and may break other software too (in particular libraries that would do the same kind of things as Boost). Indeed (correct me if I'm wrong, I don't know very much about C++), while types have namespaces, macros don't, but there are conventions under which using a prefix such as BOOST_ can be used in place of a namespace (to avoid conflicts with other software). So, I wonder why Boost doesn't do the following: since it defines the intmax_t and uintmax_t types in the boost namespace, it should use the BOOST_ prefix for the corresponding macros, e.g. BOOST_INTMAX_C and BOOST_UINTMAX_C. The only acceptable artifact concerning these types would be that additional types and macros be defined due to the inclusion of standard headers such as <stdint.h>; but in such a case, the behavior would remain consistent (i.e. INTMAX_C and UINTMAX_C would be defined only if intmax_t and uintmax_t are available). If, for some reason, Boost really needs to define the INTMAX_C and UINTMAX_C macros, then it should also define intmax_t and uintmax_t in the global namespace. But I don't think that's a good idea. Regards, -- Vincent Lefèvre <vincent(a)vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

2 4

[thread] Moving a `recursive_lock`
by Daniel Trebbien 16 Feb '10

16 Feb '10

Hello all, I have been working on a project that uses the Boost Thread library, and I realized that there is a part of the code that needs to transfer a lock to a thread that has just been started. My idea for implementing this was to use a `boost::recursive_mutex` and pass a non-`const` reference to a `boost::recursive_mutex::scoped_lock` to the thread via `boost::ref`. Also, to ensure that the `scoped_lock` does not go out of scope until until the lock is moved, I thought to use a `boost::barrier`. After writing some test code, I find it interesting that if I use a `recursive_mutex`, then an assertion fails, but if I use a `boost::mutex`, then the code seems to work fine. Here is the test code that I have been experimenting with (the `recursive_mutex` version, which is also attached): #include <iostream> #include <boost/ref.hpp> #include <boost/thread.hpp> static boost::recursive_mutex s_mutex; static boost::barrier s_lockMoveBarrier(2); void thread_fun1(boost::recursive_mutex::scoped_lock& lock_) { //boost::recursive_mutex::scoped_lock testLock(s_mutex); // uncommenting this causes deadlock, as expected std::cout << "in `void thread_fun1(...)`: moving lock..."; boost::recursive_mutex::scoped_lock lock2(boost::move(lock_)); std::cout << "done" << std::endl; s_lockMoveBarrier.wait(); std::cout << "in `void thread_fun1(...)`: after the barrier" << std::endl; } int main() { boost::recursive_mutex::scoped_lock lock(s_mutex); std::cout << "in `int main()`: lock on `s_mutex` acquired" << std::endl; boost::thread(&thread_fun1, boost::ref(lock)); s_lockMoveBarrier.wait(); std::cout << "in `int main()`: after the barrier" << std::endl; } After compiling and running this on Debian Squeeze with Boost 1.42.0, I get: in `int main()`: lock on `s_mutex` acquired in `void thread_fun1(...)`: moving lock...done in `int main()`: after the barrier a.out: /usr/local/include/boost/thread/pthread/recursive_mutex.hpp:62: boost::recursive_mutex::~recursive_mutex(): Assertion `!pthread_mutex_destroy(&m)' failed. Aborted After replacing "boost::recursive_mutex" with "boost::mutex", however, the output is: in `int main()`: lock on `s_mutex` acquired in `void thread_fun1(...)`: moving lock...done in `void thread_fun1(...)`: after the barrier in `int main()`: after the barrier This leads me to wondering: 1. Is it correct and/or safe to move a lock to a new thread in this way? 2. Why does the `recursive_mutex` version fail and the `mutex` version succeed? Daniel Trebbien

3 3

Re: [boost] [Boost][gsoc]Intrest - big integer library
by Kamil Witecki 15 Feb '10

15 Feb '10

>Given the number of times which a big integer library has been >started, I'd be wary of suggesting it as a GSoC project. I did not thought it would be so hard to be done. >Since there are already many C big integer libraries (with various >licenses), I'd be far more interested in an expression template system >that would let me hook in the operations I need. That way if I'm ok >with LGPL I can just use GMP, for instance. Also, a naive >implementation could be provided for testing and verification. It sounds very good. And does not involve reinventing the wheel from scratch as would do a new implementation of big integers. You would recommend creating expression templates that will allow to bind operators (functions or functionals) and types(for example big integers from third party library) together using type traits and passing functional as template parameter, have I got your idea right? >I remember hearing that someone had started something like that, but I >don't know its progress. I will take a deeper look if anybody has done it already. >~ Scott -- Kamil Witecki.

2 1

[filesystem] Mac OS default codecvt facet
by Beman Dawes 15 Feb '10

15 Feb '10

On Mac OS, Boost.Filesystem currently uses std::locale() as the default, since Apple doesn't see fit to support std::locale(""). There has been a request (ticket #3928) to change the codecvt facet to UTF-8 for the Boost.Filesystem default on Mac OS. This would at least potentially be a breaking change, so I wanted to ask other's opinions before making it. Questions: * Is UTF-8 OK with Mac OS users as the Boost.Filesystem default? * Would Linux users also prefer UTF-8 as the Boost.Filesystem default? Thanks, --Beman

2 6

Downcast taking account of virtual inheritance
by vicente.botet 15 Feb '10

15 Feb '10

Hi, I have a generic class that needs to downcast from a base class to a template class. The template class can use virtual inheritance or not. When the derived class use virtual inheritance I need to use dynamic cast, but not on the other cases. I'm wondering if a new downcast function that will take in account these facts would be of interest in Boost. clase B {...}; class D : public B {...}; class DV : public virtual B {...}; B* ptr; ptr= new D(); D* dPtr = downcast<D*>(ptr); // uses static_cast as is_virtual_base_of<B,D>::type is false ptr= new DV(); DV* dPtr = downcast<DV*>(ptr); // uses dynamic_cast as is_virtual_base_of<B,DV>::type is true What would be a good name for this downcast function? Best, _____________________ Vicente Juan Botet Escribá

6 11

[config] macors with variable arguments support
by vicente.botet 15 Feb '10

15 Feb '10

Hi, is threa macro to know if the compiler supports macros with variable arguments? Best, _____________________ Vicente Juan Botet Escribá

1 0

incomplete_smart_cast: a smart_cast to incomplete types
by vicente.botet 14 Feb '10

14 Feb '10

I have another user case: template <class Final, typename Base=base_transaction_object> class deep_transaction_object : public Base { Final* final() { return static_cast<Final*>(this); } const Final* final() const { return static_cast<Final const*>(this); } public: static Final* make_cache(Final const* rhs, transaction& ) { return new Final(*rhs); } virtual base_transaction_object* make_cache(transaction& t) const { return new Final(*final()); } virtual void delete_cache() { delete this; } virtual void copy_cache(base_transaction_object const & rhs) { *final() = *smart_cast<Final const*>(&rhs); // (1) } }; deep_transaction_object is a mixin class that is be used as follows class F : public deep_transaction_object<F> {...}; At the moment we use smart_cast in deep_transaction_object (1), F is not completly defined. smart_cast is a template class that needs its class parameters to be completly defined, as is_virtual_base_of needs this. In this context I can not check if Final is_virtual_base_of base_transaction_object. As F is a deep_transaction_object<F> which is a Base, the check could be limited to see if Base is_virtual_base_of base_transaction_object. Thus I need a kind of incomplete_smart_cast which in addition has an intermidiate class used for the tests *final() = *incomplete_smart_cast<Final const *, Base const*>(&rhs); incomplete_smart_cast<Target,Intermediate, Source> works like smart_cast except that instead of testing with Target, it test with Intermediate to select the cast to apply to target incomplete_smart_cast<F*, I*>(ptr) = static_cast<F*,smart_cast<I*>(ptr)> For the case of single inheritance this seems to too much to add, but with multiple inheritance the situation we can not build it from static_cast and smart_cast, we need to check if one of the intermediate classes is_virtual_base_of the base class. For example if the mixin allows to inherit from two classes template <class Final, class Base1, class Base1> class deep_transaction_object2 : public Base1, public Base2 { ... virtual void copy_cache(base_transaction_object const & rhs) { *final() = *incomplete_smart_cast2<Final const*, Base1 const*, Base2 const*>(&rhs); // (1) } }; Please let me know if my rationale is correct and if my use case is enough common to interest the Boost community. Best _____________________ Vicente Juan Botet Escribá

1 0

boost::any_ref and boost::any_const_ref
by Daniel Larimer 14 Feb '10

14 Feb '10

I am attempting to create a library with a generic interface run-time interface and have need for something like boost::any; however, boost::any requires heap allocation. boost::variant is not acceptable either because I do not know the full set of types in advance. Has anyone seen the equivalent of a type-checked void* or const void*? Effectively I would like to create a polymorphic method like this: void myclass::method( const_any_ref p1, const_any_ref p2, const any_ref p3 ) { const uint16_t& _p1 = p1; const double& _p2 = p2; const std::string& _p3 = p3; //If any of the types do not match it should throw an exception. alternatively the follow syntax may work if you want to avoid exceptions? boost::optional<const uint16_t&> _p1 = p1; if( !_p1 ) // cast failed? } Anyone have any nifty ideas on how to accomplish this without RTTI and no heap allocation? In place of RTTI I do have a "manual" RTTI system that I could use. get_typename<T>::str will return a unique const char* pointer. I am guessing the best I can hope for is a pair of pointers, one "void*" and one const char*. I am going to write such a class unless someone here knows of an existing solution. Dan

1 1

[vault][msm] Where has the vault gone?
by Agustín K-ballo Bergé 14 Feb '10

14 Feb '10

http://www.boostpro.com/vault/ gives a 404 - Not Found I'm trying to get the latest MSM version. Is there anywhere else I can get it? Agustín K-ballo Bergé.-

3 3

Re: [boost] [vault][msm] Where has the vault gone?
by Christophe Henry 13 Feb '10

13 Feb '10

> You can find it in sandbox > http://svn.boost.org/svn/boost/sandbox/msm/ Small precision, I use it as my "trunk" version. It is stable but the documentation still lags the code state (I am in the rewriting process). The last stable version and with up-to-date documentation (the one from the vault + a few bugfixes / performance improvements) is in: http://svn.boost.org/svn/boost/sandbox/msm/tags/version-2.0/ >For SF right link is http://sourceforge.net/projects/boost-msm/ And I didn't even advertise it :) I plan to use SF so that one could request and try some features before they make it into the official code, but I need to finish the project page first, so for the moment, you will find not much there. Christophe

1 0

Re: [boost] [serialization] Can one deserialize a derived classes viapointers to the base class using polymorphic archives in aDLL context?
by Bogdan 13 Feb '10

13 Feb '10

Robert Ramey <ramey <at> rrsd.com> writes: > >> > >> Please note BOOST_CLASS_EXPORT_IMPLEMENT is used only once per class > >> (inside polymorphic_derived2.cpp), yet the serializers are inserted > >> in the same map both from the Dll and from the executable. > >> > >> Am I doing something wrong? Has anyone been able to create a similar > >> working example? I really appreciate any feedback I could get. > > It looks like polymorphic_derived2.cpp is being included in both the > mainline as well as the DLL. > > It's not clear that polymorphic_base needs to be n the DLL and probably > shouldn't be. > > Make sure that your header includes BOOST_CLASS_EXPORT_KEY and not > BOOST_CLASS_EXPORT. > > finally, make sure that the test for this facility works. > > Robert Ramey > Thank you Robert for your quick response: I appreciate a lot the generous work you put in the library. I double checked the project I previously uploaded: I downloaded it via gmane.org, changed the name back from bin to zip and verified the following: - polymorphic_derived2.cpp file is included only in dll_polymorphic_derived2.vcproj. - there are only three projects dll_polymorphic_derived2, Library and test_dll_exported plus an explicit reference to the bjam files (I removed the latter after downloading); - there is no usage BOOST_CLASS_EXPORT; - there are exactly three declarations of BOOST_CLASS_EXPORT_KEY: one in polymorphic_base.hpp, and two in polymorphic_derved2.hpp one for polymorphic_derived1 and another for polymorphic_derived2. Similarly, there are only three usages of BOOST_CLASS_EXPORT_IMPLEMENT. There was only one question mark: test_dll_exported.vcproj depended on dll_polymorphic_derived2 both via Project Dependencies option and explicitly as an input library: to be on the safe side, I removed the explicit dependency of test_dll_exported on dll_polymorphic_derived2 from the solution. I rebuild the solution from scratch. Unfortunately I got the same exception. So I am still cornered and looking for some help. Thank you again, Bogdan

1 0

[serialization] Can one deserialize a derived classes via pointers to the base class using polymorphic archives in a DLL context?
by Bogdan 13 Feb '10

13 Feb '10

Hi all, I am trying to upgrade to boost 1.42 using Visual Studio 2008 and I have difficulties using serialization with polymorphic archives in a DLL setup. I would like to encapsulate in one DLL the class serialization functionality based on a polymorphic base archive. In another place, I would like to perform the actual serialization/deserialization using a specific archive (e.g., polymorphic_text_[io]archive). The section "Special Considerations" of the documentation indicates in two paragraphs ("DLLS - Serialization and Runtime Linking" and " Plugins") that this scenario is supported by the library. However I couldn't find any example that shows how to do that. Therefore, I changed slightly the boost test that includes test_dll_exported.cpp and polymorphic_derived2.cpp as follows: 1. I moved the classes polymorphic_base and polymorphic_derived1 to the project polymorphic_derived2 This way, we have one place where those classes serialize their members (i.e., polymorphic_derived2.dll) and a separate binary where we serialize them via a derived archive (i.e., test_main() inside test_dll_exported.exe); 2. I replaced the template version of the serialization functions with the equivalent version based on boost::archive::polymorphic_[io]archives. I also removed the text-based instantiation inside the Dll. As indicated in the boost documentation, the class serialization will only have to be compiled once for all archive implementations (present or future). Therefore, the DLL should contain only the serialization functions to the base polymorphic archives. While everything builds correctly, at run time I get a C++ exception BEFORE main() in basic_serializer_map.cpp around the line 48: // if this fails, it's because it's been instantiated // in multiple modules - DLLS - a recipe for problems. // So trap this here if(!result.second){ boost::serialization::throw_exception( archive_exception( archive_exception::multiple_code_instantiation, bs->get_debug_info() ) ); } Please note BOOST_CLASS_EXPORT_IMPLEMENT is used only once per class (inside polymorphic_derived2.cpp), yet the serializers are inserted in the same map both from the Dll and from the executable. Am I doing something wrong? Has anyone been able to create a similar working example? I really appreciate any feedback I could get. Thank you, Bogdan PS For more info I attached the files describing my problem plus the .sln file (I used the configuration "Debug runtime-dynamic threading-multi")

2 1

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

13 Feb '10

> I am thinking to submit a library for Contract Programming (a.k.a. > Design By Contract (TM) ) for C++. > I have drafted some of the library documentation in Boost-like format: > http://dbcpp.sourceforge.net/boost/libs/contract/doc/html/ > Comments? Hi, I would be very interested in trying such a library. I have one suggestion, which may be impossible to implement, but I think it would be worth at least looking at. The macros for defining assertions spoil function declarations. I know it is inevitable, etc., but.. read on. I know at least one library in Boost that also spoils function declarations in order to provide additional functionality: Concept Check library; they may be others too (MPL?). My suggestion is that if there are (or will be) libraries that require spoiling function declarations, they should all provide the same "spoiled" syntax. Otherwise I will be always asking "how do I declare a function in this library?". It would be very convenient if Boost provided one alternative function definition syntax that when used would enable all its libraries to work. Regards, &rzej

2 1