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_?
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 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
-------- Original message
Glob-patterns for variables is a little tricky
to handle so it was not implemented at this time (beyond the single
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
to take a stab at
it, that would be great.
The complexity is in
the collisions between glob-syntax and
One way forward is
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
FYI, the proposal below has been
implemented and pushed to master. You are welcomed to
try it and give
Note that the solution went a bit
further than the proposal, where the Expressions
not only supports glob-patterns but
also comma-separated lists of expressions e.g., $eax, myvar,
See the New&Noteworthy for the
like to propose an enhancement to the Expressions view
Debug. We are focusing on the
release right now, but since we discussed the idea
in the CDT
monthly call, I'm sending this proposal
the Registers view for CDT/GDB shows all registers in a flat
list. For targets with a large number of
not very user-friendly.
to support pattern-matching within the Expressions view to allow
users to easily create groups of
$* would display all
$st[0-5] would show $st0, $st1 , ... $st5
The user would simply type the _expression_
in the "Add new _expression_" box as she would
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
such things as create an _expression_ 'myArray[20-120] to only show
a subset of an array; many
examples can be imagined as
With such possibilities in
mind, the prototype does allow for the
_expression_: * which will
all local variables and
arguments of the selected stack
suggestions are very welcomed.
cdt-dev mailing list
cdt-dev mailing list