- Boost - lists.boost.org

BOOST_TRY like macros: time to add them?
by Pavel Vozenilek 12 Mar '04

12 Mar '04

Disabling try/catch through preprocessor when compiling without exception support was suggested e.g by Robert Ramey in: http://aspn.activestate.com/ASPN/Mail/Message/boost/1799735 Right now there are 3 libraries near review, each using their own set of similar macros: - circular_buffer - indexed_set - serialization The reasons to use macros instead of RAII is convenience and performance. Some compilers (BCB) do not allow try/catch with exceptions disabled so some solution is needed. It would be better to have and use standardized macros in Boost. Example: macros used in indexed_set: #if !defined(BOOST_NO_EXCEPTIONS) # define BOOST_INDEXED_SET_TRY try # define BOOST_INDEXED_SET_CATCH(x) catch(x) # define BOOST_INDEXED_SET_RETHROW throw #else # define BOOST_INDEXED_SET_TRY # define BOOST_INDEXED_SET_CATCH(x) if(0) # define BOOST_INDEXED_SET_RETHROW #endif Compiles w/o warnings on VC6+, BCB gives unreachable code warning (but I'll try to find workaround). /Pavel

12 32

Thread usage ?
by raja 12 Mar '04

12 Mar '04

Hi, I am trying out boost thread libraries with VC 7.1 Here are my includes : #define _MSC_VER 1310 #define BOOST_LIB_NAME "boost_thread" #define BOOST_LIB_DIAGNOSTIC "on"// Show library file details. #include <boost/config/auto_link.hpp> #include <boost/thread/thread.hpp> #include <iostream> I am getting the following error : c:\Boost\include\boost-1_31\boost\config\auto_link.hpp(269) : fatal error C1189: #error : "Mixing a dll boost library with a static runtime is a really bad idea..." Looks like I am missing some #define. Would appreciate if someone can let me know about this. Raja

2 1

Re: [boost] small addition to functional
by Fredrik 12 Mar '04

12 Mar '04

John Torjo wrote: >Hi all, >I think since member functions can be wrapped up as >functors, why not >same for member data? >Therefore, I think this could be a useful addition to >functional: <<snip>> >What do you think? I think Peter Dimov has already thought about this ;) Read the current mem_fn docs carefully and you'll find a data-case also. I agree it's very useful functionality. It was added fairly "silently" though (mid 2002 IIRC) which might have made people miss it(?). // Fredrik Blomqvist

4 7

function_equal and function::contains committed
by Douglas Gregor 12 Mar '04

12 Mar '04

Based on the discussion with Peter Dimov and Brian McNamara, I've checked in boost/function_equal.hpp with the new function_equal function. Overload boost::detail::function_equal_impl with a final argument of "int" in libraries that need to be compatible with older compilers. function_equal is documented as part of Boost.Function (because it needed a home somewhere inside BoostBook). function<> now has a contains() member function and uses function_equal instead of operator ==. Doug

1 0

Boost 2 - development in long term
by Pavel Vozenilek 12 Mar '04

12 Mar '04

Described is an idea how Boost can move on in the future. By future I mean 2-5 years, definitely not tomorrow or next month. Support for sub-standard compilers is taking away lot of time and energy of library writers. It also makes result code quite hard to understand and modify. Shouldn't only so many people be stuck with old equipment... What could be done: - create branch or fork of Boost in CVS, say Boost 2. - this project will have exactly the same structure as current Boost (directories/libraries/tests). - the project will be initially empty. - one by one, libraries will be removed of kludges, and workarounds (all of them, w/o exceptions) and copied into Boost 2. This includes: - fixes for nonconforming compilers (#ifdef BOOST_MSVC ...) - fixes for substandard STL (e.g. old Dinkumware) - fixes to deal with missing exception support - the converted libraries will be tested only with very recent compilers which are supposed to be conformant (GCC 3.4, VC8, Intel C++ 8, Metrowerks 9.2, Comeau). Why this may work: - all existing infrastructure (the tests) could be reused w/o change. - no need to deal with non-standard systems makes the cleanup less time consuming. - with no need to deal with non-standard systems it may be interesting work and fun for library writers, again. - compiler vendors may take it as incentive to improve their system, rather to rely on people will find workarounds. This effect can be already seen today. What would it require: - some site with latest compilers which would continually and automatically run all the tests. Not all people have access to newest tools. - the cleanup could be done by original library author or by someone who feels knowledgeable with it. - core libraries need to be identified and ported first. What to do with current Boost 1.XX: - the development will continue as it is now, as long as needed and feasible (my guess are few years more). - new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'. Problems: - how to keep both branches up to date with fixes and changes? This is real problem and should be solved by requiring every change in Boost 1.XX be considered for Boost 2. Backporting from Boost 2 to Boost 1.XX would be optional but rare. Hopefully most libraries are rather mature and don't go through major rewrites. Even if so, making clean version should be relatively painless. - should there be two sets of documentation? No, the documentation should not change except removing information about old systems support. This should be reasonably easy. - woudln't people with old compilers feel abandoned? Yes, but development for 1.XX should continue as long as needed/feasible. In few years hopefully support for VC6 and Borland will dimish. - there's no time to do yet more work: this should be long term project. Individual libraries can be ported at individual pace and independently. - code without kludges may not compile on ANY existing compiler: so be it. Next version of compiler will be hopefully better. Workarounds should be forbidden or very, very rare. Who will benefit of this all: - library writers who do not want to support old systems (less pressure on them) may spend more time with design. This gets more important if more powerfull/complex libraries will emerge. - users with new compilers (they can be more sure the library remains maintainable and may even be able to understand its inner, too). Their existing code using Boost should compile without changes. - compiler vendors will be able catch more errors. - standard comittee may be more interested in clean code. - if/when the world moves to C++0x it will be easier to move Boost there (this is beyond horizont of this idea though). What it it all fails: - Boost 1.XX should be unaffected by branching and could continue as if nothing had happened. I remind again this idea is about long term development of Boost. I think it has biggest effect for the effort spent. /Pavel

8 10

On bind::operator==, again
by Peter Dimov 12 Mar '04

12 Mar '04

What do you think this expression should do: bind(f, _1) == bind(g, _1) Currently, boost::bind returns f == g when f and g are of the same type, and fails at compile type otherwise (this is the equality comparison feature Doug requested). lambda::bind returns lambda(x) { return f(x) == g(x) }. It is clear that a future boost::bind that has limited lambda support would be even more problematic (as would be a future equality comparable boost.lambda). In that case, the expression will always compile, but do something different depending on whether f and g are of the same type. -- Peter Dimov http://www.pdimov.com

5 28

Explicit instantiation of boost::shared_ptr<SomeClasss>
by Greg Clayton 11 Mar '04

11 Mar '04

I am trying to do explicitly instantiate specific shared_ptr class for export from a Win32 DLL (currently with MSVC6, and eventually in VS2003). I have followed the Win32 rules found at: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com… and have something like: // Provide the storage class specifier (extern for an .exe file, null // for DLL) and the __declspec specifier (dllimport for .an .exe file, // dllexport for DLL). // You must define EXP_STL when compiling the DLL. // You can now use this header file in both the .exe file and DLL - a // much safer means of using common declarations than two different // header files. #ifdef EXP_STL # define DECLSPECIFIER __declspec(dllexport) # define EXPIMP_TEMPLATE #else # define DECLSPECIFIER __declspec(dllimport) # define EXPIMP_TEMPLATE extern #endif EXPIMP_TEMPLATE template class DECLSPECIFIER boost::shared_ptr<SomeClass>; When I look through the exports, some needed class functions seem to be missing from the DLL, and linking fails. Most notable are: void boost::shared_ptr<SomeClass>::reset(SomeClass*) This function is declared in the shared_ptr header file as: template<class Y> void reset(Y * p); The reset function which does not take an argument is in the export list which is defined as: void reset(); // never throws And if I have a forward declaration of class followed by explicit instantiation, such as found below: class SomeClass; EXPIMP_TEMPLATE template class DECLSPECIFIER boost::shared_ptr<SomeClass>; The constructor that takes a class pointer is not generated: public: __thiscall boost::shared_ptr<class SomeClass>::shared_ptr<class SomeClass>(class SomeClass *) which is declared as: template<class Y> explicit shared_ptr(Y * p); Do I need to do extra explicit instantiations for the class members whose declarations start with "template<class Y>"? If so how does this syntax work? Any help or tips would be most appreciated. Greg Clayton

2 1

[math constants] a new approach (perhaps)
by Thorsten Ottosen 11 Mar '04

11 Mar '04

Dear boosters, I discovered something that at least was new to me. It's a simple way of coding floating point constants s.t. 1. no overhead at all 2. no order dependencies occur 3. the context in which the constant appears decides the precision of the constants [important in template code] 4. whenever a narrowing or widening conversion is required, explicit action must be taken by the programmer to determine what he wants 5. all precisions of the constants co-exist, so there is no need for several headers Example: #include "math_constant.hpp" #include <iostream> #include <cmath> #include <iomanip> using namespace std; template< typename T > void test(); int main() { cout << setprecision( 10 ); test<float>(); test<double>(); test<long double>(); // cout << pi; // ambiguous cout << float( pi ) << " " << double( pi ) << " " << (long double)( pi ); // ok // int i = pi; // ambiguous int i = float( pi ); // ok cout << sqrt( float( pi ) ); } template< typename T > void test() { T two_pi = T(2) * pi; two_pi = T(pi) + pi; // note: pi operator X() pi is ambiguous T plus = T(1) + pi; T minus = pi - T(1); T divide = pi / T(2); T all = pi + T(3) - T(pi) * pi / T(3); // also ambiguous cout << T( pi ) << " "; } Any comments are more than welcome. I know there are several proposals for defining math constants, but I don't see what the big problems are (so please help me understand them :-) ) br Thorsten

8 35

Re: [boost] Re: Boost 2 - development in long term
by JOAQUIN LOPEZ MU?Z 11 Mar '04

11 Mar '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Jueves, Marzo 11, 2004 9:19 pm Asunto: [boost] Re: Boost 2 - development in long term > Robert Geiman <rgeiman(a)buckeye-express.com> writes: > > > My point is, there will be a point in time where most compilers > > support template partial specialization, etc, and all that extra > code> that adds support to outdated compilers is way more trouble > than it'll > > be worth. We obviously aren't at that point right now, but at some > > point we will be. > > > > I don't think having Boost 2.x contain NO compiler hacks is a good > > thing, but it would be nice if there was a Boost feature list of all > > C++ features compilers must support to use Boost. These features > > could be added to the list when it's generally accepted that most > > compilers support these features, so then library writers can stop > > writing hacks to support those outdates compilers and even remove > > hacks to make the code smaller, cleaner, and easier to > understand and > > maintain. > Not that I love the idea of Boost 2 (B2 in the following), but maybe there's a reasonably manageable way to automate some of the process of converting Boost libraries into B2 form: * Identify the few compilers/stdlibs qualifying as B2 * Take the set of BOOST_NO_XXX macros in Boost.Config applying to any of the B2 compilers/stdlibs. Let us call these B2 defects. * Create an automatic tool that takes the source code of a B1 library and: - remove all #ifdef BOOST_NO_XXX sections where BOOST_NO_XXX is *not* a B2 defect. - remove all BOOST_WORKAROUND sections where the compiler/stdlib is not B2. This tool hopefully would give a compilable B2 source code, or at least something simple to get correct by manual postprocessing. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

bind vs. mem_fn with data members
by David Abrahams 11 Mar '04

11 Mar '04

This surprised me; should it have? #include <boost/bind.hpp> #include <boost/mem_fn.hpp> struct X { int y; }; int main() { boost::mem_fn(&X::y); // OK boost::bind(&X::y); // Error! } -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2