[Gs-devel] RE: A small proposal about improving GS coding style : CheckRET

[Igor V. Melichev]

Well, I see everybody are against it. OK, let's live without it.
Rather I have some comments to your comments.

> From:   Henry Stiles [henrys at meerkat.dimensional.com]
> Sent:   13 ?|?  2001 ?. 09:12
> To:     Igor V. Melichev
> Cc:     tech; gs-code-review at ghostscript.com; gs-devel at ghostscript.com
> Subject:        [Gs-devel] A small proposal about improving GS coding
style : CheckRET

> Have you considered a larger monitor?

I'm doing this every week! My one is 21" 1600x1200. Where can I get a larger
one ?


> From:   Raph Levien [raph at levien.com]
> Sent:   13 ?|?  2001 ?. 09:51
> To:     Ray Johnston
> Cc:     Igor V. Melichev; tech; code review; gs-devel
> Subject:        Re: A small proposal about improving GS coding style :
CheckRET

> I agree with Ray and luke here. In general, we want to move away from
> macros, and use plain C code.

I agree to get rid of macros. In my old projects I used CheckRET only.
There is no other macros. Rather it was C++ with multiple templates,
overloaded functions and operations...

> In my opinion, the saving of a line or
> so of code every time the error must be checked is not worth the
> disadvantages of macros.

I think, it's something bigger than saving a line.
Take a look a zfontapi.c in
http://www.ghostscript.com/pipermail/gs-code-review/2001-June/000782.html

> One tip I might suggest: a lot of times, when the control flow seems
> twisted (in large part because of error checking), I've found that
> splitting functions into smaller chunks helps readability enormously.
> These days, function calls are so cheap that only in rare cases is
> efficiency a valid reason not to do this.

CheckRET is not a function. It is control structure pattern,
similar to 'throw' or longjmp.

> A further disadvantage is that error conditions often require freeing
> resources. With the macro, I think there may be more times when that's
> missed. Also, code that does free resources will look very different
> than the CheckRET invocation, even though the only difference is a
> free() call.

Again, take a look at zpassfonttoFAPI in there.
Resource management is separated from errorful processing.
I recommend everybody to learn this pattern.

> From:   gs-code-review-admin at ghostscript.com on behalf of Ray Johnston
[ray at artifex.com]
> Sent:   13 ?|?  2001 ?. 08:47
> To:     Igor V. Melichev
> Cc:     tech; code review; gs-devel
> Subject:        [Gs-code-review] Re: A small proposal about improving GS
coding style : CheckRET

> While I appreciate your objection to a some lines being eaten up on the
> screen, my biggest objection to your suggestion is that when using a
> debugger, I don't know of a single debugger that is smart enough to
> set a breakpoint on the 'return code;' line.

1. Set breakpoint to the line containing CheckRET;
2. Run until the breakpoint;
3. Remove this breakpoint;
4. Open disassembler window;
3. Find 'ret' instruction in there and set breakpoint to it.
You get what you want.

I realize, this is somewhat cumbersome,
but really setting breakpoints to specific 'return' isn't a frequent need.
Also, MSVC can move execution point by user action,
so as you can enter the function again and repeat the execution
(if it has no side effects (I do this frequently)).

Also I already submitted the patch with CheckRET.
I'd like to know, what you'll think after reading entire thing.
I see that discussing it without context and background is not effective.

Igor.