I understand that arrays and structs can't be passed by value into and out
of functions since they can be arbitrarily big. My question is: Why are
types allowed to be passed by value? Couldn't my types be arbitraily big as
well?
19  1721 
Method Man wrote: I understand that arrays and structs can't be passed by value into and out
of functions since they can be arbitrarily big.
You understand incorrectly, but only partially so. Objects of class
type _can_ be passed into functions and returned from functions by
value. Arrays cannot because they are not objects.
My question is: Why are
types allowed to be passed by value? Couldn't my types be arbitraily big as
well?
I am not sure what you mean here.
Victor
Method Man wrote: I understand that arrays and structs can't be passed by value into and out
of functions since they can be arbitrarily big. My question is: Why are
types allowed to be passed by value? Couldn't my types be arbitraily big as
well?
The simple answer is that long, long ago it was decided by the people
who designed C that arrays would be passed by reference instead of
value. If this was the best choice is open to debate, however we are
stuck with it now :)
In C++ it was decided that all classes should by default be passed by
value, as they were designed with the intention of being like the built
in types like int, char, etc rather than like arrays (note that this is
different to Java, where they are passed by reference). This was also a
decision which was made, and now we have to live with that too :)
Chris
Method Man wrote: I understand that arrays and structs can't be passed by value into and out
of functions since they can be arbitrarily big.
That's not entirely true. Structs _can_ be passed by value into and out
of function, regardless of how big they are. Arrays cannot, but not
because of their potential size, but rather because arrays are neither
assignable nor copy-constructible. This limitation for arrays has mostly
historical reasons.
My question is: Why are
types allowed to be passed by value? Couldn't my types be arbitraily big as
well?
What "your types"? Your non-scalar types in most cases will also be
"arrays or structs (classes)". How is that different from the first part
of the question?
--
Best regards,
Andrey Tarasevich
Method Man posted: I understand that arrays and structs can't be passed by
value into and out of functions since they can be arbitrarily big.
Incorrect.
They can.
It's just that it's recommended against in certain
circumstances.
My question is: Why
are types allowed to be passed by value? Couldn't my
types be arbitraily big as well?
Yes, but you've the choice.
Choice is better than no choice.
There's times when I *do* pass a string by value, or return
one by value.
-JKop
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:E5*************@newsread1.dllstx09.us.to.veri o.net... Method Man wrote: I understand that arrays and structs can't be passed by value into and
out of functions since they can be arbitrarily big.
You understand incorrectly, but only partially so. Objects of class
type _can_ be passed into functions and returned from functions by
value. Arrays cannot because they are not objects.
Hmm, I'm not sure why I included structs. My mistake. > My question is: Why are
types allowed to be passed by value? Couldn't my types be arbitraily big
as well?
I am not sure what you mean here.
Sorry, I wasn't clear on my intent. Here's an example:
If I create a type with an array as a data member, and I'm allowed to pass
an object of my type by value into a function, wouldn't all its members be
copied over (incl. the array)? So how would this work?
"Method Man" <a@b.c> wrote in message
news:Cu******************@read2.cgocable.net...
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:E5*************@newsread1.dllstx09.us.to.veri o.net... Method Man wrote: I understand that arrays and structs can't be passed by value into and out of functions since they can be arbitrarily big.
You understand incorrectly, but only partially so. Objects of class
type _can_ be passed into functions and returned from functions by
value. Arrays cannot because they are not objects.
Hmm, I'm not sure why I included structs. My mistake.
> My question is: Why are
types allowed to be passed by value? Couldn't my types be arbitraily
big as well?
I am not sure what you mean here.
Sorry, I wasn't clear on my intent. Here's an example:
If I create a type with an array as a data member, and I'm allowed to pass
an object of my type by value into a function, wouldn't all its members be
copied over (incl. the array)?
Yes.
So how would this work?
struct myType
{
char text[100];
int other;
};
void foo(myType param)
{
}
int main()
{
struct myType obj = {"hello", 0};
foo(obj);
return 0;
}
-Mike
Method Man wrote: I understand that arrays and structs can't be passed by value into
and out of functions since they can be arbitrarily big.
As others have pointed out, your assertion about structs is incorrect.
It's not correct for C either. In fact, one way of handling the array
problem is to wrap the array in a struct. That's mostly useful for C,
in C++ the vector standard container is available.
Brian Rodenborn
Method Man wrote: ...
If I create a type with an array as a data member, and I'm allowed to pass
an object of my type by value into a function, wouldn't all its members be
copied over (incl. the array)?
Yes.
So how would this work?
Hmm... They are just copied. One subobject after another. Which also
applies to arrays. Arrays are copied element by element.
--
Best regards,
Andrey Tarasevich
Andrey Tarasevich posted: Method Man wrote: ...
If I create a type with an array as a data member, and
I'm allowed to pass an object of my type by value into a function,
wouldn't all its members be copied over (incl. the array)?
Yes.
So how would this work?
Hmm... They are just copied. One subobject after another.
Which also applies to arrays. Arrays are copied element by element.
Even if you have complicated ones:
struct blah
{
std::string a[6];
std::vector b[8];
};
When you pass it by value, their copy constructors will be
called, ie. 6 copy constructed strings, 8 copy constructed
vectors!
-JKop
In article <NY******************@read2.cgocable.net>, Method Man <a@b.c> wrote: I understand that arrays and structs can't be passed by value into and out
of functions since they can be arbitrarily big. My question is: Why are
types allowed to be passed by value? Couldn't my types be arbitraily big as
well?
"Original C" did not allow structs to be passed or returned
(or assigned), but now does, as does C++ (with different rules
for non-PODs). As I understood it, the premise of the original
C constraint is that passing such items can be expensive.
Ditto for arrays (which have some of their own issues too).
Even with their allowance they can be. But yes, even your
types can be. For instance, a struct with 1000 int members
is surely larger than a array of 5 chars. So as usual,
as the programmer, you need to be aware of what you're doing
in any situation.
If this is not what you mean, please elaborate in the NG.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
"JKop" <NU**@NULL.NULL> wrote in message
news:Ul******************@news.indigo.ie... Andrey Tarasevich posted:
Method Man wrote: ...
If I create a type with an array as a data member, and I'm allowed to pass an object of my type by value into a function, wouldn't all its members be copied over (incl. the array)?
Yes.
So how would this work?
Hmm... They are just copied. One subobject after another.
Which also applies to arrays. Arrays are copied element by element.
Even if you have complicated ones:
struct blah
{
std::string a[6];
std::vector b[8];
};
When you pass it by value, their copy constructors will be
called, ie. 6 copy constructed strings, 8 copy constructed
vectors!
Ok, I think I understand now. I'll attempt to summarize what I got from this
thread.
An array itself can't be passed by value because it is not an object and not
copy-constructable. But if we simply wrap our array in a struct or class and
pass an object of that type by value, the compiler copies the array for us
element-by-element.
Sounds to me like the original restriction on arrays is pointless. I guess
I'll live ;)
"Greg Comeau" <co****@panix.com> wrote in message
news:ci**********@panix2.panix.com... In article <NY******************@read2.cgocable.net>, Method Man <a@b.c>
wrote: I understand that arrays and structs can't be passed by value into and
outof functions since they can be arbitrarily big. My question is: Why are
types allowed to be passed by value? Couldn't my types be arbitraily big
aswell?
"Original C" did not allow structs to be passed or returned
(or assigned), but now does, as does C++ (with different rules
for non-PODs). As I understood it, the premise of the original
C constraint is that passing such items can be expensive.
Ditto for arrays (which have some of their own issues too).
Thanks for clearing that up.
On Thu, 16 Sep 2004 22:22:33 -0400, "Method Man" <a@b.c> wrote in
comp.lang.c++:
"JKop" <NU**@NULL.NULL> wrote in message
news:Ul******************@news.indigo.ie... Andrey Tarasevich posted:
Method Man wrote:
> ...
> If I create a type with an array as a data member, and I'm allowed to> pass an object of my type by value into a function,
wouldn't all its> members be copied over (incl. the array)?
Yes.
> So how would this work?
Hmm... They are just copied. One subobject after another.
Which also applies to arrays. Arrays are copied element by element.
Even if you have complicated ones:
struct blah
{
std::string a[6];
std::vector b[8];
};
When you pass it by value, their copy constructors will be
called, ie. 6 copy constructed strings, 8 copy constructed
vectors!
Ok, I think I understand now. I'll attempt to summarize what I got from this
thread.
An array itself can't be passed by value because it is not an object and not
copy-constructable. But if we simply wrap our array in a struct or class and
pass an object of that type by value, the compiler copies the array for us
element-by-element.
No, an array is an object. The definition of the term 'object' in C++
has nothing at all to do with 'object oriented programming' or with
classes or user defined types.
Bare arrays are not copyable in C and C++ because of limitations that
existed when C was developed 30 odd years ago, given the type of
programming and programmers it was originally intended for.
If either C or C++ was ever changed to make bare arrays copyable, or
passable to and returnable from functions, some new syntax would have
to be developed, it couldn't be just by using the unadorned name of
the array.
If the automatic conversion from array name to pointer to first
element in function calls and return statements was ever changed, it
would break 99% of all the C and C++ programs that have ever existed.
Sounds to me like the original restriction on arrays is pointless. I guess
I'll live ;)
It wouldn't have been so pointless if, 30 plus years ago, you were an
expert systems programmer on the typical small minicomputers of the
day and your objective was to make a reasonably portable high level
language compact and efficient enough so that it could be used to
write operating systems, instead of assembly language in which they
were all written in up to that time.
I doubt if anyone was more surprised than Dennis Ritchie to see the
range of platforms and applications that C has taken on. Not to
mention the even larger applications done in C++.
--
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
In message <rV*****************@read1.cgocable.net>, Method Man <a@b.c>
writes
Sounds to me like the original restriction on arrays is pointless. I guess
I'll live ;)
It's inherited from C. Because in most contexts the name of an array
"decays" to a pointer to its first element, there's usually no way to
tell the compiler that what you want to pass is the whole array, not
just the pointer.
--
Richard Herring
In article <rV*****************@read1.cgocable.net>, Method Man <a@b.c> wrote: "JKop" <NU**@NULL.NULL> wrote in message
news:Ul******************@news.indigo.ie... Andrey Tarasevich posted: > Method Man wrote:
>> ...
>> If I create a type with an array as a data member, and I'm allowed to >> pass an object of my type by value into a function,
wouldn't all its >> members be copied over (incl. the array)?
>
> Yes.
>
>> So how would this work?
>
> Hmm... They are just copied. One subobject after another.
Which also > applies to arrays. Arrays are copied element by element.
>
Even if you have complicated ones:
struct blah
{
std::string a[6];
std::vector b[8];
};
When you pass it by value, their copy constructors will be
called, ie. 6 copy constructed strings, 8 copy constructed
vectors!
Ok, I think I understand now. I'll attempt to summarize what I got from this
thread.
An array itself can't be passed by value because it is not an object and not
copy-constructable.
The array is an object, just ends up being a second class citizen
for various reasons.
But if we simply wrap our array in a struct or class and
pass an object of that type by value, the compiler copies the array for us
element-by-element.
Well, it copies it.
Sounds to me like the original restriction on arrays is pointless. I guess
I'll live ;)
No, very pointful. Rememeber that C started out as a systems
programming language. So it was used for things like building
operating systems. You really did not want arrays passed
by value so willy-nilly. Slapping them down into pointers
to their first elements that get passed instead made sense.
As with all things, it's a compromise, so that's not always
going to be what you want. Languages and machines have
evolved over the years, but adding array copying now would
require different syntax, and with things like C++'s
std::string, std::venctor<> etc, this is "exactly" what we've got
to some extent. Those additions to have their own issues
and compromises.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jack Klein wrote: ...
If either C or C++ was ever changed to make bare arrays copyable, or
passable to and returnable from functions, some new syntax would have
to be developed, it couldn't be just by using the unadorned name of
the array.
And why exactly is the reason for that, in your opinion? Backward
compatibility considerations that you mention later? Aside from that, I
don't see any other reason for any syntax changes.
If the automatic conversion from array name to pointer to first
element in function calls and return statements was ever changed, it
would break 99% of all the C and C++ programs that have ever existed.
That's definitely true.
--
Best regards,
Andrey Tarasevich
In article <10*************@news.supernews.com>,
Andrey Tarasevich <an**************@hotmail.com> wrote: Jack Klein wrote: ...
If either C or C++ was ever changed to make bare arrays copyable, or
passable to and returnable from functions, some new syntax would have
to be developed, it couldn't be just by using the unadorned name of
the array.
And why exactly is the reason for that, in your opinion? Backward
compatibility considerations that you mention later? Aside from that, I
don't see any other reason for any syntax changes.
What for instance would this do:
"xyz" = "a";
?
What would say sizeof this new array allowance do? And when?
And so on.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Greg Comeau wrote: Andrey Tarasevich <an**************@hotmail.com> wrote:Jack Klein wrote: ...
If either C or C++ was ever changed to make bare arrays copyable, or
passable to and returnable from functions, some new syntax would have
to be developed, it couldn't be just by using the unadorned name of
the array.
And why exactly is the reason for that, in your opinion? Backward
compatibility considerations that you mention later? Aside from that, I
don't see any other reason for any syntax changes.
What for instance would this do:
"xyz" = "a";
?
Generate a diagnostic because of type incompatibility: 'char[4]' against
'char[2]'. Even if array sizes were the same it would still generate a
diagnostic for an attempt to modify a non-modifiable lvalue.
What would say sizeof this new array allowance do? And when?
I don't understand this question. Could you please rephrase that?
--
Best regards,
Andrey Tarasevich
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:p0********************************@4ax.com... On Thu, 16 Sep 2004 22:22:33 -0400, "Method Man" <a@b.c> wrote in
comp.lang.c++: An array itself can't be passed by value because it is not an object and
not
copy-constructable. But if we simply wrap our array in a struct or class
and
pass an object of that type by value, the compiler copies the array for
us
element-by-element.
No, an array is an object. The definition of the term 'object' in C++
has nothing at all to do with 'object oriented programming' or with
classes or user defined types.
.... If either C or C++ was ever changed to make bare arrays copyable, or
passable to and returnable from functions, some new syntax would have
to be developed, it couldn't be just by using the unadorned name of
the array.
I think that tr1 already brings us a solution:
template<class T, size_t N> struct array;
(6.2 in http://open-std.org/jtc1/sc22/wg21/d...2004/n1687.pdf)
When you want your array to be copied by value, replace:
float foo[10];
with:
array<float,10> foo;
As a bonus, you'll get a container-compatible interface
including begin(), end(), etc.
Cheers -Ivan
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: jr |
last post by:
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...
|
by: rahul8143 |
last post by:
hello,
why following both programs executes in different manner that
mean first goes in infinite loop and second one executes 0.
NOTE:- I am using Microsoft visual studio 6 to program C...
|
by: Abe Frohnman |
last post by:
Hello all,
I'm passing a reference to a class into the constructor of a form, like
so: public MyForm(int count, ref Area myArea) {...}
How can I use myArea outside the constructor? Should I...
|
by: phoenix |
last post by:
Hello,
I've got a design question. I need to keep track of some variables and I am
planning to put them inside a class or struct. Basically I'm talking about
10 bools, 20 ints and 2 arrays of...
|
by: Mr Newbie |
last post by:
I am often in the situation where I want to act on the result of a function,
but a simple boolean is not enough. For example, I may have a function
called
isAuthorised ( User, Action ) as ?????...
|
by: Andrew Bullock |
last post by:
Hi,
I have two classes, A and B,
B takes an A as an argument in its constructor:
A a1 = new A();
B b = new B(a1);
|
by: BenWeber |
last post by:
I have XML formed as follows (this is just a part of the XML)
- <players>
- <player id="814090">
<name>Brian</name>
<surname>Bradford</surname>
<countryfrom id="4">USA</countryfrom>...
|
by: David |
last post by:
I feel like an idiot asking this but here goes: I understand the 'concept'
of scope and passing data by value and/or by reference but I am confused on
some specifics.
class example{
int i; //my...
|
by: Bryan Parkoff |
last post by:
I write my large project in C++ source code. My C++ source code
contains approximate four thousand small functions. Most of them are
inline. I define variables and functions in the global scope....
|
by: mcl |
last post by:
Why can I not the change the value of a variable in another class,
when I have passed it via a parameter list.
I am sure I am being stupid, but I thought passed objects were Read/
Write
eg...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
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: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
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...
| |
