- Boost - lists.boost.org

[OT][fsm] I'm overwhelmed
by Andreas Huber 29 May '04

29 May '04

Dear Boosters I'm pretty much overwhelmed by the sheer volume of posts. I will try to answer every post during the weekend, but I cannot guarantee that I will not miss one or the other. If, by Sunday night you still have no answer/statement to a post you made before Saturday night then please repost your question. Thank you, Andreas

2 1

MPL for_each
by Mohammed Iqbal 29 May '04

29 May '04

Where is the documentaion of for_each? Mohammed

1 0

Re: [boost] Re: static sized strings
by Reece Dunn 29 May '04

29 May '04

Rob Stewart wrote: >From: John Nagle <nagle(a)overbot.com> > > (And you have to supply conversions.) Most strings are sized a bit too > > big, anyway. > >Oh, it just occurred to me that when the two have the same size, >there should be a cctor and copy assignment operator to avoid the >virtual function call overhead. The cctor also fixes a bug that caused a pure virtual function run-time error with VC when you have the following: template< size_t n, class C, class CSP > inline fixed_string< n, C, CSP > runtime_error() { fixed_string< n, C, CSP > res( "oops!" ); return( res ); // pure virtual call here } Thanks! >You might even be able to do >some metaprogramming to determine whether the capacity of the >source string is less than or equal to the capacity of the >destination string and avoid the virtual function call overhead >for an entire class of copies. I'll look into this. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

metacomm regressions: which borland version
by Vladimir Prus 28 May '04

28 May '04

The metacomm regression result show an error for borland compiler: http://tinyurl.com/2ql6s which reads: Assertion failed ..... config_file.cpp(144) : isTmplSpecSym(sym) .... I've just installed CBuilderX Personal, and tried to compile the library with that compiler. The interesting thing is that compiler has 5.6.4 as version string, the symbol __BORLANDC__ is defined to be 0x0564, but I don't get that error, and get some other errors. What could be the reason? - Volodya

2 3

RE: Manaed C++ (was: [boost] Re: Re: [prereview request][fsm])
by Randy Bowen 28 May '04

28 May '04

> The next version of managed C++, circa 2005, has promised > support for C++ templates. > This is probably getting off topic for Boost, but: Are you sure on this point? My understanding was that there would be general support for "generics" in managed languages, but that this is specifically not the current the C++ template mechanism. Randy Bowen Stamps.com

5 5

RE: [boost] static sized strings
by Reece Dunn 28 May '04

28 May '04

Martin wrote: >Not sure what the problem is but construction or assigment from operator+ >doesn't work int VC++2002. > >boost::fixed_string<20> xxx, yyy, zzz = xxx + yyy; > >gives the following error >[snip] The problem is that I need operator+ overloads for fixed_string: the obes for basic_string_impl will not work! I shall have a fix posted shortly. >And another thing: > >One of the find overloads doesn't check the pos argument so it might create >an >endless loop. > >inline size_type find( char_type c, size_type pos = 0 ) const { > const_iterator last( end() ); > for( const_iterator first( begin() + pos ); first != last; ++first ) Thanks! This has been corrected. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

Should std::allocator::rebind be used with std::map?
by Andreas Huber 28 May '04

28 May '04

Dear Boosters Some old implementations of std::allocator don't provide the rebind member template (e.g. MSVC6.0 stdlib). This keeps code as the following from compiling: typedef std::map< const state_base_type *, event_queue_type, std::less< const state_base_type * >, typename allocator_type::template rebind< // *** here *** std::pair< const state_base_type * const, event_queue_type > >::other > deferred_map_type; However, this map will internally not allocate objects of the type std::pair< const state_base_type * const, event_queue_type > anyway but rather of some implementation-defined tree node type. So, the above typedef could also be written as follows, ... typedef std::map< const state_base_type *, event_queue_type, std::less< const state_base_type * >, allocator_type > deferred_map_type; which should work with just about any implementation of the std library, as long as the used container is a list, (multi)set or (multi)map. Now, the questions are: - Does the standard allow the second variant (I haven't found anything pro or contra)? - Even if the standard does not allow it or is silent on it, would anyone bother to write the technically more correct first variant? If yes, even at the expense of making the code compileable on fewer compilers (or having to clutter the code with more #ifdefs)? Thanks & Regards, Andreas

4 7

Re: [boost] Re: static sized strings
by Reece Dunn 28 May '04

28 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > John Nagle wrote: > > > The big question is whether the size specified in the > > >declaration (as in "char_string<80>") includes the > > >trailing null. > > > > > I have modified the sandbox implementation to make it easy to switch >between > > the two models; it is currently using the 2nd model (adding space for >the > > null). One possibility is putting the choice of models as a template > > parameter (e.g. bool need_null -- see comments in the sandbox code for >an > > implementation), that way the decision is up to the programmer and not >the > > library implementor. > >This is overkill. I think you misunderstand what I am trying to say. See my comments below. >The purpose of fixed_string is to replace >arrays of characters, otherwise, std::string would be the right >replacement, right? correct. >Given that assumption, look to the syntax you're replacing: > > char s[] = "1234567890"; > assert(10 == strlen(s)); > size_t const LENGTH = 3; > char t[LENGTH + 1]; > strncpy(t, "ABCEFGHIJKLMNOP", LENGTH); > assert(LENGTH == strlen(t)); > >Now do the same with the new class: The equivalent would be: fixed_string< 15 > s( "1234567890" ); // [1] assert( 10 == strlen( s )); // C-style assert( 10 == s.size()); // C++-style const size_t LENGTH = 3; fixed_string< LENGTH > t; // [2] t = "ABCEFGHIJKLMNOP"; assert( LENGTH == strlen( t )); // C-style assert( LENGTH == t.length()); // alternate C++-style [1] You need to specify the size of the buffer. You cannot declare an object of type fixed_string_base (as it is abstract), you can only have references and pointers to it so you can operate on variable-capacity strings. [2] This is the point that we are discussing. Should this line be: fixed_string< LENGTH > t; as will work with the current sandbox implementation (my suggestion #2), or should it be: fixed_string< LENGTH + 1 > t; as in my suggestion #1. The code calculates the correct storage and capacity values at the top of the fixed_string class, because buffer overrun checks rely on these values: template< size_t n, typename CharT = char, class CharStringPolicy = std::char_traits< CharT > > class fixed_string: public fixed_string_base< CharT, CharStringPolicy > { BOOST_STATIC_CONSTANT( size_t, storage_c = n + 1 ); // = needs_null ? n + 1 : n BOOST_STATIC_CONSTANT( size_t, capacity_c = n ); // = needs_null ? n : n - 1 // ... }; Different programmers favour the different semantics, so I ask: why not parameterise it, providing a default behaviour. >(I know there is no make_fixed_string() -- yet -- but such a >facility would be appropriate.) Er... the fixed_string constructors! When you declare the object, you should know the size of the buffer you are using, e.g.: fixed_string< 100 > data; but when operating on them, you want to use any capacity buffers, so you either need a template (not good for existing code or code that needs to be in a static/dynamic library), so you use fixed_string_base, or [w]char_string if you want to save typing :). E.g. inline size_t strlen( const char_string & s ) { return( s.length()); } >I think this clearer reveals that fixed_string's size parameter >should specify the number of characters. Remember, one can use >boost::array to manage a fixed size, non-string buffer. If >buffer overrun protection is insufficient in boost::array, that >should be fixed (or a new class should be added to Boost). Thus, >fixed_string can ignore that usage. This is not what we are discussing. See above. The need_null name was to indicate that an extra charcter be reserved for the null, not whether to add a null terminator or not. Sorry for the confusion. I have started work on documentation, but it is currently in text form. I will post the documentation in BoostBook format within the next day or so. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

3 3

RE: [boost] input_iterator_facade (was: Re: [iterator facade] Why is dereference const?)
by Rozental, Gennadiy 28 May '04

28 May '04

> I still don't understand which design, yours or mine, is better. It seems mine > allows to create iterators with smaller number of lines, but maybe there's > something else. Why do you think so? I would say vice versa, since I do not require constructor in derived class to call found_eof(). Gennadiy.

3 3

RE: [boost] Re: static sized strings
by Reece Dunn 28 May '04

28 May '04

John Nagle wrote: >Reece Dunn wrote: >>Different programmers favour the different semantics, so I ask: why not >>parameterise it, providing a default behaviour. > > As with "do we null-terminate", I think we have to pick a >behavior and stick to it. I could live with either set of >semantics, but adding a parameter makes the issue more confusing. >(And you have to supply conversions.) Most strings are sized a bit too >big, anyway. Ok. I'll stick with the existing "add an extra character for null", since there seems to be more people wanting that style semantics. > On a related subject, we should have unconditional null termination. >"fixed_string" items are always null-terminated. "snprintf", >"strncat", etc. have hazardous semantics: if you overflow the string, >it is not null terminated. (This is a bug in my >current version, incidentally.) We should guarantee null >termination in all cases. The whole point of this >class is improved safety, after all. My implementation ensures this. If it does not, then it is a bug. Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

1 0