July 2004 - Boost - lists.boost.org

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

Moving to the Boost Software License
by Doug Gregor 26 Jul '04

26 Jul '04

We know we'd like to move over to the Boost Software License (BSL), but doing so is a bit of a pain. I've just updated John Maddock's bcp tool to add three new things to the HTML report it generates: (1) A list of files that can be converted over to the BSL at any time (but we need someone or something to do it) (2) A list of files that CAN NOT be converted because we don't have permission from one of the authors (3) A list of authors that we need to contact before files can be converted over to the BSL We have several things we need to do to make this happen. First, we need to contact the authors that prevent Boost code from being converted to the BSL. Second, we need to convert files that show up in the "can be converted" list over to the BSL, by replacing the existing licenses with the BSL. A solution to do this mechanically would be greatly appreciated; we can probably hack bcp to do it, but it's not entirely trivial; I'm slightly concerned it might not be legal and that we might need human volunteers to do it. Just looking at boost/function.hpp, here is the list of authors we need to contact. If you are on this list and would like to give your permission to move any of your code in Boost to the Boost Software License, version 1.0, please do one of the following: (A) Add your name and an e-mail address to more/blanket-permission.txt in CVS, or (B) Reply to the mailing list stating that you agree to allow your copyrighted code to be converted to the Boost Software License; I'll add you to the aforementioned file with a message time stamp. Adobe Systems Inc Bill Kempf Boost org Brad King Christof Meerwald Dan Watkins Darin Adler Dave Abrahams Doug Gregor Gennaro Prota Guillaume Melquiond Housemarque Oy Howard Hinnant Jaakko J rvi Jeremy Siek Jesse Jones Lie-Quan Lee Markus Schöpflin Martin Wille Mat Marcus Multi Media Ltd Paul Mensonides Steve Cleary Synge Todo The Trustees of Indiana University Toon Knapen (Note there are some near-misses that can easily be fixed, e.g. "Dave Abrahams" and "Doug Gregor", who are in the blanket permission file as "David Abrahams" and "Douglas Gregor"; in this case, we should probably just normalize the names in the source files). Doug

7 10

TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC in type_traits/is_convertable.hpp
by Aaron W. LaFramboise 26 Jul '04

26 Jul '04

These three lines near the end of boost/type_traits/is_convertable.hpp: TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(float) TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(double) TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(long double) don't compile on GCC 3.4.1 when -pedantic is specified. This is actually sort of strange, because it compiles without warnings when -std=c++98 -Wall -W are specified, and -pedantic itself is not supposed to generate errors, only warnings. So, there is probably at least a GCC bug here. Does anyone have any idea what this is about? $ g++ -pedantic -I../boost -c stuff.cpp In file included from stuff.cpp:1: ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: redefinition of `struct boost::is_convertible<float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: previous definition of `struct boost::is_convertible<float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: redefinition of `struct boost::is_convertible<const float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: previous definition of `struct boost::is_convertible<const float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: redefinition of `struct boost::is_convertible<volatile float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: previous definition of `struct boost::is_convertible<volatile float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: redefinition of `struct boost::is_convertible<const volatile float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: previous definition of `struct boost::is_convertible<const volatile float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: redefinition of `struct boost::is_convertible<double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: previous definition of `struct boost::is_convertible<double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: redefinition of `struct boost::is_convertible<const double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: previous definition of `struct boost::is_convertible<const double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: redefinition of `struct boost::is_convertible<volatile double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: previous definition of `struct boost::is_convertible<volatile double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: redefinition of `struct boost::is_convertible<const volatile double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: previous definition of `struct boost::is_convertible<const volatile double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: redefinition of `struct boost::is_convertible<long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: previous definition of `struct boost::is_convertible<long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: redefinition of `struct boost::is_convertible<const long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: previous definition of `struct boost::is_convertible<const long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: redefinition of `struct boost::is_convertible<volatile long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: previous definition of `struct boost::is_convertible<volatile long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: redefinition of `struct boost::is_convertible<const volatile long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: previous definition of `struct boost::is_convertible<const volatile long double, int64_t>' Pentium 4 on Windows XP Pro gcc 3.4.1 on mingw32 binutils 2.15 mingwrt 3.3 Thanks for your attention, Aaron W. LaFramboise

2 2

Re: [boost] Re: [test] regression with latest change tolibs/test/src/test_tools.cpp
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

Hi Gennadiy ----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Domingo, Julio 25, 2004 9:55 pm Asunto: [boost] Re: [test] regression with latest change tolibs/test/src/test_tools.cpp > > FYI, latest changes to the aforementioned > > file seem to break things for msvc-stlport, > > as shown for instance at: > > Dave tried to use "using namespace std" solution. It's already > fixed in cvs. > Thanks for the quick response! Let's see if this fixes things up in the next testing cycle. Best, Joaquín M López Muñoz Telefónica, Ingectigación y Desarrollo

3 5

Re: [boost] [Important For All Boost Contributors] BSL Status Update
by Stephan T. Lavavej 26 Jul '04

26 Jul '04

[Stephan T. Lavavej] > I ran it on all of the directory names in libs, in current > Boost CVS, except for CVS, python, and serialization - the > last two gave errors. [Doug Gregor] > Thanks! Sure. I had to copy a .css file to a different directory to get bcp to work in the first place. I don't know why bcp was complaining about python and serialization, and I didn't know enough to hack around it. [Stephan T. Lavavej] > The following people ARE in blanket-permission.txt, but have > used these alternate names in Boost code. > Doug Gregor [Doug Gregor] > This one should now be fixed... Great! [Stephan T. Lavavej] > * "Files that could be converted to the Boost Software > License" should be. There are a lot of files there. [Doug Gregor] > I'll see if I can come up with a program to do this > automagically. We have to be _very_ careful with this, > though. Ok. I agree, that's something that can't be screwed up. [Stephan T. Lavavej] > I don't think "boost org" is a real organization. [Doug Gregor] > I'll take care of this. Awesome! [Stephan T. Lavavej] > * The following organizations (or people with really, really > weird names) hold copyrights to non-BSL libraries. They > should be contacted. > Free Software Foundation Inc [Doug Gregor] > They're not going to agree to the BSL, that's for sure :) The Boost site says that all libraries in Boost, even those not under the BSL, conform to Boost licensing requirements (which excludes the GPL and friends). So the FSF code in Boost shouldn't be under the GPL or any of its derivatives. From my decidedly non-lawyer point of view, the BSL is just a precise statement of the Boost licensing requirements. So the FSF may not be ideologically opposed to BSL conversion. But I don't know what the FSF code in Boost is actually licensed under. > This only affects the Graphviz parser in the BGL, which is > due for a rewrite soon anyway. Ok. This does not personally affect me (I'm real interested in bind and smart_ptr for work), but it should be cleared up. Thanks for looking into some of the [quasi-]organizations I listed. > We should make this a requirement, I think. Agreed. > Probably just a form of license not matched by one of the > regexes in bcp. Easily fixed, with a little time investment. > it might be more useful to have that scorecard showing which > libraries are completely under the BSL. Both are easy enough > to implement. Such a scorecard would be excellent (something to point Microsoft's Big Scary Lawyers at). Thanks for your continuing great work! Stephan T. Lavavej

4 3