This is the mail archive of the
gsl-discuss@sourceware.cygnus.com
mailing list for the GSL project.
Re: complex number API
>Mailing-List: contact gsl-discuss-help@sourceware.cygnus.com; run by ezmlm
>Precedence: bulk
>Content-Type: text/plain; charset=us-ascii
>Date: Mon, 8 Feb 1999 18:19:00 -0700 (MST)
>From: Mark Galassi <rosalia@cygnus.com>
>Cc: Mark Galassi <rosalia@cygnus.com>, gsl-discuss@sourceware.cygnus.com
>
>
> James> By the way, I'm not necessarily advocating this for gsl,
> James> but i noticed on another project if i named all my new data
> James> types things that ended in _t, eg "Complex_t", then emacs
> James> would color them as if they were builtin types. it also
> James> made it a little easier to avoid confusion about variable
> James> names and type names.
>
>that is a very nice idea, and if we are slowing down the API evolution
>with 0.4.x we should consider this.
>
>One shortcoming I see is that gsl_complex_t is longer.
>
>complex_t is better, but might conflict with other code. Of course
>some day gsl will be the only source of numerical routines, so maybe
>that doesn't matter :-)
It is very trivial to do
#define complex_t gsl_complex_t
to cut down some typing, when you know that there will be no conflict.
You can even do:
#define cplx_t gsl_complex_t
If there is too many of these definitions, they could be placed in
a separate header file for those users that want to use them.
Elef.