Sorry for this very dumb question, but I've clearly got a long way to go!
Can someone please help me pass an array into a function. Here's a starting
point.
void TheMainFunc()
{
// Body of code...
TCHAR myArray[512];
DoStuff(myArray);
}
void DoStuff(TCHAR theArray)
{
...
}
I can't quite get my head around what the variable "myArray" is - is it a
pointer to a memory address that would hold a TCHAR (a wide char if
UNICODE)?
Thanks
John
--
---
If you need to reply personally, append "text" to the domain name in my
email adr.
Thanks
58  10014 
jr wrote: Sorry for this very dumb question, but I've clearly got a long way to
go! Can someone please help me pass an array into a function.
You cannot pass arrays into functions. Usually, a pointer to the array's
first element is passed instead.
Here's a starting point.
void TheMainFunc()
{
// Body of code...
TCHAR myArray[512];
DoStuff(myArray);
}
void DoStuff(TCHAR theArray)
{
...
}
I can't quite get my head around what the variable "myArray" is - is
it a pointer to a memory address that would hold a TCHAR (a wide char
if UNICODE)?
myArray is an array of TCHAR. Your DoStuff function takes a parameter of
type TCHAR, i.e. _one_ character.
Try:
void DoStuff(TCHAR* theArray)
When you pass the array to DoStuff, it will be automatically converted
into a pointer to its first element.
On Mon, 19 Jan 2004 23:54:58 -0000 in comp.lang.c++, "jr"
<jo***@tele.co.uk> was alleged to have written: TCHAR myArray[512];
DoStuff(myArray);
}
void DoStuff(TCHAR theArray)
{
void DoStuff(TCHAR * theArray)
{
I can't quite get my head around what the variable "myArray" is - is it a
pointer to a memory address that would hold a TCHAR (a wide char if
UNICODE)?
No, it's not a pointer, it's the actual storage for 256 instances of
TCHAR. But you often may refer to it as if it was a pointer, and C is
very ambivalent about that, converting the array variable name to a
pointer with little provocation where non-array types would require
operator& to get the pointer. C++ would probably prefer to consistently
require the operator&, but goes along with C for compatibility.
David Harmon wrote: TCHAR myArray[512];
I can't quite get my head around what the variable "myArray" is - is
it a pointer to a memory address that would hold a TCHAR (a wide char
if UNICODE)?
No, it's not a pointer, it's the actual storage for 256 instances of
TCHAR.
Sure about that? ;-)
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... jr wrote:
Sorry for this very dumb question, but I've clearly got a long way to
go! Can someone please help me pass an array into a function.
You cannot pass arrays into functions. Usually, a pointer to the array's
first element is passed instead.
Of course you pass arrays into functions:
#include <iostream>
void foo(char arr[]){
std::cout<< arr<<'\n';
arr[5]='!';
}
int main( )
{
char arr[10] = "hello";
foo(arr);
std::cout<< arr<<'\n';
}
Also if you alter the array inside the function the original is also
altered.
<snip>
HTH.
On Tue, 20 Jan 2004 01:55:11 +0100 in comp.lang.c++, Rolf Magnus
<ra******@t-online.de> was alleged to have written: David Harmon wrote:
TCHAR myArray[512];I can't quite get my head around what the variable "myArray" is - is
it a pointer to a memory address that would hold a TCHAR (a wide char
if UNICODE)?
No, it's not a pointer, it's the actual storage for 256 instances of
TCHAR.
Sure about that? ;-)
Oopsie. I didn't think he really needed the full 512.
On Tue, 20 Jan 2004 01:34:21 -0000, "Jumbo"
<pcr1000011<nospam>@uko2.co.uk> wrote in comp.lang.c++:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... jr wrote:
Sorry for this very dumb question, but I've clearly got a long way to
go! Can someone please help me pass an array into a function.
You cannot pass arrays into functions. Usually, a pointer to the array's
first element is passed instead.
Of course you pass arrays into functions:
No, you can't.
From the ISO C++ standard, "5.2.2 Function call", paragraph 7:
"The lvalue tor value (4.1), array to pointer (4.2), and function to
pointer (4.3) standard conversions are performed on the argument
expression."
The name of an array used as a function call argument is always
converted to a pointer to its first element.
But you can pass an array to a function if it is enclosed in a struct
or class and you pass an instance of the struct or class by value.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Hi jr,
when u declare an array in c or c++, the variable name is a
pointer to the first element of the array. So u can treat the variable
name as a pointer. In your case myArray is a pointer to a TCHAR. (
similar to TCHAR * myArray ).
as far as your function signature goes, in order for it to compile
successfully it must be either of these 2 i guess..
void DoStuff( TCHAR * theArray )
{
}
or
void DoStuff( TCHAR theArray[] )
{
}
Hi All,
This is my first post and reply. So plz bear with my mistakes, if
any. But for jr, i hope there are no mistakes.
Thanks and Regards,
Arun Prakash. B
"jr" <jo***@tele.co.uk> wrote in message news:<bu**********@newsg3.svr.pol.co.uk>... Sorry for this very dumb question, but I've clearly got a long way to go!
Can someone please help me pass an array into a function. Here's a starting
point.
void TheMainFunc()
{
// Body of code...
TCHAR myArray[512];
DoStuff(myArray);
}
void DoStuff(TCHAR theArray)
{
...
}
I can't quite get my head around what the variable "myArray" is - is it a
pointer to a memory address that would hold a TCHAR (a wide char if
UNICODE)?
Thanks
John
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:kr********************************@4ax.com... On Tue, 20 Jan 2004 01:34:21 -0000, "Jumbo"
<pcr1000011<nospam>@uko2.co.uk> wrote in comp.lang.c++:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... jr wrote:
> Sorry for this very dumb question, but I've clearly got a long way
to > go! Can someone please help me pass an array into a function.
You cannot pass arrays into functions. Usually, a pointer to the
array's first element is passed instead.
Of course you pass arrays into functions:
No, you can't.
From the ISO C++ standard, "5.2.2 Function call", paragraph 7:
"The lvalue tor value (4.1), array to pointer (4.2), and function to
pointer (4.3) standard conversions are performed on the argument
expression."
The name of an array used as a function call argument is always
converted to a pointer to its first element.
But you can pass an array to a function if it is enclosed in a struct
or class and you pass an instance of the struct or class by value.
Yip :-)
Jumbo wrote:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... jr wrote:
> Sorry for this very dumb question, but I've clearly got a long way
> to go! Can someone please help me pass an array into a function.
You cannot pass arrays into functions. Usually, a pointer to the
array's first element is passed instead.
Of course you pass arrays into functions:
#include <iostream>
void foo(char arr[]){
arr is not an array, but a pointer to its first element. You can see
that it's not an array, because it doesn't have a size between its [],
and arrays _always_ have a size. The only place where this is allowed
is if you define an array and initialize it, so the size can be
determined from the initializer, like:
char c[] = "Hello, world\n";
std::cout<< arr<<'\n';
arr[5]='!';
}
int main( )
{
char arr[10] = "hello";
foo(arr);
std::cout<< arr<<'\n';
}
Also if you alter the array inside the function the original is also
altered.
Yes, that's because you didn't pass the array. If you had done that, the
function would have a copy of it and the original couldn't be modified
by that function.
Jack Klein wrote: On Tue, 20 Jan 2004 01:34:21 -0000, "Jumbo"
<pcr1000011<nospam>@uko2.co.uk> wrote in comp.lang.c++:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com...
jr wrote:
Sorry for this very dumb question, but I've clearly got a long way to
go! Can someone please help me pass an array into a function.
You cannot pass arrays into functions. Usually, a pointer to the array's
first element is passed instead.
Of course you pass arrays into functions:
No, you can't.
From the ISO C++ standard, "5.2.2 Function call", paragraph 7:
"The lvalue tor value (4.1), array to pointer (4.2), and function to
pointer (4.3) standard conversions are performed on the argument
expression."
The name of an array used as a function call argument is always
converted to a pointer to its first element.
But you can pass an array to a function if it is enclosed in a struct
or class and you pass an instance of the struct or class by value.
Those conversions aren't always performed, because they're not always
necessary. Here's an example of passing an array by value. Without the
explicit template argument, the decay to a pointer type does take place.
#include <iostream>
template< typename T >
void f_by_value( T t )
{
t[ 0 ] = 1;
}
int main( )
{
int array[ ] = { 0 };
f_by_value< int[ 1 ] >( array );
std::cout << array[ 0 ] << '\n';
}
Jeff Schwab wrote: The name of an array used as a function call argument is always
converted to a pointer to its first element.
But you can pass an array to a function if it is enclosed in a struct
or class and you pass an instance of the struct or class by value.
Those conversions aren't always performed, because they're not always
necessary. Here's an example of passing an array by value. Without
the explicit template argument, the decay to a pointer type does take
place.
#include <iostream>
template< typename T >
void f_by_value( T t )
{
t[ 0 ] = 1;
}
int main( )
{
int array[ ] = { 0 };
f_by_value< int[ 1 ] >( array );
std::cout << array[ 0 ] << '\n';
}
Hmm, is that really standard conforming? Your program does work as one
would expect if the array were passed by value on gcc 3.3.2, but if I
modify the example to print the value of t[0] in f_by_value() before
modifying it, it turns out to be uninitialized and not 0 as expected.
Similar, if I use a class instead of int, my class's copy constructor
is not called. So which part is non-conforming here? The fact that it
accepts an array by value or the fact that the objects are not properly
copied? Or is there some other magic involved that just tricks us into
thinking it'S pass-by-value?
Rolf Magnus wrote: Jeff Schwab wrote:
The name of an array used as a function call argument is always
converted to a pointer to its first element.
But you can pass an array to a function if it is enclosed in a struct
or class and you pass an instance of the struct or class by value.
Those conversions aren't always performed, because they're not always
necessary. Here's an example of passing an array by value. Without
the explicit template argument, the decay to a pointer type does take
place.
#include <iostream>
template< typename T >
void f_by_value( T t )
{
t[ 0 ] = 1;
}
int main( )
{
int array[ ] = { 0 };
f_by_value< int[ 1 ] >( array );
std::cout << array[ 0 ] << '\n';
}
Hmm, is that really standard conforming? Your program does work as one
would expect if the array were passed by value on gcc 3.3.2, but if I
modify the example to print the value of t[0] in f_by_value() before
modifying it, it turns out to be uninitialized and not 0 as expected.
Similar, if I use a class instead of int, my class's copy constructor
is not called. So which part is non-conforming here? The fact that it
accepts an array by value or the fact that the objects are not properly
copied? Or is there some other magic involved that just tricks us into
thinking it'S pass-by-value?
That's interesting. I assumed the value was being copied properly, but
I see now that I was wrong. Thanks for correcting me! P. 92 of TC++PL
says:
... char v[] = "Annemarie";
... strlen(v); // implicit conversion of char[] to char*
... there is no way of declaring a function so that the
array v is copied when the function is called.
For the OP's benefit, someone should probably mention that std::vector
provides most benefits of arrays, and is easily passed by value.
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... Jumbo wrote:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... jr wrote:
> Sorry for this very dumb question, but I've clearly got a long way
> to go! Can someone please help me pass an array into a function.
You cannot pass arrays into functions. Usually, a pointer to the
array's first element is passed instead.
Of course you pass arrays into functions:
#include <iostream>
void foo(char arr[]){
arr is not an array, but a pointer to its first element.
But that's just what an array is.
You can see that it's not an array, because it doesn't have a size between its [],
and arrays _always_ have a size. The only place where this is allowed
is if you define an array and initialize it, so the size can be
determined from the initializer, like:
You could go into the guts of the computer and say everydata is the same as
it simply a picice of memory.
This is like the argument that a char is really an integer etc.
Just because an array happens to be turned into a pointer by the compiler
when you pass it to a function deoesn't mean to say that we're not passing
an array to a function. We're still passing an array to a function and it's
not a copy. So as we are passing the actually array and not a copy it even
more true to say we ARE passsing an array to a function.
char c[] = "Hello, world\n";
std::cout<< arr<<'\n';
arr[5]='!';
}
int main( )
{
char arr[10] = "hello";
foo(arr);
std::cout<< arr<<'\n';
}
Also if you alter the array inside the function the original is also
altered.
Yes, that's because you didn't pass the array. If you had done that, the
function would have a copy of it and the original couldn't be modified
by that function.
You seem to be meaning that passing an array to a function is only passing
the array if it passes a copy.
I would consider it to be the other way around where "passing the array"
would be passing by ref and passing a copy your aren't actally passing the
array your passing a copy..
"Jumbo @uko2.co.uk>" <pcr1000011<nospam> wrote in message news:10***************@news.minx.net.uk... Just because an array happens to be turned into a pointer by the compiler
when you pass it to a function deoesn't mean to say that we're not passing
an array to a function. We're still passing an array to a function and it's
not a copy. So as we are passing the actually array and not a copy it even
more true to say we ARE passsing an array to a function.
Which is to say that an array works differently in subroutine passing than
EVERY OTHER SINGLE DATA TYPE.
But you're still wrong. The language specifically says that the function parameter
types of type array are explicitly changed to pointer.
void foo(int []);
and
void foo(int*)
mean exactly the same thing.
Passing an array to such a function invokes an array-to-pointer conversion before
the function isn't called. What is passed is the pointer.
"Ron Natalie" <ro*@sensor.com> wrote in message
news:40***********************@news.newshosting.co m...
"Jumbo @uko2.co.uk>" <pcr1000011<nospam> wrote in message
news:10***************@news.minx.net.uk... Just because an array happens to be turned into a pointer by the
compiler when you pass it to a function deoesn't mean to say that we're not
passing an array to a function. We're still passing an array to a function and
it's not a copy. So as we are passing the actually array and not a copy it
even more true to say we ARE passsing an array to a function.
Which is to say that an array works differently in subroutine passing than
EVERY OTHER SINGLE DATA TYPE.
But you're still wrong. The language specifically says that the function
parameter types of type array are explicitly changed to pointer.
void foo(int []);
and
void foo(int*)
mean exactly the same thing.
Passing an array to such a function invokes an array-to-pointer conversion
before the function isn't called. What is passed is the pointer.
Yes we know this is true from the compilers point of view.
But from the programmers point of view your passing the array not a pointer
to an array.
The thing is that arrays are passed by ref as opposed to most other data
types, I wouldn't consider this as not passing an array.
Your still passing an array it's just that the behavior is different.
It's to do with your understanding of how arrays work under the hood.
Anyway putting our disagreements aside, what is going on here if arrays are
never passed by val:
#include <iostream>
void foo(const char p1[],const char p2[]){
p1="STUV";
p2="WXYZ";
std::cout<< "In foo():\t" << p1 << '\t' << p2 << std::endl;
}
int main(){
const char pch1[]= "ABCD";
const char* pch2= "EFGH";
foo(pch1,pch2);
std::cout<< "In main():\t" << pch1 << '\t' << pch2 << std::endl;
return 0;
}
Jumbo "Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com...
Jumbo wrote:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com...
jr wrote:
>Sorry for this very dumb question, but I've clearly got a long way
>to go! Can someone please help me pass an array into a function.
You cannot pass arrays into functions. Usually, a pointer to the
array's first element is passed instead.
Of course you pass arrays into functions:
#include <iostream>
void foo(char arr[]){
arr is not an array, but a pointer to its first element.
But that's just what an array is.
No, it's not.
You can see
that it's not an array, because it doesn't have a size between its [],
and arrays _always_ have a size. The only place where this is allowed
is if you define an array and initialize it, so the size can be
determined from the initializer, like:
You could go into the guts of the computer and say everydata is the same as
it simply a picice of memory.
This is like the argument that a char is really an integer etc.
Just because an array happens to be turned into a pointer by the compiler
when you pass it to a function deoesn't mean to say that we're not passing
an array to a function. We're still passing an array to a function and it's
not a copy. So as we are passing the actually array and not a copy it even
more true to say we ARE passsing an array to a function.
char c[] = "Hello, world\n";
std::cout<< arr<<'\n';
arr[5]='!';
}
int main( )
{
char arr[10] = "hello";
foo(arr);
std::cout<< arr<<'\n';
}
Also if you alter the array inside the function the original is also
altered.
Yes, that's because you didn't pass the array. If you had done that, the
function would have a copy of it and the original couldn't be modified
by that function.
You seem to be meaning that passing an array to a function is only passing
the array if it passes a copy.
I would consider it to be the other way around where "passing the array"
would be passing by ref and passing a copy your aren't actally passing the
array your passing a copy..
"Pass" here means "pass by value," not by address.
Jumbo <pcr1000011 wrote: "Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com...
arr is not an array, but a pointer to its first element.
But that's just what an array is.
Not true. An array is an array. A pointer is a pointer. There are some
syntactic similarities in how they are used*, but there are very
important differences between the two.
*Actually, the only reason for these similarities is the implicit
conversion of an array name to a pointer in most contexts.
Just because an array happens to be turned into a pointer by the compiler
when you pass it to a function deoesn't mean to say that we're not passing
an array to a function.
Of course it does. If you're passing a pointer then you aren't passing
an array. There's not some magic dual type that is simultaneously a
pointer and an array.
We're still passing an array to a function and it's
not a copy. So as we are passing the actually array and not a copy it even
more true to say we ARE passsing an array to a function.
This is simply not true, as you can demonstrate easily enough:
#include <iostream>
void pass_array(int a[])
{
std::cout << "sizeof(a) = " << sizeof(a) << std::endl;
}
int main()
{
int array[100];
std::cout << "sizeof(array) = " << sizeof(array) << std::endl;
pass_array(array);
return 0;
}
On my implementation I get this output:
sizeof(array) = 400
sizeof(a) = 4
How can you account for this if 'a' really is 'array'? It's quite easy
to account for if 'a' is actually a pointer (which it is). Also, you can
change the signature for pass_array to any of these:
void pass_array(int *a)
void pass_array(int a[100])
void pass_array(int a[7])
And you'll get the same results, because all four mean exactly the same
thing. 'a' is actually a pointer.
Yes, that's because you didn't pass the array. If you had done that, the
function would have a copy of it and the original couldn't be modified
by that function.
You seem to be meaning that passing an array to a function is only passing
the array if it passes a copy.
I doubt that's what he was trying to say.
I would consider it to be the other way around where "passing the array"
would be passing by ref and passing a copy your aren't actally passing the
array your passing a copy..
OK, but that's not what's happening, either. You *can* pass a reference
to an array to a function if you want to, but this is not done very
often because it's of limited usefulness - the function is specific to a
particular size of array (unless you make the size a template argument).
For example, if I change my previous example so that pass_array's
signature is this:
void pass_array(int (&a)[100])
Then I get the following output:
sizeof(array) = 400
sizeof(a) = 400
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:HQ*****************@newsread2.news.pas.earthl ink.net... Jumbo <pcr1000011 wrote: "Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com...
arr is not an array, but a pointer to its first element.
But that's just what an array is.
Not true. An array is an array. A pointer is a pointer. There are some
syntactic similarities in how they are used*, but there are very
important differences between the two.
*Actually, the only reason for these similarities is the implicit
conversion of an array name to a pointer in most contexts.
Just because an array happens to be turned into a pointer by the
compiler when you pass it to a function deoesn't mean to say that we're not
passing an array to a function.
Of course it does. If you're passing a pointer then you aren't passing
an array. There's not some magic dual type that is simultaneously a
pointer and an array.
We're still passing an array to a function and it's
not a copy. So as we are passing the actually array and not a copy it
even more true to say we ARE passsing an array to a function.
This is simply not true, as you can demonstrate easily enough:
#include <iostream>
void pass_array(int a[])
{
std::cout << "sizeof(a) = " << sizeof(a) << std::endl;
}
int main()
{
int array[100];
std::cout << "sizeof(array) = " << sizeof(array) << std::endl;
pass_array(array);
return 0;
}
On my implementation I get this output:
sizeof(array) = 400
sizeof(a) = 4
How can you account for this if 'a' really is 'array'? It's quite easy
to account for if 'a' is actually a pointer (which it is). Also, you can
change the signature for pass_array to any of these:
void pass_array(int *a)
void pass_array(int a[100])
void pass_array(int a[7])
And you'll get the same results, because all four mean exactly the same
thing. 'a' is actually a pointer.
Yes, that's because you didn't pass the array. If you had done that, the
function would have a copy of it and the original couldn't be modified
by that function.
You seem to be meaning that passing an array to a function is only
passing the array if it passes a copy.
I doubt that's what he was trying to say.
I would consider it to be the other way around where "passing the array"
would be passing by ref and passing a copy your aren't actally passing
the array your passing a copy..
OK, but that's not what's happening, either. You *can* pass a reference
to an array to a function if you want to, but this is not done very
often because it's of limited usefulness - the function is specific to a
particular size of array (unless you make the size a template argument).
For example, if I change my previous example so that pass_array's
signature is this:
void pass_array(int (&a)[100])
Then I get the following output:
sizeof(array) = 400
sizeof(a) = 400
Well then surely this clarifies that you *can* pass an array to a function ,
whatever way you look at it?
Yes it is important to understand how the array is passed by the compiler.
However at the end of the day whether you pass the array by ref, val , or by
pointer you're still passing the array to a function in some way or other.
Consider this:
#include <iostream>
void foo(const char arr1[]){
arr1="ZZZZ";
std::cout<< "In foo():\t"
<<"sizeof array: "<< sizeof arr1
<< "\tvalue\t" << arr1 << std::endl;
}
int main(){
const char arr1[]= "ABCD";
foo(arr1);
std::cout<< "In main():\t"
<<"sizeof array: "<< sizeof arr1
<< "\tvalue\t" << arr1 << std::endl;
return 0;
}
On my system this outputs
In foo(): sizeof array: 4 value: ZZZZ
In main(): sizeof array: 5 value: ABCD
So what's going on here then, Is this non compliant code?
Jumbo <pcr1000011 wrote:
Please trim your replies. There was no need to quote my entire message.
Well then surely this clarifies that you *can* pass an array to a function ,
whatever way you look at it?
Not at all. You can pass a pointer, or a reference, but not an array (at
least not directly - as already mentioned, it can be wrapped in a class).
Yes it is important to understand how the array is passed by the compiler.
However at the end of the day whether you pass the array by ref, val , or by
pointer you're still passing the array to a function in some way or other.
No, in all cases you are passing something that refers to the array in
some way. The effect is that you can access the array from the function,
but "passing" of arrays to functions is still significantly different
than passing other types, and the distinction is important for anyone
who wants to use the language effectively.
Consider this:
#include <iostream>
void foo(const char arr1[]){
arr1="ZZZZ";
std::cout<< "In foo():\t"
<<"sizeof array: "<< sizeof arr1
<< "\tvalue\t" << arr1 << std::endl;
}
int main(){
const char arr1[]= "ABCD";
foo(arr1);
std::cout<< "In main():\t"
<<"sizeof array: "<< sizeof arr1
<< "\tvalue\t" << arr1 << std::endl;
return 0;
}
On my system this outputs
In foo(): sizeof array: 4 value: ZZZZ
In main(): sizeof array: 5 value: ABCD
So what's going on here then, Is this non compliant code?
As far as I can tell it's compliant, but it doesn't provide any evidence
to back up your claim. You create an array 'arr1' in main, which is 5
characters long. You pass a pointer to that array to foo. The pointer is
passed by value, thus foo gets a copy. foo immediately modifies its
copy, making it point to a string literal. The first line of output
gives the size of a pointer and the value of the string literal to which
that pointer points. Back in main, 'arr1' is unmodified, and the second
line of output gives the size of the storage used for arr1 (5
characters) and the value stored there (as given in the initialization
of arr1).
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jumbo <pcr1000011 wrote: "Ron Natalie" <ro*@sensor.com> wrote in message
news:40***********************@news.newshosting.co m...
Passing an array to such a function invokes an array-to-pointer
conversion before the function isn't called. What is passed is
the pointer.
Yes we know this is true from the compilers point of view.
But from the programmers point of view your passing the array not a pointer
to an array.
If that were true, then applying sizeof to the function argument would
give the number of bytes used by the array. This would be quite handy,
and beginners often try to use this technique. They quickly find out
that it doesn't work.
The fact that the argument is actually a pointer is very relevant to the
programmer. If the programmer's point of view is that it is an array,
then the programmer is bound to run into trouble.
The thing is that arrays are passed by ref as opposed to most other data
types, I wouldn't consider this as not passing an array.
That's not true. A pointer to an array is passed by value. There is no
pass-by-reference occurring in this case. Passing a reference to an
array requires different syntax.
Your still passing an array it's just that the behavior is different.
It's to do with your understanding of how arrays work under the hood.
Anyway putting our disagreements aside, what is going on here if arrays are
never passed by val:
#include <iostream>
void foo(const char p1[],const char p2[]){
p1="STUV";
p2="WXYZ";
Pointer assignment that doesn't affect anything in main(). What is this
example supposed to show?
std::cout<< "In foo():\t" << p1 << '\t' << p2 << std::endl;
}
int main(){
const char pch1[]= "ABCD";
const char* pch2= "EFGH";
foo(pch1,pch2);
std::cout<< "In main():\t" << pch1 << '\t' << pch2 << std::endl;
return 0;
}
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
"Jumbo Consider this:
#include <iostream>
void foo(const char arr1[]){
arr1="ZZZZ";
std::cout<< "In foo():\t"
<<"sizeof array: "<< sizeof arr1
<< "\tvalue\t" << arr1 << std::endl;
}
int main(){
const char arr1[]= "ABCD";
foo(arr1);
std::cout<< "In main():\t"
<<"sizeof array: "<< sizeof arr1
<< "\tvalue\t" << arr1 << std::endl;
return 0;
}
On my system this outputs
In foo(): sizeof array: 4 value: ZZZZ
In main(): sizeof array: 5 value: ABCD
So what's going on here then, Is this non compliant code?
You realize that you just disproved your own point. If arr1 in foo() was
an array, the assignment would have been illegal, requiring a
diagnostic.
Because arr1 is a pointer, you were able to assign a new value to it.
Note that you did not copy the new value "ZZZZ" to arr1 in main(), all
you did was reset the pointer in foo() to point to the string literal
"ZZZZ" instead of the first element of arr1 in main().
I think you'd better learn some more about pointers and arrays before
you attempt to lecture experienced users on the subject. You are
embarrassing yourself.
Brian Rodenborn
Default User wrote: I think you'd better learn some more about pointers and arrays before
you attempt to lecture experienced users on the subject. You are
embarrassing yourself.
Along those lines, I suggest reading the section in the comp.lang.c FAQ: http://www.eskimo.com/~scs/C-faq/s6.html
Brian Rodenborn
Jumbo wrote:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... Jumbo wrote:
>
> "Rolf Magnus" <ra******@t-online.de> wrote in message
> news:bu*************@news.t-online.com...
>> jr wrote:
>>
>> > Sorry for this very dumb question, but I've clearly got a long
>> > way to go! Can someone please help me pass an array into a
>> > function.
>>
>> You cannot pass arrays into functions. Usually, a pointer to the
>> array's first element is passed instead.
>>
> Of course you pass arrays into functions:
> #include <iostream>
>
> void foo(char arr[]){
arr is not an array, but a pointer to its first element.
But that's just what an array is.
Then you didn't understand arrays and pointers, and especially their
difference. Try this:
#include <iostream>
#include <ostream>
void tellsize(char arr[])
{
std::cout << "size of arr in tellsize " << sizeof(arr) << '\n';
}
int main()
{
char arr[] = "Hello world\n";
std::cout << "size of arr in main " << sizeof(arr) << '\n';
tellsize(arr);
}
An array _is_ not a pointer to its first element, but it is _converted_
to one in many, but not all situations. Passing to a function is one of
those situations, using sizeof is one of the other situations.
You can see
that it's not an array, because it doesn't have a size between its
[], and arrays _always_ have a size. The only place where this is
allowed is if you define an array and initialize it, so the size can
be determined from the initializer, like:
You could go into the guts of the computer and say everydata is the
same as it simply a picice of memory.
And a pointer is a totally different piece of memory than an array.
This is like the argument that a char is really an integer etc.
I don't get you here. The C++ standard defines char as an integer type,
so what else would it be? It just happens to be the type that is often
used to store characters, though that probably will change in the
future, with wide characters and multi-language programs that need
unicode support.
Just because an array happens to be turned into a pointer by the
compiler when you pass it to a function deoesn't mean to say that
we're not passing an array to a function.
Yes it is. You can determine the size of an array, but if you pass a
pointer to its first element to a function, you will only get the size
of a pointer, not of the array, since a pointer was passed to the
function, not an array. Another difference is that passing a value to a
funciton means that this value is copied, and the function works on a
copy. This is not the case for arrays, since arrays are not copyable.
The funciton can access the original array through a pointer, not a
local copy.
We're still passing an array to a function and it's not a copy.
That's my point. Passing something means making a copy of it, unless you
pass a reference.
So as we are passing the actually array and not a copy it even more
true to say we ARE passsing an array to a function.
No, it makes it actually wrong.
> Also if you alter the array inside the function the original is
> also altered.
Yes, that's because you didn't pass the array. If you had done that,
the function would have a copy of it and the original couldn't be
modified by that function.
You seem to be meaning that passing an array to a function is only
passing the array if it passes a copy.
Yes, because that's what passing a value means in C++.
I would consider it to be the other way around where "passing the
array" would be passing by ref and passing a copy your aren't actally
passing the array your passing a copy..
Jumbo wrote: But you're still wrong. The language specifically says that the
function parameter types of type array are explicitly changed to
pointer.
void foo(int []);
and
void foo(int*)
mean exactly the same thing.
Passing an array to such a function invokes an array-to-pointer
conversion before the function isn't called. What is passed is the
pointer.
Yes we know this is true from the compilers point of view.
But from the programmers point of view your passing the array not a
pointer to an array.
The C++ standard says what is done from the programmer's view, and it
says that the array is converted to a pointer, and that pointer is
passed as parameter.
The thing is that arrays are passed by ref as opposed to most other
data types, I wouldn't consider this as not passing an array.
Your still passing an array it's just that the behavior is different.
It's to do with your understanding of how arrays work under the hood.
You don't have to understand what goes on under the hood. Just
understand how the terms are defined in C++.
Anyway putting our disagreements aside, what is going on here if
arrays are never passed by val:
#include <iostream>
void foo(const char p1[],const char p2[]){
p1="STUV";
p2="WXYZ";
std::cout<< "In foo():\t" << p1 << '\t' << p2 << std::endl;
}
int main(){
const char pch1[]= "ABCD";
Ok, we have an array.
const char* pch2= "EFGH";
and a pointer.
foo(pch1,pch2);
A pointer to the first element of pch1 is passed to foo, as well as the
pointer pch2. In foo, the local copies of those pointers get the
addresses of new string literals assigned. After the function returns,
those pointers don't exist anymore. The original pointer pch2 wasn't
changed, and neither the temporary pointer that was made from the array
pch1 or any character in that array.
std::cout<< "In main():\t" << pch1 << '\t' << pch2 << std::endl;
return 0;
}
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... Jumbo wrote:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... Jumbo wrote:
>
> "Rolf Magnus" <ra******@t-online.de> wrote in message
> news:bu*************@news.t-online.com...
>> jr wrote:
>>
>> > Sorry for this very dumb question, but I've clearly got a long
>> > way to go! Can someone please help me pass an array into a
>> > function.
>>
>> You cannot pass arrays into functions. Usually, a pointer to the
>> array's first element is passed instead.
>>
> Of course you pass arrays into functions:
> #include <iostream>
>
> void foo(char arr[]){
arr is not an array, but a pointer to its first element. But that's just what an array is.
Then you didn't understand arrays and pointers, and especially their
difference. Try this:
#include <iostream>
#include <ostream>
void tellsize(char arr[])
{
std::cout << "size of arr in tellsize " << sizeof(arr) << '\n';
}
int main()
{
char arr[] = "Hello world\n";
std::cout << "size of arr in main " << sizeof(arr) << '\n';
tellsize(arr);
}
An array _is_ not a pointer to its first element, but it is _converted_
to one in many, but not all situations. Passing to a function is one of
those situations, using sizeof is one of the other situations.
You can see
that it's not an array, because it doesn't have a size between its
[], and arrays _always_ have a size. The only place where this is
allowed is if you define an array and initialize it, so the size can
be determined from the initializer, like:
You could go into the guts of the computer and say everydata is the
same as it simply a picice of memory.
And a pointer is a totally different piece of memory than an array.
This is like the argument that a char is really an integer etc.
I don't get you here. The C++ standard defines char as an integer type,
so what else would it be? It just happens to be the type that is often
used to store characters, though that probably will change in the
future, with wide characters and multi-language programs that need
unicode support.
Well that is very confusing.
On my system a char is 1 byte and an integer is 4 bytes.
So how is a char type an integer type?
Just because an array happens to be turned into a pointer by the
compiler when you pass it to a function deoesn't mean to say that
we're not passing an array to a function.
Yes it is. You can determine the size of an array, but if you pass a
pointer to its first element to a function, you will only get the size
of a pointer, not of the array, since a pointer was passed to the
function, not an array. Another difference is that passing a value to a
funciton means that this value is copied, and the function works on a
copy. This is not the case for arrays, since arrays are not copyable.
The funciton can access the original array through a pointer, not a
local copy.
Consider the following array:
int* Array = new int[128];
Do you suggest this is not an array since you cannot determine the size of
it?
According to your idea there is no array here it's simply a pointer.
The pointer is the identifier for the array.
This is the same when you pass an array to a function, the pointer to the
first index is passed as this is the identifier for the array.
You may prefer to call it a pointer and that's fine but your saying that
it's not an array and it is an array.
It can still be indexed like an array so how do you explain that if it's not
an array?
We're still passing an array to a function and it's not a copy.
That's my point. Passing something means making a copy of it, unless you
pass a reference.
No there are two ways to pass
by ref (not meaning the reference type)
by val
Where is it defined that passing to a function means *making a copy of it* ? So as we are passing the actually array and not a copy it even more
true to say we ARE passsing an array to a function.
No, it makes it actually wrong.
> Also if you alter the array inside the function the original is
> also altered.
Yes, that's because you didn't pass the array. If you had done that,
the function would have a copy of it and the original couldn't be
modified by that function.
You seem to be meaning that passing an array to a function is only
passing the array if it passes a copy.
Yes, because that's what passing a value means in C++.
Yeah well passing by value is a different thing from simply passing.
If I say I can't pass an object to a function...
I'm not saying I can't pass it by value but I can pass it by reference am I?
Not being able to pass an object is different from not being able to make a
copy of an object. I would consider it to be the other way around where "passing the
array" would be passing by ref and passing a copy your aren't actally
passing the array your passing a copy..
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... Jumbo wrote:
But you're still wrong. The language specifically says that the
function parameter types of type array are explicitly changed to
pointer.
void foo(int []);
and
void foo(int*)
mean exactly the same thing.
Passing an array to such a function invokes an array-to-pointer
conversion before the function isn't called. What is passed is the
pointer.
Yes we know this is true from the compilers point of view.
But from the programmers point of view your passing the array not a
pointer to an array.
The C++ standard says what is done from the programmer's view, and it
says that the array is converted to a pointer, and that pointer is
passed as parameter.
No the array is not converted into a pointer.
Think of an array as a series of cubby holes in memory.
Think of a pointer as a variable that holds a memory address.
If your array is an array of 500 integers how can you convert this to a
single variable ?
The thing is that arrays are passed by ref as opposed to most other
data types, I wouldn't consider this as not passing an array.
Your still passing an array it's just that the behavior is different.
It's to do with your understanding of how arrays work under the hood.
You don't have to understand what goes on under the hood. Just
understand how the terms are defined in C++.
It's better to have a little understanding of what goes on under the hood. Anyway putting our disagreements aside, what is going on here if
arrays are never passed by val:
#include <iostream>
void foo(const char p1[],const char p2[]){
p1="STUV";
p2="WXYZ";
std::cout<< "In foo():\t" << p1 << '\t' << p2 << std::endl;
}
int main(){
const char pch1[]= "ABCD";
Ok, we have an array.
const char* pch2= "EFGH";
and a pointer.
foo(pch1,pch2);
A pointer to the first element of pch1 is passed to foo, as well as the
pointer pch2. In foo, the local copies of those pointers get the
addresses of new string literals assigned. After the function returns,
those pointers don't exist anymore. The original pointer pch2 wasn't
changed, and neither the temporary pointer that was made from the array
pch1 or any character in that array.
std::cout<< "In main():\t" << pch1 << '\t' << pch2 << std::endl;
return 0;
}
So we are passing pch1 which is an array to a function. What's so difficult
to understand about that?
How can the compile convert it to a pointer?
Assume an integer is 4 bytes and we have an array of 500 integers that takes
up 2000 bytes right?
How can we put 2000 bytes into a pointer that's only 4 bytes?
The compiler does not convert an array to a pointer.
Here's another example:
int* array = new int[500];
Do you suggest the identifier 'array' is not an array?
Are arrays on the heap not real arrays or something?
Am I missing something blatently obvious , is there a way to squeeze a large
array into a single pointer that I don't know about?
HTH
Jumbo.
"Default User" <fi********@boeing.com.invalid> wrote in message
news:40***************@boeing.com.invalid... "Jumbo
Consider this:
#include <iostream>
void foo(const char arr1[]){
arr1="ZZZZ";
std::cout<< "In foo():\t"
<<"sizeof array: "<< sizeof arr1
<< "\tvalue\t" << arr1 << std::endl;
}
int main(){
const char arr1[]= "ABCD";
foo(arr1);
std::cout<< "In main():\t"
<<"sizeof array: "<< sizeof arr1
<< "\tvalue\t" << arr1 << std::endl;
return 0;
}
On my system this outputs
In foo(): sizeof array: 4 value: ZZZZ
In main(): sizeof array: 5 value: ABCD
So what's going on here then, Is this non compliant code?
You realize that you just disproved your own point. If arr1 in foo() was
an array, the assignment would have been illegal, requiring a
diagnostic.
No I have just proved that arrays can be passed to functions.
Why would the assignment have been illegal , what's wrong with assigning a
character array to a character array?
It seems the only thing needing diagnosed is your condition. :-)
Because arr1 is a pointer, you were able to assign a new value to it.
So you can't assign new values to an array?
Note that you did not copy the new value "ZZZZ" to arr1 in main(), all
you did was reset the pointer in foo() to point to the string literal
"ZZZZ" instead of the first element of arr1 in main().
I didn't want to copy the value "ZZZZ" in main,
I was demonstrating how to pass an array to a function, something you seem
to think of as an impossibility.
I think you'd better learn some more about pointers and arrays before
you attempt to lecture experienced users on the subject. You are
embarrassing yourself.
Ha Ha
The only person embarrassing themselves around here is you ya half-wit.
HTH :-)
Jumbo <pcr1000011 wrote: "Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com...
The C++ standard says what is done from the programmer's view, and it
says that the array is converted to a pointer, and that pointer is
passed as parameter.
No the array is not converted into a pointer.
Yes it is.
Think of an array as a series of cubby holes in memory.
Think of a pointer as a variable that holds a memory address.
If your array is an array of 500 integers how can you convert this to a
single variable ?
It's the address of the first one. This *is* the way the language works,
regardless of how much you deny it.
You don't have to understand what goes on under the hood. Just
understand how the terms are defined in C++.
It's better to have a little understanding of what goes on under the hood.
I think what Rolf is getting at is that you can't really know what's
going on "under the hood" because an implementation isn't necessarily
constrained in how it implements things - optimized code, for example,
may bear very little resemblance to the original code. The Standard
allows the implementation to mutilate the code however it wants, so long
as the observable result is the same.
So we are passing pch1 which is an array to a function. What's so difficult
to understand about that?
Regardless of how you simplify it, you are passing a copy of a pointer
to the function. Arrays and pointers are different, so this is an
important distinction.
How can the compile convert it to a pointer?
I doubt I'm the only one who's getting a little tired of explaining
this. The compiler interprets the array's name as a pointer to the first
element of the array. There's even a section of the standard that
specifically talks about this:
4.2 Array-to-pointer conversion [conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown bound
of T" can be converted to an rvalue of type "pointer to T." The
result is a pointer to the first element of the array.
Assume an integer is 4 bytes and we have an array of 500 integers that takes
up 2000 bytes right?
How can we put 2000 bytes into a pointer that's only 4 bytes?
Why would we need to?
The compiler does not convert an array to a pointer.
The implementation does.
Here's another example:
int* array = new int[500];
Do you suggest the identifier 'array' is not an array?
That's correct. 'array' is a pointer.
Are arrays on the heap not real arrays or something?
They are, but they are unnamed. They can only be referred to by a pointer.
Am I missing something blatently obvious ,
Yes, you are. Well, it's not obvious, but it's also not difficult to
grasp once it's been explained.
is there a way to squeeze a large
array into a single pointer that I don't know about?
There's no reason to do that.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jumbo <pcr1000011 wrote: "Default User" <fi********@boeing.com.invalid> wrote in message
news:40***************@boeing.com.invalid...
You realize that you just disproved your own point. If arr1 in foo() was
an array, the assignment would have been illegal, requiring a
diagnostic.
No I have just proved that arrays can be passed to functions.
You can't prove what isn't true, and your code didn't even approach
proving what you claim.
Why would the assignment have been illegal , what's wrong with assigning a
character array to a character array?
Assignment to an array is forbidden.
8.3.4 Arrays [dcl.array]
5 [Note: conversions affecting lvalues of array type are described in
_conv.array_. Objects of array types cannot be modified, see
_basic.lval_. ]
It seems the only thing needing diagnosed is your condition. :-)
....
No comment.
Because arr1 is a pointer, you were able to assign a new value to it.
So you can't assign new values to an array?
No, you cannot.
Note that you did not copy the new value "ZZZZ" to arr1 in main(), all
you did was reset the pointer in foo() to point to the string literal
"ZZZZ" instead of the first element of arr1 in main().
I didn't want to copy the value "ZZZZ" in main,
I was demonstrating how to pass an array to a function, something you seem
to think of as an impossibility.
He's correct. The standard agrees with him.
I think you'd better learn some more about pointers and arrays before
you attempt to lecture experienced users on the subject. You are
embarrassing yourself.
Ha Ha
The only person embarrassing themselves around here is you ya half-wit.
If you aren't embarrassed, then you should be. In any case, your
cluelessness coupled with your abusiveness makes you no longer worth my
time.
*PLONK*
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
jr wrote: Sorry for this very dumb question, but I've clearly got a long way to go!
Can someone please help me pass an array into a function.
Here's a starting point.
void DoStuff(TCHAR theArray[]) {
// ...
}
void TheMainFunc(void) {
// Body of code...
TCHAR myArray[512];
DoStuff(myArray);
}
I can't quite get my head around what the variable "myArray" is.
Is it a pointer to a memory address that would hold a TCHAR
(a wide char if UNICODE)?
You need to define
void DoStuff(TCHAR theArray[512]);
or
void DoStuff(TCHAR theArray[]);
or
void DoStuff(TCHAR* theArray);
David Harmon wrote: jr is alleged to have written:
TCHAR myArray[512];
DoStuff(myArray);
}
void DoStuff(TCHAR theArray) {
void DoStuff(TCHAR* theArray) {
I can't quite get my head around what the variable "myArray" is.
Is it a pointer to a memory address that would hold a TCHAR?
(a wide char if UNICODE)?
No, it's not a pointer,
it's the actual storage for 256 instances of TCHAR.
Actually, myArray is the *name* of the array.
It is *not* a pointer and cannot be reseated.
The formal argument theArray *is* a pointer and *can* be reseated
even if you declare
void DoStuff(TCHAR theArray[]);
or even
void DoStuff(TCHAR theArray[512]);
When you invoke
DoStuff(myArray);
the compiler implicitly converts myArray
into a pointer to its first element.
But you often may refer to it as if it was a pointer
and C is very ambivalent about that, converting
the array variable name to a pointer with little provocation
where non-array types would require operator& to get the pointer.
C++ would probably prefer to consistently require the operator&
I don't think so.
But maybe an example would help clarify what you meant.
but goes along with C for compatibility.
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:_b******************@newsread2.news.pas.earth link.net... Jumbo <pcr1000011 wrote: "Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com...
The C++ standard says what is done from the programmer's view, and it
says that the array is converted to a pointer, and that pointer is
passed as parameter.
No the array is not converted into a pointer.
Yes it is.
No its not. :-) Think of an array as a series of cubby holes in memory.
Think of a pointer as a variable that holds a memory address.
If your array is an array of 500 integers how can you convert this to a
single variable ?
It's the address of the first one. This *is* the way the language works,
regardless of how much you deny it.
Oh so now your not actually converting the array, your converting the array
identifier into a pointer to the first element?
You don't have to understand what goes on under the hood. Just
understand how the terms are defined in C++.
It's better to have a little understanding of what goes on under the
hood.
I think what Rolf is getting at is that you can't really know what's
going on "under the hood" because an implementation isn't necessarily
constrained in how it implements things - optimized code, for example,
may bear very little resemblance to the original code. The Standard
allows the implementation to mutilate the code however it wants, so long
as the observable result is the same.
So if the implementation can do what it likes then it can pass arrays to
functions if it likes no?
So we are passing pch1 which is an array to a function. What's so
difficult to understand about that?
Regardless of how you simplify it, you are passing a copy of a pointer
to the function. Arrays and pointers are different, so this is an
important distinction.
Yes an array is a concept of memory allocation and a pointer is a different
type of memory that holds an address( it points to another location in
memory) , hence the name pointer. How can the compile convert it to a pointer?
I doubt I'm the only one who's getting a little tired of explaining
this. The compiler interprets the array's name as a pointer to the first
element of the array. There's even a section of the standard that
specifically talks about this:
4.2 Array-to-pointer conversion [conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown bound
of T" can be converted to an rvalue of type "pointer to T." The
result is a pointer to the first element of the array.
It says an array *can* be blah blah ......
This doesn't prove anything you've said yourself the implementation can
basically do what it likes. Assume an integer is 4 bytes and we have an array of 500 integers that
takes up 2000 bytes right?
How can we put 2000 bytes into a pointer that's only 4 bytes?
Why would we need to?
Well how else would you convert the array to a pointer?
The compiler does not convert an array to a pointer.
The implementation does.
You've said yourself that the implementation is free to do what it wants
right?
So how can you state what any implementation does?
Here's another example:
int* array = new int[500];
Do you suggest the identifier 'array' is not an array?
That's correct. 'array' is a pointer.
Are arrays on the heap not real arrays or something?
They are, but they are unnamed. They can only be referred to by a pointer.
So it's a real array but it's unnamed. hmmm
But what about the identifier 'array', isn't that it's name?
So what if I did:
#include <iostream>
#define ARRAY128(a)(a=new char[128])
typedef char* ARRAYT;
int main()
{
ARRAYT arrayidentifier;
ARRAY128(arrayidentifier);
for(int i=0; i<128; ++i){
arrayidentifier[i] = i;
std::cout<< i <<": "<< arrayidentifier[i]<<" \t";
}
}
Is this an unnamed array of does this array have a name?
Can this array be passed to a function?
You seem to foget that almost every variable is stored someplace in memory ,
therefore almost every variable is essentially a memory address.
If you say that an array is not an array because it's simply a pointer to an
area in memory then you'd be aswell saying that for every type.
Am I missing something blatently obvious ,
Yes, you are. Well, it's not obvious, but it's also not difficult to
grasp once it's been explained.
What exactly are you trying to explain? is there a way to squeeze a large
array into a single pointer that I don't know about?
There's no reason to do that.
Then there's no need to convert anything.
Jumbo.
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:Iw*****************@newsread2.news.pas.earthl ink.net... Jumbo <pcr1000011 wrote:
"Default User" <fi********@boeing.com.invalid> wrote in message
news:40***************@boeing.com.invalid...
You realize that you just disproved your own point. If arr1 in foo() was
an array, the assignment would have been illegal, requiring a
diagnostic.
No I have just proved that arrays can be passed to functions.
You can't prove what isn't true, and your code didn't even approach
proving what you claim.
Why would the assignment have been illegal , what's wrong with assigning
a character array to a character array?
Assignment to an array is forbidden.
8.3.4 Arrays [dcl.array]
5 [Note: conversions affecting lvalues of array type are described in
_conv.array_. Objects of array types cannot be modified, see
_basic.lval_. ]
It seems the only thing needing diagnosed is your condition. :-)
So all array are constant now? ...
No comment.
ditto.
Because arr1 is a pointer, you were able to assign a new value to it.
So you can't assign new values to an array?
No, you cannot.
Well if you really think this your obviously a bit of a crackpot.Note that you did not copy the new value "ZZZZ" to arr1 in main(), all
you did was reset the pointer in foo() to point to the string literal
"ZZZZ" instead of the first element of arr1 in main().
I didn't want to copy the value "ZZZZ" in main,
I was demonstrating how to pass an array to a function, something you
seem to think of as an impossibility.
He's correct. The standard agrees with him.
THe standards don't agree with anyone.I think you'd better learn some more about pointers and arrays before
you attempt to lecture experienced users on the subject. You are
embarrassing yourself.
Ha Ha
The only person embarrassing themselves around here is you ya half-wit.
If you aren't embarrassed, then you should be. In any case, your
cluelessness coupled with your abusiveness makes you no longer worth my
time.
LOL :-).
*PLONK*
Glad to see the back of you.
Good riddens.
:-)
"Jumbo I think what Rolf is getting at is that you can't really know what's
going on "under the hood" because an implementation isn't necessarily
constrained in how it implements things - optimized code, for example,
may bear very little resemblance to the original code. The Standard
allows the implementation to mutilate the code however it wants, so long
as the observable result is the same. So if the implementation can do what it likes then it can pass arrays to
functions if it likes no?
No it can not.
If it does, it is no longer a C++ compiler.
Plain and simple.
How can the compile convert it to a pointer?
I doubt I'm the only one who's getting a little tired of explaining
this. The compiler interprets the array's name as a pointer to the first
element of the array. There's even a section of the standard that
specifically talks about this:
4.2 Array-to-pointer conversion [conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown bound
of T" can be converted to an rvalue of type "pointer to T." The
result is a pointer to the first element of the array.
It says an array *can* be blah blah ......
This doesn't prove anything you've said yourself the implementation can
basically do what it likes.
and somewhere else in the standard it is explicitely written down, that
an array undergoes this Array-to-pointer conversion, if the name of
an array shows up in an argument list of a function call.
Assume an integer is 4 bytes and we have an array of 500 integers that takes up 2000 bytes right?
How can we put 2000 bytes into a pointer that's only 4 bytes?
Why would we need to?
Well how else would you convert the array to a pointer?
By taking the address of the first element of the array and use this
address as pointer value. (See above: 4.2 Array-to-pointer
conversion).
Here's another example:
int* array = new int[500];
Do you suggest the identifier 'array' is not an array?
That's correct. 'array' is a pointer.
Are arrays on the heap not real arrays or something?
They are, but they are unnamed. They can only be referred to by a pointer.
So it's a real array but it's unnamed. hmmm
But what about the identifier 'array', isn't that it's name?
Yes. But 'array' in the above is a pointer. You wrote it to
be a pointer
int* array
Remeber?
This pointer is assigned the starting address of an array. (How can this
be done? Same thing: 4.2 - by taking the address of the first array alement
und using that address as the address of the array).
So what if I did:
#include <iostream>
#define ARRAY128(a)(a=new char[128])
typedef char* ARRAYT;
int main()
{
ARRAYT arrayidentifier;
ARRAY128(arrayidentifier);
for(int i=0; i<128; ++i){
arrayidentifier[i] = i;
std::cout<< i <<": "<< arrayidentifier[i]<<" \t";
}
}
Is this an unnamed array of does this array have a name?
The array still doesn't have a name.
But the pointer pointing to it has: arrayidentifier
Can this array be passed to a function?
Arrays are never passed to functions. Only pointers to them are.
When will you stop claiming silly things.
You seem to foget that almost every variable is stored someplace in memory ,
And you seem to forget what pointers really are.
There is a difference between:
int m[3];
and
int* n = new int [3];
the former looks like this:
m
+------+
| |
+------+
| |
+------+
| |
+------+
while the later looks like this:
n
+------+ +-----+
| o--------------->| |
+------+ +-----+
| |
+-----+
| |
+-----+
--
Karl Heinz Buchegger kb******@gascad.at
"Jumbo >Because arr1 is a pointer, you were able to assign a new value to it.
So you can't assign new values to an array?
No, you cannot.
Well if you really think this your obviously a bit of a crackpot.
Learn the language.
You cannot assign arrays. That's how it is since at least 20 years in C
and C++ didn't change it.
--
Karl Heinz Buchegger kb******@gascad.at
Jumbo wrote: > Think of an array as a series of cubby holes in memory.
> Think of a pointer as a variable that holds a memory address.
>
> If your array is an array of 500 integers how can you convert this
> to a single variable ?
It's the address of the first one. This *is* the way the language
works, regardless of how much you deny it.
Oh so now your not actually converting the array, your converting the
array identifier into a pointer to the first element?
You should first get an understanding of what "convert" means in C++. It
means that you take an existing object and create from it a new object
that is another type. This doesn't neccesarily mean putting all the
data into the new object.
I think what Rolf is getting at is that you can't really know what's
going on "under the hood" because an implementation isn't necessarily
constrained in how it implements things - optimized code, for
example, may bear very little resemblance to the original code. The
Standard allows the implementation to mutilate the code however it
wants, so long as the observable result is the same.
So if the implementation can do what it likes then it can pass arrays
to functions if it likes no?
Yes, as long as it behaves as if the array was not passed.
> So we are passing pch1 which is an array to a function. What's so
> difficult to understand about that?
Regardless of how you simplify it, you are passing a copy of a
pointer to the function. Arrays and pointers are different, so this
is an important distinction.
Yes an array is a concept of memory allocation and a pointer is a
different type of memory that holds an address( it points to another
location in memory) , hence the name pointer. > How can the compile convert it to a pointer?
I doubt I'm the only one who's getting a little tired of explaining
this. The compiler interprets the array's name as a pointer to the
first element of the array. There's even a section of the standard
that specifically talks about this:
4.2 Array-to-pointer conversion
[conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown
bound
of T" can be converted to an rvalue of type "pointer to T."
The result is a pointer to the first element of the array.
It says an array *can* be blah blah ......
Right, and that's what you doubt above (and below, too).
> If your array is an array of 500 integers how can you convert this
> to a single variable ?
This doesn't prove anything you've said yourself the implementation
can basically do what it likes.
No. He said that under the hood, it can do what it likes, as long as the
behaviour is like the standard says. This is called the as-if rule.
> Assume an integer is 4 bytes and we have an array of 500 integers
> that takes up 2000 bytes right?
> How can we put 2000 bytes into a pointer that's only 4 bytes?
Why would we need to?
Well how else would you convert the array to a pointer?
You are under the false assumption that "conversion" means putting all
the bytes of an object into another. The iostreams have a conversion
operator to void*. So how is a whole stream object pressed into a
void*?
> The compiler does not convert an array to a pointer.
The implementation does.
You've said yourself that the implementation is free to do what it
wants right?
So how can you state what any implementation does?
See above.
> Here's another example:
> int* array = new int[500];
>
> Do you suggest the identifier 'array' is not an array?
That's correct. 'array' is a pointer.
> Are arrays on the heap not real arrays or something?
They are, but they are unnamed. They can only be referred to by a
pointer.
So it's a real array but it's unnamed.
Yes, just like any other dynamically allocated object.
hmmm
But what about the identifier 'array', isn't that it's name?
No. It's the name of a pointer that points to its first element. If you
lose that pointer, the array is still there, but can't be accessed,
because it doen't have a name and there is no pointer to it.
So what if I did:
#include <iostream>
#define ARRAY128(a)(a=new char[128])
typedef char* ARRAYT;
int main()
{
ARRAYT arrayidentifier;
ARRAY128(arrayidentifier);
for(int i=0; i<128; ++i){
arrayidentifier[i] = i;
std::cout<< i <<": "<< arrayidentifier[i]<<" \t";
}
}
Is this an unnamed array of does this array have a name?
It is unnamed.
Can this array be passed to a function?
No, it can't. Using the preprocessor to hide the fact that ARRAYT is a
pointer won't change that.
You seem to foget that almost every variable is stored someplace in
memory , therefore almost every variable is essentially a memory
address.
No. It _has_ a memory address that you can put into a pointer.
If you say that an array is not an array because it's simply
a pointer to an area in memory
_You_ are saying that, not Kevin. I quote from another posting from you:
arr is not an array, but a pointer to its first element.
But that's just what an array is.
then you'd be aswell saying that for every type.
_You_ were claiming that an array is a pointer and passing a pointer to
a function means passing the array and when you were told that this
behaviour would be different from any other type, you wrote:
The thing is that arrays are passed by ref as opposed to most other
data types, I wouldn't consider this as not passing an array.
Jumbo wrote: I don't get you here. The C++ standard defines char as an integer
type, so what else would it be? It just happens to be the type that
is often used to store characters, though that probably will change
in the future, with wide characters and multi-language programs that
need unicode support.
Well that is very confusing.
On my system a char is 1 byte and an integer is 4 bytes.
So how is a char type an integer type?
Ok, I have to admit that char is not an integer type, but it is an
integral type. And signed char and unsigned char still are integer
types. Some quotes from the chapter 3.9.1 "Fundamental types" of the
C++ standard:
2 There are four signed integer types: "signed char", "short int",
"int", and "long int". ...
3 For each of the signed integer types, there exists a corresponding
(but different) unsigned integer type: "unsigned char", "unsigned
short int", "unsigned int", and "unsigned long int"...
...
7 Types bool, char, wchar_t, and the signed and unsigned integer
types are collectively called integral types. ...
> Just because an array happens to be turned into a pointer by the
> compiler when you pass it to a function deoesn't mean to say that
> we're not passing an array to a function.
Yes it is. You can determine the size of an array, but if you pass a
pointer to its first element to a function, you will only get the
size of a pointer, not of the array, since a pointer was passed to
the function, not an array. Another difference is that passing a
value to a funciton means that this value is copied, and the function
works on a copy. This is not the case for arrays, since arrays are
not copyable. The funciton can access the original array through a
pointer, not a local copy.
Consider the following array:
int* Array = new int[128];
Do you suggest this is not an array since you cannot determine the
size of it?
Depends on what you refer to as 'this'. 'Array' is a pointer, and you
can determine its size. It would be 4 on my machine. The array that it
points to doesn't have a name, and therefore, its size cannot be
determined, since sizeof either needs a type or the name of a variable.
Have you ever tried to determine the size of that array, I mean by
experimenting with a real compiler? I would love to see how you can
find out that size.
According to your idea there is no array here it's simply a pointer.
The pointer is the identifier for the array.
No. The array doesn't have an identifier.
This is the same when you pass an array to a function, the pointer to
the first index is passed as this is the identifier for the array.
You may prefer to call it a pointer and that's fine but your saying
that it's not an array and it is an array.
Again: A pointer is _not_ an array. Therefore, what you pass cannot be a
pointer and an array at the same time. It can only be _one_.
It can still be indexed like an array so how do you explain that if
it's not an array?
The indexing is a pointer operation. Writing:
ptr[4] = 5;
is just a more convenient way of writing:
*(ptr + 4) = 5;
i.e. writing 5 into the address that is 4 beyond the pointer 'ptr'. And
since you can write it the other way round, too:
*(4 + ptr) = 5;
You can do the same with the index operator:
4[ptr] = 5;
Still, 4 is not an array, and ptr not an index into it. When you use the
index operator on an array, this array is first converted into a
pointer to its first element, so that the index operator actually works
on a pointer.
> We're still passing an array to a function and it's not a copy.
That's my point. Passing something means making a copy of it, unless
you pass a reference.
No there are two ways to pass
by ref (not meaning the reference type)
Passing by reference means passing a reference. If you pass a pointer,
you pass a pointer. Nothing else.
by val
Where is it defined that passing to a function means *making a copy of
it* ?
Passing by value does. Passing an array by reference is possible, and
that indeed doesn't copy it. That would look e.g. like:
#include <iostream>
void myfunc(int (&arr)[100])
{
std::cout << sizeof(arr) // prints the size of the array
<< std::endl;
}
int main()
{
int arr[100];
myfunc(arr);
}
> You seem to be meaning that passing an array to a function is only
> passing the array if it passes a copy.
Yes, because that's what passing a value means in C++.
Yeah well passing by value is a different thing from simply passing.
Passing by value _is_ "simply passing". If you want to simply pass an
int, you do:
void myfunc(int i) // pass an int - by value
{
}
If you instead want to pass by reference, you have to explicitly say so:
void myfunc(int& i) // by reference, not "simply" by value
{
}
If I say I can't pass an object to a function...
I'm not saying I can't pass it by value but I can pass it by reference
am I?
Yes, and I showed above what passing an arary by reference looks like.
It's of limited use though, because the size is hard-coded in the
function.
Not being able to pass an object is different from not being
able to make a copy of an object.
Yes.
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... Jumbo wrote:
> Think of an array as a series of cubby holes in memory.
> Think of a pointer as a variable that holds a memory address.
>
> If your array is an array of 500 integers how can you convert this
> to a single variable ?
It's the address of the first one. This *is* the way the language
works, regardless of how much you deny it.
Oh so now your not actually converting the array, your converting the
array identifier into a pointer to the first element?
You should first get an understanding of what "convert" means in C++. It
means that you take an existing object and create from it a new object
that is another type. This doesn't neccesarily mean putting all the
data into the new object.
ok here's the array:
int* array = new int[128];
So what do you want to convert?
You mean something like this:
array = (int*) array;
????
I don't understand what you need to convert , I don't need to covnert
anything when I use arrays.
What are you talking about converting?
I think what Rolf is getting at is that you can't really know what's
going on "under the hood" because an implementation isn't necessarily
constrained in how it implements things - optimized code, for
example, may bear very little resemblance to the original code. The
Standard allows the implementation to mutilate the code however it
wants, so long as the observable result is the same. So if the implementation can do what it likes then it can pass arrays
to functions if it likes no?
Yes, as long as it behaves as if the array was not passed.
Well I got somebody else arguing this point.
Seen as it wasn't my point in the first place and nothing to do with me.
perhapss you and Karl should take this up. > So we are passing pch1 which is an array to a function. What's so
> difficult to understand about that?
Regardless of how you simplify it, you are passing a copy of a
pointer to the function. Arrays and pointers are different, so this
is an important distinction. Yes an array is a concept of memory allocation and a pointer is a
different type of memory that holds an address( it points to another
location in memory) , hence the name pointer.
> How can the compile convert it to a pointer?
I doubt I'm the only one who's getting a little tired of explaining
this. The compiler interprets the array's name as a pointer to the
first element of the array. There's even a section of the standard
that specifically talks about this:
4.2 Array-to-pointer conversion
[conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown
bound
of T" can be converted to an rvalue of type "pointer to T."
The result is a pointer to the first element of the array.
It says an array *can* be blah blah ......
Right, and that's what you doubt above (and below, too).
No I don't doubt anything I *know* I can pass an array to a function.
> If your array is an array of 500 integers how can you convert this
> to a single variable ? This doesn't prove anything you've said yourself the implementation
can basically do what it likes.
No. He said that under the hood, it can do what it likes, as long as the
behaviour is like the standard says. This is called the as-if rule.
oh right so it can't do what it likes at all then.
That's a condraction in terms.
It can do what it likes as long as what it likes is not one of the things
that's not allowed (condradiction in terms, doesn't make sense to me) Assume an integer is 4 bytes and we have an array of 500 integers
> that takes up 2000 bytes right?
> How can we put 2000 bytes into a pointer that's only 4 bytes?
Why would we need to? Well how else would you convert the array to a pointer?
You are under the false assumption that "conversion" means putting all
the bytes of an object into another. The iostreams have a conversion
operator to void*. So how is a whole stream object pressed into a
void*?
Well it's not I never said it was. :-) > The compiler does not convert an array to a pointer.
The implementation does. You've said yourself that the implementation is free to do what it
wants right?
So how can you state what any implementation does?
See above.
> Here's another example:
> int* array = new int[500];
>
> Do you suggest the identifier 'array' is not an array?
That's correct. 'array' is a pointer.
> Are arrays on the heap not real arrays or something?
They are, but they are unnamed. They can only be referred to by a
pointer.
So it's a real array but it's unnamed.
Yes, just like any other dynamically allocated object.
So does this mean we can't pass any dynamically created objects to
functions? hmmm
But what about the identifier 'array', isn't that it's name?
No. It's the name of a pointer that points to its first element. If you
lose that pointer, the array is still there, but can't be accessed,
because it doen't have a name and there is no pointer to it.
But what if I copied the memory address in another variable or even in a
file or something.
Then you could destroy the whole program and I could still access the array.
if nothing had overwritten that area of memory it could still contain the
same values too. So we could have cross program arrays passing the address
via files.
Then what if I encoded the memory address into a character string then it
could be classified as the name of the array then no? So what if I did:
#include <iostream>
#define ARRAY128(a)(a=new char[128])
typedef char* ARRAYT;
int main()
{
ARRAYT arrayidentifier;
ARRAY128(arrayidentifier);
for(int i=0; i<128; ++i){
arrayidentifier[i] = i;
std::cout<< i <<": "<< arrayidentifier[i]<<" \t";
}
}
Is this an unnamed array of does this array have a name?
It is unnamed.
Then what shall we name it?
Do you have one of then books for expecting parents?
Can this array be passed to a function?
No, it can't. Using the preprocessor to hide the fact that ARRAYT is a
pointer won't change that.
What if I did this:
template<class ARRAY>
void foo(ARRAY arrayidentifier){
}
then passed arrayidentifier to this function. Am I not passing the array to
this function?
You seem to foget that almost every variable is stored someplace in
memory , therefore almost every variable is essentially a memory
address.
No. It _has_ a memory address that you can put into a pointer.
Then surely the pointer is the name or identifier for that particular area
of memory.
Otherwise we'de be going around calling everything that area of memory with
no name at offset blah blah blah.
If you say that an array is not an array because it's simply
a pointer to an area in memory
_You_ are saying that, not Kevin. I quote from another posting from you:
It's you's who are saying array identifiers are pointers and not arrays,
don't try and turn the tables at this stage.
Were you going to quote something? arr is not an array, but a pointer to its first element. But that's just what an array is.
then you'd be aswell saying that for every type.
_You_ were claiming that an array is a pointer and passing a pointer to
a function means passing the array and when you were told that this
behaviour would be different from any other type, you wrote:
I wrote what? The thing is that arrays are passed by ref as opposed to most other
data types, I wouldn't consider this as not passing an array.
"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:40***************@gascad.at... "Jumbo I think what Rolf is getting at is that you can't really know what's
going on "under the hood" because an implementation isn't necessarily
constrained in how it implements things - optimized code, for example,
may bear very little resemblance to the original code. The Standard
allows the implementation to mutilate the code however it wants, so
long as the observable result is the same. So if the implementation can do what it likes then it can pass arrays to
functions if it likes no?
No it can not.
If it does, it is no longer a C++ compiler.
Oh well it's not me who's saying that you better take it up with them are.
You know me well enough by now to know I don't do silly things like quote
from the standards about how compilers have to behave.
Plain and simple.
You certainly seem to be clear about that . > How can the compile convert it to a pointer?
I doubt I'm the only one who's getting a little tired of explaining
this. The compiler interprets the array's name as a pointer to the
first element of the array. There's even a section of the standard that
specifically talks about this:
4.2 Array-to-pointer conversion
[conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown
bound of T" can be converted to an rvalue of type "pointer to T."
The result is a pointer to the first element of the array.
It says an array *can* be blah blah ......
This doesn't prove anything you've said yourself the implementation can
basically do what it likes.
and somewhere else in the standard it is explicitely written down, that
an array undergoes this Array-to-pointer conversion, if the name of
an array shows up in an argument list of a function call.
And we still pass an array to the function.
What the compiler does with it does not alter the fact that we have passed
an array to a function.
> Assume an integer is 4 bytes and we have an array of 500 integers
that takes > up 2000 bytes right?
> How can we put 2000 bytes into a pointer that's only 4 bytes?
Why would we need to? Well how else would you convert the array to a pointer?
By taking the address of the first element of the array and use this
address as pointer value. (See above: 4.2 Array-to-pointer
conversion).
But the value of an array is exactly this so why would you need to convert
anything.
Have you ever dereferenced an array?
I don't see where the conversion comes in. What are you converting?
int* anArray = new int[128]
Why do you need to convert this to pass it to a function?
I don't see why they're making a big fuss about passing arrays to functions.
There's no need to convert anything.
>
> Here's another example:
> int* array = new int[500];
>
> Do you suggest the identifier 'array' is not an array?
That's correct. 'array' is a pointer.
> Are arrays on the heap not real arrays or something?
They are, but they are unnamed. They can only be referred to by a
pointer.
So it's a real array but it's unnamed. hmmm
But what about the identifier 'array', isn't that it's name?
Yes. But 'array' in the above is a pointer. You wrote it to
be a pointer
No I wrote it to be an array. It's an array
I cannot treat this array identifier as if it were a pointer to an int.
This identifier is an array identifier and it MUST be treated as such.
I don't see where you get off on calling arrays pointers. We all know that
under the hood it points to the first element.
Once it has been allocated storage for an array it becomes an array
identifier.
int* array
Remeber?
This pointer is assigned the starting address of an array. (How can this
be done? Same thing: 4.2 - by taking the address of the first array
alement und using that address as the address of the array).
Yes we don't need a lecture on array indexing.
So what if I did:
#include <iostream>
#define ARRAY128(a)(a=new char[128])
typedef char* ARRAYT;
int main()
{
ARRAYT arrayidentifier;
ARRAY128(arrayidentifier);
for(int i=0; i<128; ++i){
arrayidentifier[i] = i;
std::cout<< i <<": "<< arrayidentifier[i]<<" \t";
}
}
Is this an unnamed array of does this array have a name?
The array still doesn't have a name.
But the pointer pointing to it has: arrayidentifier
So what if I took the value of that pointer( the address) would that be the
name of the array?
Can this array be passed to a function?
Arrays are never passed to functions. Only pointers to them are.
When will you stop claiming silly things.
But then I could say no variables are ever passed to functions, only either
copies of varaibles or pointers to varaibles are passed.
The actual memory location is not actually passed as that would be silly.
You can't move the physical memory location into a function.
You seem to foget that almost every variable is stored someplace in
memory ,
And you seem to forget what pointers really are.
There is a difference between:
int m[3];
and
int* n = new int [3];
the former looks like this:
m
+------+
| |
+------+
| |
+------+
| |
+------+
while the later looks like this:
n
+------+ +-----+
| o--------------->| |
+------+ +-----+
| |
+-----+
| |
+-----+
Is that your attempt at explaining the difference between program memory
area and free store memory areas? :-)
"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:40***************@gascad.at... "Jumbo >>Because arr1 is a pointer, you were able to assign a new value to
it. >
> So you can't assign new values to an array?
No, you cannot.
Well if you really think this your obviously a bit of a crackpot.
Learn the language.
You cannot assign arrays. That's how it is since at least 20 years in C
and C++ didn't change it.
--
Learn to read.
He said you cannot assign to an array.
Would you like a demonstration of how to assign to an array?
int intarr[1];
intarr[0] =256;
I don't see what your problem is with this simple assignment.
Would you like a demonstration of how to declare and initialise a simple
variable first? Then you might be better prepared to move onto arrays. :-)
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bu*************@news.t-online.com... Jumbo wrote:
I don't get you here. The C++ standard defines char as an integer
type, so what else would it be? It just happens to be the type that
is often used to store characters, though that probably will change
in the future, with wide characters and multi-language programs that
need unicode support.
Well that is very confusing.
On my system a char is 1 byte and an integer is 4 bytes.
So how is a char type an integer type?
Ok, I have to admit that char is not an integer type, but it is an
integral type. And signed char and unsigned char still are integer
types. Some quotes from the chapter 3.9.1 "Fundamental types" of the
C++ standard:
Glad to see your eventually starting to come to your senses:-)
2 There are four signed integer types: "signed char", "short int",
"int", and "long int". ...
3 For each of the signed integer types, there exists a corresponding
(but different) unsigned integer type: "unsigned char", "unsigned
short int", "unsigned int", and "unsigned long int"...
...
7 Types bool, char, wchar_t, and the signed and unsigned integer
types are collectively called integral types. ...
> Just because an array happens to be turned into a pointer by the
> compiler when you pass it to a function deoesn't mean to say that
> we're not passing an array to a function.
Yes it is. You can determine the size of an array, but if you pass a
pointer to its first element to a function, you will only get the
size of a pointer, not of the array, since a pointer was passed to
the function, not an array. Another difference is that passing a
value to a funciton means that this value is copied, and the function
works on a copy. This is not the case for arrays, since arrays are
not copyable. The funciton can access the original array through a
pointer, not a local copy.
Consider the following array:
int* Array = new int[128];
Do you suggest this is not an array since you cannot determine the
size of it?
Depends on what you refer to as 'this'. 'Array' is a pointer, and you
can determine its size. It would be 4 on my machine. The array that it
points to doesn't have a name, and therefore, its size cannot be
determined, since sizeof either needs a type or the name of a variable.
Have you ever tried to determine the size of that array, I mean by
experimenting with a real compiler? I would love to see how you can
find out that size.
Hang on ...
Determining the size.........
determining.......
Determining the size..........
ok got it! :-)
It's err 128 x sizeof(int)
Do you want to know how I figured this out?
According to your idea there is no array here it's simply a pointer.
The pointer is the identifier for the array.
No. The array doesn't have an identifier.
The array is identified by some memory address , this memory address is
stored in a variable which we use to access the array.
Therefore the identifier for this array as far as we are concerned is.....
'Array'
This is the same when you pass an array to a function, the pointer to
the first index is passed as this is the identifier for the array.
You may prefer to call it a pointer and that's fine but your saying
that it's not an array and it is an array.
Again: A pointer is _not_ an array. Therefore, what you pass cannot be a
pointer and an array at the same time. It can only be _one_.
I never said a pointer was an array.
I can pass an array to a function without any problem whether it wants to
consider itself as an array, a pointer, a memory location, or a
electronically charged piece of material, or even a cluster of charged
atoms. Or perhaps it is an object?
So I may have just said an array was all of these things but I never said a
pointer was an array. did I?
It can still be indexed like an array so how do you explain that if
it's not an array?
The indexing is a pointer operation. Writing:
ptr[4] = 5;
is just a more convenient way of writing:
*(ptr + 4) = 5;
i.e. writing 5 into the address that is 4 beyond the pointer 'ptr'. And
since you can write it the other way round, too:
*(4 + ptr) = 5;
You can do the same with the index operator:
4[ptr] = 5;
Yes but your making out as if the pointer method is normative when it's
quite the opposite.
The normal way is to use the subscript operators and yes I have documents
that expalin all this too
it goes something like this:
quote:
A postfix-expression followed by the subscript operator, [ ], specifies
array indexing. A subscript expression represents the value at the address
that is expression positions beyond postfix-expression when expressed as
Usually, the value represented by postfix-expression is a pointer value,
such as an array identifier, and expression is an integral value (including
enumerated types).
end quote.
Note the bit that states:
the value represented by postfix-expression is a pointer value, such as an
array identifier
I do wish you'd take note of this as it is from a good source.
Still, 4 is not an array, and ptr not an index into it. When you use the
index operator on an array, this array is first converted into a
pointer to its first element, so that the index operator actually works
on a pointer.
> We're still passing an array to a function and it's not a copy.
That's my point. Passing something means making a copy of it, unless
you pass a reference. No there are two ways to pass
by ref (not meaning the reference type)
Passing by reference means passing a reference. If you pass a pointer,
you pass a pointer. Nothing else.
No. There is a refernece type in C++ and when you say passing by reference
this does not necesarilly mean passing by reference type.
by val
Where is it defined that passing to a function means *making a copy of
it* ?
Passing by value does. Passing an array by reference is possible, and
that indeed doesn't copy it. That would look e.g. like:
#include <iostream>
void myfunc(int (&arr)[100])
{
std::cout << sizeof(arr) // prints the size of the array
<< std::endl;
}
int main()
{
int arr[100];
myfunc(arr);
}
But this doesn't clarify where it stipulates that when you pass too a
function it must be by value.
> You seem to be meaning that passing an array to a function is only
> passing the array if it passes a copy.
Yes, because that's what passing a value means in C++.
Yeah well passing by value is a different thing from simply passing.
Passing by value _is_ "simply passing". If you want to simply pass an
int, you do:
void myfunc(int i) // pass an int - by value
{
}
If you instead want to pass by reference, you have to explicitly say so:
void myfunc(int& i) // by reference, not "simply" by value
{
}
LOL This is nonsense. If you don't state one way or the other it doesn't
mean passing by value is to be assumed . Most of the time your working with
pointers and passing by reference anyway it's more common to specifically
stipulate when you want to pass value, now you bring it up. If I say I can't pass an object to a function...
I'm not saying I can't pass it by value but I can pass it by reference
am I?
Yes, and I showed above what passing an arary by reference looks like.
It's of limited use though, because the size is hard-coded in the
function.
It's actually quite usefull way of extracting the size of the array.
But you seem to be missing the point that passing by reference does not
simply mean passing by reference type, you can pass pointers or address too
which can also be considered 'passing by ref'
Not being able to pass an object is different from not being
able to make a copy of an object.
Yes.
So do you agree that we can pass the object to a function yet?
"Jumbo
ok here's the array:
int* array = new int[128];
So what do you want to convert?
You mean something like this:
array = (int*) array;
????
I don't understand what you need to convert , I don't need to covnert
anything when I use arrays.
What are you talking about converting?
What has all this to do with calling a function. That's what
is the topic.
When an array is used as an argument to a function and pass
by value is used, the array decays into a pointer to it's first
element.
Since there are only 2 mechanisms to pass arguments to functions in C++
* pass by value
* pass by reference
and pass by reference it pretty useless, we are left with: In pass
by value you can't pass an array, since the array decays into a pointer
to it's first value. It is exactly this pointer that gets passed and
not the array itself.
So if the implementation can do what it likes then it can pass arrays
to functions if it likes no?
Yes, as long as it behaves as if the array was not passed.
Well I got somebody else arguing this point.
Seen as it wasn't my point in the first place and nothing to do with me.
perhapss you and Karl should take this up.
If you read carefully, we say the same thing:
Yes, as long as it behaves as if the array was not passed.
No, since you can not pass an array.
No I don't doubt anything I *know* I can pass an array to a function.
Then obviously you know more then the rest of the C++ community
(including the C++ standard and all compiler construction people).
A array cannot be passed per value.
Yes, just like any other dynamically allocated object.
So does this mean we can't pass any dynamically created objects to
functions?
No, who said that?
No. It's the name of a pointer that points to its first element. If you
lose that pointer, the array is still there, but can't be accessed,
because it doen't have a name and there is no pointer to it.
But what if I copied the memory address in another variable or even in a
file or something.
Then you have another pointer to that memory.
So strictly speaking: the allocated memory gets unaccessible when the
last pointer to that memory is lost. But that is nitpicking in a place
where nitpicking is absolutely unecesarry. Don't present yourself thumber
then you are.
Then you could destroy the whole program and I could still access the array.
If a tree falls in a wood and nobody is around, will it make a noise?
Arrays don't live in a file. The concept of arrays has a meaning
during program execution only.
So what if I did:
#include <iostream>
#define ARRAY128(a)(a=new char[128])
typedef char* ARRAYT;
int main()
{
ARRAYT arrayidentifier;
ARRAY128(arrayidentifier);
for(int i=0; i<128; ++i){
arrayidentifier[i] = i;
std::cout<< i <<": "<< arrayidentifier[i]<<" \t";
}
}
Is this an unnamed array of does this array have a name?
It is unnamed.
Then what shall we name it?
Do you have one of then books for expecting parents?
Can this array be passed to a function?
No, it can't. Using the preprocessor to hide the fact that ARRAYT is a
pointer won't change that.
What if I did this:
template<class ARRAY>
void foo(ARRAY arrayidentifier){
}
then passed arrayidentifier to this function. Am I not passing the array to
this function?
No you are not. No matter how often you repeat that, you cannot
pass arrays in C++ per value.
No. It _has_ a memory address that you can put into a pointer.
Then surely the pointer is the name or identifier for that particular area
of memory.
The pointer points to that memory. But the memory still has no name.
Otherwise we'de be going around calling everything that area of memory with
no name at offset blah blah blah.
If you say that an array is not an array because it's simply
a pointer to an area in memory
_You_ are saying that, not Kevin. I quote from another posting from you:
It's you's who are saying array identifiers are pointers and not arrays,
Nobody said that.
Array identifiers decay under certain circumstances into pointers to
their first element, but they are *not* pointers.
don't try and turn the tables at this stage.
Were you going to quote something?> arr is not an array, but a pointer to its first element.
But that's just what an array is.
This was his quote, in case you missed it. And you clearly were
wrong. An array is not a pointer, a pointer is not an array.
--
Karl Heinz Buchegger kb******@gascad.at
"Jumbo @uko2.co.uk>" <pcr1000011<nospam> wrote in message news:10***************@news.minx.net.uk... He said you cannot assign to an array.
Would you like a demonstration of how to assign to an array?
int intarr[1];
intarr[0] =256;
intarr[0] is NOT an array. It is an int that happens to be in an array.
You can't assign arrays. They are the only data type in C++ that
doesn't have assignment semantics.
"Jumbo and somewhere else in the standard it is explicitely written down, that
an array undergoes this Array-to-pointer conversion, if the name of
an array shows up in an argument list of a function call.
And we still pass an array to the function.
Not if you pass by value.
If an array is passed by value, it is always a pointer to the first
array element that gets passed.
That's not the same as passing an array.
What the compiler does with it does not alter the fact that we have passed
an array to a function.
It hasn't.
By taking the address of the first element of the array and use this
address as pointer value. (See above: 4.2 Array-to-pointer
conversion).
But the value of an array is exactly this so why would you need to convert
anything.
Have you ever dereferenced an array?
Yes. And so have you.
Whenever you write
array[i]
you dereference the array. This is because the compiler immediatly
transforms the above to:
*(array + i)
And this presents another case, where an array decays into a pointer
to its first element.
I don't see where the conversion comes in. What are you converting?
int* anArray = new int[128]
Why do you need to convert this to pass it to a function?
I don't know. You brought up the dynamic allocation in that example.
If I pass anArray to a function, then it is very clear that I don't
pass an array, since anArray isn't an array (even if it is named that way).
anArray is a pointer, and of course I can pass a pointer per value to
a function.
I don't see why they're making a big fuss about passing arrays to functions.
Because it can't be done.
There's no need to convert anything.
There is the need to decay the array into a pointer to its first element.
But doing this is a fundamental different thing then what is used in all
other cases of pass by value. Part of passing something by value is that
a copy of what is passed is created, but this does not happen in the case
of arrays. Which is very clear if we remember, that arrays are never passed
by reference, but only a pointer to their first element (but of course
one gets a copy of the original pointer, as usual when pass by value
is specified).
> >
> > Here's another example:
> > int* array = new int[500];
> >
> > Do you suggest the identifier 'array' is not an array?
>
> That's correct. 'array' is a pointer.
>
> > Are arrays on the heap not real arrays or something?
>
> They are, but they are unnamed. They can only be referred to by a pointer. >
So it's a real array but it's unnamed. hmmm
But what about the identifier 'array', isn't that it's name?
Yes. But 'array' in the above is a pointer. You wrote it to
be a pointer
No I wrote it to be an array.
Pardon me, but
int* array
clearly denotes a pointer!!!!!
What do with that pointer, what you assign to that pointer doesn't
matter. It is a pointer and it will stay a pointer until the variable
is detroyed.
It's an array
I cannot treat this array identifier as if it were a pointer to an int.
This identifier is an array identifier and it MUST be treated as such.
You are so clearly wrong.
I don't see where you get off on calling arrays pointers. We all know that
under the hood it points to the first element.
Once it has been allocated storage for an array it becomes an array
identifier.
Oh my.
That's all bullshit. Assigning something to a pointer doesn't
change the type of a variable.
Remeber?
This pointer is assigned the starting address of an array. (How can this
be done? Same thing: 4.2 - by taking the address of the first array
alement und using that address as the address of the array).
Yes we don't need a lecture on array indexing.
You obviously need a lot of lectures.
The array still doesn't have a name.
But the pointer pointing to it has: arrayidentifier
So what if I took the value of that pointer( the address) would that be the
name of the array?
No. An address is not a name (at least not in the sense of C++).
But then I could say no variables are ever passed to functions, only either
copies of varaibles or pointers to varaibles are passed.
This time you are right. When we say: a variable is passed per value
to a function, we implicitely mean: a copy of that variables value
is passed to the function and stored in a fresh varible denoted
in the parameter list.
But since this is a little bit long winded, we shorten this to: 'the
variable gets passed' and everybody knows what it means.
m
+------+
| |
+------+
| |
+------+
| |
+------+
while the later looks like this:
n
+------+ +-----+
| o--------------->| |
+------+ +-----+
| |
+-----+
| |
+-----+
Is that your attempt at explaining the difference between program memory
area and free store memory areas? :-)
No it is the attempt (a very successfull) to visualize pointers to people
which obviously have no clue about what pointers do and how to work with
them.
--
Karl Heinz Buchegger kb******@gascad.at
"Jumbo
"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:40***************@gascad.at... "Jumbo
> >>Because arr1 is a pointer, you were able to assign a new value to it. > >
> > So you can't assign new values to an array?
>
> No, you cannot.
Well if you really think this your obviously a bit of a crackpot.
Learn the language.
You cannot assign arrays. That's how it is since at least 20 years in C
and C++ didn't change it.
--
Learn to read.
He said you cannot assign to an array.
Would you like a demonstration of how to assign to an array?
int intarr[1];
intarr[0] =256;
You are not assigning to an array. You are assigning to an array element.
Thats a different thing.
Assigning to an array would be:
intarr = 5;
or
int jarray[1];
intarr = jarray;
I don't see what your problem is with this simple assignment.
Would you like a demonstration of how to declare and initialise a simple
variable first? Then you might be better prepared to move onto arrays. :-)
Given your performance in this group I don't think you are in the
position to give lessons :-)
--
Karl Heinz Buchegger kb******@gascad.at
"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message news:40***************@gascad.at...
Not if you pass by value.
If an array is passed by value, it is always a pointer to the first
array element that gets passed.
That's not the same as passing an array.
There's not even a function type tha takes an array as an argument. The language
specifically adjusts any declaration of arrays as parameters to pointer. The conversion
of array to pointer gets called to match the function type BEFORE it is actually passed.
"Jumbo
Consider the following array:
int* Array = new int[128];
Do you suggest this is not an array since you cannot determine the
size of it?
Depends on what you refer to as 'this'. 'Array' is a pointer, and you
can determine its size. It would be 4 on my machine. The array that it
points to doesn't have a name, and therefore, its size cannot be
determined, since sizeof either needs a type or the name of a variable.
Have you ever tried to determine the size of that array, I mean by
experimenting with a real compiler? I would love to see how you can
find out that size.
Hang on ...
Determining the size.........
determining.......
Determining the size..........
ok got it! :-)
It's err 128 x sizeof(int)
Do you want to know how I figured this out?
Yes. But this time with tighter rules.
Since you claim it is possible to pass an array into a function,
do it in seperate function. This function can only use what
is passed to it and no, you are not allowed to pass the
arrays size.
In other words, fill in the body in the following function skelton
which determines the passed arrays size:
void foo( int arr[] )
{
cout << ..... <- Please fill in here
}
No. The array doesn't have an identifier.
The array is identified by some memory address ,
That's not an identifier in the C++ sense.
is just a more convenient way of writing:
*(ptr + 4) = 5;
i.e. writing 5 into the address that is 4 beyond the pointer 'ptr'. And
since you can write it the other way round, too:
*(4 + ptr) = 5;
You can do the same with the index operator:
4[ptr] = 5;
Yes but your making out as if the pointer method is normative when it's
quite the opposite.
it *is* normative in the sense that it is the first thing a compiler
does when presented with an array subscript.
The normal way is to use the subscript operators and yes I have documents
that expalin all this too
it goes something like this:
quote:
Quote from where?
A postfix-expression followed by the subscript operator, [ ], specifies
array indexing. A subscript expression represents the value at the address
that is expression positions beyond postfix-expression when expressed as
Usually, the value represented by postfix-expression is a pointer value,
such as an array identifier, and expression is an integral value (including
enumerated types).
end quote.
Note the bit that states:
the value represented by postfix-expression is a pointer value, such as an
array identifier
I do wish you'd take note of this as it is from a good source.
Says who? (I mean: who says that this is a good source?)
All we care is the standards document. We don't need additional
good sources, cause all there is to say about C++ is written down
in the C++ standard.
--
Karl Heinz Buchegger kb******@gascad.at
Jumbo wrote: >> > If your array is an array of 500 integers how can you convert
>> > this to a single variable ?
>>
>> It's the address of the first one. This *is* the way the language
>> works, regardless of how much you deny it.
>
> Oh so now your not actually converting the array, your converting
> the array identifier into a pointer to the first element?
You should first get an understanding of what "convert" means in C++.
It means that you take an existing object and create from it a new
object that is another type. This doesn't neccesarily mean putting
all the data into the new object.
ok here's the array:
int* array = new int[128];
So what do you want to convert?
Nothing. new[] already returns a pointer.
You mean something like this:
array = (int*) array;
????
That's a cast, also called explicit conversion. If you want, you can
cast an array into a pointer, but if you don't it will be done
automatically where appropriate.
I don't understand what you need to convert , I don't need to covnert
anything when I use arrays.
Right, you don't convert explicitly. It's done implicitly for you.
> So if the implementation can do what it likes then it can pass
> arrays to functions if it likes no?
Yes, as long as it behaves as if the array was not passed.
Well I got somebody else arguing this point.
Seen as it wasn't my point in the first place and nothing to do with
me. perhapss you and Karl should take this up.
The implementation is allowed to internally pass the array, if it makes
it look like the array was not passed, though that seems pretty stupid,
because it would need a lot of extra work at no benefit. However, from
the programmer's point of view, that doesn't matter. For him, the array
was not passed to the function, whatever happened behind the scenes.
>> 4.2 Array-to-pointer conversion
>> [conv.array]
>>
>> 1 An lvalue or rvalue of type "array of N T" or "array of unknown
>> bound
>> of T" can be converted to an rvalue of type "pointer to
>> T." The result is a pointer to the first element of the array.
>
> It says an array *can* be blah blah ......
Right, and that's what you doubt above (and below, too).
No I don't doubt anything
You must have a bad short-term memory. Scroll up to the beginning of
this posting and read your own doubts.
I *know* I can pass an array to a function.
Then do so whenever you like. I am starting to suspect you are actually
just trolling, since you are repeatedly claiming things that got
disproven, even by quotes from the standard. You even got plonked by
respected and knowledgable regulars because you keep ignoring the
facts. Still you claim that you "*know*" different. And when you get
out of arguments, you are just starting to add new claims to discuss
about that are equally wrong.
>> > If your array is an array of 500 integers how can you convert
>> > this to a single variable ?
> This doesn't prove anything you've said yourself the implementation
> can basically do what it likes.
No. He said that under the hood, it can do what it likes, as long as
the behaviour is like the standard says. This is called the as-if
rule.
oh right so it can't do what it likes at all then.
That's a condraction in terms.
It can do what it likes as long as what it likes is not one of the
things that's not allowed (condradiction in terms, doesn't make sense
to me)
You don't understand or you pretend to not understand. I won't discuss
it anymore.
>> > Assume an integer is 4 bytes and we have an array of 500
>> > integers that takes up 2000 bytes right?
>> > How can we put 2000 bytes into a pointer that's only 4 bytes?
>>
>> Why would we need to?
> Well how else would you convert the array to a pointer?
You are under the false assumption that "conversion" means putting
all the bytes of an object into another. The iostreams have a
conversion operator to void*. So how is a whole stream object pressed
into a void*?
Well it's not I never said it was. :-)
Another contradicition. You can search the quote where you did that
yourself.
>> > Here's another example:
>> > int* array = new int[500];
>> >
>> > Do you suggest the identifier 'array' is not an array?
>>
>> That's correct. 'array' is a pointer.
>>
>> > Are arrays on the heap not real arrays or something?
>>
>> They are, but they are unnamed. They can only be referred to by a
>> pointer.
>>
> So it's a real array but it's unnamed.
Yes, just like any other dynamically allocated object.
So does this mean we can't pass any dynamically created objects to
functions?
No, it doesn't mean that. The facts that an array cannot be copied and
that it's is often converted into a pointer to its first element are
not connected to the fact that dynamically allocated objects don't have
a name.
> hmmm
> But what about the identifier 'array', isn't that it's name?
No. It's the name of a pointer that points to its first element. If
you lose that pointer, the array is still there, but can't be
accessed, because it doen't have a name and there is no pointer to
it.
But what if I copied the memory address in another variable
Then what? What happened to the name of the array? Is the name of the
new variable now suddenly the name of the array?
or even in a file or something.
Is now the file name the name of the array?
Then you could destroy the whole program and I could still access the
array. if nothing had overwritten that area of memory it could still
contain the same values too.
That heavily depends on the OS. On most modern systems, this won't work.
So we could have cross program arrays passing the address via files.
This is indeed done sometimes in some operating systems that allow such
things, but it's not required by the standard that this works, and it
won't on most systems. I bet you never tried this, like you never tried
any example that others posted here that would disprove your point or
writing any examples that prove any of your claims.
Then what if I encoded the memory address into a character string then
it could be classified as the name of the array then no?
No, not in C++.
> So what if I did:
> #include <iostream>
>
> #define ARRAY128(a)(a=new char[128])
> typedef char* ARRAYT;
>
> int main()
> {
> ARRAYT arrayidentifier;
> ARRAY128(arrayidentifier);
> for(int i=0; i<128; ++i){
> arrayidentifier[i] = i;
> std::cout<< i <<": "<< arrayidentifier[i]<<" \t";
> }
> }
>
> Is this an unnamed array of does this array have a name?
It is unnamed.
Then what shall we name it?
We can't name an object dynamically. Either it has a name at compile
time or none at all. Yours is allocated dynamically, which in turn can
only mean that it doesn't have a name.
Do you have one of then books for expecting parents?
> Can this array be passed to a function?
No, it can't. Using the preprocessor to hide the fact that ARRAYT is
a pointer won't change that.
What if I did this:
template<class ARRAY>
void foo(ARRAY arrayidentifier){
}
then passed arrayidentifier to this function. Am I not passing the
array to this function?
Nope. Again, you can easily try it out by yourself. Use sizeof or
typeid() on 'arrayidentifier' and look what size and type it has.
> You seem to foget that almost every variable is stored someplace in
> memory , therefore almost every variable is essentially a memory
> address.
No. It _has_ a memory address that you can put into a pointer.
Then surely the pointer is the name or identifier for that particular
area of memory.
The pointer _is_ not a name, it _has_ a name, and it _contains_ the
address of a memory location.
Otherwise we'de be going around calling everything that area of memory
with no name at offset blah blah blah.
I would be "going around calling" it "the object pointed to by the
pointer foo". If you access an object through a pointer, it doesn't
matter if that object has a name or not.
> If you say that an array is not an array because it's simply
> a pointer to an area in memory
_You_ are saying that, not Kevin. I quote from another posting from
you:
It's you's who are saying array identifiers are pointers
I'm saying the exact opposite. I'm saying pointers are not array
identifiers. Just scroll up a bit and you can see where you claimed
they are. I'll copy it here once again. You wrote: "Then surely the
pointer is the name or identifier for that particular area of memory."
and not arrays,
Array identifiers aren't arrays. They are the the names of arrays.
don't try and turn the tables at this stage.
Think about that again.
Were you going to quote something?
I did quote it. Just look at the below two lines. They were the quote I
was referring to: >> arr is not an array, but a pointer to its first element.
> But that's just what an array is.
> then you'd be aswell saying that for every type.
_You_ were claiming that an array is a pointer and passing a pointer
to a function means passing the array and when you were told that
this behaviour would be different from any other type, you wrote:
I wrote what?
The quote below. When I write "you wrote:" that means that the following
text is the quote.
This is the quote: > The thing is that arrays are passed by ref as opposed to most other
> data types, I wouldn't consider this as not passing an array.
And here, the quote ends.
"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:40***************@gascad.at... "Jumbo
<<followed by all kind of nonsense and anti-nonsense>>
While this thread has been fun, I begin to worry about Jumbo.
Has anyone considered that his brain might have been taken over by the
spirit of Herbert Schildt?
--
Gary [and not meaning to get into the fray, but MAKE A JOKE!] This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Simon Schaap |
last post by:
Hello,
I have encountered a strange problem and I hope you can help me to
understand it. What I want to do is to pass an array of chars to a
function that will split it up (on every location where...
|
by: Christian Maier |
last post by:
Hi
After surfing a while I have still trouble with this array thing. I
have the following function and recive a Segmentation fault, how must
I code this right??
Thanks
Christian Maier
|
by: cpptutor2000 |
last post by:
Could some C guru please help me?
I have a function that takes as an argument a pointer to an array of
unsigned chars (basically a hex representation of a dotted decimal IP
address). When I print...
|
by: Olaf Dietrich |
last post by:
I may just be temporarily (hopefully ...) stupid, but how can
I pass a function pointer between functions using an array of
(signed/unsigned) chars (in a standard-conforming way)?
E.g.:
I...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
