- Boost - lists.boost.org

ANN: Synopsis 0.7 - a source code inspection tool
by Stefan Seefeld 26 Jul '04

26 Jul '04

Synopsis 0.7 released ===================== I'm happy to announce the release of Synopsis 0.7. This is a major feature enhancement and bug fix release. Among the more important new features: * refactored Cpp processor (now a stand-alone processor) * new C processor * feature enhancements and bug fixes in the C++ processor * cleanup and bug fixes in the HTML formatter (now generates valid XHTML) * new SXR cross referencer (see http://synopsis.fresco.org/sxr/files/ for an example) * new C++ API for easier C++ backend programming * Synopsis has been ported to (native) windows An ongoing efford is to produce correct (and useful) documentation for the boost libraries (http://boost.org) You may have a look at the current status of this efford at http://synopsis.fresco.org/boost, containing a reference manual for boost::python (this site is quite large !). For information, see http://synopsis.fresco.org For (developer) documentation, see http://synopsis.fresco.org/docs.html To contact the developers, see http://synopsis.fresco.org/mailinglists.html To report bugs, see http://synopsis.fresco.org/issues/bug About Synopsis ============== Synopsis is a source code inspection framework supporting a variety of languages (right now C++, C, IDL, and Python). Its main focus is source code documentation, but effords are being made to support other forms of introspection such as code generation. Synopsis provides a framework of processors that can (via a simple and straight-forward scripting interface) be used to construct sophisticated pipelines to process abstract syntax trees (ASTs). Regards, Stefan

3 3

[multi_index] mbergal tests
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

mbergal tests (see http://www.meta-comm.com/engineering/boost-regression/developer/multi_index…) fail for multi_index, but the error messages are not any helpful: a couple of warnings followed by Failure while executing 'cl' compiler ...email Comeau for advice. Any clue about what to about this? Thank you. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Mini-reviews
by Reece Dunn 26 Jul '04

26 Jul '04

Tom Brinkman wrote: >Mini-reviews would be very useful. Im shur that each >boost developer/user could contribute a few small, >useful algorithms. It would be a great way to >increase the level of participation by developers who >want to contribute but dont have the time to write a >complete library. I agree. What about small/simple classes, e.g. an object_counter class that keept track of the number of instances of all objects derived from it? This would also make it easier to extend existing libraries like mpl and filesystem (directory iterator). Is there a streamlined system for restructuring a library or changing its interface, e.g. Boost.Random and Boost.Iterator? >We should also discuss to where to place the >algorithms /code within the boost namespace. This would depend upon the type of functions. I can think of the reciprocal trigonometric functions: sec x = 1 / cos x csc x = 1 / sin x cot x = 1 / tan x = cos x / sin x These would best reside in boost::math. Others would fit in different places. I suggest that any mathematics-related algorithms be placed in boost::math, string manipulation algorithms boost::algorithm::string and the others in boost::algorithm. General classes would go in the boost namespace. If the algorithm/class is an extension of an existing library, that should reside in the library's namespace. If the developer wants the algorithm(s)/class to go into a different namespace, a rational should be given. >I could create a document that lists all the >algorithms under consideration with a small summary. >The boost members could than accept/reject each >algorithm and offer suggestions. It would also be worth considering where the algorithms/classes should reside (w.r.t. the files section and the boost-sandbox). It would also be useful to post the algorithms/classes and their descriptions in the review e-mail to facilitate discussion with a link to the code. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

[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