References and pointers

Discussion in 'C Programming' started by Simon Saize, Dec 31, 2007.

  1. Simon Saize

    Simon Saize Guest

    Hi -

    What's the point of having references (&)? Why don't we just use
    pointers (*)?

    Thanks.
    Simon Saize, Dec 31, 2007
    #1
    1. Advertising

  2. Simon Saize said:

    > Hi -
    >
    > What's the point of having references (&)?


    In C, they don't exist. I suggest you remove comp.lang.c from the
    crosspost.

    > Why don't we just use pointers (*)?


    We do.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Dec 31, 2007
    #2
    1. Advertising

  3. Simon Saize

    Simon Saize Guest

    I believe they exist in some versions of C, e.g. lcc-win which also
    supports Operator Overloading.

    On 31/12/2007 18:43, Daniel T. wrote:
    > Simon Saize <> wrote:
    >
    >
    >>What's the point of having references (&)? Why don't we just use
    >>pointers (*)?

    >
    >
    > References were added to the language to facilitate operator overloading
    > in C++. Do they even exist in C?
    Simon Saize, Dec 31, 2007
    #3
  4. Simon Saize wrote:
    > Hi -
    >
    > What's the point of having references (&)? Why don't we just use
    > pointers (*)?


    There really was no need to post this to comp.lang.c. In C we have no
    "references", so the question is pointless. If your aim is to actually
    learn about the rationale for C++ using these (and there is one,
    although it is because of other features of C++ that we in comp.lang.c
    do without quite happily), the folks in comp.lang.c++ should be able to
    help. However, your crossposting suggests that your aim is to start
    another pointless language war; if so, I hope no one rises to the bait.

    Follow-ups restricted to comp.lang.c++, where the question actually
    makes sense.
    Martin Ambuhl, Dec 31, 2007
    #4
  5. On 31 ÄÅË, 21:31, Simon Saize <> wrote:
    > Hi -
    >
    > What's the point of having references (&)? Why don't we just use
    > pointers (*)?
    >
    > Thanks.


    The sense of using references in ó++ instead of pointers is to avoid
    annoying checking pointers for NULL

    For example if you have a function that accepts reference as a
    paramater you do not have to check the reference
    for NULL ( 0 ) before using it because references cannot be NULL but
    if you have a pointer you should always check it
    for NULL before you invoke member functions otherwise you might get
    access violation error.
    Alexey Stepanyan, Dec 31, 2007
    #5
  6. Simon Saize

    jacob navia Guest

    Simon Saize wrote:
    > I believe they exist in some versions of C, e.g. lcc-win which also
    > supports Operator Overloading.
    >


    Yes, lcc-win supports references and some other good ideas from C++.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Dec 31, 2007
    #6
  7. Simon Saize

    cr88192 Guest

    "Alexey Stepanyan" <> wrote in message
    news:...
    On 31 ???, 21:31, Simon Saize <> wrote:
    > Hi -
    >
    > What's the point of having references (&)? Why don't we just use
    > pointers (*)?
    >
    > Thanks.


    <
    The sense of using references in ?++ instead of pointers is to avoid
    annoying checking pointers for NULL

    For example if you have a function that accepts reference as a
    paramater you do not have to check the reference
    for NULL ( 0 ) before using it because references cannot be NULL but
    if you have a pointer you should always check it
    for NULL before you invoke member functions otherwise you might get
    access violation error.
    >


    as noted by others, references are non-standard in C (as such, they are only
    really valid in C++, and it is good not to confuse C and C++, as they are
    different languages).


    however, it is also nicer to be able to type:
    x=3;
    than:
    *rx=3;

    this can actually matter some with more non-trivial argument types (char as
    'char *'), where the common practice becomes to extract the value from the
    pointer, work on it, and store it back before return (this is a very common
    pattern in things like parsers, ...).

    reason:
    int foo(char **rs)
    {
    ....
    }

    rs++; //wont do what you want
    *rs++; //seems like it would work, but it does not (does something
    different)
    (*rs)++; //is problematic IME.

    so, afaik, about the only really safe option here is:
    *rs=*rs+1;

    so, common is to have to be like:
    int foo(char **rs)
    {
    char *s;
    ....
    s=*rs;
    ....
    *rs=s;
    return(i);
    }


    so, references can have some uses...
    cr88192, Dec 31, 2007
    #7
  8. Simon Saize

    CBFalconer Guest

    jacob navia wrote:
    > Simon Saize wrote:
    >
    >> I believe they exist in some versions of C, e.g. lcc-win which
    >> also supports Operator Overloading.

    >
    > Yes, lcc-win supports references and some other good ideas from
    > C++.


    However lcc-win is not a C compiler. No compiler that supports
    references is a C compiler.

    Follow-up set to c.l.c. c.l.c++ crossposts are idiotic.

    --
    Merry Christmas, Happy Hanukah, Happy New Year
    Joyeux Noel, Bonne Annee, Frohe Weihnachten
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Jan 1, 2008
    #8
  9. Simon Saize

    CBFalconer Guest

    cr88192 wrote:
    > Simon Saize <> wrote:
    >
    >> What's the point of having references (&)? Why don't we just use
    >> pointers (*)?

    >
    > The sense of using references in ?++ instead of pointers is to
    > avoid annoying checking pointers for NULL


    There are NO references in the C language. None.

    Follow-ups set to remove the idiotic C and C++ cross-post.

    --
    Merry Christmas, Happy Hanukah, Happy New Year
    Joyeux Noel, Bonne Annee, Frohe Weihnachten
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>


    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Jan 1, 2008
    #9
  10. CBFalconer said:

    > jacob navia wrote:
    >> Simon Saize wrote:
    >>
    >>> I believe they exist in some versions of C, e.g. lcc-win which
    >>> also supports Operator Overloading.

    >>
    >> Yes, lcc-win supports references and some other good ideas from
    >> C++.

    >
    > However lcc-win is not a C compiler. No compiler that supports
    > references is a C compiler.


    Wrong. The Standard does not forbid compilers from offering extensions, as
    long as (a) required diagnostic messages are still produced and (b)
    strictly conforming programs are not affected. If lcc-win32, when invoked
    in conforming mode, diagnoses C++ reference syntax as being erroneous,
    then that's all it has to do to remain conforming.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jan 1, 2008
    #10
  11. CBFalconer said:

    <snip>

    > There are NO references in the C language. None.


    Actually, there are. For example, see Translation Phase 8: "All external
    object and function references are resolved. Library components are linked
    to satisfy external references to functions and objects not defined in the
    current translation."

    It's just that "reference" means something different in C++ than it does in
    C.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jan 1, 2008
    #11
  12. Simon Saize

    CBFalconer Guest

    Richard Heathfield wrote:
    > CBFalconer said:
    >> jacob navia wrote:
    >>> Simon Saize wrote:
    >>>
    >>>> I believe they exist in some versions of C, e.g. lcc-win which
    >>>> also supports Operator Overloading.
    >>>
    >>> Yes, lcc-win supports references and some other good ideas from
    >>> C++.

    >>
    >> However lcc-win is not a C compiler. No compiler that supports
    >> references is a C compiler.

    >
    > Wrong. The Standard does not forbid compilers from offering
    > extensions, as long as (a) required diagnostic messages are still
    > produced and (b) strictly conforming programs are not affected.
    > If lcc-win32, when invoked in conforming mode, diagnoses C++
    > reference syntax as being erroneous, then that's all it has to do
    > to remain conforming.


    I think a simple example will refute this. If I write:

    foo(&thing);

    I expect to call foo, passing the address of thing, and I expect
    that the code for foo will access that address by *bar (where bar
    is the parameter name in foo). If we have C++ references, we will
    omit the * (and label the parameter differently). I.E. we now need
    two different prototypes:

    void foo(T *bar) and void foo(T &bar)

    which MUST be called differently and used differently to access
    thing:

    *bar and bar

    Since I know you have a family, what the devil are you doing
    fooling with a computer in the first two hours of 2008?

    --
    Merry Christmas, Happy Hanukah, Happy New Year
    Joyeux Noel, Bonne Annee, Frohe Weihnachten
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Jan 1, 2008
    #12
  13. CBFalconer said:

    > Richard Heathfield wrote:
    >> CBFalconer said:
    >>> jacob navia wrote:
    >>>> Simon Saize wrote:
    >>>>
    >>>>> I believe they exist in some versions of C, e.g. lcc-win which
    >>>>> also supports Operator Overloading.
    >>>>
    >>>> Yes, lcc-win supports references and some other good ideas from
    >>>> C++.
    >>>
    >>> However lcc-win is not a C compiler. No compiler that supports
    >>> references is a C compiler.

    >>
    >> Wrong. The Standard does not forbid compilers from offering
    >> extensions, as long as (a) required diagnostic messages are still
    >> produced and (b) strictly conforming programs are not affected.
    >> If lcc-win32, when invoked in conforming mode, diagnoses C++
    >> reference syntax as being erroneous, then that's all it has to do
    >> to remain conforming.

    >
    > I think a simple example will refute this. If I write:
    >
    > foo(&thing);
    >
    > I expect to call foo, passing the address of thing, and I expect
    > that the code for foo will access that address by *bar (where bar
    > is the parameter name in foo). If we have C++ references, we will
    > omit the * (and label the parameter differently). I.E. we now need
    > two different prototypes:
    >
    > void foo(T *bar) and void foo(T &bar)
    >
    > which MUST be called differently and used differently to access
    > thing:
    >
    > *bar and bar


    Yes, that's about right - and yes, that would constitute a perfectly
    legitimate extension. The compiler would be required to issue a diagnostic
    message (typically this reads something like "non-standard extension
    used... yadayadayada"), and of course a strictly conforming program would
    still have to work properly. I don't see anything in your reply that
    demonstrates a refutation of this extension being legitimate.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jan 1, 2008
    #13
  14. Simon Saize

    James Kanze Guest

    On Dec 31 2007, 8:07 pm, Simon Saize <> wrote:
    > I believe they exist in some versions of C, e.g. lcc-win which
    > also supports Operator Overloading.


    If the language supports operator overloading and references,
    it's not C. If a compiler supports them, then it is not a C
    compiler. (And presumably, discussion of it isn't relevant in
    comp.lang.c.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jan 1, 2008
    #14
  15. Simon Saize

    jacob navia Guest

    James Kanze wrote:
    > On Dec 31 2007, 8:07 pm, Simon Saize <> wrote:
    >> I believe they exist in some versions of C, e.g. lcc-win which
    >> also supports Operator Overloading.

    >
    > If the language supports operator overloading and references,
    > it's not C. If a compiler supports them, then it is not a C
    > compiler. (And presumably, discussion of it isn't relevant in
    > comp.lang.c.)
    >


    As you may know, the C standards does NOT forbid any extensions.
    The extensions in lcc-win are done according to the specifications
    for extensions: no new keywords.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Jan 1, 2008
    #15
  16. Simon Saize

    cr88192 Guest

    "CBFalconer" <> wrote in message
    news:...
    > cr88192 wrote:
    >> Simon Saize <> wrote:
    >>
    >>> What's the point of having references (&)? Why don't we just use
    >>> pointers (*)?

    >>
    >> The sense of using references in ?++ instead of pointers is to
    >> avoid annoying checking pointers for NULL

    >
    > There are NO references in the C language. None.
    >
    > Follow-ups set to remove the idiotic C and C++ cross-post.
    >


    please try to make it more clear who you are responding to...
    this comes off seeming like I had written the text you are responding to,
    but I did not.


    now, it can be noted that they don't exist, as a standard feature, but there
    are a few implementations that have them as extensions. so, if one defines C
    as "only that which is found in the standard", your statement is correct. if
    we instead define "C" in terms of existing implementation and coding
    practice, then it is only true for the majority of implementations and
    coders.


    it is much the same as if, for example, someone writes: "I brang all them
    beers in back my truck" (or, alternatively "I be rollin' in da hood with mah
    gat and fatty bling").

    does these kind of constructions exist in English:
    apparently, they do, and there are many people who speak this way.
    to say that constructions like this don't exist, or that they are as such no
    longer speaking English, is incorrect.

    now, if we ask if these constructions are valid (as per normative rules, or
    by some specific definition as to what constitutes the language), then we
    can validly argue that they are not.

    or, we can be even more fussy:
    are R's following a vowel to be pronounced as a full R sound, a soft R, or
    to be shifted to A, AU, or a Schwa?
    what about the 'ing' suffix? N followed by an asperated G, a softened
    composite sound, or shifted to a plain N sound?
    ....


    > --
    > Merry Christmas, Happy Hanukah, Happy New Year
    > Joyeux Noel, Bonne Annee, Frohe Weihnachten
    > Chuck F (cbfalconer at maineline dot net)
    > <http://cbfalconer.home.att.net>
    >
    >
    > --
    > Posted via a free Usenet account from http://www.teranews.com
    >
    cr88192, Jan 1, 2008
    #16
  17. jacob navia said:

    > James Kanze wrote:
    >> On Dec 31 2007, 8:07 pm, Simon Saize <> wrote:
    >>> I believe they exist in some versions of C, e.g. lcc-win which
    >>> also supports Operator Overloading.

    >>
    >> If the language supports operator overloading and references,
    >> it's not C. If a compiler supports them, then it is not a C
    >> compiler. (And presumably, discussion of it isn't relevant in
    >> comp.lang.c.)
    >>

    >
    > As you may know, the C standards does NOT forbid any extensions.


    Correct. Indeed, it explicitly allows them. As long as the implementation
    diagnoses extensions that constitute syntax errors and constraint
    violations, and as long as the extension doesn't break strictly conforming
    programs, it can still provide those extensions and yet qualify as a C
    compiler.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jan 1, 2008
    #17
  18. Simon Saize

    James Kanze Guest

    On Jan 1, 2:06 pm, jacob navia <> wrote:
    > James Kanze wrote:
    > > On Dec 31 2007, 8:07 pm, Simon Saize <> wrote:
    > >> I believe they exist in some versions of C, e.g. lcc-win which
    > >> also supports Operator Overloading.


    > > If the language supports operator overloading and references,
    > > it's not C. If a compiler supports them, then it is not a C
    > > compiler. (And presumably, discussion of it isn't relevant in
    > > comp.lang.c.)


    > As you may know, the C standards does NOT forbid any extensions.
    > The extensions in lcc-win are done according to the specifications
    > for extensions: no new keywords.


    If they result in syntax that wouldn't be legal C, a C compiler
    is required to output a diagnostic. And regardless, they aren't
    C, and certainly aren't relevant to comp.lang.c (and even less
    comp.lang.c++).

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jan 1, 2008
    #18
  19. Simon Saize

    jacob navia Guest

    James Kanze wrote:
    > On Jan 1, 2:06 pm, jacob navia <> wrote:
    >> James Kanze wrote:
    >>> On Dec 31 2007, 8:07 pm, Simon Saize <> wrote:
    >>>> I believe they exist in some versions of C, e.g. lcc-win which
    >>>> also supports Operator Overloading.

    >
    >>> If the language supports operator overloading and references,
    >>> it's not C. If a compiler supports them, then it is not a C
    >>> compiler. (And presumably, discussion of it isn't relevant in
    >>> comp.lang.c.)

    >
    >> As you may know, the C standards does NOT forbid any extensions.
    >> The extensions in lcc-win are done according to the specifications
    >> for extensions: no new keywords.

    >
    > If they result in syntax that wouldn't be legal C, a C compiler
    > is required to output a diagnostic. And regardless, they aren't
    > C, and certainly aren't relevant to comp.lang.c (and even less
    > comp.lang.c++).


    OK. That's your opinion.

    I disagree.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Jan 1, 2008
    #19
  20. Simon Saize

    CBFalconer Guest

    Richard Heathfield wrote:
    > CBFalconer said:
    >> Richard Heathfield wrote:
    >>> CBFalconer said:
    >>>> jacob navia wrote:
    >>>>> Simon Saize wrote:
    >>>>>
    >>>>>> I believe they exist in some versions of C, e.g. lcc-win which
    >>>>>> also supports Operator Overloading.
    >>>>>
    >>>>> Yes, lcc-win supports references and some other good ideas from
    >>>>> C++.
    >>>>
    >>>> However lcc-win is not a C compiler. No compiler that supports
    >>>> references is a C compiler.
    >>>
    >>> Wrong. The Standard does not forbid compilers from offering
    >>> extensions, as long as (a) required diagnostic messages are still
    >>> produced and (b) strictly conforming programs are not affected.
    >>> If lcc-win32, when invoked in conforming mode, diagnoses C++
    >>> reference syntax as being erroneous, then that's all it has to do
    >>> to remain conforming.

    >>
    >> I think a simple example will refute this. If I write:
    >>
    >> foo(&thing);
    >>
    >> I expect to call foo, passing the address of thing, and I expect
    >> that the code for foo will access that address by *bar (where bar
    >> is the parameter name in foo). If we have C++ references, we will
    >> omit the * (and label the parameter differently). I.E. we now need
    >> two different prototypes:
    >>
    >> void foo(T *bar) and void foo(T &bar)
    >>
    >> which MUST be called differently and used differently to access
    >> thing:
    >>
    >> *bar and bar

    >
    > Yes, that's about right - and yes, that would constitute a
    > perfectly legitimate extension. The compiler would be required to
    > issue a diagnostic message (typically this reads something like
    > "non-standard extension used... yadayadayada"), and of course a
    > strictly conforming program would still have to work properly. I
    > don't see anything in your reply that demonstrates a refutation
    > of this extension being legitimate.


    The point is that the only usage difference is in the calling
    module. The actual receiving code is exactly the same (although it
    may not be written identically). So now we need two different
    prototypes for the same function. Look at the assembly code for
    the destination module, and at the disassembly of the same code.

    --
    Merry Christmas, Happy Hanukah, Happy New Year
    Joyeux Noel, Bonne Annee, Frohe Weihnachten
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Jan 1, 2008
    #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. Roger Leigh
    Replies:
    8
    Views:
    436
    Karl Heinz Buchegger
    Nov 17, 2003
  2. Replies:
    3
    Views:
    448
    Victor Bazarov
    Nov 10, 2004
  3. DanielEKFA
    Replies:
    8
    Views:
    606
    DanielEKFA
    May 16, 2005
  4. Replies:
    8
    Views:
    711
    Bruno Desthuilliers
    Dec 12, 2006
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    672
Loading...

Share This Page