public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Lancelot SIX <lsix@lancelotsix.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v2 3/4] gdb: Have setter and getter callbacks for settings
Date: Thu, 19 Aug 2021 17:03:32 -0400	[thread overview]
Message-ID: <435b5531-5f62-d28d-9cef-c5756e8f014e@polymtl.ca> (raw)
In-Reply-To: <20210811195946.ls3e2d2sbpt24o2e@ubuntu.lan>

On 2021-08-11 4:00 p.m., Lancelot SIX wrote:
>> Another option would be to use
>>
>>   gdb::optional<setting> var;
>>
>> in cmd_list_element, and make it such that a setting can never exist in
>> an invalid state.  Two constructor would exist, one to construct a
>> setting with a pointer to a buffer and another with the setter/getter.
>> There would be no need (I think) for set_p and set_accessors.
> 
> This approach would be a problem within param_smob
> (gdb/guile/scm-param.c). This struct is memset initialized, so we cannot
> have one of its member which is not a PODType (see the redefinition of
> memset in gdbsupport/poison.h).  We could have a pointer to a properly
> constructed setting within a param_smob plus some manual memory
> management, but I am not sure it is worth it.

Tony Tye sent me some comments about this patch, which made me
reconsider the approach a bit.  I don't see the problem with
Guile / param_smob.  In your patch, setting_wrapper is just a transient
object, it exists just for a moment to make the glue between a setting
(which can be handled by the common command code) and a param_smob.  But
it never needs to be stored anywhere (in a POD type or otherwise).

I implemented this approach of using gdb::optional and constructors, and
it seems to work pretty well.  I prefer it, because, as mentioned
before, the setting object can't exist in an invalid state.  And that
is one less thing to worry about.

The other comment was that the unions setting_getter and setting_setter
plus all the get_setting_setter / get_setting_getter implementations
were not really needed but add a lot of code.  Tony suggested to save
the getter and setter function pointers to type-erased variables, just
like we do for m_var.  And I don't think we lose any safety, as
var_type_uses already validates that we don't pass some invalid type T,
and that T matches var_type.  That removes a lot of boilerplate.  I
implemented this, and stored the getters / setters as `void (*) ()`.
Storing them as `void *` wouldn't work, because you can't freely convert
function pointers to data pointers and vice versa.

I started from your users/lsix/refactor-typesafe-var, made changes to
the various patches, and uploaded it to
users/simark/refactor-typesafe-var.

Let me know what you think.

Simon

  reply	other threads:[~2021-08-19 21:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-08 19:22 [PATCH v2 0/4] gdb: Refactor cmd_list_element.var Lancelot SIX
2021-08-08 19:22 ` [PATCH v2 1/4] gdb: Add typesafe getter/setter for cmd_list_element.var Lancelot SIX
2021-08-10  1:29   ` Simon Marchi
2021-08-10 12:22   ` Simon Marchi
2021-08-10 21:58     ` Lancelot SIX
2021-08-11  0:56       ` Simon Marchi
2021-08-08 19:23 ` [PATCH v2 2/4] gdb: make string-like set show commands use std::string variable Lancelot SIX
2021-08-08 19:23 ` [PATCH v2 3/4] gdb: Have setter and getter callbacks for settings Lancelot SIX
2021-08-10  3:01   ` Simon Marchi
2021-08-10 22:18     ` Lancelot SIX
2021-08-11  1:01       ` Simon Marchi
2021-08-11 20:00         ` Lancelot SIX
2021-08-19 21:03           ` Simon Marchi [this message]
2021-08-20  7:04             ` Lancelot SIX
2021-08-08 19:23 ` [PATCH v2 4/4] gdb: Setting setter return a bool to tell if the value changed Lancelot SIX

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=435b5531-5f62-d28d-9cef-c5756e8f014e@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=lsix@lancelotsix.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).