A question regarding cast operator

[LarryChen]

Here is the code,

class B
{
};

class A
{
public:
	operator B*()
	{
		B* pB = new B;
		return pB;
	}
};



int main()
{
	A a;

	B* pB = (B*)a;  // #1
	B* pB = static_cast<B*> (a);  // #2
	return 0;
}

When I use cast operator defined in class A, should I use statement #1 or #2? BTW, they both compile. Thanks.

[S_M_A]

I would say that in a C++ code you should never use a C-style cast and in a perfect world you shouldn't use cast as all...

A C-style cast isn't as search friendly as a c++ cast i.e whenever you change stuff they still are there silenting the compiler.

[LarryChen]

I would say that in a C++ code you should never use a C-style cast and in a perfect world you shouldn't use cast as all...

A C-style cast isn't as search friendly as a c++ cast i.e whenever you change stuff they still are there silenting the compiler.

You are absolutely right. But my question is that is cast operator *() always equivalent to static_cast? Thanks.

[ninja9578]

I'm pretty sure that both are required to work correctly according to the standard, but don't take my word on it. Someone more familiar with the standard, please verify. They both work for me, but that's no guarantee of the behavior with all compilers under all optimizations.

[nuzzle]

When I use cast operator defined in class A, should I use statement #1 or #2? BTW, they both compile. Thanks.

I've never found a reason to use the conversion operator so I may be wrong here but if you define a conversion operator why do you need to cast at all? Why don't you simply do,

B* pB = a; // #3

All of #1, #2 and #3 work but if you remove the conversion operator from A none of them will. That means they're all functionally equivalent in this case. They all simply invoke the conversion operator.

Generally they're not equivalent though. When you cast explicitly you're recommended to use one of the "new" more targeted casts. In this case it would be static_cast.

[ninja9578]

They aren't equivalent as far as I know.

B * pB = static_cast<B*>(a)

means I want to treat it as B*, is that okay compiler?

B * pb = (B*)a

means, screw what the compiler thinks, I'm casting it anyway.

In fact, because a is not a pointer, I'm pretty sure if there wasn't an explicit cast operator, it would fail compilation (or at least warn.)



Just FYI LarryChen, your code in the initial post leaks memory.

[nuzzle]

---

[TheGreatCthulhu]

They aren't equivalent as far as I know.

They aren't, but:

B * pB = static_cast<B*>(a)

means I want to treat it as B*, is that okay compiler?

B * pb = (B*)a

means, screw what the compiler thinks, I'm casting it anyway.

What do you mean?
I thought c-style casts call C++-style casts in some order?

@OP: BTW, although casts should generally be avoided, occasionally you do need to use them (for example, even if you can design your way out of it, the resulting code can end up being rather convoluted and even less performant, rendering the cast-based version both more elegant and more efficient).
Also, here's a different view advocating against C++-style casts. IM(H)O, the guy has a point, and if you're gonna use C++-style casts, it should be for very specific reasons on very specific places.
Of course, C++-style casts are considered a good C++ programming practice, so many people here will not agree.
In the end, it's really up to you to learn more about both and form your own opinion.

[S_M_A]

He has some points for sure but for me the strongest argument for not using C-style casts is that they are more or less impossible to find without reading every single line of code.

C++-style casts is easy to find, a search for _cast reveals them all to be thoroughly reviewed.

[superbonzo]

I thought c-style casts call C++-style casts in some order?

yes, but given that:

1- how those c-casts are interpreted in terms of c++-casts depends on further rules usually ignored by c-cast users ( that is, if they knew them they probably knew how to use c++-casts and hence avoid c-casts in the first place )

2- those rules are such as to give the more "relaxed" behavior

hence it's fair to say that a c-cast "means, screw what the compiler thinks, I'm casting it anyway."

so many people here will not agree.

I definitely disagree indeed !

IM(H)O, the guy has a point

He has some points for sure

just for the sake of discussion, which are them ?

[TheGreatCthulhu]

@S_M_A:
OK, that's true.
If there's a need to search for C-style casts, one might use VS regular expressions in the find dialog, something along these lines: "=:b*\(.*\)".
But, that might not find all the occurrences, and the fact that you need to come up with a cryptic regular expression makes the method error prone.

[TheGreatCthulhu]

just for the sake of discussion, which are them ?

You didn't find it reasonable an assumption that they could be stated in the article?

OK. According to Mr Kalev there:

• C-style casts may perform more than one conversion at once - so what?
• C-style casts make the code clearer.
• Specialized cast operators are an example of over-engineering. [I'd like to add that's good if you have more tools in your toolbox, but that doesn't mean you should always use them.]
• According to him static_cast isn't good for anything, and even Strosutrup discourages its use [although I'd say that that statement is possibly pulled out of context].
• The code can compile without casting [as nuzzle pointed out].
  

  Derived *p= pbase;
  int result= 12.56; //yes, this code compiles
  void*opaque =&myobj;

• According to Kalev, C++ cast operators are dangerous [if I understood well, to novice programmers or to those who don't fully understand all the differences between various cast operators].
• C-style casts are context-sensitive.
• "ugly cast operators [don’t] dissuade them from using casts. [...] Programmers use casts not because they’re fun but because they are needed, or at least considered as needed."
• Although C-style casts are harder to find, the argument is weakened by: (1) "many conversions in a C++ program are implicit, and don’t use any cast operator", and (2) you can use both C-style casts and C++-style casts in the same program. He also tried to make a point that you need to search for different cast operators, but as S_M_A noticed, one can just search for "_cast".

[laserlight]

The code can compile without casting [as nuzzle pointed out].

If the conversion function was declared as explicit then that would not be so.

[superbonzo]

You didn't find it reasonable an assumption that they could be stated in the article?

yes I did; mine was a rhetoric question because I didn't actually find any; moreover, I know you like bullet lists ...

YAccording to Mr Kalev there:

he's just combining obvious observations with unwarranted assumptions coming to debatable conclusions ...

BTW, IMHO the only situation where c++ casts are unusable is with explicit arithmetic conversions; anyway, even then I always use the functional notation in this case; yes, it's functionally equivalent for non-class types, but it's more coherent ( the same syntax is used with objects of class types; also, consider generic code ) and less abuse-prone ( you need a typedef to perform complex pointer/reference conversions in functional notation ).

[TheGreatCthulhu]

@laserlight:
(sorry for the slow reply, I went out in the meantime, so I'm typing this on my phone)

Yes, but his (Kalev's) point was that there
could be conversions in the code that aren't going to be found by the "_cast" search anyway.
It all boils down to personal reasons/judgement, and how well the code is designed.
Tell me: how many times will be significantly important to have control over the cast process? And I by that I mean that there's a strong reason to do so.