J
Joshua Maurice
As an aside, I love the visual studios IDE and especially the
integrated debugger. It beats everything I've ever seen built on top
of gdb in terms of usability and power IMHO.
As an aside, I love the visual studios IDE and especially the
integrated debugger. It beats everything I've ever seen built on top
of gdb in terms of usability and power IMHO.
J
James Kanze
It depends. On most platforms, the "native" development tools
(VC++ under Windows, g++ under Linux, Sun CC under Solaris,
etc.) are generally "professional". On a lot of platforms, g++
is professional, even when it isn't native, and from what I've
heard, Intel's compilers are professional as well. I don't
think you can make any blanket statements any more. (In a
fairly distant past, free generally did mean not professional,
but that's certainly not the case now.)
Also, in general, Unix tools tend to be more professional than
Windows tools, probably because Windows is the OS of choice for
non-professionals.
J
James Kanze
[...]
Really. I find it one of the worst debuggers I've ever used.
It's constantly driving me up the wall, because I'm unable to
see what I want (where as it's filling up the screen with things
I'm not interested it).
Really. I find it one of the worst debuggers I've ever used.
It's constantly driving me up the wall, because I'm unable to
see what I want (where as it's filling up the screen with things
I'm not interested it).
R
RaZiel
This is really off-topic, but since we write "GCC" in here, it should be
OK
Cool. Yeah it's intuitive and easy to use straight away. I've
encountered the same problem, it may be that during building there are
actually problems, even if the build reports success at the end. Take a
look into the build window (left-most icon in the bottom).
The problem I had was:
g++: 'D:\Program: Invalid argument
g++: Files\wxWidgets-2.8.10'.: No such file or directory
Problems with whitespace in the path.
Aside from CodeLite hickups, I'm really impressed by wxWidgets and the
wxFormBuilder. Good luck!
- RaZ
C
crea
RaZiel said:This is really off-topic, but since we write "GCC" in here, it should
be OK
Cool. Yeah it's intuitive and easy to use straight away. I've
encountered the same problem, it may be that during building there are
actually problems, even if the build reports success at the end. Take
a look into the build window (left-most icon in the bottom).
The problem I had was:
g++: 'D:\Program: Invalid argument
g++: Files\wxWidgets-2.8.10'.: No such file or directory
Problems with whitespace in the path.
Aside from CodeLite hickups, I'm really impressed by wxWidgets and the
wxFormBuilder. Good luck!
yes, if I press the "Build active project", I get sometimes: "error:
wx/image.h: no such file or directory"
But the funny thing is that if I right click on my project name on Workspace
and select "rebuild all" it says that build is successfull.
C
crea
RaZiel said:
yes. Do I possibly have to add some paths to "Environment Variables"? I had
cygwin before this, and this had to be done for it.
A
Andre Kaufmann
Since it's some years ago, since I had a deeper look at Unix development
tools, I wonder if there are now IDE based C++ development tools
available, besides Eclipse / KDevelop ?
Could you give an example, where a professional than Windows, Unix
debugger is easier to handle ?
(Besides ... I don't know why you make a difference between Windows /
Unix / Mac, since I thought the tools are available under all OS's?)
E.g.:
In VStudio I right click a variable - select add watch and the variable
will be displayed in the watch window, every time the debugger stops and
if the variable is visible (either globally or on the current stack).
How can that be done easier or more professional under your favorite
Unix tool.
Additionally if I add a STL variable the variable will be expanded
appropriately: E.g.: std::string s = "hello" will be displayed as
s: "hello"
in the watch window.
Don't get me wrong, I like GCC (has evolved a lot and regarding standard
conformance it's ahead of VC), but I sometimes miss the comfort of an
IDE like VStudio under Unix.
Andre
J
Jorgen Grahn
I think it was me (my upthread posting) who made the distinction.
And it was simply because I don't do Windows, so I don't want to
comment on it.
(Also, I'm one of those who don't use debuggers to step through
programs. I just use gdb for post-mortem debugging. And I don't see
the point with IDEs beyond what Emacs does. But those topics have been
beaten to death here many times already.)
/Jorgen
J
Juha Nieminen
red floyd said:
Not a month goes by without someone saying here that they use VC++ 6.
What is so special about that compiler in particular that it seems to be
so universal? I don't get it.
D
Dombo
Op 05-Mar-11 19:55, Andre Kaufmann schreef:
Or just let the mouse pointer hover near a variable name in your source
and it shows its current value. Over the years I have had very few
issues with Visual Studio debugger; I wonder how they could make things
even more simple. OTOH its editor, and specifically code completion, is
another story. Extensions like Visual Assist do exist for a reason.
Or just let the mouse pointer hover near a variable name in your source
and it shows its current value. Over the years I have had very few
issues with Visual Studio debugger; I wonder how they could make things
even more simple. OTOH its editor, and specifically code completion, is
another story. Extensions like Visual Assist do exist for a reason.
D
Dombo
Op 06-Mar-11 8:55, Juha Nieminen schreef:
It was quite popular in its heyday, and the step to the next version of
Visual Studio was a big one. One of my clients spend over a manyear to
port their code (about 2 million lines) from VC6 to VS2005.
It was quite popular in its heyday, and the step to the next version of
Visual Studio was a big one. One of my clients spend over a manyear to
port their code (about 2 million lines) from VC6 to VS2005.
M
Marc
Andre said:
Pretty-printing of STL types is available in gdb, it uses some python
scripts (the STL one is shipped with libstdc++) so you can add
pretty-printers for your own types if you want to. So I guess it is
available in IDEs as well.
J
Jorgen Grahn
Yeah. As I recall it (as a not very interested observer) Microsoft did
VC6. And then they focused on Java, then on .NET and C# and that
bastard C++ for .NET for many years. When they started releasing good,
conforming C++ compilers, it came as a complete surprise to me.
/Jorgen
J
James Kanze
I don't know. All of the IDE's I've used (especially Visual
Studios, but that may be only because I've used it much more
than the others) have been very counter productive. Even when
developing under Windows, may primary development environment is
vim/bash/msbuild. About the only time I do use an IDE is when I
go into the debugger, which isn't that often. (Under Unix, I
use it even less, because tools like valgrind are often more
effective.)
What do you mean by "easier to handle"? For most things, most
of the IDE debuggers are pretty much equivalent. There are
things that the Unix debuggers do better, but generally, their
big advantage is that they are based on a more powerful
debugger, and have a command window which allows using it.
Things like setting breakpoints, getting a stack walkback, and
continuing from a breakpoint are about the same with all
debuggers I've used. On the other hand, gdb will always show
the return value when stepping out of a function, and it's easy
to display an arbitrary expression with gdb---it's much more
painful with the MS debugger. As it happens, those are two of
the most frequent things I need when debugging live code. (One
of the most frequent uses of a debugger under Unix is post
mortem debugging. Which isn't possible under Windows, but
that's not the fault of the debugger.)
Debuggers are linked with the build chain tool set. Gdb is
available under Windows, but it isn't effective for debugging
programs compiled using VS.
And you get a completely new window, hogging up screen space, so
you have to dock it and resize it very small (since all your
interested in is one variable). And of course, a lot of the
time, you want an expression that is more complicated than just
a simple variable, and most of the time, you really only want it
once. Doesn't matter, you need to go through I don't know how
many menus, open up a new watchpoint window, then go into it,
and type the expression. And then dismiss the window.
Just type in "disp <expr>" under gdb. For any arbitrary
expression. "disp " is less keystrokes than you need mouse
clicks to open a watch window, and you don't even have to take
your hands off the keyboard.
Not in the configuration I'm using. But both in VS and gdb, you
can configure it to do so, using plugins (VS) or scripts (gdb).
I currently develop mainly under Windows, and I regret having to
use an IDE for some things. It slows me down considerably.
Ö
Öö Tiib
Post-mortem debugger "Dr. Watson" has been available under Windows
like for two decades ... i think. The Windows tools are certainly not
worse than anywhere else, but setting them up is not so easy.
MS itself writes major stuff in C++ so they need and so there are good
tools. From others they expect C# so the C++ tools are delivered to
audience bundled into pieces of shit they call "toolset"s, "API"s,
"development kit"s etc. Better tools are perhaps integrated into their
most expensive version of visual studio. Some are not integrated at
all. Normal Windows developer has therefore to download various pieces
from Microsoft site and salvage, combine and integrate the tools from
these to get viable toolset for development.
D
Dombo
Op 06-Mar-11 12:39, Jorgen Grahn schreef:
....and a pleasant one for a change...
....and a pleasant one for a change...
A
Andre Kaufmann
Well, I think there are basically 2 kinds of developers. One group likes
IDE based development more, one console based development.
Since I like IDE based development, I don't care that much about using
vim/vi etc., though I like the speed of command line tools.
I tried to use such tools too, but I frequently forget the command line
instructions of the debugger / compiler and therefore deal more with
reading documentation than writing source code.
Drivers, for example, are developed under Windows from the command line
too. (there must be many former Unix/VMS developers doing core
development at Microsoft ;-) )
There is an immediate mode in the IDE and for example the free Windows
Debugger is more command line centric (and much more powerful than the
one shipped with VStudio - but IMHO more complex to understand, since
there are much more commands to know - just like in GDB)
I sometimes have the impression, that developers in both "worlds" (Unix,
Windows) don't know that much about the "other world". I frequently try
to be up to date what's going on under Linux (Unix) regarding
development tools. But unfortunately, getting a deep knowledge about the
development tools needs just too much time.
I too like the speed of command line tools, but I miss the comfort of
the IDE, so I prefer IDEs and "live" with some downsides.
The MS debugger (all of them I know) shows the return values too.
Well, I know that argument. I'm told this frequently and Unix developers
are then astonished, when I tell them that post mortem debugging is
built in the OS for years (at least in all Windows NT operating systems).
It's Windows Error Reporting, former Dr. Watson., which takes a snapshot
and optionally sends the dump to a server to Microsoft.
Normally such dumps are not saved (if there are no OS specific
informations about the crash). A company can register it's applications
and download crash information from a Microsoft server.
But the "more professional" users surely don't like information to be
sent to a server, so for example I've implemented my own crash handler
in our application.
With this crash handler we are able to send information to our servers
or optionally
get a live debugging dump (same as the crash dump).
This is quite handy to debug deadlocks (where no crash dump is written).
It's even possible to connect with Visual Studio directly to our
applications and directly debug the snapshot in the IDE. (if we are
allowed too, since it's disabled by default, and know the password for
the system)
Yes, but there are multiple debuggers.
If you like GDB, then you perhaps like the (free) Microsoft Windows
Debugger for debugging Windows VStudio compiled applications, since IMHO
it's comparable with GDB (though it's too using Windows, but is more
command line centric)
I didn't use GDB for Windows that much. But I think it doesn't support
PDB debugging file format, so I agree it's you can't professionally
debug Windows applications compiled with VStudio with GDB.
But I think the reason for that is that there's no standard (no one
which is used for all operating systems) for C++ ABI and debugging
information.
You have different options:
- Hover with the mouse pointer over the variable: Output is displayed
in a small popup
- Add watch: Variable will be added to a >single< watch window
- Add quick watch: Opens a new window (as you described)
- Pin to source: Add a small watch window directly in the source
(which I find quite cool - since the information is only displayed
when and where needed)
- Use the "command line immediate window" and enter
? variable
to get the value.
It's the option "add quick watch" which opens such a Window. I don't
like this option too and I prefer the other ones, I listed above.
My version I'm using (2008/2010) is displaying STL objects expanded
nicely by default.
The new tool chain, VC 2010, is based on MSBuild completely. So using a
text editor and Windows Debugger command line based developing should be
possible too (with all compilers).
But since this is not main stream (as under Unix) I don't think it's a
good way to go.
Andre
A
Andre Kaufmann
I not used this extensions by myself, but what I read from the
documentation, that there are commands for each STL container, so you
have to know if it's a list, a map etc.
Is there an option to pretty-print each stl container, without knowing
it's exact type ?
Andre
J
Jorgen Grahn
But that's not how you do it! You use your shell's/application's
history feature to search back in case you have forgotten the exact
command-line for doing something.
And you almost never run the compiler yourself -- you write a Makefile
(or equivalent) which contains the details of how to build.
And finally, since you speak about "console-based": it's not a
distinction between a full-blown IDE and a single 1970s terminal --
every programmer I know uses a windowing system, and graphical tools.
....
That is a fact. I'm sure I haven't understood the attraction of IDEs
myself.
/Jorgen
J
James Kanze
I don't think it's that simple. There are just so many things
that you can't do with an IDE; that require entering text. For
starters, if when entering source code, you had to choose each
letter from a menu, you'd soon get very frustrated. Or when
doing a global search and replace, using regular expressions:
you still have to type in the regular expression. All of this
means that most of the time, your fingers are in the base
position on the keyboard. And that you can type in about twenty
characters in the time it takes your hand to get to the mouse
and back.
I like the mouse when I'm just browsing, without any specific
goal in mind. Or when I'm dealing with a graphical
representation, like UML. Otherwise, however, I don't like
having to move my hands from the base position on the keyboard.
It costs too much in productivity.
In the case of the debugger, I'm often in the same case, because
I don't use it that often. Still, typing in "help" takes less
time than searching through untold menus.
I used to think that was true. And since I've been working
under Windows, some things have surprised me. But although I'm
beginning to know (and understand) the Windows world, I'm still
far more productive under Unix. And that's true for the vast
majority of programmers I've worked with.
Sometimes. Sometimes not. I've not been able to make it show
them systematically, everytime I step out of a function. And
since I use a fairly functional style of programming a lot,
that's a killer in my book.
I'm glad to hear it. But where does it put the core dump. And
why don't any of the Windows specialists where I work know about
it.
You mean I have to go through Microsoft to get a core dump?
Unless you send the program a signal to tell it to crash
.And the crash happens on your machine, and not the user's (where
no Visual Studios is installed).
Definitely. Even under Solaris, I'd use Sun's debugger with Sun
OS, and gdb with g++. Which is a pain.
I'm rarely interested in a variable; I want an expression. (As
I said, my style is often functional, and there just aren't many
variables.)
That's the one I didn't know. How do you activate it, and can I
enter an arbitrary expression?
I'll give that a try. It sounds like what I'm looking for.
There are some scripts which are pre-installed. I'm using 2005
(for the moment), and I don't have them. Sounds like yet
another argument to move to 2010. (They aren't lacking: for
starters, 2005 doesn't handled dependency checking correctly, so
it doesn't always recompile all of the necessary files.)
So I've heard. And a lot of us are eager for it. Because we
need more complex build rules than are possible with the 2005
build system. (To build one of our projects, we first have to
compile an executable which generates some of the code.)
If it really works, it sounds like you'd get the best of both
worlds. Use an IDE when it's convenient, but have full access
to all of the power of the system when it's not.
As I say, we're waiting. (The technical people don't get to
make all of the decisions, and we'd have to synchronize the move
accross a number of different groups. It will come, however.)