RFR 8071627: Code refactoring to override == operator of Symbol*
Ioi Lam
ioi.lam at oracle.com
Wed Apr 8 23:53:16 UTC 2015
Hi John,
Thanks for sending the draft.
As I mentioned in my other reply, we don't just have a few
T*::operator== that we don't like. We don't like all of the
Symbol*==Symbol* comparisons :-(
Also, we don't want to leave behind any Symbol* pointers that someone
could do a == comparison by mistake. That's why we're replacing all the
Symbol* with SymbolRef.
- Ioi
On 4/8/15 4:11 PM, John Rose wrote:
> P.S. I posted a sketch of a design pattern which can help us tame uses of T*::operator== using a wrapper template.
>
> This does not require a mass rewrite, just introduction of a cast-like operator near every use of T*::operator== that we don't like.
>
> http://cr.openjdk.java.net/~jrose/draft/saferef.cpp
>
> It's probably too clever, though: Like the proposed mega-change, it would disguise the meaning of the affected operator== occurrences.
>
> It may be better to just rewrite the operator== occurrences as Symbol::identity_equals, and document that engineers should avoid direct uses of Symbol*::operator==.
>
> (Yes, I know that Symbol* has risky aspects in its pointer-ness. But trying to code in C++ without dealing with the oddities of pointer types is IMO futile. You end up with an embedded DSL which nobody wants to understand.)
>
More information about the hotspot-runtime-dev
mailing list