# void as a function parameter

116 replies to this topic

### #41juhnu

Valued Member

• Members
• 292 posts

Posted 28 May 2006 - 01:42 PM

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" ;)

### #42.oisyn

DevMaster Staff

• Moderators
• 1842 posts

Posted 28 May 2006 - 01:49 PM

#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
-
Currently working on: the 3D engine for Tomb Raider.

### #43Nick

Senior Member

• Members
• 1227 posts

Posted 28 May 2006 - 01:49 PM

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.

### #44.oisyn

DevMaster Staff

• Moderators
• 1842 posts

Posted 28 May 2006 - 02:02 PM

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
-
Currently working on: the 3D engine for Tomb Raider.

### #45juhnu

Valued Member

• Members
• 292 posts

Posted 28 May 2006 - 02:02 PM

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.

### #46juhnu

Valued Member

• Members
• 292 posts

Posted 28 May 2006 - 02:07 PM

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

### #47juhnu

Valued Member

• Members
• 292 posts

Posted 28 May 2006 - 02:16 PM

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?

### #48Nick

Senior Member

• Members
• 1227 posts

Posted 28 May 2006 - 02:30 PM

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.

### #49juhnu

Valued Member

• Members
• 292 posts

Posted 28 May 2006 - 02:39 PM

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.

### #50bramz

Valued Member

• Members
• 189 posts

Posted 28 May 2006 - 02:49 PM

I think we can conclude that, today, the benefits of this as a reference (or automatic reference/pointer thing) does not outweight its burden =)
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #51juhnu

Valued Member

• Members
• 292 posts

Posted 28 May 2006 - 03:38 PM

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

### #52bramz

Valued Member

• Members
• 189 posts

Posted 29 May 2006 - 12:38 PM

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 ...
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #53juhnu

Valued Member

• Members
• 292 posts

Posted 29 May 2006 - 01:23 PM

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?

### #54bramz

Valued Member

• Members
• 189 posts

Posted 29 May 2006 - 01:25 PM

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&)
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #55juhnu

Valued Member

• Members
• 292 posts

Posted 29 May 2006 - 01:37 PM

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

### #56davepermen

Senior Member

• Members
• 1306 posts

Posted 29 May 2006 - 06:02 PM

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..
davepermen.net
-Loving a Person is having the wish to see this Person happy, no matter what that means to yourself.
-No matter what it means to myself....

### #57SigKILL

Valued Member

• Members
• 200 posts

Posted 01 June 2006 - 04:30 PM

Nick said:

The use of 'm_' should die completely though.

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

### #58monjardin

Senior Member

• Members
• 1033 posts

Posted 01 June 2006 - 05:21 PM

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? ;)
monjardin's JwN Meter (1,2,3,4,5,6):
|----|----|----|----|----|----|----|----|----|----|
*

### #59Groove

New Member

• Members
• 26 posts

Posted 01 June 2006 - 05:52 PM

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

### #60.oisyn

DevMaster Staff

• Moderators
• 1842 posts

Posted 01 June 2006 - 06:27 PM

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_
-
Currently working on: the 3D engine for Tomb Raider.

#### 1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users