- Boost-users - lists.boost.org

bjam exe for cygwin on win98
by Fernando Cacciola 23 Aug '03

23 Aug '03

Hi, The link on http://www.boost.org/tools/build/index.html#Jam states that bjam executables can be found at: http://sourceforge.net/project/showfiles.php?group_id=7586 but I don't know which of the bjams there is an executable for cygwin on win98 TIA Fernando Cacciola

3 5

Parent-Child Object Relationships with shared_ptr
by Martin Ecker 23 Aug '03

23 Aug '03

Hello, I've been thinking of switching one of my projects to use boost::smart_ptr and I'm currently investigating this option a bit. In my project there are a lot of cases where an object acts as factory/parent object to create other child objects. These child objects must keep the parent object alive as long as one of them still exists. Or in other words, even if the client does not hold a pointer to the parent object anymore, the parent must continue to exist as long as there is still a child object. Also the child objects sometimes need to have access to the parent object that created them. Therefore, I thought I'd have them hold a shared_ptr to the parent object. So the situation looks something like this, where both Parent and Child objects are only allocated on the heap and should only be passed around as shared_ptr. class Parent { public: boost::shared_ptr<Child> CreateChild() const { boost::shared_ptr<Child> child(new Child(this)); return child; } }; class Child { friend class Parent; protected: Child(const boost::shared_ptr<Parent> parent) : m_parent(parent) {} private: boost::shared_ptr<Parent> m_parent; }; As far as I understand it I can't do new Child(this) because Child expects a shared_ptr, so I'd have to derive Parent from enable_shared_from_this. However, in my project there are a number of classes in a rather complicated class hierarchy to which the above pattern applies and I'd thus like to avoid having to (multiply) derive them from enable_shared_from_this. Is there another, possibly better way of achieving what I want to do (keep the parent alive as long as there are still child objects) that I haven't discovered yet? Or do I really have to derive all these classes from enable_shared_from_this? Do I have to derive each class in a class hierarchy from enable_shared_from_this, if each of them needs to give out a shared_ptr-managed this pointer? Thanks for any help, Martin

3 2

newbie trying to make a dll
by schmitty9812003 22 Aug '03

22 Aug '03

This is my very first experience with Boost. I am actually trying to use the SDTS++ libraries (if anyone is familiar with them) which use Boost. Anyway, I successfully built the library using the Jamfile that was included with the download which looks something like this: lib sdtsxx : ... : <include>$(BOOST_ROOT) <include>$(TOP) <include>. <include>$(TOP)/Windows # to get bogus "unistd.h" <rtti>on <exception-handling>on <msvc><*><cflags>-TP # force to compile as C++ <gcc><*><cflags>"-x c++" # force to compile as C++ <gcc><*><define>VECTOR_ITERATOR_POINTER_NOT_EQUIVALENT : debug release ; However, what I need is for the library to be a dll. So I changed the Jamfile to look something like this: SOURCES = ...; dll sdtsxx : $(SOURCES) : <include>$(BOOST_ROOT) <include>$(TOP) <include>. <include>$(TOP)/Windows # to get bogus "unistd.h" <rtti>on <exception-handling>on <msvc><*><cflags>-TP # force to compile as C++ <gcc><*><cflags>"-x c++" # force to compile as C++ <gcc><*><define>VECTOR_ITERATOR_POINTER_NOT_EQUIVALENT : debug release ; Unfortunately this gives me linking errors like this: sb_Accessor.obj : error LNK2001: unresolved external symbol "public: class boost::filesystem::path __thiscall boost::filesystem::path::branch_path(void)const "(? branch_path@path@filesystem@boost@@QBE?AV123@XZ) Now I don't know that this is a Boost problem or if I should go to the SDTS people. Since the unresolved externals are from the Boost libraries I figured it was a Boost issue. So am I doing something wrong with the Jamfile, or is there a problem with Boost? Or is it something completely different? Oh, I'm using msvc on an XP machine, if that matters... -ms

2 1

Compiler help
by Henry ?? 22 Aug '03

22 Aug '03

I'm trying to try out the thread library on HP-UX and SGI Irix using GNU GCC and have not been able to run them succesfully. I noticed that on the "Boost Regression Tests" the compiler Status for both my platforms and compilers have failed with messages similar to what I am getting. Do I have any options or is it just not possible to try the thread library for my systems. Thanks

4 3

request: complete list of output files of build?
by Li Lirong 22 Aug '03

22 Aug '03

Is it possible for the boosters to provide a complete list of the lib and dll files (include debug and release versions) that the build system produces? Thanks. Best regards, Lirong

1 0

RE: [Boost-Users] Re: Re: boost::intrusive_ptr and Managed C++?
by Ferdinand Prantl 22 Aug '03

22 Aug '03

Hi Holger, > -----Original Message----- > From: Holger Grund [mailto:yg-boost-users@gmane.org] > Sent: Thursday, August 21, 2003 14:50 > To: boost-users(a)yahoogroups.com > Subject: [Boost-Users] Re: Re: boost::intrusive_ptr and Managed C++? > > > "Ferdinand Prantl" <ferdinand.prantl(a)ixos.de> wrote > > > The second option (as Holger says) is to make a simple facade to the > c++ > > library (all you might use), which will not have templates (here > smart > > pointers) on the interface, and to use this facade instead. > > > Did I say that? Anyway, I absolutely agree. Oops, sorry, I thought a bit further... :-) > > I just want to point out that IMHO the best solution is to > _not_ export instrusive_ptr_add_ref and _release. If you do > new and delete are called from different modules which works > only if the same CRT instance is used. And that works only if > both link against the exact same version of the CRT dll (that > is both linking against a static CRT still yields to > instances => two heaps => error). The generally safest solution yes, but not always the simpliest and most understandable. With a pile of C++ libraries with templates and STL on interface to use, I would not be very keen on writing facades for each and every... Every such a wrapper also increases the complexity of the solution. > > While we're at it, it's almost always a bad thing to export > classes or functions that rely on classes from a DLL. DLLs > are a run time concept. They don't have any clue which > version of the compiler a consumer is built with. > > E.g. say you export a function > void foo( std::string& s ) > { > s = "Hello World!"; > } Oh yeah, that's terrible constraint - if releasing binary library, one must support more compilers and also create different binary names (e.g. boost_regex). It is not needed if you release sources of the library (not the case of commercial APIs). If STL is widely used in the dependency tree of libraries, it is a pity to abandon it from their interfaces, building special marshalling structures or serializing into streams or return pointers. In this situation I broke the general recommendation (no templates on iface), preferred simplier solution and went on with STL on interfaces. It is cheaper and runs faster too. I moved the task of creating a facade without STL to the person, who needs it. As long as everybody are happy with usage of the same STL on interface, such a facade does not need to be borned (for managed .net assemblies it is also not necessary)... > > The DLL is built with the version A of the compiler and STL > and the consuming application is built with version B. There > is no guarantee for a binary compatibility between the two > version. And indeed the code above will break if version 6 & > 7 of VC are used (The former used a COW scheme while the > second uses a short string optimization). This must not happen. It is responsibility of the build configuration to use the belonging import libraries. It can be checked and forced by pragmas in msvc. Ferda > > Also, do note that the DLL CRT now supports side by side sharing. > > While I am in rant mode the catch(...) thing is also a very > bad idea in VC. This currently catches (this will be fixed in > 8.0) structured exception that are not C++ exception. That > way serious error conditions are silently ignored. > > -hg > > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> Buy Ink Cartridges or Refill Kits > for Your HP, Epson, Canon or Lexmark Printer at Myinks.com. > Free s/h on orders $50 or more to the US & Canada. > http://www.c1tracking.com/l.asp?cid=5511 > http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/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/

1 0

boost::python - double vs. int - unexpected behavior
by cavok＠filibusta.crema.unimi.it 21 Aug '03

21 Aug '03

hi, i attached a simple example that shows the following behavior: $ python Python 2.2.3+ (#1, Aug 10 2003, 10:11:23) [GCC 3.3.1 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import test >>> a=test.A() >>> a.f(3) double >>> a.f(3.8) double >>> a.f(int(3)) double >>> $ well, doesn't it look weird? any idea on how i can get the correct c++ method called? cheers dom -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 [Non-text portions of this message have been removed]

2 3

[BGL] How to destroy a subgraph?
by Stefan Slapeta 21 Aug '03

21 Aug '03

Hi, is it possible to destroy a subgraph child? I didn't find nothing on this in the documentation. Is there any other way to free the subgraph's resources? Thanks, Stefan

2 2

RE: [Boost-Users] Re: boost::intrusive_ptr and Managed C++?
by Ferdinand Prantl 21 Aug '03

21 Aug '03

Hello Drew, I implement managed assembly in mc++. I use c++ library with smart pointers and stlport on the interface to implement a functionality in unmanaged c++, even if it is exposed to .net through managed classes. So this scenario in general works. Holger has already answered you, I see also the problem in different heaps/runtime versions. You must ensure the same versions of the runtime (not only debug/release but also version of msvs - 6, 7, 7.1) and of the templated libraries used (in my case stlport for 6, 7, 7.1, which also must use the same runtime). I use msvcrt/msvcrtd everywhere and link everything automatically using pragmas to prevent strange errors from manual configuration. It can look complex but in reality it is pretty simple. The second option (as Holger says) is to make a simple facade to the c++ library (all you might use), which will not have templates (here smart pointers) on the interface, and to use this facade instead. Good Luck, Ferda P.S. with the first option you will come to problems if you register the assembly for CCW but that's another story... -----Original Message----- From: Holger Grund [mailto:yg-boost-users@gmane.org] Sent: Wednesday, August 20, 2003 18:18 To: boost-users(a)yahoogroups.com Subject: [Boost-Users] Re: boost::intrusive_ptr and Managed C++? "Drew" <drewtenn(a)yahoo.com>, > I originally posted this to microsoft.public.dotnet.languages.vc, > but they referred me back to here. > > Has anyone used boost's intrusive_ptr with Managed C++ extensions? > Mmh, not really. And it actually doesn't (currently ?) sound like a very compelling idea to me. > I have a small project where the executable (managed) is linked to a > native C++ dll. > > The code looks like: > > int _tmain() > { > boost::intrusive_ptr<Unmanaged> pUn = __nogc new Unmanaged(); > > return 0; > } > > when I exit out of main, boost::intrusive_ptr_release() throws an > exception. The last known method called is: > > UnmanagedLib.dll!_CrtIsValidHeapPointer(...) Line 1807 > This probably is not related to the managed extensions. It's more likely that intrusive_ptr's dtor calls into the DLL to free the pointer which is only possible if both modules use the DLL version of the CRT. The message indicates that the pointer to be freed is bogus or more likely from another heap. This is caused by a mismatch of the CRTs used by the main program and the DLL. You could use the /MD[d] option for both projects, so that both modules share a common CRT heap. I'd prefer to move intrusive_ptr_add_ref/release functions to the program that uses the instrusive_ptr. Don't export these functions from the DLL. Rather include these functions at build time. That way you ensure, that operator delete is called from the same module as operator new and everything should be fine. > Unmanaged* pUm = new Unmanaged(); > delete pUm; > Yep. Same module. No problem. hth -hg ------------------------ Yahoo! Groups Sponsor ---------------------~--> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511 http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/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/

3 3

[BGL] single pair problem with bfs
by Jérémie Leguay 21 Aug '03

21 Aug '03

Hi everybody! I really need to perform the single-pair problem. I have begin to implement it as it is written in some mail of the mailing list. I do a breadth first search and I want to use both a visitor recor_distances and a visito of my own which throws an exception to stop the algorithm when the destination is found. My problem is that I did'nt found the way to mix theses two visitors. Can you help me? regards, Jérémie ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1