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

BUG: counted_base::release
by perkristensennettest 11 Nov '02

11 Nov '02

To me it seems like a bug, that the weak_count in counted_base::release is decremented before the call to dispose. See below //source code begin void release() // nothrow { long new_use_count; long new_weak_count; { #ifdef BOOST_HAS_THREADS mutex_type::scoped_lock lock(mtx_); #endif new_use_count = --use_count_; new_weak_count = --weak_count_; //this is a bug } if(new_use_count == 0) { dispose(); //the this object may be deleted here } if(new_weak_count == 0) { // not a direct 'delete this', because the inlined // release() may use a different heap manager self_deleter_(this); } } //source code end If the call to dispose() indirectly calls weak_release there is an error as weak_release will decrement the --weak_count and may destruct the counted_base object. This will happen if you have an class C with a member of type weak_ptr<C>. As I see it the decrement of weak_count should be moved to after the dispose call. see below: //source code begin void release() // nothrow { long new_use_count; long new_weak_count; { #ifdef BOOST_HAS_THREADS mutex_type::scoped_lock lock(mtx_); #endif new_use_count = --use_count_; //do not decrement weak_count here } if(new_use_count == 0) { dispose(); } { #ifdef BOOST_HAS_THREADS mutex_type::scoped_lock lock(mtx_); #endif new_weak_count = --weak_count_; } if(new_weak_count == 0) { // not a direct 'delete this', because the inlined // release() may use a different heap manager self_deleter_(this); } } //source code end ????

2 1

RE: [Boost-Users] Strange bug / MSVC 6.5 / Boost 1.29 / utility_f wd.hpp
by Tom Matelich 11 Nov '02

11 Nov '02

Here's a short example: #include <boost/smart_ptr.hpp> #include <iostream> namespace ZSystem { namespace Leg { enum Type { INLET = 1, OUTLET = 2 }; } } std::ostream& operator<<(std::ostream&, ZSystem::Leg::Type); #include <boost/utility.hpp> Not sure whats going on here, I just started with a broken compile and reduced it to here. > -----Original Message----- > I haven't tracked down what include order is causing this, > but I'm getting: > > c:\dev\opt\include\boost/utility_fwd.hpp(21) : 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 > ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

Strange bug / MSVC 6.5 / Boost 1.29 / utility_fwd.hpp
by Tom Matelich 11 Nov '02

11 Nov '02

I haven't tracked down what include order is causing this, but I'm getting: c:\dev\opt\include\boost/utility_fwd.hpp(21) : 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 Of course MSVC doesn't have header include tracing. I've been working around it with spurious includes of <boost/utility/base_from_member.hpp>. Any ideas? Thanks, Tom ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

gcc bug
by wugui 11 Nov '02

11 Nov '02

FreeBSD 4.6-STABLE gcc version 2.95.3 20010315 (release) [FreeBSD] 1. CXXFLAG = -Wall -g -pthread -D_THREAD_SAFE is ok 2. CXXFLAG = -Wall -ggdb -pthread -D_THREAD_SAFE boost_1_28_0/boost/function/function_base.hpp:155: Internal compiler error in `output_die', at dwarf2out.c:5433 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

2 1

Is this shared_ptr usage okay?
by Hickman, Greg 11 Nov '02

11 Nov '02

I'd like to prevent clients from directly creating and deleting instances of a type like 'Bill' below, so Bill's constructor and destructor have been made private to prevent ordinary client access. Since Bill has reference semantics, construction is handled by a static 'Bill::create()' factory method which returns a dynamically allocated Bill instance wrapped in a shared_ptr. Destruction is handled by a private Bill::Deallocator who also happens to be a Friend of Bill (FOB). My question is: Is this an acceptable use of the shared_ptr deallocator, or am I just asking for trouble? Thanks, Greg Hickman //-------------------------------------- #include <boost/shared_ptr.hpp> using namespace boost; class Bill; typedef shared_ptr<Bill> Bill_ptr; class Bill { private: Bill() {} ~Bill() {} struct Deallocator { void operator() (Bill* b) const { delete b; } }; friend struct Deallocator; public: static Bill_ptr create() { return Bill_ptr(new Bill, Deallocator()); } };

2 1

Re: uBLAS Matrix Multiplication
by Paul C. Leopardi 10 Nov '02

10 Nov '02

Hi, There are at least two strong arguments here: 1. Use * for element-by-element multiplication of matrices. This treats matrices as if they were just arrays, with an added "mult" function, but it has the advantage that it prevents or at least discourages users from writing poorly performing code. 2. Use * for matrix multiplication. This treats matrices as if they were elements of a linear algebra, with algebra operations "+" and "*". C++ allows such abstractions, but there may be a penalty in performance if the abstraction is abused. In GluCat - http://glucat.sf.net - I implemented Clifford algebras using "+" and "*". GluCat also has two other products, for which it uses, "&" and "^". I used "*" for the main product which defines the algebra. Underlying each Clifford algebra is an isomorphic matrix algebra. Best regards

1 0

Possible Error (with Fix?) in debug build of thread(?) library created with msvc/stlport.
by Mike Wilson 10 Nov '02

10 Nov '02

As a newbie I'd like to say a big thank to all those concerned for boost. I found that the following (MSVC6) program fails when in the (default) debug build, but works in release: #include <iostream> #include <boost/thread/thread.hpp> int main(int , char* ) { int NUM_CLIENTS = 3; boost::thread_group thrds; std::cout << NUM_CLIENTS; // prints 0 in _DEBUG build, 3 in release return 0; } It was linked using the libboost_thread.lib file created using the following bjam command: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=F:\TemplateStuff" "-sBUILD=debug <runtime-link>static <stlport-iostream>on" POSSIBLE FIX Compiling the above program with _STLP_DEBUG defined gives the correct answer. Is this the correct fix to the problem? (I've noted that there is no mention of _STLP_DEBUG in the distributed docs) Mike Wilson Thanks again to the boost community.

3 2

Q: Boost Python / weave / swig
by Claudius Schnörr 09 Nov '02

09 Nov '02

Hello, I would like to build a python-interface for a C++-template library I wrote. After looking around a bit, besides Boost-python I found swig and weave, which seem to have a similar purpose in mind!?! I would appreciate it if someone could provide some comparing hints/links/information about these various solutions (I'm new to all these packages). How do they differ in terms of - the learning curve, - their capabilities and - their foci ? Thank you in advance, Claudius

1 0

N-dimensional array besides multi_array
by Paul Cameron 09 Nov '02

09 Nov '02

I'm looking for an N-dimensional array that doesn't require the dimensionality be specified at compile time, like multi_array. Does anyone know of such a beast? It doesn't need a lot of functionality, just basic storage/retrieval and some slicing. Just thought I'd ask before I roll my own. I'm thinking of tweaking Giovanni Bavestrelli's implementation which is what multi_array is based on. Thanks, Paul

1 0

RE: [Boost-Users] Boost (shared_ptr) vs Visio 2002 reverse engineering
by Randy Bowen 09 Nov '02

09 Nov '02

I assume you meant, What's the matter with Visio, right? -----Original Message----- From: Marcio Del'Valle [mailto:mjdelvalle@terra.com.br] Sent: Friday, November 08, 2002 4:11 PM To: Boost-Users(a)yahoogroups.com Subject: [Boost-Users] Boost (shared_ptr) vs Visio 2002 reverse engineering Hi, Every time I try to reverse engineer a project where I've used boost::shared_ptr Visio 2002 locks my Visual C++. What's the matter with the shared_ptr library? Marcio Del'Valle [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=238900.2578845.3984497.2273195/D=egroupweb/S=1705 006788:HM/A=1309024/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_you H1/g22lp?Target=mm/g22lp.tmpl> <http://us.adserver.yahoo.com/l?M=238900.2578845.3984497.2273195/D=egrou pmail/S=:HM/A=1309024/rand=607495686> Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]

2 1