- Boost - lists.boost.org

Trying to get Boost.Python to build on Solaris 10 using SUN Studio 11
by Timo Geusch 10 Jul '06

10 Jul '06

Good afternoon, I've so far managed to make decent progress on building RC 1.34's Boost.Python on this OS/Compiler combination using jam v1 with the patches I submitted earlier. Unfortunately I now seem to have hit a brick wall in file pickle_support.cpp. The offending lines of code are line 57, which reads: static object result(&instance_reduce); If I replace this line with plain static object result; the file will compile, however the above line produces the following error message from the compiler: sunpro-C++-action bin/boost/libs/python/build/libboost_python.so/sunpro/debug/pickle_support.o "./boost/python/converter/arg_to_python.hpp", line 215: Error: Could not find boost::python::converter::detail::arg_to_python_base::arg_to_python_base(boost::python::tuple(*)(boost::python::api::object), const boost::python::converter::registration) to initialize base class. "./boost/python/object_core.hpp", line 309: Where: While instantiating "boost::python::api::object_base_initializer<boost::python::tuple(*)(boost::python::api::object)>(boost::python::tuple(*const)(boost::python::api::object)&)". "./boost/python/object_core.hpp", line 309: Where: Instantiated from non-template code. 1 Error(s) detected I think I'm missing something obvious here but I'm not familiar enough with the Boost.Python code to work out what it is. I'd appreciate if someone who is would be able to have a closer look as this is the last file that doesn't build here. Regards, Timo

2 2

[function] Internal compiler error on VC 7.1 with default parameter
by Allen Bierbaum 10 Jul '06

10 Jul '06

The following code snippet: #include <boost/function.hpp> class TestClass { public: void doSomethingDefault(boost::function2<void, bool, bool> cb=boost::function2<void,bool,bool>()) {;} }; int main() { TestClass test; test.doSomethingDefault(); return 1; } Gives an internal compiler error on vc 7.1: cl /nologo /Od /Ob0 /Z7 /W1 /MDd /EHsc /GR /TP /Ic:\Software\boost\boost_1_33_1 /DWIN32 /D_WINDOWS /D_DEBUG /c test.cpp /Fotest.obj test.cpp test.cpp(6) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information scons: *** [test.obj] Error 2 scons: building terminated because of errors. (line 6 is the method declaration with the default value). If I remove the use of the default value, the code compiles with no errors. I know this code compiles and works correctly on gcc 4.0 and I believe I have used it with older versions of gcc. Is there something incorrect with my usage? If not, is this an known issue? I searched through the bug tracker and the mailing lists but did not see anything about this bug. Does anyone have any ideas on how to work around this bug? Thanks, Allen

2 2

Preliminary release of clone_ptr library
by Kevin Spinar 10 Jul '06

10 Jul '06

(this will be the first and last "progress update" message until it comes time to summit for a review to boost) For better or for worse (it seems there's much debate on clone_ptr) I have started on the clone_ptr library and have a working preliminary clone_ptr class. Details can be found at the following URL and I will update the website as my work progresses: http://www.peltkore.net/~alipha/clone_ptr.html If anyone is interested in receiving email updates or would like to collaborate on the project (which could just simply be someone I could bounce ideas off of) email me. To contribute some to the discussion: It has been noted that the Boost.pointer_container library could be used instead of having a container of clone_ptr. However, what if you want to use non-standard containers? Yes, Boost.pointer_container has ptr_*_adapter classes, but they can't be used for containers which don't follow the container requirements set by the C++ standard. Secondly, even if a third party container class follows the container requirements, it is still unnecessary work to create your own pointer container. Consider this generic tree class: http://www.aei.mpg.de/~peekas/tree/ http://www.aei.mpg.de/~peekas/tree/doxygen/html/functions.html There's dozens of functions in the tree class that would have to be wrapped in a ptr_tree class that the boost::ptr_sequence_adapter class doesn't wrap for you. Compare this to: tree<clone_ptr<T> > foo; The clone_ptr solution seems a lot easier. The same argument could be made with boost::graph, etc. Also, I've decided to give clone_ptr clone-on-write semantics instead of clone-on-copy. This should alleviate any concerns about performance when inserting into a std::vector or copying containers (copying clone_ptr would give similar performance to boost::shared_ptr). Kevin Spinar

4 10

Exception library proposal update
by Emil Dotchevski 10 Jul '06

10 Jul '06

Hello, As a result of today's discussion, I added a function get_exception_info to the interface of the proposed Boost Exception library: template <class T> exception_info * get_exception_info( T & ); It can be used in a catch( T & ) block, to check if the exception object has a sub-object of class exception_info. I updated the documentation, source code and tests accordingly, all available at: http://www.revergestudios.com/exception/exception.htm Click "download" to get the code and the tests, complete with boost build jamfiles. Thanks, Emil

5 15

Quickbook :/
by Philippe Vaucher 10 Jul '06

10 Jul '06

Hello, I've received many valuable advices on how to set quickbook however I still can't make it work. My platform is windows, I managed to have bjam build quickbook.exe, but from there I can't build any of the docs like in \boost\libs\type_traits\doc. For convenience's sakes I put quickbook in C:\WINNT so it's easier to read for you, but no matter which path I put bjam can't find quickbook I have user-config.jam with : using xsltproc ; using boostbook : C:/boost/tools/build/v2/docbook-xsl-1.70.1/ : C:/boost/tools/build/v2/docbook-xml-4.2/ ; using doxygen : C:/Progra~1/doxygen/bin/ ; using quickbook : C:/WINNT/quickbook.exe ; I tried to set "using quickbook;" but then it start building teh whole boost, I tried "using quickbook : C:/WINNT/ ;" but same problem. When I run "bjam --v2" in \boost\libs\functional\hash\doc, here's the output : C:\boost\libs\functional\hash\doc>bjam --v2 warning: Python location is not configured warning: the Boost.Python library won't be built Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). warning: toolset quickbook initialization: can't find tool C:/WINNT/quickbook.exe warning: initialized from warning: toolset quickbook initialization: can't find tool C:/WINNT/quickbook.exe warning: initialized from ...found 19 targets... ...updating 3 targets... quickbook.quickbook-to-boostbook..\..\..\..\bin.v2\libs\functional\hash\doc\msvc\debug\hash.xml Generating Output File: C:\boost\libs\functional\hash\doc\hash.xml xslt-xsltproc ..\..\..\..\bin.v2\libs\functional\hash\doc\msvc\debug\hash.docbook warning: failed to load external entity "../../../../bin.v2/libs/functional/hash/doc/msvc/debug/hash.xml" unable to parse ..\..\..\..\bin.v2\libs\functional\hash\doc\msvc\debug\hash.xml set XML_CATALOG_FILES=..\..\..\..\bin.v2\libs\functional\hash\doc\msvc\debug/catalog.xml "xsltproc" --xinclude -o "..\..\..\..\bin.v2\libs\functional\hash\doc\msvc\debug\hash.docbook" "C:\boost\tools\boostbook\xsl\docbook.xsl" "..\..\..\..\bin.v2\libs\functional\hash\doc\msvc\debug\hash.xml" ...failed xslt-xsltproc ..\..\..\..\bin.v2\libs\functional\hash\doc\msvc\debug\hash.docbook... ...skipped <phtml>HTML.manifest for lack of <p..\..\..\..\bin.v2\libs\functional\hash\doc\msvc\debug>hash.docbook... ...failed updating 1 target... ...skipped 1 target... ...updated 1 target... If anyone has a clue about what's going on it'd be nice. Philippe

5 7

[test] regressions for vc-6_5
by Joaquín Mª López Muñoz 10 Jul '06

10 Jul '06

The parameterized_test_test test for Boost.Test is failing for MSVC 6.5, as shown at http://tinyurl.com/lek2w . This can be fixed by just reverting a workaround on boost/test/parameterized_test.hpp which was removed Jan 28th 2006 (v1.6 --> v.1.7) Is it OK to bring the workaround back? If given permission, I can do that myself. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Re: [boost] [shmem] error while closing the segment
by Ion Gaztañaga 10 Jul '06

10 Jul '06

> yes, the destructor performs two destroy calls in front of the close > call (see below). But it should not give a damn about, destroyed is > destroyed. The call of close should only delete objects that still > exists. I've printed out the name of the named shared object which > triggers the error (it's "shmDefinition"). If I comment out the two > lines which destroy my named shared objects in the destructor, it works. > Hmm, I don't know why it not work when I destroy the objects by hand. > But definitely it should not be done twice. You are right. But this indicates that you somehow have tried to erase the same object (in this case ("shmDefinition")) twice (maybe another process?). It should assert when using a pointer (because otherwise that could corrupt all the segment) when deleting the object (a debug protection like when trying to "operator delete" the same ptr two times). However, when destroying by name, a bool is returned, saying if the object has been destroyed or not (well the only problem is to found the name in the name-object index). So it should return false in the second case, instead of asserting. The only problem is that both name and pointer delete operation uses the same code, and only one should assert. Thanks for finding this! Please, erase that assertion from your code. I will do the same in Sandbox-CVS, while I find some other solution. Regards, Ion

1 0

Minor exception lib changes
by Emil Dotchevski 10 Jul '06

10 Jul '06

Hello, I am contemplating a few minor changes to the exception library and I wanted to get some input before I implement them. First, I think that the function template failed should be renamed. Somehow, boost::failed doesn't feel right. Since English is not native to me, I really need help with this one. Second, I'm thinking of renaming wrap_string/get_string. Those names did make sense in the implementation I've been using in my own code, because the whole thing was in namespace except. Clearly, boost::get_string doesn't suggest that it's part of the exception library. I'm thinking of renaming them both to exception_string. So, stuffing a string at the time of the throw would look like this: throw failed<foo>() << exception_string<tag>("value"); To extract the string from an exception_info object, you'd do this: exception_info & xi; if( std::string const * s = exception_string<tag>(xi) ) .... Similarly, it makes sense to rename both wrap_errno/get_errno to exception_errno. Thanks for everyone's input! --Emil

2 1

boost.shmem bugs
by Dmitry Smirnov 10 Jul '06

10 Jul '06

1. If you hasn't semaphore support in your glibc libraries (in my case it was without TLS) "sem_open" function will return (sem_t*)0 instead of (sem_t*)-1 as it is described in my system header "semaphore.h". Plese correct file "shared_memory.hpp" for using SEM_FAILED macros. Defines in "semaphore.h": /* Value returned if `sem_open' failed. */ #define SEM_FAILED ((sem_t *) 0) /* Maximum value the semaphore can have. */ #define SEM_VALUE_MAX (2147483647) 2. Unclear sinuation. I wrote bugous example program where I write some data in shared_message_queue in infinity cycle without any timeout. If you stop program by Ctrl+C "boost_shmem_shm_global_mutex" stays in locked state so program will not work from second start. If you include some timeout in cycle then program will work properly. Thank you for good job! \o/ Best Regards, Dmitry Smirnov Saint-Petersburg, Russia Slackware 10.2 gcc-3.4.4 kernel 2.6.13 glibc-2.3.6

2 4

[function] Conflict with Boost.TR1
by John Maddock 10 Jul '06

10 Jul '06

Unfortunately another TR1 problem, in boost/function/detail/prolog.hpp we currently have: # include <cassert> # include <algorithm> # include <functional> // unary_function, binary_function The inclusion of <functional> here causes a circular dependency between the TR1 version of <functional> and <boost/function.hpp> leading to a long list of compile errors: simply including <boost/function.hpp> on it's own is enough to trigger these when the TR1 headers are in the include path. The only (ugly) fix I can offer at present is to use <boost/config/no_tr1/functional.hpp> in place of <functional>. Better suggestions, or policies welcomed, this is starting to become a maintenance nightmare.... John.

1 0