Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167664
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: C naming conventions |
| Date | 2022-09-13 05:18 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <86a673piw4.fsf@linuxsc.com> (permalink) |
| References | <3e090bd4-4274-467b-8cf7-6d36c3ab9dc9n@googlegroups.com> <tf5deq$3l26r$1@dont-email.me> <86edwgptqk.fsf@linuxsc.com> <tfousb$2gf7l$1@dont-email.me> |
kegs@provalid.com (Kent Dickey) writes: > In article <86edwgptqk.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> kegs@provalid.com (Kent Dickey) writes: [..largely condensed..] >>> All structs are created by STRUCT(Sample_structure) where STRUCT is: >>> #define STRUCT(a) typedef struct a ## _st a; struct a ## _st >> >> It is a little bit safer if STRUCT(a) were defined >> >> #define STRUCT(a) \ >> struct a ## _st; typedef struct a ## _st a; struct a ## _st >> >> The reasons are somewhat esoteric. But since the leading >> declaration is hidden inside a macro, it seems better to use the >> safer form. > > What are the reasons? It's not obvious to me what it is, but I would > guess it's some sort of namespace conflict you're trying to avoid. It's common to think of 'typedef struct some_tag SomeTypeName;' as doing two things, namely, introducing a new structure tag, and giving an alternate name to a struct type having that tag. What actually happens is not exactly that. The point of putting in the leading 'struct a ## _st;' is to ensure that a new tag is introduced into the relevant scope, rather than possibly reusing an existing structure tag defined in an outer scope. Basically the point of having 'struct a ## _st;' is to make sure that the following 'typedef struct a ## _st a;' behaves the way people expect it to behave, and not be blindsided by different behavior when the structure tag accidentally matches a tag defined in an outer scope. >> [...] > > My rules are a pushback against needless abstraction. [...] Whether an abstraction is needless is a subjective question. It seems to me that (some of) the rules you proprose effectively prevent any abstraction in some cases, whether it is "needless" or not. >> [...] > > I'm trying to put some protective pads on to avoid C's many > pitfalls, and make it easy to browse code, even without complex > tools. [...] I'm not sure what kinds of tools you count as "complex tools". Do you mean to avoid using any of the standard utilities that were part of Unix 40+ years ago? To me it seems silly to design rules assuming such a primitive environment (that is, one where the common Unix utilities of circa 1980 were not present). One question for you: looking over your own code, what would you say is a rough distribution of function lengths? What is the range of lengths, what is the average length, what is the median length? If you can get exact numbers, so much the better, but rough guesses (assuming they are informed guesses) are fine.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-27 16:06 -0700
Re: C naming conventions antispam@math.uni.wroc.pl - 2022-08-27 23:42 +0000
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:42 -0700
Re: C naming conventions luser droog <luser.droog@gmail.com> - 2022-08-29 19:12 -0700
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 10:54 -0700
Re: C naming conventions Opus <ifonly@youknew.org> - 2022-08-30 20:21 +0200
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 09:02 -0700
Re: C naming conventions Opus <ifonly@youknew.org> - 2022-08-29 20:06 +0200
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 18:15 -0700
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 18:46 -0700
Re: C naming conventions Blue-Maned_Hawk <bluemanedhawk@example.invalid> - 2022-09-06 02:21 -0400
Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-06 10:52 +0100
Re: C naming conventions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-06 11:03 -0700
Re: C naming conventions Opus <ifonly@youknew.org> - 2022-08-30 05:22 +0200
Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 21:25 +0100
Re: C naming conventions Anton Shepelev <anton.txt@gmail.com> - 2022-08-31 01:38 +0300
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 04:37 -0700
Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:30 +0100
Re: C naming conventions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-08-31 14:50 +0000
Re: C naming conventions scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 14:57 +0000
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 08:44 -0700
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 08:36 -0700
Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:54 +0100
Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:50 +0100
Re: C naming conventions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-08-31 17:14 +0000
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 10:21 -0700
Re: C naming conventions Anton Shepelev <anton.txt@gmail.com> - 2022-09-05 23:31 +0300
Re: C naming conventions Bart <bc@freeuk.com> - 2022-09-05 21:44 +0100
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-09-05 18:00 -0700
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-09-11 09:22 -0700
Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-11 20:33 +0100
Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-09-11 13:18 -0700
Re: C naming conventions luser droog <luser.droog@gmail.com> - 2022-09-11 21:16 -0700
Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 11:51 +0100
Re: C naming conventions luser droog <luser.droog@gmail.com> - 2022-08-30 19:36 -0700
Re: C naming conventions kegs@provalid.com (Kent Dickey) - 2022-09-05 17:59 +0000
Re: C naming conventions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-12 07:12 -0700
Re: C naming conventions kegs@provalid.com (Kent Dickey) - 2022-09-13 03:53 +0000
Re: C naming conventions Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-13 05:38 +0000
Re: C naming conventions scott@slp53.sl.home (Scott Lurndal) - 2022-09-13 13:30 +0000
Re: C naming conventions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 05:18 -0700
Re: C naming conventions kegs@provalid.com (Kent Dickey) - 2022-09-13 22:55 +0000
Re: C naming conventions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-13 16:58 -0700
Re: C naming conventions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 08:05 -0700
Re: C naming conventions Blue-Maned_Hawk <bluemanedhawk@example.invalid> - 2022-09-06 02:16 -0400
Re: C naming conventions Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 19:31 +0200
Re: C naming conventions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-12 00:45 -0700
Re: C naming conventions Jonathan Harston <jgh@mdfs.net> - 2022-09-27 06:00 -0700
Re: C naming conventions John Bode <jfbode1029@gmail.com> - 2022-09-30 13:02 -0500
Re: C naming conventions Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 18:32 +0000
Re: C naming conventions scott@slp53.sl.home (Scott Lurndal) - 2022-10-01 16:26 +0000
Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-01 00:54 +0100
Re: C naming conventions Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-10-01 00:35 -0400
Re: C naming conventions Kaz Kylheku <864-117-4973@kylheku.com> - 2022-10-01 08:12 +0000
Re: C naming conventions Kaz Kylheku <864-117-4973@kylheku.com> - 2022-10-01 08:11 +0000
csiph-web