- Boost - lists.boost.org

Re: [boost] [Submission] RawMemory
by Joe Mucchiello 07 Sep '11

07 Sep '11

For a library designed to deal with the weirdness of binary file formats, I'm surprised it does not support 24-bit integers of arbitrary alignment/sign. > uint32_t x = raw_memory <uint32_t, big_endian>::peek (&vbBuffer [5]); Do you also support a non-template "endianness" parameter? Sometimes you don't know the endian-style of the file until you open it and read some value out of it. Joe

1 0

[chrono] Build Jamfile missing three source files
by Beman Dawes 06 Sep '11

06 Sep '11

--- c:\temp\Jamfile.v2-revBASE.svn000.tmp.v2 2011-09-06 15:23:30.000000000 -0400 +++ c:\boost\trunk\libs\chrono\build\Jamfile.v2 2011-09-06 15:23:19.000000000 -0400 @@ -74,16 +74,16 @@ <toolset>gcc-3.4.4:<linkflags>--enable-auto-import <toolset>gcc-4.3.4:<linkflags>--enable-auto-import <toolset>gcc-mingw-4.4.0:<linkflags>--enable-auto-import <toolset>gcc-mingw-4.5.0:<linkflags>--enable-auto-import ; -SOURCES = chrono thread_clock process_cpu_clocks ; +SOURCES = chrono thread_clock process_cpu_clocks run_timer run_timer_static process_clock ; lib boost_chrono : $(SOURCES).cpp : <link>shared:<define>BOOST_ALL_DYN_LINK=1 # tell source we're building dll's <link>static:<define>BOOST_All_STATIC_LINK=1 # tell source we're building static lib's ; OK to commit? --Beman

2 3

Re: [boost] [contract] syntax redesign
by Andrzej Krzemienski 06 Sep '11

06 Sep '11

> This use case is different then the above (more compelling). The > issues here is that when programming contracts you quickly start using > extra checks (and especially ==) which add additional requirements on > generic types. For example, in this case T does not have to be > EqualityComparable to program the body but you still want to program > and check the postcondition when T happens to be EqualityComparable. I > have been thinking to solve this issue by providing: > namespace contract { > temlate< typename T> > bool equal(T const& left, T const& right) ... > } > equal will return true if T is not EqualityComparable and left == > right if T is EqualityComparable. That way you can program the > contracts using contract::equal(x, y) without introducing additional > requirements on T at all but still checking the contract conditions > for EqualityComparable types. I will also expand equal to handle > containers (compare all elements of a vector, etc) and I will provide > similar functions for other operations. All of these contract helper > functions will be in a separate header <contract/utility.hpp>. I have > not started to implement this yet. To me, this problem with equality indicates that Boost.Concept already proves useful, as it explores practical aspects of implementing DbC in C++ and its interactions with other C++ features. > BTW, I am also wondering if it would be useful to implement a fully > contracted version of the STL probably in contract::std: > #include <contract/std/vector.hpp> > #include <contract/std/algorithm.hpp> > contract::std::vector<int> v; > contract::std::for_each(v.begin(), v.end(), ...); > I think Boost.Contract can essentially implement most/all of the > interface contracts (preconditions, postconditions, invariants, and > concepts) documented by the SGI: > http://www.sgi.com/tech/stl/<http://www.google.com/url?sa=D&q=http://www.sgi.com/tech/stl/&usg=AFQjCNHIn…> > Would such a contract::std be any useful? This is a fair question. And probably best answered by the authors of contract programming proposal for C++. What ISO C++ Committee did with nearly every new language feature (concepts, auto, noexcept, constexpr, initializer_list) was to also use it in library in order to (i) prove that the future is usable, (ii) give a solid example of how the feature should be used. So, along this reasoning, there are good reasons to do it. I can see, however, also valid reasons against it: Boost only recently approved STL containers library rewrite: Boost.Containers ( http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h…) It already has Boost.PointerContainer (although it serves a different purpose it may be distracting that they are defined and described separately). so now, each time I use a container I will have to decide if I am using std::vector or boost::container::vector. Now if I need to consider a third option boost::contract::stl::vector it really gets hard. And would they all interoperable with one another? Perhaps if the contracts were implemented in Boost.Container, but then... I expect that Boost.Contract syntax may discourage some Boost users, that just want to use (and perhaps debug) Container library. Overwhelming them with the new syntax might discourage them from using Boost.Container. If you implement your containers separately, it is likely that they will just not be used. Difficult to say... Regards, &rzej

2 1

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