- Boost - lists.boost.org

Re: [boost] [interest] URL
by john＠firecrest.eclipse.co.uk 06 Sep '11

06 Sep '11

Hi Glyn Date: Mon, 5 Sep 2011 10:14:28 +0200 From: Glyn Matthews On 4 September 2011 21:36, John Ratcliffe wrote: > Is there any interest in a URL library along the lines of the Java one? > > http://download.oracle.com/**javase/1.5.0/docs/api/java/**net/URL.html [3] > > I'm currently working on a URI class as part of the cpp-netlib project: https://github.com/cpp-netlib [4] The parser already implements RFC 2396 and RFC 2732. There is still a lot of work to be done and, if you're interested, we'd be happy to accept contributions. Thanks for the response. I took a quick look and I am interested. I will take a closer look. What areas need attention? How does this project relate to boost? John Links: ------ [1] mailto:glyn.matthews@gmail.com [2] mailto:john@firecrest.eclipse.co.uk [3] http://download.oracle.com/**javase/1.5.0/docs/api/java/**net/URL.html%3Cht… [4] https://github.com/cpp-netlib

2 1

[Submission] RawMemory
by Adder 06 Sep '11

06 Sep '11

Dear Boost Community, I would like to submit a very modest addition to Boost... It is called "RawMemory": http://adder.iworks.ro/Boost/RawMemory/ <<It supports safe, efficient and portable (all in one) transfer of multi-byte integer values to/from "untyped memory" (also known as "arrays of bytes") (also known as "raw memory"). It handles the little endian and big endian representations and various memory transfer modes (e.g. to support aligned and unaligned data with good performance). Therefore, it can be useful to any application dealing with binary data formats (e.g.: bitmap images, network packets, serialized data structures).>> Thank you so... (-: -- Yours truly, Adder

3 3

painless currying
by Eric Niebler 06 Sep '11

06 Sep '11

After playing around with functional languages, I've come to envy how easy they make it to curry functions. Call a 2-argument function with 1 argument and you get a function that takes 1 argument. Pass another argument and it evaluates the function. Simple. In contrast, C++ users have to use binders, which are not as nice. On a lark, I implemented a wrapper that turns any TR1-style function object into a "curryable" function object (attached). Successive function call invocations bind arguments until enough arguments are bound to invoke the wrapped function. With it you can do the following: curryable<std::plus<int> > p; auto curried = p(1); int i = curried(2); assert(i == 3); Is there any interest in such a thing? -- Eric Niebler BoostPro Computing http://www.boostpro.com

26 93

[serialization] between 32 bit and 64 bit
by Jinqiang Zhang 06 Sep '11

06 Sep '11

I'm using boost.serialization for part of our messaging solution. Now here comes a problem: we want to communicate between 32bit and 64bit, is there a chance that using "text archive" would solve the problem ? jinqiang Zhang

3 3

[endian] comments
by Gordon Woodhull 05 Sep '11

05 Sep '11

Hi Beman, all, Couple of comments after scanning the documentation. It does look like a solid library but the Hello World example in the documentation appears to be out of synch with the code, and with Boost. None of its includes are correct (except iostream). It looks like the operator<= overloading (?) is intended to invoke some binary stream functionality which isn't yet in Boost. Unfortunately I wasn't able to get it to compile because I couldn't find <boost/binary_stream.hpp> anywhere. There appears to be some related detail::binary_data stuff in endian/boost/io/detail/bin_manip.hpp but I couldn't figure out how to connect it. An unrelated comment: on the "conversion functions" page of the documentation, there are some references to "indicated byte ordering" - which confuses me because I don't see where the byte ordering is indicated. Does this mean the ordering which Endian uses internally? Cheers, Gordon

2 1

[variant] Constructible/assignable from anything
by Agustín K-ballo Bergé 05 Sep '11

05 Sep '11

Boost variant has a constructor and an assignment operator that would take just anything. If it cannot be converted to any of its bounded types, it will result in an error within variant's internals. This, mixed with conversion operators, interferes with overload resolution (code that reproduces the issue attached). Would SFINAE'ing out the non-candidate constructors (and assignments) fix this? Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com

2 2

[interest] URL
by John Ratcliffe 05 Sep '11

05 Sep '11

Is there any interest in a URL library along the lines of the Java one? http://download.oracle.com/javase/1.5.0/docs/api/java/net/URL.html John Ratcliffe

2 1

[review] Conversion review starts today
by Gordon Woodhull 04 Sep '11

04 Sep '11

Hi All, The review of Vicente Botet Escriba's Conversion library starts today and ends August 29. The Conversion library manages generic explicit conversion between unrelated types. It can be thought of as a substitute for overloading static_cast, or as an alternative to lexical_cast when conversion via text is unwanted. The code is available here: http://svn.boost.org/svn/boost/sandbox/conversion/ And the documentation is here: http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h… Alternately, you can download a compressed package here: https://github.com/viboes/TBoost.Conversion Reviews may answer the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Of course, "informal reviews" and discussion are also welcome. Cheers, Gordon Woodhull Espen Harlinn

6 12

[serialization] deserializing asynchronously serialized types
by Andrew Hundt 04 Sep '11

04 Sep '11

I have an unusual use case for boost.serialization, and I was wondering if it would be possible to adapt it to my needs: - I have a set of over 100 types, and instances of each are generated asynchronously then serialized to a file in that order. - The most interesting serialized data will be written just before the power is unexpectedly cut. - I need to load in and run on as much data as possible when reading the serialized data back, ignoring incomplete data at the end (due to a power cut). - The basic Boost serialization examples require you to know the type of the next piece of data to be loaded when reading. Since these types are generated asynchronously they are not known in advance. - I need to write the data out immediately when it arrives because of the power issue. - Files will be getting up to around 150GB in size for binary archives, so it can't be marshaled in memory, it needs to be written immediately even if it is redundant. Is there a way to read in that serialized file using the facilities provided in boost.serialization? Here are my current ideas: - I tried using boost.variant, but it loses its will to compile when I increase the typelist limit to around ~60 types on gcc 4.4, and I have more than a hundred. - Use preprocessor metaprogramming to do something equivalent to boost.variant, but I would very much prefer a more pleasant option. - Serialize an index or custom headers indicating the next type to appear - One way of achieving some of these goals is writing one piece at a time using a binary archive to an fstream, with the index mentioned above separating data types. I don't know what aspects of my requirements will prove to be a problem, so if anyone can provide advice that would help me avoid a major pitfall, it would be greatly appreciated. Thanks for your thoughts. Cheers! Andrew Hundt

2 1

[conversion] review
by Gordon Woodhull 03 Sep '11

03 Sep '11

Hi all, Here is my review of the Conversion library. I like the idea of a uniform configurable casting operator, whether it's called convert_to, static_cast, convert_cast, or extrinsic_cast. If I had to write a conversion function, I would rather write it as an overload of a general-purpose converter, rather than giving it some ugly typeA2TypeB name. And I would rather find out what header to include and use a generic function rather than using such some specific name. I vote to accept the library (although obviously as Review Manager I'll follow the wishes of all reviewers). Part of the reason I took on the challenge of managing this review is that the library is something people don't know they need. I think uniformity of interface is a good enough reason to use the library, but when would you need a truly generic conversion function as this library offers? Or more to the point, what does it mean to have a "shadow conversion space" for types that don't know about each other? We would hope that libraries are generic enough so that their types can be adapted to work with each other (prime example: Polygon & Geometry). But it's the sad truth that most libraries are not designed this way, and any non-header library can't be designed this way. So that's where Conversion steps in to make combining those libraries cleaner. As we've already discussed, the Achille's Heel of this library is that it requires all compilation units to agree on what conversions they will use, to avoid ODR violations. In practice this probably means that users would have to maintain their own conversion setup headers, which is annoying. But it's hard to imagine an openly configurable global utility that doesn't suffer from some version of this problem. John Bytheway's suggestion of tagging libraries with type keys is an interesting idea. I think Vicente also mentioned the possibility of a scheme that would cause linker errors instead of ODR violations, which would be an improvement. (FWIW I suggested something involving #error but of course that would only work within a CU.) In my mind it is very clear that a templated function<T>(x) will probably return a T and I don't find it necessary that the proposed function has to use the preposition "to". But that's because I'm very aware that the explicit template argument must be the return type, which is understandably not clear to everyone. While the recursive features of this library look interesting and useful, I wonder if there isn't a more general way to do this. I keep thinking it's an awful lot like fusion::copy or Marsden's Traversals. Well, that's enough for now. I hope later today to post summaries of some comments I received off-list and maybe get those people to join the conversion. (You know who you are!) Cheers, Gordon

7 16