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

Reference to a reference

P: n/a
Hi,
I am reading Modern C++ Design where Anderi quoted "C++ does not allow
references to references".

Assume i have
DoThat(const string& strData2)
{
...
}

DoThis(const string& strData)
{
..
DoThat(strData);
}

int main()
{
string Data;
DoThis(Data);
}

Now the strData i have inside DoThis is a reference to Data.The
strData2 I have is a reference to strData.i.e strData2 is a reference
to a reference.
Here Andrei's statement confuses me..Am i missing something?

Thanks,
Senthil

Oct 27 '05 #1
Share this Question
Share on Google+
51 Replies


P: n/a
Senthil wrote:
Hi,
I am reading Modern C++ Design where Anderi quoted "C++ does not allow
references to references".

Assume i have
DoThat(const string& strData2)
{
...
}

DoThis(const string& strData)
{
..
DoThat(strData);
}

int main()
{
string Data;
DoThis(Data);
}

Now the strData i have inside DoThis is a reference to Data.The
strData2 I have is a reference to strData.i.e strData2 is a reference
to a reference.
Here Andrei's statement confuses me..Am i missing something?

Thanks,
Senthil


What's the context (section number and paragraph)? Perhaps he means
that you can't do with references what you can do with pointers:

int anInt = 42;
int *pointer_to_int = &anInt;
int **pointer_to_pointer_to_int = &pointer_to_int;

Cheers! --M

Oct 27 '05 #2

P: n/a

Senthil wrote:
Hi,
I am reading Modern C++ Design where Anderi quoted "C++ does not allow
references to references".

Assume i have
DoThat(const string& strData2)
{
...
}

DoThis(const string& strData)
{
..
DoThat(strData);
}

int main()
{
string Data;
DoThis(Data);
}

Now the strData i have inside DoThis is a reference to Data.The
strData2 I have is a reference to strData.i.e strData2 is a reference
to a reference. Here you are wrong. strData2 is a reference to a string according with
its declaration.
Here Andrei's statement confuses me..Am i missing something?

Thanks,
Senthil


/dan

Oct 27 '05 #3

P: n/a
Senthil wrote:
Hi,
I am reading Modern C++ Design where Anderi quoted "C++ does not allow
references to references".

Assume i have
DoThat(const string& strData2)
According to the declaration, strData2 is a reference to const string.
{
...
}

DoThis(const string& strData)
According to the declaration, strData is a reference to const string.
{
..
DoThat(strData);
}

int main()
{
string Data;
DoThis(Data);
}

Now the strData i have inside DoThis is a reference to Data.The
strData2 I have is a reference to strData.
It's a refernce to Data.
i.e strData2 is a reference to a reference.


No. If allowed, a reference to a reference would be declared something like:

const string&& strData2

Oct 27 '05 #4

P: n/a

mlimber wrote:
you can't do with references what you can do with pointers:

int anInt = 42;
int *pointer_to_int = &anInt;
int **pointer_to_pointer_to_int = &pointer_to_int;


than what are references are good for? what can be done with
references, that cannot be done with pointers?

Oct 27 '05 #5

P: n/a
* Senthil:

I am reading Modern C++ Design where Anderi quoted "C++ does not allow
references to references".

Assume i have
DoThat(const string& strData2)
{
...
}

DoThis(const string& strData)
{
..
DoThat(strData);
}

int main()
{
string Data;
DoThis(Data);
}

Now the strData i have inside DoThis is a reference to Data.The
strData2 I have is a reference to strData.i.e strData2 is a reference
to a reference
No, strdata2 refers to the same object that strData refers to.

Here Andrei's statement confuses me..Am i missing something?


Yes, in addition to the above, and what Andrei's sentence is all about:
that C++ doesn't currently allow the syntax T&&, or U& when U is a
reference type, which is the probem for template code (it can be solved,
as Andrei shows, but it's awkward).

Bjarne Stroustrup has suggested (possibly this was just with regard to
template code) that T&& should be allowed, and defined to mean T&.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Oct 27 '05 #6

P: n/a

makc.the.gr...@gmail.com wrote:
mlimber wrote:
you can't do with references what you can do with pointers:

int anInt = 42;
int *pointer_to_int = &anInt;
int **pointer_to_pointer_to_int = &pointer_to_int;


than what are references are good for? what can be done with
references, that cannot be done with pointers?


http://www.parashift.com/c++-faq-lite/references.html

particularly

http://www.parashift.com/c++-faq-lit...s.html#faq-8.6

Gavin Deane

Oct 27 '05 #7

P: n/a
> particularly
http://www.parashift.com/c++-faq-lit...s.html#faq-8.6


so, what's your point? what can be done with reference and can not be
done with pointer, again?

Oct 27 '05 #8

P: n/a
Thanks for all your replies..Just to make clear that i've understood it
properly,
The following should be invalid program right ?

int main()
{
int i = 10;
int &r1 = i;
int &r2 = r1;

return 0;
}

Best Regards,
Senthil

Oct 27 '05 #9

P: n/a
de*********@hotmail.com wrote:
makc.the.gr...@gmail.com wrote:
mlimber wrote:
you can't do with references what you can do with pointers:

int anInt = 42;
int *pointer_to_int = &anInt;
int **pointer_to_pointer_to_int = &pointer_to_int;


than what are references are good for? what can be done with
references, that cannot be done with pointers?


http://www.parashift.com/c++-faq-lite/references.html

particularly

http://www.parashift.com/c++-faq-lit...s.html#faq-8.6


Also, references are necessary for operator overloading:

#include <ostream>
using namespace std;

class Foo { /* ... */ };

ostream& operator<< ( ostream& os, const Foo& foo )
{
// Stream elements of Foo here ...
return os;
}

void Bar( const Foo& foo )
{
cout << "Here's your Foo:\n" << foo << endl;
// ...
}

We couldn't do this with pointers.

Cheers! --M

Oct 27 '05 #10

P: n/a
<ma************@gmail.com> schrieb im Newsbeitrag
news:11**********************@g47g2000cwa.googlegr oups.com...
particularly
http://www.parashift.com/c++-faq-lit...s.html#faq-8.6


so, what's your point? what can be done with reference and can not be
done with pointer, again?


Nothing. AFAIK references are usually implemented as pointers.
But references exist because they are more convenient to use because
references can't be NULL.

Greetings Chris
Oct 27 '05 #11

P: n/a

Senthil wrote:
Thanks for all your replies..Just to make clear that i've understood it
properly,
The following should be invalid program right ?

int main()
{
int i = 10;
int &r1 = i;
int &r2 = r1;

return 0;
}

Best Regards,
Senthil


No. That is valid. Both r1 and r2 refer to the same object (in this
case, i).

Cheers! --M

Oct 27 '05 #12

P: n/a
"Senthil" <s.**********@gmail.com> schrieb im Newsbeitrag
news:11*********************@g14g2000cwa.googlegro ups.com...
Thanks for all your replies..Just to make clear that i've understood it
properly,
The following should be invalid program right ?

int main()
{
int i = 10;
int &r1 = i;
int &r2 = r1;

return 0;
}

Best Regards,
Senthil
No, this program is valid. r2 is a reference to an int as you can see in
your declaration of r2: int &r2 = r1;


But as already mentioned before, you can't do something like
int&& r2 = r1;

Greetings Chris
Oct 27 '05 #13

P: n/a

mlimber wrote:
references are necessary for operator overloading:
We couldn't do this with pointers.


okay, agreed...

though this is because of the way operators are "implemented" or
"defined" in c++. I can imagine a language, where there would be no
difference between "variables" and "pointers" presented to programmer,
so that constants would be only objects....

Oct 27 '05 #14

P: n/a

ma************@gmail.com wrote:
particularly
http://www.parashift.com/c++-faq-lit...s.html#faq-8.6


so, what's your point? what can be done with reference and can not be
done with pointer, again?


You've snipped a lot of context. You originally asked two questions.

1 what are references are good for?
2 what can be done with references, that cannot be done with pointers?

faq 8.6 answers question 1.

I also pointed you at all of section 8
http://www.parashift.com/c++-faq-lite/references.html
Read this whole section and you will find the answer to question 2 (e.g
faq 8.3).

HTH
Gavin Deane

Oct 27 '05 #15

P: n/a

Christian Meier wrote:
because
references can't be NULL.


how about:
int* i = 0; int &j = *i;

it gives me no errors, no warnings.

Oct 27 '05 #16

P: n/a
oh wait. then we would loose math operations with pointers.

Oct 27 '05 #17

P: n/a

makc.the.gr...@gmail.com wrote:
Christian Meier wrote:
because
references can't be NULL.


how about:
int* i = 0; int &j = *i;

it gives me no errors, no warnings.


So you compiled it. Did you run it?

Gavin Deane

Oct 27 '05 #18

P: n/a

deane_ga...@hotmail.com wrote:
makc.the.gr...@gmail.com wrote:
Christian Meier wrote:
because
references can't be NULL.


how about:
int* i = 0; int &j = *i;

it gives me no errors, no warnings.


So you compiled it. Did you run it?

Gavin Deane


yes, it runs fine.
there can't be error until you USE j. and I do not :-p

Oct 27 '05 #19

P: n/a
de*********@hotmail.com wrote in news:1130423577.642411.300190
@g43g2000cwa.googlegroups.com:

makc.the.gr...@gmail.com wrote:
Christian Meier wrote:
> because
> references can't be NULL.


how about:
int* i = 0; int &j = *i;

it gives me no errors, no warnings.


So you compiled it. Did you run it?


It may run too (without crashing). Doesn't matter. Undefined Behaviour
has been invoked by dereferencing a NULL pointer. To the OP: remember that
when one says that references may not be "NULL", there is an implicit "in a
well-formed C++ program" attached to the end of the statement. By
dereferencing a NULL pointer, the program is no longer well-formed. Try to
make a reference to "NULL" without invoking undefined behaviour first.
Oct 27 '05 #20

P: n/a

makc.the.gr...@gmail.com wrote:
deane_ga...@hotmail.com wrote:
makc.the.gr...@gmail.com wrote:
Christian Meier wrote:
> because
> references can't be NULL.

how about:
int* i = 0; int &j = *i;

it gives me no errors, no warnings.


So you compiled it. Did you run it?

Gavin Deane


yes, it runs fine.
there can't be error until you USE j. and I do not :-p


My understanding, and I may be wrong, is that simply trying to
dereference i in your code is undefined behaviour. Even if you never
use j, from here on in anything (including the classic and unfortunate
"it did exactly what I expected") is possible.

Gavin Deane

Oct 27 '05 #21

P: n/a
"Senthil" <s.**********@gmail.com> wrote in news:1130422385.054927.50140
@g14g2000cwa.googlegroups.com:
Thanks for all your replies..Just to make clear that i've understood it
properly,
The following should be invalid program right ?

int main()
{
int i = 10;
int &r1 = i;
int &r2 = r1;

return 0;
}


Nope.

Right after the "int &r1 = i" line, anytime you use r1, it's really
referring to i (effectively). So when "int &r2 = r1" is done, it is
effectively the same as "int &r2 = i". Net result is that i, r1, and r2
all refer to i.
Oct 27 '05 #22

P: n/a

Andre Kostur wrote:
To the OP: remember that
when one says that references may not be "NULL", there is an implicit "in a
well-formed C++ program" attached to the end of the statement. By
dereferencing a NULL pointer, the program is no longer well-formed.


how about replacing
int* i = 0;
with
int* i = some_obscure_function_returning_zero_on_rare_occas ion();

Oct 27 '05 #23

P: n/a

makc.the.gr...@gmail.com wrote:
Andre Kostur wrote:
To the OP: remember that
when one says that references may not be "NULL", there is an implicit "in a
well-formed C++ program" attached to the end of the statement. By
dereferencing a NULL pointer, the program is no longer well-formed.


how about replacing
int* i = 0;
with
int* i = some_obscure_function_returning_zero_on_rare_occas ion();


Then on those rare occasions, int&j = *i; invokes the same undefined
behaviour.

Gavin Deane

Oct 27 '05 #24

P: n/a
> Then on those rare occasions, int&j = *i; invokes the same undefined
behaviour.

yes, but the point was that my program is perfectly legal. this bad
function can, for example, be a part of somebody else's library.

Oct 27 '05 #25

P: n/a

Andre Kostur wrote:
"Senthil" <s.**********@gmail.com> wrote in news:1130422385.054927.50140
@g14g2000cwa.googlegroups.com:
Thanks for all your replies..Just to make clear that i've understood it
properly,
The following should be invalid program right ?

int main()
{
int i = 10;
int &r1 = i;
int &r2 = r1;

return 0;
}


Nope.

Right after the "int &r1 = i" line, anytime you use r1, it's really
referring to i (effectively). So when "int &r2 = r1" is done, it is
effectively the same as "int &r2 = i". Net result is that i, r1, and r2
all refer to i.


Thanks for the enlightment folks :)

Oct 27 '05 #26

P: n/a

makc.the.gr...@gmail.com wrote:
Then on those rare occasions, int&j = *i; invokes the same undefined
behaviour.

yes, but the point was that my program is perfectly legal. this bad
function can, for example, be a part of somebody else's library.


While the usual request (particularly since Google went braindead) is
to snip more, it would actually help if you snipped a little less to
keep a bit more context.

The code in question is:

int* i = some_obscure_function_returning_zero_on_rare_occas ion();
int&j = *i; // Undefined if i is null.

The name of that function suggests that it is expected to return zero
sometimes (rarely but still sometimes). In which case you need to check
for that before dreferencing i.

If what you actually meant was

int* i = library_function_that_should_not_return_zero_but_h as_a_bug();
int&j = *i;

then you need to have a word with the library vendor.

Either way, if your code dereferences a null pointer, you have invoked
undefined behaviour. Well formed code does not do that.

Gavin Deane

Oct 27 '05 #27

P: n/a

deane_ga...@hotmail.com wrote:
While the usual request (particularly since Google went braindead) is
to snip more, it would actually help if you snipped a little less to
keep a bit more context.
why? you do know what are we talking about.
The name of that function suggests that it is expected to return zero
sometimes (rarely but still sometimes).


the name of function doesn't suggest anything to a compiler. the
program is well-formed no matter how functions are named.

Oct 27 '05 #28

P: n/a

makc.the.gr...@gmail.com wrote:
deane_ga...@hotmail.com wrote:
While the usual request (particularly since Google went braindead) is
to snip more, it would actually help if you snipped a little less to
keep a bit more context.


why? you do know what are we talking about.


I've had to twice copy bits of context you'd deleted in order to make
my point. If I'm going to post a comment on some code or a response to
a question, I want my post to also contain that code or question.
Otherwise anyone reading it has to go back to previous messages in the
thread to understand what I'm on about. And I understand that forcing
people to have to do that is considered impolite.
The name of that function suggests that it is expected to return zero
sometimes (rarely but still sometimes).


the name of function doesn't suggest anything to a compiler. the
program is well-formed no matter how functions are named.


OK, we're into the precise definition of well-formed here aren't we.
And I'm not sure what that is. If I've got you right, you're argument
is that

int* i = third_party_library_function();
int& j = *i;

is well formed even if it may invoke undefined behaviour, because the
null pointer comes from outside _your_ code.

If that's what you're saying then I'll have to leave it to someone else
to explain whether the code is well formed. There _may_ be a
distinction between the case where third_party_library_function is
expected to return zero and the case where third_party_library_function
can never return zero (except it does because it has a bug).

Incidentally, I seem to be losing the space before j and after &. I've
no idea why.

Gavin Deane

Oct 27 '05 #29

P: n/a
ma************@gmail.com wrote:

deane_ga...@hotmail.com wrote:
While the usual request (particularly since Google went braindead) is
to snip more, it would actually help if you snipped a little less to
keep a bit more context.
why? you do know what are we talking about.


This is not a private discussions. Others don't, and those shouldn't need to
dig into previous posts to search for what you are referring to. After all,
that's why quoting is done in usenet.
The name of that function suggests that it is expected to return zero
sometimes (rarely but still sometimes).


the name of function doesn't suggest anything to a compiler.


No, but to the user, it does. It suggests that the returned value might be a
null pointer, which means that he has to check for that condition before
dereferencing the pointer. If (and only if) you know that the function
_never_ returns a null pointer, you can omit that check.
the program is well-formed no matter how functions are named.


Syntactically, it's ok, but its behavior is undefined. If the returned
pointer is null, a null pointer is dereferenced, which invokes undefined
behaivor.
Oct 27 '05 #30

P: n/a
ma************@gmail.com wrote:
oh wait. then
when?
we would loose math operations with pointers.


we would?
Oct 27 '05 #31

P: n/a
de*********@hotmail.com wrote:
OK, we're into the precise definition of well-formed here aren't we.
And I'm not sure what that is.
The C++ standard defines the term "well-formed program" as "a C++ program
constructed according to the syntax rules, diagnosable semantic rules, and
the One Definition Rule". Simplified, that means that it's well-formed if
the compiler can't detect any errors. However, that doesn't mean that the
code is correct.
If I've got you right, you're argument
is that

int* i = third_party_library_function();
int& j = *i;

is well formed even if it may invoke undefined behaviour, because the
null pointer comes from outside _your_ code.


It's well-formed, but still erroneous, because the "*i" invokes undefined
behavior for the case of i == 0, and invoking undefined behavior is an
error.

Oct 27 '05 #32

P: n/a

Andre Kostur wrote:
de*********@hotmail.com wrote in news:1130423577.642411.300190
@g43g2000cwa.googlegroups.com:

makc.the.gr...@gmail.com wrote:
Christian Meier wrote:
> because
> references can't be NULL.

how about:
int* i = 0; int &j = *i;

it gives me no errors, no warnings.


So you compiled it. Did you run it?


It may run too (without crashing). Doesn't matter. Undefined Behaviour
has been invoked by dereferencing a NULL pointer. To the OP: remember that
when one says that references may not be "NULL", there is an implicit "in a
well-formed C++ program" attached to the end of the statement. By
dereferencing a NULL pointer, the program is no longer well-formed. Try to
make a reference to "NULL" without invoking undefined behaviour first.


Actually dereferencing a NULL pointer does not by itself entail
undefined behavior, although the Standard is currently currently
somewhat inconsistent on that point. But according to Language Defect
report #232 the Standard needs to be more clear that that the undefined
behavior actually occurs by retrieving the value referenced by the null
pointer and not by deferencing the null pointer itself. In which case,
the program above is well-formed since j's value is not accessed.

Or, to take this an example from the defect report itself:

char *p = 0;
char *q = &*p;

Again these statements are well formed since the value referenced by p
is not obtained.

Greg

Oct 27 '05 #33

P: n/a

Rolf Magnus wrote:
This is not a private discussions. Others don't, and those shouldn't need to
dig into previous posts to search for what you are referring to. After all,
that's why quoting is done in usenet.

this is ridiculous. if, instead of quoting exactly words one is
referring to, s/he would quote all of above thread, lengthy discussions
would end up in multy-KBs messages noone would ever read. what's the
point? not to mention pointless servers overload.

and this "diggin in previous posts" part I don't understand. I usually
dig in next messages, because all discusions have their 1st messages -
if I were not interested in that message, why would I want to jump in
somwhere in the middle? on the other hand, if I did jumped in, it's
because middle message was that of interest, and digging back is not
necessary.

finally, if you don't like short messages, you don't have to replay at
all.

Oct 27 '05 #34

P: n/a
"Greg" <gr****@pacbell.net> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

Andre Kostur wrote:
de*********@hotmail.com wrote in news:1130423577.642411.300190
@g43g2000cwa.googlegroups.com:
>
> makc.the.gr...@gmail.com wrote:
>> Christian Meier wrote:
>> > because
>> > references can't be NULL.
>>
>> how about:
>> int* i = 0; int &j = *i;
>>
>> it gives me no errors, no warnings.
>
> So you compiled it. Did you run it?
It may run too (without crashing). Doesn't matter. Undefined
Behaviour has been invoked by dereferencing a NULL pointer. To the
OP: remember that when one says that references may not be "NULL",
there is an implicit "in a well-formed C++ program" attached to the
end of the statement. By dereferencing a NULL pointer, the program
is no longer well-formed. Try to make a reference to "NULL" without
invoking undefined behaviour first.


Actually dereferencing a NULL pointer does not by itself entail
undefined behavior, although the Standard is currently currently


Really? The standard seems to state it in a few places:

Section 1.9.4 Where it talks about undefined behaviour, uses
dereferencing a null pointer as an example

Section 8.3.2.4 (Which actually talks about "null" references) says that
"... obtained by dereferencing a null pointer which causes undefined
behaviour..."

somewhat inconsistent on that point. But according to Language Defect
report #232 the Standard needs to be more clear that that the
undefined behavior actually occurs by retrieving the value referenced
by the null pointer and not by deferencing the null pointer itself. In
which case, the program above is well-formed since j's value is not
accessed.

Or, to take this an example from the defect report itself:

char *p = 0;
char *q = &*p;

Again these statements are well formed since the value referenced by p
is not obtained.


I haven't read the defect report though... so I'll take your word on it.
But I'd expect that to be undefined behaviour as well...
Oct 27 '05 #35

P: n/a
de*********@hotmail.com wrote in news:1130426617.786044.43880
@g47g2000cwa.googlegroups.com:
> The name of that function suggests that it is expected to return zero
> sometimes (rarely but still sometimes).


the name of function doesn't suggest anything to a compiler. the
program is well-formed no matter how functions are named.


OK, we're into the precise definition of well-formed here aren't we.
And I'm not sure what that is. If I've got you right, you're argument
is that


This will have to be my fault. I'm the one who brought the term "well-
formed" into the argument. I could have been more accurate. I should have
said "well-formed, and does not invoke undefined behaviour".

Oct 27 '05 #36

P: n/a
ma************@gmail.com wrote:
Rolf Magnus wrote:
This is not a private discussions. Others don't, and those shouldn't need to
dig into previous posts to search for what you are referring to. After all,
that's why quoting is done in usenet. this is ridiculous. if, instead of quoting exactly words one is
referring to, s/he would quote all of above thread, lengthy discussions
would end up in multy-KBs messages noone would ever read. what's the
point? not to mention pointless servers overload.


Who said anything about quoting the entire thread?
and this "diggin in previous posts" part I don't understand.


Which "diggin in previous posts" part? Part of what? What don't you
understand?

According to what you attribute to Rolf Magnus, he didn't mention
anything about digging in previous posts. Oh, I see. You didn't quote
enough context for your comment to be meaningful. QED

<snip>

Gavin Deane

Oct 27 '05 #37

P: n/a
de*********@hotmail.com wrote:
Part of what? What don't you
understand?
According to what you attribute to Rolf Magnus, he didn't mention
anything about digging in previous posts. Oh, I see. You didn't quote
enough context for your comment to be meaningful.


So?

Why should someone would comment on something, if he does not
understand what it is about? Just leave it ot, if you were not around
when it's started.

Oct 28 '05 #38

P: n/a

ma************@gmail.com wrote:
de*********@hotmail.com wrote:
Part of what? What don't you
understand?
According to what you attribute to Rolf Magnus, he didn't mention
anything about digging in previous posts. Oh, I see. You didn't quote
enough context for your comment to be meaningful.


So?

Why should someone would comment on something, if he does not
understand what it is about? Just leave it ot, if you were not around
when it's started.


You obviously missed the part about newsgroups not being the place for
private conversations (like this has become, so I'm stopping after this
post). But I guess you're happy that as long as _you_ understand your
own posts, you don't care that everyone else can't follow them. Fair
enough. At least we all know not to take any notice of anything you say
any more.

Gavin Deane

Oct 28 '05 #39

P: n/a
Neo
OK.. heres what i understood about references.

void swap(int &a, int &b)
{
int t=a,a=b,b=t;
}
int main()
{
int c=5,d=10;
swap(c,d);
/* here i thought that when compiling, c++ treats a nd b as c and d. So
i assumed i cannot use the function swap more than one time as a and b
cannot be substituted by another e and f.

if we indeed can then the compiler is internally looking into the
matter and substituting the pointers as required(we can see this in the
disassembly). this makes the reference arguement as a macro (which
saddens me)

What am i missing?
*/

}

Oct 29 '05 #40

P: n/a
Neo wrote:
OK.. heres what i understood about references.

void swap(int &a, int &b)
{
int t=a,a=b,b=t;
This declares three objects, 't', 'a', and 'b', all local, all with
automatic storage duration. It does not swap 'a' and 'b' arguments.
It attempts to _hide_ them. Unsuccessfully, of course. Curiously,
if it worked, 'a' would only be hidden after 't' is assigned its value
from the "real" 'a'. And 'b' would only be hidden after the local 'a'
gets its value from the "real" 'b'...

You should probably think of using semicolons instead of commas there:

int t=a; a=b; b=t;

otherwise, it's not well-formed.
}
int main()
{
int c=5,d=10;
swap(c,d);
/* here i thought that when compiling, c++ treats a nd b as c and d.
Yes, and...
So i assumed i cannot use the function swap more than one time as a
and b cannot be substituted by another e and f.
Every time the function is called, its formal arguments are initialised
from the actual arguments. That's the only way to "assign" a reference.
if we indeed can then the compiler is internally looking into the
matter and substituting the pointers as required(we can see this in
the disassembly). this makes the reference arguement as a macro (which
saddens me)

What am i missing?
Probably nothing. There are two kinds of references: those that have the
same scope as the referred objects, and those that don't. The ones that
don't have to be implemented somehow. If the function is inlined, we
might assume that the references in the inner scopes truly become aliases
but not all functions can be inlined. So, an alternative implementation
of references is needed. A pointer is it. Why it would sadden anybody
is beyond my comprehension.
*/

}


V
Oct 29 '05 #41

P: n/a

de*********@hotmail.com wrote:
part about newsgroups not being the place for
private conversations it's up to me to decide. really.
as long as _you_ understand your
own posts, you don't care that everyone else can't follow them.

1st, you != everyone
2nd, if you can't follow, you can't say anything good, so why saying
anything at all.

I just don't get it. If you care, you will "follow", if you don't - you
just don't, there's no reason to attach multikilobytes of quotes.

Oct 29 '05 #42

P: n/a
ma************@gmail.com wrote:

de*********@hotmail.com wrote:
part about newsgroups not being the place for
private conversations it's up to me to decide. really.


Actually, the nature of this medium is for nobody to decide. It so happens
to be public by design.
[snip] I just don't get it.
No need to state the obvious.

If you care, you will "follow", if you don't - you
just don't, there's no reason to attach multikilobytes of quotes.


a) You might want to read a little bit about propagation of posts in usenet.
It is actually not at all guaranteed that the history of this thread is
present on, e.g., my server. Thus quoting is not just a matter of curtesy,
it is a reasonable measure to deal with a technological feature of this
medium.

b) Read up on proper trimming. Nobody here is talking "multikilobytes."
Best

Kai-Uwe Bux
Oct 29 '05 #43

P: n/a
Neo
Thanks Vic.. but i still dont understand what you mean by 'HIDE'. If
you could tell me how the compiler puts in the binary i could
undersatnd.

Also am i right in assuming that the simple function i wrote cannot be
used twice in the main fn. according to C++ standard.

Also are reference arg functions inine by default.

Neo

Oct 29 '05 #44

P: n/a
TIT
Neo sade:
Thanks Vic.. but i still dont understand what you mean by 'HIDE'. If
you could tell me how the compiler puts in the binary i could
undersatnd.

The compiler has nothing to do with it. Perhaps a book would suffice.

void swap(int &a, int &b)
{
int t=a,a=b,b=t;
}

This function (above) that you wrote is ill-formed, as you try
to declare 'a' and 'b' twice. A corrected version:

void swap(int &a, int &b)
{
int t=a;
a=b;
b=t;
}
Also am i right in assuming that the simple function i wrote cannot be
used twice in the main fn. according to C++ standard.

Of course this corrected function can be used several times in main
and elsewhere:

int main() {
int a = 0, b = 1, c = 3, d = 4, e = 5;
swap(a,b);
swap(c,d);
swap(e,b);
swap(d,c);
swap(a,e);
return 0;
}

Consider this rewriten version of swap with pointers:

void swap( int * a, int * b ) {
int t = *a;
*a = *b;
*b = t;
}

int main() {
int a = 0, b = 1, c = 3, d = 4, e = 5;
swap(&a,&b);
swap(&c,&a);
swap(&e,&b);
swap(&d,&c);
swap(&a,&c);
return 0;
}
Also are reference arg functions inine by default.


No. Just because an argument is a reference doesn't mean
that the function is suitable to be inlined.

TIT
Oct 29 '05 #45

P: n/a
Neo schrieb:
Thanks Vic.. but i still dont understand what you mean by 'HIDE'. If
you could tell me how the compiler puts in the binary i could
undersatnd.


#include <iostream>

int i = 5;

int main()
{
int i = 42;

std::cout << i << std::endl;
}

What is the output of the program?

It is 42, because the local variable i in function main *hides* the
other variable i on file scope. I.e. if two variables with the same name
exist, the name finds the variable of the inner-most block.

Thomas
Oct 29 '05 #46

P: n/a
Neo wrote:
Thanks Vic.. but i still dont understand what you mean by 'HIDE'.
If you define a scope inside another scope (a compound statement inside
another compound statement, for example), any object declared in the
inner scope hides the object with the same name in the outer scope. It
doesn't work with function arguments, obviously, since they are declared
in the scope of the function body. But if you defined another compound
statement inside, you could hide the arguments:

void foo(int i)
{ // scope of 'i' begins here
{ // define another, nested, scope
int i = 42; // just another 'i', not the foo's argument
i = 33; // the inner 'i' is changed here
} // end of inner scope
i = 30; // outer 'i' is now changed
}
If
you could tell me how the compiler puts in the binary i could
undersatnd.
I am not sure what you mean here.
Also am i right in assuming that the simple function i wrote cannot be
used twice in the main fn. according to C++ standard.
No, that's not true. It can be used as many times as you wish.
Also are reference arg functions inine by default.


No.

V
Oct 29 '05 #47

P: n/a
Neo
> If
you could tell me how the compiler puts in the binary i could
undersatnd.

I am not sure what you mean here.
-------------------------------------
I mean what are the variables passed to the fn. onto the stack.

Ok lets consider
void swap(int &a,int &b)
{
int t;
t=a;
a=b;
b=t;
}

in the main:
swap(c,d);//1
swap(e,f); //2 this wont give an error

What are the variables passed on to the stack. Are they the addresses
of te vars c,d,e,f??

If yes, then the exact same is done in the case of Void swap(int *a,
int *b).... swap(&c,&d);... so how is the passing thru reference any
different from passing thru pointeres..

If no.... well could someone explain what happens at the machine level
(as in what is exaxtly passed on the stack.. or if the stack isn't
involved at all)

...Or should i post the whole thing at alt.compilers???

Neo

Oct 30 '05 #48

P: n/a
Neo wrote:
If
you could tell me how the compiler puts in the binary i could
undersatnd.
I am not sure what you mean here.
-------------------------------------
I mean what are the variables passed to the fn. onto the stack.

Ok lets consider
void swap(int &a,int &b)
{
int t;
t=a;
a=b;
b=t;
}

in the main:
swap(c,d);//1
swap(e,f); //2 this wont give an error

What are the variables passed on to the stack. Are they the addresses
of te vars c,d,e,f??


Yes.

If yes, then the exact same is done in the case of Void swap(int *a,
int *b).... swap(&c,&d);... so how is the passing thru reference any
different from passing thru pointeres..
The syntax is more convenient. Imagine writing an assignment operator,
or copy constructor with no references

X::X(const X* rhs)
X* X::operator=(const X* rhs)

X a;
X b(a); // doesn't compile
X c = a; // doesn't compile
b = a; // doesn't compile

Also you cannot pass NULL to a swap with references

If no.... well could someone explain what happens at the machine level
(as in what is exaxtly passed on the stack.. or if the stack isn't
involved at all)


At the implementation level references are exactly like pointers. It is
at the C++ language level that there are differences. For instance a
pointer can be assigned to point at something else, but a reference cannot.

john
Oct 30 '05 #49

P: n/a
Neo
Thanks John..
Thats why i called passing by reference as macro.

Neo

Oct 30 '05 #50

51 Replies

This discussion thread is closed

Replies have been disabled for this discussion.