Re: [PATCH 15/16] gdb: make cmd_list_element var an optional union

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-07-29 4:12 p.m., Lancelot SIX via Gdb-patches wrote:
> On Thu, Jul 29, 2021 at 11:47:10AM -0600, Tom Tromey wrote:
>>>>>>> "Lancelot" == Lancelot SIX <lsix@lancelotsix.com> writes:
>>
>> Lancelot> Would you prefer to have something like var.get<var_string> () return a
>> Lancelot> string happily if var is lets say a var_filename but fail if it is a
>> Lancelot> var_boolean?
>>
>> Yeah.
>>
>> Lancelot> I guess it is possible, but I did intentionally went for a very explicit
>> Lancelot> approach.  The idea is to have the user of the class state that he is
>> Lancelot> aware he will access a data of a given type that can be interpreted in
>> Lancelot> different ways.  This kind of makes more sense when dealing with the
>> Lancelot> various var_*integer* types where the same value can have different
>> Lancelot> meaning depending on the effective var_type.
>>
>> I don't understand how to reconcile this with the idea that one could
>> pass in a bunch of var_ parameters and get some result back.
>> Like does get<var_integer, var_zinteger> work?
> 
> Yes, given that both var_integer and var_zinteger use a int*, this would
> work. However, something like get<var_uinteger, var_zuienteger> will
> fail to compile because var_uinteger uses unsigned int* while
> var_zuinteger uses a int*.
> 
>>
>> I guess the argument would be that the author of that line is supposed
>> to understand what's happening and that the meaning of the value might
>> "vary"?
> 
> It is the original idea.  Multiple "var_types" can share the same
> storage type while still being different logical types (a given value is
> to be interpreted differently based on the actual type).  The original
> idea was to use it in a 'get<var_sometype>' way but this was conflicting
> with how this is used.  I followed that path to see where it lead.
> 
>> For me that seems to add a bunch of extra template code but
>> without any real gain in safety.

There is some gain in safety... in that it could catch some mistakes at
compile time.  I don't really have an opinion on when the amount of
template complexity gets too high compared to the gain in safety.

> I’ll revisit all of this in a V2 later.  I was worried about the amount
> of template boilerplate this adds compared to the value it brings, I
> should have worried a bit more!  If I strip the extra template noise,
> this can come down to some get_string/set_string/get_int/set_int and so
> on.  The 'get<var_?>' can be a light abstraction on top of that, if ever
> needed (I am not sure it is).

Would the get_string/set_string/get_int/set_int methods still assert
that the var_type matches the storage type accessed?  I think that's
important to have.

Simon