quote:

---

Originally posted by GennadiyKorol

When I wrote about giving the priority to class members I have meant that if I use autocompletion on an empty space or partially typed name, the completion list should show me class members first.

Right now it will show bunch of other symbols coming from various include files.

---

#define MacroDeclareSharedPtr( classname ) \    class classname; \    typedef MacroTyoeSharedPtr<classname> classname##Ptr

MacroDeclareSharedPtr( TestType );

quote:

---

Originally posted by feline

There is confusion I do not understand what you are talking about here.

---

class Apple 
{
public:
   int compare(const Orange & orange) const;
   float juiciness() const;

   double _weird;

private:
   Person privateRyan;
};


// Writing other code:
int Apple::compare(const Orange & orange) const 
{
   // Here the privateRyan is visible in the completion list!
   // By the way, some priority to class members should be given here as well.
   Apple apple;
   apple. | compare()    |
          | juiciness()  |
          | _weird       |
          | privateRyan  |
}


void squeezeTheApple(Apple & apple)
{ 
     // This function has no private access to the Apple class.
     // Only the public members are visible.
     // _weird member is optionally hidden here as well, just because of the prefix, even though it's accessible.
     apple. | compare()    |
            | juiciness()  |
}

quote:

---

Originally posted by feline
Firstly you need to know ALL pre-processor declarations in order to do this correctly. If it works 90% of the time this is a problem, since 10% of the time you are getting the wrong result. The IDE lets you set pre-processor directives in lots of places.

Secondly the code after running the pre-processor may be quite different to the code you are editing, causing all sorts of problems with scope, etc.

Thirdly, VA is designed to help you with code that is inactive. Code inside a #if 0 block, or a #ifdef LINUX block. This code would be removed as soon as you run the pre-processor, making it rather hard to help you with it.

Before you say "no one ever does that" what about #ifdef DEBUG blocks?

---

quote:

---

The sample code you posted, if NetBeans is running the code through a pre-processor then it is not going to have any problems with macro's, since it never sees them. I do wonder how it handles "commented out" code though.

---

quote:

---

Originally posted by GennadiyKorol

I don't think we're on the same page for my latest suggestion about _members.

What I meant was, given you implement context-sensitivity in the suggestion lists, you will not have the problem with _members that are declared public in the STL and at the same time you won't have the problem of not showing the private _members of user classes (the case you suggested is a possible problem), since in this case the _filtering shouldn't be applied.

---

#define DUMMY

#ifdef DUMMY
#define DECLARE_MEMBER(name, args) \void name(args) { \    \}
#else
#define DECLARE_MEMBER(name, args)
#endif


template <typename T>
class A
{
    public:
        DECLARE_MEMBER(cool, int)
        DECLARE_MEMBER(cool, double)
};