This is the mail archive of the 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: [PATCH] New function value_has_address

On 10/28/2016 12:49 PM, Yao Qi wrote:
>> > IMO, struct value and its lval types would be nice candidates
>> > for converting to a class hierarchy, with lval_funcs
>> > expanded into virtual methods in struct value directly, that are
>> > then used by all value lval types, including lval_memory/lval_register.
>> >
> Yes, I agree, but I don't know how much memory usage increase
> if "struct value" becomes "class value".  

Maybe one pointer.  Probably doesn't matter.
It'd be the equivalent of moving the const struct lval_funcs *funcs field
out of the union (If you add virtual methods to a class, it adds one
hidden pointer to a table of function pointers -- the vtable, so
that calls to virtual methods can dynamically dispatch, just like
lval_funcs).  If some fields move to subclasses that are seldom
instantiated, then you may actually save memory.  Or not, because
the heap may already be returning memory blocks larger than
we ask it, and we might simply waste less.  Depends on current size
of the structure, and malloc being used, etc.  Not a clear cut.

> We have such comments to "struct value",
> /* Note that the fields in this structure are arranged to save a bit
>    of memory.  */

I think that's referring to the maybe-surprising ordering of members
of the struct -- they're layed out to avoid holes due to alignment.

> I am not ready converting value to C++ as I still don't think I fully
> understand it.

I wasn't suggesting you'd do it yourself.  Just saying that if people
want to try it, they have my support.  :-)

Pedro Alves

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