February 2010 - Boost - lists.preview.boost.org

Interest in Remote Procedure Call Library?
by Daniel Larimer 13 Feb '10

13 Feb '10

I have been playing with some code and recently developed a very efficient, extensible, and easy to use API for performing remote procedure calls (with multiple protocols). I am writing to gauge interest and get feedback on the user API. The native "protocol" is a custom combined tcp/udp protocol using multi-cast for discovery, but it would be very easy to add a shared memory solution, a dbus, XML/RPC, CORBA, etc back end to the user api. Example: class SomeClass { public: int add( int a, int b ) { return a + b ); void sub( int a, int b, int* result ) { if(result) *result = a -b; }; void inout( int& a ) { a += 5; } }; META_INTERFACE( SomeClass, METHOD(add) METHOD(sub) METHOD(inout) ) // server SomeClass myclass; Server myserver( &myclass, "my.named.service" ); // client RemoteInterface<SomeClass> ri( "my.named.service" ); int result = ri.add(1,4); assert( result == 5 ) ri.sub( 5, 1, &result ); assert( result == 4 ); ri.inout(result); assert( result == 9 ); API can support any type that is serializable. It also supports the signal/slot paradigm. SomeClass could have any number of base-classes both virtual and non-virtual. With respect to performance, it can perform 15,000+ synchronous (invoke, wait for return) operations per-second on localhost/linux. Asynchronous operations are capable of 500,000+ invokes/sec. The library doubles as a built-in reflection system allowing run time inspection member functions, parameter types, inheritance, etc. I am working to convince my employer (small company of 25) that contributing this library would bring more benefits than "costs" to the company. The reasons I think it is a good idea include: 1) Expose the company to more people (marketing) 2) We can give our customers an "open" API for communicating with our products 2) Offload some of the development / maintenance / support to the open source community 3) I like open source and have personal reasons for wanting it free and open. So I need to get some more support to convince my employer that this will be a good move. Active interest would be a good sign. Other ideas on the positive aspects of contributing vs keeping it internal would also help me make my case. Thanks, Dan

7 33

WARNING: BoostBook build change..
by Rene Rivera 13 Feb '10

13 Feb '10

In response to the whole, using Boost logo outside of real Boost Libraries, I changed the BoostBook XSL slightly to: * Default to not including a navbar. * Default to not including the Boost logo in the navbar, when one expressly asks to include the navbar. I changed the Boost Jamroot to include the two options one needs to get back the standard Boost navbar+logo: <xsl:param>nav.layout=horizontal <xsl:param>boost.image=Boost The "boost.image" param is new and lets one specify: none (for no logo image), Boost (for the boost.png image), or anything else (for your own custom image. So.. WARNING: You may have to change your doc builds if you previously assumed that the navbar or logo would show up outside of Boost to include the above options (or some version thereof). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

bcp utility documentation
by Jeroen Habraken 13 Feb '10

13 Feb '10

Hi, I just noticed that http://www.boost.org/doc/libs/1_42_0/tools/bcp/bcp.html which is linked to from the main boost.org page under documentation leads to a 404. The page used to exist as http://www.boost.org/doc/libs/1_41_0/tools/bcp/bcp.html. Regards, Jeroen Habraken

2 2

[property_tree] Proposal for Boost.Property_Tree put function
by Andrew Hundt 12 Feb '10

12 Feb '10

I have been using the boost::property_tree in one of our products, and have become frustrated by an inconsistency between two of the convenience functions. The basic_ptree get function allows the specification of a separate delimiter when specifying the path, such as: pt.get<float>('/', "p.a.t.h/t.o/v.a.l.u.e"); However, there is no similar way to call put to place the same value as follows: pt.put('/', "p.a.t.h/t.o/v.a.l.u.e", 3.14f); I would like propose the addition of functions to allow consistency between the use of get and put functions. The basic use of these functions is described in http://www.boost.org/doc/libs/1_42_0/doc/html/boost_propertytree/accessing.… Are there any thoughts or comments? Regards, Andrew Hundt

1 0

[1.3.9][hpux]:pthread_create syambol does not exist in boost.1.3.9 library
by gopal haldar 12 Feb '10

12 Feb '10

Hi I built both boost.1.3.2 and boost 1.3.9 in the hpux 11.23 system. I can see the pthread_create symbol in boost 1.3.2 library but not in boost1.3.9 thread library. Due to this issue, my application crashing hpux 11.11 with boost 1.3.9 system and showing message "pthead_create symbol not found" in the boost thread library but working fine with 1.3.2. Please let me know the solution. Regards Gopal

2 1

[transact] code in sandbox
by strasser＠uni-bremen.de 11 Feb '10

11 Feb '10

Hi, I haven't had much time lately, and that's not going to change to next couple of weeks, so I've uploaded what I have so far to the sandbox: https://svn.boost.org/svn/boost/sandbox/transaction/boost/transact/ what's new: *** basic_transaction_manager: - now supports all kinds of combinations of commits, like we've discussed, including one-phase/transient two-phase, persistent two-phase. no logging/recovery yet. - lazy and non-lazy transaction construction, user-configurable *** simple_transaction_manager: a transaction manager supporting only one resource. basic_tranaction_manager includes a lot of MPL/fusion and the logging infrastrucure, none of which is needed for only one resource. this is intended to be the default transaction manager when one of our libraries is used on its own. *** logging infrastructure: to be used by basic_transaction_manager for its distributed transaction log, and optionally by resource managers that need logging (so it is part of the public interface!) - olog_files: maintaining log files without knowing its contents, manual log rolling - otransaction_log_files: same as olog_files, but automatic log rolling based on transactions - olog: writes to olog_files, aware of log entries - olog_buffer: same interface as olog, but buffers log entries locally and only accesses the log when the internal buffer overflows. - TODO: ilog_files/ilog to read/recover from logs. code is there, but not migrated to "transact". - TODO: interleaved_ologs/..., providing multiple olog interfaces so different resource managers can share a log, as we've discussed. *** new syntax for transaction scopes: syntax changed from: atomic{ ... }retry; to do atomic{ }commit(); I prefer that syntax because it resembles the do{}while(...) syntax. downside is that it conflicts with transaction::commit() if the user chooses to define BOOST_TRANSACT_COMMIT to "commit" (as is done above). *** TODO object_access not migrated to "transact" yet. utility functions for resource managers to serialize/clone/compare/... objects. regards, Stefan

2 4

Re: [boost] Iterator facade example could use some changes/documentation adjustments
by Jacob McIntosh 11 Feb '10

11 Feb '10

> From: Jeffrey Hellrung <jhellrung(a)ucla.edu> > To: boost(a)lists.boost.org > Subject: Re: [boost] Iterator facade example could use some > changes/documentation adjustments > > I think this is a valid concern, though I'm guessing this would cause > problems at most infrequently. I'm having difficulty coming up with a > use case where this would be a problem. Did you stumble upon this while > writing "real" code? It just came to mind while I was writing some of my own iterators. I wasn't even using iterator facade to do it, as I ended up using raw pointers for iterators in my use case, but I started looking at the documentation for is_convertible to figure out why they chose that conversion, and noticed the other behavior. And, though I personally haven't used that in real code, I could imagine a developer having the bright idea of converting a derived iterator into a base one thinking it will _only_ remove his need to explicitly cast the value provided by the derived iterator for whatever purpose. But, even disregarding that, on a more basic level... using is_convertible to allow conversion from non-const to const iterators is really doing more than just that. It's letting you do a host of other things as well... and though my example involved derived classes, The same would happen in cases like converting an integer iterator into a double iterator, as is_convertible returns true in that case as well. Any time the size of the types is different, it could cause problems. This is arguably a very stupid usage of iterators, but if we can enforce proper usage via compile time errors rather than runtime errors... why not? > > Would this motivate the existence of an is_iterator_convertible > metafunction, which is identical to is_convertible except for pointers? > > - Jeff > I'm not sure what there is to gain from this, would have to see what functionality is_iterator_convertible would provide. IMO, it doesn't make a whole lot of sense to convert an iterator<A> to iterator<B> unless A == const B. Converting a const iterator to non-const iterator wouldn't enforce the access of the const iterator, and doing so in a copy constructor removes the need to const_cast for clarity. And converting an iterator<derived> to iterator<base>... or iterator<int> to iterator<double> doesn't seem to make much sense, to me. - Jacob

1 0

Iterator facade example could use some changes/documentation adjustments
by Jacob McIntosh 10 Feb '10

10 Feb '10

My example here: http://codepad.org/pH3pXAvb As mentioned in the comment block at the codepad page: http://www.boost.org/doc/libs/1_41_0/libs/iterator/doc/iterator_facade.html… The above link demonstrates in a linked-list scenario, using is_convertible to handle the conversion from non-const iterators to const iterators. This works fine in the example's linked list scenario, but it's likely than many users of iterator_facade will more generally copy this usage to their own container, from the example. However, as my example demonstrates, in the case where the data lives in contiguous memory locations, or perhaps other scenarios, using is_convertible is very bad for this purpose. It lets you convert from a derived class pointer to a base class pointer, and this is problematic if sizeof(base) is less than sizeof(derived) See the below, very minimal example to illustrate my point. Look at CFixedTest for my proposed replacement for is_convertible to prevent this undesirable behavior. Seems to me that noting such behavior, or simply changing the example code to not allow the conversion (as my example does), would remedy the misunderstanding/problem. Just thought I'd contribute that - thanks, nacitar

2 1

[iterator] Interest in abstract iterator?
by Andrey Semashev 09 Feb '10

09 Feb '10

Hi, Quite a few times I needed a type-erased iterator, that is somewhat similar to boost::function and boost::any with regard to functors and other objects. I've crafted a simple abstract_iterator that is capable to adopt other iterators. Main features are: * A quite small and simple implementation. * Small objects optimization. By default, adopting iterators with size of a pointer or smaller will not result in dynamic memory allocation. * The abstract_iterator is capable to adopt other abstract_iterators of the same or more relaxed iterator category without increasing the adoption level. * Most operations on the iterator introduce a virtual function call overhead. Operations involving two iterators also require a dynamic_cast. The code is in the Vault: http://tinyurl.com/yhxbkl3 Tested on MSVC 9. Is there any interest?

4 4

[1.3.9][thread]:nm: libboost_thread-gcc40-mt-1_39.sl: no symbols
by gopal haldar 09 Feb '10

09 Feb '10

Hi I have built the boost thread library locally in hpux 11.23 system. But when I try to check the symbol in the library using nm it displays the following message. nm: libboost_thread-gcc40-mt-1_39.sl: no symbols. Please let me know how to check the symbols in boost library. Regards Gopal

3 2

[rfc] sized_array
by Tim Blechmann 09 Feb '10

09 Feb '10

hi all, i have a small class, something between std::vector and boost::array. if others find it useful, i could submit it as an extension to the boost.array libray. it basically implements a dynamically sized array, similar to boost::array, but its size can be defined at run-time, rather than compile-time. in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. it can basically be used like boost::array, the only difference is its constructor, which takes either an integer size or a container. boost::array<float, 5> ba; sized_array<float> sa(5); // initialize to size 5 assert(sa.size() == ba.size()); // container size ba.assign(pi); sa.assign(pi); // assignment sized_array<float> sa2(ba); // construct from container the code is available at [1], would be interested to hear, if other people find it useful .. thanks, tim [1] http://tim.klingt.org/git?p=nova-server.git;a=blob;f=source/utilities/sized… -- tim(a)klingt.org http://tim.klingt.org Art is either a complaint or do something else John Cage quoting Jasper Johns

7 10

[website] Move guidelines and developer documentation to Trac?
by Daniel James 09 Feb '10

09 Feb '10

Hello all, The guidelines and developer documentation on the boost site are getting a bit old, and no one's really updating them. Meanwhile new developer documentation is being written on the Trac wiki. It seems confusing to split the documentation over two sites, and most developers find it easier to update the wiki so it might be a good idea to move all the developer documentation over to the wiki and the Trac would become the 'developer's site'. This could also help improve the main boost site. It could be simpler and more focussed towards users. Some developer pages would probably have to remain on the site for technical reasons (such as test results) and some articles might not be appropriate, or we might not have the author's permission to put them on a wiki. The developer section would be replaced by a page suggesting how to contribute to boost (along the lines of http://lists.boost.org/MailArchives/boost-docs/2010/01/3960.php) We'd also keep the calendar on the main site in some form, as it can be useful for users. Any thoughts? Daniel

3 4

TMP runtime access problem
by Willy Liu 09 Feb '10

09 Feb '10

Hi, I wonder that how to access metadata in runtime. If I pre-compute something and save them into a template ARRAY<int N>, how can I random access the metadatas in runtime? What I can only do is binary searching. Is it possible to do in constant time, or there exist some functions in MPL doing this? #include<cstdio> using namespace std; template<int N> struct ARRAY { static const int a = ARRAY<N - 1>::a * 2; }; template<> struct ARRAY<0> { static const int a = 1; }; template<int LOWER, int UPPER> struct BS { static const int MID = UPPER + LOWER >> 1; typedef BS<MID + 1, UPPER> GREATER; typedef BS<LOWER, MID> LESS; static inline int binary_search(int n) { if(n > MID) return GREATER::binary_search(n); else return LESS::binary_search(n); } }; template<int N> struct BS<N, N> { static const int MID = N; typedef ARRAY<MID> result; static inline int binary_search(int n) { return result::a; } }; int main() { int n; printf("2^n n:"); scanf("%d", &n); printf("ARRAY<%d>::a = %d\n", n, BS<0, 30>::binary_search(n)); main(); return 0; }

2 1

[GGL][Polygon][Union] Union returns hole (inner ring) of the expected result as the output polygon (outer ring)
by Mohammad Morshed Alam Helal 09 Feb '10

09 Feb '10

Hi, Union of two polygon_2d returns a hole (inner ring) as result. Where - Input polygons - Polygon 1: A big rectangle with a hexagonal hole inside Polygon 2: A triangle that intersects the hole from inside leaving portion of it in the hole Output polygon - The hexagonal hole without the triangle-portion. Expected output polygon - The big rectangle with current output polygon as hole (inner)as described in this picture. The Union of a rectangle with a hexagonal hole and a triangle intersecting the first polygon ***************************** ***************************** ***************************** ******** ********* ******* **X***** ****** XXX***** ***** XXX****** **** XX ***** ***** ****** ****** ******* ******* ******** ******** ********* ***************************** ***************************** ***************************** returns this polygon, instead of the correct result. ++++++++++++ ++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ +++ ++++++++++++++++++ ++++++++++++++++ ++++++++++++++ ++++++++++++ You can use the code bellow to generate the case and some PPM images. You may use a WSQ Viewer to see the polygons. Please let me know any workaround or anything thats I am missing. Thank and regards, Helal // the code void uniontest() // Your main should call it { double L = 200.0; const double outloop[][2] = { {L, L}, {L, -L}, {-L, -L}, {-L, L}, {L, L} }; double R = 100.0; double H = R * sqrt(3.0) / 2; const double inloop[][2] = { {R, 0}, {R/2, -H}, {-R/2, -H}, {-R, 0}, {-R/2, H}, {R/2, H}, {R, 0} }; polygon_2d BIGpoly; //A rectangle with a hexagonal hole in it assign(BIGpoly, outloop); //the rectangle BIGpoly.inners().resize(1); linear_ring<point_2d>& inner = BIGpoly.inners().back(); assign(inner, inloop); //the inner hexagon correct(BIGpoly); //correct the order iff not double a = 20.0; double h = a * sqrt(3.0) / 2; const double t1[][2] = { { 30+0, 10+0}, { 30+a/2, 10+h}, { 30+a, 10+0} }; const double t2[][2] = { { 0, 0}, { a/2, h}, { a, 0} }; const double t3[][2] = { {-10+0, -10+0}, {-10+a/2, -10+h}, {-10+a, -10+0} }; const double t4[][2] = { { 0, -15+0}, { a/2, -15+h}, { a, -15+0} }; const double t5[][2] = { {-50, -40}, {-110, 0}, {-100, 30}, {-50, -40} }; polygon_2d T1, T2, T3, T4, T5, T6; //the triangles assign(T1, t1); correct(T1); assign(T2, t2); correct(T2); assign(T3, t3); correct(T3); assign(T4, t4); correct(T4); assign(T5, t5); correct(T5); std::vector<polygon_2d > P_list, P_union, P_tmp; //the outer shape P_union.push_back(BIGpoly); DumbPPMPrint("c:\\BIGpoly.ppm", P_union.begin(), P_union.size()); //Case 1: floating triangle in hole P_union.clear(); ggl::union_inserter<ggl::polygon_2d >(BIGpoly, T1, std::back_inserter(P_union)); DumbPPMPrint("c:\\case1.ppm", P_union.begin(), P_union.size()); //Case 2: three solid triangle creating a small hole P_union.clear(); P_tmp.clear(); ggl::union_inserter<ggl::polygon_2d >(T2, T3, std::back_inserter(P_tmp)); DumbPPMPrint("c:\\case2_i.ppm", P_tmp.begin(), P_tmp.size()); ggl::union_inserter<ggl::polygon_2d >( (*(P_tmp.begin())), T4, std::back_inserter(P_union)); DumbPPMPrint("c:\\case2.ppm", P_union.begin(), P_union.size()); //Case 3: floating holed-polygon in hole //P_union.clear(); //contains result of case 2 P_tmp.clear(); ggl::union_inserter<ggl::polygon_2d >(BIGpoly, (*(P_union.begin())), std::back_inserter(P_tmp)); DumbPPMPrint("c:\\case3.ppm", P_tmp.begin(), P_tmp.size()); //Case 4: a triangle intersecting the hole from inside P_union.clear(); P_union.push_back(BIGpoly); P_union.push_back(T5); DumbPPMPrint("c:\\case4_pre.ppm", P_union.begin(), P_union.size()); P_union.clear(); ggl::union_inserter<ggl::polygon_2d >( BIGpoly, T5, std::back_inserter(P_union)); DumbPPMPrint("c:\\case4.ppm", P_union.begin(), P_union.size()); P_union.clear(); ggl::union_inserter<ggl::polygon_2d >( T5, BIGpoly, std::back_inserter(P_union)); DumbPPMPrint("c:\\case4_rev_order.ppm", P_union.begin(), P_union.size()); } void DumbPPMPrint(char *name, std::vector<polygon_2d >::iterator it, unsigned int n) { //WSQ Viewer can be of help //http://www.cognaxon.com/index.php?page=wsqview //the holes are black. //the more number of polygons are present at a pixel the brighter the pixel is. unsigned int imgwidth = 512; //pixel width of image unsigned int imgheight = 512; //pixel height of image float width = 400.0; //width of image: 10 units (e.g. meters) float height = 400.0; //height of image: 10 units (e.g. meters) //float width = 6000.0; //width of image: 10 units (e.g. meters) //float height = 6000.0; //height of image: 10 units (e.g. meters) //header FILE *signal = fopen(name, "wt"); fprintf(signal, "P3\n"); fprintf(signal, "# %s\n", name); fprintf(signal, "%d %d\n", imgwidth, imgheight); fprintf(signal, "255\n"); unsigned int x, y, i; float xpos, ypos; // PPM images carry red, green, blue color channels. int val0, val1, val2; std::vector<polygon_2d >::iterator poly; for (y = 0; y < imgheight; y++) { ypos = height/2 - height * y / imgheight; for (x = 0; x < imgwidth; x++) { xpos = width/2 - width * x / imgwidth; val0 = val1 = val2 = 0; //black ggl::point_xy<float> point(xpos, ypos); poly = it; for (i = 0; i < n; i++, poly++) { if( ggl::within( point, (*poly) ) ) { val0 += 255/n; val1 += 255/n; val2 += 255/n; } } //fi_poly // clamp to allowed range if (val0 < 0) val0 = 0; else if (val0 > 255) val0 = 255; if (val1 < 0) val1 = 0; else if (val1 > 255) val1 = 255; if (val2 < 0) val2 = 0; else if (val2 > 255) val2 = 255; fprintf(signal, "%3d %3d %3d ", val0, val1, val2); if (x%16 == 15) fprintf(signal, "\n"); } //fi_x } //fi_y fclose(signal); } //@End_of_Code

2 7

C++ Networking Library Release 0.5
by Dean Michael Berris 09 Feb '10

09 Feb '10

Good day everyone, and I apologize in advance for the shameless plug. That said though, I'd like to announce the availability of version 0.5 of the C++ Network Library (cpp-netlib) on both Github and Sourceforge. For those interested in trying out a header-only being-developed-for-boost-inclusion networking library collection, you can download the latest release from: http://github.com/cpp-netlib/cpp-netlib/downloads or https://sourceforge.net/projects/cpp-netlib/ Active development happens on Github where the official repository is http://github.com/cpp-netlib/cpp-netlib (or via git) git://github.com/cpp-netlib/cpp-netlib.git While the cutting edge "clearing house" repository is the one I host also on Github http://github.com/mikhailberis/cpp-netlib (or via git) git://github.com/mikhailberis/cpp-netlib.git The latest release contains: * An HTTP 1.1 client * An embeddable HTTP 1.0 server template If you're interested in joining in on the development, please join the discussion at the cpp-netlib-devel mailing list at: https://lists.sourceforge.net/mailman/listinfo/cpp-netlib-devel or just fork my Github hosted repository -- then send pull requests when you feel like submitting your work "upstream" to me. We're currently in the process of moving on to implementing an HTTP 1.1 server template (looks like a Java Servlet Container), more efficient HTTP 1.1 client implementations, and other goodies. You can find documentation about cpp-netlib over at http://cpp-netlib.github.com/ Thanks in advance everyone and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

31 123

[contract] Contract Programming Library
by Lorenzo Caminiti 09 Feb '10

09 Feb '10

Hi all, I am thinking to submit a library for Contract Programming (a.k.a. Design By Contract (TM) ) for C++. I have drafted some of the library documentation in Boost-like format: http://dbcpp.sourceforge.net/boost/libs/contract/doc/html/ Comments? Regards, Lorenzo

6 15

Re: [boost] boost::mpl::for_each and value_initialized
by Niels Dekker - address until 2010-10-10 08 Feb '10

08 Feb '10

>> I'm sorry, MSVC bug #100744 is still there, even though #335987 has >> been fixed. VC9 deals with POD types correctly, but may not do so >> for non-POD aggregate class types. Domagoj Saric wrote: > but if this is so, shouldn't the proposed patch atleast be > modified to: > > #ifdef BOOST_VALUE_INITIALIZATION_NEEDS_MEMSET > if > ( > !( > ( _MSC_VER >= 1500 ) && > ( is_pod<T>::value ) > ) > ) > std::memset(&x, 0, sizeof(x)); > > #endif > ? I would consider that a refinement. But it's not that simple. MSVC does value-initialize a lot of non-POD types correctly! (But not all of them.) Other compilers may value-initialize built-in types correctly, but not aggregates. I can't remember exactly. So I'd rather start by committing the simple fix that I proposed at Aleksey's ticket #3869, "Unconditional call to memset in value_initialized()", https://svn.boost.org/trac/boost/ticket/3869 Note that I'm planning to rename the macro to BOOST_NO_PROPER_VALUE_INITIALIZATION_FOR_ALL_TYPES. I hope that's okay. But before I commit I'll have to write unit tests for this macro, as John explained to me. I'm planning to do so later this month. When all that is done and stabilized, I wouldn't mind looking at some possible fine tuning, to further reduce the number of memset calls. But I'm afraid it will be a maintainer's headache. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

2 1

[lexical_cast] efficiency
by Domagoj Saric 08 Feb '10

08 Feb '10

'A while back', in the "error_code debate" I used a lexical_cast<> example for demonstrating certain concerns/aspects but the whole post was so long (as usual :) that it was probably read by less than 0.1% of people :) Anyways I'm extracting and reposting this bit now as I think it warrants attention. The first problem is the ('standard') "std::streams vs efficency" issue: - on msvc 9.0 sp1 the single line boost::lexical_cast<int>( "321" ); caused 14 calls to new and 26 calls to EnterCriticalSection() (not to mention vtable initializations, virtual function calls, usage of locales...) the first time it is called, and 3 calls to new and 15 calls to EnterCriticalSection() on subsequent calls...It also caused the binary (which does not otherwise use streams) to increase by 50 kB! ...which is IMNHO abhorrent... (with my usual 'put things in perspective' examples http://www.theprodukkt.com/kkrieger http://www.youtube.com/watch?v=3vzcMdkvPPg :) As a start maybe this problem could be sufficiently "lessened" by providing lexical_cast specializations/overloads that use C library functions (strtol, itoa and the likes) as they suffer less from bloat/performance issues than std::streams. Ideally, IMHO, lexical_cast<> should provide the power/configurability of boost::numeric_cast (so that one can, for example, say I do not need/want to use locales/assume ASCII strings and things like that). The second problem is the use of exceptions (or better of only using exceptions): if, for example, one uses lexical_cast<> deep in the bowels of some parser it is probably "natural" to use a bad_cast exception to report an error to the outside world but if one uses lexical_cast<> to convert a string entered into a widget by a user into an int it would mostly be simpler to have a simple error code if the user entered an invalid string and issue a warning and retry "at the face of the place" (without the need for try-catch blocks)... In other words maybe a dual/hybrid approach of using both exceptions and error codes (through different overloads would be justified). -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

5 9

boost::mpl::for_each and value_initialized
by Peter Foelsche 08 Feb '10

08 Feb '10

Dear All, what is the use of value_initialized in boost::mpl::for_each? It should be sufficient if the value is initialized by the constructor. value_initialized() calls memset() in before calling the constructor. This memset() is not being optimized away with gnu-c++ 4.4.1. What class does require zeroed memory to work correctly? Peter *** boost_1_40_0/boost/mpl/for_each.hpp Mon Aug 17 22:16:53 2009 --- boost_1_40_0.saved/boost/mpl/for_each.hpp Tue Sep 1 12:54:55 2009 *************** *** 71,78 **** // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. ! value_initialized<arg> x; ! aux::unwrap(f, 0)(boost::get(x)); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value> --- 71,78 ---- // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. ! //value_initialized<arg> x; ! aux::unwrap(f, 0)(arg()); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value>

5 10

[fusion] is there an adapter for C-arrays?
by vicente.botet 08 Feb '10

08 Feb '10

Hi, I need to visit the members of a C++ type using Fusion sequences. For structures I plan to use BOOST_FUSION_ADAPT_STRUCT. I need also to visit also c-arrays (with static size). I see that there is already an adapter for boost::array. Is there an adapter for C-arrays? Thanks, _____________________ Vicente Juan Botet Escribá

4 11

Re: [boost] boost::mpl::for_each and value_initialized
by Niels Dekker - address until 2010-10-10 07 Feb '10

07 Feb '10

Peter Foelsche wrote: > in boost_1_41_0 there is still an unconditional call to memset in > value_initialized() Fernando Cacciola and I originally added the memset call within value_initialized() for MSVC only, because MSVC's implementation of value-initialization was known to incorrectly leave some bytes uninitialized, in some very relevant use cases. https://svn.boost.org/trac/boost/changeset/39157/trunk/boost/utility/value_… Thereby we also added extra unit tests, which were passed by MSVC by then, because of the memset. But unfortunately they failed on other compilers (GCC, Borland/Codegear and Sun), because of similar value-initialization issues. That's when we thought it was wise to just have the memset call there for all compilers: https://svn.boost.org/trac/boost/changeset/41942/trunk/boost/utility/value_… Do I understand correctly that you want the memset call to be skipped for those compiler versions that have implemented value-initialization entirely correctly? Do you know exactly which compiler versions do implement value-initialization correctly? Personally I do appreciate that the behavior of value_initialized is now exactly the same for all compilers. But I do understand you're concerned about the performance penalty of the memset call, for those compilers that have implemented value-initialization correctly. If so, can you please create a ticket, preferably including a patch? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

5 8

wrapper to add Boost.Iterator adaptors to Boost.Range
by dstahlke 07 Feb '10

07 Feb '10

I've worked up a subclass that adds Boost.Iterator functionality to a Boost.Range object. The motivation was twofold: Range combines begin() and end() into one object, preventing the need to write iterator adapter code twice, and adding adaptors into the subclass avoids the need to specify namespaces and allows code structures similar to those of perl or ruby. I expect that this type of writing will become desirable when C++0x lambda functions are available. The C++0x 'auto' keyword will allow storing the generated iterators to local variables for further arithmetic; as it stands now the induced types are far to complex to be written out by hand. The point of this message is just to share the idea in case anyone wishes to do something with it. I'm relatively new to C++ and lack the knowledge needed to make something like this the right way. For example, I have no idea how to make the transform_tuple function work with anything other than a two element tuple. The '*' and '+' arithmetic operators have been defined to perform pairwise arithmetic between elements, but it may also make sense to define operators like "magic_iter + scalar" and "magic_iter += magic_iter". With the 'auto' keyword this would allow converting a bunch of STL containers into iterator objects which could then be manipulated mathematically as if they were Blitz++ arrays. /////////////////////////////////////////////// // magic_iter_demo.cpp /////////////////////////////////////////////// #include <magic_iter.h> #include <vector> #include <set> #include <iostream> #include <boost/foreach.hpp> #include <boost/lambda/lambda.hpp> using namespace boost::lambda; int main() { std::cout << "--- odd multiples of 10, reverse sorted\n"; std::vector<int> tmp; BOOST_FOREACH( int x, my::make_magic_counter(0, 10). filter(_1 & 1). transform<int>(_1 * 10). assign_to(tmp). // needed to allow sort sort(_1 > _2) ) { std::cout << x << std::endl; } std::cout << "--- unique elements of v*w, using zip\n"; std::vector<int> v; std::vector<double> w; my::make_magic_counter(0, 11). transform<int>(_1 - 5). assign_to(v). transform<double>(_1 * 0.01). assign_to(w); std::set<double> tmp2; zip(my::make_magic_iter(v), my::make_magic_iter(w)). transform_tuple<double>(_1 * _2). insert_into(tmp2). // uniq for_each(std::cout << _1 << "\n"); std::cout << "--- elements of v*w, using operator\n"; (my::make_magic_iter(v) * my::make_magic_iter(w)). for_each(std::cout << _1 << "\n"); } /////////////////////////////////////////////// // magic_iter.h /////////////////////////////////////////////// #ifndef MAGIC_ITER_H #define MAGIC_ITER_H #include <iterator> #include <algorithm> #include <boost/range/iterator_range.hpp> #include <boost/iterator/transform_iterator.hpp> #include <boost/iterator/filter_iterator.hpp> #include <boost/iterator/zip_iterator.hpp> #include <boost/iterator/counting_iterator.hpp> #include <boost/tuple/tuple.hpp> #include <boost/lambda/lambda.hpp> namespace my { // result_type_wrapper is from mailing list post by Maxim Yegorushkin template <class R, class F> struct result_type_wrapper : F { typedef R result_type; explicit result_type_wrapper(const F &f) : F(f) {} }; template <class R, class F> static inline result_type_wrapper<R, F> result_type(const F &f) { return result_type_wrapper<R, F>(f); } template <class R, class F> struct tuple_lambda_wrapper { typedef R result_type; explicit tuple_lambda_wrapper(const F &_f) : f(_f) { } template <class T> R operator()(const T &tuple_val) const { return f( boost::tuples::get<0>(tuple_val), boost::tuples::get<1>(tuple_val) ); } F f; }; template <class R, class F> static inline tuple_lambda_wrapper<R, F> tuple_lambda(const F &f) { return tuple_lambda_wrapper<R, F>(f); } template <class T> class magic_iter : public boost::iterator_range<T> { public: typedef typename std::iterator_traits<T>::value_type value_type; magic_iter(const T &_begin, const T &_end) : boost::iterator_range<T>(_begin, _end) { } template <class F> magic_iter<boost::transform_iterator<F, T> > transform(const F &f) { return magic_iter<boost::transform_iterator<F, T> >( boost::make_transform_iterator(this->begin(), f), boost::make_transform_iterator(this->end(), f) ); } template <class R, class F> magic_iter<boost::transform_iterator< result_type_wrapper<R, F>, T> > transform(const F &f) { return transform(result_type<R>(f)); } template <class R, class F> magic_iter<boost::transform_iterator< tuple_lambda_wrapper<R, F>, T> > transform_tuple(const F &f) { return transform(tuple_lambda<R>(f)); } template <class C> magic_iter<typename C::iterator> assign_to(C &container) { container.assign(this->begin(), this->end()); return make_magic_iter(container); } template <class C> magic_iter<typename C::iterator> insert_into(C &container) { container.insert(this->begin(), this->end()); return make_magic_iter(container); } template <class F> magic_iter<T> &sort(const F &comparator) { std::sort(this->begin(), this->end(), comparator); return *this; } template <class F> magic_iter<boost::filter_iterator<F, T> > filter(const F &f) { return magic_iter<boost::filter_iterator<F, T> >( boost::make_filter_iterator(f, this->begin(), this- >end()), boost::make_filter_iterator(f, this->end(), this->end()) ); } template <class F> void for_each(const F &f) { std::for_each(this->begin(), this->end(), f); } }; template <class T> magic_iter<typename T::iterator> make_magic_iter(T &container) { return magic_iter<typename T::iterator>(container.begin(), container.end()); } template <class T> magic_iter<typename T::iterator> make_magic_iter(const T &begin, const T &end) { return magic_iter<typename T::iterator>(begin, end); } template <class T> magic_iter<typename boost::counting_iterator<T> > make_magic_counter(const T &begin, const T &end) { return magic_iter<typename boost::counting_iterator<T> >( boost::counting_iterator<T>(begin), boost::counting_iterator<T>(end) ); } template <class A, class B> magic_iter<boost::zip_iterator<boost::tuple<A, B> > > zip(const magic_iter<A> &a, const magic_iter<B> &b) { //return make_magic_iter( return magic_iter<boost::zip_iterator<boost::tuple<A, B> > >( boost::make_zip_iterator( boost::tuple<A, B>(a.begin(), b.begin()) ), boost::make_zip_iterator( boost::tuple<A, B>(a.end(), b.end()) ) ); } template <class X, class Y> struct tuple_multiply { typedef typename boost::lambda::return_type_2< boost::lambda::arithmetic_action< boost::lambda::multiply_action >, X, Y>::type result_type; result_type operator()(const boost::tuple<X, Y> &t) const { const X &x = boost::tuples::get<0>(t); const Y &y = boost::tuples::get<1>(t); return x*y; } }; template <class X, class Y> magic_iter<boost::transform_iterator< tuple_multiply<typename X::value_type, typename Y::value_type>, boost::zip_iterator<boost::tuple<X, Y> > > > operator*(magic_iter<X> x, magic_iter<Y> y) { //magic_iter<boost::zip_iterator<boost::tuple<X, Y> > > zi = zip(x, y); //return zi.transform(tuple_multiply<typename X::value_type, typename Y::value_type>()); tuple_multiply<typename X::value_type, typename Y::value_type> op; return zip(x, y).transform(op); } template <class X, class Y> struct tuple_plus { typedef typename boost::lambda::return_type_2< boost::lambda::arithmetic_action< boost::lambda::plus_action >, X, Y>::type result_type; result_type operator()(const boost::tuple<X, Y> &t) const { const X &x = boost::tuples::get<0>(t); const Y &y = boost::tuples::get<1>(t); return x+y; } }; template <class X, class Y> magic_iter<boost::transform_iterator< tuple_plus<typename X::value_type, typename Y::value_type>, boost::zip_iterator<boost::tuple<X, Y> > > > operator+(magic_iter<X> x, magic_iter<Y> y) { tuple_plus<typename X::value_type, typename Y::value_type> op; return zip(x, y).transform(op); } } // namespace my #endif // MAGIC_ITER_H

3 2

[wave] limited extensibility
by Christopher Lux 07 Feb '10

07 Feb '10

Hi, i am trying to use boost.wave as a preprocessor for OpenGL Shading Language shader files (GLSL). GLSL uses a limited C/C++ preprocessor (no included etc.). I want to use boost.wave to handle the includes correctly besides generally gaining a more powerful preprocessor. Now the problem is that there a special preprocessor directives in GLSL that the compiler itself has to handle. I am speaking of the #version and #extension directives. I hoped boost.wave would provide the possibility to add special directives that the client code then can handle properly. Currently I use the context hook as follows: class glsl_preprocessing_hook : public boost::wave::context_policies::default_preprocessing_hooks { public: template <typename ContextT> void throw_exception(ContextT const &ctx, std::exception const& e) { throw e; } template <typename ContextT> void throw_exception(ContextT const &ctx, boost::wave::preprocess_exception const& e) { // just ignore ill formed directives (version, exception...) and let the glsl compiler handle these if(e.get_errorcode() != boost::wave::preprocess_exception::ill_formed_directive) { throw e; } } }; This just ignores the ill formed directives, but may still let unwanted errors through. Would it be possible to extend boost.wave in a way to be able feed the lexer or context regular expressions of the new custom directives? These could be pushed into a special hook method with the appropriate context information. I think this functionality would greatly increase the usability for C++ like languages with custom extensions to the preprocessor. Regards -chris

2 4

[chrono] v0.3.1 Support for wide characters
by vicente.botet 07 Feb '10

07 Feb '10

Hi, this new version includes: * Added support for wide characters on formatters. * Added chrono.hpp and stopwatches.hpp header files at the boost level. * Update of the doc taking care of preceding comments. Comments are welcome :) Best, Vicente ----- Original Message ----- From: "vicente.botet" <vicente.botet(a)wanadoo.fr> To: <boost(a)lists.boost.org>; <boost-users(a)lists.boost.org> Sent: Sunday, January 17, 2010 9:14 PM Subject: [chrono] v0.3 New Stopwatch Feature Hi, I'm pleased to announce the new version of the Boost.Chrono library. The implementaton is quite stable; the new interface could suffer of some modifications, renaming, ... as far as you submit some proposals. I would request a formal review soon and I will need a review manager. I know that review managers are hard to find, so if you are interested in the library, please the Review Wizards. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. I've tested it with gcc and MSVC. Previoous version of the library have been testted on Mac, but I'm not able to test this platform. Could someone check if there are some regressions on Mac? New Features: * Process cpu clocks * Independent process cpu clocks for real, user, system process CPU time * Global process cpu clock for real, user, system process CPU time * Stopwatch concept measuring elapsed time between different points in time associated to the operations start, stop, suspend and resume. * stopwatch is a model Stopwatch measuring the elapsed time between the start and the stop operations. * stopwatch_accumulator is a model Stopwatch allowing to accumulate several time samples and give the average, ... * Scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopwatch Formatter concept * stopwatch formatter "%ds\n" * stopwatch accumulator formatter "%c times, sum%ss, min%ms, max%Ms, mean%as\n" * time formatter "real %rs, cpu %cs (%p%), user %us, system %ss\n" * digital_time decomposition class separating days, hours,minutes,seconds, nanoseconds from any duration class (looking for a better name) * digital_time formatter "%d days(s) %h:%m:%s.%n\n" * stopwatch_reporter is a convenient generic class reporting elapsed time for the Stopwatch concept. * stopclock<Clock> shortcut stopwatch_reporter<stopwatch<Clcok>> * typeof registration for classes duration and time_point Depreceated Features: * The classes process_times, process_clock, process_timer, timer and run_timer are now deprecated as the preceding additions are more generic. However for backward compatibility they are preserved until inclusion of the library in Boost. Next follows the equivalences: timer<> ~ stopwatch<> process_timer ~ stopwatch<process_cpu_clock> run_timer ~ stopclock<> Bug Fixes * Try to correct warning C4251: 'boost::chrono::run_timer::m_format' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'boost::chrono::run_timer', by don't including inlines functions using the std::string m_format. For people that doesn't know it yet, Boost.Chrono library provides: * The C++0x Standard Library's common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including: * Class template duration * Class template time_point * Clocks: * system_clock * monotonic_clock * high_resolution_clock * typeof registration for classes duration and time_point * Process clocks: * process_real_CPU_clocks, capturing real-CPU times. * process_user_CPU_clocks, capturing user-CPU times. * process_system_CPU_clocks, capturing system-CPU times. * process_cpu_clock, tuple-like class capturing at once real, user-CPU, and system-CPU times. * Stopwatches: * stopwatch, capturing elapsed Clock times. * stopwatch_accumulator, capturing cummulated elapsed Clock times. * scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopclocks or Stopwatch reporters: * stopwatch_reporter, convenient reporting of models of Stopwatch results. * stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Best regards, _____________________ Vicente Juan Botet Escribá

7 9

[thread] small futures patch
by Christopher Lux 07 Feb '10

07 Feb '10

Hi, i came across an annoying compiler warning when using boost.thread (1.42 release) in a 64bit environment. Attached is a small patch for the futures.hpp in the trunk. Regards -chris

1 0