Re: [g-a-devel]Re: gnopernicus bits ... & patch

[Michael Meeks <michael ximian com>]

Hi Dragi,

On Thu, 2002-08-15 at 21:42, Draghi Puterity wrote:
> thank you for the time you spent to review the Gnopernicus code.

	The least I can do; I didn't read that much of it I'm afraid though.

> > Firstly, the code is covered in C++ style '//' comments, these
> > are not portable, and illegal ANSI C, gcc just happens to support
> > them.
> 
> MP: We will comply, but we are VERY unhappy about this.

	:-) life sucks; it's pretty easy to fix automatically, although it'll
result in a big checkin; if you create a perl script a little like:

#!/usr/bin/perl -pi.bak

     s|//(.*)|/\*\1 \*/|;

	And then do:

	find -name '*.c' -exec /tmp/mypl.pl {} \;

	It'll do the sed for you ... ;-) of course, this will cause trouble
with single line comments within multi-line comments [ the C way is to
use #if 0 / #endif for these ], but it seems likely to help the manual
labour ;-)

> MP: True, but I usually address this problem by declaring one pointer var on
> a line. For me the star on the right of the type is more readable as I can
> read the declaration from left to right instead of right to left (i.e. "var
> is a pointer to Type").

	Fair enough; whatever - I think at our stage we parse code in great
chunks anyway so 'Type *p' is just as legible as 'Type* p'. Either way,
the Gnome way seems to be the former, if you're very convinced about
your way stick with it, I just think it's confusing.

>   How about using
> 
> typedef  Type* PTYPE;
> PTYPE pa, pb;     /* same as Type *pa, *pb; */ ?

	XGack; Asoon PNyou'll Vbe Vwanting Nhungarian Nnotation ;-) etc.
typically it's frowned upon to hide a pointer in a typedef like that.

> MP: It seems that my thinking was alterated by higher-level MS tools (i.e.
> go to declaration / implementation of function, etc) ;-) Will try to comply
> in the new code and review the existing code ASAP.

	:-) I wouldn't bother cleaning this up ASAP - I'd focus on the
warnings, and just clean it later as you re-read / maintain the code.
That way you get a sort of cumulative history of how old the method is,
by how ancient it's style is ;-)

> MP: For my part, go ahead and comit the patches for brlimp.c, sercomm.c. For
> the others I'd like to have first the OK from each devloper. Adi, to make it
> easier for all, please gather all the comments from the romanian developers
> in one mail.

	I'll wait for a combined diagnosis so I can commit in a block; thanks.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot