[gs-devel] RE: [Gs-code-review] recent change to C-style.htm
Igor V. Melichev
igor at artifex.com
Mon Mar 4 10:16:10 PST 2002
> From: Dan Coby [mailto:dan at artifex.com]
> Sent: Saturday, March 02, 2002 2:00 AM
> To: Igor V. Melichev; Ray Johnston; L. Peter Deutsch; code review;
> Cc: Miles Jones
> Subject: RE: [Gs-code-review] recent change to C-style.htm
> I have used this feature on several
> occasions and I think that it is very useful. However, in some cases, it
> helped. In my recent situation of debugging an invalid return code in the
> fill logic, this feature only told about thousands of 'dict full' errors
> told me nothing about problems in the fill logic.
As Peter said, you could resolve this with a conditional breakpoint,
which depends on the return code.
In any case, an universal solution doesn't exist, and I'm not hunting for
My point is that without the macro first you need to find a particular
return statement for setting a breakpoint. Currently GS contains
thousand ones, and you don't know which one to choose.
Also it is not clear why do you want to break at a propagating code
rather than at originating code.
> I still dislike hiding flow control within macros. In general, I believe
> that hiding the flow control is a bad idea. Hiding things is the first
> overlooking things. Macros like CheckRET cannot be used in any routine
> which has resources that need to be released before the routine exits.
In my vision, it is not a flow control at all.
It is an exception.
> I understand the desire for shorter source code but I think that saving
> or two lines
It is some bigger than a line or two.
It is a different vision of algorithms.
As well as GS code contains thousands such lines rather than two.
More information about the gs-devel