Re: STL bitset class slow..
On Mar 8, 10:48 pm, Andre Kaufmann <akinet#remo...@t-online.de> wrote:
On 07.03.2011 23:11, James Kanze wrote:
On Mar 7, 8:02 am, Andre Kaufmann<akinet#remo...@t-online.de> wrote:
On 06.03.2011 13:36, James Kanze wrote:
[...]
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.
Agreed, but I don't see the difference controlling VI / VIM by keyboard
or VStudio by keyboard ? [o.k. VIM should be faster and perhaps more
responsive ;-) - but besides that point ?]
If you could control Visual Studio from the standard keyboard.
None of the experts where I work seem to be able to control it
without having to use function keys, or otherwise move their
hands from the standard position.
(Of course, there's also the issue that Visual Studio, at least
2005, is broken. It seems like I spend half my time doing full
rebuilds, because it won't compile all the object files whose
sources have changed. And I've had to create a couple of
separate, one file projects, because I need to build a small,
local program to generate part of my 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.
Yes I know what you mean, though I think the browser it's
commonly the fastest tool to get any information quickly ;-) -
at least under Windows.
In general, I find a GUI preferable for the tools you rarely
use, and a command line interface preferable for the ones you
regularly use: if you don't know the command, it's probably
faster searching through a well thought out menu hierarchy than
searching through the manual. So logically, I'd favor a GUI for
the debugger. But the VS debugger seems to go out of its way to
make it difficult to do one or two of the more common tasks.
(Not all of them, of course.)
[...]
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.
Depends, if you debug applications built with release
configuration then yes, commonly you won't see the return
values, since the functions don't exist anymore, because they
have been removed by the global optimizer. But I don't think
that is different under Unix - is it ?
None of the debuggers are very good with optimized code. They
could all be better.
For debug builds I hadn't that much problems, rather with
automatic stl expansion in combination with complex template
classes.
I've yet to figure out what I'm doing differently, but
sometimes, I do see the return values. Most of the times not,
however.
But I often get the feeling that the debugger is not
deterministic. Some of my work is on Excel plug-ins. For over
a year, I've been starting Excel, attaching the debugger to the
process, and debugging from there. That's the way my collegues
showed me to do it. Sometime recently, however, that stopped
working. Now I have to specify Excel as my binary, and start it
from the debugger. (On the other hand, I can still debug the
Java plug-ins by attaching to the running Java process. Va
comprendre.)
I'll have to try your other suggestions at work.
--
James Kanze