| Author |
 Topic  |
|
|
dgehri
Senior Member
Switzerland
43 Posts |
 Posted - Jan 24 2006 : 02:16:53 AM
|
Hello,
I'm using VA.X (VA_X.dll file version 10.2.1438.0 built 2005.12.16 ). I found a problem related to namespace aliases. Given the code below, VA.X does not provide parameter info, and underlines, X::foo on the line marked with "<<<<" below:
namespace a {
namespace b = c;
}
namespace a {
namespace c {
class X { static void foo(); };
}
}
using namespace a;
void bar()
{
b::X::foo(); // <<<<<<<<
c::X::foo(); // OK
}
Kind regards,
Daniel Gehriger |
|
|
feline
Whole Tomato Software
United Kingdom
18995 Posts |
Posted - Jan 24 2006 : 3:38:17 PM
|
i am seeing the same thing, but i did have to move the alias to after the class definition to get this to compile. i had not seen a namespace alias forward declared before, so i was curious to see if it would work.
case=967 |
zen is the art of being at one with the two'ness |
 |
|
|
dgehri
Senior Member
Switzerland
43 Posts |
Posted - Jan 24 2006 : 3:58:07 PM
|
You are right, of course. And a public access specifier is needed, too.
Here is the corrected code. Still, Intellisense does not work, and this problem is affecting a huge project of mine...
namespace a {
namespace c {
class X { public: static void foo(); };
}
}
namespace a {
namespace b = c;
}
using namespace a;
void bar()
{
b::X::foo(); // <<<<<<<<
c::X::foo(); // OK
}
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18995 Posts |
Posted - Jan 24 2006 : 5:31:51 PM
|
what happens if you press CTRL-SPACE after the namespace name and double colon? for me intellisense was working correctly when i did this.
can you check your setting VA Options -> text editor -> listboxes -> get content from default intellisense
this may have an effect on what you are seeing. i have this turned off. |
zen is the art of being at one with the two'ness |
|
|
|
dgehri
Senior Member
Switzerland
43 Posts |
Posted - Jan 24 2006 : 5:36:54 PM
|
I tried Ctrl-Space after "b::" and "b::X" but I get nothing. When doing the same using "c::" I see the list box suggesting "X" (even without Ctrl-Space), and after "c::X::" it suggests "foo".
My "get content from default intellisense" setting is and has always been turned off. |
|
|
|
dgehri
Senior Member
Switzerland
43 Posts |
Posted - Jan 24 2006 : 5:38:07 PM
|
PS: Meanwhile, I upgraded to "VA_X.dll file version 10.2.1440.0 built 2006.01.17", but the problem still applies.
|
|
|
|
o2a
Junior Member
24 Posts |
Posted - Jan 24 2006 : 7:11:16 PM
|
I tripped over a similar issue.
VA doesn't seem to recognize namespace aliases at all.
Having a nested namespace TTP::Interface and an alias declaration
namespace I = TTP::Interface;
VA won't recognize members of the TTP::Interface namespace when referred to with the alias like I::whatever.
Currently I'm using the following workaround in a special header file:
#define namespaceI namespace I = TTP::Interface;
namespaceI
#undef namespaceI
#define I TTP::Interface
#undef I
Using the macro namespaceI instead of inserting the namespace alias declaration directly is necessary, since VA would otherwise refer to the alias definition itself for anything beginning with this alias. (e.g. with "I::Vector" it would refer to "I" at the place "namespace I =..." instead to the declaration of TTP::Interface::Vector) - it simply doesn't recognize "I" as a namespace.
When using the detour with the macro, VA doesn't see the declaration of "I" and can't 'misread' it.
Then defining "I" as a macro 'alias' does point VA in the right direction. The #undef following is ignored by VA luckily while the compiler can use the real namespace alias.
May be this workaround is useful for others too.
(Btw, I have "get content from default intellisense" off too as I have disabled VS2005's often overly slow parsing completely by hiding the relevant dll.)
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18995 Posts |
Posted - Jan 25 2006 : 3:30:46 PM
|
all right, something unexpected is going on here. to avoid possible problems with duplicate variables, since i am using a test application, the actual code i tested is:
namespace SPACE_A {
namespace SPACE_C {
class X
{ public: static void foo() {} };
}
}
namespace SPACE_A {
namespace SPACE_B = SPACE_C;
}
using namespace SPACE_A;
void bar()
{
SPACE_B::X::foo();
SPACE_C::X::foo();
}
i believe this is basically the same as the code at the top of this thread, but i have made the namespace names better and made sure that it compiles.
using VS2003, pure C++ and VA 1440 both
SPACE_B::|
SPACE_C::|
spontaneously produce a completion listbox holding the single item "X". pressing CTRL-SPACE produces the same listbox. can someone else try this code and see what happens? it is possible VA is confusing the single letter namespace names. also which version of the IDE are you getting problems with?
o2a the reason VA ignores the #endif is that VA is designed to help you with all of your code, so it does not try to resolve the very tricky question (given you are editing) of which #define's are on and which are off. otherwise you would find yourself getting no suggestions inside #ifdef _DEBUG sections in release mode  |
zen is the art of being at one with the two'ness |
|
|
|
dgehri
Senior Member
Switzerland
43 Posts |
Posted - Jan 25 2006 : 3:43:26 PM
|
I tried your version. Of the two
SPACE_B::
SPACE_C::
only the second one produces the list box (spontaneously). The first one doesn't produce a list box, even when forced using Ctrl-Space. This is in a new empty C++ file (.h), VS2003, VA 1440.
quote:
VA_X.dll file version 10.2.1440.0 built 2006.01.17
Licensed to:
VA X: [email protected] (1-user license) Support ends 2006.06.23
VA.NET 7.1: [email protected] (1-user license)
VAOpsWin.dll version 1.3.2.0
VATE.dll version 1.0.4.12
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Lucida Console 12(Pixels)
Comctl32.dll version 5.82.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
Single processor
Platform: Custom
Stable Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include\\prerelease;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include;
C:\\WMSDK\\WMFSDK9\\include;
C:\\WINDOWS\\system32;
C:\\Daniel\\linkcad\\3rd-party\\STLport\\stlport;
C:\\Daniel\\linkcad\\3rd-party\\FOX\\include;
C:\\Daniel\\linkcad\\3rd-party\\boost;
Library Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\crt\\src;
Other Includes:
|
|
|
|
o2a
Junior Member
24 Posts |
Posted - Jan 26 2006 : 3:35:31 PM
|
I can confirm dgehri's last result with VS2005 and VAX1440. Only SPACE_C:: does work. Both have got the namespace icon in the completion list. (As a sidenote, SPACE_A on the other hand got the icon for "reserved word", although SPACE_A:: does work right.)
feline: VAX's handling of macros sounds reasonable to me. I am aware of the parsing problems C++ has inherited from C by it's pre-processor. Templates are hard enough to parse - but macros can become a nightmare (for human "parsers" too ;).
One of VS2005's new IDE features is to try to keep up with the current macro "state" - i.e. also parsing #if... & Co. correctly, displaying inactive parts of code in gray. This surprisingly works most of the time - not always though.
Back to namespaces - I don't think it's a problem with single letter namespaces. VAX just doesn't seem to handle namespace aliases itself correctly. If I add
namespace SPACE_D = SPACE_A;
namespace SPACE_E = ::SPACE_A::SPACE_C;
right below the "using namespace SPACE_A;" line (ok, doesn't really matter where) these two aliases still have the same problem, although not nested, not declared inside other namespaces and not single letter.
Ok, although VAX still lacks stable support for some advanced C++ features, I have to admit, it's a damn fine tool. Can't imagine doing without it anymore. (Btw, interested in bug reports about some issues with advanced operator overloading as found in the boost libs? I'd have to do some testing though to tell you what's wrong exactly. But I could imagine and understand if you say these are just "known issues" with low priority.) |
|
|
|
feline
Whole Tomato Software
United Kingdom
18995 Posts |
Posted - Jan 26 2006 : 4:22:26 PM
|
*puzzled* something very strange is going on here. starting with my test project, i am placing this code at the bottom of a small, existing cpp file, and it works fine.
when i create a new unnamed .h file in the same project it does not work. the same if i create a new unnamed cpp file.
moving to a new C++ command line project if i add this code at the bottom of the single cpp file then this works. yet add a blank unnamed cpp file to this project and paste in the code, then it does not work.
i have now confirmed this effect on a second machine, so what ever is causing it seems to be consistent.
case=974 |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
18995 Posts |
Posted - Jan 26 2006 : 4:26:21 PM
|
all right, this is getting confusing. i cannot reproduce the effect both of you are seeing. for me completion either works on both namespace lines, or neither. do either of you have the time to follow through the bug report instructions i have just reported:
the problem appears to be "random". in some files completion works, and in other files it does not work at all. the following steps reproduced this on two different machines for me.
open VS2003 and create a new C++ console application, not .NET, using the defaults.
at the bottom of the cpp file paste in the code:
namespace SPACE_A {
namespace SPACE_C {
class X
{ public: static void foo() {} };
}
}
namespace SPACE_A {
namespace SPACE_B = SPACE_C;
}
using namespace SPACE_A;
void bar()
{
// SPACE_B
// SPACE_C
}
uncomment SPACE_B and then type "::X::foo();" after it, and do the same for SPACE_C, to get:
SPACE_B::X::foo();
SPACE_C::X::foo();
you should get suggestions for both X and foo() in both cases.
undo the changes, and create a new cpp file. there is no need to save this out. paste in the same code and to the same tests. i get no suggestions at all, and CTRL-SPACE does not produce any either. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
18995 Posts |
Posted - Jan 26 2006 : 4:31:28 PM
|
quote:
Originally posted by o2a
Ok, although VAX still lacks stable support for some advanced C++ features, I have to admit, it's a damn fine tool. Can't imagine doing without it anymore. (Btw, interested in bug reports about some issues with advanced operator overloading as found in the boost libs? I'd have to do some testing though to tell you what's wrong exactly. But I could imagine and understand if you say these are just "known issues" with low priority.)
we do try  if you want to put VA in perspective try coding without it for a couple of days 
if you can produce a simple example of the operator overloading problem i will have a look. off hand i am not aware of anything like this, but some of the boost code seems to be using the C++ language to the fullest! |
zen is the art of being at one with the two'ness |
|
|
|
dgehri
Senior Member
Switzerland
43 Posts |
Posted - Jan 26 2006 : 4:33:10 PM
|
I tested your cases:
1. Appending code to file conaining _tmain(): completion works in both cases, but (!) VA.NET underlines "X" and "foo" in "SPACE_B::X::foo()". It does not underline anything in "SPACE_C::X::foo()".
2. Completion does not work for SPACE_B, but it does work for SPACE_C.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18995 Posts |
Posted - Jan 26 2006 : 4:56:59 PM
|
the underlining is expected, and is covered by case=967
it makes no sense to me that you get a different result for test 2. so i have added this fact to the case, hopefully this will make more sense to the developers. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Dec 19 2006 : 9:12:14 PM
|
| case=967 is fixed in build 1543 |
|
|
| |
Topic |
|
Problem with namespace aliases
