Why "this" is a pointer, I just realized!

Discussion in 'C++' started by JKop, Sep 6, 2004.

  1. JKop

    JKop Guest

    You can overload the address-of operator. Consider a simple class:

    class Blah
    {
    public:

    Blah* operator&()
    {
    return this;
    }
    };

    Now... consider if "this" was a reference (as before I've argued it should
    be):

    class Blah
    {
    public:

    Blah* operator&()
    {
    return &this;
    }
    };


    looks like an infinite loop to me...


    Although to be honest I would've prefered "p_this".


    -JKop
     
    JKop, Sep 6, 2004
    #1
    1. Advertising

  2. JKop

    David Hilsee Guest

    "JKop" <> wrote in message
    news:Ss5%c.26732$...
    > You can overload the address-of operator. Consider a simple class:
    >
    > class Blah
    > {
    > public:
    >
    > Blah* operator&()
    > {
    > return this;
    > }
    > };
    >
    > Now... consider if "this" was a reference (as before I've argued it should
    > be):
    >
    > class Blah
    > {
    > public:
    >
    > Blah* operator&()
    > {
    > return &this;
    > }
    > };
    >
    >
    > looks like an infinite loop to me...
    >
    >
    > Although to be honest I would've prefered "p_this".


    In "The Design and Evolution of C++", Bjarne Stroustrup says that "this" is
    a pointer and not a reference because references were not present in "C with
    Classes" at the time that "this" was introduced.

    --
    David Hilsee
     
    David Hilsee, Sep 7, 2004
    #2
    1. Advertising

  3. JKop

    David Hilsee Guest

    "David Hilsee" <> wrote in message
    news:...
    > "JKop" <> wrote in message
    > news:Ss5%c.26732$...
    > > You can overload the address-of operator. Consider a simple class:
    > >
    > > class Blah
    > > {
    > > public:
    > >
    > > Blah* operator&()
    > > {
    > > return this;
    > > }
    > > };
    > >
    > > Now... consider if "this" was a reference (as before I've argued it

    should
    > > be):
    > >
    > > class Blah
    > > {
    > > public:
    > >
    > > Blah* operator&()
    > > {
    > > return &this;
    > > }
    > > };
    > >
    > >
    > > looks like an infinite loop to me...
    > >
    > >
    > > Although to be honest I would've prefered "p_this".

    >
    > In "The Design and Evolution of C++", Bjarne Stroustrup says that "this"

    is
    > a pointer and not a reference because references were not present in "C

    with
    > Classes" at the time that "this" was introduced.


    I did a quick search and found that many people already said this the first
    time you brought this up. I must have missed the discussion the first time
    around. I'll add something new by pointing out that your overload of
    operator& has little bearing on the matter, because it is rarely (if ever)
    used in the way that you are using it. Normally, operator& is overloaded to
    _alter_ the return value. If you just want to return "this", then you don't
    need to overload operator&.

    If you really wanted the address and wanted to avoid invoking operator&, you
    could use something like boost's addressof
    (http://www.boost.org/libs/utility/utility.htm#addressof), so it wouldn't
    matter if "this" was a reference.

    --
    David Hilsee
     
    David Hilsee, Sep 7, 2004
    #3
  4. JKop wrote:
    > You can overload the address-of operator. Consider a simple class:
    >
    > class Blah
    > {
    > public:
    >
    > Blah* operator&()
    > {
    > return this;
    > }
    > };
    >
    > Now... consider if "this" was a reference (as before I've argued it should
    > be):
    >
    > class Blah
    > {
    > public:
    >
    > Blah* operator&()
    > {
    > return &this;
    > }
    > };
    >
    >
    > looks like an infinite loop to me...
    >
    >
    > Although to be honest I would've prefered "p_this".




    Provided the reference to "Design and Evolution" that David provided, I
    want to note that C++ is not a language of the lab, but a product of
    evolution that *addresses real world problems*.


    So here is the evolution of C++:


    BCPL


    B: As dmr mentions, "B can be thought of as C without types; more
    accurately, it is BCPL squeezed into 8K bytes of memory and filtered
    through Thompson's brain."

    http://www.cs.bell-labs.com/who/dmr/chist.html


    C90 (ISO C90)


    C++98 (some concepts also taken from Simula).






    Regards,

    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Sep 7, 2004
    #4
  5. JKop

    Phlip Guest

    Ioannis Vranos wrote:

    > Provided the reference to "Design and Evolution" that David provided, I
    > want to note that C++ is not a language of the lab, but a product of
    > evolution that *addresses real world problems*.


    Notice Ioannis is saying that C++ was deployed to business users before all
    its logical inconsistencies were removed. These tend to shock newbies who
    think that a language designer must be somehow infallible.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Sep 7, 2004
    #5
  6. JKop

    Jerry Coffin Guest

    "Phlip" <> wrote in message news:<8cb%c.14831$>...

    [ ... ]

    > Notice Ioannis is saying that C++ was deployed to business users before all
    > its logical inconsistencies were removed. These tend to shock newbies who
    > think that a language designer must be somehow infallible.


    Regardless of the method by which it was developed, I've yet to see a
    single language from which all logical inconsistencies had been
    removed, or which lacked "features" that could surprise newbies. In
    the end, language designers are human, and the languages they design
    reflect that.

    OTOH, I'd keep in mind that a language is basically a specification
    for some software. Most current thought on specs for software seems to
    emphasize collecting information from real users on a regular and
    ongoing basis throughout the design process, and IMO, a language is no
    different. If anything, I'd say that languages generally suffer more
    from language designers who are too close to infallible. They design
    languages that work well for their aims, but they're enough different
    from the average programmer that they often design things that average
    programmers can barely understand, not to mention really use.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Sep 7, 2004
    #6
    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. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    939
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,139
    Smokey Grindel
    Dec 2, 2006
  3. Replies:
    10
    Views:
    731
    Chris Torek
    Feb 4, 2005
  4. Michael
    Replies:
    19
    Views:
    474
    Earl Purple
    Aug 30, 2006
  5. Josef Moellers

    Tk: Call subroutine when MainWindow is realized?

    Josef Moellers, Jan 10, 2005, in forum: Perl Misc
    Replies:
    7
    Views:
    131
    Steve Lidie
    Jan 15, 2005
Loading...

Share This Page