- Boost-users - lists.boost.org

using 'this' with shared_ptrs
by Stephen Crowley 17 Nov '02

17 Nov '02

How is someone supposed to use 'this' when setting a member of another class to point back to it? Here is an example.. when you run it, this will happen. constructor called 0x804af10 constructor called 0x804af48 destructor called 0x804af48 destructor called 0x804af10 destructor called 0x804af10 The last destructor is called twice! The only way I can think to get around this add a member to the class called "shared_ptr<MyClass> thisptr" which is initialized to "this" in the constructor and over-ride the assignment operator or something.. will that work? ------------------------ #include <boost/shared_ptr.hpp> #include <boost/weak_ptr.hpp> #include <iostream> using namespace std; using namespace boost; class MyClass; typedef shared_ptr<MyClass> MyClassPtr; class MyClass { public: MyClass(); ~MyClass(); MyClassPtr makeCopy(); MyClassPtr original; }; MyClass::MyClass() { cout << "constructor called " << this << endl; } MyClass::~MyClass() { cout << "destructor called " << this << endl; } MyClassPtr MyClass::makeCopy() { MyClassPtr mc(new MyClass); mc->original = MyClassPtr(this); return mc; } main() { MyClassPtr oc(new MyClass); MyClassPtr cc = oc->makeCopy(); // the problem lies here // when cc's reference count is 0 it will be deleted, which will // in turn decrease its 'original' reference count which will be 0, thus // causing it to be deleted as well even though it is still being used by oc! cc.reset(); } ----------------------------------- -- Stephen

2 2

Date_time library question...
by shaneforbes 16 Nov '02

16 Nov '02

With the following line in my Microsoft Vc7 program: std::cout << to_simple_string(d) << std::endl; I get the following linker errors: error LNK2005: "public: __thiscall std::locale::id::id(unsigned int)" (??0id@locale@std@@QAE@I@Z) already defined in stdafx.obj error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCD.lib(typinfo.obj) error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (?? 4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCD.lib(typinfo.obj) Clearly I am missing something important! I did put #define DATE_TIME_INLINE in my stdafx.h file and that allowed me to create dates (date d(...)) but clearly something else is needed (for IO related stuff?)... Do I have to for instance recreate the libboost_date_time.lib file with different settings? I just used 'bjam "-sTOOLS=vc7" "- sBUILD=debug release"'. Any help appreciated. Thanks to Jeff Garland and the rest of the Boost group for creating this library - I would really like to use it in my programs from now on but why won't the silly linker oblige!

2 8

Codewarrior 8 and Include Paths
by Roland Weiss 15 Nov '02

15 Nov '02

Hello, I'm trying to compile some simple test programs that use Boost Header libraries (no building required), like any, shared_ptr etc. Using CW8, I have a strange problem. When I add the Boost root to the access path, the compiler finds the according boost headers, but inside the config header the Boost lib looks up some headers using this syntax: #include <user.hpp> and so on. CW8 then fails to find these headers. If I change <user.hpp> to "user.hpp" all works fine (but it fails on the next header in angle brackets). Any help appreciated. Roland

2 2

uBlass outer_product
by Olaf Petzold 15 Nov '02

15 Nov '02

Hi, I can't get the following snipped from the doc examples to work: #include <iostream> #include <boost/numeric/ublas/vector.hpp> #include <boost/numeric/ublas/io.hpp> int main () { using namespace boost::numeric::ublas; vector<double> v1 (3), v2 (3); for (int i = 0; i < std::min (v1.size (), v2.size ()); ++ i) v1 (i) = v2 (i) = i; std::cout << outer_prod (v1, v2) << std::endl; } ublas_cross.cc: In function `int main()': ublas_cross.cc:17: `outer_prod' undeclared (first use this function) ublas_cross.cc:17: (Each undeclared identifier is reported only once for each function it appears in.) What's wrong here? Thanks Olaf

2 1

RE: [Boost-Users] using 'this' with shared_ptrs
by Per Kristensen 15 Nov '02

15 Nov '02

You initialises two shared_ptr with the same raw pointer. As a consequent the destructor is called twice, as you will have two different shared_count object which will calls delete as the count become zero. Try to use weak_ptr as a member: ----------------------------------- typedef shared_ptr<MyClass> MyClassPtr; class MyClass { public: MyClass(); ~MyClass(); void setOriginal(MyClassPtr); MyClassPtr makeCopy(); weak_ptr<MyClass> original; }; MyClass::MyClass() { cout << "constructor called " << this << endl; } MyClass::~MyClass() { cout << "destructor called " << this << endl; } void MyClass::setOriginal(MyClassPtr p) { original = p; } MyClassPtr MyClass::makeCopy() { return MyClassPtr(original); } main() { MyClassPtr oc(new MyClass); oc->setOriginal(oc); MyClassPtr cc = oc->makeCopy(); } --------------------------------- Per -----Original Message----- From: Stephen Crowley [mailto:stephenc@digitalpassage.com] Sent: 15. november 2002 05:37 To: Boost-Users(a)yahoogroups.com Subject: [Boost-Users] using 'this' with shared_ptrs How is someone supposed to use 'this' when setting a member of another class to point back to it? Here is an example.. when you run it, this will happen. constructor called 0x804af10 constructor called 0x804af48 destructor called 0x804af48 destructor called 0x804af10 destructor called 0x804af10 The last destructor is called twice! The only way I can think to get around this add a member to the class called "shared_ptr<MyClass> thisptr" which is initialized to "this" in the constructor and over-ride the assignment operator or something.. will that work? ------------------------ #include <boost/shared_ptr.hpp> #include <boost/weak_ptr.hpp> #include <iostream> using namespace std; using namespace boost; class MyClass; typedef shared_ptr<MyClass> MyClassPtr; class MyClass { public: MyClass(); ~MyClass(); MyClassPtr makeCopy(); MyClassPtr original; }; MyClass::MyClass() { cout << "constructor called " << this << endl; } MyClass::~MyClass() { cout << "destructor called " << this << endl; } MyClassPtr MyClass::makeCopy() { MyClassPtr mc(new MyClass); mc->original = MyClassPtr(this); return mc; } main() { MyClassPtr oc(new MyClass); MyClassPtr cc = oc->makeCopy(); // the problem lies here // when cc's reference count is 0 it will be deleted, which will // in turn decrease its 'original' reference count which will be 0, thus // causing it to be deleted as well even though it is still being used by oc! cc.reset(); } ----------------------------------- -- Stephen 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]

1 0

graph question : cycle detection - undirected graph
by Matthew Galati 15 Nov '02

15 Nov '02

Can DFS be used to detect cycles in an undirected graph? Using the code in the example file_dependencies.cpp on an undirected graph - it detects cycles even though there is none. Do we have to do more than simply look for back edges for an undirected graph? or should I convert it to directed then use this function? Thanks, Matt -- Matthew Galati ISE Lehigh University IBM Service Parts Solutions 610.758.4042 (Office) 610.882.0779 (Home) magh(a)lehigh.edu, magal11(a)us.ibm.com http://sagan.ie.lehigh.edu/mgalati/

2 1

Getting a matrix to the -1 power
by agiatojon 14 Nov '02

14 Nov '02

Hello all, I am trying to evaluate a matrix to the -1 power but have not been able to find a quick and dirty solution. Any suggestions? Thanks! Jon Agiato JonAgiato(a)nyc.rr.com

1 0

Preprocessor lib problems on Solaris (Forte compiler)
by Robert A. Reece 14 Nov '02

14 Nov '02

I'm using Forte 6 update 2 to compile my code. The preprocessor headers seem to have problems with all the various macros that get defined. These are the errors I'm seeing from compiling libs/preprocessor/test/list.cpp (using command CC -I../../.. list.cpp): /hades03/pegstage/boost/boost_1_29_0/libs/preprocessor/test> /../.. list.cpp < "list.cpp", line 24: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 24: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 24: Error: BOOST_PP_LIST_FOLD_LEFT_129 is not defined. "list.cpp", line 24: Error: BOOST_PP_NIL is not defined. "list.cpp", line 24: Error: BOOST_PP_TUPLE_EAT_3 is not defined. "list.cpp", line 24: Error: Badly formed expression. "list.cpp", line 25: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 25: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 25: Error: BOOST_PP_LIST_FOLD_LEFT_129 is not defined. "list.cpp", line 25: Error: BOOST_PP_NIL is not defined. "list.cpp", line 25: Error: BOOST_PP_TUPLE_EAT_3 is not defined. "list.cpp", line 25: Error: Badly formed expression. "list.cpp", line 26: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 26: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 26: Error: BOOST_PP_LIST_FOLD_LEFT_129 is not defined. "list.cpp", line 26: Error: BOOST_PP_NIL is not defined. "list.cpp", line 26: Error: BOOST_PP_TUPLE_EAT_3 is not defined. "list.cpp", line 26: Error: Badly formed expression. "list.cpp", line 28: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 28: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 28: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 28: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 28: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 28: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 28: Error: BOOST_PP_LIST_FOLD_LEFT_129 is not defined. "list.cpp", line 28: Error: BOOST_PP_NIL is not defined. "list.cpp", line 28: Error: BOOST_PP_TUPLE_EAT_3 is not defined. "list.cpp", line 28: Error: Badly formed expression. "list.cpp", line 30: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 30: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 30: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 30: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 30: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 30: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 30: Error: BOOST_PP_LIST_FOLD_LEFT_129 is not defined. "list.cpp", line 30: Error: BOOST_PP_NIL is not defined. "list.cpp", line 30: Error: BOOST_PP_TUPLE_EAT_3 is not defined. "list.cpp", line 30: Error: Badly formed expression. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 31: Error: BOOST_PP_LIST_FOLD_LEFT_129 is not defined. "list.cpp", line 31: Error: BOOST_PP_NIL is not defined. "list.cpp", line 31: Error: BOOST_PP_TUPLE_EAT_3 is not defined. "list.cpp", line 31: Error: Badly formed expression. "list.cpp", line 33: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 33: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "list.cpp", line 33: Error: BOOST_PP_LIST_FIRST_I is not defined. Compilation aborted, too many Error messages. Any thoughts would be great. -Rob

4 6

RE: [Boost-Users] A strange question-)
by Aleksey Gurtovoy 14 Nov '02

14 Nov '02

Sam Gentile wrote: > I'm sorry, no I still don't understand. Could you please say more? Well, it would help me if you've said what exact points in my answer you are having troubles with :). Aleksey > > -----Original Message----- > From: Aleksey Gurtovoy [mailto:alexy@meta-comm.com] > Sent: Wednesday, November 13, 2002 3:19 AM > To: 'Boost-Users(a)yahoogroups.com' > Subject: RE: [Boost-Users] A strange question-) > > > > Sam Gentile wrote: > > I went there and indeed it can't get any simpler - at least > > in theory-) > > Read the document > > C:\Boost\boost_1_29_0\libs\type_traits\c++_type_traits.htm > > and its quite > > simple: > > > > template <typename T> > > struct is_void > > { static const bool value = false; }; > > > > template <> > > struct is_void<void> > > { static const bool value = true; }; > > > > That's exactly what I want to show. So I go to the header files and > > instead: > > > > //* is a type T void - is_void<T> > > > > BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_void,T,false) > > > > BOOST_TT_AUX_BOOL_TRAIT_SPEC1(is_void,void,true) > > > > > > > > Huh? So I look in bool_trait_def.hpp: > > > > #define BOOST_TT_AUX_BOOL_TRAIT_DEF1(trait,T,C) \ > > > > template< typename T > struct trait \ > > > > : mpl::bool_c< C > \ > > > > { \ > > > > BOOST_TT_AUX_BOOL_TRAIT_VALUE_DECL(C) \ > > > > BOOST_MPL_AUX_LAMBDA_SUPPORT(1,trait,(T)) \ > > > > }; \ > > > Well, the original code doesn't have all these excessive newlines ;), > but > yes, basically that's how it's implemented. > > > Argh! Why is it done like this? This makes it much more > > complicated and unreadable than it has to be. Why are macros > > being used everywhere? > > Practical engineering matters. If you consider that the fact > that there > are > ~60 trait templates in the library and every time when a new > version of > a > compiler comes out, or when somebody starts porting the > library to a new > platform, there is a chance that you need to change half of those > definitions, from, for instance, > > template <typename T> > struct is_void > : mpl::bool_c<false> > { > }; > > to > > template <typename T> > struct is_void > { > BOOST_STATIC_CONSTANT(bool, value = false); > typedef mpl::bool_c<value> type; > }; > > it might all make sense, after all :). Something along the > lines of both > of > the above scenarios has actually happened, a couple of times. It's not > the > whole picture yet, but IMO it's enough of the motivation already, so I > won't > go too deep into details :). > > Hope this answers your question, > Aleksey > > 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! > <http://docs.yahoo.com/info/terms/> Terms of Service. > > > > [Non-text portions of this message have been removed] > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/ASSHAA/EbFolB/TM > -------------------------------------------------------------- > -------~-> > > 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 http://docs.yahoo.com/info/terms/

4 4

RE: [Boost-Users] A strange question-)
by Jim.Hyslop 14 Nov '02

14 Nov '02

Sam Gentile [mailto:ManagedCode@attbi.com] wrote: > Well at least you gave somewhat of an answer. I still want to > understand > how those particular macros give that portability. I haven't looked at the macros in question, but one approach to portability is to separate the macro definitions into platform-specific files. Exactly which file gets included depends on the compiler settings. For example: // file: compilerX/defines.h [omitting include guards for brevity #define DO_SOMETHING(x) CallCompilerXFn( x ) // end file // file: compilerY/defines.h #define DO_SOMETHING(x) compiler_y_function( x ) // end file // file: some Boost header #include "defines.h" class someClass { void f(T a) { DO_SOMETHING( a ); } }; Exactly _which_ "defines.h" gets included is controlled by the build settings, which are determined by the platform. The alternative is a really ugly set of #ifdefs: // file: some Boost header class someClass { void f(T a) { #ifdef COMPILER_X CallCompilerXFn( a ); #elif defined(COMPILER_Y) compiler_y_function( a ); [... etc. for each platform supported #endif } }; As I said, that's _one_ approach - Boost uses something slightly different. Have a look at config.hpp to see its approach. -- Jim

1 0