Re: [dev] [sbase] style

From: <anselm_AT_garbe.us>
Date: Thu, 20 Nov 2014 07:56:29 +0100

On 20 November 2014 06:31, Markus Wichmann <nullplan_AT_gmx.net> wrote:
> On Wed, Nov 19, 2014 at 07:58:28PM +0100, k0ga_AT_shike2.com wrote:
>> For long time I followed the rule of kernel style of not using typedef
>> ever, but I changed it to the rule of using typedef only with structs
>> and capital letter, and I can say that this last is far better; You
>> get more readable function definitions:
>>
>> funcion(struct Term *term1, struct Term *term2)
>>
>> becomes
>>
>> function(Term *term1, Term *term2)
>>
>>
>> Regards,
>
> How's that more readable? I do agree that function pointer typedefs make

It's more compact, hence more readable. Not only in signatures, but
also in other structs and at variable declarations.

> But regarding the typedefs for structs: C has only a few namespace
> features, so lets not dismantle the probably most used one, alright?
> "struct stat" can be something different from "stat()"! I like that
> namespace thing so much I even use it in C++ (declaring objects with
> "class foo object;"). Not that I use C++ all that often, but, you know,
> professional obligations and shit.

Why do you bring typedefs in correlation with namespaces?

Thank god C does not require C++-style namespaces. (And if someone
really wanted them, some CPP magic do the same).

Requiring and using C++ namespaces is a pretty good indicator of wrong
abstraction and software design, mostly inherited by the introduction
of OOP. Having mixed together algorithms and data structs in classes
in C++ it didn't took long that namespaces had to be introduced as
well...

> In your above example in the first definition it is clear that Term is a
> struct to everyone. All I know from the second definition is that I have
> to look up what a Term is, because for all I can see it might be
> typedef'd to a pointer type, or a union, or an array of whatever. True,
> that might not be necessary all that often, but with your first line it
> becomes completely unnecessary.
>
> Oh, and typedefing struct pointers is just evil. For instance, when you
> declare
>
> struct foo;
> typedef struct foo *PST_FOO;
> function(const PST_FOO);

That wasn't suggested. Just typedef'ing structs and function
signatures. If you come across such a typedef'ed "type" you know quite
easily that it can only be a struct, in case of a function I would
also pre- or postfix Fn to make it more explicit that such a type
refers to a function.

If you can rely on the fact that reading Foo means struct and reading
FooFn means function, then you don't really need to check if Foo is
something else. You will need to check the struct fields anyways by
seeking for Foo's definition.

BR,
Anselm
Received on Thu Nov 20 2014 - 07:56:29 CET