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

Re: [Boost-users] boost::python and Python 2.4
by Nat Goodspeed 09 Nov '05

09 Nov '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Noel Yap > Sent: Tuesday, November 08, 2005 9:14 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] boost::python and Python 2.4 > > I see the problem. Since the location of pyconfig.h depends upon > which compiler was used, it's not located in the same directory as the > rest of the Python header files. [Nat] ? Sorry, I don't understand you at all. On my Windows system I installed Python 2.3 into the default directory, c:\Python23. Likewise Python 2.4 is installed in c:\Python24. The only pyconfig.h files on my system are in 'include' subdirectories of those two directories. They don't seem to be in compiler-dependent locations, and those 'include' subdirs ARE where 300+ other Python header files live. It's worth noting that we build the Boost libraries we use as MSVC 7.1 projects. Those projects (and others) look for a PYTHONDIR environment variable whose value used to be c:\Python23 and is now c:\Python24. > I've tried passing a ':'-separated path as PYTHON_INCLUDES, but that > doesn't work. Anyone have any thoughts on this? I suppose I /could/ > hack around this by using symlinks, but I'd rather find a less hacky > solution. [Nat] So, maybe the reason I don't understand the problem you're having is because you're on a different system with a different compiler.

2 2

[BGL] a.k.a. [Graph] -- bundled properties not compiling for me under MS Dev
by Goldman, Jon 08 Nov '05

08 Nov '05

Hello, I am using Microsoft Development Environment 2002. I am trying to compile a Graph and use bundled properties. The error I am getting: \src\vtkSNL\Applications\RouteViz\rtrGraph.cxx(37) : error C2676: binary '[' : 'SimpleGraph' does not define this operator or a conversion to a type acceptable to the predefined operator \src\vtkSNL\Applications\RouteViz\rtrGraph.cxx(37) : error C2228: left of '.i' must have class/struct/union type The code snippet below exhibits the problem: struct nodeProp { int i; }; struct edgeProp { int i; }; typedef adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, nodeProp, edgeProp> SimpleGraph; void someFunc() { SimpleGraph someGraph(3); Graph::vertex_descriptor v = *vertices(someGraph).first; someGraph[v].i = 7; // This line is where the error is occuring } Anybody familiar with this problem? Thanks for looking this over, -Jon

2 1

What is the way to sort graph vertices?
by Slava 08 Nov '05

08 Nov '05

Hi, I need to find Maxumum Common Subgraph (between two graphs). For that task i need to get all the vertices of the 2 graphs sorted with some property (like vertex label or id). regular std::sort seems not working with vertex iterators (vertices(graph)). What is the way to accomplish this? Thanks

2 1

Re: [Boost-users] [Boost][serialization] Serialization and DLLs
by Topi Mäenpää 08 Nov '05

08 Nov '05

>>> Could this be related to the fact that the low-level type_info pointer >>> for the classes is different in the dll and the exe? > > That sounds like it could explain this. > > >>> (This is also the >>> reason why dynamic_cast doesn't work across dynamic library >>> boundaries.) > > I've never heard of this before. If this is true it would be key indicator > that > something's wrong. Is this a known MSVC bug? That would be very > interesting to know. I'm not a pro on this matter, but at least gcc (and its Windows version, mingw) have similar "feature". I still need to double-check if I have forgotten to include rtti support somewhere, but I have seen a couple of different my::dynamic_cast implementations that try to work around this. The most well known one might be Qt:s qobject_cast. As far as I know, compilers use pointer equivalence to compare type_infos. It seems that the type_info pointer isn't exported from dynamically loaded modules, which makes dynamic type casting (and also certain exceptions) impossible across dll boundaries. I don't know the reason, but I have verified this with three different compilers, on Linux and Windows. > Is it possible to use the non-rtti versions with MSVC > >>> 7.1? > > > I have implemented non-rtti version which is documented and tested - > test_non_rtti. > The test verifies that types which are identified with different runtime > typing systems > can inter-operate. The library includes extended_type_info_no_rtti.cpp (a > mis-nomer > I see now). This runtime typing system uses the BOOST_CLASS_EXPORT key > as the type identifier. So to use this you'll have to fix the > "type_info_implementation" > trait for this type and besure its exported. This hasn't really been used > except in the > testing (as far as I know). As far as using it a derived class defined in a > DLL where > the base class is in some other library? Too bad I found the reason this late. You already had the feature there! > I reviewed the relevant code and have verified that the serialization system > presumes > that type_info returns the same value regardless of whether the type is > implemented > within a an executable, standard library or dll. I can't imagine why it > would be any > other way. I also don't have any other reports of this. Of course, this is > not > a common usage so that probably doesn't mean much. Double check that that > there aren't any differences in things like _cdecl etc. Maybe that might > explain > why the run-time type signatures vary depending up where the type is > implemented. > > I've started written my own test of this situation but its kind of hung up > in some > in trying to get it worked into bjam. So I haven't finished it. > > I'll do what I can. Thanks for a thorough inspection of the matter. I finally managed to work out a temporary hack that does the thing. Here is how: Change tkmap/ktmap multisets to sets. Modify extended_type_info so that it always compares keys literally. Re-export base classes from wherever subclasses are exported. This ensures that the correct key is recorded to extended_type_info even though there are multiple distinct instances. The downside is that one now always needs a key, but I'm assuming it is the only possible way of dealing with shared libs anyway. Phew! I like the design of the library and the ease of use a lot. Good luck this is (at least partially) resolved now, because it would have been a show stopper to me. I hope my findings have some use in developing an even better version of it :) Best regards, Topi (not so frustrated any more, I'm gonna meet the deadline ;)

1 0

Pyste question--how to exclude a constructor?
by Drumheller, Michael 08 Nov '05

08 Nov '05

I would like to be able to exclude a constructor. My situation is precisely analogous to this: http://mail.python.org/pipermail/c++-sig/2004-March/006952.html But the above thread did not seem to terminate with a solution. Does anyone know how to do this? Thanks, MD

1 0

Re: [Boost-users] [Boost][serialization] Serialization and DLLs
by Topi Mäenpää 08 Nov '05

08 Nov '05

> I have a suggestion, please comment. The problem _could_ be in that >> guid_initializer isn't exported. If I register my base class in a >> DLL, the DLL interface does not expose the >> guid_initializer::instance I have created. Since my exe now doesn't >> know about it, it creates a new definition. The same applies to >> other DLLs. (This would also explain why the same code works on >> Linux: all symbols are automatically exported.) What if we exposed >> the guid_initializer struct to the DLL interface? Would it help? At >> least it shouldn't do any harm to export it from the exe. > That might explain the behavior. We'll look into it. I'm having > problems making test which uses a dynamically loaded DLL that I can > run under bjam. No, it didn't work... I also exported the extended_type_info subclasses (_0 and _1) from my DLL, but I still encounter the same problems. The code lacks comments, and I find it difficult to study some some of the constructs. It seems that whenever I register a class, its superclasses get registered as well. The extended_type_info pointer for my common superclase is however different for each instantiation. The exe crashes due to an unhandled unregistered_cast exception thrown at oserializer.hpp:408. Thus, it seems that downcasting cannot succeed. I even modified the extended_type_info so that it always compares keys literally instead of pointers, but this has no effect. Furthermore, I changed the tkmap and ktmap multisets to sets. I assumed this could prevent multiple registrations, but it does not. Could someone point me out a way to work around this? Any temporary solution will do until the problem has been identified and fixed. Best regards, Topi

2 3

Re: [Boost-users] linker problem with regex library - resolved
by Oliver.Kowalke＠infineon.com 08 Nov '05

08 Nov '05

Hello, I could get the boost libraries linked against my application if I compile the boost libraries with -fpic (bjam "-sBUILD=release debug <cxxflags>-fpic" "-sTOOLS=gcc" install). I think you should use -fpic as default parameter in the boost build for gcc on (at least) HP/UX PA RISC 11.11. The -fPIC choice always works, but may produce larger code than -fpic. Using -fpic option usually generates smaller and faster code, but will have platform-dependent limitations, such as the number of globally visible symbols or the size of the code. The linker will tell you whether it fits when you create the shared library. When in doubt, I choose -fPIC, because it always works. @John: would this be possible? With regards, Oliver >> I get the linker error (see below) if I try to compile my test app. >> What is the problem? >> >> /usr/ccs/bin/ld: Invalid loader fixup in text space needed in output >> file for symbol "__gxx_personality_sj0" in input file >> "/opt/boost/lib/libboost_regex-gcc. > >No idea, I did a quick google for this error message and it seems to be a >common error when people are building shared libraries, but with one of the >components not built with -fPIC. So for example if you tried to link a >static regex build into a shared lib. Does this sound familiar? > >John. > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] boost::python and Python 2.4
by Nat Goodspeed 07 Nov '05

07 Nov '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Noel Yap > Sent: Monday, November 07, 2005 3:47 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] boost::python and Python 2.4 > > Is there any work being done to get boost::python to work with Python > 2.4? Does anyone see any reasons it won't work (assuming the build is > able to work)? [Nat] I hope nobody sees any reasons it wouldn't work: we're using Python 2.4 now. But we're also using Boost 1.31. I tried to convert to 1.32 a couple months ago and ran into failures I didn't understand with other parts of Boost. I haven't yet charged with lowered spear at 1.33.

2 1

[Wave] extracting preprocessing grammar and comments from sourcefile
by Andreas Sæbjørnsen 07 Nov '05

07 Nov '05

After looking at the documentation of Wave I believe it can be used to extract the preprocessor grammar and I am therefore looking for some tips on how to get started on my problem. I want to adapt wave into a mechanism for exptracting all preprocessor grammar from a source file without modifying the library itself, and I will try to explain what I want to use wave for. What I want to do is to *extracting the position and value of preprocessor tokens like #ifdef's, #defines, #warning etc. *evaluate the preprocessor conditionals *after evaluating the preprocessor conditional, extract the portion which was evaluated as false as a string #define positive #ifdef int positive #endif /*Extract this false part as string*/ int x; #endif *I am also interested in the value and position of unexpanded macros *extracting the C/C++ statement or expression that the unexpanded macro (and expanded) is a part of. *extract the value and position of all C and C++ comments Which work should I bace my work upon and which data structures should I reimplement and for what? I have looked at the documentation and the code, and it seems easy to do some parts but other are not obvious to me at this point. Thanks, Andreas Saebjoernsen

2 9

LNK2019: unresolved external symbol
by Hiba Tabbara 07 Nov '05

07 Nov '05

1 0