This is the mail archive of the
gsl-discuss@sourceware.cygnus.com
mailing list for the GSL project.
Re: complex number API
- To: Mark Galassi <rosalia@cygnus.com>
- Subject: Re: complex number API
- From: James Theiler <jt@nis.lanl.gov>
- Date: Mon, 8 Feb 1999 16:04:43 -0700 (MST)
- cc: gsl-discuss@sourceware.cygnus.com
On Mon, 8 Feb 1999, Mark Galassi wrote:
]
] Gerard> I would like to add another form as well, of the suggested
] Gerard> 'return z' type, since that looks like it would be nicer
] Gerard> to type. I'm thinking something contructor-like
]
] Gerard> GSL_COMPLEX(x,y)
]
] Gerard> which could be used like
]
] Gerard> gsl_complex foo_z = GSL_COMPLEX(x,y);
]
] Gerard> Trivial as an inline function, but is it possible to do as
] Gerard> a macro too?
]
] I would also like such a function, but I can't figure out how to do it
] with a macro. James's cute trick of using the do { stuff } while(0)
] won't work if you have to return a value. You do need a block to
] allocate a variable for the result, but I don't know how to return
] something.
]
] James, do you have any cute tricks?
]
] Maybe we could go with an autoconf/ifdef-ed use of GCC's inline
] functions across module boundaries, but they are a bit annoying.
]
Sorry, no cute tricks.
Is this the kind of thing that is likely to be deep in an inner loop,
though? ie, does the macro really buy you that much?
I agree that the following code snippet is annoying
#ifdef HAVE_INLINE
inline
#endif
gsl_complex func()
but I thought that autoconf was smarter than that, and if you asked
it to check for whether your compiler supported inline's, and your
compiler doesn't, then it would set
#define inline
in the config.h file. In that case, can't you blithely write
inline gsl_complex func()
and the compiler (actually cpp, I guess) will do the right thing?
Maybe I'm wrong...
By the way, I'm not necessarily advocating this for gsl, but i noticed on
another project if i named all my new data types things that ended in _t,
eg "Complex_t", then emacs would color them as if they were builtin types.
it also made it a little easier to avoid confusion about variable names
and type names.
regards,
jt
---------------------------------------------
James Theiler jt@lanl.gov
MS-D436, NIS-2, LANL tel: 505/665-5682
Los Alamos, NM 87545 fax: 505/665-4414
----- Space and Remote Sensing Sciences -----