June 2006 - Boost-users - lists.boost.org

[serialization] - xdr-archives?
by Oliver.Kowalke＠qimonda.com 15 Jun '06

15 Jun '06

Hello, did someone tried to implement XDR-archive? I know that Jack Reeves illustrated an XDRstream implementation on CUJ/C++ forum. Regards, Oliver

1 0

Boost installation OS X 10.3
by Amit Bhatia 15 Jun '06

15 Jun '06

Hi, I did a google search to look for how to install boost library on os X 10.3 after trying the instructions on the boost.org site (and failing). But I have not been able to find anything useful yet. I am using gcc version 3.3 20030304 (Apple Computer, Inc. build 1640). I also use fink package manager for a lot of packages that I need. I have python version 2.3 I believe. Can anyone suggest to me step by step instructions of how to install boost library 1_33_1 ? I have already tried using bjam for the same but the installation terminated with ...failed updating 49 targets... ...skipped 3624 targets... ...updated 691 targets... thanks, -a. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[preprocessor] concatenating values to create typedef permutations
by Chris Weed 15 Jun '06

15 Jun '06

Hi, I am trying to use the preprocessor iteration ability to create typedef permutations. I want to do something like use the following set of types TYPE1: char int float TYPE2: char int float double to generate permutations of MyClass<TYPE1,TYPE2> such as typedef MyClass<char,char> Mycc; typedef MyClass<char,int> Myci; typedef MyClass<char,float> Mycf; ... Any help would be greatly appreciated. Thanks, Chris

3 8

Re: [Boost-users] type_with_alignment
by Gottlob Frege 15 Jun '06

15 Jun '06

> > From: Howard Hinnant <hinnant(a)twcny.rr.com> > >> On Jun 14, 2006, at 6:55 AM, David Abrahams wrote: > >> > >>> I think what the OP is looking for is called boost::shared_ptr ;-) > >> Actually, *one* of my uses is a bit more devious - more like the short-string optimization - you might want to call it "embedded_ptr<T, size>". Where it reserves enough space for T (because you explicitly supply the size) and acts like a pointer to T otherwise. You might call it a hack and/or dangerous, and I won't entirely disagree. It does have a static assert on the implementation side (where T is known) to ensure size == sizeof(T), but it is still dangerous if the client compiles with different settings than the implementation. However, knowing these caveats, it may still be useful in cases where you really want/need to avoid the allocation overhead (and still want to separate implementation from interface). If that use-case is not 'worthy' enough to be an argument for default-alignment-based-on-size, a more typical case would probably be a custom allocator. In particular, a small-block allocator. If I need to allocate 4 bytes, I don't want to allocate it on a 16 byte boundary. Now maybe if I am writing an allocator am doing platform-dependent things anyhow, but I don't necessarily think so. Another use of aligned_storage (where T IS complete) is a more noble cause - handling thread safe static locals: void func() { static thread_safe_static_local<Foo> foo; // foo's constructor called once, THREADSAFELY ... } Not sure why I bother to mention that, other than the fact it shares much of the same code as the embedded_ptr. P.S. even if some of you have to hold your nose when thinking of the hack that is embedded_ptr, what do people think of the name? I've been throwing around some different names (ie embedded_incomplete) but until Dave mentioned shared_ptr, I hadn't thought of embedded_ptr. >> shared_ptr can't compete with this application performance-wise. > > > > Well, it depends how expensive it is to copy your small object. If it > > turns out that T is a vector, and it fits in your local buffer, when > > Container is copied it might be a lot cheaper to use shared_ptr. > > Sure. I'm responding to the assertion that you need a known complete > type to effectively use aligned_storage. My point is that there > exist valuable use cases where this assertion is false. The > existence of these cases is what makes the defaulted alignment > template parameter on aligned_storage valuable. > > Tony's observation is that this default value is even more valuable > if it is dependent upon the buffer size, which again I fully agree > with. If you want a 5 byte buffer that is aligned to the "most > stringent alignment requirements" (definition found in 5.3.4p10), an > alignment of 16 (for example) is likely to be correct but overkill. > I had personally settled on 8 for this particular example but Tony > makes a convincing argument for 4 being the optimum (all numbers > assuming current popular desktop processors and quoted just for > example). Actually, after thinking about it a bit, I'm now tempted to say a 5 byte buffer should have 1 byte alignment. eg (given a typical platform): struct test_alignment { int x; char y; }; At first, I thought that any 5 byte structure could have AT MOST a 4 byte alignment requirement because it could have an int as the first param, as in the example above. However, if it does have 4 byte alignment, its size will be 8, so that an array of them will align to 4 bytes. (Howard, you hinted at this in another email thread). So, If sizeof(test_alignment) == 5, then the alignment must really be 1 (ie there is probably a pragma pack(1) in play). Either way, the alignment is NOT 16 (or whatever max alignment might be), but derivable from the size of the structure. Also, in any case, for boost::type_with_alignment<5> doesn't compile. I think it should at least do something (or else the standard/docs need to have lots of wording explaining which ints work and which do not). Similarly, aligned_storage has the same 'problem' and basically only works with alignment_of (or something that does the same thing). Since that is the case anyhow, I would suggest that aligned_storage be replaced with: storage_for<T, count = 1>; (which can be written in terms of aligned_storage and alignment_of, but since the two are tied together, and typically used together, why not just supply what is really wanted). So really I'd like: storage_for_type<T, size_t count = 1> and storage_for_size<size_t> where storage_for_size determines the minimum necessary alignment based on the size, as discussed. -Howard Tony

2 1

finding the index of a partial match with regex_iterator?
by dave＠superelite.net 14 Jun '06

14 Jun '06

hello (and thanks for previous help!), I'm having some difficulty accessing the location of the beginning of a successful partial match. in the callback below, match_results.position() does give me the index of successful matches. How do i get it for partial? The code does recognize a partial match but what[0].first seems to be undefined on a partial match. The callback is called 3 times and does identify the partial but have been totally unable to get that index..Code is below, thanks alot! Dave bool regex_callback(const boost::match_results<std::string::const_iterator>& what) { cout << "in callback, index is " << what.position(0) << endl; if(!what[0].matched) cout << "|--is partial " << endl; return true; } int main(int argc, char *argv[]) { string sMatchMe = "HELLO"; int theseflags=0; boost::regex xreMatchme(sMatchMe, theseflags); boost::cmatch xcmMatch; string stupid = "sdfaHELLOdsfh*saHELLOdhfas1d3ahsdf%as&d!adfasdfsdHELL"; boost::sregex_iterator m1(stupid.begin(), stupid.end(), xreMatchme, boost::match_default | boost::match_partial); boost::sregex_iterator m2; std::for_each(m1, m2, &regex_callback); return 1; }

1 0

compiling boost shmem-0.93 on winxp with mingw-3.4.2
by christopher taylor 14 Jun '06

14 Jun '06

To the Boost-User community, I'm not sure if this is the right forum for this type of question so I'll probably take heat for posting this problem here...in any case, I've been having some build errors working with boost shmem-0.93 on winxp using mingw-3.4.2. Documentation states that shmem should compile on this platform but, I've discovered an interesting error with char_traits. In all shmem streams, I have problems with the type referencing of post_type - I'm getting this error: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' Below is the gcc output of my build error. Any help with this is greatly appreciated! Chris Taylor gcc ../../test/bufferstream_test.cpp -I/C/MinGW/include/boost-1_33_1 -L/C/MinGW/ libs -Wall -L-I/C/MinGW/include -L/C/MinGW/libs -lboost_thread-gcc-mt -I../../. ./.. -lstdc++ -o ../../bin/mingw/test_bufferstream_test.out c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/streambuf: I n instantiation of `std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >': ../../../../boost/shmem/streams/bufferstream.hpp:56: instantiated from `boost: :shmem::basic_bufferbuf<wchar_t, std::char_traits<wchar_t> >' ../../test/bufferstream_test.cpp:9: instantiated from here c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/streambuf:13 5: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/streambuf:23 4: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/streambuf:23 9: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/streambuf:57 4: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/streambuf:58 6: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' ../../../../boost/shmem/streams/bufferstream.hpp: In instantiation of `boost::sh mem::basic_bufferbuf<wchar_t, std::char_traits<wchar_t> >': ../../test/bufferstream_test.cpp:9: instantiated from here ../../../../boost/shmem/streams/bufferstream.hpp:60: error: no type named `pos_t ype' in `struct std::char_traits<wchar_t>' ../../../../boost/shmem/streams/bufferstream.hpp:236: error: no type named `pos_ type' in `struct std::char_traits<wchar_t>' ../../../../boost/shmem/streams/bufferstream.hpp:301: error: no type named `pos_ type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_i os.h: In instantiation of `std::basic_ios<wchar_t, std::char_traits<wchar_t> >': c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/istream:60: instantiated from `std::basic_istream<wchar_t, std::char_traits<wchar_t> >' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/istream:706: instantiated from `std::basic_iostream<wchar_t, std::char_traits<wchar_t> >' ../../../../boost/shmem/streams/bufferstream.hpp:443: instantiated from `boost ::shmem::basic_bufferstream<wchar_t, std::char_traits<wchar_t> >' ../../test/bufferstream_test.cpp:11: instantiated from here c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_i os.h:67: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/istream: In instantiation of `std::basic_istream<wchar_t, std::char_traits<wchar_t> >': c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/istream:706: instantiated from `std::basic_iostream<wchar_t, std::char_traits<wchar_t> >' ../../../../boost/shmem/streams/bufferstream.hpp:443: instantiated from `boost ::shmem::basic_bufferstream<wchar_t, std::char_traits<wchar_t> >' ../../test/bufferstream_test.cpp:11: instantiated from here c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/istream:65: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/istream .tcc:847: error: no type named `pos_type' in `class std::basic_istream<wchar_t, std::char_traits<wchar_t> >' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/istream .tcc:865: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ostream: In instantiation of `std::basic_ostream<wchar_t, std::char_traits<wchar_t> >': c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/istream:706: instantiated from `std::basic_iostream<wchar_t, std::char_traits<wchar_t> >' ../../../../boost/shmem/streams/bufferstream.hpp:443: instantiated from `boost ::shmem::basic_bufferstream<wchar_t, std::char_traits<wchar_t> >' ../../test/bufferstream_test.cpp:11: instantiated from here c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ostream:64: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/ostream .tcc:404: error: no type named `pos_type' in `class std::basic_ostream<wchar_t, std::char_traits<wchar_t> >' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/ostream .tcc:420: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/istream: In instantiation of `std::basic_iostream<wchar_t, std::char_traits<wchar_t> >': ../../../../boost/shmem/streams/bufferstream.hpp:443: instantiated from `boost ::shmem::basic_bufferstream<wchar_t, std::char_traits<wchar_t> >' ../../test/bufferstream_test.cpp:11: instantiated from here c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/istream:713: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' ../../../../boost/shmem/streams/bufferstream.hpp: In instantiation of `boost::sh mem::basic_bufferstream<wchar_t, std::char_traits<wchar_t> >': ../../test/bufferstream_test.cpp:11: instantiated from here ../../../../boost/shmem/streams/bufferstream.hpp:448: error: no type named `pos_ type' in `class std::basic_ios<wchar_t, std::char_traits<wchar_t> >' ../../../../boost/shmem/streams/bufferstream.hpp: In instantiation of `boost::sh mem::basic_ibufferstream<wchar_t, std::char_traits<wchar_t> >': ../../test/bufferstream_test.cpp:13: instantiated from here ../../../../boost/shmem/streams/bufferstream.hpp:342: error: no type named `pos_ type' in `class std::basic_ios<wchar_t, std::char_traits<wchar_t> >' ../../../../boost/shmem/streams/bufferstream.hpp: In instantiation of `boost::sh mem::basic_obufferstream<wchar_t, std::char_traits<wchar_t> >': ../../test/bufferstream_test.cpp:15: instantiated from here ../../../../boost/shmem/streams/bufferstream.hpp:394: error: no type named `pos_ type' in `class std::basic_ios<wchar_t, std::char_traits<wchar_t> >' make: *** [../../bin/mingw/test_bufferstream_test.out] Error 1

3 3

Mingw 3.4.2 char_traits.hpp patch fixes shmem-0.93 build for winxp
by christopher taylor 14 Jun '06

14 Jun '06

to interested parties: i did some additional searching today and managed to find out that there is a bug in mingw's c++ include directory. to get shmem compiled for winxp using mingw, go into your equivalent to "/C/MinGW/include/c++/3.4.2/bits" open "char_traits.hpp" and comment out lines 309 and 311. The area, after commenting, should look like this: 309: //#if defined (_GLIBCXX_USE_WCHAR_T) 310: typedef wstreampos pos_type; 311: typedef mbstate_t state_type; 312: //#endif the define statement conflicts with a similar define statement that takes places at the begining of this template type's definition. after completing this simple patch, run the build script for mingw in the shmem 0.93 and try out the test programs, they should work at this point. the semi-notorious, "fixes error: no type named `pos_type' in `struct std::char_traits<wchar_t>'" error is gone. thanks to those parties that were looking into this issue and i hope this proves helpful for someone out there. chris taylor

2 1

[numeric] fit to numeric PODs
by alefor＠gmx.de 14 Jun '06

14 Jun '06

Hi, I'm parsing with Spirit strings of numeric values and want to guess the right POD that can fit all of them. For example, I see at glance sets with only 0.0 and 1.0, that can be optimized to a adjacent group of bool: 1. Or some doubles, in another set, which value ranges and resolution like shorts. Or if something like "0.000000000000000000000001" will fit exactly in my floats. I'm reading boost/lexical_cast , numeric/conversion and interval docs, but still don't found a way to convert strings to POD knowing if that cast is exact or not. Range check is there, but don't find a test telling me if that cast was exact. The 'exact' term here is what boost::numeric doc definitions chapter means. Thanks, alef -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: [Boost-users] Boost.Thread locking across two functions
by Moshe Matitya 14 Jun '06

14 Jun '06

On Fri, 09 Jun 2006 22:51:48 -0300, Peteris Krumins [Newsgroups] <pknewsgroups_at_[hidden]> wrote: > > Hello! > > I am using a library which itself internally does not use any thread > sync mechanisms but it provides callback functions > lib_lock() and lib_unlock() which I can specify if the lib is used in > multithread environment. > lib_lock() would get called before critical segment and after it > lib_unlock() would get called. > > I read Boost.Thread documentation and I understand that lock concept is > not thread-safe itself and should be used only at block scope. > This makes me think that I have no way to use locking provided by Boost > to acquire a lock in > lib_lock() function and release it in lib_unlock()? But I am not sure. > > Do you have any suggestions if this can be done using Boost? > > Thanks! > P.Krumins I don't think it was intended to be used this way, but you can accomplish what you want with the lock_ops<> class: mutex m; lib_lock() { boost::detail::thread::lock_ops<boost::mutex>::lock (m); } lib_unlock() { boost::detail::thread::lock_ops<boost::mutex>::unlock (m); } Moshe

1 0

Re: [Boost-users] type_with_alignment
by Gottlob Frege 14 Jun '06

14 Jun '06

> > Date: Tue, 13 Jun 2006 19:28:07 +0100 > From: "John Maddock" <john(a)johnmaddock.co.uk> > > What's wrong with: > > boost::alignment_of<unknown_struct>::value ? > > You can feed the result into type_with_alignment<> if that's what you want > as well. > > John. if unknown_struct is an incomplete type (which is what I meant, and should have said), alignment_of doesn't compile. Tony

4 5