I have already written code that allows me to create std like strings of fixed upper bound length. If such thing doesn't exist in boost, I am willing to submit and help standardise my code. Eg. // create a string with upper bound length of 4 characters. boost::slstring<4> myLimitedString; My implementation has the ability to quickly copy between strings with the same upper bound (ie without checking the max length). But during assignments from char* or normal std::string objects or strings with different upper bound, the upper bound condition is checked and exception is thrown if there is an error. Martin. Martin Bosticky Software Engineer Action Information Management Ltd. Tel: (01225) 711200 Fax: (01225) 711222 Email: mbosticky@aimltd.co.uk -----Original Message----- From: John Nagle [mailto:nagle@animats.com] Sent: 12 May 2004 23:00 To: boost@lists.boost.org Subject: [boost] Re: static sized strings Reece Dunn wrote:
Rob Stewart wrote:
From: John Nagle <nagle@animats.com>
STL strings are variable-sized, with no limit. When you add characters, "size()" increases. Should fixed-size
^^^^ I presume you're referring to fixed-capacity strings which can have a variable size, right?
Yes.
yup. The idea is to make it a buffer-overflow safe replacement for C style character buffers, e.g.:
char buf[ 100 ]; ::sprintf( buf, "...", ... );
Yes.
If the string if (sic) fixed-capacity *and* there remains sufficient capacity, c_str() can null terminate the buffer. If there isn't sufficient remaining capacity, then throw an exception.
Done that way, if you write char_string<4> s; strcat(s,"ABCDE"); // truncates at "ABCD", no null. printf("s=%s\n",s.c_str()); // c_str throws exception which is quite different from classic <string.h> semantics. You couldn't use that as a drop-in replacement for C strings. Nor is it compatible with STL basic_string semantics. I'd suggest consistent null-terminated semantics for char_string.
IOW, make it a runtime error to fix the capacity too small to permit null termination when calling c_str(). That still leaves room for things like the 4-character file signature to which you referred, and yet prevents buffer overrun, but doesn't require foregoing flexibility.
If you want a 4-char file signature, you can use "boost::array<char,4>", which does that job. Is there any real need for that functionality in char_string? char_string might have some convenience template functions to interconvert "boost::array" and "boost::char_string".
That is a good idea. It will mean keeping track of the string length,
Yes, that seems to be necessary. What about the base class issue? There's a need to be able to write something like "char_string_base& s" when you want to pass around fixed-capacity strings of more than one capacity.
Regards, Reece
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email message contains confidential information and is intended for the use of its intended recipient only. Access to this email by anyone else is unauthorised. If you are not the intended recipient you are hereby notified that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If this communication has been sent to you in error, please notify us immediately. Action Information Management Ltd. 129 Devizes Road, Hilperton, Trowbridge, Wiltshire BA14 7SZ. Tel: +44 (0) 1225 711200 Fax: +44 (0) 1225 711222 Website www.aimltd.co.uk email: support@aimltd.co.uk