char* and char

[Ying Yang]

Hi,

whats the difference between:

char* a = new char;

char* b = new char[10];

char c [10];
Regards
BN

[David White]

"Ying Yang" <Yi******@hotmail.com> wrote in message
news:3f********@news.iprimus.com.au...

Hi,

whats the difference between:

char* a = new char;

char* b = new char[10];
'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.
char c [10];

'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

[Attila Feher]

Ying Yang wrote:

Hi,

whats the difference between:

char* a = new char;
"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.
char* b = new char[10];
"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.
char c [10];

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

[Karl Heinz Buchegger]

Ying Yang wrote:

Hi,

whats the difference between:

char* a = new char;
a
+-------+ +---+
| o------------------>| |
+-------+ +---+
char* b = new char[10];

b
+-------+ +---+---+---+---+---+---+---+---+---+---+
| o------------------>| | | | | | | | | | |
+-------+ +---+---+---+---+---+---+---+---+---+---+
char c [10];

c
+---+---+---+---+---+---+---+---+---+---+
| | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+

HTH

--
Karl Heinz Buchegger
kb******@gascad.at

[Default User]

David White wrote:

'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.

Except for a few well-documented cases, such as when used with the
sizeof and address-of (&) operators.


Brian Rodenborn

[David White]

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...

David White wrote:

'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.

Except for a few well-documented cases, such as when used with the
sizeof and address-of (&) operators.

But neither of these cases is using 'c' where a char * is expected, is it?

DW

[Kevin Goodsell]

David White wrote:

'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.

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.

[White Wolf]

Kevin Goodsell wrote:

David White wrote:

'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.

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*.

Not exactly. Template argument deduction will not (AFAIK) decay it into a
pointer.

--
WW aka Attila

[Kevin Goodsell]

White Wolf wrote:

Not exactly. Template argument deduction will not (AFAIK) decay it into a
pointer.

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.

[Default User]

David White wrote:

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...

David White wrote:

'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.

Except for a few well-documented cases, such as when used with the
sizeof and address-of (&) operators.

But neither of these cases is using 'c' where a char * is expected, is it?

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

[Default User]

Kevin Goodsell wrote:

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.

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

[White Wolf]

Default User wrote:

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.

Really? How come? What do you mean by that?

--
WW aka Attila

[David White]

Kevin Goodsell <us*********************@neverbox.com> wrote in message
news:DK*****************@newsread4.news.pas.earthl ink.net...

David White wrote:

'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.

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*.

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

[White Wolf]

David White wrote:

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?
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.
There is no array arithmetics in C++, but there is pointer arithmetics.
What happens to the array here?
Here you do not use the array.
struct S
{
char c[10];
};

void f(S &s1, S &s2)
{
s1 = s2;
}

There's no pointer behaviour in this case.
Because you do not use the name of the array.
I think it's better to list the cases where one type decays to
another than to list the exceptions.

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+something)

in our case

*(6+gree_thing)

--
WW aka Attila

[Kevin Goodsell]

Default User wrote:

Kevin Goodsell wrote:

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.
I wasn't either, so I hedged my bets :)

I'm not as strong on templates as I should be,

It seems like few people are. I know I'm not. It's a complicated topic.
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.

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.

[Kevin Goodsell]

David White wrote:

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?
A pointer, of course.

What happens to the array here?
struct S
{
char c[10];
};

void f(S &s1, S &s2)
{
s1 = s2;
}

The conversion applies when the array is referred to by name. It's often
stated something like "The name of an array becomes a pointer to the
first element of the array in most case. The exceptions are..."
I think it's better to list the cases where one type decays to another than
to list the exceptions.

But there are far more cases where it becomes a pointer - that's the
norm. I doubt I could list them all. In C there are only the 2 cases
where it doesn't. We're still discussing what additional cases are added
in C++.

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

[David White]

White Wolf <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

David White wrote:

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?
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.

There is no array arithmetics in C++, but there is pointer arithmetics.

What happens to the array here?

Here you do not use the array.

Yes I do, implicitly.

struct S
{
char c[10];
};

void f(S &s1, S &s2)
{
s1 = s2;
}

There's no pointer behaviour in this case.

Because you do not use the name of the array.

Does it really matter? The array is being used in the code above, and not
like a pointer. The contents of s1.c are replaced.

I think it's better to list the cases where one type decays to
another than to list the exceptions.

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+something)

in our case

*(6+gree_thing)

So, an array, unlike a pointer, contains no address and some number of
actual characters, yet we are to think of it as an address and no
characters. And a pointer, which contains just an address and no characters,
we are to think of as an array of characters (for the purposes of array[i]
anyway). It's not surprising that newbies have to ask lots of questions
here.

Nothing above surprises me, though I'd forgotten the quirky reversal of
array and index that I now remember seeing years ago, but for practical
purposes I'll stick to thinking of an array as an array and a pointer as a
pointer. Below is one reason why:

char c[10];
char d[10];
char *p = &c[0];
char *q = &d[0];

p = q; // okay
p = d; // okay
c = d; // error

This is another exception.

DW

[David White]

Kevin Goodsell <us*********************@neverbox.com> wrote in message
news:bg*****************@newsread4.news.pas.earthl ink.net...

David White wrote:
The conversion applies when the array is referred to by name. It's often
stated something like "The name of an array becomes a pointer to the
first element of the array in most case. The exceptions are..."

I would think that people, newbies in particular, are interested in all the
differences betweeen pointers and arrays, not just those where the name is
used. I can see no good reason to single out uses of the name alone.

I think it's better to list the cases where one type decays to another than to list the exceptions.

But there are far more cases where it becomes a pointer - that's the
norm. I doubt I could list them all. In C there are only the 2 cases
where it doesn't. We're still discussing what additional cases are added
in C++.

If you list the exceptions and you miss one, the statement "An array is
treated as a pointer except..." becomes a false statement. But if you say,
"An array decays to a pointer where a pointer is expected," you at least
aren't making a false statement if there are other cases as well. So far the
exceptions in C++ are:
sizeof, address of, template parameter, default assignment of structs and
classes, and that an array is not an l-value.

That's quite a few, and are we certain there aren't more?

DW

[White Wolf]

David White wrote:

What happens to the array here?
Here you do not use the array.

Yes I do, implicitly.

No, you are not. Using the array in this context (decaying) means using the
arrays name. It is not the array which decays, it is name.

Because you do not use the name of the array.

Does it really matter?

Yes it does. It is nto the array decaying into a pointer: its name does.
So, an array, unlike a pointer, contains no address and some number of
actual characters, yet we are to think of it as an address and no
characters.
No. We are talking about array *names* and not arrays.
And a pointer, which contains just an address and no
characters, we are to think of as an array of characters (for the
purposes of array[i] anyway). It's not surprising that newbies have
to ask lots of questions here.
Nope. Array *names* behave like pointers to the arrays first element - most
of the cases. Pointers _never_ behave like arrays.
Nothing above surprises me, though I'd forgotten the quirky reversal
of array and index that I now remember seeing years ago, but for
practical purposes I'll stick to thinking of an array as an array and
a pointer as a pointer.

No one asked you to stop think about an array as an array and a pointer as a
pointer. But please also think about the _name_ of the array as one which ,
in certain contexts, can decay into naming a pointer rvalue. Not ever as an
lvalue as you example tried to show.

--
WW aka Attila

[White Wolf]

David White wrote:

I would think that people, newbies in particular, are interested in
all the differences betweeen pointers and arrays, not just those
where the name is used. I can see no good reason to single out uses
of the name alone.
You mean that we should not mention one very important rule of the language
just because at first sight it differs from other languages?
If you list the exceptions and you miss one, the statement "An array
is treated as a pointer except..." becomes a false statement.
It is _always_ a false statement. And array is *never* treated as a
pointer. The *name* of the array *variable* can behave as or decay into a
pointer.
But if
you say, "An array decays to a pointer where a pointer is expected,"
you at least aren't making a false statement
You are. The array never decays into anything.

T foo[S];

Suppose the above is an array declaration. The array is a variable. It has
an object part (the associated continuous region of storage) and a name
part, which we use to refer to that storage and a type part, which tells
what is in that storage, how big that storage is etc.

The array is the object (the storage) with its type. The word foo is the
name of the variable. We use the name of the variable to refer to the
storage. Now in some cases, foo refers to that storage as a pointer to its
first element, while in another cases it represent the whole storage with
all the elements in it.
So far the exceptions in C++ are:
sizeof, address of, template parameter,
Yes.
default assignment of structs
and classes,
No. In the default assignment of classes the _name_ of the array is not
used.
and that an array is not an l-value.
That's quite a few, and are we certain there aren't more?

The standard lists those.

--
WW aka Attila

[David White]

White Wolf <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

David White wrote:

I would think that people, newbies in particular, are interested in
all the differences betweeen pointers and arrays, not just those
where the name is used. I can see no good reason to single out uses
of the name alone.
You mean that we should not mention one very important rule of the

language just because at first sight it differs from other languages?
I didn't mention other languages. I paid no mind to other languages in
making that statement. Arrays and pointers have a whole bunch of properties.
If an array is involved in a particular operation, then particular behaviour
will result, whether its name is used or not. As long as you know what will
happen in a given circumstance, then I don't see why you would think in
terms of an array's name, unless you happen to find it easier to remember
everything that way.

If you list the exceptions and you miss one, the statement "An array
is treated as a pointer except..." becomes a false statement.

It is _always_ a false statement. And array is *never* treated as a
pointer. The *name* of the array *variable* can behave as or decay into a
pointer.

What about here?

void f(char *p)
{
}

void g()
{
char c[10];
char (*pc)[10] = &c;
f(*pc);
}

Isn't *pc an unnamed array? The value of sizeof(*pc) suggests that it is. So
doesn't f(*pc) convert our unnamed array into a pointer to its first
element?

But if
you say, "An array decays to a pointer where a pointer is expected,"
you at least aren't making a false statement

You are. The array never decays into anything.

It was a poor choice of wording. Try again: "The use of an array where a
pointer is expected equates to the address of the array's first element."
T foo[S];

Suppose the above is an array declaration. The array is a variable. It has an object part (the associated continuous region of storage) and a name
part, which we use to refer to that storage and a type part, which tells
what is in that storage, how big that storage is etc.

The array is the object (the storage) with its type.
I'm aware of that. That's why I never think of arrays as pointers.
The word foo is the
name of the variable. We use the name of the variable to refer to the
storage. Now in some cases, foo refers to that storage as a pointer to its first element, while in another cases it represent the whole storage with
all the elements in it.

Okay, I'm happy with that, but I still don't particularly care about the
name. In some cases referring to the array, however that might be, results
in the address of its first element. Forget the name.

So far the exceptions in C++ are:
sizeof, address of, template parameter,

Yes.

default assignment of structs
and classes,

No. In the default assignment of classes the _name_ of the array is not
used.

So we just forget about that then? I didn't think the OP was asking about
names. I thought the question was about pointers and arrays. Default
assignment of structs needs to be learned as much as anything else.

DW

[Attila Feher]

David White wrote:

Arrays and pointers have a whole bunch of properties.
I am sorry but I have no idea what do you mean.
If an array is involved in a particular operation, then
particular behaviour will result, whether its name is used or not.
You have just said nothing.
As long as you know what will happen in a given circumstance,
then I don't see why you would think in terms of an array's
name, unless you happen to find it easier to remember
everything that way.
Because the rules are based on that. You could start to disregard traffic
lamps, because you think that instinct will drive you through the road
crossings better, but it is not a life insurance.

There is a simple trick to learn and understand the rules of arrays in C and
C++. It goes like this: learn and understand the rules of arrays in C and
C++. Of course you can choose a separate route and not learn them, but then
you will not know them.

If you list the exceptions and you miss one, the statement "An array
is treated as a pointer except..." becomes a false statement.

It is _always_ a false statement. And array is *never* treated as a
pointer. The *name* of the array *variable* can behave as or decay
into a pointer.

What about here?

void f(char *p)
{
}

void g()
{
char c[10];
char (*pc)[10] = &c;
f(*pc);
}

Isn't *pc an unnamed array?

Yes. But you are still referring to an array in an expression. Whether the
reference takes the form of *pc or "My char array" it does not matter. It
is not the array which changes its type: only the way you refer to it
changes.
The value of sizeof(*pc) suggests that it is.
I am not exactly sure if it is right to call that an unnamed array. An
unnamed array should be an array temporary, and AFAIK those do not exist,
since you are unable to return arrays from functions. The closest thing I
can imagine is that character literal above.
So doesn't f(*pc) convert our unnamed array into a pointer to its
first element?
Not really. Not the array. The reference to it.

You are. The array never decays into anything.

It was a poor choice of wording. Try again: "The use of an array
where a pointer is expected equates to the address of the array's
first element."

Yep. That should work.

The array is the object (the storage) with its type.

I'm aware of that. That's why I never think of arrays as pointers.

Good. Now the next step is to do it also the other way around.
Okay, I'm happy with that, but I still don't particularly care about
the name. In some cases referring to the array, however that might
be, results in the address of its first element. Forget the name.
Okay. We forget it.

No. In the default assignment of classes the _name_ of the array is
not used.

So we just forget about that then?

OK. Forget. The *array* is *not* used either. Plain and simple. You use
a struct/class. The array type is used by the copy constructor or the
assignment operator of that class type. Very different situation.
I didn't think the OP was asking about names.
I thought the question was about pointers and arrays.
And I did not answer to the OP talking about names.
Default assignment of structs needs to be learned
as much as anything else.

There is no such thing in C++. structs are class types.

Anyway that has nothing to do with refering to an array and that reference
decaying to a pointer.

--
Attila aka WW

[David White]

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bk**********@newstree.wise.edt.ericsson.se...

David White wrote:

Arrays and pointers have a whole bunch of properties.
I am sorry but I have no idea what do you mean.

They aren't any use if they don't have properties.

If an array is involved in a particular operation, then
particular behaviour will result, whether its name is used or not.

You have just said nothing.

No, I've said that one should not be preoccupied by an array's name.

As long as you know what will happen in a given circumstance,
then I don't see why you would think in terms of an array's
name, unless you happen to find it easier to remember
everything that way.

Because the rules are based on that. You could start to disregard traffic
lamps, because you think that instinct will drive you through the road
crossings better, but it is not a life insurance.

The rules might be stated that way. It doesn't mean that's the most
appropriate way to understand arrays. There are also declaration rules,
e.g., that the * in a pointer declaration is bound more closely to the
identifier than to the type. But that doesn't stop people, including the
designer of C++, writing char* p instead of char *p, in defiance of the
rules. I'm sure that at least some such people know the rules, but they
still prefer to think of them differently in that special case. Now, where
these people have chosen to make a special case out of a general rule, I've
chosen to make a general case out of arrays wherever the rules allow it,
regardless of the form in which the rules are expressed.
There is a simple trick to learn and understand the rules of arrays in C and C++. It goes like this: learn and understand the rules of arrays in C and
C++. Of course you can choose a separate route and not learn them, but then you will not know them.
Well, I don't know. I've been using arrays and pointers for a long time and
the way I think of them hasn't got me into trouble yet. I don't remember
ever being confused as to whether a reference to an array would be treated
as an array or a pointer.

If you list the exceptions and you miss one, the statement "An array
is treated as a pointer except..." becomes a false statement.

It is _always_ a false statement. And array is *never* treated as a
pointer. The *name* of the array *variable* can behave as or decay
into a pointer.

What about here?

void f(char *p)
{
}

void g()
{
char c[10];
char (*pc)[10] = &c;
f(*pc);
}

Isn't *pc an unnamed array?

Yes. But you are still referring to an array in an expression.

That was the whole idea - to demonstrate that the result is the same whether
you refer to an array by name or not.
reference takes the form of *pc or "My char array" it does not matter. It
is not the array which changes its type: only the way you refer to it
changes.
Yes, I know. I said as much in my very first post:
"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'."

The value of sizeof(*pc) suggests that it is.

I am not exactly sure if it is right to call that an unnamed array. An
unnamed array should be an array temporary, and AFAIK those do not exist,
since you are unable to return arrays from functions. The closest thing I
can imagine is that character literal above.

The argument *pc either is an array name or it isn't. I suggest that it
isn't. Are you saying that the term 'array name', or equivalent, as you've
used it under this topic so far, was intended to embrace expressions that
evaluate to arrays as well as actual names of arrays? Is this how the
standard defines an array's name?

So doesn't f(*pc) convert our unnamed array into a pointer to its
first element?

Not really. Not the array. The reference to it.

I am aware that an object cannot spontaneously change its type. See the
first-post quote above for the intended meaning.

The array is the object (the storage) with its type.
I'm aware of that. That's why I never think of arrays as pointers.

Good. Now the next step is to do it also the other way around.

So we just forget about that then?

OK. Forget. The *array* is *not* used either. Plain and simple. You

use a struct/class. The array type is used by the copy constructor or the
assignment operator of that class type. Very different situation.

Yes, different situation. Nevertheless, it is one circumstance in which an
array is not treated like a pointer. I'm not sure why this shouldn't counted
among the cases in which an array is not treated like a pointer.

This argument started when I questioned Kevin Goodsell's statement:
"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*."

Whatever Kevin meant by 'c', I've been talking about the array 'c' and its
like, not the name 'c'. I am yet to be convinced that a discussion of the
treatment of an array should be confined to the usage of its name. If there
is any circumstance in which the usage of an array's name causes different
behaviour than an expression that evaluates to an array (e.g., *pc above, if
that is indeed not a name), then of course it should be pointed out, but
where the behaviour is the same in both cases, it seems to me more useful to
describe that behaviour in terms of any expression that evaluates to an
array (according to the appropriate type declaration) rather than array
names. Why be specific if you can be general? And for completeness, there's
no reason to exclude the treatment of arrays in other contexts, such as in
class/struct default assignment.

I didn't think the OP was asking about names.
I thought the question was about pointers and arrays.

And I did not answer to the OP talking about names.

I didn't either, but somehow they keep coming up.

Default assignment of structs needs to be learned
as much as anything else.

There is no such thing in C++. structs are class types.

Have I got this right? You are saying that there is no such thing as structs
in C++, yet structs are class types in C++?

DW

[Default User]

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.


Brian Rodenborn

[Alexander Terekhov]

Default User wrote:

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.

Really? How come? What do you mean by that?

regards,
alexander.

[White Wolf]

Default User wrote:

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.

For all I know I have asked you a question. If you cannot answer it just
say so. Nobody is perfect.

BTW your obsession with me is worrying. I state it second and last time for
you: I pay no special attention to you (unlike you to me) and I am not
interested in your paranoia. If you cannot answer a question just don't
post or post that.

--
WW aka Attila

[Default User]

Alexander Terekhov wrote:

Default User wrote:

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.

Really? How come? What do you mean by that?

I thought you and Wolfie was best buds, and you'd want to hear from him.


Brian Rodenborn

[White Wolf]

Default User wrote:

Alexander Terekhov wrote:

Default User wrote:

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.

Really? How come? What do you mean by that?

I thought you and Wolfie was best buds, and you'd want to hear from
him.

We are so much best buds that we have spent quite a considerable time
arguing and at that time I was indeed an asshole. :-) IIRC we have even
spent some time in each others killfile. But if people do not refuse to
think and listen to each other things work out.

--
WW aka Attila

[White Wolf]

White Wolf wrote:

We are so much best buds that we have spent quite a considerable time
arguing and at that time I was indeed an asshole. :-)

BTW me being an PITA at that time was due to my complete misunderstanding of
thread and SMP related issues - amongst many other. :-)

--
WW aka Attila

[Default User]

White Wolf wrote:

BTW your obsession with me is worrying.

Go troll somebody else.

Brian Rodenborn

[White Wolf]

Default User wrote:

White Wolf wrote:

BTW your obsession with me is worrying.

Go troll somebody else.

Again: I am not interested in you. The reason I answer your posts is
because of their content and technical inaccuracies and not because of your
person. Furthermore I am not trolling. If you have difficulty to
understand what trolling is, I suggest you look it up in the Jargon
dictionary.

--
WW aka Attila

[Default User]

White Wolf wrote:

Again: I am not interested in you.

Go troll somebody else.


Brian Rodenborn

[WW]

Default User wrote:

White Wolf wrote:

Again: I am not interested in you.

Go troll somebody else.

It is just so elevating to see how dedicated people can motivate others. At
the start of the day I did not have *any* motivation whatsoever to care
about you the least bit. By calling me troll quite a few times you have
changed my mind completely. So I have made some decisions:

1.) Until further decision of mine all of my code I will post will use the
struct keyword to define its classes

2.) I will never ever again react to any insult from you, I will simply
ignore that part of any communication you make, as long as it is legally
possible.

3.) Whenever I find the slightest logical or technical inaccuracy in your
posts I will point it out in public. Not because I want to waste my time on
hopeless people. On the contrary. Because I want to make sure that your
fallacies will not ruin the chance fopr newbies to understand the language.

Ever heard of self fulfilling prophecy? You thought I am after you. Now I
am.

--
WW aka Attila

[Default User]

WW wrote:

It is just so elevating to see how dedicated people can motivate others.

Go troll somebody else.

Brian Rodenborn

[Alexander Terekhov]

Default User wrote: < Nth time in a row >
[...]

Go troll somebody else.

http://aafp.org/afp/20030715/tips/15.html
(Repetitive Behaviors: a Clue to Early Dementia)

regards,
alexander.

[WW]

Alexander Terekhov wrote:

Default User wrote: < Nth time in a row >
[...]

Go troll somebody else.

http://aafp.org/afp/20030715/tips/15.html
(Repetitive Behaviors: a Clue to Early Dementia)

:-)

You must employ bodyguards soon. ;-)

--
WW aka Attila