Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #7150 > unrolled thread

References discussion

Back to article view | Back to comp.lang.c

Contents

  References discussion jacob navia <jacob@spamsink.net> - 2011-06-28 18:38 +0200
    Re: References discussion Ian Collins <ian-news@hotmail.com> - 2011-06-29 07:43 +1200
      Re: References discussion jacob navia <jacob@spamsink.net> - 2011-06-28 21:59 +0200
        Re: References discussion Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-02 09:51 +0200

#7150 — References discussion

I would like to thank all people that participated in that discussion.

I have learned interesting points that I did not even consider before
(thanks to Shao for pointing out that references could bypass the
"array decay" problem and pass size information into the called
function)

I discovered quite a few bugs in my implementation, that I am correcting
now.

Ian discovered that there was an incompatibility between my 
implementation and the C++ behavior. I build a constant reference
object without *requiring* that the reference is declared as "const"...

I do not see really the problem but will change this to remain
compatible with C++.

I will post a more formal description of my references implementation
when I have ironed out all the bugs.

Thanks again

jacob

[toc] | [next] | [standalone]

#7161

On 06/29/11 04:38 AM, jacob navia wrote:
> I would like to thank all people that participated in that discussion.
>
> I have learned interesting points that I did not even consider before
> (thanks to Shao for pointing out that references could bypass the
> "array decay" problem and pass size information into the called
> function)
>
> I discovered quite a few bugs in my implementation, that I am correcting
> now.
>
> Ian discovered that there was an incompatibility between my
> implementation and the C++ behavior. I build a constant reference
> object without *requiring* that the reference is declared as "const"...
>
> I do not see really the problem but will change this to remain
> compatible with C++.

 From Tim Rentsch's post, something like

void foo( int& x )
{
   ++x;
}

int n = 42;

foo( n );

foo( n++ );  // What is the resulting value of n?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7162

Le 28/06/11 21:43, Ian Collins a écrit :
>
>  From Tim Rentsch's post, something like
>
> void foo( int& x )
> {
> ++x;
> }
>
> int n = 42;
>
> foo( n );
>
> foo( n++ ); // What is the resulting value of n?
>

I do not know. It doesn't compile since it is the same as:
int fn(void)
{
     int n=42;
     int *pn = &n++;
}

That doesn't compile either.

I just do not see what is the problem but very probably it is my fault.

[toc] | [prev] | [next] | [standalone]

#7430

Am 28.06.2011 21:59, schrieb jacob navia:
> Le 28/06/11 21:43, Ian Collins a écrit :
>> foo( n++ ); // What is the resulting value of n?
> I just do not see what is the problem but very probably it is my fault.

The problem is that you can't get by any means close to the behavior
of C++. In C++ many of the standard operators return lvalues where
they return rvalues in C.

For the example, instead of postfix ++ use

foo(++n);

This would compile in C++ (for foo taking a reference) and give the
user about what (s)he expects, since (in C++) in contrast to n++
(which returns an rvalue) ++n evaluates to an lvalue that represents
the same object as n.

A simple rule that just implicitly creates lvalues from rvalues when
passed to a function with references would have surprising effects
for the programmer.

Introducing references into C without discussing the types of all
standard operators (in terms of rvalue or lvalue) and without
discussing if functions would be allowed to return lvalues makes not
much sense to me.

Jens

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web