- Boost - lists.boost.org

[integer] Type-safe and bounded integers with compile-time checking
by Leif Linderstam 07 Sep '11

07 Sep '11

Hi all, There are some integer libraries out there that improve on the fundamental integers; Boost.Integer, ACCU BoundedInt, part of The Boost Constrained Value library, and probably many other. They add the ability to specify an integer based on a range, they add bounds checking at runtime, or a combination of both. What I have not found yet though is a library that checks bounds at compile time. Me personally I would like to have the compiler check as much as possible. For instance, the compiler would complain about an assignment if the target's range is not a superset of the source's, unless an explicit conversion is made. Does anyone know of a library supporting this? If there is no such library I hope there is an interest in one and that this post will start a discussion about how it best can be done. The motivation for this kind of library is that its usage helps show the intent of the developer, and it can point out faults that otherwise even an extensive test suite might miss. That it forces the developer to thoroughly think about value ranges in computations I also regard as a point in favour. What about the type-safe part in the subject of this post? Even though most mistakes will be caught by the bounds checking, I believe there are situations where one wants to clearly state that an integer represents one specific concept and nothing else, for instance a numeric identifier. So I would like this kind of library to also support a kind of type-safety. I am not sure that that is the correct term for it, but what I mean is that when one declares a bounded integer it should be possible to state that it can not mix with other bounded integers regardless if the bounds are compatible. As I have been thinking about this for years now I of course have a lot of ideas on how to implement this. As a starting point for a discussion I would like to present some basic parts of what I have come up with. The integer type is declared as follows: template< typename Range, typename Tune = fast > struct integer; It takes a range type instead of taking the bounds directly. It also has a tuning parameter which is used when selecting the fundamental integer type to use for storage. The idea of having a separate range type is that it can be used for other types, see the array type below. The range type then: template< intmax_t Lower, intmax_t Upper, typename TypesafetyTag = defaultTypesafety > struct range_c; The bounds is no surprise, but here I add the type-safety part. I am not quit sure about this approach because the bounds and the type-safety mechanisms are orthogonal, but it works together quite well in practice I believe. Maybe it should not be named "range" but something else. The type-safety mechanism is fairly simple; two integers must have the same tag to be part of the same expression (unless a type-safety conversion is used). This means that they cannot be mixed with fundamental integers either. The default type-safety tag is special in that it allows for a mix with fundamental integers except that there is no implicit conversion or assignment to fundamental integers (this would otherwise provide a loophole). In practice fundamental integers do not work that well with the static bounded integers though, because most often the range is too big. Another type that seems fairly obvious is a static array (similar to Boost.Array): template< typename Range > struct array; The array of course is just as large as needed for the range. As subscript parameter it only accepts bounded integers with compatible ranges, i.e. with subset bounds and equal type-safety tag. Contrary to what is normal in C++ the array is not necessarily zero-based, it starts at the lower bound of the array. There is much more of course, for instance that the range type should take types instead of integers as bounds, but this post is getting too long already. As said before I hope this is going to be the start of a fruitful discussion. Sincerely, Leif Linderstam

4 12

[Boost][GSoC] Checks summary
by Pierre Talbot 07 Sep '11

07 Sep '11

Hello all, The Google summer of code gave me the opportunity to learn a lot, but overall I started to build another little part of the open-source world. This was a great experience for me. I'd like to thank my mentor, Paul A. Bristow for all the help he bestowed, Google and all the Boost members who gave me their opinions or advice. During this summer, I've started to build the foundation of a new library. It's only a prototype for the time being but I hope make it useful and powerful soon. The name of this library is "Checks", it currently implements one kind of check function: those used for catching human errors. For example, the famous ISBN has a check digit computed with all the characters. It exists few algorithms and a lot of number are based on well-known algorithm. This library should offer useful extending possibilities because there are so many that we can't implement every type of checks for a Boost library. I've implemented and written the following contents : * Basic check algorithms ( Luhn, Mod11, Verhoeff, ...). * Start to write a test suite that should facilitate the measurement of efficiency of the check algorithms (number of alterations, transposition, ... detected). * Write some sanity tests for the functions implemented (using Boot.Test). * Documented the functions already written and start a "global" documentation of the parameters that affect the efficiency of each algorithms. This library is absolutely not finished but can be used for simple verification or computation of check digit. I would like to improve and even-fuller-document this library before a Boost review. The code, tests and documentation can be found at https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/ and here are a direct links to the documentation in html https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/libs/checks/doc/htm… and as a single pdf file https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/libs/checks/doc/che… (Sadly the Doxygen comments documenting the (many) template parameters are not displayed correctly in the C++ reference section (due to a buglet in the toolchain), so for now you may need to consult the header files to read the C++/Doxygen \tparam comments. Meanwhile, you can also consult the Standalone Doxygen documentation at https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/libs/checks/doc/dox… Or you can rebuild the Standalone Doxygen documentation using the Doxywizard and https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/libs/checks/doc/dox… If you have any comments or suggestions, please do not hesitate to contact me. Cordially, Pierre Talbot.

1 0

Re: [boost] [interest] URL (John Ratcliffe)
by john＠firecrest.eclipse.co.uk 07 Sep '11

07 Sep '11

From: Dean Michael Berris Date: Tue, 6 Sep 2011 22:34:19 +1000 > This project (cpp-netlib) is already submitted for review to Boost, > but is still under heavy development. I've already had some offline > arrangements for a review manager, but now it's a matter of scheduling > for when the formal review should be held. > Needless to say it follows much of the Boost conventions and rely > mostly entirely on Boost libraries. And if I'm brave enough I just > might think about submitting the library interfaces to the ISO C++ > Committee through the Library Working Group. :D > I hope this clarifies things. Yes thanks. I noticed the boost namespace and wondered. It looks and sounds well advanced. I would like to get involved but is there anything a new hand can contribute at this stage? Cheers John Links: ------ [1] mailto:mikhailberis@gmail.com

2 1

Intel TBB or Microsoft PPL like Boost library
by Brendon Costa 07 Sep '11

07 Sep '11

Are there any libraries for boost proposed, accepted or in progress that are similar to the Intel Threaded Building Blocks library or the Microsoft Parallel Patterns Library? I did not see any in the official library list and dont remember hearing about any in this mailing list. Such a library could be very useful (well I could use it right now :-) )

2 1

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