- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-949189 ] typos in wrapping_int.hpp
by SourceForge.net 06 May '04

06 May '04

Bugs item #949189, was opened at 2004-05-06 15:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=949189&group_i… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pieter (morban) Assigned to: Jeff Garland (az_sw_dude) Summary: typos in wrapping_int.hpp Initial Comment: In the following code: template<typename int_type_, int_type_ wrap_min, int_type_ wrap_max> class wrapping_int2 { public: typedef int_type_ int_type; static unsigned long wrap_value() {return wrap_max;} static unsigned long min_value() {return wrap_min;} ... the last two lines should probably read (changing return types and the first function's name): static int_type max_value() {return wrap_max;} static int_type min_value() {return wrap_min;} May I suggest renaming this class to "top_wrapping_int" in reaction to the comment above it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=949189&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Formal review] Collection Traits library review ends tomorrow
by hartmutkaiser＠t-online.de 06 May '04

06 May '04

Hi all, Just wanted to remind you, that the formal review of the Collection Traits library written by Thorsten Ottosen ends tomorrow, May 7th, 2004. Please submit your reviews until then, if you haven't already. Regards Hartmut Review Manager

1 0

Re: [boost] Re: Re: Using Serialization for binary marshalling
by brangdon＠cix.compulink.co.uk 06 May '04

06 May '04

In-Reply-To: <95C853D0-9EAF-11D8-BFD9-000A95DC1C98(a)itp.phys.ethz.ch> troyer(a)itp.phys.ethz.ch (Matthias Troyer) wrote (abridged): > As I see it the current serialization library allows both options, > depending on your preferences. Any archive may choose which types it > view as fundamental, but both have their disadvantages: I would use variable length integers. Use as many bytes as you need for the integer's actual value. That way the archive format is independent of whether short, int, long or some other type was used by the outputting program. It can also give you byte order independence for free. Specifically, I'd use a byte oriented scheme where the low 7 bits of each byte contribute to the current number, and the high bit says whether there are more bytes to come. void load( uintmax_t &result ) { result = 0; while (true) { unsigned char byte; *this >> byte; result = (result << 7) | (byte & 0x7f); if ((byte & 0x80) == 0) return; } } Thus integers less than 128 take 1 byte, less than 16,000 take 2 bytes etc. This gives a compact representation while still supporting 64-bit ints and beyond. You can use boost::numeric_cast<> or similar to bring the uintmax_t down to a smaller size. -- Dave Harris, Nottingham, UK

4 4

Re: static sized strings
by John Nagle 06 May '04

06 May '04

Reece Dunn wrote: > There is currently a static-sized array in the Boost library that allows > you to operate on arrays of fixed size. I was wondering if something > similar exists for strings, in particular, providing buffer-overflow > safe string operations. > > I have an nstring< std::size_t n > string class that provides size-safe > copying and comparison, allowing for you to do things like: That's an excellent direction in which to be moving. How far can we go in replacing unsafe C strings? With the endless reports of buffer overflow exploits, anything that can be done in that direction would help. I'd suggest a class with the following properties: Fixed-allocated strings, with length information. No calls to "new". Supports most of the operations allowed for STL strings. Also supports the "classic" C string operations, like "sprintf", "strlen", etc., using the classic C syntax for them. Implicit conversion to "const char*", but not "char *", for compatibility with existing library calls. Fully protected against overflow. It might also be worthwhile to provide "sprintf", "strlen", etc. for STL strings. The basic idea is that this should be retrofittable to old code without major efforts. Ideally, you go through the code with a program, replacing "char foo[nnn]" with "char_array<nnn> foo", and "char *" with "char_array&", and it mostly works. Everything that doesn't work gets a compile-time error. You fix all the compile time errors, and your program is overflow-proof, at least in this area. John Nagle Team Overbot

1 0

Re:[boost] Re: Re: Re: Using Serialization for binary
by Robert Ramey 06 May '04

06 May '04

Ian McCulloch wrote: > > Dave Harris wrote: > > > In-Reply-To: <95C853D0-9EAF-11D8-BFD9-000A95DC1C98(a)itp.phys.ethz.ch> > > troyer(a)itp.phys.ethz.ch (Matthias Troyer) wrote (abridged): > >> As I see it the current serialization library allows both options, > >> depending on your preferences. Any archive may choose which types it > >> view as fundamental, but both have their disadvantages: > > > > I would use variable length integers. Use as many bytes as you need for > > the integer's actual value. That way the archive format is independent > of > > whether short, int, long or some other type was used by the outputting > > program. It can also give you byte order independence for free. > > > > Specifically, I'd use a byte oriented scheme where the low 7 bits of > each > > byte contribute to the current number, and the high bit says whether > there > > are more bytes to come. > [...] > > Thus integers less than 128 take 1 byte, less than 16,000 take 2 bytes > > etc. This gives a compact representation while still supporting 64-bit > > ints and beyond. You can use boost::numeric_cast<> or similar to bring > the > > uintmax_t down to a smaller size. > > Nice idea. I was thinking along the lines of how to achieve > high-performance, with shared memory & fast network message passing in > mind. I think now though, this is probably too specialized an application > for boost::serialization. > That's the way it's done in demo_portable_binary_archive included in the current serialization package. Robert Ramey

1 0

signals and threads
by David Abrahams 06 May '04

06 May '04

So, we're thinking of using the signals library in one of our projects, but the lack of thread-safety is a concern for us. What issues are preventing Boost.Signals from being made threadsafe? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 6

pool_alloc with Pair Associative Container?
by Thomas 05 May '04

05 May '04

Can someone give me an example of how to use the boost pool_alloc allocator interface with a Pair Associative Container, like hash_map? I tried doing something like typedef hash_map<long long,double,longLongHasher,boost::pool_allocator< pair<const long long,double> > > tLongLongToDoubleHashMap; ,,,but I get errors when I try to compile code that actually uses tLongLongToDoubleHashMap. Thanks! Thomas -- Thomas <hazard(a)imsa.edu>

1 0

[Boost-bugs] [ boost-Bugs-948785 ] lambda doesn't overload deref op correctly
by SourceForge.net 05 May '04

05 May '04

Bugs item #948785, was opened at 2004-05-05 13:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=948785&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lambda doesn't overload deref op correctly Initial Comment: The dereference operator overload for lambda fn params seems to assume that the argument is an iterator. This precludes easy dereference of UDTs and smart ptrs. Thanks Bill Somerville bill(a)classdesign.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=948785&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Re: Re: Spirit and typeof [was typeof]
by Reece Dunn 05 May '04

05 May '04

Arkadiy Vertleyb wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote > > > One question though: I have a parser where I have created several >external > > grammars to help modularize the grammar and employ the trick suggested >in > > the techniques section (c.f. sub-grammar): > > > > [snip] > > Once you have a (sub-)rule like this, you can use it like: > > > > rule_t<ScannerT> tagName = !( identifier >> ':' ) >> identifier; > > > > I was wondering if this would cause any major problems when implemented >with > > the typeof/auto hack (since it could then be implemented as a grammar). > >I think you would just have to register your identifier_parser class. The >typeof system then would treat it as an atom and not care what is behind >it. This was what I was thinking. But is there a way of handling the grammar template as a special case, e.g.: template< typename T > class deduce_type { typedef ... type; }; template< typename DerivedT > class deduce_type< boost::spirit::grammar< DerivedT > > { typedef DerivedT::type type; }; I am not saying that this is what it will look like as I am not up to speed with your typeof mechanism, but if something similar could be implemented, it would make custom grammars more powerful (may even reduce the number of types that need explicit registration). Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

Re: RE: [boost] Re: Using Serialization for binary marshalling
by Robert Ramey 05 May '04

05 May '04

Brian Braatz wrote: > Question- I was just looking for clarification. Does the boost > serialization library allow me to have objects on different platforms > stream to each other? Yes. However, the archive must be designed to be platform independent. This is a little bit more subtle than it would first appear. For example, consider the text archive. It stores all numbers as text delimited by spaces. That's portable. But suppose a machine which uses an 80 bit IEEE double stores a high precision value to an archive. Another machine that reads the archive might only have a 64 bit double. So, some of the original precision would be lost. Of course the original value would have been preserved to the extent possible on the new machine. Even here, moving to an ebcdic machine would require a custom codecvt facet which is not in library. Is this "portable"? You be the judge. Within the limitations of the above, text and xml archives can be considered portable. The binary archive is really "native binary" in that it doesn't make conversions for integer size or endianness. (It does check that the endianness and integer size are the same on the saving and loading machines so it might be portable between some pairs of machines). In general the binary archive should be considered non-portable and not suitable for archives meant to be transferred from non identical architectures. There has been lots of interest in making an XDR and CDR archives. I really haven't considered issues in using XDR or CDR. I don't know whether these are just standards for encoding low level types or describe a whole protocol. If it's the former, it would be pretty simple implement. Otherwise, we have the problem of matching the serial representation of some arbitrary C++ structure with some externally defined protocol. Though it might be possible in certain cases, this is not something that the serialization system has been designed to do. http://lists.boost.org/MailArchives/boost/msg63695.php The package includes a "portable" archive as a demo. It doesn't include code for floats and longs. The portable archive includes a lead byte for each integer indicating the number of bytes required to hold the value. If the integer doesn't "fit" in the loaded type, an exception is thrown. The usage of boost::uint_16 etc. doesn't have to be explicitly considered. I didn't have good method for handling floats and doubles across machine architectures. Now that I have suitable code for handling portable floats/doubles, (http://lists.boost.org/MailArchives/boost/msg63672.php) I might think of promoting portable_binary_?archive to a first class supported archive. It would be complete and general, but depend on the serialization library being implemented on the "other" machine. Not an unreasonable restriction in my view. For those who must have CDR/XDR I have no final answer. Robert Ramey

3 4