If not needed, I'd prefer to keep things simple, without a
prefix. The idea is to make it as easy
as possible for users to get to see the expressions they
want, so the simpler the format the better.
I am not sure it is a critical issue (I could open
a bug though). Don't you think it is better to add some prefix ("group: var1,
var2") or e.g. take the group in square brackets ("[var1, var2]")
to explicitly emphasize that it is a
group but not a simple _expression_?
Thanks, Anton.
--------
Original message --------
That is an interesting point.
The current implementation assumes that ',' and ';' can
only be group separators. Therefore,
it is not possible to use those two characters anymore
as part of an _expression_.
If you can open a bug, I think we can do something like
perl does, and let the user
choose which of ',' and ';' is the separator, freeing
the other one to be used as part
of the _expression_.
Thanks
Marc
Thanks for link, the clarification in comment
was helpful. However it also leads to another question. How to distinct
"var1, var2" meaning group with var1 & var2 from C++ _expression_
containing to variables and overloaded operator ","?
Note: I have
tried to evaluate an _expression_ containing overloaded "," with gdb 7.3.1,
but it seems it does not support calling overloaded operator ",". However
the other operators (e.g. "+") work properly, so it seems like a
bug.
Thanks, Anton.
-------- Original message
--------
Glob-patterns for variables is a little tricky
to handle so it was not implemented at this time (beyond the single
_expression_ '*').
I think it would be
great to support these, but I personally won't have time to
work on it in the near future. If someone
wants
to take a stab at
it, that would be great.
The complexity is in
the collisions between glob-syntax and
C/C++-syntax.
One way forward is
proposed at
Thanks
Marc
Hi,
Cool feature! I am wondering
what was the final decision about using glob-patterns for variables?
Will they be supported or not (as I can see in N&N they are not
supported yet)?
Thanks, Anton
-------- Original
message --------
Hi,
FYI, the proposal below has been
implemented and pushed to master. You are welcomed to
try it and give
feedback.
Note that the solution went a bit
further than the proposal, where the Expressions
view
not only supports glob-patterns but
also comma-separated lists of expressions e.g., $eax, myvar,
$$s*
See the New&Noteworthy for the
short description:
BR,
Marc
Hello,
I would
like to propose an enhancement to the Expressions view
for CDT
Debug. We are focusing on the
Juno
release right now, but since we discussed the idea
in the CDT
monthly call, I'm sending this proposal
now.
==
Currently,
the Registers view for CDT/GDB shows all registers in a flat
list. For targets with a large number of
registers
this is
not very user-friendly.
I propose
to support pattern-matching within the Expressions view to allow
users to easily create groups of
registers. For
example:
$* would display all
registers
$st[0-5] would show $st0, $st1 , ... $st5
The user would simply type the _expression_
in the "Add new _expression_" box as she would
for
any other
_expression_.
Although
this feature is focusing on registers (only _expression_s starting with $ will allow patterns)
it may be
a nice enhancement to extend this to other
expressions. If that was also supported, a
user
could do
such things as create an _expression_ 'myArray[20-120] to only show
a subset of an array; many
other
examples can be imagined as
well.
With such possibilities in
mind, the prototype does allow for the
_expression_: * which will
automatically
show
all local variables and
arguments of the selected stack
frame.
Comments and
suggestions are very welcomed.
Thanks
Marc
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|