From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [RFA 01/14] Introduce py-ref.h
Date: Thu, 10 Nov 2016 23:48:00 -0000 [thread overview]
Message-ID: <7df8b22f-cd05-c0d6-5ede-e9dc29bca6e2@redhat.com> (raw)
In-Reply-To: <1478497656-11832-2-git-send-email-tom@tromey.com>
On 11/07/2016 05:47 AM, Tom Tromey wrote:
> +/* An instance of this class holds a reference to a PyObject. When
> + the object is destroyed, the PyObject is decref'd.
> +
> + Normally an instance is constructed using a PyObject*. This sort
> + of initialization lets this class manage the lifetime of that
> + reference.
> +
> + Assignment and copy construction will make a new reference as
> + appropriate. Assignment from a plain PyObject* is disallowed to
> + avoid confusion about whether this acquires a new reference;
> + instead use the "reset" method -- which, like the PyObject*
> + constructor, transfers ownership.
I think this should say something about supporting explicitly
wrapping a NULL PyObject *, and how to check whether there's
a managed object.
> +*/
> +class gdbpy_reference
> +{
> + public:
> +
> + /* Create a new NULL instance. */
> + gdbpy_reference ()
> + : m_obj (NULL)
> + {
> + }
> +
> + /* Create a new NULL instance. */
> + gdbpy_reference (nullptr_t)
> + : m_obj (NULL)
> + {
> + }
I don't think this overload is needed, since there's no
ambiguity without it. If you don't provide it, initializing
with nullptr selects the one below, with the same result.
Otherwise, shouldn't this overload be explicit too?
> +
> + /* Create a new instance. OBJ is a reference, management of which
> + is now transferred to this class. */
> + explicit gdbpy_reference (PyObject *obj)
> + : m_obj (obj)
> + {
> + }
> + /* Equality. */
> + bool operator== (const PyObject *other) const
> + {
> + return m_obj == other;
> + }
> +
> + /* Inequality. */
> + bool operator!= (const PyObject *other) const
> + {
> + return m_obj != other;
> + }
This supports:
gdbpy_reference == PyObject *
Seems to me we should support these too:
gdbpy_reference == gdbpy_reference
PyObject * == gdbpy_reference
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-11-10 23:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-07 6:00 [RFA 00/14] add a smart pointer for PyObject* Tom Tromey
2016-11-07 5:48 ` [RFA 10/14] Use gdbpy_reference in call_doc_function Tom Tromey
2016-11-07 5:48 ` [RFA 07/14] Use gdbpy_reference in gdbpy_breakpoints Tom Tromey
2016-11-07 5:48 ` [RFA 12/14] Use gdbpy_reference in python.c Tom Tromey
2016-11-07 5:48 ` [RFA 06/14] Use gdbpy_reference in gdbpy_inferiors Tom Tromey
2016-11-07 5:48 ` [RFA 13/14] Use gdbpy_reference in py-value.c Tom Tromey
2016-11-07 5:48 ` [RFA 04/14] Use gdbpy_reference in gdbpy_string_to_argv Tom Tromey
2016-11-07 5:48 ` [RFA 03/14] Use gdbpy_reference in py-type.c Tom Tromey
2016-11-07 5:48 ` [RFA 01/14] Introduce py-ref.h Tom Tromey
2016-11-07 7:45 ` Jan Kratochvil
2016-11-07 15:48 ` Tom Tromey
2016-11-10 23:48 ` Pedro Alves [this message]
2016-11-12 17:31 ` Tom Tromey
2016-11-15 14:32 ` Pedro Alves
2016-11-16 23:18 ` Tom Tromey
2016-11-16 23:34 ` Pedro Alves
2016-11-07 5:48 ` [RFA 11/14] Use gdbpy_reference in py-prettyprint.c Tom Tromey
2016-11-07 5:48 ` [RFA 05/14] Use gdbpy_reference in py-function.c Tom Tromey
2016-11-07 5:48 ` [RFA 14/14] Use gdbpy_reference in gdbpy_lookup_symbol Tom Tromey
2016-11-07 5:48 ` [RFA 08/14] Use gdbpy_reference in py-framefilter.c Tom Tromey
2016-11-07 5:56 ` [RFA 02/14] Change event code to use gdbpy_reference Tom Tromey
2016-11-11 0:09 ` Pedro Alves
2016-11-11 0:51 ` Pedro Alves
2016-11-07 5:57 ` [RFA 09/14] Use gdbpy_reference in py-linetable.c Tom Tromey
2016-11-08 4:07 ` [RFA 00/14] add a smart pointer for PyObject* Tom Tromey
2016-11-11 1:18 ` Pedro Alves
2016-11-11 3:34 ` Tom Tromey
2016-11-11 4:03 ` Pedro Alves
2016-11-11 5:49 ` Tom Tromey
2016-11-12 17:11 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7df8b22f-cd05-c0d6-5ede-e9dc29bca6e2@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox