| T O P I C R E V I E W |
| clintsinger |
Posted - Aug 14 2006 : 2:44:19 PM
Hi,
First of all this post is about c++.
I have a frustrating problem with regards to alt-g and interfaces. When I have a class that implements an interface and I create a pointer to that class onto a variable of the interface, when I alt-g on it takes me to the Interface class where the Method is defined. While I realize this is the behaviour that should be expected, it isn't what I want.
What I really want is a pop-up that lists the classes in my project that implement the interface. More specifically, the method which I am activating Alt-G. Rarely do I need to go to the interface itself when using Alt-G, rather I want to one of the classes that implement the interface. (Although, I would still like the actual interface to be in the list too.)
Cheers,
Clint |
| 4 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Apr 23 2007 : 08:01:11 AM
In addition to sl@sh's very good points, what happens when pFoo points at CFoo for the first 3 lines of a function, and CAnotherFoo for the next 3 lines of the same function?
Ultimately the compiler always resolves what pFoo is pointing at, but since the whole point of this sort of code is that you can, and do, change the nature of the class at run time this becomes rather complicated for VA to try and pin down.
Here you know the name of the function, and if you use a consistent naming convention that it is a member of a class "*foo*", so why not use FSIW? You can filter it on "methoda foo", which will give you all items containing these two strings. |
| sl@sh |
Posted - Apr 23 2007 : 03:47:32 AM
Not sure what you mean by tracing back, and why you think this would be unambiguous? For all I know, the methods SomeOtherClass::UsingFooX() might be called from within a library that is linked to your code, and that you don't even have the source code of. So you wouldn't know what pFoo is instantiated with.
Or even more likely - if you already use inheritance, it will be likely that either function is called by a pFoo that is instantiated by objects of different classes.
Anyway, I don't see how this would be relevant, since as long as you are using your interface class IFoo, it doesn't matter what class pFoo is instantiated with - so why would you want to know?
P.S.:
to be more to the point: you have one of two possible scenarios:
1. if you *know* your pFoo is going to be a pointer to CFoo, why do you call it an IFoo* on your method interface? You should make your pFoo a CFoo* then.
2. if you *don't know* what class your pFoo is actually instantiated with, then - before you could use any of the features of the actual class - you should first cast it to the appropriate class, after somehow testing what class it actually is. A much easier way however would be to just use virtual functions and implement whatever you want to do within your methods UsingFooX() right within your instantiated classes, not within IFoo! |
| clintsinger |
Posted - Apr 21 2007 : 1:17:59 PM
What if the alt-g could trace back to where the class is being instansiated?
For example
class IFoo
{
public:
virtual void MethodA() = 0;
}
class CFoo : public IFoo
{
public:
virtual void MethodA();
}
class CAnotherFoo : public IFoo
{
public:
virtual void MethodA();
}
void SomeOtherClass::CreatingFoo()
{
IFoo* pFoo = new CFoo();
IFoo* pAnotherFoo = new CAnotherFoo();
UsingFoo1(pFoo);
UsingFoo2(pAnotherFoo);
}
void SomeOtherClass::UsingFoo1(IFoo* pFoo)
{
pFoo->MethodA();
^- alt-g here would know that CFoo() is where I want to be and gives me it as the option in the popup list.
}
void SomeOtherClass::UsingFoo2(IFoo* pFoo)
{
pFoo->MethodA();
^- alt-g here would know that CAnotherFoo() is where I want to be and gives me it as the option in the popup list.
}
So, VisualAssist would have to know where the variable was instansiated and that would take a bit of tracing back in the code.
But I would love this feature! 
|
| feline |
Posted - Aug 14 2006 : 6:18:21 PM
have you tried the latest beta build? there is a new feature "find references", which you may find helps if you run this on the interface type.
when you say interface are you talking about some specific keyword? or are you talking about a common (and probably abstract) base class? i believe interfaces exist as a specific type of class in C#.
however if this is simply a base class, then this could cause problems if you ever derive a class from a common framework class, since suddenly you may find yourself with hundreds of references on alt-g. |
|
|
