reference type for C

Discussion in 'C Programming' started by roland.arthaud@gmail.com, May 16, 2013.

  1. Guest

    I like the reference type that has been introduced with C++
    I wondered why isn't that feature retrofitted in C.
    Is there something hindering it?

    thx - roar -
    , May 16, 2013
    #1
    1. Advertising

  2. On Thursday, May 16, 2013 3:08:43 PM UTC+1, wrote:
    > I like the reference type that has been introduced with C++
    >
    > I wondered why isn't that feature retrofitted in C.
    >
    > Is there something hindering it?
    >
    > thx - roar -
    >

    References are really just pointers in disguise, though in C++ they have the
    feature that they can never be null.
    In C, it's better to keep everything explicit. That's the design principle
    of the language, to expose as much as possible of the underlying machine
    operations to the programmer. So if you're passed an address, you can
    examine its bits to see which area of memory it came from, for example.

    --
    Visit Malcolm's website
    http://www.malcolmmclean.site11.com/www
    Malcolm McLean, May 16, 2013
    #2
    1. Advertising

  3. James Kuyper Guest

    On 05/16/2013 10:08 AM, wrote:
    > I like the reference type that has been introduced with C++
    > I wondered why isn't that feature retrofitted in C.
    > Is there something hindering it?


    Reference types in C++ don't allow you do anything that can't also be
    done, with slightly different syntax, using pointers. Syntactic
    convenience is often sufficient to justify a feature, such as += or ++;
    but in this case the increased convenience is relatively minor. I'm not
    saying that this can't be done - but there's just not a lot of demand
    for it. There is a minor inconvenience: because references and pointers
    provide 2 different ways of doing the same thing, wherever the C++
    standard says something about pointers, it often has to also say
    something similar about references. Adding references to C would require
    adding similar text in a great many places in the C standard.
    James Kuyper, May 16, 2013
    #3
  4. ralph Guest

    On Thu, 16 May 2013 07:08:43 -0700 (PDT),
    wrote:

    >I like the reference type that has been introduced with C++
    >I wondered why isn't that feature retrofitted in C.
    >Is there something hindering it?
    >


    Object-oriented programming (and design/analysis) has a concept of
    Identity. A Reference in OO is simply a thingy containing enough
    information to uniquely refer to, allow access to, a specific object.

    C++ is an OOPL, essentially designed to facilitate coding OO
    solutions, thus it is no surprise that C++ provides a 'reference'
    thingy.

    While EVERYBODY and his friends and family *knows* a C++ reference is
    a 'pointer', after all they are implemented as 'pointers' (albeit with
    a few restrictions) - the fact is the C++ standard goes to great
    lengths to NOT define how a reference is implemented.

    As C has no need to introduce another higher-level concept it boils
    down to what Mr. Kuyper pointed out - "syntactic
    convenience".

    -ralph
    ralph, May 16, 2013
    #4
  5. Martin Shobe Guest

    On 5/16/2013 9:52 AM, James Kuyper wrote:
    > On 05/16/2013 10:08 AM, wrote:
    >> I like the reference type that has been introduced with C++
    >> I wondered why isn't that feature retrofitted in C.
    >> Is there something hindering it?

    >
    > Reference types in C++ don't allow you do anything that can't also be
    > done, with slightly different syntax, using pointers.


    While this isn't the place to go too deep into C++'s bag of tricks.
    there are things that you can do with references that you can't do with
    pointers. For example, you can extend the lifetime of a temporary.

    Martin Shobe
    Martin Shobe, May 16, 2013
    #5
  6. BGB Guest

    (actually wrote earlier today, but I had accidentally sent as an email...).


    On 5/16/2013 9:52 AM, James Kuyper wrote:
    > On 05/16/2013 10:08 AM, wrote:
    >> I like the reference type that has been introduced with C++
    >> I wondered why isn't that feature retrofitted in C.
    >> Is there something hindering it?

    >
    > Reference types in C++ don't allow you do anything that can't also be
    > done, with slightly different syntax, using pointers. Syntactic
    > convenience is often sufficient to justify a feature, such as += or ++;
    > but in this case the increased convenience is relatively minor. I'm not
    > saying that this can't be done - but there's just not a lot of demand
    > for it. There is a minor inconvenience: because references and pointers
    > provide 2 different ways of doing the same thing, wherever the C++
    > standard says something about pointers, it often has to also say
    > something similar about references. Adding references to C would require
    > adding similar text in a great many places in the C standard.
    >


    albeit there is a possible lazier solution:
    a reference is (formally) just a slight syntactic sugar over a pointer.
    (IOW: just define it as being a pointer... possibly just leaving a NULL
    reference as undefined behavior).

    maybe the behavior is: a variable declared as a reference will always
    behave as-if it was being operated on with a the '*' operator.


    possibly a keyword could be added both for declarations, and partly to
    take the role of the '&' operator in these cases ('_Ref' in an
    expression canceling out its use in a declaration, giving access to the
    raw pointer).


    say, if added as a keyword:
    int foo(_Ref int r) //internally 'int *r'
    {
    r=3; //declaration suppresses need for explicit "*r"
    }

    int i;
    foo(&i); //creates pointer/reference to int
    foo(_Ref i); //would do basically the same thing as &i here

    int bar(_Ref int r)
    {
    int *pr;
    pr=_Ref r; //maybe less conceptually ambiguous than '&r'.
    ...
    _Ref r=pr; //maybe allow assigning references
    }

    optionally, the compiler could add sanity checks as-needed to try to
    avoid NULL references.


    alternatively, it could be possible to just mimic the C++ behavior.
    BGB, May 17, 2013
    #6
  7. Ian Collins Guest

    James Kuyper wrote:
    > On 05/16/2013 10:08 AM, wrote:
    >> I like the reference type that has been introduced with C++
    >> I wondered why isn't that feature retrofitted in C.
    >> Is there something hindering it?

    >
    > Reference types in C++ don't allow you do anything that can't also be
    > done, with slightly different syntax, using pointers.


    It's probably fairer to say reference types in C wouldn't allow you do
    anything that can't also be done, with slightly different syntax, using
    pointers.

    In C++, they enable rather a lot.

    --
    Ian Collins
    Ian Collins, May 17, 2013
    #7
  8. Guest

    Thanks for your contributions so far.

    I'd like to remind though that the question was : is there anything in the C standard so far that would hinder implementation of this feature.

    I don't want to duplicate here all the discussions one can see on the web re. the feature in C++ (esp. ref being pointers in disguise in the implementation)

    (and if you wonder why I would like to have it in C : reference cannot be made to refer to another var after it is defined / I know you can go throughhoops to make this statement false, and *yes* I like the syntactic sugar that reference can make code more "unobstructed" for uses of const pointers)-- but again, please no rant about my own tastes.
    , May 17, 2013
    #8
  9. gwowen Guest

    On May 17, 4:33 am, BGB <> wrote:
    > albeit there is a possible lazier solution:
    > a reference is (formally) just a slight syntactic sugar over a pointer.
    > (IOW: just define it as being a pointer... possibly just leaving a NULL
    > reference as undefined behavior).


    In non-pathological usage, a C++ reference cannot be null. That's
    caught at compile time, which is a *massive* win over introducing
    another bit of undefined behaviour.

    A C++ reference-to-T cannot be mistaken for the the start of any array
    of T, or an iterator into a collection of T's, so you can't do pointer
    arithmetic on them.

    NULL pointer dereferences and incorrect pointer arithmetic are two of
    the most common causes of bugs in C/C++ programs.

    To say "you can't do anything with a reference that you can't do with
    a pointer" is to miss the point. The things that you *can't* do to a
    reference are a feature (but can do to a pointer).

    In C, a pointer is one-or-more of "a reference to an object", "an
    iterator into an array of objects", "the address of some memory", "a
    reference to nothing".

    In C++, a reference is "a reference to an object".

    I don't consider that restriction to be "slight syntactic sugar". It
    actually allows the compiler to do type checking so that the function
    caller's and the function writer's intentions are the same.

    Of course, they'll never be introduced to C, because C of the
    minimalist nature of C. Introducing new types similar to old types -
    regardless of the type safety advantages - will not happen.
    gwowen, May 17, 2013
    #9
  10. James Kuyper Guest

    On 05/17/2013 06:38 AM, gwowen wrote:
    ....
    > A C++ reference-to-T cannot be mistaken for the the start of any array
    > of T, or an iterator into a collection of T's, so you can't do pointer
    > arithmetic on them.


    Given
    int original;
    int &reference = original;
    int *pointer = &original;

    then reference corresponds to *pointer, and &reference corresponds to
    pointer. You can do pointer arithmetic on &reference.
    --
    James Kuyper
    James Kuyper, May 17, 2013
    #10
  11. Ian Collins Guest

    James Kuyper wrote:
    > On 05/17/2013 06:38 AM, gwowen wrote:
    > ....
    >> A C++ reference-to-T cannot be mistaken for the the start of any array
    >> of T, or an iterator into a collection of T's, so you can't do pointer
    >> arithmetic on them.

    >
    > Given
    > int original;
    > int &reference = original;
    > int *pointer = &original;
    >
    > then reference corresponds to *pointer, and &reference corresponds to
    > pointer. You can do pointer arithmetic on &reference.


    You can do pointer arithmetic on &original, so what's your point?

    --
    Ian Collins
    Ian Collins, May 17, 2013
    #11
  12. James Kuyper Guest

    On 05/17/2013 07:42 AM, Ian Collins wrote:
    > James Kuyper wrote:
    >> On 05/17/2013 06:38 AM, gwowen wrote:
    >> ....
    >>> A C++ reference-to-T cannot be mistaken for the the start of any array
    >>> of T, or an iterator into a collection of T's, so you can't do pointer
    >>> arithmetic on them.

    >>
    >> Given
    >> int original;
    >> int &reference = original;
    >> int *pointer = &original;
    >>
    >> then reference corresponds to *pointer, and &reference corresponds to
    >> pointer. You can do pointer arithmetic on &reference.

    >
    > You can do pointer arithmetic on &original, so what's your point?


    That the difference between references and pointers is primarily
    syntactic, and that the inability to do pointer arithmetic on references
    does NOT constitute an exception to that fact - a single operator is the
    only syntactic difference between a reference and something that you can
    indeed to pointer arithmetic on. Properly, I should have used

    int * const pointer = & original;

    to make the analogy closer.
    --
    James Kuyper
    James Kuyper, May 17, 2013
    #12
  13. Guest

    For me, gowen has been the best advocate for why reference is a very good thing to have in C.

    I would also say that using a reference has a semantic value (the alias role) for the reader of the code, which (as gowen said) is lost if one used the army-knife-pointer - in that sense it helps legibility.

    But what I am hearing is that it will never make it, either because people might not see the value of it, or because you can do without it or even because updating the standard would be too difficulte -- sob...
    , May 17, 2013
    #13
  14. Ed Prochak Guest

    On Thursday, May 16, 2013 3:24:14 PM UTC-4, Martin Shobe wrote:

    >
    > While this isn't the place to go too deep into C++'s bag of tricks.
    > there are things that you can do with references that you can't do with
    > pointers. For example, you can extend the lifetime of a temporary.
    >
    >
    > Martin Shobe


    I don't get it. In C I can control the lifetime of everything. I don't have a garbage collector taking things away behind my back. So I don't see this as an advantage of references.

    ed
    Ed Prochak, May 17, 2013
    #14
  15. On Friday, May 17, 2013 11:38:56 AM UTC+1, gwowen wrote:
    > On May 17, 4:33 am, BGB <> wrote:
    >
    >
    > In non-pathological usage, a C++ reference cannot be null. That's
    > caught at compile time, which is a *massive* win over introducing
    > another bit of undefined behaviour.
    >
    >

    Most aircraft crashes are caused by controlled flight into terrain.
    Most errors can be corrected by automatic systems. But not the pilot
    explicitly telling the aircraft to fly into a mountain, because, from
    the aircraft's point of view, everything is correct an normal.

    Undefined behaviour is bad, but it's only "undefined" from the point of view
    of the c standard. Null pointer defererences can and usually are defined
    to stop the program with an error message. Depending on the situation,
    that's usually a lot better than wrong results.
    >
    >
    > NULL pointer dereferences and incorrect pointer arithmetic are two of
    > the most common causes of bugs in C/C++ programs.
    >

    Pointer arithmetic is seldom necessary and usually indicates old-fashioned
    programming. Pointers usually point either to structures or arrays, and
    don't need modifying.
    Null pointer dereferences are a bug, but they aren't usually the root cause
    of a bug. If a pointer that should be valid is in fact null, then usually
    that's because there's a logic error somewhere upstream. So you have to fix
    the bug at the place the pointer became null, not where it was dereferenced..
    References might help slightly, but you can't overcome logic errors with
    syntactical constructs. The flip of references can't be null is that you
    can't use null as a sentinel. If you use a special "empty" sentinel value,
    you've got far more potential for logic errors than if you use null pointers.
    Malcolm McLean, May 17, 2013
    #15
  16. Ike Naar Guest

    On 2013-05-17, James Kuyper <> wrote:
    > On 05/17/2013 06:38 AM, gwowen wrote:
    > ...
    >> A C++ reference-to-T cannot be mistaken for the the start of any array
    >> of T, or an iterator into a collection of T's, so you can't do pointer
    >> arithmetic on them.

    >
    > Given
    > int original;
    > int &reference = original;
    > int *pointer = &original;
    >
    > then reference corresponds to *pointer, and &reference corresponds to
    > pointer. You can do pointer arithmetic on &reference.


    Alternatively, one can view a reference not as some kind of pointer,
    but as another name for a given object.
    Consider the two code fragments:

    int original;
    int &reference = original;
    // point A

    and

    int reference;
    int &original = reference;
    // point A

    The situation at point A in the first fragment is indistinguishable
    from the situation at point A in the second fragment.
    At both locations, 'original' and 'reference' have type 'int' and refer to
    a common object. At point A, it's impossible to tell which one of 'original'
    or 'reference' is the original object, and which one is the reference.

    Isn't it a bit odd, then, to regard 'reference' as some kind of pointer
    in the first code fragment, but not in the second fragment?
    Ike Naar, May 17, 2013
    #16
  17. Paul N Guest

    On May 17, 9:58 am, wrote:
    > Thanks for your contributions so far.
    >
    > I'd like to remind though that the question was : is there anything in the C standard so far that would hinder implementation of this feature.
    >
    > I don't want to duplicate here all the discussions one can see on the webre. the feature in C++ (esp. ref being pointers in disguise in the implementation)
    >
    > (and if you wonder why I would like to have it in C : reference cannot bemade to refer to another var after it is defined / I know you can go through hoops to make this statement false, and *yes* I like the syntactic sugarthat reference can make code more "unobstructed" for uses of const pointers) -- but again, please no rant about my own tastes.


    I don't think there's anything in the standard that would hinder
    having references. In particular, if a function is called before a
    prototype has been seen, and so the compiler rashly treats it as a
    call-by-value rather than a call-by-reference, it will complain when
    it does see the prototype.

    I think it's more a matter of philosophy. In C's predecessor BCPL,
    everything was the same type, so it could be arranged that calling a
    function simply involved bunging the arguments on the stack and the
    function could simply reel them off. (Or, indeed, use the stack
    locations as where to store the parameters.) C does of course have
    types, but I think it would be considered a leap too far for a
    function call that looks like it is referring to a variable to
    actually be pushing a disguised pointer instead. If you want a laguage
    with different trade-offs, then C++ is there and waiting; but if you
    don't, then you don't.

    [PS I hope the above comes out OK as regarding line lnegths and
    quoting - I'm using the old Google groups which seemed to do this
    right, but this time it looks suspicious.]
    Paul N, May 17, 2013
    #17
  18. Noob Guest

    gwowen wrote:

    > In non-pathological usage, a C++ reference cannot be null. That's
    > caught at compile time, which is a *massive* win over introducing
    > another bit of undefined behaviour.


    I had thought "restrict" might help:

    $ cat ref.c
    int foo(int *restrict const p) { return *p; }
    int bar(void) { return foo(0); }
    $ gcc -std=c99 -pedantic-errors -Wall -Wextra -Os -S ref.c
    /* NO WARNING */

    I expected a warning.
    (AFAIU, restrict pointers must be valid, foo(0) is not allowed.)
    Perhaps I should test with something more recent than 4.6.3

    Regards.
    Noob, May 17, 2013
    #18
  19. SG Guest

    On May 16, 4:08 pm, wrote:
    > I like the reference type that has been introduced with C++


    What do you like about it?
    What would it enable in C that was not possible before?

    It's like Ian said: There are a lot of situations where references
    help a lot in C++. I don't see these kinds of situations in C.

    > I wondered why isn't that feature retrofitted in C.
    > Is there something hindering it?


    I guess there has to be enough bang for the buck. Is there?

    Cheers!
    SG
    SG, May 17, 2013
    #19
  20. Martin Shobe Guest

    On 5/17/2013 7:37 AM, Ed Prochak wrote:
    > On Thursday, May 16, 2013 3:24:14 PM UTC-4, Martin Shobe wrote:
    >
    >>
    >> While this isn't the place to go too deep into C++'s bag of tricks.
    >> there are things that you can do with references that you can't do with
    >> pointers. For example, you can extend the lifetime of a temporary.
    >>
    >>
    >> Martin Shobe

    >
    > I don't get it. In C I can control the lifetime of everything. I don't have a garbage collector taking things away behind my back. So I don't see this as an advantage of references.
    >
    > ed
    >


    In C++, some expressions result in the creation of temporary objects.
    Usually these objects are destroyed when the program has finished
    evaluating the expression[1] they were created in. If a temporary object
    is bound to a reference, then (with a few exceptions) the object isn't
    destroyed until the reference is. Garbage collection (which C++ isn't
    required to have) has nothing to do with it.

    Martin Shobe

    [1] This expression is the one referred to in the C++ standard as the
    full-expression.
    Martin Shobe, May 17, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. heyo
    Replies:
    3
    Views:
    881
    Dan Pop
    Apr 1, 2004
  2. pete
    Replies:
    4
    Views:
    779
    Dan Pop
    Apr 2, 2004
  3. Yevgen Muntyan

    #define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))

    Yevgen Muntyan, Feb 9, 2007, in forum: C Programming
    Replies:
    10
    Views:
    878
    Yevgen Muntyan
    Feb 13, 2007
  4. bhadorn
    Replies:
    0
    Views:
    757
    bhadorn
    Oct 30, 2009
  5. Sam Sungshik Kong

    Value type or reference type

    Sam Sungshik Kong, Jun 2, 2004, in forum: Ruby
    Replies:
    1
    Views:
    94
    Robert Klemme
    Jun 2, 2004
Loading...

Share This Page