R: Gearlib as a DSP Library

[Marco Ballini]

----- Original Message -----
From: Unkargherth <address@hidden>
To: <address@hidden>
Sent: Thursday, May 31, 2001 12:04 AM
Subject: RE: Gearlib as a DSP Library

> As when I startted to upload code to the GEARLIB section of cvs in
> octalmachines project i was the first, I used ( or tried to) my own naming
> conventions and guidelines set. Obviously i'ts open for discusion, but
> bassically

I really appreciated your work. Sorry if I didn't mention it (I also didn't
mention Linefeed's lfstoredsin.c, which I actually read after posting my
first message) but I needed some feedback, because maybe things (code) could
come faster if we agreed explicitly about some conventions. OTOH, I think
this conventions could regard not only a naming standard.

>
> .- All the source files ar named Something Like GR_<Name>.xx
>
> .- All the functions are named something Like GR_NameOfTheFunction
>
> .- All the functions are classes something Like GR_NameOfTheFunction
>
> .- All the public methods are named GR_ClassName::MethodName
>

-- From an aesthetic point of view, I think  I'd prefer something like GTK+
naming convention.Well, this is not so important, but for example I'd prefer
the C functions in lower case like gr_function_name() and use upper case for
struct types and C++ stuff.

-- I was also wondering whether it is better to have each file in gearlib
independant (except from GR_Base.h, or few others "friend" files) or to have
some kind of hierarchy. Maybe something like a C object oriented system
similar to that of GTK+ (but hopefully simpler). Then we could have the
opportunity to easily reuse code deriving classes (maybe most of classes
could depend on a GrGear struct that provides an interface and methods for
signal routing). I tend to prefer this second solution, as most of my
filters
share some structs and some functions.

> .- All all the private/protected methods are named as you want
>
> .- All the Attributes (supossing they are private to the class) are named
as
> you want
>
> .- I'm tried to avoid satic declarations ( dto knows it well )
>
> .- Avoid int's in calculations
>
> .- At the risk of seeming stupid for the obviousness, but seems important.
> Better don't include any code that doesn' clean compile !!!
>

> .- I tried to make ( whenever i could figure out) a C version AND a C++
> Version ( ie define structures and functions AND THEN a class wrapper to
use
> it from C++)
>
Yes! Something like gtk+ and gtk-- (this seems an obsession... but that
system is a really good job, and is a good example as almost every GNU
developer knows it).

> .- There's a  GR_Base.h file who make all non GearLib Includes with the
> convenient #ifdef's. And it's the Only Place where we include this files.
> From GEARLIB files we imake #include GR_Base.h
>
> .- There's a GR_All.h file that make #inlcudes of all the GR_xxx.h files
>  to simplify de GEARLIB Make)
>


> .- While we discuss and agree another way to do it, all params from CORE
> OX_API shoulds be passed to the functions by value
> .- The standard CORE API def's ( param, samp and so ) shouldn't be used In
> GEARLIB ( to maintain the independence)
>
Actually I used those typedefs, because when for example Octal will change
samp from float to double we will want to do the same in GearLib avoiding to
manually change all the "float"s in our code. But maybe you are right.
Probably we could have something like grsamp, grparam, etc.?

> I tried to follow this Guidelines in all the source i've uploaded ( and
the
> parts that I didn't uploaded too) but if you check it, be prepared to find
> mistakes realted to the previous list. I'll try to correct it as soon as
> posible

Thanks for your answer,
Marco