On Mon, 2009-06-01 at 05:14 +0200, Michael Bruck wrote:
> On Mon, Jun 1, 2009 at 4:35 AM, Zach Welch <z...@superlucidity.net> wrote:
> > On Mon, 2009-06-01 at 04:15 +0200, Michael Bruck wrote:
[snip]
> > I think 'struct foo' is much more clear when reading and writing code.
> >
> >> Doxygen seems to recognize the foo_s and foo_t version as one an the
> >> same, I don't see what problem you have there. However it will just as
> >> happily accept foo_t only, like in
> >>
> >> typedef struct {} foo_t;
> >
> > The problem with the documentation is the fact that there are two types
> > that refer to the same thing. The current scheme imposes extra effort
> > for new developers to realize that many blah_t types are structures, and
> > there is not immediate way to tell them apart without digging into
> > further into the documentation or code.
> >
> > I think the Wikipedia page on typedefs does a good job of explaining the
> > reasons to avoid them in this particular case:
> >
> > http://en.wikipedia.org/wiki/Typedef
> >
> > Neither of the K&R guidelines for using typedefs are met in this case:
> > 1) These types do nothing to aid portability; they add no value here.
> > 2) These types do not make a complex declaration easier to understand.
> > If anything, they make a simple declaration unnecessarily opaque.
>
> Thanks, I know the purpose of typedef. In this particular case it is a
> widely-used way to simulate the C++ behavior where the struct keyword
> is unnecessary.
By this argument, the foo_s should preferred for the same reasons: you
could use that without struct in C++ too. C is _not_ C++; in fact, C++
is even more opaque and obfuscated, so this argument holds little water.
If you like obfuscation, then use C++ -- let C be C.
> If it was for me the foo_s version would not exist, and there would be
> no duplication.
>
> You are pulling out K&R? You can't be serious!
I am pulling out the original _principles_ that created the keyword.
Both of the points that I made still hold true, even with C99.
C++ principles are not compelling, since we are discussing C code.
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
