August 2002 - Boost-users - lists.preview.boost.org

RE: [Boost-Users] Re: boost::object_pool
by scleary＠jerviswebb.com 22 Aug '02

22 Aug '02

> -----Original Message----- > From: wugui [mailto:yg-boost-users@m.gmane.org] > > another question: > > how make boost::object_pool thread_safe? To make a pool object thread-safe, guard all access with a mutex. -Steve

1 0

RE: [Boost-Users] boost::object_pool
by scleary＠jerviswebb.com 22 Aug '02

22 Aug '02

> -----Original Message----- > From: wugui [mailto:yg-boost-users@m.gmane.org] > > class A; > class B; > class AB : virtual public A, virtual public B; > > all destruct is virtual > > boost::object_pool<AB> pool_ab; > > B * pb = pool_ab.constuct(); > pool_ab.destroy(pb); // is this right? This looks right to me; what "pool_ab.destroy(pb);" does is: pb->~AB(); free(pb); // puts pb back in the free list of pool_ab -Steve

1 0

Kai C++ for Linux and Solaris
by Wintermantel , Marc 22 Aug '02

22 Aug '02

Hi everybody, We really badly need the latest version available of Kai C++ Compiler for Linux and Solaris. If someone wants to sell his copy, please write me!!! We would really be grateful. Yours truly, Marc Wintermantel Marc Wintermantel IMES - Structures Technology ETH Zurich, LEO C4 Leonhardstrasse 27 CH- 8092 Zurich Tel. ++41 1 633 35 32 Fax. ++41 1 632 17 02 [Non-text portions of this message have been removed]

1 0

boost::object_pool
by wugui 22 Aug '02

22 Aug '02

class A; class B; class AB : virtual public A, virtual public B; all destruct is virtual boost::object_pool<AB> pool_ab; B * pb = pool_ab.constuct(); pool_ab.destroy(pb); // is this right?

1 1

boost lambda library compile error
by khuroth 21 Aug '02

21 Aug '02

I have searched already in this list and the dev list for these MSVC compiler errors, but none of the solutions have worked so far. I have turned off precompiled headers, built clean, tried defining BOOST_NO_MEMBER_TEMPLATES before including "boost/lambda/lambda.hpp" (or "boost/lambda/bind.hpp"), and I still always get this error under Visual C++ 6 SP5 (Win2k Pro SP3), in both the Debug and Release configurations: Deleting intermediate files and output files for project 'dWin - Win32 Release'. --------------------Configuration: dWin - Win32 Release--------------- ----- Compiling... dwin-button.cpp dwin-common-control.cpp dwin-dialog.cpp C:\TMP\BOOST\BOOST_1_28_0\boost/lambda/detail/lambda_fwd.hpp(31) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Not sure what I'm doing wrong..

4 6

Boost Concept Check Library
by igor_bashkirov 21 Aug '02

21 Aug '02

Hello, I work on big software project that is ported to several platforms/compilers, including Linux,Solaris/GCC 2.95.2,3.0.4); Windows/MSVC 6.0; AIX/VisualAge; MacOS X / GCC 2.95.2 (Apple). Recently, I decided to make use of Boost library (v 1.28) and the first thing I tried was Boost Concept Check Library (BCCL). Unfortunately, the use of the library wasn't as smooth as I expected, namely, with respect to BOOST_CLASS_REQUIRES macro. Thus, I'd like to submit a couple of observations and one proposal regarding usage of this macro. Let's start with observations: following is the snippet from <boost/concept_check.hpp> header: [code // The BOOST_CLASS_REQUIRES macros use function pointers as // template parameters, which VC++ does not support. #if defined(BOOST_NO_FUNCTION_PTR_TEMPLATE_PARAMETERS) #define BOOST_CLASS_REQUIRES(type_var, concept) .... #else #define BOOST_CLASS_REQUIRES(type_var, concept) \ typedef void (concept <type_var>::* func##type_var##concept)(); \ .... end code] As you could see, BOOST_CLASS_REQUIRES macros evaluate to nothing if BOOST_NO_FUNCTION_PTR_TEMPLATE_PARAMETERS symbol is defined. But, to my great surprise, I didn't find any more references to BOOST_NO_FUNCTION_PTR_TEMPLATE_PARAMETERS symbol throughout the Boost library. Moreover, the above comment about VC++ not supporting function pointers as template parameters is wrong (at least for MSVC 6.0 with SP5). Not to be unfounded, I will provide following sample program successfully compiled and run under MSVC 6.0 with SP5: [code #include <iostream> using namespace std; typedef void(*FP)(); template <FP T> class X { FP fp_; public: X() : fp_(T) {} void print() const { cout << fp_ << endl; } }; void f() {} int main(int, char**) { X<&f> x1; x1.print(); return 0; } end code] The same is true for pointers to member functions of both ordinary and template classes. OK, this observation could be treated as "cosmetic" one, but the following won't. Let's look at the definition of BOOST_CLASS_REQUIRES macro: [code #define BOOST_CLASS_REQUIRES(type_var, concept) \ typedef void (concept <type_var>::* func##type_var##concept)(); \ template <func##type_var##concept _Tp1> \ struct concept_checking_##type_var##concept { }; \ typedef concept_checking_##type_var##concept< \ BOOST_FPTR concept <type_var>::constraints> \ concept_checking_typedef_##type_var##concept end code] and at a typical usage of this macro (taken from Boost documentation): [code template <class T> struct generic_library_class { BOOST_CLASS_REQUIRES(T, EqualityComparableConcept); // ... }; end code] Here, the "EqualityComparableConcept" is a concept checking class defined in the "boost" namespace. OK, that's great and works fine until "generic_library_class" is also declared in the "boost" namespace. Let's now suppose "generic_library_class" is declared in namespace "ns1". Then, BOOST_CLASS_REQUIRES macro evaluates to following: [code namespace ns1 { template <class T> struct generic_library_class { typedef void (EqualityComparableConcept <T>::* funcTEqualityComparableConcept)(); ... }; } end code] Did you see the problem places? Yes, it's where "concept" parameter of the macro is substituted for "EqualityComparableConcept". This name is not declared in the namespace "ns1"! The first itch could be to specify "boost::EqualityComparableConcept" as a value of the second parameter of the macro, but, "not so fast, Skywalker!" - in this case we will end up with "funcTboost::EqualityComparableConcept" name for the pointer to member function that is not a legal name of C/C++ identifier. Someone could say "What a big deal?! Just write 'using namespace boost;' or 'using boost::EqualityComparableConcept;' just before declaring 'generic_library_class'.". Well, the declaration of "generic_library_class" seems to be in the header, right? And what do you think about writing "using-directives" in header files? Yes, right, - it's evil! Especially for large production code. Just check your favorite C++ book. Though, the use of "using-declarations" in headers is a moot point, I also consider it as evil for the same reasons as for "using- directives". Anyway, "using-declarations" won't help us, - they just don't work under MSVC 6.0 in our case. So, what do we have, - "exclusive circle"? I hope not. Finally, I got to the proposal that should help us to eliminate defects of the macro and to obviate above-stated difficulties. What if to add one more parameter, say, "ns", to the BOOST_CLASS_REQUIRES macro to pass the name of the namespace the concept checking class belongs to? Let's look at the new definition of the macro: [code #define BOOST_CLASS_REQUIRES(type_var, ns, concept) \ typedef void (ns::concept <type_var>::* func##type_var##ns##concept) (); \ template <func##type_var##ns##concept _Tp1> \ struct concept_checking_##type_var##ns##concept { }; \ typedef concept_checking_##type_var##ns##concept< \ BOOST_FPTR ns::concept <type_var>::constraints> \ concept_checking_typedef_##type_var##ns##concept; end code] and at it's usage: [code namespace ns1 { template <class T> struct generic_library_class { BOOST_CLASS_REQUIRES(T, boost, EqualityComparableConcept); // ... }; } end code] that will evaluate to the following: [code namespace ns1 { template <class T> struct generic_library_class { typedef void (boost::EqualityComparableConcept <T>::* funcTboostEqualityComparableConcept)(); ... }; } end code] That's it. Moreover, this solution does not suffer from yet another drawback inherent to the original one, viz, name clashing when using in the same class concept checking classes with the same name, but from different namespaces. The only issue I could see with my suggestion was impossibility to use concept checking classes declared at the global scope, but, I hope nobody would think of such thing, because it's evil (sorry for repetition). I hope the proposed solution will increase usability of the BCCL. Best regards, Igor Bashkirov.

3 2

Upgrade VisC++ compiler
by sen_al2002 20 Aug '02

20 Aug '02

Hi, I am a newbie to all this programmer stuff. I am a physics student doing some computer simulations. I was trying to use the special function atanh from boost libraries but couldn't. The error message reads d:\boost_1_28_0\atanh.hpp(77) : error C2989: 'atanh_helper1_t<T,0>' : template class has already been defined as a non-template class Some advised me to update my VisC++ ver 6.0 compiler. How can I do that? Does anybody out there have any better advise? Thanks sen

4 4

boost python link error
by kiminkim 20 Aug '02

20 Aug '02

I want to export C++ class...use boost lib but link error occured... help me. #include <windows.h> #include <boost/python/class_builder.hpp> #include <string> namespace python = boost::python; class CBaseBox { public: CBaseBox() {}; void move(); private: std::string a; }; void CBaseBox::move() { MessageBox(NULL, "kkm", "kkm", MB_OK); } BOOST_PYTHON_MODULE_INIT(tuesday) { python::module_builder this_module("tuesday"); python::class_builder<CBaseBox> CBaseBox_class(this_module, "CBaseBox"); CBaseBox_class.def(&CBaseBox::move , "move"); } --------------------Configuration: tuesday - Win32 Debug-------------------- Compiling... export.cpp Linking... Creating library pyds\./tuesday_d.lib and object pyds\./tuesday_d.exp export.obj : error LNK2001: unresolved external symbol "class CBaseBox & __cdecl from_python(struct _object *,struct boost::python::type<class CBaseBox &>)" (?from_python@@YAAAVCBaseBox@@PAU_object@@U?$type@AAVCBaseBox@@@python@boost @@@Z) pyds\.\tuesday_d.pyd : fatal error LNK1120: 1 unresolved externals Error executing link.exe.

1 0

Boost Python error handling
by cseymour＠interchange.ubc.ca 19 Aug '02

19 Aug '02

Here is a sample program which shows the problem i've been having (posted in earlier messages). When I import the module "sample" and run the function test(), I get the following output: This is a test Raising an error Aborted When I should get a message saying it caught the error, and then a Python error, instead of it Aborting and quitting Python. /* sample.c */ #include "Python.h" #include "boost/python/class_builder.hpp" namespace py = boost::python; void test() { std::cout << "This is a test" << std::endl; std::cout << "Raising an error" << std::endl; PyErr_SetString(PyExc_TypeError, "This is the error"); throw py::argument_error(); } BOOST_PYTHON_MODULE_INIT(sample) { try { py::module_builder this_module("sample"); this_module.def(test, "test"); } catch (...) { std::cout << "Caught an error" << std::endl; py::handle_exception(); } }

1 0

Newbie and shared_ptr
by Ian Mold 19 Aug '02

19 Aug '02

I have been looking at the shared_ptr class, and I have made a change to include an assignment from a standard pointer. I have done this so that I don't have to create a new shared_ptr just to reassign an existing shared_ptr. // Assignment to a 'normal' pointer. shared_ptr & operator=(T * r) { this_type(r).swap(*this); return *this; } I have a few questions. 1) Is this necessary? 2) Does this do the job? 3) Is there any reason this wasn't included in the first place? I welcome any comments. Regards, IanM

3 2