By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,905 Members | 902 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,905 IT Pros & Developers. It's quick & easy.

difference for array in c and c++?

P: n/a
hi friends,
is ther any difference in array in c and array in c++?

Sep 25 '07 #1
Share this Question
Share on Google+
45 Replies


P: n/a
user923005 said:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
>hi friends,
is ther any difference in array in c and array in c++?

Sure, if it's an array of objects.
In both C and C++, there's no other kind of array than an array of objects
(in the C sense of the word, which is also as near as makes no odds the
C++ sense of the word).

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 25 '07 #2

P: n/a
user923005 wrote:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
>hi friends,
is ther any difference in array in c and array in c++?

Sure, if it's an array of objects.
Only if those are C++ types, if the code compiles as C, there isn't any
difference.

--
Ian Collins.
Sep 25 '07 #3

P: n/a
On Sep 25, 12:21 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
hi friends,
is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.

Only if those are C++ types, if the code compiles as C, there isn't any
difference.
Besides the difference for allocated memory management, the public
symbol names can also be different. C++ data types can be decorated
with name mangling stuff. So if you link to a public symbol compiled
in C and your program is C++ you may have to define the linkage with
extern "C".

Sep 25 '07 #4

P: n/a
On Sep 25, 12:06 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
hi friends,
is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.

In both C and C++, there's no other kind of array than an array of objects
(in the C sense of the word, which is also as near as makes no odds the
C++ sense of the word).

<snip>
In C++ the array operator [] can be overloaded to mean something
completely different than what it means in C.

Sep 25 '07 #5

P: n/a
user923005 wrote:
On Sep 25, 12:21 am, Ian Collins <ian-n...@hotmail.comwrote:
>user923005 wrote:
>>On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
hi friends,
is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.
Only if those are C++ types, if the code compiles as C, there isn't any
difference.

Besides the difference for allocated memory management, the public
symbol names can also be different. C++ data types can be decorated
with name mangling stuff. So if you link to a public symbol compiled
in C and your program is C++ you may have to define the linkage with
extern "C".
There need not be any difference for allocated memory management, malloc
works in C++. Name mangling applies to functions, not arrays.

I think the OP was asking about behavior of arrays, not the objects
stored in them, or how the memory they use is allocated.

--
Ian Collins.
Sep 25 '07 #6

P: n/a
user923005 said:
On Sep 25, 12:06 am, Richard Heathfield <r...@see.sig.invalidwrote:
>user923005 said:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
hi friends,
is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.

In both C and C++, there's no other kind of array than an array of
objects (in the C sense of the word, which is also as near as makes no
odds the C++ sense of the word).

<snip>

In C++ the array operator [] can be overloaded to mean something
completely different than what it means in C.
Of course, but that doesn't change the nature of arrays. It merely changes
the nature of the [] operator. And my point remains - that *all* arrays,
in both C and C++, are arrays of objects. So to say "if it's an array of
objects" is tautologically and redundantly superfluous.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 25 '07 #7

P: n/a
On Sep 25, 1:37 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 25, 12:21 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
hi friends,
is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.
Only if those are C++ types, if the code compiles as C, there isn't any
difference.
Besides the difference for allocated memory management, the public
symbol names can also be different. C++ data types can be decorated
with name mangling stuff. So if you link to a public symbol compiled
in C and your program is C++ you may have to define the linkage with
extern "C".

There need not be any difference for allocated memory management, malloc
works in C++. Name mangling applies to functions, not arrays.

I think the OP was asking about behavior of arrays, not the objects
stored in them, or how the memory they use is allocated.
C:\tmp>cl test.c t.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

test.c
Generating Code...
Compiling...
t.cpp
Generating Code...
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj
t.obj
test.obj : error LNK2019: unresolved external symbol _uiCpp referenced
in function _main
test.exe : fatal error LNK1120: 1 unresolved externals

C:\tmp>type test.c
#include <stdio.h>

extern unsigned int uiCpp[4];

int main(void)
{
printf("uiCpp[0] = %u\n", uiCpp[0]);
return 0;
}

C:\tmp>type t.cpp
unsigned int uiCpp[4] = {1};

C:\tmp>ren t.cpp t.c

C:\tmp>cl test.c t.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

test.c
t.c
Generating Code...
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj
t.obj

C:\tmp>

Sep 25 '07 #8

P: n/a
anto_frank:
hi friends,
is ther any difference in array in c and array in c++?

I program in both languages are there's no suprises when it comes to
arrays.

There's a good page on the web that has a finite list of all the
differences between C and C++ when it comes to their common subset...
can't remember the URL though, try Google for something like
"Differences C C++". Off the top of my head, here's a few of the
differences:

1: Character literals are int in C, char in C++.
2: Global variable are static in C, extern in C++ (...if I remember
correctly)

Martin
Sep 25 '07 #9

P: n/a
On Sep 25, 1:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:


On Sep 25, 12:06 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
hi friends,
is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.
In both C and C++, there's no other kind of array than an array of
objects (in the C sense of the word, which is also as near as makes no
odds the C++ sense of the word).
<snip>
In C++ the array operator [] can be overloaded to mean something
completely different than what it means in C.

Of course, but that doesn't change the nature of arrays. It merely changes
the nature of the [] operator. And my point remains - that *all* arrays,
in both C and C++, are arrays of objects. So to say "if it's an array of
objects" is tautologically and redundantly superfluous.
My point was that you should not count on a C++ array behaving like a
C array (it may or may not behave in a similar way). The objects in C+
+ are also (generally) quite different than C objects, which do not
have constructors or destructors.

Assigning an object to an array can have a very different meaning for
a struct, for instance.
In C++, the struct can have a constructor, and in C it cannot.
In short, there are subtle and important differences between arrays in
C and C++.
They are not the same.
C:\tmp\p\new>cl t.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

t.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

/out:t.exe
t.obj

C:\tmp\p\new>t
arr[2].a=5, arr[2].b=5,arr[2].x=3.571429

C:\tmp\p\new>type t.cpp
#include <stdio.h>

struct foo {
int a;
int b;
double x;
foo() {
a = 5;
b = 5;
x = (a * b) / 7.0;
}
};

int main()
{
struct foo arr[10];
printf("arr[2].a=%d, arr[2].b=%d,arr[2].x=%f\n", arr[2].a,
arr[2].b, arr[2].x);
return 0;
}

Sep 25 '07 #10

P: n/a
user923005 wrote:
On Sep 25, 1:37 am, Ian Collins <ian-n...@hotmail.comwrote:
>user923005 wrote:
>>On Sep 25, 12:21 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
>hi friends,
> is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.
Only if those are C++ types, if the code compiles as C, there isn't any
difference.
Besides the difference for allocated memory management, the public
symbol names can also be different. C++ data types can be decorated
with name mangling stuff. So if you link to a public symbol compiled
in C and your program is C++ you may have to define the linkage with
extern "C".
There need not be any difference for allocated memory management, malloc
works in C++. Name mangling applies to functions, not arrays.

I think the OP was asking about behavior of arrays, not the objects
stored in them, or how the memory they use is allocated.

C:\tmp>cl test.c t.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

test.c
Generating Code...
Compiling...
t.cpp
Generating Code...
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj
t.obj
test.obj : error LNK2019: unresolved external symbol _uiCpp referenced
in function _main
test.exe : fatal error LNK1120: 1 unresolved externals
I don't know what your compiler is doing, but _uiCpp isn't a mangled
name, I bet if you look in the assembler for both C and C++, the symbol
has the same name. The above appears to be the reverse of the situation
you cited above.

On my box:

CC -o t -c t.cc
cc -o test test.c
cc t test
../a.out
uiCpp[0] = 1

--
Ian Collins.
Sep 25 '07 #11

P: n/a
user923005 wrote:
On Sep 25, 1:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
>user923005 said:
>>On Sep 25, 12:06 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
>hi friends,
> is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.
In both C and C++, there's no other kind of array than an array of
objects (in the C sense of the word, which is also as near as makes no
odds the C++ sense of the word).
<snip>
In C++ the array operator [] can be overloaded to mean something
completely different than what it means in C.
Of course, but that doesn't change the nature of arrays. It merely changes
the nature of the [] operator. And my point remains - that *all* arrays,
in both C and C++, are arrays of objects. So to say "if it's an array of
objects" is tautologically and redundantly superfluous.

My point was that you should not count on a C++ array behaving like a
C array (it may or may not behave in a similar way). The objects in C+
+ are also (generally) quite different than C objects, which do not
have constructors or destructors.
A C++ array behaves exactly like a C one, what gets stored in the array
is another matter.
In short, there are subtle and important differences between arrays in
C and C++.
They are not the same.
They do behave the same, it's what they are arrays of than can differ.

--
Ian Collins.
Sep 25 '07 #12

P: n/a
On Sep 25, 2:20 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 25, 1:37 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 25, 12:21 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
hi friends,
is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.
Only if those are C++ types, if the code compiles as C, there isn't any
difference.
Besides the difference for allocated memory management, the public
symbol names can also be different. C++ data types can be decorated
with name mangling stuff. So if you link to a public symbol compiled
in C and your program is C++ you may have to define the linkage with
extern "C".
There need not be any difference for allocated memory management, malloc
works in C++. Name mangling applies to functions, not arrays.
I think the OP was asking about behavior of arrays, not the objects
stored in them, or how the memory they use is allocated.
C:\tmp>cl test.c t.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
test.c
Generating Code...
Compiling...
t.cpp
Generating Code...
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
/out:test.exe
test.obj
t.obj
test.obj : error LNK2019: unresolved external symbol _uiCpp referenced
in function _main
test.exe : fatal error LNK1120: 1 unresolved externals

I don't know what your compiler is doing, but _uiCpp isn't a mangled
name, I bet if you look in the assembler for both C and C++, the symbol
has the same name. The above appears to be the reverse of the situation
you cited above.

On my box:

CC -o t -c t.cc
cc -o test test.c
cc t test
./a.out
uiCpp[0] = 1
This is the symbol generated for a C++ file:
0004:00000000 ?uiCpp@@3PAIA 00417000 t.obj

This is the symbol generated for a C file:
0004:00000014 _uiCpp 00417014 tt.obj

As you can see, the C++ file has a name mangled symbol, and the C file
has the standard leading underscore in its public symbol.

It may sound like a defect, but in C++ if you declare an extern int
and then actually create an unsigned variable, then the linker won't
find it (hence saving you from a bug).

Not all compilers behave this way, but it is certainly within the
rules for public symbols.

Sep 25 '07 #13

P: n/a
On Sep 25, 2:23 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 25, 1:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
>On Sep 25, 12:06 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
hi friends,
is ther any difference in array in c and array in c++?
Sure, if it's an array of objects.
In both C and C++, there's no other kind of array than an array of
objects (in the C sense of the word, which is also as near as makes no
odds the C++ sense of the word).
<snip>
In C++ the array operator [] can be overloaded to mean something
completely different than what it means in C.
Of course, but that doesn't change the nature of arrays. It merely changes
the nature of the [] operator. And my point remains - that *all* arrays,
in both C and C++, are arrays of objects. So to say "if it's an array of
objects" is tautologically and redundantly superfluous.
My point was that you should not count on a C++ array behaving like a
C array (it may or may not behave in a similar way). The objects in C+
+ are also (generally) quite different than C objects, which do not
have constructors or destructors.

A C++ array behaves exactly like a C one, what gets stored in the array
is another matter.
In short, there are subtle and important differences between arrays in
C and C++.
They are not the same.

They do behave the same, it's what they are arrays of than can differ.
C arrays of structs cannot have constructors. C++ arrays of structs
can have constructors.
In my opinion, that is not the same behavior.
Sep 25 '07 #14

P: n/a
user923005 said:

<snip>
My point was that you should not count on a C++ array behaving like a
C array (it may or may not behave in a similar way). The objects in C+
+ are also (generally) quite different than C objects, which do not
have constructors or destructors.
Understood. Nevertheless, *my* point was that the objects in C++ are no
different from objects in C. Therefore, the subordinate clause in your
claim (in response to the question "is there any difference?") of "Sure,
if it's an array of objects" was IMHO redundant.

References:

Here is the C89 definition of an object:

* Object --- a region of data storage in the execution environment,
the contents of which can represent values.

And in C99:

3.14
1 object
region of data storage in the execution environment, the contents of which
can represent values.

And in C++98:

An object is a region of storage.

I am given to understand that C++ has undergone further standardisation
since 1998. If the later standard has changed the above definition, my
point may be invalid for post-1998 C++.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 25 '07 #15

P: n/a
user923005 wrote:
On Sep 25, 2:23 am, Ian Collins <ian-n...@hotmail.comwrote:
>user923005 wrote:
>>On Sep 25, 1:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
On Sep 25, 12:06 am, Richard Heathfield <r...@see.sig.invalidwrote:
>user923005 said:
>>On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
>>>hi friends,
>>> is ther any difference in array in c and array in c++?
>>Sure, if it's an array of objects.
>In both C and C++, there's no other kind of array than an array of
>objects (in the C sense of the word, which is also as near as makes no
>odds the C++ sense of the word).
><snip>
In C++ the array operator [] can be overloaded to mean something
completely different than what it means in C.
Of course, but that doesn't change the nature of arrays. It merely changes
the nature of the [] operator. And my point remains - that *all* arrays,
in both C and C++, are arrays of objects. So to say "if it's an array of
objects" is tautologically and redundantly superfluous.
My point was that you should not count on a C++ array behaving like a
C array (it may or may not behave in a similar way). The objects in C+
+ are also (generally) quite different than C objects, which do not
have constructors or destructors.
A C++ array behaves exactly like a C one, what gets stored in the array
is another matter.
>>In short, there are subtle and important differences between arrays in
C and C++.
They are not the same.
They do behave the same, it's what they are arrays of than can differ.

C arrays of structs cannot have constructors. C++ arrays of structs
can have constructors.
No, they can not. The structure may have a constructor, but the array
doesn't. It is just a plain old bloc of memory, no different from C.

--
Ian Collins.
Sep 25 '07 #16

P: n/a
user923005 wrote:
>
This is the symbol generated for a C++ file:
0004:00000000 ?uiCpp@@3PAIA 00417000 t.obj

This is the symbol generated for a C file:
0004:00000014 _uiCpp 00417014 tt.obj

As you can see, the C++ file has a name mangled symbol, and the C file
has the standard leading underscore in its public symbol.

It may sound like a defect, but in C++ if you declare an extern int
and then actually create an unsigned variable, then the linker won't
find it (hence saving you from a bug).

Not all compilers behave this way, but it is certainly within the
rules for public symbols.
Fair enough.

--
Ian Collins.
Sep 25 '07 #17

P: n/a
On Sep 25, 4:10 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 25, 2:23 am, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 25, 1:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
On Sep 25, 12:06 am, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
>On Sep 24, 11:20 pm, anto frank <j.antofrank...@gmail.comwrote:
>>hi friends,
>> is ther any difference in array in c and array in c++?
>Sure, if it's an array of objects.
In both C and C++, there's no other kind of array than an array of
objects (in the C sense of the word, which is also as near as makes no
odds the C++ sense of the word).
<snip>
In C++ the array operator [] can be overloaded to mean something
completely different than what it means in C.
Of course, but that doesn't change the nature of arrays. It merely changes
the nature of the [] operator. And my point remains - that *all* arrays,
in both C and C++, are arrays of objects. So to say "if it's an array of
objects" is tautologically and redundantly superfluous.
My point was that you should not count on a C++ array behaving like a
C array (it may or may not behave in a similar way). The objects in C+
+ are also (generally) quite different than C objects, which do not
have constructors or destructors.
A C++ array behaves exactly like a C one, what gets stored in the array
is another matter.
>In short, there are subtle and important differences between arrays in
C and C++.
They are not the same.
They do behave the same, it's what they are arrays of than can differ.
C arrays of structs cannot have constructors. C++ arrays of structs
can have constructors.

No, they can not. The structure may have a constructor, but the array
doesn't. It is just a plain old bloc of memory, no different from C.
Really, no different?

Did you know that you cannot safely memcpy or memmove structs in C++
because they may have constructors? Obviously, you can do this with
impunity in C.

These claims that C and C++ arrays behave in the same manner are
simply not true, and I do not care who says otherwise.

Sep 25 '07 #18

P: n/a
user923005 wrote:
On Sep 25, 4:10 am, Ian Collins <ian-n...@hotmail.comwrote:
>No, they can not. The structure may have a constructor, but the array
doesn't. It is just a plain old bloc of memory, no different from C.

Really, no different?

Did you know that you cannot safely memcpy or memmove structs in C++
because they may have constructors? Obviously, you can do this with
impunity in C.
If the array is an array of something valid in C, it behaves the same in
both languages. If the array is an array of something not valid in C,
the comparison is meaningless.
These claims that C and C++ arrays behave in the same manner are
simply not true, and I do not care who says otherwise.
Please explain the difference between int array[10] in C and C++.

--
Ian Collins.
Sep 25 '07 #19

P: n/a
On Sep 25, 1:45 pm, Ian Collins <ian-n...@hotmail.comwrote:
user923005 wrote:
On Sep 25, 4:10 am, Ian Collins <ian-n...@hotmail.comwrote:
No, they can not. The structure may have a constructor, but the array
doesn't. It is just a plain old bloc of memory, no different from C.
Really, no different?
Did you know that you cannot safely memcpy or memmove structs in C++
because they may have constructors? Obviously, you can do this with
impunity in C.

If the array is an array of something valid in C, it behaves the same in
both languages. If the array is an array of something not valid in C,
the comparison is meaningless.
Because a struct is not the same in C and C++, I partly agree with
you. If it compiles in C then it will behave very similarly.
However, because of constructors and operator overloading, C++ struct
arrays can behave in a manner that does not resemble C at all.
These claims that C and C++ arrays behave in the same manner are
simply not true, and I do not care who says otherwise.

Please explain the difference between int array[10] in C and C++.
If it is a public symbol, then the name can be mangled. If you want
to access it from C, then it may be necessary to give it extern "C"
linkage.

If it has been allocated with the new operator, then freeing it with
the free() function causes undefined behavior.

Because of the increased capability of structures in C++ verses C,
that is where the striking differences come into play.

It is possible (for instance) to have the operation:

struct bar foo[5], test;
foo[5] = test;

send an email in C++. In C, it is undefined behavior because test has
not been initialized.

Sep 25 '07 #20

P: n/a
On Sep 25, 2:00 pm, user923005 <dcor...@connx.comwrote:
[snip]
It is possible (for instance) to have the operation:

struct bar foo[5], test;
foo[5] = test;

send an email in C++. In C, it is undefined behavior because test has
not been initialized.
And also because the 6th element has not been allocated and C does not
allow operator overloading.

Sep 25 '07 #21

P: n/a
On Tue, 25 Sep 2007 14:00:52 -0700, user923005 wrote:
Because of the increased capability of structures in C++ verses C, that
is where the striking differences come into play.

It is possible (for instance) to have the operation:

struct bar foo[5], test;
foo[5] = test;

send an email in C++.
Is it any different from

struct bar foo, test;
foo = test;

? If not, then I don't believe it says anything about arrays.
In C, it is undefined behavior because test has
not been initialized.
In C, it is undefined behaviour because 5 >= 5 as you noted, but

struct bar foo[6], test;
foo[5] = test;

is allowed, even though test is uninitialised.
Sep 25 '07 #22

P: n/a
On Sep 25, 2:11 pm, Harald van D k <true...@gmail.comwrote:
On Tue, 25 Sep 2007 14:00:52 -0700, user923005 wrote:
Because of the increased capability of structures in C++ verses C, that
is where the striking differences come into play.
It is possible (for instance) to have the operation:
struct bar foo[5], test;
foo[5] = test;
send an email in C++.

Is it any different from

struct bar foo, test;
foo = test;

? If not, then I don't believe it says anything about arrays.
In C, it is undefined behavior because test has
not been initialized.

In C, it is undefined behaviour because 5 >= 5 as you noted, but

struct bar foo[6], test;
foo[5] = test;

is allowed, even though test is uninitialised.
Is there some sort of disclaimer for structs that I am not aware of?
{Caveat: I am assuming automatic and not static storage duration}
Under 6.2.6.1 General, we have this:

"5 Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation and is read by an lvalue expression that does not have
character type, the behavior is defined. If such a representation is
produced by a side effect that modifies all or any part of the object
by an lvalue expression that does not have character type, the
behavior is undefined.41) Such a representation is called
a trap representation."
"41) Thus, an automatic variable can be initialized to a trap
representation without causing undefined behavior, but the value of
the variable cannot be used until a proper value is stored in it."

§6.2.6.1 Language 37

Sep 25 '07 #23

P: n/a
user923005 <dc*****@connx.comwrites:
On Sep 25, 2:11 pm, Harald van D k <true...@gmail.comwrote:
[...]
>In C, it is undefined behaviour because 5 >= 5 as you noted, but

struct bar foo[6], test;
foo[5] = test;

is allowed, even though test is uninitialised.

Is there some sort of disclaimer for structs that I am not aware of?
{Caveat: I am assuming automatic and not static storage duration}
Under 6.2.6.1 General, we have this:

"5 Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation and is read by an lvalue expression that does not have
character type, the behavior is defined. If such a representation is
produced by a side effect that modifies all or any part of the object
by an lvalue expression that does not have character type, the
behavior is undefined.41) Such a representation is called
a trap representation."
"41) Thus, an automatic variable can be initialized to a trap
representation without causing undefined behavior, but the value of
the variable cannot be used until a proper value is stored in it."

§6.2.6.1 Language 37
Yes. N1256 6.2.6.1p6:

When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values. The value of a structure or union object is
never a trap representation, even though the value of a member of
the structure or union object may be a trap representation.

The wording was changed by TC2. The original C99 standard says:

When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values. The values of padding bytes shall not affect
whether the value of such an object is a trap
representation. Those bits of a structure or union object that are
in the same byte as a bit-field member, but are not part of that
member, shall similarly not affect whether the value of such an
object is a trap representation.

See Defect Report #222,
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_222.htm>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 25 '07 #24

P: n/a
Ian Collins wrote:
user923005 wrote:
.... snip ...
>
If the array is an array of something valid in C, it behaves the
same in both languages. If the array is an array of something not
valid in C, the comparison is meaningless.
>These claims that C and C++ arrays behave in the same manner are
simply not true, and I do not care who says otherwise.

Please explain the difference between int array[10] in C and C++.
int new[22];
int class[22];

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 25 '07 #25

P: n/a
CBFalconer wrote:
Ian Collins wrote:
>user923005 wrote:
.... snip ...
>If the array is an array of something valid in C, it behaves the
same in both languages. If the array is an array of something not
valid in C, the comparison is meaningless.
>>These claims that C and C++ arrays behave in the same manner are
simply not true, and I do not care who says otherwise.
Please explain the difference between int array[10] in C and C++.

int new[22];
int class[22];
That doesn't answer my question.

--
Ian Collins.
Sep 26 '07 #26

P: n/a
On Sep 26, 9:00 am, user923005 <dcor...@connx.comwrote:
It is possible (for instance) to have the operation:

struct bar foo[5], test;
foo[5] = test;

send an email in C++. In C, it is undefined behavior because test has
not been initialized.
This causes undefined behaviour in C++, regardless
of context[*].

It is certainly possible that undefined behaviour
could cause an email to be sent.

[*] I'm sure someone will shoot this down now that
I've said it, e.g. it would not be UB if the whole
thing were enclosed in quote marks

Sep 26 '07 #27

P: n/a
On Sep 25, 9:11 pm, Martin Wells <war...@eircom.netwrote:
2: Global variable are static in C, extern in C++ (...if I remember
correctly)
To be precise: variables declared at file scope and
without linkage (i.e. without 'static' or 'extern'),
have external linkage in both languages -- except for
if the variable is declared 'const', then in C++ only
it has internal linkage.

Sep 26 '07 #28

P: n/a
Ian Collins wrote:
CBFalconer wrote:
>Ian Collins wrote:
>>user923005 wrote:
.... snip ...
>>If the array is an array of something valid in C, it behaves the
same in both languages. If the array is an array of something not
valid in C, the comparison is meaningless.

These claims that C and C++ arrays behave in the same manner are
simply not true, and I do not care who says otherwise.

Please explain the difference between int array[10] in C and C++.

int new[22];
int class[22];

That doesn't answer my question.
It answers user923005's statement, thus obviating your question :-)

Please don't email copies of your postings.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 26 '07 #29

P: n/a
On Sep 25, 9:18 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Sep 26, 9:00 am, user923005 <dcor...@connx.comwrote:
It is possible (for instance) to have the operation:
struct bar foo[5], test;
foo[5] = test;
send an email in C++. In C, it is undefined behavior because test has
not been initialized.

This causes undefined behaviour in C++, regardless
of context[*].

It is certainly possible that undefined behaviour
could cause an email to be sent.
[*] I'm sure someone will shoot this down now that
I've said it, e.g. it would not be UB if the whole
thing were enclosed in quote marks

In C++, I can create constructors for the struct so that they are
initialized.
In C++ I can overload the [] operator so that it behaves normally for
index values from 0 to ARR_SIZE-1, and performs a system call to send
an email if the array bounds are exceeded.
I don't think that it causes undefined behavior in C++ (unless I want
it to).
Sep 26 '07 #30

P: n/a
user923005 wrote:
On Sep 25, 9:18 pm, Old Wolf <oldw...@inspire.net.nzwrote:
>On Sep 26, 9:00 am, user923005 <dcor...@connx.comwrote:
>>It is possible (for instance) to have the operation:
struct bar foo[5], test;
foo[5] = test;
send an email in C++. In C, it is undefined behavior because test has
not been initialized.
This causes undefined behaviour in C++, regardless
of context[*].

It is certainly possible that undefined behaviour
could cause an email to be sent.

[*] I'm sure someone will shoot this down now that
I've said it, e.g. it would not be UB if the whole
thing were enclosed in quote marks

In C++, I can create constructors for the struct so that they are
initialized.
In C++ I can overload the [] operator so that it behaves normally for
index values from 0 to ARR_SIZE-1, and performs a system call to send
an email if the array bounds are exceeded.
You can overload the [] operator on a struct, but not the global
operator [], so you do have undefined behavior.

foo is an array of 5 bars.

foo[5] is one past the end.

--
Ian Collins.
Sep 26 '07 #31

P: n/a
On Sep 26, 9:15 pm, user923005 <dcor...@connx.comwrote:
On Sep 25, 9:18 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Sep 26, 9:00 am, user923005 <dcor...@connx.comwrote:
It is possible (for instance) to have the operation:
struct bar foo[5], test;
foo[5] = test;
This causes undefined behaviour in C++, regardless
of context[*].

In C++ I can overload the [] operator so that it behaves normally
for index values from 0 to ARR_SIZE-1, and performs a system call
to send an email if the array bounds are exceeded.
Actually you can't. The meaning of [] for arrays is fixed
and cannot be 'overloaded'. Note, this is off-topic for c.l.c,
so if you disagree then post an example program on c.l.c++ or
something.

Sep 26 '07 #32

P: n/a
On Sep 26, 3:04 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Sep 26, 9:15 pm, user923005 <dcor...@connx.comwrote:
On Sep 25, 9:18 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Sep 26, 9:00 am, user923005 <dcor...@connx.comwrote:
It is possible (for instance) to have the operation:
struct bar foo[5], test;
foo[5] = test;
This causes undefined behaviour in C++, regardless
of context[*].
In C++ I can overload the [] operator so that it behaves normally
for index values from 0 to ARR_SIZE-1, and performs a system call
to send an email if the array bounds are exceeded.

Actually you can't. The meaning of [] for arrays is fixed
and cannot be 'overloaded'. Note, this is off-topic for c.l.c,
so if you disagree then post an example program on c.l.c++ or
something.
C:\tmp>cl /EHsc foo.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

foo.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

/out:foo.exe
foo.obj

C:\tmp>foo
name Delta Romeo Charlie
address1 1122 Boogie Woogie Avenue
address2 Apt. C-305
city Federal Way
state WA
zip 98023
phone 253-555-1212
Error! Address (4294967295) is outside range of (0-30)
Error! Address (50) is outside range of (0-30)

C:\tmp>type foo.cpp
#include <cassert>
#include <cstdlib>
#include <cstring>
#include <iostream>

using namespace std;

struct arr_test {

char name[30];
char address0[50];
char address1[50];
char city[50];
char state[3];
char zip[15];
char phone[15];

unsigned numCols;
struct arr_test *arr_list;

arr_test & operator[] (unsigned column) {
if (column < 0 || column >= numCols)
{
std::cout << "Error! Address (" << column << ") is outside
range of (0-" << numCols <<")" << std::endl;
}
return arr_list[column];
}

arr_test(void) {
arr_list = NULL;
}
arr_test(unsigned size) {
numCols = size;
arr_list = new struct arr_test[size];
}
};

int main(void)
{
arr_test foo(30);
arr_test bar;
strncpy(foo[7].name, "Delta Romeo Charlie", sizeof foo[7].name);
strncpy(foo[7].address0, "1122 Boogie Woogie Avenue", sizeof
foo[7].address0);
strncpy(foo[7].address1, "Apt. C-305", sizeof foo[7].address1);
strncpy(foo[7].city, "Federal Way", sizeof foo[7].city);
strncpy(foo[7].state, "WA", sizeof foo[7].state);
strncpy(foo[7].zip, "98023", sizeof foo[7].zip);
strncpy(foo[7].phone, "253-555-1212", sizeof foo[7].phone);

bar = foo[7];
std::cout << "name " << bar.name << std::endl;
std::cout << "address1 " << bar.address0 << std::endl;
std::cout << "address2 " << bar.address1 << std::endl;
std::cout << "city " << bar.city << std::endl;
std::cout << "state " << bar.state << std::endl;
std::cout << "zip " << bar.zip << std::endl;
std::cout << "phone " << bar.phone << std::endl;
bar = foo[-1];
bar = foo[50];
return 0;
}

Sep 27 '07 #33

P: n/a
user923005 wrote:
On Sep 26, 3:04 pm, Old Wolf <oldw...@inspire.net.nzwrote:
>On Sep 26, 9:15 pm, user923005 <dcor...@connx.comwrote:
>>On Sep 25, 9:18 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Sep 26, 9:00 am, user923005 <dcor...@connx.comwrote:
It is possible (for instance) to have the operation:
struct bar foo[5], test;
foo[5] = test;
This causes undefined behaviour in C++, regardless
of context[*].
In C++ I can overload the [] operator so that it behaves normally
for index values from 0 to ARR_SIZE-1, and performs a system call
to send an email if the array bounds are exceeded.
Actually you can't. The meaning of [] for arrays is fixed
and cannot be 'overloaded'. Note, this is off-topic for c.l.c,
so if you disagree then post an example program on c.l.c++ or
something.
<snip>

You have done exactly what "Old Wolf" and I said you could, added
operator [] to a struct. You have not changed the meaning of [] for
arrays, which can't be done in either C or C++.

--
Ian Collins.
Sep 27 '07 #34

P: n/a
user923005 said:
On Sep 26, 3:04 pm, Old Wolf <oldw...@inspire.net.nzwrote:
>On Sep 26, 9:15 pm, user923005 <dcor...@connx.comwrote:
<snip>
>>
In C++ I can overload the [] operator so that it behaves normally
for index values from 0 to ARR_SIZE-1, and performs a system call
to send an email if the array bounds are exceeded.

Actually you can't. The meaning of [] for arrays is fixed
and cannot be 'overloaded'. Note, this is off-topic for c.l.c,
so if you disagree then post an example program on c.l.c++ or
something.

C:\tmp>cl /EHsc foo.cpp
The claim is that you can't legally do this. Demonstrating that you can
nevertheless do this on some particular implementation does not mean that
you can legally do this, any more than a demonstration of erroneous input
stream clearing with fflush(stdin) means that fflush(stdin) is anything
other than illegal.

The real user923005 would have realised this. Oh, *now* I see what's going
on...

You are Ioannis Vranos, and I claim my five pounds!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 27 '07 #35

P: n/a
On Sep 27, 1:11 pm, user923005 <dcor...@connx.comwrote:
On Sep 26, 3:04 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Sep 26, 9:15 pm, user923005 <dcor...@connx.comwrote:
On Sep 26, 9:00 am, user923005 <dcor...@connx.comwrote:
struct bar foo[5], test;
foo[5] = test;
This causes undefined behaviour in C++, regardless
of context[*].

strncpy(foo[7].name, "Delta Romeo Charlie", sizeof foo[7].name);
strncpy(foo[7].address0, "1122 Boogie Woogie Avenue", sizeof
[snip...]

None of this stuff you just posted contains the code
under discussion:
struct bar foo[5], test;
foo[5] = test;
Sep 27 '07 #36

P: n/a
On Sep 27, 2:34 pm, Richard Heathfield <r...@see.sig.invalidwrote:
The claim is that you can't legally do this. Demonstrating that you can
nevertheless do this on some particular implementation does not mean that
you can legally do this, any more than a demonstration of erroneous input
stream clearing with fflush(stdin) means that fflush(stdin) is anything
other than illegal.
Not to mention that he didn't even demonstrate the
effect called for.
You are Ioannis Vranos, and I claim my five pounds!
Ding ding!

Sep 27 '07 #37

P: n/a
"user923005" <dc*****@connx.coma écrit dans le message de news:
11*********************@k79g2000hse.googlegroups.c om...
C:\tmp>type foo.cpp
#include <cassert>
#include <cstdlib>
#include <cstring>
#include <iostream>

using namespace std;

struct arr_test {

char name[30];
char address0[50];
char address1[50];
char city[50];
char state[3];
char zip[15];
char phone[15];
[...]
};

int main(void)
{
arr_test foo(30);
arr_test bar;
strncpy(foo[7].name, "Delta Romeo Charlie", sizeof foo[7].name);
strncpy(foo[7].address0, "1122 Boogie Woogie Avenue", sizeof
foo[7].address0);
strncpy(foo[7].address1, "Apt. C-305", sizeof foo[7].address1);
strncpy(foo[7].city, "Federal Way", sizeof foo[7].city);
strncpy(foo[7].state, "WA", sizeof foo[7].state);
strncpy(foo[7].zip, "98023", sizeof foo[7].zip);
strncpy(foo[7].phone, "253-555-1212", sizeof foo[7].phone);
strncpy can be misused in C++ just like in C.
Using it in a thread focussing on array bound checking is quite pervert.
Especially in view of how you use the char array members below.
bar = foo[7];
std::cout << "name " << bar.name << std::endl;
std::cout << "address1 " << bar.address0 << std::endl;
std::cout << "address2 " << bar.address1 << std::endl;
std::cout << "city " << bar.city << std::endl;
std::cout << "state " << bar.state << std::endl;
std::cout << "zip " << bar.zip << std::endl;
std::cout << "phone " << bar.phone << std::endl;
bar = foo[-1];
bar = foo[50];
return 0;
}
There is just one thing to remember about strncpy: DONT USE IT !

--
Chqrlie.
Sep 27 '07 #38

P: n/a
Keith Thompson wrote:
Old Wolf <ol*****@inspire.net.nzwrites:
.... snip ...
>>
One system I am working on right now, some operating system
functions take an 8-byte char array to indicate which module you
request. If it is shorter than 8 bytes, then a null character
indicates the end of the module name. strncpy is perfect for
this situation.

Well, almost perfect. If only a single null character is
required to terminate a string^H^H^H^H^H^H character sequence
shorter than 8 bytes, then strncpy()'s padding of the entire
remainder of the array with null characters is wasteful. But if
it's only 8 bytes long, the waste is minimal. Then again, if
there's an advantage to zero-padding the entire array, then yes,
strncpy is perfect for the job.
What zero padding? It's up to you. From N869:

7.21.2.4 The strncpy function

Synopsis
[#1]
#include <string.h>
char *strncpy(char * restrict s1,
const char * restrict s2,
size_t n);

Description

[#2] The strncpy function copies not more than n characters
(characters that follow a null character are not copied)
from the array pointed to by s2 to the array pointed to by
s1.246) If copying takes place between objects that
overlap, the behavior is undefined.

[#3] If the array pointed to by s2 is a string that is
shorter than n characters, null characters are appended to
the copy in the array pointed to by s1, until n characters
in all have been written.

Returns

[#4] The strncpy function returns the value of s1.

____________________

246Thus, if there is no null character in the first n
characters of the array pointed to by s2, the result will
not be null-terminated.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 28 '07 #39

P: n/a
Keith Thompson wrote, On 27/09/07 23:29:
Richard <rg****@gmail.comwrites:
>"Charlie Gordon" <ne**@chqrlie.orgwrites:
<snip>
>>Almost all uses of strncpy are misuses!
In your code possibly. I don't know. I know not in mine and the various
projects I have worked on over the years. People code with regard to
what the API does you see. And it gets reviewed.

Do you *really* write code that uses the data format produced by
strncpy()? The format in question is a fixed-width array of N
characters, padded with null characters if and only if there are fewer
than N significant characters. (By contrast, a C string is always
terminated with a null character, and characters past the terminating
null needn't be set to zero.)

I've seen that format used for file names in very old versions of
Unix, but nowhere else that I can recall.
I can certainly believe it since I work with a similar (but not
identical) format, a fixed number of characters padded with spaces and
no null character anywhere near it. One reason for using fixed width
"strings" is databases where you want each field in a row to take
exactly the same number of characters so you can do a lot of things very
easily, and you would not want to waist a byte for each character field
so you do not null terminate them.
--
Flash Gordon
Sep 28 '07 #40

P: n/a
CBFalconer wrote:
>
Keith Thompson wrote:
Old Wolf <ol*****@inspire.net.nzwrites:
... snip ...
>
One system I am working on right now, some operating system
functions take an 8-byte char array to indicate which module you
request. If it is shorter than 8 bytes, then a null character
indicates the end of the module name. strncpy is perfect for
this situation.
Well, almost perfect. If only a single null character is
required to terminate a string^H^H^H^H^H^H character sequence
shorter than 8 bytes, then strncpy()'s padding of the entire
remainder of the array with null characters is wasteful. But if
it's only 8 bytes long, the waste is minimal. Then again, if
there's an advantage to zero-padding the entire array, then yes,
strncpy is perfect for the job.

What zero padding?
This zero padding:
From N869:
null characters are appended to
the copy in the array pointed to by s1,
--
pete
Sep 28 '07 #41

P: n/a
CBFalconer wrote:
Keith Thompson wrote:
>Old Wolf <ol*****@inspire.net.nzwrites:
... snip ...
>>One system I am working on right now, some operating system
functions take an 8-byte char array to indicate which module you
request. If it is shorter than 8 bytes, then a null character
indicates the end of the module name. strncpy is perfect for
this situation.
Well, almost perfect. If only a single null character is
required to terminate a string^H^H^H^H^H^H character sequence
shorter than 8 bytes, then strncpy()'s padding of the entire
remainder of the array with null characters is wasteful. But if
it's only 8 bytes long, the waste is minimal. Then again, if
there's an advantage to zero-padding the entire array, then yes,
strncpy is perfect for the job.

What zero padding? It's up to you. From N869:

7.21.2.4 The strncpy function

Synopsis
[#1]
#include <string.h>
char *strncpy(char * restrict s1,
const char * restrict s2,
size_t n);

Description

[#2] The strncpy function copies not more than n characters
(characters that follow a null character are not copied)
from the array pointed to by s2 to the array pointed to by
s1.246) If copying takes place between objects that
overlap, the behavior is undefined.

[#3] If the array pointed to by s2 is a string that is
shorter than n characters, null characters are appended to
the copy in the array pointed to by s1, until n characters
in all have been written.

Returns

[#4] The strncpy function returns the value of s1.

____________________

246Thus, if there is no null character in the first n
characters of the array pointed to by s2, the result will
not be null-terminated.
If you need an action similar to strncpy(), but you must have
null termination... you can do something like this:

char dstr[40], src[] = "This is text";

dstr[0] = '\0';

strncat(dstr,src,6);
Unlike strncpy(), strncat() *does* guarantee null termination.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Sep 28 '07 #42

P: n/a
Keith Thompson <ks***@mib.orgwrites:
Do you *really* write code that uses the data format produced by
strncpy()? The format in question is a fixed-width array of N
characters, padded with null characters if and only if there are fewer
than N significant characters. (By contrast, a C string is always
terminated with a null character, and characters past the terminating
null needn't be set to zero.)

I've seen that format used for file names in very old versions of
Unix, but nowhere else that I can recall.
I used to be very much more common, I think. The file name example is
a good one and I've seen it in other old database-like applications.
I even peeked into a linker once that used padded 6-byte arrays for
names to see if that could be changed. I decided against fiddling
with it.

Apart from the obvious advantage of indexed look-ups, the fixed length
and forced padding made comparisons quite fast on many systems (for
short lengths, at least). Despite that, there are far too many
drawbacks to it to recommend it for a new project.

--
Ben.
Sep 28 '07 #43

P: n/a
"Charles Richmond" <fr*****@tx.rr.coma écrit dans le message de news:
46************@tx.rr.com...
>
If you need an action similar to strncpy(), but you must have
null termination... you can do something like this:

char dstr[40], src[] = "This is text";

dstr[0] = '\0';

strncat(dstr,src,6);
Unlike strncpy(), strncat() *does* guarantee null termination.
Yes, but the argument for the limit is error prone. Compare:

snprintf(dstr, sizeof(dstr), "%s", src);

dstr[0] = '\0';
strncat(dstr, src, sizeof(dstr) - 1);

using strncat for copy with truncation and zero termination is prone to
off-by-one errors.

--
Chqrlie.
Sep 28 '07 #44

P: n/a
"anto frank" <j.************@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
hi friends,
is ther any difference in array in c and array in c++?
when using types without constructors, destructors.. etc (in C++, a class is
a type), the behaviour should be almost the same.

there is one difference, if i remember right from stroustrup's book: that in
C++ its allowed (and required) to access 1 beyond the array bounds..but
check it up..
there is also a difference with respect initiaization of char array by a
string...

Sep 28 '07 #45

P: n/a
"Ravishankar S" <ra***********@in.bosch.comwrites:
"anto frank" <j.************@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
>hi friends,
is ther any difference in array in c and array in c++?

when using types without constructors, destructors.. etc (in C++, a class is
a type), the behaviour should be almost the same.

there is one difference, if i remember right from stroustrup's book: that in
C++ its allowed (and required) to access 1 beyond the array bounds..but
check it up..
In C, it's legal to construct a pointer just past the end of an array;
it's not legal to dereference such a pointer. I suspect C++ has the
same rules, but I'm not sure.
there is also a difference with respect initiaization of char array by a
string...
In C, this:

char arr[3] = "abc";

initializes arr to {'a', 'b', 'c'} with no terminating '\0'. This is
the only case (when the length of the literal exactly matches the
length of the array) where a string literal initializer results in the
initialized object not being '\0'-terminated.

In C++, I believe the declaration would be rejected by the compiler,
so string literal initializers always '\0'-terminate the target
object.

I don't know if I'd call that a difference between C arrays and C++
arrays (and let's not debate the point; it really doesn't matter).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 28 '07 #46

This discussion thread is closed

Replies have been disabled for this discussion.