As a regular CDT & VS user I
can say that advantages of writing code in CDT definitely
outweigh the
limitations of debugging with it,
so I prefer to use and really love CDT. Thank you guys for
working on it!
From my experience the main usability problems comes not from
CDT debugging support (DSF at least), but from gdb that is
used behind the scene. We have a quite big C++ project with
a few dozen
of shared libraries and gdb performance is not as good
as of VS debugger. In addition unfortunately gdb itself often
crashes during the debugging session, so sometimes I have to
debug not only my application, but also gdb itself. In this
connection, I am wondering whether there are plans about lldb
support. Or at least are there any difficulties expected to
implement it (except a lot of work, sure)?
There are also a few things to improve in CDT debugging
support. That most issues are related to Variables &
Expressions views and possibly
affect the Eclipse Platform rather than CDT
itself, however as an ending user I compare the complete
usability of IDE. Here are a few items:
- Something similar to VS visualizers feature [1]. VS has
a nice feature that allows to visualize the value of a
variable of some type with a custom GUI (there are a few
built-in visualizers, but they could be easily extended
with user plugins). It is like gdb pretty printers, but
work on GUI level. For example separate dialog for
examination of variables with long multiline strings or
XML/HTML content viewers (BTW currently viewing long
strings is almost impossible). Taking into account that
gdb has a python support, this feature could be really
flexible.
- GDB errors handling in Expressions view. When I add an
invalid _expression_ (e.g. variable) to the view I am
getting "Error: Multiple errors reported.", but as I can
see in gdb traces console, gdb itself returns "No symbol
\"b\" in current context." and "-var-create: unable to
create variable object". The refresh button directly in
the value column of the view would be also helpful, but
probably it is a Platform (not CDT) issue.
- Hover for the variable values in Variables &
Expressions views on Linux. Often the
value of the variable or _expression_ does not fit into
the value column. In such cases on Windows the hover
is shown. Probably it is a common issue of SWT or even
GTK (that is used by SWT on Linux), but I really miss
it especially here.
- Hot key for "Move to line (C/C++)" action. Not very
important, but a useful improvement.
[1] - http://msdn.microsoft.com/en-us/library/zayyhzts%28v=vs.80%29.aspx
Thanks,
Anton
-------- Original message --------
Yes, as Java programmers, we
don't get to use the CDT debugger very much. Even less
get exposed to the other debuggers such VS.
It would be great to get user
feedback on what is missing in the CDT debugger.
Marc-Andre had mentioned that
we are missing the ability to show the return value of a
method automatically. That would be
a great feature to have.
Are there other things that
an experienced VS user misses from CDT debug?
Thanks
Marc
Hi Guy,
That's good to hear! I find this comment intriguing: "(At
least for writing code not debugging)". Are you saying
that because you feel some features are missing when
debugging? I'm sure the debug guys would appreciate
feedback from someone coming from Visual Studio (perhaps
in a new thread).
Marc-Andre
On 13-07-03 11:56 AM,
guy.bonneau@xxxxxxxxxxxx wrote:
Indeed....
Yet I have to say that I really love Eclipse and
all its capabilities and architecture...
For 25 years I have worked only with Visual Studio
IDE. From 4.0 up to 2012 and C++. I couldn't believe
there was a better IDE than Visual Studio or C++
language. Until I switched job and had to work with
Eclipse and Java..! After 20 years with almost the
same IDE I struggled a lot and couldn't find the IDE
tools I wanted! It took me a year...Helped by 25 years
younger developers than me to patiently bring me to a
point were I was wowed by all the capabilities of
Eclipse! I Learned a lot both at the coding and
architecture level. And once I mastered Eclipse IDE I
wouldn't want to go back with VS (At least for writing
code not debugging)! I became a more proficient coder
with Eclipse and really enjoyed the coding experience
with it.
Since Microsoft released Visual 2012 I really hated
what they did with the IDE. Thousand of developers are
crying to Microsoft telling tell how they hate what
they did to their beloved IDE.
So I hope that Eclipse CDT IDE will grow in
architecture and coding stability. Its a great IDE.
Thought that I believe much work is left to do for
that they seems to be very close to bring the CDT to
maturity.
Thanks guys for the great CDT plugin.
Keep the good work.
Guy
Le 03/07/13, Joseph Henry <Joseph.Henry@xxxxxxx>
a écrit :
I
feel your pain Guy!!
I
too have struggled through the
tooling mess and custom command
lines just to get a few simple
outputs.
It
does seem like it should be much
simpler to go from initial input to
final output(s).
From:
cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of guy.bonneau@xxxxxxxxxxxx
Sent: Tuesday, July 02, 2013
5:33 PM
To:
cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Adding
a profile tool to a standard CDT
toolchain
After
much digging in the CDT code I
have progressed and I am now able
to have the profiler tool kick-in
with the appropriate inputs type
and output target. However I am
left with a feeling of something
unfinished regarding how the
output types (Primary or
secondary) can be defined and are
processed up to the command step
building. For example I don't see
how you can really produce many
outputs (primary and secondaries)
from a single tool since the
command line pattern have only one
${OUTPUT} dedicated to the primary
output.
I have
nonetheless be able to bypass this
problem by custom command line
generation and using option
definition. However I feel it
shouldn't be that hard.
To
have my profiler step builder
created and executed I have had to
solve an issue for which I have
created a bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=412146 The
calculateOutput method of build
description wrongly uses the tool
outputs file extension attribute
to create the resource outputs of
any outputType associated to the
tool. This prevent the build
manager to resolve the appropriate
build steps.
Guy
|
_______________________________________________
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