2

I am currently creating my own intellisense, and was slightly unsure on a point:

The VS Intellisense can look into referenced DLLs and pull out the namespaces, classes etc from it. Does it do this with reflection? What if I add a DLL made in java (if that can be done?)

for C++, does the intellisense simple scan header files you #include, and find available namespaces, classes etc from that?

I don't fully care about the exact implementation of intellisense in visual studio, but I am interested in how it obtains it's data.

LynchDev
  • 793
  • 1
  • 12
  • 27
  • 2
    .Net and Java and C++ have _nothing_ to do with each-other. What _specifically_ are you asking about? – SLaks Feb 05 '12 at 23:16
  • 1
    I am fairly sure you are going to have to scan the headers. Getting data from binary C++ is going to get difficult(most of your stuff goes away at compile time). –  Feb 05 '12 at 23:22
  • The VC++ IDE just parses the header files, it doesn't look into any binaries. VC# does though but only because .NET assemblies are nearly completely different from normal executables. – Seth Carnegie Feb 05 '12 at 23:25
  • @SLaks: If I am reading the question correctly, the OP is asking *specifically* about all three of them. – kkm inactive - support strike Feb 05 '12 at 23:42
  • @kkm: If so, those are three separate questions that should be asked separately. – SLaks Feb 05 '12 at 23:44
  • Sorry for the confusion, but I am basically looking at how I could implement an intellisense for different languages – LynchDev Feb 06 '12 at 01:43

1 Answers1

1

Compiled .NET assemblies and Java classes contain all meta-information about classes and symbols that they define. Nothing like .h or .lib files is required to link against them. For these types of modules, significant amount information may be extracted directly from them.

I do not know if Visual Studio is using reflection to read metadata from managed assemblies, but reflection is certainly a correct mechanism to apply in this case. But also note that VS displays more information than there is contained in an assembly directly, namely, the /// doc-comments. These may come from source files in other projects in the solution, and from separate .XML files that come with assemblies.

For C and C++, the matter is different. There is little information available in a DLL alone. There are export symbols, but they do not usually signal whether a symbol is a function or just an extrn, and how many arguments and what types the function takes. C++ uses so called "mangled" names, from which some information may be gained. But most information that is available about a library is coming from header files. VS, as far as I know, parses sopurce files of projects and .h files included from code to get intellisense database. There are macros (#define's), and inline and template classes and functions that are not reflected in DLL extern symbols at all.

For both managed and unmanaged assemblies, sometimes debug information PDB files are available. Again, I am not sure, but I think VS is not using them for intellisense. This does not mean that you should not. There do contain extended information about external variables, classes, functions and methods. All in all, there is no "standard" intellisense approach, and you probably should consider using multiple sources for the symbolic source information.

Unfortunately, I do not know much about Java to give a detailed answer to that part of your question. Also, there is a popular IDE framework called Eclipse, but I have not looked under its hood. There must be some interesting parts hidden there, but do your own research.

A few useful references:

  1. Visual Studio SDK. Even if you are not extending visual studio, you may want to read its documentation. It has a section on Intellisense. Also, look at open-source IDEs, such as Eclipse and #develop

  2. System.Diagnostics.SymbolStore Namespace contains classes to access PDB files. In unmanaged world, use DbgHelp library, part of Windows SDK.

  3. A utility called Depends was part of Win32 SDK, and is avalable separately now. It shows externals defined by an unmanaged DLL. This SO discussion reveals a few ways to access this information programmatically. DbgHelp contains functions to un-mangle C++ names, after you extract them from the PE export directory.

Community
  • 1
  • 1
kkm inactive - support strike
  • 5,190
  • 2
  • 32
  • 59
  • Thanks for the reply, this is exactly what I was looking for. Sorry for any confusion in the original post – LynchDev Feb 06 '12 at 01:41