- Boost-users - lists.boost.org

[BGL] Segmentation fault in add_vertex
by Martin Magnusson 19 May '05

19 May '05

I am sometimes getting segmentation faults (using gcc 3.3.4 under Cygwin) in calls to add_vertex( g ), where g is of the following type: boost::adjacency_list < boost::setS, boost::vecS, boost::undirectedS, Vertex_Properties, Edge_Length > This happens when I try to merge two graphs with repeated calls to add_vertex (not updating edges or anything, just adding new vertices), and usually when the returned index from add_vertex is around 40000-50000, but it depends on the data. Creating a single graph with more than 50000 vertices in one go is not a problem. Does anyone have an idea of what is going on in add_vertex, and what could be the problem here? I suspect it has something to do with the automatic resizing of the internal vector used to store the vertices. Is there a way to reserve memory in advance for this?

2 1

How to get BGL compiled with VC2005?
by sr kumar 19 May '05

19 May '05

Hi, I am attempting to compile Boost with VC2005. All goes well, with the exception of the Boost Graph library. The compiler errors at the bottom of the email. flex and bison from http://gnuwin32.sourceforge.net/ The problems seem to be the unistd.h which is missing on Win32. I played around with setting YY_NO_UNISTD_H in the Jamfile and the header files themselves. However, I'm not an expert (and have obviously been unsuccessful!). Would appreciate any help in figuring how to work around the problem. thanks, -sr _______________________________________ bison.bison ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_graph_parser.cpp ..\..\..\bin.v 2\libs\graph\build\msvc-8.0\debug\graphviz_graph_parser.hpp ..\..\..\libs\graph\src\graphviz_parser.yy: conflicts: 1 shift/reduce bison.bison ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_digraph_parser.cpp ..\..\..\bin .v2\libs\graph\build\msvc-8.0\debug\graphviz_digraph_parser.hpp ..\..\..\libs\graph\src\graphviz_parser.yy: conflicts: 1 shift/reduce msvc.compile.c++ ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_graph_lex.obj graphviz_graph_lex.cpp ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_graph_lex.cpp(43) : fatal error C1083: Cann ot open include file: 'unistd.h': No such file or directory call "C:\Program Files\Microsoft\Visual Studio 8\VC\bin\vcvars32.bat" > nul cl /Zm800 -nologo -TP -DBOOST_ALL_NO_LIB=1 -DGRAPHVIZ_DIRECTED=0 -DYY_NO_UNISTD_H /Z7 /Od /Ob0 /E Hsc /GR /MDd -I"..\..\..\libs\graph\src" -I"C:\bugsnoop\trunk\src\checkmate\boost" -I"..\..\..\bin .v2\libs\graph\build\msvc-8.0\debug" -c -Fo"..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphvi z_graph_lex.obj" "..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_graph_lex.cpp" ...failed msvc.compile.c++ ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_graph_lex.obj... lex.lex ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_digraph_lex.cpp msvc.compile.c++ ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_digraph_lex.obj graphviz_digraph_lex.cpp ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_digraph_lex.cpp(43) : fatal error C1083: Ca nnot open include file: 'unistd.h': No such file or directory call "C:\Program Files\Microsoft\Visual Studio 8\VC\bin\vcvars32.bat" > nul cl /Zm800 -nologo -TP -DBOOST_ALL_NO_LIB=1 -DGRAPHVIZ_DIRECTED=1 -DYY_NO_UNISTD_H /Z7 /Od /Ob0 /E Hsc /GR /MDd -I"..\..\..\libs\graph\src" -I"C:\bugsnoop\trunk\src\checkmate\boost" -I"..\..\..\bin .v2\libs\graph\build\msvc-8.0\debug" -c -Fo"..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphvi z_digraph_lex.obj" "..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_digraph_lex.cpp" ...failed msvc.compile.c++ ..\..\..\bin.v2\libs\graph\build\msvc-8.0\debug\graphviz_digraph_lex.obj. ___________________________

2 1

BGL question: edge order
by Andreas Fabri 19 May '05

19 May '05

Hello, in order to store planar graphs, I am wondering if the graph classes of the BGL allow to enforce an order of the edges which are adjacent to a vertex. Also is it possible to add an edge between two edges. andreas

2 1

BGL: copy graph & edge predicate question
by Sebastian Weber 19 May '05

19 May '05

Hello Everybody! I am trying to extract a part of a graph. Speaking in terms of the BGL, I do a copy from a filtered graph object into a new graph. To do so, I defined a VerticePredicate for the filtered graph. As a result not all vertices in the graph are present in the filtered version. This implies that some edges do disappear in the filtered version fo the graph. In order to copy from this filtered graph into a new, fresh graph via copy, do I have to use the following EdgePredicate? // edge predicate which only lets edges through which are part // of the given VerticePredicate template <class Graph, class VerticePredicate> struct edge_filter { typedef boost::graph_traits<Graph> Traits; typedef typename Traits::edge_descriptor Edge; // needs to be default-constructible ! edge_filter() { } edge_filter(Graph& g, VerticePredicate& vFilter) : m_g(&g), m_vFilter(&vFilter) {} bool operator()(const Edge& e) const { return (*m_vFilter)(boost::target(e,*m_g)) && (*m_vFilter)(boost::source(e,*m_g)); } private: Graph* m_g; VerticePredicate* m_vFilter; }; Or is this not necessary and implicitly done by the filtered graph interface? Another thing concernig the copy-function: Is there a way to NOT copy the vertice indices, but rather have the vertices renumbered from 1 to size of filtered graph? I guess I have to cope with the vertice_copier-function stuff, but I don't see how to do it. And another matter: The copy_component function does not seem to be documented. I found it by chance in the sources of copy.hpp. Thanks a lot! Sebastian Weber

2 1

Question about template optimization
by Elisha Berns 19 May '05

19 May '05

I need help with this one, even though it's a pure C++ question, it's about template optimization: If a template class has methods that DO NOT depend on or use the type parameter(s) of the template will the code for the methods nevertheless get instantiated separately for each unique instance of the template class? For example, if there are 20 unique types used to declare 20 instances of template class X, do those methods get implemented 20 different times, needlessly, and cause a big code bloat? Even if most compilers are smart about this kind of thing, is it still better practice to separate from the template class (or method) all of the code that does not use the template type parameters? Thanks, Elisha Berns e.berns(a)computer.org

1 0

Re: ~intrusive_ptr bug?
by Jean-François Brouillet 18 May '05

18 May '05

>> intrusive_ptr(T * p, bool add_ref = true); >> Effects: if(p != 0 && add_ref) intrusive_ptr_add_ref(p);. >> >> Postconditions: get() == p. > > [...] > > Right, so you can't call it a bug if the implementation does > exactly as stated. ;-) Consider: X * x = new X ; { intrusive_ptr<X> px(x) ; } Here, x is destroyed, and rightly so. Now (same example as yesterday): X * x = new X ; { intrusive_ptr<X, false> px(x) ; } Here, x is destroyed *too*, even though the additional "false" was supposed to mean: "please, don't mess-up with refCounts at all, *I* have everything under control. Nope. If preserving the current intrusive_ptr semantics is paramount (as I kind of sense it is now), some confusion could be avoided by renaming "addRef" to something less ambiguous or suggestive. The question is not _how_ it does what it does (it does it by adding 1 to the refCount, or not, hence that dubious name) but _what_ it does when that argument is set to false. If it is difficult to find a name to describe _what_ it does in such a case (which might point to a poorly understood use-case) then the next best thing is probably a catch-all word such as "standard", which, by negation (=false) means a clear warning: "What you're about to do when setting ``standard'' to false is, by definition non standard, and you *must* understand so and so to avoid being caught with your pants down" > I'm pretty sure that a shared_ptr-based port can closely > approximate the original, "approximate"! That's the key. I don't want to "approximate". Either I find a way to *completely* hide the smart pointer modulo: - the initial "new X" - "on the fly" packaging of ``this'' when required __from within__ (ie when passing ``this'' to some other unrelated method of some other class that requires an _envelope_ as argument and not a _body_, since my whole API, once translated from Java, will only expose _envelopes_) or I will go the painful Boehm's road and use conservative GC. > but a custom smart pointer would probably be a better choice for > idiomatic Java code. I wish you are right! I'll give myself all the evenings and week-ends until the end of May. If I fail to come up with something that is acceptable, I'll go conservative, because "Real artists ship!" :-) > As for intrusive_ptr, its main strength is that it has the size > of a pointer. HoHum ...scoped_ptr shares this "exclusive" strength ... > Adding a boolean would likely meet serious opposition. Never mind the opposition. Is that the right thing to do or not? Since I don't understand your use cases, I just can't comment. > Your requirements are very interesting, however, and point to a > shared/intrusive hybrid along the lines of: > > template<class T> class intrusive_ptr_2 > { > T * px_; > intrusive_ptr<Object> pn_; > > // insert smart pointer boilerplate here ;-) > }; I'm not sure I understand. pn_ is supposed to perform the refCounting part, and px_ is supposed to be the actual _body_ ? > It's an intrusive pointer that's close to shared_ptr in expressive > power; you can use it to point to a subobject, for example. > > Extending intrusive_ptr to accommodate the above along the lines of > > template<class T, class U = void> class intrusive_ptr > { > T * px_; > U * pn_; // not present when U == void > }; > > could be feasible. I'm lost. I don't see how this relates to the problem of providing an indirection ("pointer") construct such that, once you've have written xxxx_ptr<X> p(new X) ; you're done, once and for all, never asking _user_ code to deal with the intricacies of your xxxx_ptr *implementation*. When you come to think of it, a garbage collector is meant to provide _automatic_ garbage collection, not semi-automatic, or half-manual. Compounding the problem of memory management with additional idiosyncratic problems is not going to free that one remaining brain cell out of a total of 7, that holds the whole universe under your current consciousness level. A bad guarantee is worse than no guarantee at all. IMHO :) Many thanks -- JFB

2 1

RE: [Boost-users] Re: fatal error C1204 on MS .Net with boost serialize
by Olivier Vanden Bos 18 May '05

18 May '05

/Zm do not change anything in this case. I use the 1.32 version, with the .Net project , but the parameters for the boost project are not concerned, as the compiler block when compiling my files in my project. Actually I am trying to have feedback from Microsoft... http://www.kbalertz.com/kb_883655.aspx - VDB - "LNK1210: exceeded internal ILK size limit" -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 18 mai 2005 15:53 To: boost-users(a)lists.boost.org Subject: [Boost-users] Re: fatal error C1204 on MS .Net with boost serialize Look at the command line switches used by bjam for this platform. Also, the 1.32 and 1.33 packages include premade VC 7 projects with command line switches set. Look at them. Definitely use /Zm800 among others. Robert Ramey Olivier Vanden Bos wrote: > It's just my signature :) (bad idea, I can see that) > The real error is > > Fatal Error C1204 : compiler limit : internal structure overflow > The compiler has run out of memory. Your program needs to be > simplified, perhaps by splitting a large source code file into > smaller files. > > And i found a mail about that "[Boost-users] serialization library - > Serializing classes from a DLL", that didnt not solve my case > (identical) but explain it :P > It is just that the work around (splitting the file) becomes very hard > to apply , actually i need to put one BOOST_DCL for each file !!! > > > - VDB - > > > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Arne Vogel > Sent: 17 mai 2005 03:35 > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] fatal error C1204 on MS .Net with boost > serialize > > Olivier Vanden Bos wrote: > >> I ve got a lot of this, i m forced to split all declarations of >> classes in separate .cpp file. >> >> In fact, Boost::serialize become unusable... >> >> Does somebody have a solution ? >> >> **- VDB - ** / / >> / "//LNK2019: unresolved external symbol//"/ >> * * >> > > Could you be more specific about _what_ symbols are unresolved? > > - Arne Vogel > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

RE: [Boost-users] Re: fatal error C1204 on MS .Net with boost serialize
by Olivier Vanden Bos 18 May '05

18 May '05

I just tried. Nothing changed. - VDB - "LNK1210: exceeded internal ILK size limit" -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: 18 mai 2005 15:14 To: boost-users(a)lists.boost.org Subject: [Boost-users] Re: fatal error C1204 on MS .Net with boost serialize "Olivier Vanden Bos" <olivier.vanden-bos(a)ubisoft.com> wrote in message news:930168C299A0C44D905F4B11995AD744013FD607@UBIMAIL2.ubisoft.org... > It's just my signature :) (bad idea, I can see that) > The real error is > > Fatal Error C1204 : compiler limit : internal structure overflow > The compiler has run out of memory. Your program needs to be simplified, > perhaps by splitting a large source code file into smaller files. Have you tried using: #define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP in your translation unit previous to any serialization header inclusions? Jeff Flinn _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

RE: [Boost-users] fatal error C1204 on MS .Net with boost serialize
by Olivier Vanden Bos 18 May '05

18 May '05

It's just my signature :) (bad idea, I can see that) The real error is Fatal Error C1204 : compiler limit : internal structure overflow The compiler has run out of memory. Your program needs to be simplified, perhaps by splitting a large source code file into smaller files. And i found a mail about that "[Boost-users] serialization library - Serializing classes from a DLL", that didnt not solve my case (identical) but explain it :P It is just that the work around (splitting the file) becomes very hard to apply , actually i need to put one BOOST_DCL for each file !!! - VDB - -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Arne Vogel Sent: 17 mai 2005 03:35 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] fatal error C1204 on MS .Net with boost serialize Olivier Vanden Bos wrote: > I ve got a lot of this, i m forced to split all declarations of > classes in separate .cpp file. > > In fact, Boost::serialize become unusable... > > Does somebody have a solution ? > > **- VDB - ** / / > / "//LNK2019: unresolved external symbol//"/ > * * > Could you be more specific about _what_ symbols are unresolved? - Arne Vogel _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

4 3

Intefaces (BIL) IDL formating
by Tim Michals 18 May '05

18 May '05

I'm trying to figure out how would you format the IDL function for a general function like printf? For example the function is printf( const char *fmt, ...) How you format the IDL function? BOOST_IDL_FN1(formatMsg, const char *fmt)

2 1