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

How to link (properly)
by Jason House 17 May '06

17 May '06

When I run bjam install on my laptop running Mandriva 2006, it places a lot of files in /usr/local/lib with names like libboost_XXX-gcc.a While I know that I can pass -lboost_XXX-gcc and it links, the -gcc bit seems to make things a bit too platform dependent for my liking. What's the proper way to handle that extra bit at the end of the library name? The project I'm working on uses autoconf/configure/make as its build environment.

2 2

Regex Localization problem
by Antonio Scotti 17 May '06

17 May '06

Hi, I have a portability problem with regex (probably due to localization issues). I've found that, under Win32, the regular expression "\w" matches all the alphanumeric chars, including non ascii ones (such as e grave or e acute). This doesn't hold while under linux. In fact, \w only seems to match ascii characters. I've tried chancing the locale, but nothing changed. Is there a way to make \w have on linux the same behaviour it has on win32? Thanks in advance.

2 2

newbie boost::random how can I get a variate_generator for uniform_01 distribution?
by wave style 17 May '06

17 May '06

Hi, I have some strange behavior on win XP with VC 8.0 version and boost::random library. When I use variate_generator helper template with uniform_01 distribution, I always get an compiler error. like as: //code boost::mt19937 rng(time(0)); boost::uniform_01<mt19937> u01(rng); boost::variate_generator<mt19937, uniform_01<mt19937> > die401(rng, u01); //compile info error C2039: 'input_type' : is not a member of 'boost::uniform_01<UniformRandomNumberGenerator>' with [ UniformRandomNumberGenerator=boost::mt19937 ] f:\my documents\visual studio 2005\projects\testboost\testrandom\testrandom.cpp(169) : see reference to class template instantiation 'boost::variate_generator<Engine,Distribution>' being compiled with [ Engine=boost::mt19937, Distribution=boost::uniform_01<boost::mt19937> ] Actually, the uniform_01 class doesn't declare a type named input_type in uniform_01.hpp, because uniform_01 distribution can accept both IntegerType and RealType UniformRandomGenerator. It seems that variate_generator can not support the uniform_01. However, I found the engine_helper struct be specialized for uniform_01 and uniform_int_float in variate_generator.hpp. I got confused. It's vc8.0compiler's bug? How can I get a variate_generator for uniform_01 distribution? Any feedback welcomed!! Thanks. Waveform.

1 0

[boost-build] telling one project to depend on another
by Brian Budge 17 May '06

17 May '06

Hi all - I'm trying out boost-build for the first time, and running into some issues related to project dependencies. I've spent many hours looking at boost-build documentation, and now I'm stuck. My directory structure is laid out like this: -------------------------------------------- base_dir Jamroot simp_envelopes Jamfile ***source*** simp_envelopes ***include files*** my_lib Jamfile ***source*** include ***include files*** test Jamfile tester.cc --------------------------------------------- Basically, my_lib depends on simp_envelopes and test depends on my_lib. In simp_envelopes/Jamfile I have this: ------------ project simplify-libs : usage-requirements <include>simp_envelopes ; lib simplify : [ glob *.cc ] : <include>simp_envelopes ; ------------ which I believe should tell my_libs to include simp_envelopes/simp_envelopes, if only my_libs can know that it should depend on the simp_envelopes project. My Jamroot looks like: ------------ use-project simplify-libs : simp_envelopes ; use-project my-libs : my_libs ; project my_app : requirements <include>.. <include>../SGUL/include : default-build debug ; lib open-mesh : : <file>../OpenMesh/Core/Linux_gcc_max/libOpenMesh_Core.so ; build-project simp_envelopes ; build-project my_libs ; build-project test ; ------------ My my_libs Jamfile: ------------ project my_libs : requirements <include>../simp_envelopes : usage-requirements <include>include ; lib my_libs : [ glob *.cc ] /simplify-libs//simplify : <include>include ; ------------- I had to add the requirements <include>../simp_envelopes for my_libs to find the include files for simp_envelopes... is there a way to get my_libs to depend on simp_envelopes (or simplify-libs) and take care of this automatically? I have similar issues for the test app... I need to at a requirements for the my_libs include directory. Finally, I have defined a library name open-mesh to point to my external library, but I don't know how to have my my_libs essentially require linking against open-mesh. This is in fact even more important because I don't currently have a way of making my application build rule depend on open-mesh. Any help is appreciated! Brian

2 1

[Thread] Get current thread id
by marie-line.gentil2 17 May '06

17 May '06

Is there a boost method which does it? I went through the whole thread documention but could not figure out how to do so.

5 4

assert.h
by dvir schirman 16 May '06

16 May '06

Hi I try to use the random library in order to create a noise signal with normal distribution. I'm using Cygwin platform, and I'm using g++ compiler. I wrote: #include <boost/random.hpp> at the beginning of my header file. and when I tried to compile I got the following error message: In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cassert:48, from ../boost/boost/random/linear_congruential.hpp:20, from ../boost/boost/random.hpp:36, from actor.H:12, from tdagent.H:11, from main.C:1: /usr/include/assert.h:6: error: expected unqualified-id before string constant /usr/include/assert.h:6: error: expected `,' or `;' before string constant main.C, tdagent.H, actor.H are files that I've written. I am not familiar with assert.h, I guess it's part of the c++ headers, and that there shouldn't be an error in it. Hope someone can help me solve it. Dvir.

1 0

Re: [Boost-users] newbie - boost::shared_ptr of type stringstream using << operator?
by james.jones＠firstinvestors.com 16 May '06

16 May '06

From: Ed Johnson <ed(a)edwardotis.com> > Hi Eric, > > I tried and none of the following modes worked. > >boost::shared_ptr< std::stringstream > sharedStream(new >std::stringstream("hello world", std::stringstream::out | >std::stringstream::ate )); [other examples snipped] Ed, I think you should prove this isn't a boost::shared_ptr issue first. Have you tried it with a raw pointer? I suspect you'll get the exact same results as with boost::shared_ptr, which would indicate a problem with your implementation of std::stringstream, not with boost::shared_ptr. Your prior example was this: > std::stringstream tr; > tr << "hello everyone"; > tr << "!"; > std::cerr << tr.str() << std::endl; But this is a different call pattern, not just a change from an object to a smart pointer. This probably works fine: boost::shared_ptr<std::stringstream> tr(new std::stringstream()); (*tr) << "hello, world"; (*tr) << "!"; std::cerr << tr->str() << std::endl; And this probably doesn't work: std::stringstream tr("hello, world", std::stringstream::out | std::stringstream::ate); tr << "!"; std::cerr << tr.str() << std::endl; If I'm right in both cases, your problem is with std::stringstream, not with boost::shared_ptr. Regards, - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

1 0

Re: [Boost-users] [review] Boost.Fusion
by David Abrahams 16 May '06

16 May '06

Joel de Guzman <joel(a)boost-consulting.com> writes: >> It will catch up :-) On a side note, it seems the tests were run with >> gcc 3.4. IIRC, gcc 4 and beyond introduced a couple of interesting >> optimizations so I wonder how far do those go towards narrowing the gap. > > I would love to see better numbers for g++. Building a later G++ under cygwin is pretty easy if you know what to do. That's how I stay abreast of G++ developments. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

boost::shared_ptr typedef drives me crazy
by Ovanes Markarian 16 May '06

16 May '06

I have some strange behavior on RH Enterprise Linux 2.6.9-34 with gcc (GCC) 3.2.3 version and boost::shared_ptr template. The thning which drives me crazy compiles for one library without any problems and for the other library it can't compile one of my typedefs. Maybe some of you have had the similar problem before. Here some snippet: I have some really simple type traits definitions: template <class T> struct traits_internal { typedef T type; typedef T& ref; typedef T* ptr; typedef const T* const_ptr; typedef const T& const_ref; typedef const T const_type; }; template <class T> struct traits : traits_internal<T> {}; template <class T> struct traits<T*> : traits_internal<T> {}; template <class T> struct traits<T&> : traits_internal<T> {}; then I have a factory class, which can creates an empty class instance, copies the instance from another instance or copies it from the underlying POD (raw data). template<class Type_, class Raw_, class MemMan_> struct Creator { public: typedef typename msg_factory::traits<Type_>::type val_type; typedef typename msg_factory::traits<Type_ >::const_type const_type; typedef typename msg_factory::traits<Raw_>::type raw_type; typedef typename msg_factory::traits<MemMan_>::type man_type; typedef boost::shared_ptr<val_type> smart_ptr; typedef boost::shared_ptr<const_type> const_smart_ptr; private: /** * a union container which decides which member to use, POD or Class * used to save space required by 2 pointers */ typedef msg_factory::PointerContainer<val_type, raw_type> ptr_container; typedef Creator<Type_, Raw_, MemMan_> my_type; public: inline explicit Creator(man_type* m = NULL) : memMan(m), copy_from(static_cast<val_type*>(NULL)){} inline explicit Creator(const raw_type* s, man_type* m = NULL) : memMan(m), copy_from(s) {} inline explicit Creator(const val_type& t, man_type* m = NULL) : memMan(m), copy_from(&t) {} inline ~Creator(){} inline operator smart_ptr()const { return smart_ptr((copy_from.is_valid()?(copy_from.first()?(new val_type(*copy_from.first(), memMan)):(new val_type(copy_from.second(), memMan))):(new val_type(memMan)))); } private: inline Creator(const my_type&) {} inline my_type& operator=(const my_type&) {return *this;} template <class OtherType_, class OtherRaw_, class OtherMemMan_> inline Creator(const Creator<OtherType_, OtherRaw_, OtherMemMan_>&) {} template <class OtherType_, class OtherRaw_, class OtherMemMan_> inline Creator& operator =(const Creator<OtherType_, OtherRaw_, OtherMemMan_>&) {return *this;} man_type* memMan; ptr_container copy_from; }; class ClassB : public ClassA { public: typedef Creator<ClassB, POD_B, ClassA> heap_instance; typedef heap_instance::smart_ptr smart_ptr; -->typedef heap_instance::const_smart_ptr const_smart_ptr; private: friend class Creator<ClassB, POD_B, ClassA>; explicit ClassB(ClassA *pcDataManager = NULL); explicit ClassB(const POD_B *ptCopyFromPOD, ClassA *pcDataManager = NULL); explicit ClassB(const ClassB &copyFromOtherClassB, ClassA *pcDataManager = NULL); //some class data follows } In this line compiler raises the error: ISO C++ forbids declaration of `const_smart_ptr' with no type /some/path/here/fname:lineno: cannot declare member ` Creator<ClassB, POD_B, ClassA>::const_smart_ptr' within `ClassB' /some/path/here/fname:lineno: syntax error before `;' token *** Error code 1 Somehow it does not know the type, even if I try in Creator to change the typedef from: typedef boost::shared_ptr<const_type> const_smart_ptr; to typedef boost::shared_ptr<val_type> const_smart_ptr; I still get an error at this line. And the most weired thing is, why it can compile a line before?! Where typedef boost::shared_ptr<val_type> smart_ptr; is used as forward declaration? I also tried in the Creator to change typedef boost::shared_ptr<const_type> const_smart_ptr; to typedef smart_ptr const_smart_ptr; And compiler was able to compile it... Do you have any suggestions? I am using boost 1.33_0 Many thanks, Ovanes Markarian

1 1

Re: [Boost-users] newbie - boost::shared_ptr of type stringstreamusing << operator?
by Andrew McDonald 16 May '06

16 May '06

The stringstream (or ostringstream) stringstream ss("Hello", ios_base::out); will create a stringstream with the output sequence initialised to "Hello" and the position set to the _beginning_ of the sequence. Thus any insertions will overwrite the value from the initialiser string. There were various issues and debates after the 1998 standard came out [Issues 432 and Issue 45 (closed)]..and it is a little unclear to me what the resolution was...but I _think_ the following is correct... - The standard does not mandate that ostringstream (more precisely the underlying stringbuf) supports ios_base::ate. - However, many implementations do support it. As an arbitrary test, compiling with Visual Express 2005 and using ios_base::ate, I find that this does move the position to the end of the sequence. Note that stringstreams must support explicitly seeking to the end of the sequence; e.g. ostringstream oss("Hello"); oss.seekp(o, ios_base::end); oss << " world"; regards, Andrew McDonald System Architect Norwood Systems Australia Pty Ltd Level 1, 71 Troy Terrace PO Box 1281 Subiaco, WA 6904 Tel +61 8 9380 7766 Fax +61 8 9380 7733 andrew.mcdonald(a)norwoodsystems.com The information in this email, and any attachments, may contain confidential information and is intended solely for the attention and use of the named addressee (s). It must not be disclosed to any person(s) without authorization. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to, and must not, disclose, copy, distribute, or retain this message or any part of it. If you have received this communication in error, please notify the sender immediately.

1 0