January 2008 - Boost - lists.boost.org

Re: [boost] upcoming Switch library review Jan 5th - Jan 9th
by Tobias Schwinger 06 Jan '08

06 Jan '08

Forwarding this post from boost.user... Steven Watanabe wrote: > AMDG > > Tobias Schwinger <tschwinger <at> isonews2.com> writes: > >> dan marsden wrote: >>> Why is the fall through behaviour to throw an exception? >> I too tripped over this one, yesterday. >> >> <snip> > The other option is an assertion. Is that any better? I think the "default default behavior" should be to use the default constructor. This approach works nice with Any, Variant and Optional. > Or should a void return type be a special case? If 'Default's result type is 'void' although something else is expected, we should assert it never actually returns at runtime (note that it is possible to detect the result type with an overloaded comma operator and without requiring 'Default' to work with 'result_of' -- might also be faster). If assertions are disabled the behavior should be unspecified in that case. <snip> >> Of course there are no pointers to templates, so using a function >> pointer for anything but the default is pretty pointless. So is trying >> to handle varying result types -- maybe the result type should be passed >> in with another template parameter? > > I'd rather leave it as result_of<F()>::type. Actually 'result_of<F()>::type' determines the result of the nullary call to F. I don't think I like this sort of "result_of abuse"... The correct usage would be 'result_of<F(MPLConstant)>::type' but it's pointless since 'MPLConstant' varies and so may the whole type expression. So, if you insist on deducing the result type from the function object (instead of having it specified explicitly) my vote is 'F::result_type', however, I still find another template parameter more appropriate for the following good reasons: o The function object can work fine with result_of in a non-'switch_' context. The cases can return different things as long as they are convertible to the result of 'switch_', and o there is no way to determine this type with 'result_of. Regards, Tobias

2 1

Re: [boost] Trac lists not all available libraries
by Daniel James 06 Jan '08

06 Jan '08

On 06/01/2008, Marshall Clow <marshall(a)idio.com> wrote: > I'll add accumulators to the trac system. Please can you add unordered as well. thanks, Daniel

2 3

[Interprocess] Interprocess' reference documentation overwritten by Boostbook's.
by Daniel James 06 Jan '08

06 Jan '08

Hi Ion, The main page of the Interprocess reference documentation is created at '/doc/html/reference.html' which is the same location as the Boostbook reference documentation. When the combined documentation is generated is gets overwritten by boostbook. So can you change the location it's generated at? Thanks, Daniel

1 0

Re: [boost] Switch library overloads of call operator
by dan marsden 06 Jan '08

06 Jan '08

Steven Watanabe wrote: >dan marsden <danmarsden <at> yahoo.co.uk> writes: >> The documentation is not specific about which specific type >> (e.g. mpl::int_<1> for case 1 matching in the >> underlying switch statement) is going to be used. >The type that is passed to f is whatever is in the list of cases. Ok cool. >> It looks to me like >> it would be convenient to overload >> operator() for each case I want to service, but this will be >> awkward to do without knowing the exact type >> that will be incoming. >> >> <snip> > >If multiple cases are not grouped together, I don't >see how it's an advantage to use my library vs. using a >plain old hand-written switch. Would you mind elaborating? I think you're probably right, my original suggestion that multiple overloads of operator() would be likely is probably wrong. I can only suggest handling special cases such as divide by zero for example, but I think my original suggestion may be a red herring. Cheers Dan ___________________________________________________________ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

2 1

Switch library overloads of call operator
by dan marsden 06 Jan '08

06 Jan '08

Hi Another question about the design / docs for the switch library under review. From what I understand switch takes a runtime integral value, uses a PP generated switch statement, and calls out using some sort of MPL integral constant to specify the switch case to be served. This is pretty cool, as we seem to be travelling back from runtime into compile time world. The documentation is not specific about which specific type (e.g. mpl::int_<1> for case 1 matching in the underlying switch statement) is going to be used. It looks to me like it would be convenient to overload operator() for each case I want to service, but this will be awkward to do without knowing the exact type that will be incoming. Otherwise I'm going to have to use enable_if or something to separate out the cases, which seems unnecessarily awkward. The example provided is fortunate that it behaves uniformly for each incoming value, so only 1 overload of operator() is required. IMO this will not be the common case, an example with differing behaviour would be helpful. I think the documentation could do with a bit of clarification in this area. Cheers Dan ___________________________________________________________ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

3 2

Re: [boost] Iostreams and Network [asio]
by Jonathan Turkanis 05 Jan '08

05 Jan '08

Hi JD, JD wrote: > And also, is there any attempt to write a Source/Sink to read and write > from shared memory? Currently there is http://www.boost.org/libs/iostreams/doc/classes/mapped_file.html. While I have been away from Boost, the Interprocess library has been accepted, providing sophisticated support for shared memory and memory mapped files. I am planning to write devices to access the functionality of the Boost.Interprocess for 1.36. > JD >> Hi, >> >> Iostreams documentation states: "For example, Boost.Iostreams can be >> used to create streams to access TCP connections". Is there any such >> attempt to create a TCP/IP communicating Source/Sink couple? >> I know asio is doing this, but I was looking for an pure Iostreams >> solution. Currently there are no devices for TCP/IP communications. I am planning to implement blocking TCP/IO devices using asio for 1.36, but I also hope at some point to achieve a better degree of integration. Standard iostreams are not a very good way to access network connections, since they are designed for blocking i/o; however, Boost.Iostreams is also intended as a framework for filtering, and I was careful to design filter concepts that would work with asynchronous and non-blocking devices. When Boost.Asio was proposed, I was looking forward to the possibility of introducing asynchronous and non-blocking device concepts to make the libraries work together, but unfortunately I became so busy that I was not able to participate in the review process or collaborate with Chris Kohlhoff in the subsequent development of the library. Now that I have more time I am committed to trying to make the two libraries work together as much as possible. >> Regards, >> >> JD -- Jonathan Turkanis CodeRage http://www.coderage.com

1 0

[iostreams] understanding the models
by Benjamin Collins 05 Jan '08

05 Jan '08

I'm trying to write a device for iostreams, but I'm having a hard time understanding how the current sources and the models explained in the documentation are in agreement. Maybe I'm shooting myself in the foot by never being able to work on this for more than 30 minutes at a time and having that 30 minutes be late at night, but... Anyway, it seems odd to me - for example, the boost::iostreams::mapped_file_source class has the following category of source_tag + direct_tag + closable_tag, and has member functions open(), size(), data(), begin(), and end(). None of these are particularly surprising. After all - a mapped_file has to be open()ed at some point. But under what model as defined in the docs? In other words, how and when is that function called, and how does a stream_buffer know he can call open() on a particular device? Also, the documentation indicates that a source device needs to support the read() function - but mapped_file_source has no read() (maybe because it is convertible to 'direct'?). -- Benjamin A. Collins <ben.collins(a)acm.org> http://bloggoergosum.us

2 1

[iostreams] Patch for latest CodeGear (Borland) compiler
by Nicola Musatti 05 Jan '08

05 Jan '08

Hallo, The patch in http://svn.boost.org/trac/boost/ticket/1294 improves support for the latest version of bcc32, 5.9.2 . If I don't receive objections in two or three days I'll apply it. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

2 1

build error during integration of serialization lib
by Arunava Saha 05 Jan '08

05 Jan '08

Dear Robert/experts, I am getting build errors after the integration of versioning in serialization lib. I have included the version.hpp. The following is the error msgs I am getting. Can someone please point me to the issue? FYI, everything is working fine except this versioning stuff. error: 'version' is not a template error: explicit specialization of non-template error: 'mpl' has not been declared error: ISO C++ forbids declaration of 'int_' with no type error: expected ';' before '<' token error: 'mpl' has not been declared error: 'integral_c_tag' does not name a type Thanks, Arunava.

2 1

[1.35.0] Intel compiler - does anyone care?
by Beman Dawes 05 Jan '08

05 Jan '08

The great bulk of remaining 1.35.0 release test issues are with the Intel compiler. See http://beta.boost.org/development/tests/release/developer/issues.html Does anyone really care about this compiler? Should we drop it from the high priority list? If there are folks who do care, perhaps they could suggest a plan to eliminate the failures, or at least shed light on why so many tests are failing. --Beman

9 20