This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: __imag__ and __real__ in C++ (bug 11437)


> But I'd like a C++ person to look at bug 11437, and at my analysis and 
> see what should be done.  An alternative solution is to remove _Complex 
> support from C++, of course.

I certainly don't have much to say here, but if you'd ask me: get rid of this 
stuff. C++ has a perfectly C++-style complex class, and __imag__/__real__ 
operators are just plain ugly [1]. There's not need for them. Let's have a 
C++ compiler, not one that tries to follow all possible contortions people's 
brains have invented over time. [2]

W.

[1] You'll have noticed that I wasn't even sure what the code in the PR should 
mean. I suspected that __imag__ might be an extraction operator, but wasn't 
sure. I would much rather rate this in the category "good for code 
obfuscation contests".

[2] One thought about backward compatibility -- we're talking here about C++, 
and in this case I think it's likely that 90% of codes already need fixing 
for gcc3.4, since they didn't follow two-stage name lookup and template base 
class member lookup in the correct way. Compared to the trouble we are 
putting people in with that, the question here (use of __real__/__imag__) is 
certainly one that will affect a miniscule number of people. 3.4 is certainly 
a good timeframe to abandon all kinds of odd extensions.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]