- Boost - lists.boost.org

[config] seems like VC 8.0 needs BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

Tests at RudbekAssociates for multi_index in VC 8.0 show this recurrent error: error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail' The code causing the problem has the following form: ***********BEGIN CODE*********** namespace boost{ namespace multi_index{ namespace safe_mode{ template<typename Iterator> inline void detach_equivalent_iterators(Iterator& it) { ... } }// namespace boost::multi_index::safe_mode namespace detail{ class safe_iterator_base { ... template<typename Iterator> friend void safe_mode::detach_equivalent_iterators(Iterator&); }; } // namespace boost::multi_index::detail } // namespace boost::multi_index } // namespace boost ***********END CODE*********** which AFACIS seems to indicate that VC 8.0 does *not* support member template friends (VC 7.1 didn't support them either) and thus BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be defined for it (it isn't). I've searched through the VC 2005 beta docs and, allegedly, member template friends are supported, so this particular problem could be a bug rather than complete lack of support for this feature. Maybe someone with local access to VC 8.0 can test the above code and see what happens (I currently don't have the time and resources to try myself.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: DLL library (Was: [boost] Re: additional boost libraries?)
by Reece Dunn 26 Jul '04

26 Jul '04

Vladimir Prus wrote: >Hi Mattias, > > On Fri, 23 Jul 2004 13:49:22 +0400, Vladimir Prus <ghost(a)cs.msu.su> >wrote: > > > static imported_function<void()> apiFunc( "ApiFunc", "OSLib" ); > > > > Couldn't find a nice point in the thread at which to insert this > > comment, so I'll just spit it out: Since we have both the name of the > > function and the function type, and given that a lib such as this > > should provide a platform-independent interface, would it be useful if > > the library automatically mangled the name according to the type? > >I think you've missed something ;-) Even my initial reply inthe "additional >boost libraries" thread mentioned the possibility of calling functions >which >are not "extern "C". At least two other persons seems to want this. I find >this would be nice, though not critical at all. Would it be possible to have a mangle function, then you could do something like: static imported_function<void()> apiFunc( mangle::mwcw( "ApiFunc" ), "OSLib" ); This would mean that imported_function need only know how to get the function (e.g. using GetProcAddress in Win32) and not worry about the name mangling scheme used. The name mangling could then be handled by a mangler/demangler library that would be useful in diagnostics, e.g.: template< typename T > inline void print_type( const T & t ) { std::cout << demangle::gcc3( typeid(t).name()); } Also, wouldn't it be better to have import as a function of shared_library, so you could do something like: boost::shared_library mylib( "user32.dll" ) typedef ... msgboxA_fn; msgboxA_fn mbA = mylib.import< msgboxA_fn >( "MessageBoxA" ); msgboxW_fn mbW = mylib.import< msgboxW_fn >( "MessageBoxW" ); With the possible Win32 implementation of, but using boost::function: namespace boost { class shared_library { private: HANDLE hDLL; public: template< typename Function > inline Function * import( const char * fn ) { if( hDLL == 0 ) return( 0 ); return( reinterpret_cast< Function * >( ::GetProcAddress( hDLL, fn ))); } public: inline shared_library( const char * fn ): hDLL( ::LoadLibrary( fn )) { } inline ~shared_library() { if( hDLL ) { ::FreeLibrary( hDLL ); hDLL = 0; } } }; } Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Serialization bug
by Matthias Troyer 26 Jul '04

26 Jul '04

There is a bug in serialization which becomes apparent on 64-bit machines, such as an AMD Opteron: /asgard/home/phys/troyer/src/boost/boost/archive/ polymorphic_oarchive.hpp:66: error: `virtual void boost::archive::polymorphic_oarchive::save(int64_t)' and `virtual void boost::archive::polymorphic_oarchive::save(long int)' cannot be overloaded /asgard/home/phys/troyer/src/boost/boost/archive/ polymorphic_oarchive.hpp:67: error: `virtual void boost::archive::polymorphic_oarchive::save(uint64_t)' and `virtual void boost::archive::polymorphic_oarchive::save(long unsigned int)' cannot be overloaded long and int64_t are the same when using the gcc compiler on a 64-bit machine and this overload fails. Matthias

1 0

Re:[boost] [multi_index] regrssion with Intel 8.0 for Linux.
by Robert Ramey 26 Jul '04

26 Jul '04

Joaqu?n M? L?pez Mu?oz wrote: Intel will let you download the lastest compiler version on a trial basis for free for 30 days. I did it and it was very helpful - (sadly, my license has now expired) You could do that if all else fails. Robert Ramey

1 0

Re:[boost] Re: question regarding vacpp tests and mpl
by Robert Ramey 26 Jul '04

26 Jul '04

Toon Knapen wrote: Message: 13 Date: Mon, 26 Jul 2004 15:02:27 +0200 From: Toon Knapen <toon.knapen(a)fft.be> >Aleksey Gurtovoy wrote: >> I think the most practical way to >> approach the error is to simplify the above to the bare minimum >> (ignoring the semantics for now), and see how the compiler reacts. For >> instance, >> >> #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) >> typedef >> BOOST_DEDUCED_TYPENAME mpl::apply_if< >> is_base_and_derived<basic_traits, T>, >> traits_class_level<T>, >> mpl::int_<object_serializable> >> >::type type; >> #else >> // original code ... >> >> #endif >> >I tried Aleksey's suggestion above and it seems to improve the situation >for the serialization lib on vacpp. I suggest to apply the suggested modif. The problem is that the rest of the library depends upon the semantics of the operation. So, I can't just roll in the modification and declare victory. I can see experimenting as a way to discover an equivalent formulation that will compile under vacpp. But doing this isn't practical for me with a one day test turnaround. So I feel I have no choice but to set it aside for now. Of course, if "someone" wants to entertain himself with this little puzzle and has convenient access to the compiler - then I would be very appreciative. Thanks for your help. Robert Ramey

1 0

[multi_index] regrssion with Intel 8.0 for Linux.
by Joaquín Mª López Muñoz 26 Jul '04

26 Jul '04

One out of the 18 tests is making ICC 8.0 go wild, please see http://tinyurl.com/6u4og icc: error: Fatal error in /opt/intel_cc_80/bin/mcpcom, terminated by segmentation violation compilation aborted for ../libs/multi_index/test/test_update_main.cpp (code 1) . /opt/intel_cc_80/bin/iccvars.sh icc -c -w1 -g -O0 -I"../bin/boost/libs/multi_index/test" -I"/boost/head-regression/boost" -o "../bin/boost/libs/multi_index/test/test_update.test/intel-8.0-linux/debug/test_update_main.o" "../libs/multi_index/test/test_update_main.cpp" Anyone has any idea what to do about this? The offending test is not more complicated than the others, so this is most bizarre. If anyone with local access to the compiler could try commenting out code to see which particular piece of the test is making ICC bang, I'd much appreciate it. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 3

RE: [boost] Re: DLL library (Was: Re: additional boost libraries?)
by Reece Dunn 26 Jul '04

26 Jul '04

Vladimir Prus wrote: >Reece Dunn wrote: > > Would it be possible to have a mangle function, then you could do > > something like: > > > > static imported_function<void()> apiFunc( mangle::mwcw( "ApiFunc" >), > > "OSLib" ); > > > > This would mean that imported_function need only know how to get the > > function (e.g. using GetProcAddress in Win32) and not worry about the >name > > mangling scheme used. > >I though more about a policy function/class. Something like: > > boost::dll my_dll("foo", cpp_mangler); > boost::dll my_dll2("foo", c_mangler); The problem with this is if you need different mangling schemes for the same library then you will have several instances of the same library loaded (not sure how Windows handles this). A possibility is to have the mangler specified in the constructor (defaulting to extern "C" functions) be the default mangler and have another function where you can explicitly state which mangler you need: boost::dll mylib( "mylib", gcc3_mangler ); mylib.import< ... >( "get_id" ); // use GCC3 mangling mylib.import< ... >( "factorial", c_mangler ); // use extern "C" mangling > > The name mangling could then be handled by a > > mangler/demangler library that would be useful in diagnostics, e.g.: > > > > template< typename T > > > inline void print_type( const T & t ) > > { > > std::cout << demangle::gcc3( typeid(t).name()); > > } > >That's for sure. And in other contexts too. True. If you go for an external policy-based mangler like above then you don't need to worry about name mangler support (e.g. does the library have VC or GCC3 mangling?) immediately. You can provide a base set and add to that set later. >I also wonder if it makes sense to sumbit just "dll" library, or some >additional plugin support need to be developed first. What sort of plugin support are you looking for? Do you mean something like COM/CORBA support or wrapper, e.g. something that can target both (and others like them) in one implementation? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

DLL library (Was: [boost] Re: additional boost libraries?)
by Vladimir Prus 26 Jul '04

26 Jul '04

Hi Sven, > > Probably, you could start by explaining your vision of the library first. > > Of three points you've given: > > The problems I would like to solve for myself are: > > 1) Often you need to write progams that need to work on different versions > of a particular OS, with later versions having additional API calls that > you could use. > void MyAPIStub() > { > static imported_function<void()> apiFunc( "ApiFunc", "OSLib" ); > > if ( !apiFunc ) > { > // do something here > } > > apiFunc(); I think this is reasonable use case. I wanted something similiar recently. I have a library which calls user-provided 'userinit' function. To allow the user to not provide the function, the library has its own definition. So, when the library's version is called, it call 'dlsym' to find the 'next' definition of 'userinit' and if it exists, calls it. But I'm afraid this semantic (find the next definition of symbol) is Unix-specific. I'm not even sure if two symbols with the same names in different DLLs are allowed on Windows. > Altough I acknowlege that the locking required in multi-threaded progams > would clutter the syntax (more than) a little. I'm not sure it's necessary, unless the called function is not thread-safe. > 2) When creating plugin interfaces, having to go through extern "C" is a > bit ugly to me. At the same time it ditches the C++ type safety. Being able > to export a C++ plugin function and have the import library figure out the > name mangling for me would improve the both the readability and the > correctness of the program I don't care that much about type safety of a single function, given that implementing that type-safety can be hard. But, of course, this would be a nice addition if you want to code it ;-) I'm more interested in nice interface to declare plugins. For example, on Unix static initialisers in a library are run when it's opened, so you can do something like this: extern std::map<std::string, Codegen*> codegens; // defined somewhere in application class Codegen1 {}; class Codegen2 {}; RegisterHelper<Codegen1> X(codegens, "1"); RegisterHelper<Codegen1> X(codegens, "2"); But will this work for Windows? Can DLL have unresolved external references? Are static initializers run when DLL is opened? If not, we'd have to do much less nice: void init_codegens(std::map<....>& m) { m["1"] = new Codegen1; m["2"] = new Codegen2; } It's less nice, because the first approach allows to register different codegens in different translation units. BTW, I think if you want typesafety, not don't need overloading, you can do this: // caller typedef void (right_type)(int, foo, bar); void* fp = ... get raw pointer to function ...; ((right_type*)fp)(....., typeid(right_type).name()); // callee typedef void (right_type)(int, foo, bar); void func(int, foo, bar, char* sig) { assert(strcmp(sig, typeid(right_type).name()) == 0); ..... } > > boost::function<void (void)> f > > = static_cast<void (*void)>dlsym(h, "whatever") > > > > - Volodya > > Yeah, yesterday morning I was already thinking more of something like this > > boost::function<void()> f1 = import<void()>( "lib", "whatever" ); > boost::function<void()> f2 = import<void()>( lib, "whatever" ); > boost::function<void()> f3 = import<void()>( lib, "whatever", > some_decorator () ); Yes, I think that's just as fine. I'm a bit suspicious about passing library name as string -- you'd need to keep a list of all opened dll handles somewhere. Maybe just class 'dll' with method 'import'? > As far as the cdecl decorator and the tool is concerned. I have always > considered it very likely that I would fail and not achieve what I want, > but that won't stop me from trying. ;-) Just keep us informed somehow... I'd be interested in working on this too, though won't have any time till September. - Volodya

7 10

Re: question regarding vacpp tests and mpl
by Toon Knapen 26 Jul '04

26 Jul '04

Aleksey Gurtovoy wrote: > Robert Ramey writes: > >>The serialization library is failing all tests with IBM visual age compiler. >>Errors occur within mpl. > > > Not quite, I am afraid. Considering that the 'apply_if' test itself > compiles without an error, this looks more like a problem with the > particular context where the facility is used: > > "/home/tk/boost_regression/boost/boost/serialization/level.hpp", line > 44.9: 1540-0038 (S) The name "typename mpl::apply_if< > boost::is_base_and_derived< boost::serialization::basic_traits, > boost::serialization::nvp<A[9]> >, > boost::serialization::implementation_level< > boost::serialization::nvp<A[9]> >::traits_class_level< > boost::serialization::nvp<A[9]> >, boost::mpl::int_<3> >::type" is > not a type. > > Looking at the code in "level.hpp", this is one complicated typedef! > > typedef > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_base_and_derived<basic_traits, T>, > traits_class_level<T>, > //else > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_fundamental<T>, > mpl::int_<primitive_type>, > //else > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_class<T>, > mpl::int_<object_class_info>, > //else > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_array<T>, > #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) > mpl::int_<not_serializable>, > #else > mpl::int_<object_serializable>, > #endif > //else > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_enum<T>, > #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) > mpl::int_<not_serializable>, > #else > mpl::int_<object_serializable>, > #endif > //else > mpl::int_<not_serializable> > >::type > >::type > >::type > >::type > >::type type; > > > It's inefficient, too (you don't need all these '::type's except the > very last one), but in any case: I think the most practical way to > approach the error is to simplify the above to the bare minimum > (ignoring the semantics for now), and see how the compiler reacts. For > instance, > > #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) > typedef > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_base_and_derived<basic_traits, T>, > traits_class_level<T>, > mpl::int_<object_serializable> > >::type type; > #else > // original code ... > > #endif > I tried Aleksey's suggestion above and it seems to improve the situation for the serialization lib on vacpp. I suggest to apply the suggested modif. Sorry for the late response but I was on vacation. Toon

1 0

Attention Doug: Tabs in files...
by Rene Rivera 26 Jul '04

26 Jul '04

Doug, Please fix your editor so that you don't introduce tabs into code... http://www.boost.org/regression-logs/inspection_report.html#bcp Boost Inspection Report -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1