Re: STL bitset class slow..
On Mar 5, 6:55 pm, Andre Kaufmann <akinet#remo...@t-online.de> wrote:
On 05.03.2011 13:27, James Kanze wrote:
On Mar 5, 3:34 am, Joshua Maurice<joshuamaur...@gmail.com> wrote:
[...]
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.
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).
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 ?
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.)
Could you give an example, where a professional than Windows, Unix
debugger is easier to handle ?
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.)
(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?)
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.
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).
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.
How can that be done easier or more professional under your favorite
Unix tool.
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.
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.
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).
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.
I currently develop mainly under Windows, and I regret having to
use an IDE for some things. It slows me down considerably.
--
James Kanze