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

[JKop]

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

 

[David Hilsee]

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]

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.

 

[Ioannis Vranos]

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

 

[Phlip]

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.

 

[Jerry Coffin]

[ ... ]

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.