- Boost - lists.boost.org

Re: [boost] [switch] Is there any interest in library switch extention?
by Kasra Nassiri(Math & ComSci) 01 Oct '08

01 Oct '08

>I hardly see how this could work for a O(1) lookup (the point of the >switch statement). I have found a compile time solution! However, we need C++0x :( A hash functions with output type of <int> so we could embed the statement in a normal switch statement on C++0x. #define BOOST_SWITCH( object ) switch ( const_hash_function(object) ) #define BOOST_CASE( case_object ) case const_hash_function(case_object) #define BOOST_DEFAULT default So we could write code like: BOOST_SWITCH( "Hello World" ) { BOOST_CASE("wrong value"): BOOST_CASE("another wrong value"): cout << "Reached wrong statements" << endl; BOOST_BREAK; BOOST_DEFAULT: cout << "Hello World" << endl; }; What I like to add is a reference to the value of the BOOST_SWITCH(...), in this example "Hello World".

2 1

[integer] Promotion of endian library code from vault
by Neil Mayhew 01 Oct '08

01 Oct '08

On 2006-07-22 12:21:01, Beman Dawes wrote: > [boost] [integer] endian-0.6 posted w/ names changed > endian-0.6.zip has been posted in the integer directory of the file > vault at http://boost-consulting.com/vault/ This code is still in the vault, but I'd like to see it in the main part of boost. What needs to be done to make this happen? The endian library is exactly what I've been looking for, and I would really like to use it in my work, but I can't justify that to my colleagues if it's not an official part of boost. I would hate to become yet another person that reinvents this particular wheel. However, I notice there was a lot of discussion <http://lists.boost.org/Archives/boost/2006/07/108125.php> about PODs vs constructors, because of unions, so maybe not enough consensus was reached? There were some interesting proposals but no agreed-upon solution. In which case, I suspect that people will need to copy the code and each hack it to suit their own purposes, which is not what boost is all about. I have two use cases from my own work: TrueType fonts, and Mac HFS+ file systems. Both of these are big-endian file formats that need to be read into memory and processed, so (FWIW) I would support the POD approach. Currently, I can't use the code as-is because of the need to use the types in unions. References: http://lists.boost.org/Archives/boost/2000/03/2495.php http://lists.boost.org/Archives/boost/2006/05/105621.php http://lists.boost.org/Archives/boost/2006/06/105695.php http://lists.boost.org/Archives/boost/2006/06/105779.php http://lists.boost.org/Archives/boost/2006/06/105968.php http://lists.boost.org/Archives/boost/2006/06/106655.php http://lists.boost.org/Archives/boost/2006/07/108125.php http://lists.boost.org/Archives/boost/2006/07/108202.php --Neil

9 37

[Phoenix] Review ended September 30th
by Hartmut Kaiser 01 Oct '08

01 Oct '08

Hi all, just a (last) reminder for all of you still wanting to submit a review. The official review period is over, but since I'm going prepare the review summary this weekend only anyway - you still have a day or two. Regards Hartmut Review Manager

1 0

Phoenix and perfect forwarding
by Mathias Gaunard 01 Oct '08

01 Oct '08

Compilers are starting to support rvalue references. Wouldn't it be pertinent to use that to implement perfect forwarding, if available? Phoenix could surely benefit from that.

3 2

[python] Setting a pointer into an object
by Robert Dailey 30 Sep '08

30 Sep '08

Hi, I am trying to do the following: SomeClassOfMine* myInstance; // Assume valid pointer boost::python::object myObject( myInstance ); However, doing so causes an exception to be thrown when I run my application. The exception thrown is below (Note I'm using MSVC9): First-chance exception at 0x7c812aeb in Crusades_Debug.exe: Microsoft C++ exception: boost::python::error_already_set at memory location 0x0012f0cc.. Unhandled exception at 0x7c812aeb in Crusades_Debug.exe: Microsoft C++ exception: boost::python::error_already_set at memory location 0x0012f0cc.. How can I assign the pointer above to a boost::python::object? I'm trying to give my python scripts access to an instance of a class that I haven't really exposed to Python yet, so I'm not sure of the consequences of that. I was going to extend the SomeClassOfMine class to python later on after I verify that I can get this working. Once I have myObject in a valid state, I will insert it into the __main__'s __dict__ namespace for a specific module so that it has access to it as a global python variable. Help is appreciated.

2 3

[interprocess] message_queue documentation issue
by Michael Caisse 30 Sep '08

30 Sep '08

The message_queue documentation states: message_queue(open_only_t <http://www.boost.org/doc/libs/1_36_0/doc/html/boost/interprocess/open_only_…> open_only, *const* *char* * name); Opens a previously created process shared message queue with name "name". If the was not previously created or there are no free resources, the function returns false. The constructor doesn't return a value of course. It does look like the message_queue constructors can throw however... and the documentation should mention that. Best Regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[Phoenix] Some questions and notes...
by Giovanni Piero Deretta 30 Sep '08

30 Sep '08

Hi all, I'm writing a review of phoenix, but first I have a some questions and notes. * First of all, it is not clear to me how 'lambda' works. I would have thought that it just introduced a new scope, but it seems that it does something more: 1: int i = 10; 2: cout << arg1(i) <<endl; 3: cout << lambda[ arg1 ](i) <<endl; // doesn't compile 4: cout << lambda[ arg1 ]()(i) The use of lambda at line 3 is completely superfluous, nevertheless, I prefer that syntax because it makes it clear that I'm using a lambda expression (always using lambda will also allow some other tricks I'll discuss later). Surprisingly, line 3 doesn't compile. lambda::operator[] actually returns a nullary stub that must be evaluated to actually get our unary function. Is this really necessary? can it be fixed? * non-standard result<> protocol. IMHO for Phoenix to become a first class boost library, it should support result_of out of the box. I understand that this is not done for backward compatibility, but I think that there are three solutions: 1) old users will still be able to use the Phoenix inside spirit if they have a large codebase that uses the old protocol. 2) phoenix could provide a wrapper that converts from the old to the new protocol and viceversa. This would require some changes in the client code. 3) phoenix could detect the protocol used by the user function and switch between the old and new 'result'. This is hard to do in a robust way, but breaks no user code. I would prefer the first option. * Perfect forwarding. I'm used to the perfect forwarding in boost lambda (which, contrary to what the documentation states, perfectly forwards up to 3 args). Personally have little use for lambdas that take their arguments by non const reference as I strive for referential transparency. I know that implementing this feature has an high compile time cost, but there should at least be an option to enable it. I would vote for two additional 'lambda' syntaxes: clambda and plambda (better names are wellcome). The first one would work like boost lambda const_arguments and should have no compile time cost, while the second will do perfect forwarding up to some parameter number. This would require the lambda[] syntax to actually return the wrapped function object, not a stub (as per first question). * operator->*. I sometimes use this operator with boost lambda, as a short hand for binding member functions, but, as in phoenix, it requires it lhs to be a pointer. Would it possible to extend it to any functions? for example: struct foo { int bar; }; std::vector<foo> in =...; std::vector<int> out; std::transform(in.begin(), in.end(), std::back_inserter(out), (&arg1)->*&foo::bar); The parenthesis, and ampersand are ugly, it would be great if this worked: std::transform(in.begin(), in.end(), std::back_inserter(out), arg1->*&foo::bar); I think this would interfere with foo implementing its own operator->*. Which brings the question... * ... how do I implement type deduction for the my own overloaded operators? I.e. what is the phoenix equivalent of http://tinyurl.com/4botne ? By reading of the documentation I couldn't figure out an easy way to do it. Well, that's all for now, those questions are mostly to get the discussion rolling, more to come. -- gpd

3 10

Re: [boost] [Review] Phoenix review starts today, September 21st
by dan marsden 30 Sep '08

30 Sep '08

Daniel Walker wrote: <snip> >Of course not. :-) But going in-depth into V2's implementation is not >the same as going in-depth into V3. The design may be the same, but >simple diffing and greping shows the implementations are not. And >that's to be expected. As I understand, whole components were gutted >and replaced with Proto, which is a good thing. So let's continue that >effort and spend our energy on V3 and not look back! > >Now, how that relates to the review formalities and the fact that >apparently V2 is under review, I am not sure. As far as I can tell, >all the reviews thus far have assumed the V2 implementation. I would >suggest withdrawing V2 from consideration (leaving it as is in >Boost.Spirit), finishing V3 (which becomes the new Boost.Lambda), and >then resubmitting for review, but I'm no expert on this process. > It is my understanding that Boost authors retain the "rights" to modify and upgrade their libraries once accepted, both in terms of implementation and interface changes. Boost.Xpressive has seen many changes iirc, including the sorts of changes that we're discussing (reimplementing in terms of proto + I believe some smaller interface changes). Many other libraries have similar history. If the authors of these libraries had stated their development plans, in advance of review, should they have been rejected until they were "finished"? Joel has been very open in stating his future plans, but what he plans has happened many times before to accepted libraries. Obviously the rather fluid state of the libraries does muddy the purpose of the review. I'd suggest we review libraries as is, answer all the usual questions about interface, quality of implementation, docs etc. There seems to be some implicit assumption that the author will act in the spirit of Boost, and reimplement + extend to the same level of quality as seen in the review. I think Joels track record in this area speaks for itself. On your other comment about Phoenix2 remaining under Spirit if it were not to be accepted, that is obviously true, but at some employers/organizations passing the review process and being an official part of a Boost release is a prerequisite to using a library. Cheers Dan

10 24

[threadpool] new version with work-stealing
by k-oli＠gmx.de 30 Sep '08

30 Sep '08

Hi, I've uploaded a new version of threadpool lib (http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_…) changes: - support of work-stealing strategy - task can be interrupted an waited for its termination - thread management strategies lazy and adaptive removed - channel rendezvous removed regards, Oliver

1 0

[config] BOOST_HAS_THREADS with libstdc++
by Frank Mori Hess 30 Sep '08

30 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It looks like the gcc bug (pr 11953) that inspired the workaround in boost/config/stdlib/libstdcpp3.hpp that goes: #ifdef __GLIBCXX__ // gcc 3.4 and greater: # if defined(_GLIBCXX_HAVE_GTHR_DEFAULT) \ || defined(_GLIBCXX__PTHREADS) // // If the std lib has thread support turned on, then turn it on in Boost // as well. We do this because some gcc-3.4 std lib headers define _REENTANT // while others do not... // # define BOOST_HAS_THREADS was fixed for mainstream gcc 4.1.2 and later versions in December of 2006. So can we change the first line to something like: #ifdef __GLIBCXX__ && __GLIBCXX__<20070101 so detection of whether gcc is in multi-threaded mode or not works again? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI4Rim5vihyNWuA4URAs/NAJ45aP24OAUerZUaV48Y1faYt0GsSACeOoJi eiWSbyfmjW8653luxIe0U/s= =HySJ -----END PGP SIGNATURE-----

2 1