- Boost - lists.boost.org

Bug in signals library
by Алексей Суббота 06 May '04

06 May '04

There is bug at boost/signals/detail/config.hpp: Before #ifdef BOOST_HAS_DECLSPEC must be #include <boost/config.hpp> Without it line dll's version does't export nothing.

2 1

[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