This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: String class + Documentation Questions
- To: Joe Buck <jbuck at synopsys dot com>
- Subject: Re: String class + Documentation Questions
- From: nbecker at fred dot net
- Date: 21 Aug 1998 11:34:29 -0400
- Cc: tv at pobox dot com, johnr at euler dot mcdata dot com, egcs at cygnus dot com
- References: <199808211516.IAA14156@atrus.synopsys.com>
>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:
>> What I'd like to see is a complex class that's more useful for
>> numerical processing:
>>
>> 1) No default constructor (avoid wasting time initializing arrays)
>> 2) Direct public access to .re and .im to ease porting of legacy code.
Joe> It is trivial to write one. But I don't understand your second point:
Joe> what large body of legacy code assumes complex values have accessible
Joe> .re and .im (and not .r and .i, .real and .imag, etc).?
You need write access to something. In at least some cases legacy
code can be ported by using #define. In that case the exact name may
not matter.
An example is libfftw. Fortunately, it uses:
#define c_re(c) ((c).re)
#define c_im(c) ((c).im)
So I can easily redefine this. The problem I've seen in many legacy
cases is that some way to assign directly to the real or imaginary
part is assumed. This can't easily be faked with the stl complex.