| Author |
 Topic  |
|
|
cbranch
Senior Member
USA
30 Posts |
 Posted - Dec 05 2006 : 6:51:44 PM
|
We have a issue with Namespaces that are conditionally compiled out via project settings. By in large this is not a big issue except when refactoring code.
Example Code:
//Conditional use a custom namespace if one is defined by the project
//preprocessor settings.
#ifdef NOT_DEFINED
namespace NOT_DEFINED {
#endif
typedef int AnyThing;
#ifdef NOT_DEFINED
}
#endif
class Test
{
AnyThing test();
};
Operation, Create implementation of test.
Result:
NOT_DEFINED::AnyThing test()
{
}
Given that NOT_DEFINED is not defined anywhere in code or project settings. The prefered output would be.
AnyThing test()
{
}
But if NOT_DEFINED was defined in the project preprocessor settings it would be expanded.
Currently we do not have the option of removing namespaces from the headers since they are used by several large 3rd party libraries.
It would be nice if Visual Assist could apply the project preprocessor settings when parsing which ignore to remove the namespace.
Also some places there are multiple separate implementations of classes with the same name and specified conditionally depending on the project configuration.
#ifdef CONFIG_A
class Foo { void set(int);}
#endif
#ifdef CONFIG_B
class Foo { void get(int);}
#endif
Visual Assist creates the logical union of the classes in Visual Assists View, it would be nice if it could handle per-configuration differences, depending on the project's preprocessor defines for that configuration.
The issue of not knowing if a macro is set in code or in the Project preprocessor could be defined via an option in the VAX options called 'Use Project Settings Preprocessor' which by default would be off. But when it was on it would enforce defines /D(to indicate something is defined once in the project) and undefines /U( to indicate something is never defined in the project). And parse accordingly.
|
Colin Branch |
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
|
|
cbranch
Senior Member
USA
30 Posts |
Posted - Dec 06 2006 : 11:48:19 AM
|
That is sound reasoning in a general sense.
However I don't think it is completely unreasonable to assume that Visual Assist *could* get parse the preprocessor using the project settings and treat those as constant project wide variables.
Of course actually implementing such functionality may be completely unreasonable, but it's worth asking anyway.
This is most certainly a feature would benefit the 10 or so developers that use VAX at my company and potentially the hundreds of customers who use our middleware products. |
Colin Branch |
 |
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Dec 07 2006 : 10:15:14 AM
|
Are these pre-processor definitions basically fixed, or do they change fairly regularly?
I am wondering if it is possible to "cheat", and use an existing feature of VA to trick VA into working correctly in at least some of these cases. If this can be made to work (a bit of a long shot) it would not be ideal for regularly changing pre-processor definitions. |
zen is the art of being at one with the two'ness |
|
|
|
cbranch
Senior Member
USA
30 Posts |
Posted - Dec 07 2006 : 1:59:38 PM
|
Well most are constant based upon the project configuration. Our products are built against different architectures. They provide similar capabilities but are incompatible with in the same project and have different interfaces. Thus when building against a given architecture we use the #if blocks to conditionally compiler both complete classes and change the interface within classes. Granted, not the best way to manage code however our code base is too large to change now. This problem results in false positives in VAX which while annoying don't cause too much havoc. The use of optional namespaces is the main problem since they are controlled by a solution wide constant for all configurations in products which use the said product as a import library, which of course makes the refactoring not generate the proper class names.
I take a guess and say you're talking about modifying the files in /Misc dir? I'm all for cheating as long as it works. Any suggestions for how to force a value of a macro would be nice. Though of course it would be even better to be able to do it on a per project per configuration basis. |
Colin Branch |
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Dec 08 2006 : 12:05:02 PM
|
A change to VA's parser to handle your situation is possible, but to be honest unlikely. This is likely to be quite a lot of work which is only going to help in this specific situation. Plus it will open the door to a lot of requests / complaints about not picking up the configuration flags from all over the place.
You are correct, I am thinking about modifying "C:\\Program Files\\Visual Assist X\\Misc\\StdAfx.h"
The problem is going to be working out the correct modification.
Based on the sample code here I have done the following. If the code is changed to read:
#ifdef NOT_DEFINED
#define START_NOT_DEFINED namespace NOT_DEFINED {
#define END_NOT_DEFINED }
#else
#define START_NOT_DEFINED
#define END_NOT_DEFINED
#endif
START_NOT_DEFINED
typedef int AnyThing;
END_NOT_DEFINED
class Test
{
AnyThing test();
};
And the file "C:\\Program Files\\Visual Assist X\\Misc\\StdAfx.h" is modified to contain the lines:
#define START_NOT_DEFINED
#define END_NOT_DEFINED
and I rebuild VA's symbol database when I next run Create Implementation I get a return type with no namespace.
Depending on the code you are using, and the namespaces you are working with, you may be able to add a couple more #define's for the start and end of the namespaces and add the VA #defines:
#define START_NOT_DEFINED /*
#define END_NOT_DEFINED */
now I have not tested this second idea, but in theory it will hide the inactive code from VA. That or it will just not work at all 
If you try this then do remember that you will need to reapply your changes to StdAfx.h after every upgrade to VA is installed, since the installer ships with the current standard versions of these header files. |
zen is the art of being at one with the two'ness |
Edited by - feline on Dec 08 2006 12:06:12 PM |
|
|
|
cbranch
Senior Member
USA
30 Posts |
Posted - Dec 11 2006 : 1:30:02 PM
|
Unfortunately I can't change the code:
#ifdef Foo
namespace A {
#endif
...
#ifdef Foo
}
#endif
to your suggestion, which I bet would work, since that code is from an external library and not part of my product. And while I probably could technically remove it from the headers, there are over a 1000 of them. Writing a script the properly removed them would be very difficult to check (I'd have to hope the compiling just worked).
I guess it just would be nice to be able to force a value for a specific macro (via the stdafx.h or another header) to be globally applied by VAX's parser. This would have to be a new feature. I get the picture this is not likely to be added but I will leave it as a feature request. |
Colin Branch |
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Dec 11 2006 : 5:13:28 PM
|
I have put in a feature request to see what people think of this.
case=4059 |
zen is the art of being at one with the two'ness |
|
|
|
sneftel
Junior Member
Ireland
24 Posts |
Posted - Oct 03 2013 : 04:46:23 AM
|
| I would second this feature. The _asm{ trick I came up with is great for ignoring C++ code, but it is utterly ineffective against preprocessor macros. Anything which could force VAX to actually skip a conditional block would be great. For instance, VAX could special-case any preprocessor conditional which ended in the characters "&& !defined(__VisualAssist__)". That wouldn't affect any actual compilation, and AFAICT it wouldn't require significant changes to VAX's preprocessor. (It wouldn't recognize __VisualAssist__ as a macro or need to evaluate the conditional expression, just recognize the character sequence as a sentinel.) |
Edited by - sneftel on Oct 03 2013 04:53:38 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Oct 03 2013 : 1:04:58 PM
|
Are you trying to hide specific blocks of code from VA, or just specific macros? I suspect blocks of code, but its best to check.
Out of interest why are you looking to hide blocks of code from VA? Hiding the auto-generated files makes sense, so I am wondering what you are encountering here. |
zen is the art of being at one with the two'ness |
|
|
|
sneftel
Junior Member
Ireland
24 Posts |
Posted - Oct 04 2013 : 04:37:54 AM
|
| Macros, actually. I should say that this is a fairly minor niggle, but as a counterpart to all that codegen, most of our classes use a DECLARE_REFLECTION() macro which expands to a few static member declarations. It would be nice for those to not show up. (Again, it's a minor niggle.) |
Edited by - sneftel on Oct 04 2013 04:38:22 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Oct 04 2013 : 12:05:16 PM
|
Since its actually a specific macro, can you please try creating a "va_stdafx.h" file in the root directory of your solution, as explained here:
http://docs.wholetomato.com?W302
and add the line:
#define DECLARE_REFLECTION()
to the "va_stdafx.h" file, making sure it ends with a blank line. If you now rebuild your symbol database:
VA Options -> Performance -> General -> Rebuild symbol databases
VA should now ignore this macro in your code, since the empty version in the va_stdafx.h file takes priority. |
zen is the art of being at one with the two'ness |
|
|
|
sneftel
Junior Member
Ireland
24 Posts |
Posted - Oct 08 2013 : 09:02:22 AM
|
Hey, it worked. Thanks. That was the last of the reflection stuff... my Find Symbol list is now so clean I could eat off it. :-)
I'm a little surprised... if there's multiple definitions of a given macro, doesn't VAX expand it with each of the possible expansions? Or are definitions in va_stdafx.h "special" in this regard? |
Edited by - sneftel on Oct 08 2013 09:03:15 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Oct 08 2013 : 11:30:51 AM
|
For an actual macro, VA tends to use the first definition it encounters. This is something you can then use and control if all of the definitions are in the same file, but its much harder to control if the definitions are in different files.
When you use #if #else #endif blocks then VA parses and is active in both branches, even if the #if is controlled via a macro.
The va_stdafx.h file is always parsed first, so it takes priority over everything in your solution. It is ideal for these sorts of situations, where there is a macro in your solution that VA either needs some help understanding, or that you simply want VA to ignore entirely.
The advantage of the va_stdafx.h file is that since it is not part of your solution and the compiler should never see it, you can add it into source control along with the rest of your solution, knowing that VA will pick it up if and when you move to a new machine.
I hope this makes sense and helps to explain why this works. I am glad this has helped so much |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Use project preprocessor settings while parsing
