| T O P I C R E V I E W |
| sjaffe |
Posted - Oct 13 2006 : 10:58:04 AM
VAX 1535 in eVC++ 4.0: I have two classes with the same name (one inheriting from the other), but in different namespaces. I have a pointer of this type pointing to a member of one of the classes. Often VAX is unable to resolve this symbol (Alt-G doesn't work, squiggly red line under symbol).
namespace x
{
class a
{
};
}
namespace y
{
class a : public x::a
{
int m;
};
a* ptr;
a->m; // VAX can't find m
}
(The actual code is spread over multiple files). My workaround is to rename one of the classes to something different, but this is valid C++, so VAX should parse it correctly.
I also am finding with this version (1535) that quite often for no apparent reason VAX seems to forget many of the symbol referrences and my file is filled with red squigglies under many of the symbols. I tracked down some of these to the above problem of same name classes (with inheritance) in different work spaces with polymorphic pointers, so there's probably more than one problem. I don't believe this was a problem in older releases (Alt-G change recently introduced this?) |
| 16 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Dec 12 2007 : 07:39:57 AM
Are you testing with the *same* code in both your main project and the new test project? Or just code that "should be the same"?
The sample code I posted should be safe to insert into your main project, since it uses (hopefully) unique names to avoid any clashes.
It could be the actual problem code in your main project is more complex.
The organisation of the files might be a factor, but off hand I don't see why. |
| StanleyWu |
Posted - Dec 11 2007 : 3:10:01 PM
I am pleased to let you know that it works for a new small default project.
But the problem's still there in our existing project. I will let you know if something new is found to help reproduce it in a simple way. |
| feline |
Posted - Dec 07 2007 : 2:39:22 PM
I added the member function to try and make the code more confusing.
I have now removed the member function from the class in the namespace, reloaded VC6, and alt-g still works perfectly, taking me to both the global class and the member function in the global class.
Can you reproduce this problem in a new default project? I am starting to wonder if the project configuration or file layout is part of the problem. |
| StanleyWu |
Posted - Dec 07 2007 : 12:47:10 PM
If you delete the declaration of memberFunction() in TEST_ALT_G_SPACE_GLOBAL_CLASS_NAME_SCATTERED::testAltGGlobalNamespaceDuplicateScattered, you will probably see the problem. Try again and see what will happen. Btw, I always use VC6. |
| feline |
Posted - Dec 07 2007 : 08:46:08 AM
I am still not seeing the problem. using VS2005 and VA 1623 I have:
"test_alt_g.h" holds:
namespace TEST_ALT_G_SPACE_GLOBAL_CLASS_NAME_SCATTERED
{
class testAltGGlobalNamespaceDuplicateScattered
{
public:
void memberFunction();
};
}
"test_general.h" holds:
class testAltGGlobalNamespaceDuplicateScattered
{
public:
void memberFunction();
};
and "test_alt_g.cpp" holds:
#include "test_alt_g.h"
#include "test_general.h"
void testAltGGlobalNamespaceDuplicateScattered::memberFunction()
{
}
sitting in "test_alt_g.cpp" I have used alt-g on both the class name and the function name. Alt-g always takes me directly to "test_general.h", the class in the global namespace.
I have restarted the IDE after adding this code, to make sure VA has had time to catch up with all of my moving code from one file to another. |
| StanleyWu |
Posted - Dec 06 2007 : 3:01:44 PM
Problem is still there even after my upgrading to VAX 1623. You may recreate it just save the above three blocks of code in separate files.
For example,
1. save the declaration of TEST_ALT_G_SPACE_GLOBAL_CLASS_NAME::testAltGGlobalNamespaceDuplicate in "test1.h" file
2. save the declaration of ::testAltGGlobalNamespaceDuplicate in "test2.h" file
3. save the definition of "void testAltGGlobalNamespaceDuplicate::memberFunction()" in test.cpp, don't forget to include "test1.h" and "test2.h"
|
| feline |
Posted - Dec 06 2007 : 09:01:43 AM
Using VA 1623 this works correctly for me. Using the following code, with unique type names, I have tried this in both VC6 and VS2005. In both cases alt-g on the function implementation jumps to the function declaration in the global scope.
In my tests all of this code is placed into a header file.
namespace TEST_ALT_G_SPACE_GLOBAL_CLASS_NAME
{
class testAltGGlobalNamespaceDuplicate
{
};
}
class testAltGGlobalNamespaceDuplicate
{
public:
void memberFunction();
};
void testAltGGlobalNamespaceDuplicate::memberFunction()
{
}
|
| StanleyWu |
Posted - Dec 05 2007 : 2:36:09 PM
It seems that VAX, even in version 10.4.1619.0, can't resolve symbol which is defined in DEFAULT namespace.
Consider the following code:
namespace x
{
class a
{
};
}
class a
{
public:
void fn();
};
void a::fn(){ // <--VAX can't find symbol "fn"
}
It can be compiled successfully in VC++6, but VAX can not find symbol "fn" because of class name duplication.
If I change it to "void ::a::fn()", VAX can find it. However, it is impossible for me to change them all in the existing big project.
|
| support |
Posted - Nov 24 2006 : 9:26:11 PM
Case 734 is fixed in build 1541. |
| feline |
Posted - Oct 14 2006 : 12:10:13 PM
*ah* that makes sense. by the time something is distilled down to a sensible problem description, it often makes very little sense as code  |
| sjaffe |
Posted - Oct 13 2006 : 2:14:53 PM
Not directly related to the defect, but thought feline might want to know why we have two classes with the same name:
We have our code architected into a portion that is common to a number of products (shared) and product specific. Each has its own namespace. The product specific class inherits from the shared class, extending its functionality. The product specific code instantiates a product specific object. Each namespace has a pointer to this object. The shared pointer only has access to the shared portion, the product specific pointer has full access. The pointers have the same name. The convenience of this system is a programmer can use the same name pointer in either namespace without having to think which one they are in. It works out quite nicely. |
| rhummer |
Posted - Oct 13 2006 : 1:57:21 PM
its our internal database, we put it here for our own references so we can search the forum quickly for those cases when they are fixed ;) |
| sjaffe |
Posted - Oct 13 2006 : 1:40:28 PM
I've seen a number of references to "case=xxx". Is this database of cases available somewhere through the website, or is it just something Whole Tomato uses internally? If internal only, it doesn't seem particularly useful listing it in this public forum context ;^) |
| feline |
Posted - Oct 13 2006 : 1:34:04 PM
based on the dates here:
http://www.wholetomato.com/support/history.asp
for the general release versions you could have been using 1301, which did have a different parser, and some different behaviours. |
| sjaffe |
Posted - Oct 13 2006 : 1:25:42 PM
The previous version we were using was downloaded about a year ago (sorry, don't know the specific version #)
Stan |
| feline |
Posted - Oct 13 2006 : 1:21:29 PM
there are some known issues with duplicate class names in different namespaces. this should be covered by
case=734
this is certainly valid C++, but doesn't it get confusing? you are deriving a class from another class with the same name.
do you have any idea which version of VA you were using before? I was not aware that this had changed in recent builds, but the parser was changed around VA 1418 - quite a while ago now. |
