Actually what Visual Assist does is in the course of typing p.something it 
auto-magically changes the . to a -> and vice versa.

I've never seen Visual Assist get it wrong either ... it even properly can 
handle (*p).bar without issue.  This is quite useful and would mean one less 
(in this case annoying) problem reporter error output :) (saving room for all 
your other errors)

Problem is still present in kdevelop 3.0 cvs HEAD.

Wouldn't it be better to implement a feature in code completion that automagically change the operator to the correct form (typing . change to -> if the var is defined as a pointer). That's how I'm used with in Windows/Visual Assist

Subject: Re:  code completion reacts on dot operator for pointer to struct

Hello Jacques,

Wednesday, January 14, 2004, 11:44:12 AM, you wrote:

JA> ------- You are receiving this mail because: -------
JA> You reported the bug, or are watching the reporter.
      
JA> http://bugs.kde.org/show_bug.cgi?id=46684      




JA> ------- Additional Comments From jacques.abada@arcanthea.com  2004-01-14 10:44 -------
JA> Wouldn't it be better to implement a feature in code completion that automagically change the operator to the correct form (typing . change to -> if the var is defined as a pointer). That's how
JA> I'm used with in Windows/Visual Assist
 

Looks a terrible feature to me! If I write statement foo->bar for
an  object, the editor would change it to foo.bar, but what if I meant
operator  -> ()? To check the class definition for operator -> () is
not a good solution, too, because one can intend to fix the class
definition later. There is no reason to copy the disturbing behaviour
of Microsoft user interface, which forces you to do things in the
way they like, not in the way you like.

Er ... Visual Assist is not from Microsoft but from a third party.  Second, I also mentioned in my comment #1 that Visual Assist is smart.  It rarely gets confused over which . or -> to use.  In fact, it's saved me many times by switching to the correct operator.  Thirdly, like most features like this, it's implemented such that if you come back to it later and change the . or -> it will not try to switch them again.  It's like that feature in some word processors that changes words to uppercase for you, even if not intended, but if you go back to change it to lowercase it'll leave you alone.  

It's maybe the feature that I hate the most in word processors, and in the development-environments-that-should-not-be-named. If using a pointer as a plain object happens often, I'd prefer to implement something like a tooltip saying to me what is the type of the variable I am using. 

IMO, passive information is useful, active actions are annoying.

(I love passive popups in KDE)

Seems to me that it's better to underline it with an error line when an impossible operator has been used.
Or some other error has been made, something that it does not do right now (at least not for c source files).
This in combination with a passive popup seems very usefull.

Thats odd because I _hate_ passive popups :)  Underlining errors is currently not possible right now but will be soon in the future.  This, however, is a no-brainer change if you ask me.  It should be fairly simple to switch to the right operator and it's saved me lots of times.  Compared to some of the things kdevelop is doing internally, this is pale in comparison as long as kdevelop gets the proper type of a variable (pointer or not) and then checks to see if it has overloaded methods.  I believe it's that simple to detect.

If you do change a definition later or switch variable types then, yes, underlining it and including it in the problem reporter output would be the right thing to do.  But as long as it can be changed as you type, then why not really?  It's going to do the right thing so why not let it.

The capitalization example was not really suited for this I guess.  But in this case it will always be correct in the 'current' context anyhow -- meaning if you were to compile right then and there it would complete successfully.

I'm also against actively changing the source code, it really never seems to work fully, and it's a lot of work for KDevelop if it needs to parse the source to understand pointers, further more it needs to update the parsed data every time something is changed. With passive pop-ups the data does not have to be 100% correct, as the user will understand that it's because it's how the source looked like to begin with, however with actively changing your source code it _must_ be 100% correct, so users don't have to struggle with the IDE.

A solution would be as you said, not to change it twice, however changing it once to often is too much to, and it's more code that needs to be implemented in KDevelop.

Stick to the passive pop-ups, or underlining.

Hmm, well passive popups and/or underlining require the same code infrastructure as the automatic switching from . to -> etc. (both need the same underlying information for decisions) ... but they are not to far from what _already_ happens.  Kdevelop already parses the classes and the code to fill in the auto-completion and the real-time problem reporter.  The only extension that needs to be done to the parser is also part of bug 68610.  That wish would bring kdevelop's parser more inline with Eclipse's (more featureful) and also makes note of a future kate interface to allow for underlining of text (I'm a part time dev for kate).  But the main wish is to parse the code more intelligently wrt variables and other constructs.

I'm also willing to say that it _is_ possible to get 100% accurate results for the switching.  I've seen Visual Assist get it right in very complex casting situations where both objects and pointers are involved.  If kdevelop knows enough to popup a message or underline the text, it knows the correct form anyhow.

Regardless, one small configuration checkbox would suffice as an option so that any user could decide for himself.

So what?
Could we all please sit down, have a cup of tea and calm a little down? As either side is insisting on their (good) arguments, this will soon end up in a totally unneccessary flame war - so let's please come back to facts.

Fact 1 is: KDevelop does currently not know about what kind of operations could be used on a variable. Thus it has to present code completion on either . or ->

Fact 2 is: All of you forgot: :: must also lead to code completion - and is even much complexer than . or -> is; if we're out of the scope of a function implementation, we need to show up all members declared in the classname before the double colun and/or all public symbols inside a namespacename before the class. The second one needs to consider all previous using directives to work correctly. If we're inside a class declaration, we need to resolve only namespacenames. And finally: if we're outside any scope, we need to present namespaces, all classmembers and namespaces.

Fact 3 is: Knowing such things is a very hard job. It's not like watching for variable declarations. Taking "operator*()", "operator->()" and "operator classname()" into account it's even worse. I have even written working code like: "if( var.isValid() ) var->doSomething();" It becomes yet complexer, if class templates come into account.

Fact 4 is: I have a project, where i have XML::Node and Tree::Node classes. I create instances of Tree::Node only via some garbage-collection aware smart-pointer template class. Thus "Node a; a." can be valid, if i'm "using namespace XML;". If i use "Ref< Node > a" and "using namespace Tree;" then: "a." "a->" "(*a)." "(**)a." "(*a)->" are all valid.

Fact 5 is: What about *-> and *. operators?

I don't think, that i catched up every problem/question that arises here.

So - what could we conclude out of this? This turns to be a complex wish.

If anybody comes up with an implementation that in fact works, i don't see a cause to not include it. Even if i would personally have it turned off at my side all the time - And it should be turned off by default UNTIL it is proven that it really works, even in border-line-cases.

Cheers Sascha

After all - this is still a "wish" and will still be present in kdevelop3.1

CVS commit by treat: 

* Only show completion when using the correct member access operator. ie,
for Foo *f; we show completion with f-> and for Foo f; we show completion for
f. ... and no other.

"And another one bites the dust!"

BUGS:46684


  M +73 -12    cppcodecompletion.cpp   1.162
  M +1 -0      cppcodecompletion.h   1.54