OT: MSVC goodies (was Re: [Alephmodular-devel] 0.3 current status)

[Woody Z. I. <woo...@sb...>]

On Thursday, January 9, 2003, at 12:16  AM, Joe Auricchio wrote:

> Hm. Is it just me, or does MSVC just suck in every way imaginable? Is 
> there anything it's GOOD at?

There are certainly some technical drawbacks, but from a user's 
standpoint (as a developer) the IDE has some really nice features:

1.  It "reads over your shoulder" and tries to help.  For example...
a.  when you type "get_shape_descriptor(", it pops up a little ToolTip 
with get_shape_descriptor's formal parameters, bolding each parameter as 
you walk through them (in your typing).  (If there are multiple 
get_shape_descriptor functions, it says "1 of 3" or whatever next to it 
and lets you cycle through the different prototypes.)
b.  When you type "bitmap_definition->", it pops up a menu of all of 
{whatever type bitmap_definition is}'s data members and methods.  
(Actually, if you're not in a privileged scope, it may only pop up the 
public ones; don't remember.)  Each identifier in the menu is identified 
by a tiny icon as to whether it's a data member, a method, public, 
protected, etc.  As you type the next few characters it refines its 
guess as to which one you mean (or you can use the arrow keys or click 
the mouse).  Once it has it right, hit return or any other 
non-identifier-character key, and it autocompletes.
c.  at any time, hit control+space to attempt to complete the current 
identifier.  This is smarter than Project Builder's "complete:" 
keybinding (if you set one up) since it knows about scoping and about 
identifiers (and their properties) from other source files etc.  Also, 
it uses the pop-up list thing as discussed above, instead of just 
guessing (and getting it wrong half the time) the way PB does.

2.  It has instant "call graph" and "callers graph" support.  So if 
you're trying to learn your way around a big, unfamiliar code base 
(like, say, A1), you can just ask it "What functions call 
get_shape_descriptor?" (I mean, by like clicking on the identifier and 
hitting Alt+F12 or choosing a menu option), and it will show you in a 
new little window.  And each of those functions can also be expanded in 
the tree view to show _their_ callers.  And you can double-click any of 
them to jump to the code.  It's clever enough that if 
initialize_application() calles atexit(shutdown_application), 
initialize_application() shows up in the callers-graph of 
shutdown_application.

3.  Incremental linking and Edit and Continue.  Incremental linking lets 
the linker only reprocess code that needs to be reprocessed, cutting 
link time (after the first build) down substantially.  Edit and Continue 
is pretty cool.  Suppose you're stepping through a function and see that 
it's about to execute some code that does something really dumb.  So you 
just fix it, and Edit and Continue!  The changed code is compiled, 
linked, and patcthed into the currently-executing (but stopped) 
program.  So you keep on stepping through, no need to quit the app, make 
the change, rebuild, rerun, and try to get back to where you were.

4.  Miscellaneous niceties, like if you point at an identifier in the 
code while debugging, it identifies the type and current value of that 
identifier in a ToolTip.  It's also good about, when you right-click an 
identifier and ask to see its definition, actually taking you to the 
right place, and doing it quickly.  In my experience PB is less pleasant 
on both counts (particularly if there are multiple candidates) when you 
command-double-click.  Also in general PB only knows about an identifier 
once you've successfully compiled its file.  MSVC must do some sort of 
real-time online parsing while you're coding; it knows about identifiers 
and their types etc. long before you actually compile your changes.  
Also when you change a header file, MSVC analyzes which other source 
files are actually affected, and will only rebuild those (it won't 
necessarily rebuild every source file that #includes the header).

So yeah, not trying to start a war here...  MSVC has problems 
(especially in the compiler proper), but it has some pretty nice stuff 
too (especially in the IDE).  (You _did_ ask.)  It probably sounds like 
small potatoes, but once you code with the "smart completion" stuff 
kicking in, it's hard to go back to having to constantly be manually 
looking up function prototypes and names of methods and so forth.  It 
takes me well over 3x as long to write a (non-trivial) new function body 
in Project Builder than in MSVC for exactly this reason - the constant 
switching to Internet Explorer or another source file or whatever is 
annoying and distracting and time-consuming.  And maybe there's a way to 
use six command-line tools in a row (probably with special build options 
specified while compiling) to get a text dump of a callers-graph with 
Apple's (GNU's) tools, but having it right at your fingertips in MSVC 
gets you to the code you need to see in seconds.

If you haven't experienced writing and browsing code in MSVC, your life 
is incomplete.  :)  Of course, I would make a similar claim about using 
Apple's (NeXT's) Interface Builder (in Cocoa, anyway... I gather you 
can't instantiate objects and make connections - which is the whole 
point - with Carbon applications).  [Apple's/NeXT's?] Sampler is pretty 
cool too.

Maybe other environments (like CodeWarrior, Forte, etc.) are also doing 
the things I mentioned as MSVC niceties.  Maybe they were even doing 
some of them first.  I don't know.

Woody