On 04.01.2011 16:44, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane_at_xbc.nu]
>> Sent: dinsdag 4 januari 2011 16:27
>> To: dev_at_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
Received on 2011-01-04 17:14:03 CET