"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