Re: STL bitset class slow..
On Mar 7, 8:02 am, Andre Kaufmann <akinet#remo...@t-online.de> wrote:
On 06.03.2011 13:36, James Kanze wrote:
On Mar 5, 6:55 pm, Andre Kaufmann<akinet#remo...@t-online.de> wrote:
[...]
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.)
Well, I think there are basically 2 kinds of developers. One group likes
IDE based development more, one console based development.
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.
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.
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.
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 ;-) )
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.
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 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.
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.
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,
The MS debugger (all of them I know) shows the return values too.
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.
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.)
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).
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.
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.
You mean I have to go through Microsoft to get a core dump?
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).
Unless you send the program a signal to tell it to crash:-).
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)
And the crash happens on your machine, and not the user's (where
no Visual Studios is installed).
Gdb is
available under Windows, but it isn't effective for debugging
programs compiled using VS.
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.
Definitely. Even under Solaris, I'd use Sun's debugger with Sun
OS, and gdb with g++. Which is a pain.
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 different options:
- Hover with the mouse pointer over the variable: Output is displayed
in a small popup
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.)
- 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.
That's the one I didn't know. How do you activate it, and can I
enter an arbitrary expression?
you have to dock it and resize it very small (since all your
interested in is one variable).
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.
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.
I wonder why this is more complex than entering: ?<expr> in the
immediate window?
I'll give that a try. It sounds like what I'm looking for.
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).
My version I'm using (2008/2010) is displaying STL objects expanded
nicely by default.
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.)
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.
The new tool chain, VC 2010, is based on MSBuild completely.
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.)
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.
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.)
--
James Kanze