Hi,
We have been using Visual Assist for several years in a team of six developers on a C++ codebase of over 2 million lines of code. The level of acceptance is reasonably high throughout the team. I personally would rather code with just one hand than not use Visual Assist
.
Anyway, the reason for this post is that we are increasingly affected by what could be viewed as a limitation (or even defect) in Visual Assist:
We use a deeply nested structure of namespaces to organise a relatively large C++ codebase (2+ MLoC). In order to make our lives easier (and to provide some degree of standardisation in an otherwise decentralised system of namespaces), we employ a collection of macros. For example:
// n1.h
#define BEGIN_N1 namespace n1 \ { /* n1 */
#define END_N1 } /* n1 */
#define N1 n1
#define USING_N1 using N1
// n2.h
#include G?n1.hG?
#define BEGIN_N2 BEGIN_N1 \ namespace n2 \ { /* n2 */
#define END_N2 } /* n2 */ \ END_N1
#define N2 N1::n2
#define USING_N2 USING_N1::n2
This allows us to write code that looks like this:
// c.h
#include G?n2.hG?
BEGIN_N2
class C
{
public:
static C* GetC() {return new C;}
void M() {}
};
END_N2
which is arguably easier to read and to maintain, especially if the namespace structure should happen to change. Of course, we use proper (descriptive) names for our namespaces, macros, classes, methods, functions, etc. The above is just for illustration.
We have discovered that if we use the macros in declarations of local variables, the Visual Assist IntelliSense doesnG??t work properly:
#include G?c.hG?
void f()
{
N2::C* c = N2::C::GetC(); // no VA IntelliSense
c->M(); // no VA IntelliSense
delete c;
}
The same block of code (in the same compilation unit) re-engineered to not use the namespace definition macro works properly:
#include G?c.hG?
void f()
{
n1::n2::C* c = n1::n2::C::GetC(); // VA IntelliSense OK
c->M(); // VA IntelliSense OK
delete c;
}
Is there anything that can be done about this?
We are very reluctant to drop the usage of macros for namespace definitions. Aside from the benefits (we believe) we get from using the macros, we have a lot of legacy code that employs them extensively (and we wouldnG??t want to have to hire a regular expressions guru to engineer the macros out of the existing code).
Thanks,
Radu Carlan
Chief Software Architect
CorProfit Systems Australia