[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ayttm-devel] Function prototypes in .c files
From: |
Andy |
Subject: |
Re: [Ayttm-devel] Function prototypes in .c files |
Date: |
Wed, 22 Jan 2003 08:37:37 -0100 |
User-agent: |
KMail/1.4.3 |
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