{"id":4233,"date":"2009-10-14T14:03:00","date_gmt":"2009-10-14T14:03:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2009\/10\/14\/visual-c-code-model-in-visual-studio-2010\/"},"modified":"2019-02-18T18:45:46","modified_gmt":"2019-02-18T18:45:46","slug":"visual-c-code-model-in-visual-studio-2010","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/visual-c-code-model-in-visual-studio-2010\/","title":{"rendered":"Visual C++ Code Model in Visual Studio 2010"},"content":{"rendered":"

Hello, I’m Vytautas Leonavičius, a developer on the Visual C++ IDE<\/i> team. Today, I’d like to discuss how the new principles we’re applying to code browsing in Visual Studio 2010<\/i> (see <\/font>here<\/font><\/a> and <\/font>here<\/font><\/a>) will affect VCCodeModel<\/i>.  General information about VCCodeModel<\/i> can be found <\/font>here<\/font><\/a>.<\/font><\/p>\n

Improvements<\/p>\n

<\/span><\/b><\/p>\n

Because of our new incremental update architecture, VCCodeModel<\/i> implicitly gets certain benefits:<\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>Availability:<\/b> Once initial population is done, VCCodeModel<\/i> is pretty much always available. That is a positive result of design decisions to parse files independently. No change of a single file (even the omnipresent windows.h, if you like) will cause “rebuild of the world”. That means, if issued, calls to VCCodeModel.Synchronize<\/i><\/b> will return almost instantly.<\/font><\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>Reliability:<\/b> We no longer use the old NCB<\/i> database<\/i>. Instead, we now use the same redistributable SQL CE components that we provide to our end-users.  Suggestions to “delete your .ncb file” (due to DB corruption) in order to restore functionality of Browsing\/Intellisense<\/i> are a thing of the past.  <\/p>\n

<\/b><\/font><\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>Independence from a macro state:<\/b> Prior to Visual Studio 2010<\/i>, a file snapshot was taken in a certain undefined macro state. Depending on macro state active in a translation unit at the moment file contents were analyzed, certain constructs would or would not make it into the NCB database<\/i>.  That caused a lot of confusion.  In Visual Studio 2010<\/i> macro state is ignored and all source file declarations and definitions make it into database, and therefore into VCCodeModel<\/i>.<\/p>\n

<\/b><\/font><\/font><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

\/\/ Both A and B will make it into database and VCCodeModel, no matter if X is
\/\/ defined or not.<\/span><\/p>\n

<\/span><\/p>\n

#ifdef<\/span> X<\/p>\n

<\/span><\/p>\n

class<\/span> A {};<\/p>\n

<\/span><\/p>\n

#else<\/span><\/p>\n

<\/span><\/p>\n

class<\/span> B {};<\/p>\n

<\/span><\/p>\n

#endif<\/span><\/p>\n

<\/span><\/p>\n

See Dealing with preprocessor conditional directives <\/b>and Hint files <\/b>sections of Thierry’s <\/font>post<\/font><\/a>.<\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>Improved eventing model: <\/i><\/b>VCCodeModel<\/i> edit Events<\/i> are more precise and correct, thanks to improvements to our code difference<\/i> algorithms.  The new difference<\/i> algorithms have better understanding of user edits.  This is especially true in the presence of templates. This improves the reliability of the Visual C++ Wizards <\/i>and clients who listen to VCCodeModel Events<\/i>.<\/font><\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>Performance: <\/i><\/b>VCCodeModel<\/i> is faster in scenarios where an object reference is taken and passed through external third party code (your code!) which may perform looped inquiries. This is thanks to some targeted caching we added to VCCodeModel<\/i>.  All clients should benefit from this since many of VCCodeModel<\/i> services are implemented using its externally exposed APIs for correctness.<\/font><\/font><\/p>\n

Limitations<\/p>\n

<\/span><\/b><\/p>\n

The aforementioned benefits are primarily brought about by the design decision to treat every single file independently and through some targeted performance work.  However, a downside that this design decision exposes is a lack of absolute precision in full symbol resolution in Visual Studio 2010 Browsing<\/i>. It applies the following limitations on VCCodeModel<\/i>: <\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>No symbol resolution<\/b>: Type Strings for functions (return type), typedefs, base classes, macro definitions (except those specified in hint files) and parameters are coming directly from source code. They are no longer resolved by compiler as it used to be.  This problem may surface if a caller wants to figure out precisely what type a function is returning:<\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Example 1:<\/p>\n

<\/font><\/font><\/b><\/p>\n

using<\/span> namespace<\/span> X;<\/p>\n

<\/span><\/p>\n

using namespace <\/span>Z;<\/p>\n

<\/span><\/p>\n

Type foo() { return<\/span> Type(); }<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

The Type String for VCCodeFunction <\/i><\/b>object referring to function <\/font>foo<\/span> is <\/font>Type<\/span>. We don’t really know if it is <\/font>X::Type<\/span>, global <\/font>Type<\/span> or <\/font>Z::Type<\/span>. Note that <\/font>using namespace<\/span> in this sample, should not necessarily be in same file, it can be in a header (far away). Without building the full translation unit, there’s no efficient way to resolve the symbol <\/font>Type<\/span> deterministically and to maintain the performance improvements that our customers desire and that we have achieved with this new design. <\/p>\n

<\/b><\/font><\/font><\/p>\n

Example 2:<\/p>\n

<\/font><\/font><\/b><\/p>\n

File.h<\/font><\/p>\n

class<\/span> Base {};<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

File2.h <\/p>\n

<\/span><\/font><\/font><\/p>\n

namespace<\/span> A {
       class<\/span> Base {};<\/span>
}<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

namespace<\/span> B { <\/p>\n

<\/span><\/p>\n

       class<\/span> Base {};<\/p>\n

<\/span><\/p>\n

}<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

File.cpp<\/font><\/p>\n

#include<\/span> “a_header_including_many_headers_and_introducing_using_directives.h”<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

class<\/span> Derived : Base \/\/ Which Base is that? Base, A::Base or B::Base?<\/span><\/p>\n

<\/span><\/p>\n

{};<\/p>\n

<\/span><\/p>\n

Lack of precise fully-qualified symbol resolution affects TypeString<\/i><\/b> properties of VCCodeParameter<\/i><\/b>, VCCodeTypedef<\/i><\/b> and FullName<\/i><\/b> property of VCCodeBase<\/i><\/b>.It also indirectly affects several APIs of the CodeTypeRef<\/i><\/b> object that is used as a link between object in source code and type.<\/font><\/p>\n

VCCodeModel <\/i>provides heuristic APIs that attempt to resolve a name to a type, even if name is not fully qualified. For incompletely qualified names (like <\/font>”Type”<\/span>, if <\/font>Type<\/span> belongs to namespace <\/font>X<\/span>)  VCCodeModel.CodeTypeFromFullName<\/i><\/b> and VCCodeModel.CodeElementFromFullName<\/i><\/b> prefer names defined at global scope and only resolve to a name defined in a namespace if a global one is not found. <\/font><\/font><\/p>\n

We’ve added a helper API called VCCodeModel.CodeElementFromFullName2<\/i><\/b>  in \nVisual Studio 2010<\/i> to help clients detect this ambiguity. See below.<\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>No code elements from imported assemblies in C++\/CLI:<\/b> Code elements from imported assemblies are not added to the Browsing database<\/i>. As a consequence, the types coming from these assemblies would not be resolved.  For example, if you have a function with a parameter type specified as <\/font>Exception<\/span> in source code, VCCodeModel<\/i> won’t be able to resolve it to <\/font>System::Exception<\/span>, since currently such class is not present in database.<\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

•<\/font>        <\/span><\/span><\/span>We’ve removed Managed C++ support from VCCodeModel in Dev10: <\/b>Support for C++\/CLI <\/i>is still there. <\/b><\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

New APIs in Visual Studio 2010<\/p>\n

<\/span><\/b><\/p>\n

We have introduced the following APIs to VCCodeModel<\/i> in Visual Studio 2010<\/i>. All APIs are additions to the VCCodeModel <\/i><\/b>interface: <\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>CodeElementFromFullName2<\/i><\/b>: Is identical to CodeElementFromFullName<\/i><\/b>, except that it will disregard namespaces during lookup. Because there is no symbol resolution in Visual Studio 2010 <\/i>version of VCCodeModel<\/i> it is sometimes beneficial to know whether a particular symbol is ambiguous. The primary source of ambiguity in VCCodeModel<\/i> is <\/font>using namespace<\/span> directives. CodeElementFromFullName2<\/i> <\/b>API looks up the name disregarding namespace. For the following source code:<\/font><\/font><\/p>\n

class<\/span> X {};<\/p>\n

<\/span><\/p>\n

namespace<\/span> NS1 {<\/p>\n

<\/span><\/p>\n

       class<\/span> X {};<\/p>\n

<\/span><\/p>\n

       namespace<\/span> NS2 {<\/p>\n

<\/span><\/p>\n

              class<\/span> X {};<\/p>\n

<\/span><\/p>\n

       }<\/p>\n

<\/span><\/p>\n

}<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

Calls to <\/font>VCCodeModel.CodeElementFromFullName2(“X”)<\/span> will yield<\/font> {X; NS1::X; NS1::NS2::X}<\/span>. <\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

•<\/font>        <\/span><\/span><\/span>CodeTypeFromFullName2<\/i><\/b>: Is identical to CodeTypeFromFullName<\/i><\/b> except that it will attempt typedef resolution. That is, for the following code:<\/font><\/font><\/p>\n

class<\/span> X {};<\/p>\n

<\/span><\/p>\n

typedef<\/span> X TD;<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

call to <\/font>VCCodeModel.CodeTypeFromFullName2(“TD”)<\/span> will yield class <\/font>X<\/span>.<\/font><\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>IsSynchronized<\/i>:<\/b> returns true or false depending on whether VCCodeModel <\/i>is in sync with solution’s source code. Useful for avoiding blocking the calling thread for an undefined period of time while Browsing<\/i> database<\/i> is being populated.<\/font><\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>SynchronizeFiles<\/i><\/b>: If\nVCCodeModel <\/i>is not in sync with source code, it is not safe to query for a VCFileCodeModel<\/i><\/b> for a project file (caller will get null reference if project files are not yet registered in Browsing<\/i> database<\/i>). Call to SynchronizeFiles<\/i><\/b> makes sure that FileCodeModel<\/i><\/b> property on a project file is guaranteed to be not null.<\/font><\/font><\/p>\n

•<\/font>        <\/span><\/span><\/span>SynchronizeCancellable<\/i><\/b>: if caller invokes this API while Browsing database<\/i> is being populated, and there’s significant delay till population completes (for example: initial population of solution Browsing database<\/i>), the user will see a dialog box with a progress bar.  The dialog box also allows users to cancel wait and API will exit unblocking thread. <\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

We’re looking forward to hearing your feedback.  Any suggestions, comments and feedback about what can we do to make VCCodeModel<\/i> better are welcome.<\/font><\/p>\n

Vytas\/Visual C++<\/font><\/p>\n

\n

 <\/font><\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

Hello, I’m Vytautas Leonavičius, a developer on the Visual C++ IDE team. Today, I’d like to discuss how the new principles we’re applying to code browsing in Visual Studio 2010 (see here and here) will affect VCCodeModel.  General information about VCCodeModel can be found here. Improvements Because of our new incremental update architecture, VCCodeModel implicitly […]<\/p>\n","protected":false},"author":289,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[6],"class_list":["post-4233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","tag-ide"],"acf":[],"blog_post_summary":"

Hello, I’m Vytautas Leonavičius, a developer on the Visual C++ IDE team. Today, I’d like to discuss how the new principles we’re applying to code browsing in Visual Studio 2010 (see here and here) will affect VCCodeModel.  General information about VCCodeModel can be found here. Improvements Because of our new incremental update architecture, VCCodeModel implicitly […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/289"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=4233"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4233\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=4233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=4233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=4233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}