On Fri, 23 Jun 2017 09:08:12 +0200
Anselm R Garbe <garbeam_AT_gmail.com> wrote:
Dear Anselm,
> How come? I mean the rationale behind my suggestion of typedef'ing
> structs or enums is *not* to make them opaque, but to avoid additional
> qualifiers in the code or composed struct definitions which sucks. I
> prefer having
>
> Type type;
>
> instead of
>
> struct s_type type;
>
> or within a struct definition:
>
> typedef struct {
> int x;
> Type *types;
> } SomeOtherType;
>
> instead of
>
> struct s_some_other_type {
> int x;
> struct s_type *types;
> }
>
> It reads much easier avoiding the additional qualifiers.
it is a matter of taste. Hiding a struct behind a typedef just
complicates the matter in my opinion, and in my view comes very close
to defining an opaque type.
The qualifier "struct" indicates that you have a data structure with
fields and which you can only pass by pointer. Custom types don't allow
you to see this immediately, given there are enough pieces of code
where e.g. "uin32_t" is typedeffed to "Integer32" or something. Doing
so for structs the same way does not allow you to see the nature of the
structure.
It's the same with enums. Of course, they are just of type int, but
using enum-types helps give more semantic meaning to a piece of code.
> Wrt. looking up the definition I also don't see the point you are
> making if we require the typedef being at the struct definition or
> just prior to it due to forward declaration reasons. In order to look
> it up, it makes no difference at all.
If you typedef an anonymous struct directly, this is correct. The
example I gave was where big libraries actually don't do that and have
internal and external names for the same struct. I may have been a bit
unclear, as suckless code is not affected by that.
> But this is not due to the use of typedef's, it's because of the
> exposure of opaque types, which I'm not propagating at all.
I agree with you on the matter with regard to opaque types. In my view
though, typedeffing struct almost equates to making it an opaque type,
as you cannot discern the nature of the type from such a custom name as
easily as with a plain struct-qualifier.
> NO NO NO -- the coding style is absolutely correct about "_user_
> defined types - I never talked about opaque types.
>
> Opaque types relate from the people that learned programming the OO
> way first and buy into the argument of information hiding and crap
> like that. Elegant libraries and code barley needs information hiding.
>
> Information hiding is particularly required in a OO modelling world,
> as there typically mediocre co-developers are your "customers" and you
> don't want them to mess in your business logic. But the real problem
> is that the typical OO-world mixes data and algorithms together. In C
> this barely is a problem. Neither it is with OO done right in Go for
> instance.
Yes, in general you should strive to avoid opaque datatypes. However,
there are many exceptions, and I gave one in particular. The FILE
type from stdio.h is an opaque type and the reasons why that is are
legitimate.
> So I'm really keen on incorporating this style of typedef'ed user
> defined types in suckless projects. It has been there for a reason and
> it is in dwm/dmenu/ etc. for a reason.
I understand your point, and I hope you understand mine. After all, the
per-project-style rule is effective here. Let's discuss this a bit more
at the hackathon; I'm looking forward to it! :)
With best regards
Laslo Hunhold
--
Laslo Hunhold <dev_AT_frign.de>
Received on Fri Jun 23 2017 - 12:49:00 CEST