Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Feature Requests

Recognizing Handles

You must be registered to post a reply.
Click here to register.

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

[quote][i]Originally posted by sl@sh[/i]
[br]I am using a Handle class for some of my pointers, i. e. a class that works just like a pointer wrt. coding issues, but keeps track of all copied references and automatically releases the object once the last reference is gone.

One of the basic features of such a class is that it redefines the operator-> to point to the governed object. The class basically looks like this:[code]template <class X> class Handle {
    X* rep;
public:
    X* operator->() { return rep; }
// ...
};
[/code]

Now I can define a variable as a Handle to another class and access it's members like this:[code]class CFoo {
    int m_bar;
public:
    int getBar() const {return m_bar;}
};
main()
{
    Handle<CFoo> pFoo;
    int somevalue = pFoo->getBar();
}
[/code]

What I am missing is the suggestion box after typing the '->'. VA doesn't recognize the operator->() has been assigned to work as a pointer, so it doesn't provide the list of members from class CFoo.

My suggestion would be for VA to check operators typically used for referencing or dereferencing for possiblle overrides and supply a suggestion box with members of the returned class type.

I have to admit I haven't considered all the consequences: possibly, if you deal with operator->(), you might want to do the same with operator.(), or even operator&(). Considering that sometimes Handles are not quite defined the 'standard way' (i. e. as suggested by Bjarne Stroustrup) there might be some hidden traps...
[/quote]

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
sl@sh	Posted - Sep 18 2007 : 06:14:50 AM I am using a Handle class for some of my pointers, i. e. a class that works just like a pointer wrt. coding issues, but keeps track of all copied references and automatically releases the object once the last reference is gone. One of the basic features of such a class is that it redefines the operator-> to point to the governed object. The class basically looks like this: template <class X> class Handle { X* rep; public: X* operator->() { return rep; } // ... }; Now I can define a variable as a Handle to another class and access it's members like this: class CFoo { int m_bar; public: int getBar() const {return m_bar;} }; main() { Handle<CFoo> pFoo; int somevalue = pFoo->getBar(); } What I am missing is the suggestion box after typing the '->'. VA doesn't recognize the operator->() has been assigned to work as a pointer, so it doesn't provide the list of members from class CFoo. My suggestion would be for VA to check operators typically used for referencing or dereferencing for possiblle overrides and supply a suggestion box with members of the returned class type. I have to admit I haven't considered all the consequences: possibly, if you deal with operator->(), you might want to do the same with operator.(), or even operator&(). Considering that sometimes Handles are not quite defined the 'standard way' (i. e. as suggested by Bjarne Stroustrup) there might be some hidden traps...
3 L A T E S T R E P L I E S (Newest First)
feline	Posted - Sep 19 2007 : 10:56:55 AM Thank you. I am certainly interested in any test cases that show this breaking.
sl@sh	Posted - Sep 19 2007 : 04:06:17 AM Interesting, works alright for me as well. I again tried my original - rather complex - examples, and found that while some of them indeed don't suggest any completions (which triggered my suggestion) many instances work as well. I suppose there's something in my code which prevents VA from properly showing suggestions in some places, but at the moment I am not able to pin down the reason. When I have time (i. e. not right now) I will try to strip down part of the code to see what it is that makes VA stumble. Both the working examples and those that don't are in the same file. I also noticed a few oddities VA doesn't seem to be able to cope with, but that might be due to the fact I'm doing a major refactoring right now and parts of the code are currently seriously out of whack. I'll get back to these VA problems once the code is back to 'normal'....
feline	Posted - Sep 18 2007 : 1:10:26 PM Effectively you are talking about a smart pointer class. The short answer is that VA already does this. I have two standard tests for this, that both work just fine for me. One tests uses this variable: boost::shared_ptr<testBoostPtrListbox> pTest; and the second test uses this class: template <class T> class SmartPtr { public: SmartPtr() { ptr = NULL; RefCount = NULL; } int Attached() const { return ptr != NULL; } T &operator() { return ptr; } T operator->() { return ptr; } const T operator->() const { return ptr; } private: T ptr; size_t RefCount; }; Lets start with the simple test. Can you add my class to one of your header files and then in the matching cpp file add this code: class SimpleClass { public: SimpleClass(); int one; }; static void testSmartPointerArrayAccess() { Block< SmartPtr< SimpleClass > > SomeVariable; int x = 0, y = 10; for (x = 0; x < y; x++) { if (SomeVariable[x]->one) { // type -> before the semi-colon, and make sure that VA suggests // "one" and "SimpleClass()" SomeVariable[x]; } } } A little more complex than the situation you are describing, but an easy place to start.

Snitz Forums 2000