473,322 Members | 1,431 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

const reference vs. value

Dear members of comp.lang.c++,
I am a little bit confused about the differences between constant
references and values. I understand that it is faster to use a constant
reference ("const T&") than a value ("T") since the former does not
require copying whereas the latter does, is that correct? Also, I un
derstand that "const T&" allows for polymorphism whereas "T" will
generate code cuttting.
On the former points, I am fairly confident... But I'm somewhat
confused on how the two influence conversions. For example, suppose I
define the following type:

class Real{
public:
Real(int)
Real(float);
Real(double);
Real(long double);
...
Real operator+(Real);
};

Can I now write the following?
Real x = 5.0;
Real y = x + 3;
//is above legal now if I don't define Real::operator+(int)?

Now, suppose I change the declaration+definition of
Real::operator+(Real) to Real::operator+(const Real&), is the above
still legal? Or do I need to modify the above to the following?

Real x = 5.0;
Real tmp = 3;
Real y = x + tmp;

**************************************

In short, can one convert an unnamed constant to a constant reference or
only to a value?
Aug 17 '06 #1
8 4070
Michael Safyan posted:
Dear members of comp.lang.c++,
I am a little bit confused about the differences between constant
references and values. I understand that it is faster to use a constant
reference ("const T&") than a value ("T") since the former does not
require copying whereas the latter does, is that correct?

Generalised answer: For large user-defined types, yes. For built-in types,
no.

In C++, references are "magical". The Standard says everything about how
they behave, but absolutely nothing about what they actually are.

In C, everything was passed by value, and everything was returned by value.
If you wanted to alter an object in the calling function, then you passed
its address. There was one other time, however, in C, where you passed the
object's address: when the object type was large and it would have been
more efficient to pass its address rather than passing the object by value.

As mysterious as references may be, they're still apart of our world, and
must obey the laws of our physics and so forth. If you have a scenario such
as:

struct PictureInfo {

unsigned width;
unsigned height;
unsigned colour_depth;

/* More members */
};

void Func(PictureInfo const &info)
{
/* Do stuff with the object */
}

Then the compiler will treat it as if you wrote:

void Func(PictureInfo const *const p)

For the most part, references are exactly like const pointers -- const
pointers which you don't have to dereference.

There's something special about "references to const" though. If you bind a
"reference to const" to an R-value, then an object is created which lives
until the reference goes out of scope. Writing the following:

{
int &r = 5;
}

is effectively like writing:

{
int const five = 5;
int &r = five;
}

Also, I un derstand that "const T&" allows for polymorphism whereas "T"
will generate code cuttting.

Indeed. In general though, you should always be passing user-defined
objects by reference to const, rather than by value.

On the former points, I am fairly confident... But I'm somewhat
confused on how the two influence conversions. For example, suppose I
define the following type:

class Real{
public:
Real(int)
Real(float);
Real(double);
Real(long double);
...
Real operator+(Real);
};

Can I now write the following?
Real x = 5.0;
Real y = x + 3;
//is above legal now if I don't define Real::operator+(int)?

Question to Physics teacher:
"I have an apple in my hand; if I let go of it, will gravity pull it to
the ground?"

Answer from Physics teacher:
"Why are you asking *me* when you can try compile it with your own
compiler?"

Now, suppose I change the declaration+definition of
Real::operator+(Real) to Real::operator+(const Real&), is the above
still legal? Or do I need to modify the above to the following?

Would it be legal if you passed its address? References are just a fancy
way of passing around addresses.

--

Frederick Gotham
Aug 17 '06 #2
Frederick Gotham wrote:
Michael Safyan posted:
>Dear members of comp.lang.c++,
I am a little bit confused about the differences between constant
references and values. I understand that it is faster to use a constant
reference ("const T&") than a value ("T") since the former does not
require copying whereas the latter does, is that correct?


Generalised answer: For large user-defined types, yes. For built-in types,
no.

In C++, references are "magical". The Standard says everything about how
they behave, but absolutely nothing about what they actually are.

In C, everything was passed by value, and everything was returned by value.
If you wanted to alter an object in the calling function, then you passed
its address. There was one other time, however, in C, where you passed the
object's address: when the object type was large and it would have been
more efficient to pass its address rather than passing the object by value.

As mysterious as references may be, they're still apart of our world, and
must obey the laws of our physics and so forth. If you have a scenario such
as:

struct PictureInfo {

unsigned width;
unsigned height;
unsigned colour_depth;

/* More members */
};

void Func(PictureInfo const &info)
{
/* Do stuff with the object */
}

Then the compiler will treat it as if you wrote:

void Func(PictureInfo const *const p)

For the most part, references are exactly like const pointers -- const
pointers which you don't have to dereference.

There's something special about "references to const" though. If you bind a
"reference to const" to an R-value, then an object is created which lives
until the reference goes out of scope. Writing the following:

{
int &r = 5;
}

is effectively like writing:

{
int const five = 5;
int &r = five;
}

>Also, I un derstand that "const T&" allows for polymorphism whereas "T"
will generate code cuttting.


Indeed. In general though, you should always be passing user-defined
objects by reference to const, rather than by value.

> On the former points, I am fairly confident... But I'm somewhat
confused on how the two influence conversions. For example, suppose I
define the following type:

class Real{
public:
Real(int)
Real(float);
Real(double);
Real(long double);
...
Real operator+(Real);
};

Can I now write the following?
Real x = 5.0;
Real y = x + 3;
//is above legal now if I don't define Real::operator+(int)?


Question to Physics teacher:
"I have an apple in my hand; if I let go of it, will gravity pull it to
the ground?"

Answer from Physics teacher:
"Why are you asking *me* when you can try compile it with your own
compiler?"
Because not all compilers are conformant, and I have been having
difficulty getting it to work either way. Although, I submit, I have
been using a more complicated instance than the example given here.
>
>Now, suppose I change the declaration+definition of
Real::operator+(Real) to Real::operator+(const Real&), is the above
still legal? Or do I need to modify the above to the following?


Would it be legal if you passed its address? References are just a fancy
way of passing around addresses.
Yes, I understand that... Then I suppose I misstated the question.
>
The question is this:
Given the two definitions type::func(const type&) and type::func(type),
does the compiler use different rules to match these? Given
type::type(int) and either type::func(const type&) or type::func(type),
does the compiler accept type::func(5) in both cases? If not does it
accept it in any case?

Aug 17 '06 #3
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:ns*******************@news.indigo.ie...
>
Question to Physics teacher:
"I have an apple in my hand; if I let go of it, will gravity pull it
to
the ground?"

Answer from Physics teacher:
"Why are you asking *me* when you can try compile it with your own
compiler?"
Because my compiler might accept non-standard code?
Would it be legal if you passed its address? References are just a fancy
way of passing around addresses.
References are just a way of renaming objects. That's all. They can be
implemented by passing around addresses, but that's no requirement. For
example:

void fn(int &x) { x = 2*x; }

This function would be horrible if implemented as pass-by-address, when x
could simply be passed in and out by value. The compiler is free to
implement the function this way, and it should.

--
Philip Potter

Aug 17 '06 #4
In article <ns*******************@news.indigo.ie>,
Frederick Gotham <fg*******@SPAM.comwrote:
>In C++, references are "magical". The Standard says everything about how
they behave, but absolutely nothing about what they actually are.
This is true of many things though.
>In C, everything was passed by value,
And how are they passed now? :)

Anyway, in C array's are not passed by value.
>...
{
int &r = 5;
}

is effectively like writing:

{
int const five = 5;
int &r = five;
}
No, that's an error. Actually both forms are. You probably mean
const int &r
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
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?
Aug 17 '06 #5
Michael Safyan wrote:
Dear members of comp.lang.c++,
I am a little bit confused about the differences between constant
references and values. I understand that it is faster to use a constant
reference ("const T&") than a value ("T") since the former does not
require copying whereas the latter does, is that correct?
Not necessarily. If the copying is trivial, you may introduce
worse performance with the reference. For example, it's probably
a lose with any numeric or pointer type. Small POD classes probably
also may not be a win. However, when you've got something with a
large amount of internally-managed dynamic memory, you are right.
Using the original (read-only) rather than a copy is going to win.

Can I now write the following?
Real x = 5.0;
Real y = x + 3;
//is above legal now if I don't define Real::operator+(int)?
Yes, because you have converting constructors to go from int to Real.
>
Now, suppose I change the declaration+definition of
Real::operator+(Real) to Real::operator+(const Real&), is the above
still legal? Or do I need to modify the above to the following?
No problem, and this is specifically why you want to make it a
CONST reference. A non-const reference could not be bound to
the temporary converted value.
In short, can one convert an unnamed constant to a constant reference or
only to a value?
If it will convert to a value, it will convert to a const-reference.
Aug 17 '06 #6

Greg Comeau wrote:
In article <ns*******************@news.indigo.ie>,
Frederick Gotham <fg*******@SPAM.comwrote:
In C++, references are "magical". The Standard says everything about how
they behave, but absolutely nothing about what they actually are.

This is true of many things though.
In C, everything was passed by value,

And how are they passed now? :)

Anyway, in C array's are not passed by value.
In C arrays are not passed at all. Arrays degrade to pointers any time
they are used as an r-value. The pointer is passed by value to the
function. Even when you use syntax such as:

void c(int arr[]);

arr is actually a pointer inside of 'c'. All the above syntax does is
inform the human reader that the input is expected to be an array. To
the compiler it means exactly the same thing as:

void c(int * arr);

Aug 17 '06 #7
Ron Natalie wrote:
Michael Safyan wrote:
>Dear members of comp.lang.c++,
I am a little bit confused about the differences between constant
references and values. I understand that it is faster to use a
constant reference ("const T&") than a value ("T") since the former
does not require copying whereas the latter does, is that correct?

Not necessarily. If the copying is trivial, you may introduce
worse performance with the reference. For example, it's probably
a lose with any numeric or pointer type. Small POD classes probably
also may not be a win. However, when you've got something with a
large amount of internally-managed dynamic memory, you are right.
Using the original (read-only) rather than a copy is going to win.

>Can I now write the following?
Real x = 5.0;
Real y = x + 3;
//is above legal now if I don't define Real::operator+(int)?

Yes, because you have converting constructors to go from int to Real.
>>
Now, suppose I change the declaration+definition of
Real::operator+(Real) to Real::operator+(const Real&), is the above
still legal? Or do I need to modify the above to the following?

No problem, and this is specifically why you want to make it a
CONST reference. A non-const reference could not be bound to
the temporary converted value.
>In short, can one convert an unnamed constant to a constant reference
or only to a value?

If it will convert to a value, it will convert to a const-reference.
Thank you so much. That was exactly what I wanted to know.
Aug 17 '06 #8
In article <11**********************@p79g2000cwp.googlegroups .com>,
Noah Roberts <ro**********@gmail.comwrote:
>Greg Comeau wrote:
>In article <ns*******************@news.indigo.ie>,
Frederick Gotham <fg*******@SPAM.comwrote:
>In C++, references are "magical". The Standard says everything about how
they behave, but absolutely nothing about what they actually are.

This is true of many things though.
>In C, everything was passed by value,

And how are they passed now? :)

Anyway, in C array's are not passed by value.

In C arrays are not passed at all.
In some cross-breeding of terms, actually more informally it's
boinks into the realm of 'pass by reference' which is not
about C++ references though some of the underlying machinery
may be similar, and which has the semantics your desribe.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
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?
Aug 18 '06 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Bolin | last post by:
Hi all, A question about smart pointers of constant objects. The problem is to convert from Ptr<T> to Ptr<const T>. I have look up and seen some answers to this question, but I guess I am too...
19
by: Christian Engström | last post by:
If you have a function that returns something by value, the gcc compiler (version 3.2.3 on Windows XP with MinGW) converts the returned value from the type you specify in the code, to the const...
39
by: JKop | last post by:
Back when I read my first C++ book, I was given the following scenario: class Cheese { public: int number_of_holes; int colour;
11
by: modemer | last post by:
If I define the following codes: void f(const MyClass & in) {cout << "f(const)\n";} void f(MyClass in) {cout<<"f()\n";} MyClass myclass; f(myclass); Compiler complain that it can't find...
2
by: Eric Lilja | last post by:
Hello, consider this complete program: #include <iostream> #include <string> using std::cout; using std::endl; using std::string; class Hanna {
4
by: grizggg | last post by:
I have searched and not found an answer to this question. I ran upon the following statement in a *.cpp file in a member function: static const char * const pacz_HTMLContentTypeHeader =...
10
by: JurgenvonOerthel | last post by:
Consider the classes Base, Derived1 and Derived2. Both Derived1 and Derived2 derive publicly from Base. Given a 'const Base &input' I want to initialize a 'const Derived1 &output'. If the...
2
by: wizofaus | last post by:
Given the following code: public class Test { static unsafe void StringManip(string data) { fixed (char* ps = data) ps = '$'; }
3
by: George2 | last post by:
Hello everyone, I am debugging MSDN code from, http://msdn2.microsoft.com/en-us/library/0eestyah(VS.80).aspx here is my output, 1>main.cpp
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.