T O P I C R E V I E W |
.oisyn |
Posted - Jul 14 2008 : 6:18:27 PM When you forward-declare a class or struct, that type is colored like a variable instead of a type.
struct Foo;
struct Bar
{
}; Foo is colored as a variable, while Bar is colored like a type.
(related to http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=7982 ?) |
8 L A T E S T R E P L I E S (Newest First) |
support |
Posted - Jan 31 2010 : 1:38:50 PM case=18883 is fixed in build 1810 |
feline |
Posted - Aug 01 2008 : 4:09:15 PM Find References on the forward declared structure, I am seeing the same problem:
case=18883
And I am also seeing the colouring problem with the specialised template:
case=18884 |
.oisyn |
Posted - Jul 27 2008 : 1:15:52 PM No. If I do a find references on the 'Foo' at #1 or #2 it finds nothing. If I do it on the 'Foo' at #3 or #4 it finds all uses of Foo (even those in the header).
Btw, I just found out that coloring doesn't work for template classes of which only specializations are defined as well, but only if those classes have constructors:
template<class T> struct Foo;
template<class T> struct Bar;
template<> struct Foo<int>
{
};
template<> struct Bar<int>
{
Bar() { }
};
Foo will be colored as a type, but Bar isn't (as a method actually), until I define a general template of Bar (with or without ctor). |
feline |
Posted - Jul 25 2008 : 1:04:47 PM Does Find References help in this situation? |
.oisyn |
Posted - Jul 24 2008 : 5:13:18 PM Hmmm, I could swear I have never seen it happen before 1645. But indeed, as soon as the type is actually defined somewhere (even in a completely unrelated file), it gets colored as a type. Btw, the actual code I was seeing it in was a case where a (private) nested struct was declared in the header and defined in the sourcefile. However, this no longer seems to be the case, and there might have been a complete reparse of the symbols in between, so perhaps an out-dated database was to blame for that.
But, as we are on the subject anyway, doing an alt-g on a type in a header that was only declared in that header brings me to the declaration in that header. While in the sourcefile, where it's defined, it brings me to the definition of the type in the sourcefile.
Example:
// foo.h
struct Foo; // #1
void Bar(Foo f); // #2
// foo.cpp
#include "foo.h"
struct Foo { }; // #3
void Bar(Foo f) // #4
{
} If I do alt-g on 'Foo' in #2, it brings me to #1. If I do it on 'Foo' in #4, it brings me to #3. Of course I'd rather have it to navigate to #3 if I'm on #2 (or even #1) as well. |
feline |
Posted - Jul 16 2008 : 10:15:09 AM Which version of VA were you using before? Using the following C++ code and VS2005 I have just run some tests.
struct A;
struct forwardDeclareVariableName;
static void testGeneralCode()
{
int forwardDeclareVariableName;
}
"A" is coloured as a variable in VA 1626, 1640 and 1645. "forwardDeclareVariableName" is coloured as a type in 1626 on both lines - which is wrong. "forwardDeclareVariableName" is coloured as a variable in 1640 and 1645 on both lines, which is still wrong.
However given the limitations our colouring code has to work with this is an unfair test.
In your code is the forward declared type ever actually defined anywhere? There is a difference between a forward declaration and an actual declaration. Specifically you do not want alt-g to take you to the forward declaration of a type. |
.oisyn |
Posted - Jul 15 2008 : 5:55:51 PM You are correct. But there are no variables with those names in that scope - even if I use a completely empty sourcefile with just 'struct A;' it colors A as a variable. This is new in 1645 and pretty annoying. If you define a struct rather than declaring it, coloring is fine too. Why is a declaration different from a definition? Both things declare a type which from thereon can be used, so the distinction makes no sense in the first place. |
feline |
Posted - Jul 15 2008 : 09:39:54 AM Can you try this test code please:
struct FelineForwardDeclareChocolateStruct;
struct FelineCreateChocolateStruct
{
};
both types are coloured as types for me. I have picked these names since they should be unique. If the forward declared type name is also the name of a variable VA is probably getting confused over exactly what it is, and how to colour it. |