Re: A few questions on std::string

From: Leor Zolman (leor_at_bdsoft.com)
Date: 04/16/04 

Date: Fri, 16 Apr 2004 02:13:15 GMT

On Thu, 15 Apr 2004 20:09:00 -0400, Mark <mark_netNews@hotmail.com> wrote:

>
>
>Request clarification on items that seems puzzling per the Josuttis
>text I've been reading. Consider
>
>#include <iostream>
>#include <iomanip>
>#include <sstream>
>
>void DoASpecialThing (const char* abc)
>{
> for (int idx=0; idx < 5; idx++)
> {
> std::cout << " " << abc[idx] << std::endl;
> if (abc[idx] == '\0')
> std::cout << " terminating null \\0" << std::endl;
> else
> std::cout << " " << abc[idx] << std::endl;
> }
>}
>
>int main()
>{
>
> std::string myString("abcd");
> DoASpecialThing (myString.c_str()); // (1) preferred '/0' appended
> DoASpecialThing (&myString[0]); // (2)
> return 0;
>}
>The output for items (1) and (2) from the program is
>a
>b
>c
>d
>terminating null \0
>
>1.
>One the one hand a call to c_str() requires that only the pointer to
>the buffer needs to be returned. That said, is it required that
>c_str() appends the terminating null char?

The pointer returned by c_str() will point to a NUL-terminated array of
char, yes. Whether c_str() "appends" it or not is immaterial; it may have
already been there, or perhaps not. What counts is that the thing you get
back from c_str() has the NUL.

>
>2.
>It is my understanding that the [] operator is only required to
>deliver a reference to the character at the specified position in the
>string, however it seems to be sheer luck that I obtained the null
>character. Yes/No?

/Probably/ not. If I were implementing std::string, I'd have it keep a NUL
there in order to make things such as c_str() efficient. But there's no
requirement that std::string necessarily work that way.

>
>3.
>While it's true that I'm almost sold on std::string. It appears to me
>that c-strings 'might" be friendlier to use than std::string, simply
>because there are times when one is required to shoehorn std::string
>into places where it doesn't fit easily, or write ten lines of code
>where two would suffice. In other words, I suspect it's helpful to
>understand the STL implementation but I've oft been of the impression
>that STL implementation details are left for those who do the
>implementing.

Not having to worry about buffer overruns is the 800-pound gorilla. Lots
of things about C strings are easier than std::string, but that sure aint
one of them ;-) And that makes all the difference in the world, unless
you're coding for an embedded system where you just refuse to pay the
overhead for std::string. You may find this enlightening (or not):
        http://www.bdsoft.com/resources/thinking.html

>
>Futhermore, it's my understanding that vector is required to be
>implemented as a contiguous memory block so as to allow it to be used
>across the C++/C boundary. Trouble is, the same cannot really be
>assumed for basic_string<char> or am I mistaken?

Right. Doesn't mean it can't be implemented that way, but you're correct.
You can't assume anything.

>
>Assuming I'm not mistaken, the alternative then would be to create a
>string class that uses a vector underneath and provides the STL string
>functions. Then you can safely use &myString[0] across STL
>implementations. Doing so may sacrifice performance, so it might be
>something I'd only use in places where I need to use an STL string
>buffer or something of the sort.

std::string is there for the convenience of doing "string-like" things at a
higher level of abstraction than what we all had to do when all there was
to implement with were char *'s. If you wish to return to the char * level,
then just do /that/; why try to stuff a vector under there?

Perhaps if you tell us what the application is you have in mind, we can
help you figure out which existing facilities are most appropriate.
Whatever you're doing, I doubt you'll need to implement YASC (Yet Another
String Class).
        -leor

>
>The groups thoughts.

>
>Thanks in advance
>
>
>Mark
>------------------------------------------------------------------------
>If I wanted to measure the natural resonances of any object
>-- bell, Helmholz resonator -- I imagine that I would get a better
>result by rigging up some kind of continuous exciter than by
>attempting to analyze an impulse response 

-- 
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix  
C++ users: download BD Software's free STL Error Message Decryptor at:
   www.bdsoft.com/tools/stlfilt.html

Relevant Pages

  • [PATCH 09/21] perf: rewire generic library stuff, p5
    ... +int eprintf(int level, const char *fmt, ...) ... * Helper function for splitting a string into an argv-like array. ... +static int count_argc(const char *str) ...
    (Linux-Kernel)
  • Re: How to add thousand separators
    ... First, this code is obsolete as written, because char is a dead data type and should not ... Note that both of these should be stored as string resources since they might need to be ... 18 digits for any reason. ... you have made a VERY SERIOUS DESIGN ERROR. ...
    (microsoft.public.vc.mfc)
  • Re: Returning a character buffer from a DLL
    ... I need to return a string buffer from the DLL in a RunQuery function. ... I find it odd that you are using the obsolete 'char *' data type here. ... want to use a string pointer of any type here! ...
    (microsoft.public.vc.mfc)
  • Re: what is the best way of passing floats into a string
    ... I do not null-terminate as snprintf takes care of this (according to ... But the easiest way to determine the size needed to format a number, ... int length_of_representation(double n,const char* format){ ... I get a nice result of -10.000000 in my char * string. ...
    (comp.unix.programmer)
  • Re: weird problem
    ... I already told you that the comparison between an integer and a float ... to strcmpwhich expects a pointer to a string. ... And now a question about something else: why do you use floating ... int,float, char, etc. ...
    (comp.lang.c)