: Re: [RFC] multiple breakpoints from FILE:LINE

[Robert Dewar]

Jim Blandy wrote:

>But the case being discussed in this thread is menus that appear in
>response to a location specified by a filename and line number.  It's
>not clear that the kind of legitimate ambiguity you're concerned about
>is present here.
>  
>
OK, understood.

>When a function has been inlined, it's odd for users to demand to be
>able to set breakpoints on one inlined instance but not another.  You
>can't set a breakpoint on a function conditional on it having been
>called from a certain place; why would users suddenly require that
>functionality just because the compiler decided to optimize the code
>in a certain way?
>  
>
I agree with this for the caser of inlined procedures, and I don't think 
it is
even necessary to have the possibility of setting breakpoints on an instance
by instance basis

>In-charge and not-in-charge constructors are a similar situation. 
>There's nothing in the semantics of the source language that ever
>suggests that there are two separate reifications of the single block
>of code the user wrote.  This differs from instantiations of generics,
>which (if I understand right) are things that the user actually did
>ask for.  The two constructor instances don't behave differently, as
>far as the source level in concerned.  Separating the two is purely an
>implementation strategy, and should be hidden from the user when
>reasonable.
>  
>
I agree

>In cases where the same code has been #included twice, I think there's
>more of a case that users might want to choose one or the other, since
>it is indeed explicit in the source code that this particular source
>line is going to contribute twice to the translation unit.  But even
>here, setting the breakpoint in both places would be a clear
>improvement over what we do now: choose one #inclusion randomly.
>  
>
Indeed, one random instance is for suer wrong

>(The last time we discussed this, Michael Chastain pointed out that
>you actually *do* want to choose a specific constructor instance when
>you're disassembling.  But we're talking about breakpoints here; the
>decision just needs to be made at the right place, so we can do one
>thing for 'break' and a different thing for 'disass'.)
>  
>
There is one more case, related to the #include case, which is generic 
templates in Ada, and here
too I think you want the possibility of setting a breakpoint in specific 
instances.