This is the mail archive of the
gsl-discuss@sourceware.cygnus.com
mailing list for the GSL project.
Re: complex number API
I don't know what if this is the right thing, but I find that Emacs will
highlight a struct correctly if you write is as "struct gsl_cool" instead
of simply "gsl_cool". So the convention that I use in my code is to include
the word "struct". Occasionally, when I hate the typing, I insert the
appropriate "typedef" definitions on the C file. In some cases I put a
whole lot of these "typedef" definitions on another header file.
I have no idea if this style is considered good. It makes Emacs happy however,
and it's my 2 cents.
Elef.
>
>I generally use _t if the type is a single element, like an unsigned int
>or function pointer, and drop the _t for a struct/class (e.g. like
>time_t vs struct tm). gsl_complex_t seems wrong to me somehow.
>
>Mark Galassi wrote:
>>
>> 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 :-)