116 replies to this topic

[juhnu]

Nick said:

I wonder if, hypothetically, 'this' could automatically evaluate to a reference type or a pointer type (sort of like an implicit cast operator), it could possibly break any existing code...

or they could introduce a new keyword "self" ;)

[.oisyn]

#define this (*this)

About member access: that should definitely NOT change. Or do you think you should always type the fully qualified name for any global as well (e.g., ::mynamespace::myfunction instead of myfunction)? Because they're not so unrelated

[Nick]

juhnu said:

or they could introduce a new keyword "self" ;)

Then I rather keep writing 'this->'. :sad: And in fact that would instantly break all code that uses 'self' as an identifier.

Seriously though, I'd love to find one example of currently valid C++ code that would break when 'this' can automatically evaluate to a reference.

[.oisyn]

Or, if we had some sort of typeof operator

template<class T> struct thisref_t : public T
{
    T * operator -> () { return this; }
};

#define this static_cast<thisref_t<typeof(*this)> &>(*this)

class MyClass()
{
    void foo();
    void bar()
    {
        this.foo(); // ok
        this->foo(); // ok
    }
};

Then again, that would disable the use of an operator-> defined in MyClass

[juhnu]

Nick said:

Then I rather keep writing 'this->'. :sad: And in fact that would instantly break all code that uses 'self' as an identifier.

Seriously though, I'd love to find one example of currently valid C++ code that would break when 'this' can automatically evaluate to a reference.

Yeah, I'd prefer writing 'this->' over 'self.' too actually. The automatic evaluation to a reference type is an interesting idea. I can't think of any example rightaway where it wouldn't work. 'this' should be a pointer by default, and implicitly casted to a reference when needed.

[juhnu]

.oisyn said:

Then again, that would disable the use of an operator-> defined in MyClass

and it would have problems when you want to pass 'this'-pointer to a function.

[juhnu]

bramz said:

About (2), today you already have the choice to access all your member variables through this anyway, so why break all that existing code?

..because then the compiler would help in catching some bugs like in this:

struct Foo {

   int legCount;

   void SetLegCount(int legcount) {

     this->legCount=legCount;

   } 

};

To avoid this I usually use 'p'-prefix for function parameters. Maybe if there was a keyword to define the normal member access or a stricter one for a function?

[Nick]

I think I found an interesting (but unfortunate) counter-example:

class ABC

{

    void doX(ABC *abc);

    void doX(ABC &abc);


    void doY();

    {

        doX(this);   // Call first or second version?

    }

};

So clearly it wouldn't work to have 'this.' syntax with backward compatibility.

[juhnu]

Nick said:

I think I found an interesting (but unfortunate) counter-example:

class ABC

{

    void doX(ABC *abc);

    void doX(ABC &abc);


    void doY();

    {

        doX(this);   // Call first or second version?

    }

};

So clearly it wouldn't work to have 'this.' syntax with backward compatibility.

That would call the first one as the 'this' would be evaluated as a pointer.

[bramz]

I think we can conclude that, today, the benefits of this as a reference (or automatic reference/pointer thing) does not outweight its burden =)

[juhnu]

bramz said:

I think we can conclude that, today, the benefits of this as a reference (or automatic reference/pointer thing) does not outweight its burden =)

well..I'd like to hold off judgement on a thing like that, sir, until all the facts are in. =)

[bramz]

What other facts do you want?

Thing is, we can't get it to being a reference exclusively, for obvious reasons. So, if we want it to act as reference, we should give it a dual character of being both a reference and pointer, but that poses ambiguities that confuse matters in a way that's not proportional to the rather mundane problem at hand: being able to write a dot instead of an arrow. Frankly, I hardly ever use the this pointer anyway. Or more correctly: if I do, it mostly is to pass it as an argument to a function. This minor syntantic change is really not worth the troubles ...

[juhnu]

bramz said:

What other facts do you want?

Can you think of a situation where the dual-nature of a this-pointer/reference would cause problems in the existing code?

[bramz]

juhnu said:

Can you think of a situation where the dual-nature of a this-pointer/reference would cause problems in the existing code?

See above ... operator-> and foo(bar*) + foo(bar&)

[juhnu]

bramz said:

See above ... operator-> and foo(bar*) + foo(bar&)

ah yes, the operator-> would be a problem indeed, but foo(bar*)/foo(bar&) wouldn't..... ok I give up ;)

[davepermen]

i'd prefer my over self..

my.counter ++; just sounds as good or bad as self.counter ++; (imho, my sound better).

but i don't care about it at all :D and there is no chance because of backwards compatibility..

[SigKILL]

Nick said:

The use of 'm_' should die completely though.

Care to explain why? I like my m_ ´s.

[monjardin]

davepermen said:

i'd prefer my over self..

Do as .oisyn pointed out:

#define my (*this)

Of course, you're a C# guy anyway right? ;)

[Groove]

I prefer self too. It's a more commom one also used in Python

[.oisyn]

SigKILL said:

Care to explain why? I like my m_ ´s.

I dislike the underscore, my preference would be mMemberVariable and sStaticVariable and such. Unfortunately, the m_ is a coding standard at our company. But on the bright side of things, Visual Assist has the feature to interpret the sequence [m] [shift] as m_