December 2004 - Boost - lists.boost.org

[Variant] Binary visitation and return type
by Hartmut Kaiser 09 Dec '04

09 Dec '04

Hi all, is there a means of using the binary visitation pattern provided by the Boost.Variant library and make the return type of the visitation process dependent on the types currently stored inside the visited variant object instances? I.e. I'm looking for some way to do the following: typedef boost::variant<unsigned long, long> variant_type; struct add_visitor : public .... { long operator()(long t1, long t2) { return t1 + t2; } template <typename T> unsigned long operator()(unsigned long t1, T t2) { return t1 + t2; } template <typename T> unsigned long operator()(T t1, unsigned long t2) { return t1 + t2; } }; variant_type term1 = 1L; variant_type term2 = 2UL; variant_type term3 = -2L; variant_type unsigned_result = boost::apply_visitor(add_visitor(), term1, term2); variant_type signed_result = boost::apply_visitor(add_visitor(), term1, term3); Is this possible with the current implementation? Regards Hartmut

3 6

logo contest?
by David Abrahams 09 Dec '04

09 Dec '04

Are we actually going to publicize a logo contest or are we going to be doing it all here? I think it should be the former, and I think we should get most of the logo announcements and commentary off this list so it can return to its regularly scheduled programming. But first I guess someone has to volunteer to manage the thing at least (make up the announcement, settle voting procedure, etc.) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

9 15

RE: [boost] shared_ptr, interface and dlls,
by Dirk Gregorius 09 Dec '04

09 Dec '04

> extern "C" Interface* DLLCreate() > { > return new InterfaceImpl; > } > extern "C" void DLLDestroy( Interface* p ) > { > delete p; > } > and then construct an InterfacePtr( DLLCreate(), DLLDestroy ). You'll need a public virtual destructor in this case, > though. I changed my code to this: void DLLCreate( Interface& rInterface ) { // Implementation option #1: rInterface.reset( new InterfaceImple ); // Implementation option #2: rInterface = InterfacePtr( new InterfaceImpl ); } Is this a valid solution as well? At least it compiles - but with the first solution I have the feeling that I could run into the boundary problem, since the actual pointer is not constructed on the DLL side. But as I said - I can only guess here... Is there a difference between both solutions? > Yes, it's allowed. Since you are using the DLL runtime, you probably don't need to interoperate with different C++ > compilers so you probably need to just omit the extern "C" from DLLCreate. But how can I load the function than after it got mangled? -Dirk PS: Sorry for the wrong post...

2 2

porting to realtime platform
by Harald Haspl 09 Dec '04

09 Dec '04

Hello list, To use the realtime features of my hardware I need to link against a special library instead of rt. How can I replace the -lrt linker flags by -lrealtime when compiling the boost library? Harald Haspl

2 2

memory mapped containers?
by Neal D. Becker 08 Dec '04

08 Dec '04

I recall there was some discussion here about containers with memory-mapped storage? There was as I recall some interest. What is the status of this?

2 1

Re: Boost Digest, Vol 935, Issue 2
by Dirk Gregorius 08 Dec '04

08 Dec '04

> extern "C" Interface* DLLCreate() > { > return new InterfaceImpl; > } > extern "C" void DLLDestroy( Interface* p ) > { > delete p; > } > and then construct an InterfacePtr( DLLCreate(), DLLDestroy ). You'll need a public virtual destructor in this case, > though. I changed to this: void DLLCreate( Interface& rInterface ) { // Implementation option #1: rInterface.reset( new InterfaceImple ); // Implementation option #2: rInterface = InterfacePtr( new InterfaceImpl ); } Is this a valid solution as well? At least it compiles - but with the first solution I have the feeling that I could run into the boundary problem, since the actual pointer is not constructed on the DLL side. But as I said - I can only guess here... Is there a difference between both solutions? > Yes, it's allowed. Since you are using the DLL runtime, you probably don't need to interoperate with different C++ > compilers so you probably need to just omit the extern "C" from DLLCreate. But how can I load the function than after it got mangled?

2 1

[Range] bugs in legacy compiler support
by Eric Niebler 08 Dec '04

08 Dec '04

In range/detail/begin.hpp: template<> struct range_begin<array_> { template< typename T, std::size_t sz > static T* fun( T BOOST_ARRAY_REF[sz] ) BOOST_ARRAY_REF is not defined anywhere I can see. This should probably be: template< typename T, std::size_t sz > static T* fun( T BOOST_RANGE_ARRAY_REF()[sz] ) ---------------------------------- In range/detail/end.hpp: template<> struct range_end<char_array_> { template< typename T, std::size_t sz > static std::size_t fun( T BOOST_RANGE_ARRAY_REF()[sz] ) { return boost::range_detail::array_end( array ); } }; template<> struct range_end<wchar_t_array_> { template< typename T, std::size_t sz > static std::size_t fun( T BOOST_RANGE_ARRAY_REF()[sz] ) { return boost::range_detail::array_end( array ); } }; The return types of these two functions are wrong. They should be T* instead of std::size_t. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

RE: [boost] shared_ptr, interface and dlls
by Stefan Seefeld 08 Dec '04

08 Dec '04

> From: Peter Dimov [mailto:pdimov@mmltd.net] > > Is your advice > > above simply due to a limitation with MSVC ? > > It seems so. From a quick test, g++ and bcc32 do return C++ > classes from > extern "C" functions, only MSVC emits an error. I'm not sure > whether such a > function makes sense, though. If you suppress name mangling, > presumably > because two different compilers mangle names differently, > what are the > chances that the object layout will be the same? Oh, ABI compatibility is an entirely different issue, I agree. However, if you want to write your own component model you have to use an entry point with extern C linkage, even though the whole thing will be compiled with the same toolchain. Regards, Stefan

1 0

RE: [boost] shared_ptr, interface and dlls
by Stefan Seefeld 08 Dec '04

08 Dec '04

> > extern "C" InterfacePtr DLLCreate( void ) > > { > > return InterfacePtr( new InterfaceImpl ); > > } > > > > At the moment this code doesn't compile because VS7.1 complains that > > it a function with extern "C" linkage can't return a > > shared_ptr<Interface> instance. How could I implement the desired > > behavior? > > Either omit the extern "C" or, if you must use a C-style > interface, do this: > > extern "C" Interface* DLLCreate() > { > return new InterfaceImpl; > } > > extern "C" void DLLDestroy( Interface* p ) > { > delete p; > } > > and then construct an InterfacePtr( DLLCreate(), DLLDestroy > ). You'll need a > public virtual destructor in this case, though. When writing plugins under linux (i.e. with 'dlopen' etc.), I believe I have already used a function returning a std::auto_ptr as entry point for the loader. What is wrong with that ? Is your advice above simply due to a limitation with MSVC ? Regards, Stefan

2 1

shared_ptr, interface and dlls
by Dirk Gregorius 08 Dec '04

08 Dec '04

Hi, is it possible to return a shared_ptr to an interface from a dl?. I thought of the following what unfortunately doesn't work: // Interface.h - exe project class Interface { public: vitrtual void f( void ) = 0; virtual void g( void ) = 0; protected: ~Interface( void ) {} } typedef shared_ptr<Interface> InterfacePtr; InterfacePtr Create( void ) { // Load a special create function from the dll //.... return DLLCreate(); } // InterfaceImpl.h - dll project #include Interface class InterfaceImpl : public Interface { public: void f( void ) { /* ... */ }; void g( void ) { /* ... */ }; private: // No copy operations } extern "C" InterfacePtr DLLCreate( void ) { return InterfacePtr( new InterfaceImpl ); } At the moment this code doesn't compile because VS7.1 complains that it a function with extern "C" linkage can't return a shared_ptr<Interface> instance. How could I implement the desired behavior? Some other related questions regarding this topic: 1.) I link to the multithreaded C run-time dll - is this allowed? I read in an older post that only static CRT linking is allowed. 2.) Does the above code - loading the factory from the DLL as well and (hopefully) constructing the instance there - solve the boundary problems? I read some articles regarding this issue, but to be honest I haven't completly understood the problems that may occure in this case so far. Any help is greatly appreiciated.. -Dirk

2 1