Re: [boost] [Review] Fixed Strings library

From: Andy Little (andy_at_[hidden])
Date: 2006-01-27 19:52:05

"Reece Dunn"  wrote
> Andy Little wrote:

>>I would prefer a lot more detail on the functionality of fixed_string. What
>>happens on overrun for example? Is it mentioned?
>
> On overrun, the string is truncated to prevent the overrun happening. It is
> mentioned in the docs, although not explicitly. Something like:
>
>   fixed_string< 5 > str = "123456789";
>   std::cout << str << std::endl; // output: 12345

Is there a way to change this behaviour. I would have expected that  it would
throw an exception on overrun. In a lot of cases the end result of truncating
the string is going to be an error, so I'm surprised that isnt an option. OTOH I
see that one of the uses is to prevent buffer overrrun at the hands of malicious
users so I can see the reason for the policy. The problem with this is that (as
I understand it) the fixed_string isnt actually fixed in size, so its a bit more
susceptible to malicious users than a string with const size. Nevertheless I
think that contrasting how fixed_string  and a char array withstand attacks at
the hands of malicious users would make a good useage example. That alone would
be a good reason for its existence.

[...]

> An early version of the library just used fixed_string< N >, so if you
> wanted to write a function that operated on *all sizes* of fixed_strings,
> you would need to do:
>
> template< int n >
> int strlen( const fixed_string< n > & str )
> {
>   return str.length();
> }
>
> however, one of the early commenters of the library during development
> wanted to do that without templastizing the function for the size.
> Therefore, you can now write:
>
> int strlen( const char_string & str )
> {
>   return str.length();
> }
>
> where char_string is a typedef for the variable-capacity base class that
> fixed_string< n > uses.

I'm confused as to why fixed_string  needs the size template parameter at all if
its derived from a variable capacity string and can be resized. The main
advantage of the size template parameter would be speed I guess, as well as
offering good optimisation opportunities to the compiler because of its fixed
size, but some of that would surely be lost as soon as the size is changeable.
OTOH I may have the wrong end of the stick, however the documents dont really
help me much. As I understand it if I declare

fixed_string<10> fs;

then some time down the line fs might actually have a capacity of 20 characters.
Is that correct? If so I would say just simply do away with the size template
parameter altogether as its downright confusing. Either that or make
fixed_string have immutable size.

>>Formatter. Why does formatter need to be a policy? Cant it be a separate
>>entity
>>to fixed_string? What is relation  (if any) to boost::format. Maybe though
>>fixed_string formatter is another library to fixed-string?  Could
>>fixed_string
>>use boost::format interface? Documentation doesnt  seem to have details on
>>formatter input
>
> The format_policy contains a vsprintf-style method called format that you
> can replace with whatever you want. The library provides the C API version,
> but you could replace this with the Win32 API version, or FormatMessage, for
> example. The fixed_string class uses this to create a format method, so you
> can call this directly on the fixed_string object. It uses this method to
> implement the sprintf functionality.

I'm trying to understand why I dont have a sequence  of characters in one object
and a means of formating it in another.

> This is not related to boost::format, but printf. If you create a format
> policy for FormatMessage, you could have something like:
>
>   std::cout << format_message( "Hello %1!s! World!", "fixed_string" ) <<
> std::endl;
>   boost::fixed_string< 100, char, format_message_policy > fmt;
>   sprintf( fmt, "Meine %1!s! Welt!", "grosse" );
>   std::cout << fmt << std::endl;

But why cant you do :

     fixed_string_no_format_policy  str;

    sprintf <format_message_policy >( str ,  "Meine %1!s! Welt!", "grosse" ,);

etc. IOW separating the formatting functionality from the data in the string?
OTOH in c-style strings the  text of a particular string is intimately bound up
with the format, hence a string needs the format as a policy. Is this the point?

>>What happens between fixed_string and std::string. Are they compatible?
>>Example
>>code would help to show a few scenarios.
>
> As far as I know, they are not, just as basic_string< char, nocase_traits<
> char > > is incompatible with std::string! I was not sure what to do here,
> so I went with the standard.

I was thinking of e.g

    fixed_string<7> fs = "Hello ";

    std::string str = "World";

    str + fs ;

    fs + str;

etc

It occurs to me that I'm probably missing the point of fixed_stringsomewhat .
Maybe It would help if I was walked through the functionality with some more
examples in the documentation..

regards
Andy Little