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