[Olsr-dev] questions regarding v2 coding style / lang

[Henning Rogge]

Am Montag 08 September 2008 14:34:16 schrieb Bernd Petrovitsch:
> How can the compiler inline a function he doesn't know (because the body
> is buried in some other .[co] file)?
Okay, you got me... another "bad design" of c... :(

> gcc was notoriously bad for this - read: inline'd too much. And for
> others I have even less estimations.
Was ? That sounds like we could use "compiler inlining" now.

> BTW according to the C standard the "inline" keyword was never nothing
> more than a hint to the compiler (and he is free to ignore it for
> whatever reason, e.g. "not implemented").
> I use (and see) inline functions only as "type-checking macros" (in the
> nearest sense). So anything more than some one- or two-liner (see the
> ones in src/ipcalc.h as the somewhat largest that makes sense IMHO.
> Granted, a few of them are debatable) shouldn't be inlined in the first
> place. Of course if someone shows good reasons, I have no problems with
> exceptions to rules (including a comment here so that it is not
> forgotten).
> One use for macros is to transparently hide __FILE__ and __LINE__
> parameters.
Okay, so macros (as long as they keep simple) have their place in debug printf 
commands...

> [...]
>
> > I think our config file parser is one of the BAD examples... it's always
> > a nightmare to understand what this thing is doing and how to add/change
> > an option.
>
> It's a typical lex/yacc parser. And yes, they do not produce the most
> beautiful code in the world. But people (at least me) are old enough to
> know lex/yacc good enough to use it (and my sed scripts are there to
> kill the warnings. We can also disable the warnings for the relevant
> files but adding the `sed` stuff was simpler as it was in exactly two
> places).
>
> For starters on lex/yacc: find another similar option and copy-edit it.
>
> The only chance that I see: Throw it out and replace it with something
> better.
Exactly.

> > > If someone is interested in mine (additional to the above;-):
> > >
> > > The most important one: Do not copy "logic" (read: almost always code).
> > > Abstract it. Or will have a maintenance nightmare sooner or later.
> >
> > Yes, abstraction is a good idea.
>
> One can over-abstract too - especially on the higher levels and trashing
> the performance through enormous use of malloc()/free() onm large
> networks.
The trick is to abstract but to keep good code... my design goal for the 
packetbb parser is a completely generic parser which does not need to 
allocate any kind of memory during parsing (as an example).

> Yes, sometimes (especially with old libs like xdr, rpcgen etc.) that
> gets messy (and "free(void *)" is broken defined in the C
> standard/POSIX/SUSv3 BTW. That should better be "free(const void *)").
>
> And then you are doing something wrong. The duplicated set of accessors
> in src/common/avl.h is IMHO a strong sign that we should get rid of them
> completely.
> I see no real value in them anyways: for "hiding of internals" to the
> rest of the world they are IMHO too low level (and one wouldn't use them
> internally anyways).
> And what's their practical value?
I see no practical reason for C "const" except something like a comment "this 
should not be modified".

> Then fix you *C-compiler* and/or it's settings.
> If the compiler produces a warning, you are *not* using a C-compiler
> (but more probably a C++ compiler).
> Sorry, "people with misconfigured and/or br0ken environments" are not a
> good reason IMHO.
> If someone really wants to support C++ compilers (for whatever reason),
> please find a saner solution than to add type casts (and/or disable
> warnings).
I have to check this at home, I think a gcc (not g++) with -Werror and -Wall 
throws an error for converting a void* into another pointer without a 
typecast.

> So I'm more the "do `find -name '*.[ch]' -print0 | xargs -0r perl -w -i
> -p -e 's/olsr_u8_t/uint8_t/' and remove the typedef" person.
> Hmm, I have to try <inttypes.h> on Win32.
exactly... if this doesn't work on windows and OSX we cannot use it.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)