This is the mail archive of the gsl-discuss@sourceware.cygnus.com mailing list for the GSL project.


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

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 :-)


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