Understanding char*

[Kevin Goodsell]

Re: Understanding char*

Big Brian wrote:
[color=blue][color=green][color=darkred]
>>>Could someone explain for me what is happening here?[/color]
>>
>>char* is not a string type. It is a pointer to a single character.
>>At this point in your career you should stay clear ofit. Use the std::string type instead.[/color]
>
>
> Everybody needs to understand c style strings as well.[/color]

Yes, but they should avoid them. Beginners and experts alike should
prefer std::string.
[color=blue]
> I've worked on
> projects where you couldn't use std::string.[/color]

So, projects where you weren't allowed to use C++? (At least not all of
it.) I wonder why that restriction would be placed on a project written
in C++.
[color=blue]
> And you never know when
> you're going to have to maintain old code which uses them.[/color]

Yeah. When maintaining that kind of code, I recommend converting it to
use std::string.

The advantages of std::string over C-style strings are clear. Of course
a good programmer should now how to use messy things like C-style
strings, but he should also know better than to use them (at least most
of the time).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[A]

Re: Understanding char*

[color=blue]
>[color=green][color=darkred]
> > > string = new char[5];[/color]
> >
> > You have made this pointer point to the first element in a constant[/color][/color]
array[color=blue]
> of[color=green]
> > type char that has 5 elements. This constant array is allocated on the[/color]
> heap[color=green]
> > (using the new operator). Note, there is a close association between
> > pointers and arrays.[/color]
>
> Why are you saying 'constant array'? The array of chars that is
> allocated by the statement above is not constant at all.[/color]

Array identifiers are constant so you cannot assign a value to array
identifiers - you can only assign values to the elements in the array.
[color=blue][color=green][color=darkred]
> > > string = "This is the string";
> > > cout << string << std::endl;
> > > The output contains (This the string) even though I only allocated 5
> > > characters in memory with new.[/color]
> >
> > The elements in the constant array is filled with the characters in the
> > string literal.[/color]
>
> No, not at all. The elements of the array you allocated with 'new[]'[/color]
are[color=blue]
> untouched and the pointer to the first element of that array is lost. See
> Gianni's post for an in-depth explanation.[/color]

Incorrect.
[color=blue][color=green]
> > Two important things to notice here is that (1) the null
> > character is automatically appended at the end of the array[/color]
>
> Using the above statement, no. This applies when using any of the str*
> functions, like strcpy, strcat and whatnot.[/color]

Incorrect.

char myString[] = "Hello World";

The null character is automatically included here.

[Kevin Goodsell]

Re: Understanding char*

A wrote:
[color=blue][color=green]
>>
>> Why are you saying 'constant array'? The array of chars that is
>>allocated by the statement above is not constant at all.[/color]
>
>
> Array identifiers are constant so you cannot assign a value to array
> identifiers - you can only assign values to the elements in the array.[/color]

But there were no arrays in the example, other than the dynamically
allocated one (which doesn't have an identifier). Neither the pointer
nor the thing pointed to were const in the example.
[color=blue][color=green]
>>
>>No, not at all. The elements of the array you allocated with 'new[]' are
>>untouched and the pointer to the first element of that array is lost. See
>>Gianni's post for an in-depth explanation.[/color]
>
>
> Incorrect.[/color]

He was precisely correct. You seem to have a lot to learn about C++.
There is absolutely no copying of array elements happening here. All
that happens is a pointer being modified to point to a different
address, thus losing the address of the dynamic array - in other words,
leaking the memory.
[color=blue]
>
>[color=green][color=darkred]
>>>Two important things to notice here is that (1) the null
>>>character is automatically appended at the end of the array[/color]
>>
>> Using the above statement, no. This applies when using any of the str*
>>functions, like strcpy, strcat and whatnot.[/color]
>
>
> Incorrect.[/color]

He's right. You are not.
[color=blue]
>
> char myString[] = "Hello World";
>
> The null character is automatically included here.[/color]

Yes, but this example has nothing to do with your (blatantly incorrect)
statements, and it does nothing to disprove Jakob's (correct) statements.

(As a side note, here we have another example of the difference between
assignment and initialization. The above initialization automatically
copies the elements of the string literal into the myString array. This
cannot be duplicated with an assignment.)

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Jack Klein]

Re: Understanding char*

On Sat, 13 Sep 2003 18:34:16 GMT, Kevin Goodsell
<usenet1.spamfr ee.fusion@never box.com> wrote in comp.lang.c++:
[color=blue]
> Big Brian wrote:
>[color=green][color=darkred]
> >>>Could someone explain for me what is happening here?
> >>
> >>char* is not a string type. It is a pointer to a single character.
> >>At this point in your career you should stay clear ofit. Use the std::string type instead.[/color]
> >
> >
> > Everybody needs to understand c style strings as well.[/color]
>
> Yes, but they should avoid them. Beginners and experts alike should
> prefer std::string.
>[color=green]
> > I've worked on
> > projects where you couldn't use std::string.[/color]
>
> So, projects where you weren't allowed to use C++? (At least not all of
> it.) I wonder why that restriction would be placed on a project written
> in C++.[/color]

There are many existing applications that were written in a dialect of
C++ before there was a std::string or an ISO/IEC standard for C++. If
these are viable, they often need to be maintained and extended,
sometimes for very many years.

Not every project includes the luxury of starting with a clean sheet
of paper.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Kevin Goodsell]

Re: Understanding char*

Jack Klein wrote:[color=blue]
>
> There are many existing applications that were written in a dialect of
> C++ before there was a std::string or an ISO/IEC standard for C++. If
> these are viable, they often need to be maintained and extended,
> sometimes for very many years.
>
> Not every project includes the luxury of starting with a clean sheet
> of paper.
>[/color]

Yeah, I know. But I think it's unfortunate when projects that *could*
use modern C++ don't, and do things the hard way instead. I question the
validity of the reasons for this. Is there really a good reason to
forbid, e.g., templates in a C++ program in this day and age?

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Duane Hebert]

Re: Understanding char*

> Yeah, I know. But I think it's unfortunate when projects that *could*[color=blue]
> use modern C++ don't, and do things the hard way instead. I question the
> validity of the reasons for this. Is there really a good reason to
> forbid, e.g., templates in a C++ program in this day and age?[/color]

Theoretically no but if the compiler that you're stuck with using has broken
support for templates...

[Kevin Goodsell]

Re: Understanding char*

Duane Hebert wrote:[color=blue][color=green]
>>Yeah, I know. But I think it's unfortunate when projects that *could*
>>use modern C++ don't, and do things the hard way instead. I question the
>>validity of the reasons for this. Is there really a good reason to
>>forbid, e.g., templates in a C++ program in this day and age?[/color]
>
>
> Theoretically no but if the compiler that you're stuck with using has broken
> support for templates...[/color]

Well, it's not necessarily one compiler. If you are targeting multiple
systems, you may be stuck with the "lowest common denominator",
unfortunately. I understand this, but what I don't quite understand is
what standard some people are apparently using to determine what the
lowest common denominator is.

Take the Mozilla project, for example. I love Mozilla. I use Firebird
for all my browsing and Thunderbird for mail and news. But I think their
coding standards are a joke. Here's a few links:

http://www.mozilla.org/hacking/mozilla-style-guide.html

http://www.mozilla.org/hacking/portable-cpp.html

And here's a few examples of the rules:

* Don't use NULL for pointers. On some systems it's declared as void *
and causes a compile warning when assigned to a pointer.

* Don't use templates.

* Don't use exceptions.

* Don't use namespaces.

* Don't put constructors in header files. (Because VC++ 1.5 can't handle it)

This seems crazy to me. Portable is one thing, but portable to ancient
compilers is another. They want it to be able to build for pretty much
any system - that's great, but is it necessary to restrict the language
that much? Considering the compilers that are available today, you'd
think they could allow the use of most language features with no
problems at all. gcc and Comeau come to mind - how many platforms do
they cover? If they could *only* build on those two compilers, I think
they'd still have pretty much the platform coverage they have now. And
if they were using the language rather than working around it, they'd
probably have fewer bugs.

I think we should demand compilers that support the actual language,
rather than restricting our use of the language to those features
vendors feel like supporting.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Greg Comeau]

Re: Understanding char*

In article <6139b.3421$BS5 .1864@newsread4 .news.pas.earth link.net>,
Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote:[color=blue]
>...Take .. Mozilla ... I think their
>coding standards are a joke. Here's a few links:
>
>http://www.mozilla.org/hacking/mozilla-style-guide.html
>http://www.mozilla.org/hacking/portable-cpp.html
>
>And here's a few examples of the rules:
>
>* Don't use NULL for pointers. On some systems it's declared as void *
>and causes a compile warning when assigned to a pointer.
>
>* Don't use templates.
>
>* Don't use exceptions.
>
>* Don't use namespaces.
>
>* Don't put constructors in header files. (Because VC++ 1.5 can't handle it)
>
>This seems crazy to me. Portable is one thing, but portable to ancient
>compilers is another. They want it to be able to build for pretty much
>any system - that's great, but is it necessary to restrict the language
>that much? Considering the compilers that are available today, you'd
>think they could allow the use of most language features with no
>problems at all. gcc and Comeau come to mind - how many platforms do
>they cover? If they could *only* build on those two compilers, I think
>they'd still have pretty much the platform coverage they have now. And
>if they were using the language rather than working around it, they'd
>probably have fewer bugs.
>
>I think we should demand compilers that support the actual language,
>rather than restricting our use of the language to those features
>vendors feel like supporting.[/color]

It definitely *is* the case that many projects need to constrain
themselves as per the guidelines above. However, I don't think
that's the problem, that is, I think the problem is projects which
don't need such constrains to be tied down by them, coding standards
which take on lies of their own, coding standard which remain
stagnant, inapplying situations, etc. So sure, for many project,
it can make no sense at all, and doing something as you say just
might be the ticket.
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Default User]

Re: Understanding char*

Greg Comeau wrote:
[color=blue]
> coding standards which take on lies of their own[/color]


Damn those lying code standards! Or was that a bit of a Freudian?




Brian Rodenborn

[Greg Comeau]

Re: Understanding char*

In article <3F65EF07.CD6E3 9E5@company.com >,
Default User <first.last@com pany.com> wrote:[color=blue]
>Greg Comeau wrote:[color=green]
>> coding standards which take on lies of their own[/color]
>
>Damn those lying code standards! Or was that a bit of a Freudian?[/color]

heh. Has got to be :)
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?