- Boost - lists.boost.org

Re: [boost] shared_ptr question
by Martin Bonner 22 Jun '05

22 Jun '05

----Original Message---- From: H. van Niekerk [mailto:h.v.niekerk@hccnet.nl] Sent: 20 June 2005 19:22 To: boost(a)lists.boost.org Subject: [boost] shared_ptr question > Hi, > > I'm rather new to shared_ptr and I'm not very experienced in > programmer > with C++ but have to do it anyway. > My problem is this: I have 3 .cpp files, e.g. Master.cpp, Client.cpp > and Satellite.cpp. > > Originally, Master.cpp is the only .cpp file, and uses auto_ptr to > enable writing and reading from an interface. Like this: > > { > .... > auto_ptr<FtInterface> fti (ftGetIfFromFactory(device, > connection)); > fti->getIfInfo(ii); > IfOutputs out; // to set interface outputs (ctor clears > // everything to 0) > IfInputs inp; // to be read from interface > fti->writeAndReadAllData(out, inp); > ... > } > > This works well with every action taking place in this file. Now, as > said I have those 3 .cpp files. Master.cpp sends an argument to > Client.cpp and Client.cpp sends it to Satellite.cpp. Satellite.cpp > reads > from the interface, and sends it back via Client.cpp to Master.cpp. I > can't use auto_ptr with this and from the Boost-documentation I can't > figure out exactly how to use shared_ptr for this. Can somebody please > help me out? > > I hope I explained my problem clear enough. I'm afraid you didn't. Could you write some sample (pseudo-) code just using raw C pointers and not worrying about memory leaks? Then we can probably work out how to rewrite using smart pointers. Incidentally, I don't think the presence of three .cpp files is directly relevent. I suspect that the relevent factor is that you have three *functions*, and your problem is passing the data between them. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

5 12

Broken link to boost/thread/barrier.hpp on www.boost.org
by Peter Simons 22 Jun '05

22 Jun '05

If you follow the link to "barrier.hpp" on the page http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads/ref… ..., then you'll be directed to http://www.boost.org/regression-logs/cs-win32_metacomm/boost/thread/barrier… ..., and that page doesn't exist. Peter

1 0

[mpl][tru64cxx] set still failing
by Joaquín Mª López Muñoz 22 Jun '05

22 Jun '05

Hello again, Despite recent changes by Dave Abrahams, mpl::set is still failing in tru64cxx as shown in the last regression cycle: http://tinyurl.com/9qzuh (Dave's works weren't intended to tackle this issue anyway, so this comes as no surprise.) The reason for the regression lies in recent changes to the associated toolset jam setting strict_ansi mode compilation. The offending code is: BOOST_STATIC_CONSTANT(bool, value = ( sizeof( BOOST_MPL_AUX_OVERLOAD_CALL_IS_MASKED( Set , BOOST_MPL_AUX_STATIC_CAST(aux::type_wrapper<T>*, 0) ) ) == sizeof(aux::no_tag) ) ); and the error message goes like "NULL reference is not allowed". Digging deeper, I'm pretty sure the problem has to do with tru64cxx not accepting selected implementation of BOOST_MPL_AUX_PTR_TO_REF in boost/mpl/aux_/ptr_to_ref.hpp when the pointer passed is null. There are two alternative implementations of this macro: 1. (MSVC, EDG) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ *BOOST_MPL_AUX_STATIC_CAST(X*, 0) \ /**/ 2. (remaining compilers) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ aux::ptr_to_ref(BOOST_MPL_AUX_STATIC_CAST(X*, 0)) \ /**/ tru64cxx, which is EDG-based, uses #1; it used to work OK, but when strict_ansi mode was selected, the compiler didn't like #1 anymore. So my questions are: A. Is there any reason why EDG is forced to use implementation #1? The CVS history doesn't shed much light about this. B. If A is unavoidable, can we macro-detect strict ansi mode so as to divert EDG+strict_ansi to implementation #2? C. If B has negative answer, could we at least eliminate the null pointer in boost/mpl/aux_/ptr_to_ref.hpp (by using a dummy make_ptr function, perhaps)? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[boost.lambda] Function invocation via lambda
by Falcon 22 Jun '05

22 Jun '05

Sorry if this has been asked before (I couldn't find anything, or else I wasn't using the right searches)... How does one create a lambda function that invokes its parameter? For example, for use with std::for_each: std::vector<boost::function0<void> > Methods; std::for_each(Methods.begin(), Methods.end(), *???*) Peregrine Falcon

2 2

boost building question
by H 22 Jun '05

22 Jun '05

Hi, In the Jamfile help it says: --builddir=DIR Build in this location instead of building within the distribution tree. Recomended! Does this mean the build is not the same as the install, i.e. while building, files are being stored somewhere and removed after final installation? Thank you, H.

2 2

[lexical_cast] specializing
by Maxim Yegorushkin 22 Jun '05

22 Jun '05

I'd like to be able to specialize lexical_cast for certain source->target conversions. With its current design I see no possibility to do that as function templates can not be partially specialized. Are the any plans to change that? -- Maxim Yegorushkin

3 6

Re: [boost] Boost::regex match prefix problem
by A. Johan 22 Jun '05

22 Jun '05

Thanks John! Will try the cvs then. Cheers. Alfonso Johan Soft Switch Sdn. Bhd. Kuala Lumpur, Malaysia http://www.softswitch.com.my -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.10/25 - Release Date: 21/06/2005

1 0

[filesystem 1.32.0] bug in name checking for win32 native paths
by Russell Hind 22 Jun '05

22 Jun '05

I have two paths, both set to c:\ and if I concatenate them using operator /, I get a resultant path of c:\c:\ which is invalid, but the namechecking doesn't throw an execption. e.g. void test(void) { boost::filesystem::path p("C:\\", boost::filesystem::native); boost::filesystem::path p2(p); p2 = p2 / p; } p2 results as "c:/c:/" (the internal representation). Cheers Russell

2 1

Boost::regex match prefix problem
by A. Johan 22 Jun '05

22 Jun '05

Hello all, I'm developing an application that uses boost::regex library and ms visual c++ 2003 (7.1). I'm trying to split a string into a smaller set of strings by using regex_split. However I would like to skip if the split character is prefixed by \. Typically I would use the following regex - (?<!\\); Where in c++ it would be something like std::string s("(?<!\\\\);") Compiles ok but I will get an exception when I try to use it as a parameter to the regex - boost::regex(s) So would appreciate any pointers or ideas or am I just doing I plainly wrong? Cheers & have a good day all. A. Johan -- "The roof, the roof, the roof is on fire..." -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.10/25 - Release Date: 21/06/2005

2 1

Re: [boost] Boost.config not recognize threading support enabled?
by BRIDGES Dick 22 Jun '05

22 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On > Behalf Of John Maddock > Sent: Saturday, June 18, 2005 4:31 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Boost.config not recognize threading support enabled? <snip> > If you look at the line that triggers the #error, you will see it is within > a block scoped by: > > #elif !defined(BOOST_HAS_THREADS) > > so the error is triggered by BOOST_HAS_THREADS not being defined. If you > now grep through the boost/config headers you will see: > > In suffix.hpp: > > #if (defined(__MT__) || defined(_MT) || defined(_REENTRANT) \ > || defined(_PTHREADS)) && !defined(BOOST_HAS_THREADS) > # define BOOST_HAS_THREADS > #endif <snip> > To find out which of the above is the cause the easiest way I find is to > through some #errors in the preprocessor branches you think may be taken and > then see if the #error is triggered or not (this is much easier than > preprocessing the code IMO). > > To help you more we probably need: > > The gcc version. [Dick] "/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2.3.2/bin/arm-so ftfloat-linux-gnu-c++" -v Reading specs from /opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2.3.2/lib/gcc-lib /arm-softfloat-linux-gnu/3.3.3/specs Configured with: /data/work/OMAP/crosstool/crosstool-0.28-rc37/build/arm-softfloat-linux- gnu/gcc-3.3.3-glibc-2.3.2/gcc-3.3.3/configure --target=arm-softfloat-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2.3.2 --with-float=soft --with-headers=/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2. 3.2/arm-softfloat-linux-gnu/include --with-local-prefix=/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-gli bc-2.3.2/arm-softfloat-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 3.3.3 __GLIBCPP__ is 20040214 and __GLIBCXX__ is not defined. I 'peppered' the headers with #warningS and determined that: - BOOST_HAS_THREADS is not defined in gcc.hpp because linux, __linux & __linux__ are all defined. - BOOST_STDLIB_CONFIG is defined as "boost/config/stdlib/libstdcpp3.hpp" in select_stdlib_config.hpp. But BOOST_HAS_THREADS is not defined in libstdcpp3.hpp because __GLIBCXX__ is not defined. - BOOST_HAS_PTHREADS is defined in posix_features.hpp after <unistd.h> is included. I had hoped this was a good thing. ;) - Then we get to suffix.hpp. BOOST_HAS_PTHREADS is defined and BOOST_DISABLE_THREADS is !defined. So far, so good. However, because none of _REENTRANT, _PTHREADS, __MT__, and __MT are defined, BOOST_HAS_THREADS is still not defined. Consequently, on the way out, BOOST_HAS_PTHREADS is undef'D. Now that I see how BOOST_HAS_THREADS is not defined, I've moved into the dark nether region of the-land-way-over-my-head. I'm tempted to add BOOST_HAS_PTHREADS to the list of macros tested here: <snippet file=suffix.hpp> // Turn on threading support if the compiler thinks that it's in // multithreaded mode. We put this here because there are only a // limited number of macros that identify this (if there's any missing // from here then add to the appropriate compiler section): </snippet> *BUT*, that little parenthetical admonition strongly suggests this file is not to be modified - ever again. ;) Besides: there must have been a reason for defining BOOST_HAS_PTHREADS without automatically concluding BOOST_HAS_THREADS. Apparently a similar problem was fixed in the past (http://lists.boost.org/MailArchives/boost/msg19675.php) by adding an unconditional define of BOOST_HAS_THREADS to metrowerks.hpp. But that clearly won't work with gcc.hpp. I am sorely in need of guidance. Where should I go from here? > The command line that produced the above error. [Dick] "/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2.3.2/bin/arm-so ftfloat-linux-gnu-c++" -I/usr/local/boost_1_32_0 -pthread test.cpp > The output from the config_info program (cd into libs/config/test then > "bjam -sBUILD="<threading>multi" config_info", then look for output the > program generated somewhere under > boost-path/bin/boost/libs/config/test/config_info/ ...some directories... > /*.output [Dick] Hey, that's a NEAT tool! (Unfortunately the "default" compiler is gcc 3.4 and defines _REENTRANT. %>[ ) I'm going back through the docs now to figure out how to invoke the cross-compiler but hoping the above info might yield and answer. > Hope this gets you further forward. > > John. > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost [Dick] Your help with this is sincerely appreciated. Thank you.

2 1