- Boost - lists.boost.org

[lambda] warning supression
by Steven Watanabe 26 Feb '09

26 Feb '09

AMDG The attached patch allows Lambda's tests to compile with warnings=all warnings-as-errors=on with gcc-4.3.0 msvc8.0express and msvc-9.0express. Ok to commit? In Christ, Steven Watanabe

3 2

[tuple] gcc warnings
by Steven Watanabe 26 Feb '09

26 Feb '09

AMDG I've tested the fix for #2388 and it looks ok. Okay to commit? In Christ, Steven Watanabe

3 2

best way to remove duplicates from forwardIterator [startIter, endIter]
by Sandeep Gupta 26 Feb '09

26 Feb '09

Hi, Given a collection in terms of [startIter, endIter] how can obtain [uniqBeginIter, uniqEndIter] that represents unique elements of the original container. I can always explicitly instantiate a set S of [startIter, endIter] and use [S.begin(), S.end()]. Is it possible to express this in terms of algorithms. Please note that I won't be able to use std::sort as startIter does not conform to RandomAccessIterator. Its a forward iterator. Thanks Sandeep

3 3

Re: [boost] [convert] Default Syntax Idea
by Vladimir.Batov＠wrsa.com.au 26 Feb '09

26 Feb '09

> From: "Stewart, Robert" <Robert.Stewart(a)sig.com> > I was thinking a bit about syntax for the default value for the > notional boost::convert() and kin. How about the following: > > int const i(3); > string const s("something"); > int const j(convert<int>(s) | 5); Yes, this idea is similar to int j = convert<int>(s).or_default(5); but does not introduce new vocabulary (my main hesitation). With the suggested op|, as I am reading it, it makes perfect reading just like I'd read English. And that is usually my criterion for an interface. So, I am voting 'yes'... in principle. See further below. > convert<DestType,SourceType>(SourceType) can return a type which > throws on failure in operator DestType(), but has an operator > |(SourceType) which returns a second type constructed with the > SourceType value. The second type provides its own operator > |(SourceType) which returns that value in its operator DestType() on failure. When the user does not want comprehensive result, it works. The problem as I see it is when the user wants the comprehensive report -- we return two different types, convert1<string, int> j1 = convert<string, int>(s); convert2<string, int> j2 = convert<string, int>(s) | 5; Sometimes I feel we need that as I might like to explicitly check if the call failed without relying on the default convert1<string, int> j1 = convert<string, int>(s) & boost::nothrow; convert2<string, int> j2 = convert<string, int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed Unless we convert both convert1 and convert2 to convert<string, int>::result as convert<string, int>::result j1 = convert<string, int>(s) & boost::nothrow; convert<string, int>::result j2 = convert<string, int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed Or we might simplify that as convert::result<int> j1 = convert::to<int>(s) & boost::nothrow; convert::result<int> j2 = convert::to<int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed The reason I am sticking 'to' in again is that I need the 'convert' as a namespace... or rather as a namespace-like structure: struct convert : mimic_namespace /*I have such a class*/ { template<class TypeOut> struct result { TypeOut value_; bool good_; }; struct internal_with_default { ... }; struct internal_with_no_default { ... }; template<class TypeOut, class TypeIn> internal_with_default<TypeOut, TypeIn> to(TypeIn const&); }; With namespace-like convert structure people will not be able to shortcut 'convert'. I.e. they'll always have to say convert::to which is darn close to convert_to with the advantage of having a dedicated namespace-like place instead of messing inside the boost namespace. Now it seems like I am back where I started. :-) > Returning a default value in lieu of an exception is a special case; > it ought not be treated like formatting. I have an impression that throwing/not-throwing and providing/not-providing the default have to be configured independently. Like I *might* need to throw even if I provide the default: direction dir = convert<string, direction>(str, direction::up) & boost::dothrow; Above I provide the default because I have to (direction does not have the def. ctor). However, I still *might* like to throw on failure. > Thus, while Boost. > Parameter might be appropriate to package the extra information > desired for formatting, I don't like the idea of writing "default_ = > 5" in the call, and I don't think ", 5" in the argument list is as > clear as it could be. I tend to agree with you on both. > The syntax above is obvious and concise while > being distinct from whatever may be done for formatting. You meant to say "laconic", right? Oh, just kidding. Thanks for pointing it out BTW. BTW, what do you think of convert<string, int>(s) & boost::dothrow; instead of convert<string, int>(s) >> boost::throw_t(); People seem to get put off by op>>. Best, V.

7 11

[optional_io] InputStreamable refinement
by Andrew Troschinetz 25 Feb '09

25 Feb '09

This is a spin off from the thread "[lexical_cast] A suggestion" While trying to get lexical_cast and optional to play nice I've run up against some problems with the InputStreamable solution for optional types in optional_io.hpp. The crux of the problem is that I think any given optional type should behave as much like the type it wraps as possible. For example I think this: stringstream sin ("1.2.3.4.5"); optional<double> token; while (sin >> token) cout << token << endl; Should have the same output as this: stringstream sin ("1.2.3.4.5"); double token; while (sin >> token) cout << token << endl; And that this shouldn't fail: stringstream sin ("test"); optional<string> token; sin >> token; // token shouldn't be empty The current InputStreamable solution for optional does not pass these tests. But that's not all, I also believe that there is room for even more improvement here! Since it's semantically valid to have an un- initialized optional type, I think failure to extract something off a stream should return an empty optional type _without_ setting the failbit on the stream. Here's a usage example that demonstrates what I mean by that: // output is "1 nan nan nan nan 5.5 nan nan nan nan nan nan nan -3.2 nan " istringstream sin (" 1 this 5.5 is a test -3.2 a"); optional<double> token; const double nan = numeric_limits<double>::quiet_NaN (); while (sin >> token) cout << token.get_value_or (nan) << " "; // output is "1 " istringstream sin (" 1 this 5.5 is a test -3.2 a"); double token; while (sin >> token) cout << token << " "; I did submit a ticket with the final comment proposing code that is (maybe?) a solution to this refinement. ( https://svn.boost.org/trac/boost/ticket/2659 ) Please pardon any guffaws I made in replies to that ticket, I'm still learning about the nuts and bolts of streams and boost as I go. However there is still one problem, and this brings us back to lexical_cast. Consider this example: int an_invalid_uint = -1; unsigned i = lexical_cast<optional<unsigned> > (an_invalid_uint).get_value_or (0); I believe we should expect this to store 0 in i, but instead it will throw a bad_lexical_cast exception even with my proposed revision to optional_io.hpp. A possible solution is a specialization for optional<Target> somewhere in lexical_cast.hpp that would replace code that looks something like this (pseudocode): do lexical_cast if failed to cast: throw exception With something like this: do lexical_cast if failed to cast: return optional<Target>() So is there any interest in this sort of refinement of optional's InputStreamable implementation or lexical_cast? -- Andrew Troschinetz Applied Research Laboratories

2 2

Extending asio (SCTP support)
by Hal Finkel 25 Feb '09

25 Feb '09

Hello, I've started implementing SCTP support in asio. I would like some feedback on what methodology is preferred. Although I had originally wanted to provide SCTP support as a pure add-on to the current framework, unfortunately, I don't think that can be done. For example, SCTP supports multi-homed endpoints, and the standard API provides a function sctp_bindx which can add and remove endpoint addresses from an active association (connection). While I can provide a subclass of socket_acceptor_service with this extended interface, there is no way of changing the wrapper (detail::reactive_socket_service) used to implement socket_acceptor_service's service_impl_type, and since socket_, protocol_, etc. are private members of detail::reactive_socket_service, I think that there is no way a subclass of socket_acceptor_service can access the underlying socket object. This seems to leave two options: 1. Patch the missing functionality into the existing classes. What worries me is that this approach does not seem to "scale" well with respect to the addition of new protocols. (what happens if someone needs TIPC support, for example). 2. Provide some kind of protocol-specific extension mechanism (templated base classes for example) for detail::reactive_socket_service and other such classes so that it is possible to provide protocol-specific extensions to the base asio interface. Does anyone have a preference on how I proceed? (or is there an option I've missed?) And if some extension mechanism is desired, is there a preference on the technique used for its implementation? Thank you in advance, Hal Finkel P.S. For anyone looking for a quick introduction to SCTP and its associated socket API, I've found HP's SCTP Programmer's Guide (http://docs.hp.com/en/5992-4578/index.html) to be pretty good.

2 2

[geometry] gtl review pre-announcement
by Simonson, Lucanus J 25 Feb '09

25 Feb '09

Fellow geometry authors and interested reviewers, My abstract for gtl has recently been accepted to boostcon. I was unable to put together a geometry panel discussion, however. I am also working on completing documentation for the library by April. I would like the gtl library to be under review during boostcon because I may get the opportunity to meet and talk to some of the reviewers in person. To that end I'd like to ask for volunteers to be review manager and reviewers of the library now so that it isn't a surprise and things can proceed smoothly when the documentation is ready in a few weeks. I especially want other geometry authors to be aware of my plans and schedule. I have the utmost respect for the authors of the other two serious geometry proposals. It is my hope that we can work together during the review process and after to improve and converge our libraries toward the ideal boost::geometry library that all of us can feel proud of. Eventually it is my hope that algorithms in boost::geometry come for a variety of sources selected based upon quality such that there is no single owner of the library, but rather a community. I look forward to your reviews. Thanks, Luke

1 0

Re: [boost] Boost.Convert+Boost.Parameter
by Vladimir.Batov＠wrsa.com.au 25 Feb '09

25 Feb '09

> The keywords are decoupled. > ... > Did you read through the Boost.Parameter tutorial? OK, I admit before I only glanced over the docs a couple of times. I thought I got the idea. Obviously not. :-( Now I printed it out and set down reading. Now I see the registration is all by itself and not coupled with anything. That's good. So, convert() can take those parameters in. Given we do not know how many parameters there might be I'd suggest we set those parameters with operator(). Like convert<string, int>(str)(default_ = -1)(throw_ = false)(some_other_parameter_ = ...) Given, convert() does not know and does not understand "some_other_parameter_" somebody else will need to do something with it. Who would that be and what would it do? I presume we could come up with a Boost.Parameter-based manipulator analog... or... no, I admit I am out of ideas. How can all that work? Thanks, Vladimir.

6 7

[utility] value_initialized fix causes Intel-linux 9.0 compile error
by Niels Dekker - mail address until 2010-10-10 24 Feb '09

24 Feb '09

My fix of the "const incorrectness" of boost::value_initialized (changeset [51355]), committed to the trunk last Friday, has passed the value_init_test tests successfully on most compilers, including intel-linux 10.0 and 10.1: www.boost.org/development/tests/trunk/developer/utility_.html Unfortunately it has a compile time regression failure on intel-linux 9.0, when trying to compare a value_initialized<NonPOD*> and a NonPOD*: error: more than one operator "==" matches these operands: built-in operator "pointer == pointer" built-in operator "pointer == pointer" operand types are: boost::value_initialized<NonPOD *> == NonPOD *const www.boost.org/development/tests/trunk/output/Sandia-intel-9-0-boost-bin-v2-… I don't have access to an Intel compiler, but it looks like the compile error is specific to pointers, as it doesn't seem to occur when comparing value_initialized<T> and T for other types T (int, double, POD, NonPOD). Is this a known compiler bug of the Intel 9.0? Apparently it's fixed by Intel 10.0. The fix of changeset [51355] replaced the existing conversion operator by a pair of them, overloaded for const and non-const. See also https://svn.boost.org/trac/boost/ticket/2548 Would it be okay to just mark the regression failure as "expected", and leave the implementation of boost::value_initialized as it is, including the const-fix? Otherwise, do you have any suggestion for a workaround? Note that the compile error is specific to the implicit use of the conversion operator. value_initialized also provides "get" functions and data() member functions to retrieve its value, which should still work fine on Intel 9.0. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

DynObj - Library for C++ runtime plugin objects
by Arne Steinarson 24 Feb '09

24 Feb '09

I'm the developer of DynObj - a C++ library for cross platform plugin objects/components. In short, the approach of the library is to exploit the underlying compiler representation of virtual function tables. Since the VTable of any type occupies a unique place in memory, the VPTR forms a valid runtime type ID. With the help of this type ID, DynObj (in a host application) can then access type information emitted by the plugin compiler. In effect, we get a cross compiler variant of dynamic_cast<>: * U* do_cast<U*>( T *pt )* This cast operation then takes the role of *QueryInterface(...)* in COM or xpCOM. The difference is that we're not forced into using a specific base class for plugin capable types. We also get a meaningful type system shared across host/plugin, not just isolated interfaces. To go about all of this, the library relies on quite a bit of template code, effectively tracking down object and interface offsets inside classes, and then exporting them in a well defined, binary safe structure. However, to simplify this (there is a bit of 'boiler plate code' needed for each plugin type), DynObj uses a preprocessor that generates most of this, based on a few preprocessing tags embedded in C++ comments. So it is not a 100% compile-time library. Also when using plugins, a fair bit of template code is used, for instantiating objects, smart pointers, executing functions on foreign interfaces and so on. Using plugin objects becomes almost transparent in many cases. More information is available here: http://dynobj.sourceforge.net Now, I wonder if there is any interest from Boost in this type of library. At this time, I'm not eager to do a complete rewrite, since it fills our needs pretty much as it is. If there is some interest, and the basic approach and design is found useful to Boost, I'd be willing to take this some steps further, time permitting. Also, general feedback and experience with the library is appreciated. Best Regards Arne Steinarson, Z-Soft

1 0