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

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

Re: [Boost-users] [review] Boost.Fusion
by João Abecasis 16 May '06

16 May '06

Joel de Guzman wrote: > João Abecasis wrote: >> On the directory structure used for the headers, I like the modular >> approach but sometimes get the feeling that it's too fragmented. Having >> more top-level reflections of individual components would ease my >> concerns. Another aspect is that this structure diverges from what is >> used in MPL. Given the parallel between the two libraries I think an >> effort should be made to keep the structure similar. In fact, this is >> also part of the user interface. Still, in the end, I recognize that >> they're two independent libraries and must each follow its path. > > Understood. I'll give this a lot of thinking. At the very least, > we'll surely have a flat set of headers that forward to the > main headers. Where to place them is a matter to deliberate on. > Maybe <boost/fusion/hdr/xxx.hpp> ? or simply <boost/fusion/xxx.hpp> > and push the main tree downwards in another directory, say, "main"? Why do you need to have them in separate directories? Are there conflicting/overlaping headers when you mix the approaches (or are you just trying to keep everything nice and tidy ;-) ) ? >> Fusion is coded with the expectation that the library code will be >> optimized into very tight code, which seems to be a reasonable >> assumption with (any?) modern compilers. > > I hope g++ will catch up! See Dan's post regarding some Fusion > speed tests. g++ produces the fattest and slowest code :( > I wish I was using incorrect flags or I haven't found the > best compiler switches to use for g++. 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. > MS VC8.0 produces the tightest and fastest code, so far. > (No, I'm not a fan of MS. Those are just the facts.) Of course ;-) I like facts! From my limited experience, I've also seen MSVC produce the tightest code. Perhaps there should be a way to extract some benchmarks (e.g., code size, performance) from the Boost regression tests, or separate benchmark-tests for the different compilers could be integrated into the system. This could be interesting and useful information for library developers. >>> - What is your evaluation of the potential usefulness of the library? >> I believe Fusion has great potential as a library building block but >> also as a more application-oriented library. On the library building >> block side, I believe it has the potential to become a fundamental/core >> piece of Boost. For application developers, Fusion takes tuples to a new >> level, allowing one to make the most of information that is available at >> compile-time. I wanted to make an additional suggestion that might make Fusion's usefulness more visible, but it slipped my mind at the last minute. While I'm not that familiar with Boost.Serialization it seems to be a fairly popular library with developers of varying technical level. My suggestion is that Fusion Sequences be made serializable, using Boost.Serialization. This would go in a separate header (e.g., in fusion/sequence/io/serialization.hpp) and have the requirement that serialization be implemented for individual element types. If possible, the serialization would be generic, i.e., tied to the type sequence and not to the particular Fusion Sequence. With serialization in place, Fusion sequences could be used to manage a class's data and its serialization or they could be used as a proxy during serialization: archive & tie(a, b, c); Hmm... I see that the Quick Start mentions serialization as an example. Is there a reason for not offering the interface to Boost.Serialization in the library? Best regards, João

1 0