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

[boost::program_options] bad_function_call and -g
by alexandre.ignjatovic＠insia.org 17 Aug '05

17 Aug '05

Hi, Does anyone know why i get a bad_function_call at the execution of this code (compiled without the '-g' option): namespace bpo = boost::program_options; _optDesc.add_options() ("version,v", "print version") ("help,h", "print this help message") ("config-file,f", bpo::value<std::string>(&_cfg)->default_value(_cfg), "specify configuration file") ("id,i", bpo::value<std::string>(&_id)->default_value(a_id), "specify server identifier"); bpo::variables_map vm; bpo::store(bpo::parse_command_line(argc, argv, _optDesc), vm); bpo::notify(vm); while it runs correctly with "-g" ? Compiler : gcc 343 (linux) or cc 57 (solaris) Boost version: 1.32.0 The exception seems to be trown by the notify function. By the way, it is quit hard to trace undebuggable compiled code (no -g, no way :)) Thanks in advance. -- Alexandre Ignjatovic

2 4

bjam - How to remove intermediate files?
by Matt Vogt 17 Aug '05

17 Aug '05

What is the equivalent of 'make clean' with bjam? 'bjam clean' seems to remove targets as well as intermediate files... I just want to remove objects in the build tree. Thanks, Matt

2 1

[Deprecation methods] (was [range] From 1.33.0 gives newwarningvs1.32)
by Sohail Somani 16 Aug '05

16 Aug '05

> maybe, but remember the code in question is deprecated and so > is likely to disappear in1.34. Speaking of deprecation, are there any compiler independent ways to indicate API deprecation ala Java? I investigated this a while back using compile time errors if a certain preprocessor directive was defined but it got hairy with virtual methods. Sohail

1 0

std::vector<std::string> pb
by Lana Abadie 16 Aug '05

16 Aug '05

Hello, Sorry to reiterate but if it's not the right forum to send this kind of message, I would really appreciate that sb tells me where to post it, because I'm stuck. Thanks for helping Lana /*****************************/ Hello, I am using boost for the first time. I have the following boost.cpp file: #include "../confDBAPIpython/test1.h" #include <boost/python.hpp> #include <boost/python/suite/indexing/vector_indexing_suite.hpp> #include <boost/python/module.hpp> #include <boost/python/def.hpp> #include <boost/python/implicit.hpp> using namespace boost::python; BOOST_PYTHON_MODULE(confDBAPIpython) { // Compile check only... class_<std::vector<int> >("IntVec") .def(vector_indexing_suite<std::vector<int> >()); class_<std::vector<std::string> >("StringVec") .def(vector_indexing_suite<std::vector<std::string> >()); def("DBConnexion",PyDBConnexion); def("DBDeconnexion",PyDBDeconnexion); def("GetDeviceTypeRow",PyGetDeviceTypeRow); def("GetDeviceRow_devicename",PyGetDeviceRow_devicename); def("GetDeviceRow_deviceid",PyGetDeviceRow_deviceid); def("GetDetailedConnectivityBetweenDevices",PyGetDetailedConnectivityBet weenDevices); def("GetConnectivityBetweenDevices",PyGetConnectivityBetweenDevices); } The two last fct returns vector<std::string>. When I try to use them in python, I have the following error message: list_str=libconfDBAPIpython.GetConnectivityBetweenDevices("TFC","THOR_00 ","ECAL_L1FE06_02_00"); print list_str[0]; Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: No Python class registered for C++ class std::string I don't understand why. I thought it will be handled by the vector_indexing_suite. I have no problem when a fcuntion returns a string or a vector<int> Thanks for helping Lana

2 1

Re: [Boost-users] [BULK] Re: [BULK] Re: [range] From 1.33.0 gives newwarningvs 1.32
by Sohail Somani 16 Aug '05

16 Aug '05

> no. I always use const_cast in my own code. so that is why I > believe it might be there for a reason. Speaking from my own experience, I've found that people use C-style casts because theyre lazy OR they don't understand what they want to do. The latter is really scary sometimes but its normal. Anyway, because I am dealing with a legacy C api, sometimes I have to const_cast to call these functions, but marking these with const_cast makes the casts easy to look for.

1 0

Re: [Boost-users] [BULK] Re: [BULK] Re: [range] From 1.33.0 gives newwarningvs1.32
by Sohail Somani 16 Aug '05

16 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Thorsten Ottosen > Sent: Tuesday, August 16, 2005 8:45 AM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [BULK] Re: [range] From > 1.33.0 gives newwarningvs1.32 > Importance: Low > Porting something to 10+ compilers is not always super easy. I agree, I have to only deal with the two of the most popular ones and even that's a headache sometimes. > And changing something that might break a regression is > always something I'm a bit reluctant to do. Yes, I've seen > compilers where a reinterpret_cast > + const_cast did not do what c-style cast would do. Don't ask me why. > + :-) You scare me.

1 0

Re: [Boost-users] [BULK] Re: [range] From 1.33.0 gives newwarningvs 1.32
by Sohail Somani 16 Aug '05

16 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > David Abrahams > Sent: Monday, August 15, 2005 2:55 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [BULK] Re: [range] From 1.33.0 > gives newwarningvs 1.32 > > Thorsten, the difference is in fragility over time with > maintenance. That's why the compiler issues the warning. Any > decent beginner's book on C++ will advise you to eschew all > casts, and prefer the new-style ones. Do you really need to > have the fundamentals of good > C++ programming practice explained? > > Incidentally, if you find that the proper C++ construct is > "less portable. somehow." you should use BOOST_WORKAROUND to > isolate the compiler for which it fails to work, if only so > that the reason for the workaround is documented. I thought the same thing but my name isnt Dave Abrahams and I don't have an important email address. Doh.

2 1

Re: [Boost-users] [serialization][1.33.0?] xml_iarchive leak
by Richard Jennings 16 Aug '05

16 Aug '05

> > > b) If I recall correctly, the borland version of scoped_ptr > fails when > > the type is incomplete - which makes it not useful for implementing > > the PIMPL idiom. > > it always fails unless the destructor is included first in > the cpp file IIRC. > Sadly this does not work on BCB even if the destructor is defined in the cpp file, which means that scoped_ptr can't be used for pimpl with this compiler. The details are here: http://lists.boost.org/Archives/boost/2001/12/21796.php You can of course use shared_ptr, but then the intention is less clear.

2 1

Re: [Boost-users] Maybe a problem with boost::object_pool?
by Labour, Matthieu (MLPRO SF) 16 Aug '05

16 Aug '05

Thank you for your answer Sorry about the wrong info RedHat: uname -a : Linux ejecxapeqdtmad01 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 athlon i386 GNU/Linux /etc/redhat-release: Red Hat Enterprise Linux AS release 3 (Taroon Update 5) GNU gcc version: gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52) I'll try to update gcc and run the test again Did you try to run the test and and crash the program? Thank you -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Caleb Epstein Sent: Thursday, August 11, 2005 4:51 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Maybe a problem with boost::object_pool? On 8/9/05, Labour, Matthieu (MLPRO SF) <matthieu_labour(a)ml.com> wrote: > I use Red Hat linux 3.2.3-47 Are you sure that is the version you're using? That doesn't look like a RedHat version number. What does "uname -a" tell you, and what is the contents of /etc/redhat-release? I have: Linux scsefpldcs0213 2.4.21-27.0.4.ELhugemem #1 SMP Sat Apr 16 18:22:53 EDT 2005 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux AS release 3 (Taroon Update 4) > Gcc version 3.2.3 20030502 Perhaps the compiler is at fault here. Thats an old-ish version of GCC. I use 3.3.4. It could also be a buggy GNU libc or libstdc++ if you're on an older RedHat version. -- Caleb Epstein caleb dot epstein at gmail dot com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

2 1

Problem with Comeau 4.3.3 (compilation)
by pisalmon＠numericable.fr 16 Aug '05

16 Aug '05

Hi, I have some problem with boost compilation when I use Comeau 4.3.3 Compiler (with gcc 3.3.5 on Ubuntu Hoary) and bjam tools : The signal librairy cant compile. Do you known why ???

1 0