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