IntelliSense, Part 2 (The Future)

BioSensorAB » IntelliSense, Part 2 (The Future)

BioSensorAB » IntelliSense, Part 2 (The Future) — Fri, 29 Feb 2008 21:03:29 GMT

PingBack from http://www.biosensorab.org/2008/02/29/intellisense-part-2-the-future/

re: IntelliSense, Part 2 (The Future)

Sys64738 — Fri, 29 Feb 2008 21:19:07 GMT

I think that you are going to do a *great* work for VC++ IDE! I hope you really do "10 is the new 6" :-)

One thing you could implement with your SQL-based system is the following: make it possible to query the DB resulting from parsing the C++ source code, for things like: "give me all ANSI strings in this source code file", so a macro could convert all the ANSI strings in source code into Unicode version (decorating them with L"..."), or decorate them with _T("...").

C++ development will speed up with the use of SQL Server Compact

Steve Lasker's Web Log — Fri, 29 Feb 2008 22:35:50 GMT

Jim Springfield, an Architect on the Visual C++ team has just posted a great example of how SQL Server

C++ development will speed up with the use of SQL Server Compact

Noticias externas — Fri, 29 Feb 2008 23:16:38 GMT

Jim Springfield, an Architect on the Visual C++ team has just posted a great example of how SQL Server

re: IntelliSense, Part 2 (The Future)

phrosty — Sat, 01 Mar 2008 00:33:19 GMT

cool :) i will be looking forward to this.

re: IntelliSense, Part 2 (The Future)

Steve Nuchia — Sat, 01 Mar 2008 01:55:42 GMT

Several things occur to me reading this.

One, I'm pretty sure you know this but files can be included more than once in a translation unit and their effects can be different each time. You used the singular in your article.

On a related point, we have some legacy code with oddball names for included code chunks. When we browse into one of those files it isn't treated as C++ even though the compiler and intellisense have both parsed it recently. That is probably not something you'll want to change but it violates the principle of least astonishment, at least for me.

The other issue is that good intellisense is *more* important for broken code than it is for working code. If you can make that work properly I'll finally start believing IDEs may have a future :-) Whatever "properly" means in the context of broken code. What I mean is that it helps me understand the cryptogram the compiler emitted and investigate how it might be fixed. Giving me the wrong expansions for all the DLL import/export and UNICODE and X64 conditional macros does not help at all. Failing to provide intellisense / browse functionality for a source file that doesn't scan is better but still not optimal.

It would be an *enormous* help if I could get a "preprocessed" view of my file without having to check out and modify the project file, recompile the translation unit (including finding it in the tree view if the error navigation took me straight to the header), browse to $(IntDir) and find the .asm file, search for the right spot, and then remember to undo my change to the project file before checking in.

And while I'm here, any chance of fixing the bug that causes the permanent hourglass when you right-click in a source window while intellisense is restarting after a build? The window for that bug may be small on the toys you guys compile in your labs but with 4+ million lines of code in 200+ projects in one solution you could drive a bus through it. The only recovery is to kill the process and start over.

OK, one more thing related to source browsing: When I fix an error reported in the 3-hour-long full build and do my check build on the modified sources, my full build log is gone. I have to nurse it along, trading off the need to test my changes incrementally against the need to fix more than one error per day. There should be a way to push-and-pop the log or perhaps numbered output windows like you have for find.

Related but less fatal: when you double-click on an item in the Errors window it syncs the "Build" output window but not the "Build Order" output window. When you have 40,000 lines of build output it can take a while to locate the error you were working on.

And one more thing :) select-and-copy are a bit funky in the build output windows. It seems to often take more than one try to get a good copy in the buffer to paste from. But that could be a VMware issue.

Yes, I know, Team Build fixes all ills. Except it doesn't work with third-party compilers (Intel Visual Fortran, in our case) and we're still porting and are weeks away from being able to build everything. It doesn't make much sense to start producing 2000 work items per build right now.

Thanks for listening!

-steve

re: IntelliSense, Part 2 (The Future)

mos — Sat, 01 Mar 2008 02:16:26 GMT

Any chance this will help out with general C++ code editing? I'm specifically comparing it to C#, where the IDE is just a dream to work with.

For example, if I type:

MyClass c = new

the compiler will pop up a little window that contains the line:

MyClass();

and all I have to do is hit enter. (It also helps me type "new", "int", and "MyClass".) This sort of user friendliness is <i>all over</i> C#, and I really miss it when I do my C++ work.

re: IntelliSense, Part 2 (The Future)

Sys64738 — Sat, 01 Mar 2008 02:32:08 GMT

mos: You should really try Visual Assist X: it is great for C++ !

re: IntelliSense, Part 2 (The Future)

Steve — Sat, 01 Mar 2008 12:11:22 GMT

Has anyone checked out the Eclipse CDT project?

I've heard it handles this sort of stuff really well

re: IntelliSense, Part 2 (The Future)

PierreMF — Sat, 01 Mar 2008 16:07:38 GMT

Using a SQL database as a code reference is a great idea (IMHO). It could be used for code refactoring for example, or all these C# available features that are missing in the C++ IDE (as Mos says, above).

Also, you say that "SQL Server Compact is very small and efficient, while retaining the flexibility of SQL". Yep, I agree with that. But using SQL Server Compact in native code is not easy at all... You know that since you've done it.

Using SQL Server Compact could be usefull in many native C++ applications (it is in Visual C++ IDE ! ;)). But there is nothing in the MFC to use it. Not even a sample.

re: IntelliSense, Part 2 (The Future)

Peter — Sat, 01 Mar 2008 18:39:11 GMT

Firstly, I have no idea why you're tooting your horn on getting rid of the ncb file if all you really mean is that you're taking on totally opaque file and replacing it with another totally opaque file.

Secondly, the most useful thing to me is if you honored the 'OutputDirectory' or 'InternediateDirectory' settings in my project. I tend to do development on a flash drive (why? because!, that's why!). It's set up to drop all of the large, constantly changing files onto a temp directory on the real hard drive -- except that I can' redirect the huge&slow ncb file. Which is constantly being 'rebuilt'.

Thanks,

Peter

re: IntelliSense, Part 2 (The Future)

Qwe — Sat, 01 Mar 2008 19:52:13 GMT

All I can suggest Jim, and I know you guys are having a tough time is to approach the C++ community out there (especially on Windows and it is still big and very dissapointed with .NET bloatware after it was used and sold for the last 7 years) is:

Get, some, funding.

Don't, buy, other, companies.

Put, money, into VC++ team.

Employ, more, people.

Talk, to, Bill and Steve.

Engage, the, community.

Don't, fight, Boost.

Open, up, the, compiler.

re: IntelliSense, Part 2 (The Future)

Bill — Sun, 02 Mar 2008 00:41:14 GMT

With the in process database I don't see much improvement over the current situation (other than it could be more performant), but an out of process sql server session could be incredibly powerful; so long as you detail the specification and have it under a license which allows others to use it. Not only would it be able to do the things you described (after weaving it with TFS), but with some extensions it could do much more powerful things like:

scan your code for possible cases of derefrencing null pointers;

make sure objects instantiated with the new keyword have a cooresponding delete;

point out possible stack/buffer overflows;

discover redundant code;

find similar code

re: IntelliSense, Part 2 (The Future)

fdsa — Sun, 02 Mar 2008 17:58:35 GMT

i totally disagree with your statement "The other issue is that good intellisense is *more* important for broken code than it is for working code".

in general coding is putting new code around functions to glue some existing code from an _established_ codebase/toolbox/library that one, a coworker or 3rd party wrote before. because one doesn't remeber the exact parameters and functions one uses intellisense to look them up.

but the new code that you are writing and that get "broken" by editing it at the moment is definitely in your "zone". being in that "zone" means you remember every bit and don't need intellisense for editing it.

that's why i would expect that intellisense should only provide information about the established codebase. but this information should be exact and all macros in the translation unit should be handled as the compiler does.

why don't you just parse the already preprocessed c++ code that is passed to the compiler by redirecting a copy of it???!?

re: IntelliSense, Part 2 (The Future)

dataland — Sun, 02 Mar 2008 18:21:22 GMT

Jim,

thank you for the great post (as usual). I see massive potential with MS VC++ and i'm glad you are in the thick of it!

PierreMF,

I hear you on the lack of info on using sqlce with mfc. I spent far too long figuring this out (and ended up using non-microsoft provided details on how to do it: sad but true). i've complained to deaf MS ears so i'll say it again: Microsoft please provide more *NATIVE* MFC C++ sample code for new technologies.

Qwe,

I agree with you 100% well said!!

Bill,

I also agree that your proposed (cutting edge) features would be hugely beneficial. I wish MS invested more in quality & useful VC++ features and less on .NET bloatware.

re: IntelliSense, Part 2 (The Future)

dataland — Sun, 02 Mar 2008 18:33:18 GMT

Jim,

thank you for the great post (as usual). I see massive potential with MS VC++ and i'm glad you are in the thick of it!

PierreMF,

Qwe,

I agree with you 100% well said!!

Bill,

I also agree that your proposed (cutting edge) features would be hugely beneficial. I wish MS invested more in quality & useful VC++ features and less on .NET bloatware.

Oh yeah!

QbProg — Mon, 03 Mar 2008 10:39:16 GMT

It would be nice to have such a level of intellisense.

I too prefer to have "broken code" to work , since many times to get intellisense in a new function you are writing you should complete the main prototype and then wait a bunch of seconds...

There are many other things I'd like to see in VC++ 10 , but here these are off topic

re: IntelliSense, Part 2 (The Future)

Jim Springfield — Mon, 03 Mar 2008 21:46:46 GMT

Thanks for all of the comments everyone.

There are a few comments regarding using SQLCE from C++. We are using the ATL OLEDB consumer templates and it has been fairly easy. ATL and MFC are pretty integrated today, so it should be fairly straightforward to use them if you are an MFC user, although I don't know offhand what the MFC databinding story is with ATL OLEDB.

Peter: The goal is not to have an opaque file, especially one that is difficult for us to maintain and change. You can actually load the SQLCE SDF file into Visual Studio and explore it, and issue SQL queries against it. I imagine there will be some interesting addons that exploit it. One point I am driving hard here is that we need to make some things much more configurable. Your suggestion about being able to specify a location for the store is a great one. It would also be useful in the case of opening a project over a network share that you don't have write access to.

Steve: I hear your point about how a header can be included multiple times into a single translation unit. We will see it both ways when doing the full parse of a translation unit. An interesting question, however, is if the editor has the header itself open, what context should be used when editing it? My experience with these types of header, however, is that they are typically some kind of heavily macroized structured "data" that will expand into code and/or data when included. I doubt that Intellisense is actually very useful in this case, but I would be open to hearing some examples.

Bill: I also see the value in an out-of-proc mechanism and it is something we want to support. However, we also have users in some organizations that are restricted from installing SQL on their own machines and insert performance is very good for SQLCE. However, the code as written today can actually target full SQL as well as SQLCE. We aren't sure what we will provide in VC10 around this, but we believe it could be very valuable.

I believe Intellisense needs to work well in both code that compiles and code that doesn't. Obviously, it can't read your mind about what the code is supposed to do, but we are trying to design our parsers to be very resilient to the types of errors that are likely to be seen on code that is being actively written such as mismatched braces/parens, etc.

We do have plans to provide other features similar to what C# provides today that we hope will increase coding productivity. This set isn't 100% firm yet, but we do hear you.

re: IntelliSense, Part 2 (The Future)

Steve Nuchia — Mon, 03 Mar 2008 22:42:12 GMT

> what context should be used when editing it?

How about a dropdown list in the title bar of all the insertion sites, constructed so I can see project, translation unit, and #include line and file. Hmm, maybe that would have to be a popup, it's really a lot of info. The selection would drive colorization, intellisense, and ctrl-F7. Yeah!

But when headers include other headers and you get an error deep in the nest, the IDE gives you very little help in navigation. Something like a debugger call stack window would help a lot. My typical work cycle is to double-click an error message, then return to the Output window and scroll back, noting the .CPP file name as I go, until I find the project name announcment line in the output. Switch to the Solution explorer, navigate to that project, open the "Source Files" filter, and scroll down to the right .CPP file. Now, if I'm lucky, the #include is a direct one and I've got most of what I'm going to need. If not I have to use a combination of Zen and brute force to find the #include trail connecting the two files I have open.

fdsa: When I'm writing new code I'd agree with your point of view. Right now, however, I'm in a porting situation and code I didn't write is being broken by changes I didn't make to code and meta-code burried deep in the header jungle. For this kind of work I really need intellisense (mostly tooltips and browse-to-defn) that groks preprocessor semantics and can cope with multiple incompatible definitions in scope and missing definitions and all that sort of brokenness.

re: IntelliSense, Part 2 (The Future)

Norman Diamond — Tue, 04 Mar 2008 06:51:57 GMT

> what context should be used when editing it?

If there's a macro definition in the project properties (/D on the command line) then that should be respected in colouring the #if and #else blocks. Also (and more importantly) if there's a #define in the file itself then that should be respected.

But if the #define comes from a parent file and the situation isn't known in the included file itself, it's tough. Maybe both the #if and #else parts should be coloured as usable code, but it's still tough. A macro could expand to either of two possibilities, and which expansion should be recognized? Tough question. But the other cases were simpler and they should be handled properly.

re: IntelliSense, Part 2 (The Future)

marcel — Wed, 05 Mar 2008 21:24:28 GMT

I second Visual Assist X, it is way better, ms should buy it or make one like that, it is much faster and gives better suggestions

re: IntelliSense, Part 2 (The Future)

mikeb — Thu, 06 Mar 2008 01:14:50 GMT

> It would be an *enormous* help if I could get a "preprocessed" view of my file without having to check out and modify the project file, recompile the translation unit (including finding it in the tree view if the error navigation took me straight to the header), browse to $(IntDir) and find the .asm file, search for the right spot, and then remember to undo my change to the project file before checking in.

This is a very good idea. I don't often have to delve into debugging the preprocessor, but when it needs to be done something like the suggestion above would be very handy.

Intellisense: big change in next visual studio

Omnitechie — Fri, 07 Mar 2008 05:57:32 GMT

Intellisense: big change in next visual studio

re: IntelliSense, Part 2 (The Future)

Christophe Pichaud — Sun, 09 Mar 2008 07:15:12 GMT

I think in fact, SQL light storage is the most eficient way.

In a recent post, I was thinking about ADAM because of its superiority in terms of the couple storage/search&criterions.

but OK, let'go with SQL. It will easier to write.

great job guys.

regards,

christophep

re: IntelliSense, Part 2 (The Future)

RichardG — Sun, 09 Mar 2008 16:15:17 GMT

- Developing in a codebase with a lot of boost headers and templates means my translation units often take 10-50 seconds to compile. Do you account for this when you run the full background parse?

- Have you investigated using the information as a hint to the compiler? Faster builds would be most welcome.

- Does the new intellisense still crash or hang the machine? Can we reboot intellisense when it breaks? We need reliability.

- I am interested in third party add-ins for the new Intellisense. If it's open enough, I think this could be the best feature of VS10.

Best of luck with development, I look forward to using it!

re: IntelliSense, Part 2 (The Future)

Twain — Mon, 10 Mar 2008 08:47:07 GMT

Jim,

Your planned use of SQL Server Compact Edition with the OLE DB Consumer Templates for ATL is intriguing. My hope is that several things flow from this effort (in addition to the higher performance Intellisense, of course). First, maybe Microsoft will make available these interfaces (OLE DB) for Windows Mobile developers, recognizing that not everyone wants to use ADO.Net and C# for applications with database connections. Second, it will be a useful learning experience if the MSDN magazine publishes code snippets in C++ that illustrate how you guys are using the consumer templates. Third, hopefully the MSDN website will publish more C++ examples on how to use OLE DB. All of this points to the fact that if the Visual C++ developers are using C++ to interface with SQL Server Compact edition, why wouldn't other developers want to do the same on the Windows Mobile platform? Thoughts anyone??

Thanks,

Twain

re: IntelliSense, Part 2 (The Future)

Scott Colcord — Thu, 13 Mar 2008 04:53:09 GMT

"The parser is also designed to be extremely resilient and will be able to handle ambiguous code, mismatched braces or parentheses, and supports a 'hint' file. Due to the nature of C/C++ macros and because we aren’t parsing into headers, there is good bit of code that would be misunderstood. The hint file will contain definitions for certain macros that fundamentally change the parsing and therefore understanding of a file."

Hmm...ever heard of an OO toolkit from about 10 years ago called 'Genitor'? It used pretty much this exact approach to reverse-engineer C++ code.

re: IntelliSense, Part 2 (The Future)

Steve Nuchia — Mon, 24 Mar 2008 18:42:24 GMT

One thing that would be nice to have "while you're at it" in the database: If you would provide for storage of historical / statistical / estimation(?) data on the build times for projects and translation units it could be used by the parallel build scheduler to do a much better job.

As it is, the scheduler will frequently end up building a "large" project (or dependency chain) single-threaded at the end of the job. If it had data on build history it could push the prerequisites for that project forward and get better overall build performance. Statistics on individual translation units wuold be needed to do this for incremenatal builds.

Making the "units" for this performance data somewhat insensitive to platform scale would help if it will be possible to share the database among team members: we don't all have the same vintage machines.

re: IntelliSense, Part 2 (The Future)

Qwe — Tue, 25 Mar 2008 16:26:59 GMT

Why do you guys keep the OLE DB wizard source closed anyway? It makes code gen useless for C++ devs and ADO.NET is just a hack plenty of companies refuse to use.

I agree you have a tough time ahead with Intellisense and editors (which should be CLR like fuzzy work anyway), but look around and you'll find guys with great AST ideas for C++ (apart from EDG etc).

My main worry is that you guys are underfunded in C++ land, all while we are seeing 300MB silly SilverLight and WPF apps that will never ever make any business sense, not in the next 10 years for many, many app.

If CLR team could just get their act together and polish up page faults on GDI+ and get it into harware acceleration, you have a fast enough environment to do all the editor work.

But that's a whole different topic and project to compiler, it being better exposed for preprocessing/introspection/code-gen/optimisation/etc/etc, and the idea you ought to have it opened up so it can shine with integration that managed crowd would never understand anyway (they are ignorant enough as is)..

re: IntelliSense, Part 2 (The Future)

Leo Treggiari — Mon, 31 Mar 2008 22:57:36 GMT

With IntelliSense improving, wiil the VC++ product continue to support generating Browse Information (.bsc files)? If so, what will Browse Information do that IntelliSense won't?

Thanks,

Leo

re: IntelliSense, Part 2 (The Future)

Noran — Tue, 01 Apr 2008 17:41:49 GMT

I never doubt that Visual C++ team can do a better job than Visual Assist X. But all these years , from vc 6.0 to vc 9.0, I have to pay some dollars to get a license of VAX, just because I hate to press Alt + ->

"Best of luck with development, I look forward to using it!"

re: IntelliSense, Part 2 (The Future)

sidinsd — Tue, 22 Apr 2008 19:21:00 GMT

Is there a way to customize the Quick Tips tooltips that Intellisense displays when you hover over a method's name?

My Visual Studio vNext wish list

Granville Barnett — Mon, 04 Aug 2008 13:21:20 GMT

My wish list for Visual Studio vNext isn't that long. The things I would like to see in Visual Studio

My Visual Studio vNext wish list

Granville Barnett — Mon, 04 Aug 2008 13:21:44 GMT

My wish list for Visual Studio vNext isn't that long. The things I would like to see in Visual Studio

Dev10 Is Just The Beginning

Visual C++ Team Blog — Tue, 27 Jan 2009 19:49:57 GMT

Hello, I’m Mark Hall, an architect in the Visual C++ group. I wanted to follow up on Jim Springfield’s

Rebuilding Intellisense

Visual C++ Team Blog — Wed, 27 May 2009 19:34:39 GMT

Hi, my name is Boris Jabes. I've been working on the C++ team for over 4 years now (you may have come