Re: [Ayttm-devel] Function prototypes in .c files

[Andy]

On Wednesday 22 January 2003 05:02, Philip S Tellis wrote:
> On Tue, 21 Jan 2003, Andy wrote:
> > I don't understand how including a header can affect the .o size
> > [unless it adds some junk for debugging with -g on or includes code?].
>
> try this:
>
> #include <stdio.h>
> int main() { printf("Hello, World!\n"); return 0;}
>
> gcc -c
>
> Next, add #include <gtk/gtk.h> to the top and gcc -c again.

I don't have time to do this right now - have to get to work.  I believe you, 
I just don't understand it :-)

[snip]
> > Great plan.  I'm all for working towards this.  Then can I have my Qt
> > interface? :-)
>
> And I can have my text only interface.  Also, on this note, has anyone
> had a look at ariyahoo?  It's a client that's used mainly by blind
> people.  Would be cool if we could have that kind of support.  A TTS
> interface would be great.

Hey, that sounds neat.

> if(
> a.h:
> GList * accounts;
> ) then a.h must #include <glib.h>, even if a.h #includes b.h, which in
> turn #includes glib.h.  This is so because at some point we may not
> require a.h to depend on b.h.  That would suddenly make a.h not work.

OK.  This is the point that we differ on :-)  I let the compiler do the work 
to figure out when this kind of thing happens.  Adding/removing header files 
is not too taxing IMHO.

> > > ayttm.  Forward declarations are fine in this regard if the size of
>
> forward declarations for types that we define.  (eg: struct contact;)
>
> > repercussions.  The whole namespace thing is a mess in ayttm.  There
> > seems to be no naming conventions whatsoever [please correct me if I'm
> > wrong].
>
> then I won't correct you ;)
>
> ok, something else I found out yesterday.  In the service plugins, we
> can make almost all functions static.  Anything that is passed to ayttm
> through the service_callbacks struct can be static.

I noticed that too.  I've been more-or-less staying away from the plugins 
because I didn't want to tread on your [and Colin's] domain :-)

> > Again header -> file size relation?  Is this a GTK thing?
>
> very likely dependent only on Gtk.  I think the reason is that Gtk
> defines so many types.  Also, Gtk includes Gdk - which again defines so
> many types, and glib - which although not that many, and not that big,
> also defines its own types.  glib on its own doesn't do that much

Obviously Gtk was also not started by Software Engineers :-)

> damage, but we're really only using the GList from glib, so it makes
> sense to just write our own doubly-linked-list library (like yahoo_list
> in libyahoo2 or elist in eb-lite).

I agree here.  [writing doubly-linked lists AGAIN!?! :-)]

> > I know that a variable called filename is global?  My preference is to
> > use gFileName if it's truly a global and sFileName if it's a .c file
>
> Ok, I'm ok with this, except that variable capitalisation reminds me too
> much of Visual Basic programs.  I'd rather use underscores if it's okay

Never used VB.

> with everyone.  Also (and people may hate me for this, but) a very
> stripped down Hungarian notation <already starting to run> may help:
>
> g - global to project
> l - local to function
> t - function parameter
> s - file scope

I use g and s.  I eliminate the 'l' and a break t into in*, out*, and io* to 
show its role [as in int foo( char inFlag, int *outResponse )]. 

Colin favours a 'g_filename' kind of thing which is fine with me.  [Although I 
_know_ an ioFooBar is going to slip by occasionally - it's the way I've 
worked for umpteen years :-)]

> I don't think we need type information specified... if the variable name
> doesn't offer a hint to that then it may have to be renamed.

Agreed.  Gets way too cumbersome.

> > Which makes me think of another thing here.  There seems to be an
> > awful lot of 'magic numbers' in this code.  I think this should be
> > addressed as well.  We could also talk about preferring an enum over a
> > bunch of defines....
>
> Well, I prefer enums - as you can see from the yahoo code - so I'm with
> you on this.
>
> The question now is ... where do we start?

...Good question.  I've already started on the static thing as you've seen.  I 
will also enum some of the #define lists I've seen.  I'm not going to propose 
that we go through and change variable names all over the place yet, however 
some of the 'globals' drive me nuts [filename] so I may just do something 
there....

Should we write up a coding standard, and change things as we see them?   Or 
is this getting too formal? :-)

Cheers,
        Andy