This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Debug Operators with GDB Python


On Mon, Dec 3, 2012 at 5:48 AM, Siva Chandra <sivachandra@google.com> wrote:
> Unless we aim to allow overloading of the Python
> implementations themselves, we will any way have to bypass that
> infrastructure which selects the right operator/method if a Python
> implementation is found.

There may be a disconnect, so let me take a step back.
One question is, besides overloading, how much more of the c++
language itself comes into play here?

> Am I missing something here? If we are not
> gaining anything, what I am suggesting is that we do this as a two
> step process treating them as two separate features.

There may be a disconnect here as well, or perhaps not.  No worries.
Anyways, a concern I have is that I don't want anything going into a
published API (that we can't later change) without having spent some
time understanding where we want to end up.  And that means spending
some time on what you're referring to as the second step before
committing to the first step.  The second step doesn't have to be
implemented at the same time, but it does have to be understood.

> But again, if we
> do not want to allow Python operators to be defined for languages
> other than C++, treating them as methods/functions is probably more
> meaningful from the users' point of view.

Ah, thanks for reminding me.
No claim is made that we want anything C++ only, but one thing an
operator-only feature needs to do is to parameterize the language the
operator is for.

>> Regarding templates,
>> pretty-printers for, e.g., stl vectors, already have to handle this issue.
>> To me it's a solvable problem (not involving excessive effort).
>
> The issue with templates comes when we want to "add methods to a
> class/type". Since a user will specify type names using name matchers,
> we will not know which explicit class/type to add methods to. Having
> the ability to add methods/functions would have been ideal though, as
> it would then been able to make use of the GDB infrastructure which
> deals with inheritance and dynamic types.

I could be missing something, but for the task at hand do we need to
know, in advance, what class to add the methods to?  I can envision
implementations that don't.

Hmm, that reminds me of another thing.  The parameter matchers need to
support regular-expression based matching, but I think we need to
leave it to the operator author to decide how to actually perform the
match.  We would provide utilities to make the common case simple, but
we can't hardwire in the inability to handle more complex cases.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]