- Boost - lists.preview.boost.org

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

Re: [boost] Re: BOOST_TRY like macros: time to add them?
by JOAQUIN LOPEZ MU?Z 11 Mar '04

11 Mar '04

----- Mensaje original ----- De: Gennaro Prota <gennaro_prota(a)yahoo.com> Fecha: Jueves, Marzo 11, 2004 8:36 pm Asunto: [boost] Re: BOOST_TRY like macros: time to add them? > On Thu, 11 Mar 2004 12:21:09 -0500, David Abrahams > <dave(a)boost-consulting.com> wrote: > > >I think if you review this thread you'll see that there's no > argument. > No argument in favor of the macros? Yes, I see that. [...] Now I'm lost. Are you saying try-catch-rethrow macros for coping with BOOST_NO_EXCEPTIONS along the line proposed by Pavel are not good? Why not? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[indexed_set] volunteers wanted for testing
by Joaquín Mª López Muñoz 11 Mar '04

11 Mar '04

Review for indexed_set will take place in a couple of weeks; I'd like to ask for volunteers who want to try the tests on their compilers/platforms to make sure it works on a reasonable number of them. Current version has been tested for MSVC++ 6.0 SP5, ICC++ 7.1 and GCC 3.3.1 (cygwin). In particular, I'm interested in ICC+ 8.0 and MSVC 7.1, where prior versions of the library were tested without problems. Last version of the library (9.2) available at http://groups.yahoo.com/group/boost/files/indexed_set.zip Thank you in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 10

[filesystem] create_directory() & create_directories() return bool
by Beman Dawes 11 Mar '04

11 Mar '04

create_directory() no longer throws if the directory already exists. create_directory() and create_directories() now return a bool indicating if a directory was actually created. Both throw if the path argument exists and is not a directory. Docs and test cases updated accordingly. --Beman

1 0

[Signals] Added disconnect() based on function object equivalence
by Douglas Gregor 11 Mar '04

11 Mar '04

Since we're discussing the issue, I've added an experimental disconnect() member function to signals that allows one to disconnect equivalent slots, e.g., void foo(); void bar(); signal<void()> sig; sig.connect(&foo); sig.connect(&bar); sig.disconnect(&foo); // disconnects foo, but not bar We could also reconsider the += and -= syntax, since support for -= now makes some sense. Doug

2 1

iterator adaptors problem
by Pavol Droba 10 Mar '04

10 Mar '04

Hi, I have a problem with iterator_facade usage. Error is reported by Comeau and MIPSPro compilers: An error output can be found in regression tables: http://tinyurl.com/37mxz The compiler is reporting, that iterator_core_access cannot access the private equal() function, althought it has been marked as friend. My iterator class is publicaly derived from iterator_facade and privately from another templated class. Is it possible, that multiple inheritance creates the problem? Thanks for any help. Pavol

3 6

lambda BLL question
by Neal D. Becker 10 Mar '04

10 Mar '04

I was just trying out lambda and I have a question. I have a template class Ave template<typename in_t, typename Scale> struct Ave {...} It takes a function type argument "Scale". Here's a test: typedef typeof (_1 * 0.1) some_type; some_type func (_1 * 0.1); // Ave<double, typeof (_1 * 0.1)> ave (_1 * 0.1); << this will work Ave<double, some_type> ave (func); << this will also What is the preferred way to do this without "typeof"? How do I get the type returned by the lambda expression to feed to the template Ave?

2 1