On 04.01.2011 16:44, Bert Huijben wrote: > >> -----Original Message----- >> From: Branko Čibej [mailto:br...@xbc.nu] >> Sent: dinsdag 4 januari 2011 16:27 >> To: dev@subversion.apache.org >> Subject: Re: svn commit: r1053996 [1/2] - in >> /subversion/trunk/subversion: include/ include/private/ libsvn_client/ >> libsvn_diff/ libsvn_fs_base/ libsvn_fs_base/bdb/ libsvn_fs_fs/ >> libsvn_ra_neon/ libsvn_ra_serf/ libsvn_ra_svn/ libsvn_subr/ libsvn_wc/ >> mod_authz_svn/ >> >> I frankly see no reason at all to do this "everywhere", it's just >> unnecessary code churn. The struct tags are only useful if the >> structure >> references itself (via pointers), and our practice for such cases was >> to >> declare the typedef first, and the struct itself below it, and use the >> typedef name in the struct definition. >> >> So unless someone can explain the reasoning why all these anonymous >> structs and enums etc. should have names -- on technical grounds, not >> some stylistic hand-waving -- then please revert. > 2 minor (but to me very useful) reasons to use an explicit name: > * svn diff -x -p shows the structname this way, so it makes commit diffs more > readable > * Debuggers that handle typedefs as an alias for the struct (such as Visual > Studio) show foo_t in the debugger output instead of __unnamed_ABCDEF (ABCDEF > is a hex number which can change between compiler invocations).
Ah. The debugger thing is not a bad reason at all. Personally I prefer this way: typedef struct foo_t foo_t; struct foo_t {}; but I like vermilion bikesheds, too. -- Brane