- Boost - lists.boost.org

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

[Boost-bugs] [ boost-Support Requests-1081415 ] isdigit, problem with namespace
by SourceForge.net 08 Dec '04

08 Dec '04

Support Requests item #1081415, was opened at 2004-12-08 07:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1081415&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: isdigit, problem with namespace Initial Comment: Hi! In one of my projects I use the regex library, and it works great. But unfortunately it seems to mess up my namespaces, or something like that. I included #include "boost/regex.hpp". Using the boost library I am to call functions from the std namespace (memset, isdigit, ...) like ::isdigit(). Without the namespace-operator the compiler seems to have two functions called isdigit. Now it happens that I am to use another library along with regex (one of my company), which uses an isdigit() call (without namespace- operator), and which i must not alter. Honestly, I'm a little bit puzzled at all that the regex- library forces me to use the namespace-operator with functions from std-namespace. Is this the way it was ment, or did I somethig wrong? Thanks for your help, Markus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1081415&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[date_time] Sunpro wide test errors should be marked expected
by Caleb Epstein 08 Dec '04

08 Dec '04

-- Caleb Epstein caleb dot epstein at gmail dot com

2 1

[external_allocators] any interest?
by Thorsten Ottosen 08 Dec '04

08 Dec '04

Dear all, I have sometimes spoken with people here that had an interest in allocators that could be reset within containers. For example, some have wanted a allocator& container::get_allocator(); member function. One way to solve that problem could be a class like this: template< class Allocator > class external_allocator { public: // forward to Allocator* member }; And then it can be used like this typedef external_allocator< std::allocator<T> > ex_allocator; std::allocator<T> alloc; ex_allocator ex_alloc(alloc); std::vector<T,ex_allocator> vec(ex_alloc); and can now control the allocator from the outside. There seems to only be a small overhead with this approach. One usage scenario I can see would be to use a stack-based allocator on performance critical paths. (because we need the copy-semantics of the container's allocator to be shallow) If there is interest, I can also add the specified member function to the smart containers. or an appropriate member to external_allocator<>. Feedback is welcome -Thorsten

2 2