Hi,
whats the difference between:
char* a = new char;
char* b = new char[10];
char c [10];
Regards
BN
whats the difference between:
char* a = new char;
char* b = new char[10];
char c [10];
Regards
BN
-
-
Re: char* and char
"Ying Yang" <YingYang@hotma il.com> wrote in message
news:3f6984ca_1 @news.iprimus.c om.au...[color=blue]
> Hi,
>
> whats the difference between:
>
> char* a = new char;
>
> char* b = new char[10];[/color]
'a' and 'b' are both pointers to a char. That is, they each contain the
address in memory of a char. In the case of 'b', there happens to be another
9 chars after the first one, but it is up to the programmer to be aware of
that (including using "delete[]" for 'b' and just "delete" for 'a' later
when you delete them). Once created, the compiler treats both pointers the
same.
[color=blue]
> char c [10];[/color]
'c' is an array of 10 chars. If you use 'c' where a char * is expected, the
compiler will create the char * by taking the address of the first char in
the array. But 'c' itself is an array, not a pointer, so it is a different
type from 'a' and 'b'.
DW
-
Re: char* and char
Ying Yang wrote:[color=blue]
> Hi,
>
> whats the difference between:
>
> char* a = new char;[/color]
"a" is a pointer to a character, initialized by the expression new char.
The expression new char allocates memory for one character from the free
store and (according to the current wording of the standard) initialized it
by doing nothing. So "a" will point at that "random" character in the free
store (sometimes called heap).
If new char cannot allocate memory for one object of type char it will throw
an std::bad_alloc exception, which will be either caught by an appropriate
ctach-handler or will cause the system to call a function named terminate(),
which will by default call a function named abort() and that one will stop
the programs' execution.
[color=blue]
> char* b = new char[10];[/color]
"b" is a pointer to a character, initialized by the expression new char[10].
The expression new char[10] allocates a block of continuous memory for 10
character from the free store and (according to the current wording of the
standard) initialized it by doing nothing. After initialization "b" will
point at the first of those 10 "random" characters in the free store
(sometimes called heap).
Rest is the same as before.
[color=blue]
> char c [10];[/color]
This one can be many things. So let's skip initialization and meaning
(because it can be namespace scope or automatic or member declaration) and
let's just go for the type.
"c" is an array of 10 characters. This means that it has the type: array of
10 characters. When using "c" in certain expressions it will (so-called)
decay into a pointer to the first element of that array. In such a case it
will behave much like "b" before, except that the memory area belonging to
"c" is not necessarily from the free-store:
c[2]; // third element of c
b[2]; // third element of b
It is important to note that while many many times "c" will behave as a
pointer to the first element of the array it represents, it is not one. It
just can behave as one (in certain expressions) for our convenience.
--
Attila aka WW
Comment
-
Re: char* and char
Ying Yang wrote:[color=blue]
>
> Hi,
>
> whats the difference between:
>
> char* a = new char;
>[/color]
a
+-------+ +---+
| o------------------>| |
+-------+ +---+
[color=blue]
> char* b = new char[10];
>[/color]
b
+-------+ +---+---+---+---+---+---+---+---+---+---+
| o------------------>| | | | | | | | | | |
+-------+ +---+---+---+---+---+---+---+---+---+---+
[color=blue]
> char c [10];
>[/color]
c
+---+---+---+---+---+---+---+---+---+---+
| | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+
HTH
--
Karl Heinz Buchegger
kbuchegg@gascad .at
Comment
-
Re: char* and char
David White wrote:
[color=blue]
> 'c' is an array of 10 chars. If you use 'c' where a char * is expected, the
> compiler will create the char * by taking the address of the first char in
> the array.[/color]
Except for a few well-documented cases, such as when used with the
sizeof and address-of (&) operators.
Brian Rodenborn
Comment
-
Re: char* and char
"Default User" <first.last@com pany.com> wrote in message
news:3F69DEEB.A 704E57A@company .com...[color=blue]
> David White wrote:
>[color=green]
> > 'c' is an array of 10 chars. If you use 'c' where a char * is expected,[/color][/color]
the[color=blue][color=green]
> > compiler will create the char * by taking the address of the first char[/color][/color]
in[color=blue][color=green]
> > the array.[/color]
>
> Except for a few well-documented cases, such as when used with the
> sizeof and address-of (&) operators.[/color]
But neither of these cases is using 'c' where a char * is expected, is it?
DW
Comment
-
Re: char* and char
David White wrote:[color=blue]
>
> 'c' is an array of 10 chars. If you use 'c' where a char * is expected, the
> compiler will create the char * by taking the address of the first char in
> the array.[/color]
A stronger statement is called for here. If you use 'c' for any purpose
other than as the operand for the address-of or sizeof operator, the
compiler will convert it to char*. It does not have to occur in a
context that calls for a char*.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Comment
-
Re: char* and char
Kevin Goodsell wrote:[color=blue]
> David White wrote:[color=green]
>>
>> 'c' is an array of 10 chars. If you use 'c' where a char * is
>> expected, the compiler will create the char * by taking the address
>> of the first char in the array.[/color]
>
> A stronger statement is called for here. If you use 'c' for any
> purpose other than as the operand for the address-of or sizeof
> operator, the compiler will convert it to char*. It does not have to
> occur in a
> context that calls for a char*.[/color]
Not exactly. Template argument deduction will not (AFAIK) decay it into a
pointer.
--
WW aka Attila
Comment
-
Re: char* and char
White Wolf wrote:
[color=blue]
>
> Not exactly. Template argument deduction will not (AFAIK) decay it into a
> pointer.
>[/color]
Good point. In C what I said holds true, but I was never very sure if
C++ added other contexts where the "decay to pointer" would be bypassed.
No one bothered to point this out until now, and it simply never
occurred to me.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Comment
-
Re: char* and char
David White wrote:[color=blue]
>
> "Default User" <first.last@com pany.com> wrote in message
> news:3F69DEEB.A 704E57A@company .com...[color=green]
> > David White wrote:
> >[color=darkred]
> > > 'c' is an array of 10 chars. If you use 'c' where a char * is expected,[/color][/color]
> the[color=green][color=darkred]
> > > compiler will create the char * by taking the address of the first char[/color][/color]
> in[color=green][color=darkred]
> > > the array.[/color]
> >
> > Except for a few well-documented cases, such as when used with the
> > sizeof and address-of (&) operators.[/color]
>
> But neither of these cases is using 'c' where a char * is expected, is it?[/color]
I'm pointing out the cases where no conversion takes place. Many people
are unaware of these exceptions, you'll often see the phrase, "the name
of the array is a pointer to the first element". Naturally, the
operators mentioned take any type.
Brian Rodenborn
Comment
-
Re: char* and char
Kevin Goodsell wrote:
[color=blue]
> Good point. In C what I said holds true, but I was never very sure if
> C++ added other contexts where the "decay to pointer" would be bypassed.
> No one bothered to point this out until now, and it simply never
> occurred to me.[/color]
I wasn't either, so I hedged my bets :)
I'm not as strong on templates as I should be, I wasn't sure if you
could instantiate with array types or not. They'd be tricky, because any
resulting variables in a class would not be modifiable lvalues and all
that.
Brian Rodenborn
Comment
-
Re: char* and char
Default User wrote:[color=blue]
> I wasn't either, so I hedged my bets :)
>
> I'm not as strong on templates as I should be, I wasn't sure if you
> could instantiate with array types or not. They'd be tricky, because
> any resulting variables in a class would not be modifiable lvalues
> and all that.[/color]
Really? How come? What do you mean by that?
--
WW aka Attila
Comment
-
Re: char* and char
Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote in message
news:DKoab.8564 $BS5.3463@newsr ead4.news.pas.e arthlink.net...[color=blue]
> David White wrote:[color=green]
> >
> > 'c' is an array of 10 chars. If you use 'c' where a char * is expected,[/color][/color]
the[color=blue][color=green]
> > compiler will create the char * by taking the address of the first char[/color][/color]
in[color=blue][color=green]
> > the array.[/color]
>
> A stronger statement is called for here. If you use 'c' for any purpose
> other than as the operand for the address-of or sizeof operator, the
> compiler will convert it to char*. It does not have to occur in a
> context that calls for a char*.[/color]
Perhaps this is a bit too strong. It's liable to cause some people to think
of an array more as a pointer than as an array.
What about
char ch = c[i];
?
Is this using 'c' as an array or a pointer? The result is the same whether
'c' is an array or a pointer, but I'd prefer to think of the pointer case as
behaving like an array than the array case behaving like a pointer.
What happens to the array here?
struct S
{
char c[10];
};
void f(S &s1, S &s2)
{
s1 = s2;
}
There's no pointer behaviour in this case.
I think it's better to list the cases where one type decays to another than
to list the exceptions.
DW
Comment
-
Re: char* and char
David White wrote:[color=blue]
> Perhaps this is a bit too strong. It's liable to cause some people to
> think of an array more as a pointer than as an array.
>
> What about
> char ch = c[i];
> ?
> Is this using 'c' as an array or a pointer?[/color]
Pointer.
[color=blue]
> The result is the same
> whether 'c' is an array or a pointer, but I'd prefer to think of the
> pointer case as behaving like an array than the array case behaving
> like a pointer.[/color]
There is no array arithmetics in C++, but there is pointer arithmetics.
[color=blue]
> What happens to the array here?[/color]
Here you do not use the array.
[color=blue]
> struct S
> {
> char c[10];
> };
>
> void f(S &s1, S &s2)
> {
> s1 = s2;
> }
>
> There's no pointer behaviour in this case.[/color]
Because you do not use the name of the array.
[color=blue]
> I think it's better to list the cases where one type decays to
> another than to list the exceptions.[/color]
Except if the exceptions are way less.
BTW if you do not believe me that in you example case above "c" indeed
decayed to a pointer try the following:
// Warning1 Untested code typed with flue and migrene
#include <iostream>
typedef int not_void_ever;
not_void_ever main() {
char const gree_thing[] = "Hello world!";
std::cout << "char 6: " << 6[gree_thing] << std::endl;
}
Compile it. It will. Run it. It will and it will print "char 5: w".
Why? Because 6 is an array? Nope. But because gree_thing decays into a
pointer to the first element of the character array. And then what we have
is:
something[something]
which translates to
*(something+som ething)
in our case
*(6+gree_thing)
--
WW aka Attila
Comment
-
Re: char* and char
Default User wrote:
[color=blue]
> Kevin Goodsell wrote:
>
>[color=green]
>>Good point. In C what I said holds true, but I was never very sure if
>>C++ added other contexts where the "decay to pointer" would be bypassed.
>>No one bothered to point this out until now, and it simply never
>>occurred to me.[/color]
>
>
>
> I wasn't either, so I hedged my bets :)
>
> I'm not as strong on templates as I should be,[/color]
It seems like few people are. I know I'm not. It's a complicated topic.
[color=blue]
> I wasn't sure if you
> could instantiate with array types or not. They'd be tricky, because any
> resulting variables in a class would not be modifiable lvalues and all
> that.[/color]
I'm not sure how it would work either, outside of things like this:
template<class T, size_t N>
void foo(T (&array)[N])
{
}
I'm not sure if this counts or not (it's what I thought of when I read
Attila's message, but maybe he was talking about something else). But I
think it points to another situation where arrays don't decay to
pointers - binding to a reference:
int a[20];
int (&r)[20] = a;
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Comment
Comment