References and pointers

Discussion in 'C++' 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

    Daniel T. Guest

    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?
     
    Daniel T., Dec 31, 2007
    #3
  4. 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
    #4
  5. 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
    #5
  6. 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
    #6
  7. 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
    #7
  8. Simon Saize

    Howard Guest

    > >
    > > 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


    > 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.


    I have to disagree about the need to always check pointers for NULL. A
    program should only need to check for NULL pointers if the design of the
    program intentionally allows and expects pointers to be NULL under certain
    conditions. If there is a requirement (by the calling code) that the
    pointer it wants to use is not NULL, then any NULL pointer you encounter is
    an ERROR, and it's just as acceptable to let it crash by using it as it is
    to check it and then throw (or whatever). Unexpected NULL pointers are best
    handled (in my opinion) by assertions, to help (but not guarantee) catching
    programming mistakes during development. If you have production code which
    generates a NULL pointer when a NULL pointer is not expected and allowed,
    then you need to fix the part of the program that allowed the NULL to occur
    in the first place, not add code to check if it's NULL. Of course, if your
    program expects and allows NULL pointers on purpose, then checking for that
    condition is perfectly acceptable. But in general, adding NULL pointer
    checks everywhere is a poor practice, IMO.

    -Howard
     
    Howard, Dec 31, 2007
    #8
  9. 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
    #9
  10. Simon Saize

    Salt_Peter Guest

    On Dec 31, 1:31 pm, Simon Saize <> wrote:
    > Hi -
    >
    > What's the point of having references (&)? Why don't we just use
    > pointers (*)?
    >
    > Thanks.


    Because references can do things pointers can't in C++ (the reverse is
    true as well).
    C++ references benefits includes declaring and implementing operators.
    They also support polymorphic calls, just like pointers do.
    References make the code's intentions clear and unambiguous.
    (doesn't mean C++ is better, in some respects it does mean its safer)
    References can offer guarentees that pointers can't.
    For example:

    void foo(const int& r)
    {
    // do stuff
    }

    guarentees that reference r, if accessed within that function body,
    will refer to the original integer.
    That relationship is indestructeable.

    On the other hand, since a pointer_to_const is reseatable:

    void foo(const int* p)
    {
    int x(88);
    p = &x; // oops
    // do stuff
    }

    and a const pointer_to_const can be const_cast away:

    void foo(const int* const p)
    {
    int x(88);
    int* p_ = const_cast<int*>(p);
    p_ = &x; // oops
    // do stuff
    }

    a pointer of any flavour is unable to offer the same guarentee a
    reference can.
    void foo(const int& r) clearly states the intentions of the code.
    There is no uncertainty.
     
    Salt_Peter, Dec 31, 2007
    #10
  11. 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
    #11
  12. 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
    #12
  13. 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
    #13
  14. 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
    #14
  15. 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
    #15
  16. 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
    #16
  17. 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
    #17
  18. Simon Saize <> wrote in comp.lang.c:

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


    I don't know if anyone's interested, but I have a little trick for
    implementing references in C:

    The function "CopyUntilNull" copies TChar's from psrc to pdest, but it
    also updates the calling function's pointer. You'd use it like so:

    TChar buf[NUM],
    *p = buf;

    CopyUntilNull(&p,some_array_1);
    CopyUntilNull(&p,some_array_2); /* p has incremented value */
    CopyUntilNull(&p,some_array_3); /* p has incremented value */

    Here's the function that simulates taking a reference to a pointer:

    void CopyUntilNull(TChar **const ppdest, TChar const *psrc)
    {
    # define pdest (*ppdest)

    /* Now pdest is an L-value, just as if the
    function parameter had been TChar *&pdest */

    while (*++pdest = *++psrc);

    # undef pdest
    }

    This isn't a magnificient example of my "trick" (i.e. it'd be more
    efficient to use a local pointer and then set *ppdest at the very end so
    as to have one level of indirection instead of two), but you get the
    idea.

    --
    Tomás Ó hÉilidhe
     
    Tomás Ó hÉilidhe, Jan 1, 2008
    #18
  19. "Tomás Ó hÉilidhe" <> wrote in comp.lang.c:


    > while (*++pdest = *++psrc);


    That sort of is and isn't a typo. I had to alter the code slightly before
    posting (to remove crap people didn't need to see). But of course it would
    make more sense as:

    while (*pdest++ = *psrc++);

    --
    Tomás Ó hÉilidhe
     
    Tomás Ó hÉilidhe, Jan 1, 2008
    #19
  20. Simon Saize

    James Kanze Guest

    On Jan 1, 7:09 pm, jacob navia <> wrote:
    > 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.


    The charter of the group is not my opinion. Neither is the
    contents of the C standard. One thing the charter insists on is
    that the subject be relevant to all (or at least most)
    mainstream C implementations.

    As for opinion, yes: add references, operator overloading, and
    who kows what all else to C, and you no longer have C, but
    rather a crippled and broken 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 2, 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:
    473
    Karl Heinz Buchegger
    Nov 17, 2003
  2. Replies:
    3
    Views:
    484
    Victor Bazarov
    Nov 10, 2004
  3. DanielEKFA
    Replies:
    8
    Views:
    641
    DanielEKFA
    May 16, 2005
  4. Replies:
    8
    Views:
    759
    Bruno Desthuilliers
    Dec 12, 2006
  5. cerr

    pointers, pointers, pointers...

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

Share This Page