🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2577

remarks about the string chapter

#2577
From: Nico Josuttis
Date: Tue, 14 Nov 1995 16:32
153 lines
5463 bytes
Hello,
reading and trying to understand the CD i got some
problems, remarks and questions.
They may come from my litle knowledge but also from problems the CD might
have.
To understand the stuff and to avoid it to blame myself making a proposal
i have the following questions. I hope, someone familiar with the
string library could answer them.
The questions regard the CD of 26 September 1995.


21.1.1.4, 21.1.1.9

 - wouldn't it make sense to have a constructor 
     explicit basic_string (charT c); 
   to do something like
     string s = c;
   instead of
     string s;
     s = c;
   or
     string s (1,c);
   ?
   I don't see an easy way to e.g. append or insert char's in strings.


 - what is the background for the sepcification, when size() is 0
   data() being "a non-null pointer that is copyable and 
                 can have zero added to it"
    - why not simply a null-pointer (NULL) ?
    - does "can have zero added to it" mean "can have zero APPENDED to it"
      or does really an addition takes place here ?

 > basic_string (size_type n, charT c, Allocator& = Allocator());

 - shouldn't be defined "const charT& c" instead of "charT c",
   because charT might not be a fundamental data type ?

   This also belongs to other places as for operator=(), resize() or append().
   

21.1.1.5

 - Why does size() and length() for strings exist
   (it seems they do exactly the same) ?


21.1.1.6

 > void resize (size_type n);
 is an undefined behavior if n > size() for the most
 important types string and wstring, because
 char() and wchar_t() are undefined (or are they ?)

 I'd suggest to define explicitly versions for both types,
 e.g.: void string::resize(size_type n)
       effects: string::resize(n,eos());

 - The behavior of reserve() should be made clearer.
   If I understand it right, it reserves space for "res_arg - 1" char-like objects,
   because eos() may be needed internally.
   If i am right, please document it, because it is a very dangerous
   feature (people may assume reserve(5) is enough to be shure,
            a reallocation will occure only if the string gets more
            than 5 chars).
   If not, explain it clearly.
   Anyway to be more safe i suggest to use "res_arg" and not "res_arg-1"
   as the new minimum size() of the string
   (what means that capacity() typically became res_arg+1
           and a length_error might be thrown if it is npos).
   This would make the internal behavior more independent from the interface.

 - Following this it might even be senseful to let
   capacity() not return the size of the allocated storage
   but the possible size() of the string.


21.1.1.8.3

 > basic_string<charT,traits,Allocator>& assign(const charT* s);
 >
 > Returns: assign(basic_string(s)).

 - shouldn't it return: "assign(basic_string<charT,traits,Allocator>(s))" ?


21.1.1.8.7

 - "copy" is a name that is often used to return a copy of the object,
   the function is called for.
   I think a name like "copy_into" would be more clear.


21.1.1.9

 - several functions return "npos".

   some remarks:
    a) the specification that npos is char_type -1 IMHO means that
       char_type is an unsigned value and npos is the maximum value of it.
       Am I right ?
       If so, what happens if char_type is not unsigned (or is it specified somewhere?).
       Wouldn't it be better to define npos beeing max(char_type) ?

    b) As far as I understand, i have to check the return value
       with something like:
   	    string s, str;
   	    if (s.find(str) == string::npos)

       I don't think, "npos" is a good (self explaining) name.
       May be something like "nopos" would be better.

    c) Every string type has its own "npos".
	But what happens if i make a bug and mix them ?
	Example:
   	    string s, str;
   	    if (s.find(str) == wstring::npos)

    d) The return value is an inconsistence with STL, because there typically
       "last" is returned (what would be eos() for strings).
       So why this special behavior ?


21.1.1.9.1

 > Returns: find(basic_string<charT,traits,Allocator>(s,n)pos);

 - "," is missing between "(s,n)" and "pos", isn't it ?


21.1.1.9.3

 - IMHO there is no difference between
	find (charT, size_type = 0)
   and
	find_first_of (charT, size_type = 0)
   if i call them only with a char.
   So why does both exist ?
   Same for rfind() and find_last_of().


It would be nice if any answer could ALSO be postet directly to my emali address.
Thanks in advance.

Sorry for my english. 

Nicolai Josuttis
nico@bredex.de
BREDEX GmbH, Germany

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID: <199511141627.RAA07095@bredex.bredex.de>
Path: arc1-ca.pugleaf.net!engnews1.Eng.Sun.COM!taumet!clamage

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!engnews1.Eng.Sun.COM!taumet!clamage
From: Nico Josuttis <nico@bredex.de>
Newsgroups: comp.std.c++
Subject: remarks about the string chapter
Date: 14 Nov 1995 16:32:11 GMT
Organization: ?
Approved: clamage@eng.sun.com (comp.std.c++)
Message-ID: <199511141627.RAA07095@bredex.bredex.de>
NNTP-Posting-Host: taumet.eng.sun.com
Content-Type: text
X-Authentication-Warning: bredex.bredex.de: Host localhost didn't use HELO protocol
X-Mts: smtp
Content-Length: 4570
X-Lines: 149
Originator: clamage@taumet