- Boost - lists.boost.org

RE: Re: Re: Re: typeof integrated
by Jason Shirk 09 Dec '04

09 Dec '04

> From: Arkadiy Vertleyb [mailto:vertleyb@hotmail.com] > Sent: Wednesday, December 08, 2004 1:16 PM > Subject: Re: Re: Re: Re: typeof integrated > > "Peder Holt" <peder.holt(a)gmail.com> wrote > > > Then again, the following compiles with VC7.1, so maybe there is hope > > after all :) > > Wow... > > The reason it compiles is that you are using "class" where I used > "typename". The following does not work: > > template<typename A0> > void deduce_container(*typename* std::_Tree<A0>::iterator) > { > std::cout << "map" << "\n"; > } > > I don't think this is a legal standard usage, though... Probably a > Microsoft - specific "feature"... Any comments from language experts? > Should the following work according to the Standard? > This is definitely a compiler bug, not a feature. -- Jason Shirk VC++ Compiler Team

1 0

Re: Problem with boost.iterator II
by David Abrahams 09 Dec '04

09 Dec '04

Bob Bell wrote: > Dave- > > I was looking over my "sent" items and I think something was wrong with > my return address, so I'm resending this with the right address. Sorry > for any confusion it may have caused. Bob, Please post Boost questions to one of the Boost mailing lists (unless you want to hire us for consulting services, that is!) > I've been using the boost iterator adaptor library, and first let me say > thanks; it's really a great library. You're welcome :) > Having said that, however, I'm having a problem. I'm trying to build an > iterator that uses both boost::filter_iterator and > boost::transform_iterator, but what happens is that when I combine these > two adaptors, it seems to lose the iterator category of the original > iterator. That is, say I build an iterator like this: > > boost::transform_iterator<SomeTransform, > boost::filter_iterator<SomeFilter, int*> > > > The resulting iterator only seems to be a forward iterator. My > understanding is that the iterator category of the base iterator (int*), > should become the category of the resulting composite. So my first > question is: is this a correct understanding on my part? Not according to http://www.boost.org/libs/iterator/doc/filter_iterator.html#filter-iterator… A filter iterator is never more than a forward iterator. HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[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