December 2004 - Boost - lists.preview.boost.org

missing regression tests?
by John Maddock 10 Dec '04

10 Dec '04

What's happened to most of the regression tests? The Tru64, SGI, AIX etc test results have all disappeared. Thanks, John.

3 2

boost::shared_ptr<> uses mutex rather than CAS methods
by Dayton 09 Dec '04

09 Dec '04

Shared_ptr<> down deep uses a light-weight mutex to protect the increment and decrement of its reference count. A mutex isn't needed here. A mutex may yield the context of execution. This seems silly to protect a single instruction. To support threads, all modern processors offer some form of interlocked operation or atomic compare-and-swap instruction. On SPARC cpus, it is the CAS instruction, which acts much like a spin-lock. Windows offers InterlockedIncrement() and InterlocledDecrement() functions, which in the newer Microsoft compilers may be compiled as an intrinsic. I'm a bit allergic to context yielding synchronization objects thrown randomly into my server code. Does anyone know of any reasons to not use CAS-style programming here before I propose using it for smart_ptr<>? Glen

6 7

[Boost-bugs] [ boost-Support Requests-1082491 ] Linker error
by SourceForge.net 09 Dec '04

09 Dec '04

Support Requests item #1082491, was opened at 2004-12-09 13:52 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=1082491&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Linker error Initial Comment: Hi, Does anyone know why I get this linker error? fatal error LNK1104: cannot open file 'libboost_regex-vc7- sgd-1_32.lib'. I search my system for the file but no luck. I'm on Windows XP, using C++ .Net 7.0. Thanks in advance. Ken ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1082491&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

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

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

[ublas] matrix.hpp doesn't compile with Borland bcc32 5.6.4
by Nicola Musatti 08 Dec '04

08 Dec '04

Hallo, A translation unit that only includes #include <boost/numeric/ublas/matrix.hpp> from Boost 1.32.0 doesn't compile with Borland's bcc32 5.6.4 (BCB6 with Update 4), but it used to with Boost 1.31.0 . I get the following error messages: Build [C++ Error] traits.hpp(349): E2285 Could not find a match for 'std::abs(const _STL::complex<float>)' [C++ Error] traits.hpp(354): E2285 Could not find a match for 'std::sqrt(const _STL::complex<float>)' [C++ Error] traits.hpp(419): E2285 Could not find a match for 'std::abs(const _STL::complex<double>)' [C++ Error] traits.hpp(424): E2285 Could not find a match for 'std::sqrt(const _STL::complex<double>)' [C++ Error] traits.hpp(486): E2285 Could not find a match for 'std::abs(const _STL::complex<long double>)' [C++ Error] traits.hpp(491): E2285 Could not find a match for 'std::sqrt(const _STL::complex<long double>)' [C++ Error] vector.hpp(813): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(804): E2344 Earlier declaration of 'T' [C++ Error] vector.hpp(819): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(805): E2344 Earlier declaration of 'T' [C++ Error] vector.hpp(1030): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(1022): E2344 Earlier declaration of 'T' Cheers, Nicola Musatti

1 0

Solaris+gcc regression errors should be marked expected
by Caleb Epstein 08 Dec '04

08 Dec '04

Sorry, I think I sent an empty message just before this one. Please ignore it. There are several test failures for date_time and other Boost libs on sunos5+gcc (see for example http://tinyurl.com/4y6tx) that are due to incomplete wide character support on that platorm. This situation appears to be similar to a number other configurations (e.g. win32+mingw) which have a similar or identical tests marked as expected failures in the test matrix. I think sunos5+gcc should be treated similarly. Here is the relevant section of boost/config/stdlib/libstdcpp3.hpp: #if !defined(_GLIBCPP_USE_WCHAR_T) && !defined(_GLIBCXX_USE_WCHAR_T) # define BOOST_NO_CWCHAR # define BOOST_NO_CWCTYPE # define BOOST_NO_STD_WSTRING # define BOOST_NO_STD_WSTREAMBUF #endif -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Name checking in filesystem
by Walter Landry 08 Dec '04

08 Dec '04

Greetings, I have come across an annoying problem with the filesystem library. I have wrapped filesystem with Swig so that I can call it from python. I had to rewrite the filesystem::path implementation a little because Swig can't handle nested classes. In any case, once I got that sorted out, I wanted to do something like p=path(".bar") which doesn't work because filenames starting with a period are not allowed by the default name checking routine. Argh. Unfortunately, I can't figure out how to change the default name checker from python. If I worked at it long enough, I could probably work it out. But I am sure that I don't want to have to run something like path.default_name_check(no_check) at the beginning of every 10 line script. It is a particular piece of functionality (name checking) that just gets in the way. I would wager that most people using boost::filesystem from scripts would not want to have to deal with it, since it is completely different from every other portable, cross platform filesystem API. So to make a long story short, I think the default for boost::filesystem should be not to check for "portable" paths. This is different from a position I took earlier, where I thought that it is ok if I only have to set it once at the beginning. That is acceptable for large programs, but not for small ones. Regards, Walter Landry wlandry(a)ucsd.edu

6 14

[review-results] Smart Container Library
by Pavol Droba 08 Dec '04

08 Dec '04

Hi, I hereby announce that the Smart Container library is ACCEPTED into Boost. Congratulations and thanks to Thorsten Ottosen for providing us with this library. Most of the reviewers were in favor of acceptance, but there were several requests for improvements. I have consulted them with Thorsten and he proposed to do following changes. I consider them sufficient for acceptance. 1. add support for boost.range in insert functions, constructors etc 2. use void* implementation 3. improve docs as discussed during the review 4. add support for null values: - remove preconditions - add functions is_null( size_t idx ); is_null( iterator ); 5. add more debug checks after access to ptr_begin(), ptr_end() 6. reconfigure policies: ptr_vector<T,clone_manager> becomes ptr_vector<T,clone_allocator = something, std::allocator<T*> = std::allocator<T*> > or perhaps ptr_vector<T,clone_allocator = something< std::allocator<T* > > 7. improve tests I also suggest, that before the inclusion of the library into the boost distribution, the library should be brought in the discussion to verify, that all issues above have been addressed. Best Regards, Pavol Droba Review Manager

2 1

[date_time] SunPRO patch for date_names_put facet
by Caleb Epstein 07 Dec '04

07 Dec '04

The following patch is required to build date_time using the Sun Workshop C++ compiler. I mentioned this previously in another thread, but I fear it has been lost. --- boost/date_time/date_names_put.hpp~ 2004-12-01 08:58:32.846228000 -0500 +++ boost/date_time/date_names_put.hpp 2004-12-01 08:59:38.334228000 -0500 @@ -52,6 +52,11 @@ typedef std::basic_string<charT> string_type; static std::locale::id id; + +#if defined (__SUNPRO_CC) && defined (_RWSTD_VER) + std::locale::id& __get_id (void) const { return id; } +#endif + void put_special_value(iter_type& oitr, special_value_enum sv) const { do_put_special_value(oitr, sv); -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Two more logos...
by JOAQUIN LOPEZ MU?Z 07 Dec '04

07 Dec '04

...to add to the bunch. Variations on a previous theme. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

duplicate source files in boost- utf8_codecvt_facet
by Robert Ramey 07 Dec '04

07 Dec '04

We now have a at least one set of files more or less duplicated in boost. Ron Garcia's utf8_codecvt_facet is included in: boost/utf8_codecvt_facet.hpp boost/detail/utf8_codecvt_facet.hpp boost/libs/serialization/src/utf8_codecvt_facet.cpp boost/libs/program_options/detail/utf8_codecvt_facet.cpp boost/libs/doc/serialization/utf8_codecvt_facet.html boost/libs/serialization/test/test_utf8_codecvt_facet.cpp Leaving aside how this came to be, I would like to do the following: boost/detail/utf8_codecvt_facet.hpp boost/libs/detail // new directory boost/libs/detai/src/utf8_codecvt_facet.cpp boost/libs/detail/test/test_utf8_codecvt_facet.cpp boost/libs/detail/doc/utf8_codecvt_facet.html This would make both the serialization and program options libraries that much smaller and server our needs until a reviewed version of codecvt facets in added to boost. Robert Ramey

7 11