QtCreator automatic member declaration

[wysota]

Good points. Anyway I guess you can agree on the fact that when no conflicts are presents, there are no problems.

No, I can't agree. The fact that there are no conflicts at an arbitrary point in time doesn't mean there won't be a moment later and this invalidates this technique.
Let's follow my example - you have created a.h containing "class Class{};" and used class Class. So the IDE inserted an inclusion of a.h behind your back. 10 minutes later you decided that you need a different declaration of class Class that depends on existance of the STH macro so you edited a.h and possibly added b.h. But since inclusion of a.h was inserted behind your back, you're not aware that there is a possibility that you need to change it to b.h and so your compilation fails and you spend lots of time looking in wrong places because you were lazy enough not to include a.h yourself in the first place.

Another simple example - you have two classes - Fafafel declared in fafafel.h and Falafel declared in falafel.h. You write code and by mistake (or conciously) you declare a variable of a wrong class. The IDE gladly provides an include for you. But then you realize you really wanted to use the other class so you change the class name in the variable. And the IDE gladly includes the other file. But it can't possibly know it should remove the original include because it won't be able to trace dependencies on the original file that might have emerged in the meantime. At every keypress it would have to rescan all included files, parse them and try to determine with "good-enough" probability that this file is no longer needed. Your IDE would be busy all the time scanning files instead of compiling your software or aiding you in the editing process.

An algorithm that I really like is "do the sure things automatically and let the human solve the unsure things".

To me the algorithm that fits more to this situation is "if we can substitute knowledge with a button then let's get the button and don't learn at all (and fire the software developer)".

Nonetheless I think that often asking the user "do you mean A::Class or B::Class?" is a better option than leave the user to write all down.

I think my IDE shouldn't try to be smarter than me. It should help me but not do my work for me without me even knowing. For me it is enough to have a keyboard shortcut that when pressed will insert an include statement according to some predefined pattern. I want to be concious about what my IDE is doing.

It's not only a matter of speed, but also of method: having an automatic tool that does automatically things that you're usually doing over and over, let you to forget about those things and rely on the automatic tool. In other words: I would always be sure to include the headers - or to be asked to.

You see the point is people forget about it even if they don't have this magic tool. So if you give them such tool and they don't learn that they actually have to have a prototype of a symbol available, once you place them in front of an environment that doesn't have such capabilities, they'll be totally lost. The tool has to augment and not replace skills.

Mmh I don't think so. Knowing new things doesn't necessarily invalidate the things you knew before; it depends on how solid were your foundations.

According to the laws of logic if there is at least one case when a hypothesis fails then the whole hypothesis is invalid. I think that what you say here is wishful thinking - maybe in ideal world with ideal tools and ideal people using them everything would work as expected. But unfortunately the world is not ideal and nor are people developing software. Just browse the forum and see how many times people were completely lost about situations with a missing include. Also count how many times people were convinced that including a header file automatically links their application with implementation of functions declared in this file. These are pure examples of lack of knowledge. Sure you can try to substitute it with a button or a robot but then do we really need such software developers at all? Why aid them? Let's get rid of them (or ignore them) completely and focus on those who are bright, open-minded and skilled.

I'll make you an example, to clarify: Newtonian's mechanic was the SURE thing before relativity. The scientific method here is comparable to software development process: physics laws are theorized, found erroneous in some cases and then corrected. The process is iterative until the laws cover every known case. That's the same of writing a program with have some requirements, then bugs are found, and the program is bugfixed, until it's necessary to use that software.
But then Einstein comes in: he found something new, the relativity. But this discovery doesn't change the Newtonian's laws! Newton laws are STILL SURE and didn't change. Our mind changed: we thought that Newton's law was the only one, but after Einstein we found that it wasn't, still it is only a specific case in a more broad set of options.

But you have to learn and understand both laws and situations when you should use each of those and why. You can't use Netwon's laws and once you approach near-light speeds or near-quantum sizes and start cursing Newton or redoing your Newton-based maths looking for calculation errors blaming the whole world around you. You have to be aware that you reached some border conditions past which the law is invalid. Furthermore Netwon's laws are an approximation for Einsteins' in some well defined conditions, they are not some other alternative solution to "problem A".

So is the software: if you write a (correct) piece of code, it will always work.

And who defines that a piece of code is correct? I would rephrase what you said as "if you write a piece of code you think is correct, it will work until you reach a situation for which your assumed correctness is no longer valid". In other words if you have such piece of code:

int x = a/b;

int x = a/b;

To copy to clipboard, switch view to plain text mode 

then until you assign "0" to "b" you might think your code is correct. But it isn't (someone might add a situation when b IS assigned 0 and your original "correct" code fails). The world is full of people (and software developers in particular) who are sure their approaches are correct until they are proven otherwise by some very unhappy incident sometimes involving loss of life or some gigantic sum of money (like the infamous launch of a Mars probe a couple of years ago).