QtCreator automatic member declaration

[akiross]

Hello,
I've started using QtCreator, but there are some things I feel lacking.

For example: suppose there is a class "Widget" and I'm adding a new method to it.
Usually one have to add the declaration in the widget.hh and the implementation in widget.cpp.
But it's so slow... Is there a way to ask QtCreator to automatically add the relative declaration for the method I'm writing?
If not, is this feature under development or something?

Thanks
~Aki

[SixDegrees]

I'm not aware of any tool that can automatically create declarations; such a feat would require mind reading, at a bare minimum.

Given a declaration, it should be possible to automatically provide a stub implementation. But there are a lot of assumptions involved even with this: a source file must be created if one doesn't already exist, but this is tricky because implementation can be spread across several source files if desired. Also, implementation within the header file is also legitimate in C++, and depending on compiler such an implementation may have certain advantages over one placed in a separate source file. Then there's the matter of templates; what to do about potential specializationts? Where should they go? What about partial specializations? Should common operations like assignment, copy and initialization be stubbed out, provided with partial implementation, or be left unimplemented? And the list goes on.

C++ is a complex language, and coming up with a solution that would please all users in all cases is essentially impossible, as are the chances of coming up with a solution that would please even a significant fraction of users.

If you have a particular approach that would work well in your particular case, though, you can search for lex-compatible C++ language templates and build your own.

[squidge]

If you have a non-express version of Visual Studio then you can use Visual Assist to do that for you. Either you create the implementation and it'll create the definition in the class, or you create the definition and it creates you a stub implementation. It's still not automatic however, you write one or the other and then click "Refactor->Create implementation" (or whichever, which you can probably put on a hotkey should you want less work, but by default its on the context menu). I find it quite useful, but it can be annoying if you like bulk operations, ie. if you just wrote a page full of definitions and you want implementations creating for each of them before testing the build as it'll swap to your source code every time, so you have to go back to the header file each time. 'Create Definition' isn't quite as smart as it usually puts it in the wrong place requiring you to copy and paste it in the correct place.

At home I just write all the definitions and then copy/paste them into my source file and run a macro to change semicolons into brackets and add the class names to the start of each function. Works 95% of the time. Others the result needs a bit of manual tweaking.

[wysota]

Actually Qt Creator indeed can do it If you write the implementation of the method and right click on it and open the refactor menu, an appropriate entry should be there (called "Add public declaration" or something like that).

[akiross]

Many thanks wysota. It was exactly what I was looking for! It's a pity it's not shortcut-able (at least, can't find it in the unmapped shortcuts) nor automatic.
...Now I'm just missing the auto-inclusion... Do you have a solution, too? XD

I'm not aware of any tool that can automatically create declarations; such a feat would require mind reading, at a bare minimum.

LOL Probably you just didn't get what I said or I just said it in an unclear way Anyway the idea was the inverse: from an implementation, getting the relative declaration, apart - of course - the visibility of the method which is unspecified in the implementation itself.

Thanks everyone
~Aki

[wysota]

...Now I'm just missing the auto-inclusion... Do you have a solution, too? XD

To be honest I don't see that happening. How would the IDE know in which file a particular class is declared?

[akiross]

Well, of course headers could be indexed (at least Qt ones), as the code in headers is usually free available.

Anyway in Qt you can usually include each class separately:

#include <QList>

and this kind of inclusion is straightforward to do on a single file, but this may lead to multiple inclusion - but could work for a "light and fast method" when prototyping.

So probably the matter is a bit more complicated, requiring to partially-compile the source to check; specifically, it's possible to do so by just pre-processing the source code with the compiler and check for header presence there. But probably that's getting a bit too complex... Anyway, Eclipse can do that with Java (dunno with other languages), although Eclipse uses compiler and probably some kind of library inspection (which, I think, is some kind of indexing).

[wysota]

Well, of course headers could be indexed (at least Qt ones), as the code in headers is usually free available.

Indexing is not enough. Consider the two files:

// a.h
#ifdef STH
class Class {};
#endif

// a.h
#ifdef STH
class Class {};
#endif

To copy to clipboard, switch view to plain text mode 

// b.h
#ifndef STH
class Class {};
#endif

// b.h
#ifndef STH
class Class {};
#endif

To copy to clipboard, switch view to plain text mode 

Which would you include when using "Class"?

Anyway in Qt you can usually include each class separately:

#include <QList>

I really hate the word "usually" here. What if I have my own class called QList, possibly in a separate namespace imported into the main namespace with "using namespace x" that's declared in "mycustomqlistimplementation.h"? What if I had a class "SomeClass" that would really be a define or a typedef to "QString"?

and this kind of inclusion is straightforward to do on a single file, but this may lead to multiple inclusion - but could work for a "light and fast method" when prototyping.

Unfortunately it would backfire for 1) advanced people who know what they are doing and 2) newbie people who have no idea what they are doing. Good software has to work and not "usually work", that's not Windows which usually works.

[akiross]

Good points. Anyway I guess you can agree on the fact that when no conflicts are presents, there are no problems.
An algorithm that I really like is "do the sure things automatically and let the human solve the unsure things".

BTW, in Eclipse class name clash is not infrequent, so of course you point out important problems.
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. 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.

Good software has to do things right. No matter how often (usually, rarely, always).
~Aki

[tbscope]

"do the sure things automatically and let the human solve the unsure things".

Beautiful last words.

Unfortunately, reality doesn't allow you to do that.

[akiross]

Beautiful last words.

Unfortunately, reality doesn't allow you to do that.

Please, tell me: why not?

[tbscope]

Please, tell me: why not?

As soon as you have an unsure thing, the sure thing becomes unsure.

Examples:
I can do technique A in one and only one way, A1. But, after a while I find another way to implement technique A, using method A2. How are you going to automate this?
I can do technique B in one and only one way, B1. But, after a while I find a little flaw in the logic and B1 doesn't seem to cover all the details needed to implement technique B. How does the automation cope with that?

I guess you can build some huge neural network with some kind of artificial intelligence.

I have some experience in automating machines (production machines in factories) using Programmable Logic Controllers (PLC's).
The degree of complexity to automate machines is huge. It is practically impossible to get everything right. Edit: I must say that it is impossible to create standard code for each and every machine. You can have standard building blocks, but when you're busy automating a machine, you'll always have to adjust some parameters in those building blocks, or even add additional ones.

I agree that automation is helpful, needed and makes our lives easier. The problem is implementing that automation that is extremely difficult.
You might only see it as just automatically including a header or creating a stub in your source code. However, as demonstrated above, that is just one way you could automate a process like this.

Edit: by the way, this is just my personal opinion of course, don't take it as anything else.

[akiross]

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.

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.

So is the software: if you write a (correct) piece of code, it will always work. If you found something new, you can write more software to cover the new cases, but this doesn't mean that the old cases doesn't hold anymore.

Luckily we can use mathematics to keep "sure things reasonably sure" until a new math is found (but, I bet you agree with me, this is very very unlikely). So once you're program is sure (and bugfree), it won't change.

What change are requirements, and this means that new algorithms have to be written. But this is another matter. If you build an algorithm to find all the headers file that describe the class "Foo", that algorithm will never change.

Well, you see, neural networks and artificial intelligence comes here exactly not to do what I said
I said: "sure thing automatically, unsure things by the human". NN and AI comes to do unsure things, to replace human in some way (I'm not saying it's a bad thing).

Of course, as you say, the world is complex and the automation is complex too. For example, if I show you a picture of a person we both know, you may or may not recognize the same person I recognize in that picture. This is unsure thing. You can program a computer to try to do the same (and, sometimes, computer can be much better than humans in doing these tasks), but the result of an "unsure-computation" will always be a likelihood valutation (i.e. a probability).
If I ask you to do a "sure-computation", you cannot reply with probability. If I ask you to find the highest number in a sequence, or all the documents that match a word, you will either succeed or fail, but there is not a "degree of correctness".

All this to say: it is very possible to automate things. Indeed computers DO automate certain things and we are still working to automate uncertain things to help humans.

I think reality allows you to do that (i.e. automate the sure, let human to resolve the unsure). Of course, you must agree on what is "sure" and what doesn't
I think that including an header is mostly an automatic work which is sure once you've enough informations to uniquely identify the subject of the inclusion. That is, if you want to include "Class" but there is a conflict, it's automatic to ask yourself "A::Class or B::Class?". The machine can ask it to you (since it cannot read minds, afaik ) and all the doubts are gone.

Ok, sorry for the wall of text

[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).

[SixDegrees]

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

Sadly, there is no such thing as a "correct" piece of code. See the Halting Problem, proven by Alan Turing, for an introduction. Continue with Gödel's Incompleteness Theorem.

[akiross]

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.
(cut)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.

Wait, what are we talking about? The fact that automation may speed up my coding process OR the fact that an lazy/unaware user will fail in using the automation?
The problem is not that automatic tools are bad, the problem is that choice is good. I (me, myself) would like to have an auto-include feature in QtCreator. You think that lazy/unexperienced users may fail in using it? Well, so just do as auto-declaration/definition: not making it "auto" but having a tool to do it with a right click

Another simple example

Thanks, there's no need for examples: as you, I can think a lot of cases in where automation will NOT aid unaware users. But this is the fact: unawareness is the problem, not automation.
Automation is a double-edged weapon: it can be really useful if you know what you're doing.

Being accustomed to Eclipse - which has such a feature - I would accept it gladly also in QtCreator. It's something that now I can use and appreciate like code completion: of course I could avoid using it, but it's faster, and I like to be fast in writing code.

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)".

Ahah nice But I don't think that it's the case. You know, Whitehead said "Civilization advances by extending the number of important operations which we can perform without thinking of them". This is why studying is more and more important in our society: because if the button exists is ok, but we must be sure to understand why the button is there and why we have to learn anyway.

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.

Sorry, I don't think I've ever said "without even knowing". Au contraire, I said "asking the user". I don't see why asking a question and avoiding to write some words would be "too smart" or "too risky". On the other hand if you write an class twice in two includes, you may also fail without knowing. So, there are also cases in which an automatic control may help to include the right thing.

You see the point is people forget about it even if they don't have this magic tool.

I don't. This is what I call "automatic and tedious work" and I program the machines to do it for me. Everytime I include an header file - writing by hand - for a class that is not ambiguous, I think "in the time I'm wasting writing these headers I could solve bugs or add new features".

The tool has to augment and not replace skills.

This is a nice phrase, but did you thought it through? Do you have the skills (not knowledge) to do everything that an automatic tool is doing for you? Why do you use compilers? Why do you use C++ and not programming directly in hex in your computer? Maybe you do. But the fact is that for some jobs skills are simply not required anymore. That may be sad, but it's true. I bet you would be dead as me if civilization will fail tomorrow and we would go back to the stone age.

According to the laws of logic if there is at least one case when a hypothesis fails then the whole hypothesis is invalid.

Oh please, before talking about logic PLEASE read carefully what I said. I didn't said "your premises were false" or "the hypothesis didn't hold". I said "Knowing new things"... Feel free to use set theory to prove that I'm right (or wrong, if you can).

And who defines that a piece of code is correct?

Math is usually a valid reference for correctness of a problem. See lambda calculus.
That code you wrote is right for b not equal to 0 and for non-overflowing integers. There is no problem with the code. The problem is assuming superficially that the code is correct for every value of a and b.
It's like the fraction a/b, real numbers: it's perfectly legal and always defined on its domain. The error - often done - is thinking that a fraction is defined with denominator equal to zero.

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".

Actually, when writing that, I wasn't thinking to Dijkstra, but to Hoare and Church.

(someone might add a situation when b IS assigned 0 and your original "correct" code fails)

Ehehe that's a nice case You couldn't say that MY code is not correct after someone else edited it.

Anyway, the starting topic was: I would like QtCreator to have a feature to auto-include headers. I don't know how we come to this point, but my request is still valid, because I don't think that is such a feature that compromises the learning career of the next generation of programmers. I hate to write headers and Eclipse has been the only IDE that I really appreciated about this - but I understand that Java is a radically different environment so such a feature may be missing in QtCreator forever

---

Added after 11 minutes:

@SixDegrees, already done. Did you forget partial correctness?

EDIT: Anyway, I think your reference to the Halting problem and Goedel was a bit too general. There is no need to talk about total and partial correctness when the reality is that we are mostly interested in trivial properties on the natural numbers. Of course, Rice's theorem says that non-trivial properties are not decidable, but we all know that even if they are very numerous, we are interested in a small subset of properties - and even those give us issues.
Anyway, I think the validity of the Halting problem is mostly to be considered in the general case: you can prove the correctness of (for instance) a simple bubble sort. As I said (to wysota), formal methods for testing correctness do exists, for example lambda calculus or Hoare logic (which are the only one I know and used).

[wysota]

Wait, what are we talking about? The fact that automation may speed up my coding process OR the fact that an lazy/unaware user will fail in using the automation?
The problem is not that automatic tools are bad, the problem is that choice is good. I (me, myself) would like to have an auto-include feature in QtCreator. You think that lazy/unexperienced users may fail in using it? Well, so just do as auto-declaration/definition: not making it "auto" but having a tool to do it with a right click

If using the tool requires a concious decision in each and every case then I have nothing against it and implementing it for simple cases is a trivial thing to do.

Thanks, there's no need for examples: as you, I can think a lot of cases in where automation will NOT aid unaware users. But this is the fact: unawareness is the problem, not automation.
Automation is a double-edged weapon: it can be really useful if you know what you're doing.

I couldn't agree more. Unfortunately here we're dealing mostly with people who'd like to use Qt (and tools that go with it) to its full potential with a minimum effort on their side (the most common phrase on this forum is "I'm a newbie in Qt and C++") so I may be biased. On the other hand there are experienced people who suggest inexperienced people to use solutions they do not understand so I'm forseeing questions about code not compiling because of missing includes (of course without understanding that missing includes are the problem) and an answer such as "right click and choose 'insert missing include' from the menu". That's a straight road to encountering a situation when such an automatic include fails for some reason and the newbie ending up here or elsewhere saying "my program doesn't work" (and no details).

Ahah nice But I don't think that it's the case. You know, Whitehead said "Civilization advances by extending the number of important operations which we can perform without thinking of them". This is why studying is more and more important in our society:

Unfortunately what we observe in practise is quite the opposite - people on average are becomming dumber and dumber because they can't do simple things without help from a machine that does it for them. Of course there is an elite who can do all that and they drive the civilization forwards but we're rarely dealing with "elite" in everyday life.

because if the button exists is ok, but we must be sure to understand why the button is there and why we have to learn anyway.

First one has to learn that if the button exists and all one does is push the button then one is obsolete as we can automate button-pushing as well. Still many people fail to see that yet they call themselves "professionals" ("I'm a pro button-pusher? Hmm.... naaa.... I'm a pro software developer!").

Sorry, I don't think I've ever said "without even knowing". Au contraire, I said "asking the user".

Point taken. As I already said, asking the user is ok.

I don't. This is what I call "automatic and tedious work" and I program the machines to do it for me.

That's fine with me but there are more people than just you. If you provide a general mechanism you have to be aware that the general population will be using it and most of it will not be part of the "elite" I mentioned earlier. Sometimes it is best to learn by your own mistakes. If you have a tool that corrects mistakes for you all the time then you will never understand what you are doing wrong. If you do understand then such automation is fine. This is an educational aspect vs engineering aspect. Once you are a qualified engineer, automation helps. But earlier it prevents you from becoming a qualified engineer.

Everytime I include an header file - writing by hand - for a class that is not ambiguous, I think "in the time I'm wasting writing these headers I could solve bugs or add new features".

Then you are either a very lousy typer or an excellent bug chaser.

This is a nice phrase, but did you thought it through?

Yes, I did.

Do you have the skills (not knowledge) to do everything that an automatic tool is doing for you?

When it comes to programming? Probably yes.

Why do you use compilers?

I see where you're going but that's a blind path I'm using a compiler because I'm using a language that requires compiling. It doesn't mean I wouldn't be able to repeat what the compiler does if I had to, provided I had time to do it. I understand how computers work, how programs are executed, why they fail and how to fix it. I'm using Qt Designer not because I lack the skills to implement a class manually but because the time required to do it is much shorter (and you can't compare it to bug chasing and adding an include statement). When placing a widget on a form I'm aware of exact C++ statements my actions cause. Unfortunately many people simply can't do something in code and they rely on Designer (Creator, button, whatever) to do it for them. That's what I mean by augmentation vs replacement.

Why do you use C++ and not programming directly in hex in your computer?

Yeah, that's a blind path. I use C++ but I understand that it is then translated to binary and how it is executed.

But the fact is that for some jobs skills are simply not required anymore. That may be sad, but it's true.

I don't agree. You may not posses the manual skills but you should know the skills are there. If you have a car, you should know that it has an engine and how (more or less) it works. If your car stops in the middle of nowhere you will either be able to check basic things (such as if there is gas in the tank) or be stranded until help arrives. Sure you can consider this knowledge obsolete and just wait for assistance but then I won't consider you a person that "knows much about cars".

I bet you would be dead as me if civilization will fail tomorrow and we would go back to the stone age.

I would be terribly bored but probably not so much dead, at least not that quickly. I may fail to implement my knowledge but then my knowledge may help me find someone who can.

Math is usually a valid reference for correctness of a problem.

But you need a formal math model of the problem which is not a trivial thing to obtain. I doubt you make formal models of each piece of code you write.

That code you wrote is right for b not equal to 0 and for non-overflowing integers. There is no problem with the code.

Sure there is a problem with the code. You have some constraints you do not check. You are implicitly assuming (hoping?) they will hold. The fact that code "works" doesn't mean it is "correct". The fact that the code is correct in some conditions doesn't mean it is correct in general so if you do not enforce the conditions you can't say the code is correct. If your program fails to check the conditions prior to doing some operation then it is buggy, incorrect.

Ehehe that's a nice case You couldn't say that MY code is not correct after someone else edited it.

The fact that you cannot prove incorrectness of a theory doesn't validate the theory (and your code uses "b" and does not "create" it so no change of your code is required to make it fail). It works the other way round. You can't say your drug is effective if you only give it to healthy people and see they don't show symptoms of the disease. And your drug doesn't become ineffective when you give it to someone ill and it doesn't work (or kills the poor guy). It has always been ineffective, there was just no proof of that.

Anyway, the starting topic was: I would like QtCreator to have a feature to auto-include headers.

When you're done implementing it, let us know where we can download the plugin from, I'm sure many people will benefit from it.

[akiross]

If using the tool requires a concious decision in each and every case then I have nothing against it and implementing it for simple cases is a trivial thing to do.

When you're done implementing it, let us know where we can download the plugin from, I'm sure many people will benefit from it.

The problem is that I've no much time for coding and I (sadly) prefer keep on with something that noises me (i.e. lack of an automatic feature like this) instead of "wasting" my time learning QtCreator's internals and developing an extension. It's not really a waste, but knowing myself (short-memory) and my objective, doing that wouldn't be productive. If someone knows QtCreator and likes to implement this feature, I'll gladly accept it, but it's just not my role to make it. Do you make your car better just because you think it can be improved? I don't think, even if you could be given enough time.

I couldn't agree more. Unfortunately here we're dealing mostly with people who'd like to use Qt (and tools that go with it) to its full potential with a minimum effort on their side (the most common phrase on this forum is "I'm a newbie in Qt and C++") so I may be biased. On the other hand there are experienced people who suggest inexperienced people to use solutions they do not understand so I'm forseeing questions about code not compiling because of missing includes (of course without understanding that missing includes are the problem) and an answer such as "right click and choose 'insert missing include' from the menu". That's a straight road to encountering a situation when such an automatic include fails for some reason and the newbie ending up here or elsewhere saying "my program doesn't work" (and no details).

Your point is valid, but sometimes I had to remember myself that openness is good (it's good if someone wants to learn and I can help), but I also have to remember that programming is not for everyone. I know people who practiced for years in programming (even ones with a master degree), but they can't obviously write a "good" piece of code. With computers and internet diffusions, people will try to use them (as I did myself many years ago) without understanding what they are doing. In this case, natural selection applies. If one starts programming without knowledge of Qt AND C++, well probably should try a more serious path and check if programming is what he really want to do.

Unfortunately what we observe in practise is quite the opposite - people on average are becomming dumber and dumber because they can't do simple things without help from a machine that does it for them. Of course there is an elite who can do all that and they drive the civilization forwards but we're rarely dealing with "elite" in everyday life.

This is a consequence, I think, of what I said above. But being computers an established technology, I think it's common that someone starts using them, starting to understand and know them and finishing (maybe) with studying them and understand all what's below the surface. Computers are so complex that it's normal to have "elite" and "noobs". You just can't avoid that. So, give that button: good people (both experienced and unexperienced) will do good things with it.

That's fine with me but there are more people than just you. If you provide a general mechanism you have to be aware that the general population will be using it and most of it will not be part of the "elite" I mentioned earlier. Sometimes it is best to learn by your own mistakes. If you have a tool that corrects mistakes for you all the time then you will never understand what you are doing wrong.

But you can learn and try to understand!! This is what make "the elite": even if one is unexperienced, you can tell he's "elite" when he goes deep and improve himself and his knowledge!

Then you are either a very lousy typer or an excellent bug chaser.

Ahaha probably the first But usually co-workers say I'm fast in writing code, so maybe I just "feel" the pain in the ass in wasting writing time. Anyway, to add an header implies moving up and down in the code, losing focus, etc. It's not really something I can call "funny to do" even if it's short. Anyway, even if it was a single second to include one header, imagine how many seconds would you save in your entire career.

I see where you're going but that's a blind path
(cut)
Yeah, that's a blind path. I use C++ but I understand that it is then translated to binary and how it is executed.

I don't think it's a blind path: my point was to show that automation is extremely complex and present in a number of levels. It's very good if you can understand how things work, but I think it's even better if an automation can be introduced without compromising your understanding. Now, with introduction of namespaces C++ has did a great thing: provided a structure for organizing code which goes beyond the "file level". I'm trying to say that, since the language has the features required to uniquely identify a piece of code, why are we required to handle files with a preprocessor and include them? I think that we have the tools to automate completely and without ambiguity the inclusion process, and I think it's the kind of automation that could help programmers, hiding something that doesn't really need an understanding, but which can be understood easily if you want to (and this choice, to learn or not, is legitimate, even if experienced programmers may agree that it's better to know it).
Do you get what I'm saying? As instance, let's compare C++ and Java on this aspect: in C++ you write classes in a namespace, in Java in a package. In C++ you include FILES, in Java you import CLASSES. The fact that Java handles a class in each file with the same name is irrelevant to the fact that the Java compiler automatically finds, in the classpath, what you need. In C++ we are still handling files. And THAT'S GOOD, but I'm saying that this process is often tedious and can be automated because C++ provides the foundations to build such an automation

Sure you can consider this knowledge obsolete and just wait for assistance but then I won't consider you a person that "knows much about cars".

That's my point: you can, it's not wrong. Personally, I'd really like to be an engineer who's capable of fixing EVERYTHING is broken, from a microwave to a space shuttle. But I just can't. I don't consider myself a good programmer and code is the thing I most care about So it's inevitable that sometimes, somehow, some automations and technology are unknown, in a Black Box. It's inevitable. You can have an understanding about how they work, but you'll never have the skills about everything. You could try, and I admire people who does, but it's not realistic: humanity has so much knowledge that something is constantly out of our reach. Being conscious of this, our society is divided in "areas of expertize" and it's all-right with the fact that I can't fix a car. You can call me an idiot because you can while I can't, but you're not more right than me.

I would be terribly bored

Eheh curious, I would be thrilled Would be fun to see if everything I've always studied *in theory* can be made to work.

But you need a formal math model of the problem which is not a trivial thing to obtain. I doubt you make formal models of each piece of code you write.

Indeed I don't. But this is going a bit far from the original topic: I was just saying that if a code is correct, no further knowledge can compromise it. "New knowledge" doesn't mean "changing requirements".
Code doesn't change: what changes is our view of things (i.e. requirements) and code meaning. In fact, you say:

Sure there is a problem with the code. You have some constraints you do not check. You are implicitly assuming (hoping?) they will hold. The fact that code "works" doesn't mean it is "correct". The fact that the code is correct in some conditions doesn't mean it is correct in general so if you do not enforce the conditions you can't say the code is correct. If your program fails to check the conditions prior to doing some operation then it is buggy, incorrect.

And this is the point: correctness is not "general", but it's very, very specific about some "requirements" or "specification". It's wrong to say that your code works for EVERY integer, but if I say you to perform a division between two positive, non-null and less-than 1000 integers, that code works indeed. What is wrong is not the code, it's the assumption that the "everything I tested so far is everything it can be tested". I wasn't talking about "it works", but "it's correct".
And, to conclude, this was NOT was I was implying. I was saying to tbscope that automation do works, that it's reliable and that we actually are using it effectively. What does change is not the automation, but are our needs. And this is why I think my sentence he quoted in post #10 still holds.

The fact that you cannot prove incorrectness of a theory doesn't validate the theory

Never said that I said "You couldn't say that MY code is not correct after someone else edited it." which means that after editing you can no longer guarantee the correctness of the original program. Which it's obvious.

[wysota]

Do you make your car better just because you think it can be improved? I don't think, even if you could be given enough time.

Don't tempt me, I'm close to doing exactly that.

In this case, natural selection applies.

You have taken it out of my mouth, I wanted to write that in the previous post Unfortunately natural selection is an evolutionary and not a revolutionary process and sometime I am wondering what will come first - the weak will die out or I will shoot myself in the head (thus becoming one of the weak).

So, give that button: good people (both experienced and unexperienced) will do good things with it.

Unfortunately the remaining 90% of people will come and complain the button does something else than they expected.

But you can learn and try to understand!! This is what make "the elite": even if one is unexperienced, you can tell he's "elite" when he goes deep and improve himself and his knowledge!

True, but learning takes time and people are expecting quick results. These two don't go together well. Giving them buttons promotes quick results which demotes learning which brings more "noobs" and less "elite". At the same time you need to be considered a professional to have a job thus more and more noobs consider themselves pro. That's a blind circle, if you ask me.

Anyway, to add an header implies moving up and down in the code, losing focus, etc.

Learn Qt Creator shortcuts, they come in handy, especially the ALT+Left and ALT+Right combos.

Anyway, even if it was a single second to include one header, imagine how many seconds would you save in your entire career.

Well... you can always use precompiled headers and use things such as #include <QtCore>. This saves even more time.

I don't think it's a blind path: my point was to show that automation is extremely complex and present in a number of levels.

Nobody argues with that. The point is at some point you might reach a situation when understanding of low-level mechanisms is required (or beneficial) to do things the right way. There are countless people who think that a single line of C++ code is executed atomically by the CPU and are very suprised when they tackle against multithreading issues. Automation makes people lazy. Automation is good but you should be aware that automation does take place here and you should know what it does. Lots of people (like here) think that including a header file is enough to use external libraries. That's the result of implicit automation provided by IDEs.

I think it's even better if an automation can be introduced without compromising your understanding.

No argument here. I'm just worried about the "if" here.

I'm trying to say that, since the language has the features required to uniquely identify a piece of code, why are we required to handle files with a preprocessor and include them? I think that we have the tools to automate completely and without ambiguity the inclusion process,

No, you're wrong. A simple situation - C++ is (and will be in forseeable future) compatible with C thus you have to support pure C code. Furthermore C/C++ are quite flexible languages that do not require practically any strict environment. This is not the case with Java, Python and similar languages. There you don't need include statements but you require files to be in proper places and/or to be named according to a strict predefined pattern.

That's my point: you can, it's not wrong.

As long as you don't work as a car mechanic, it's fine. It's not fine if such a person starts "repairing" my car.

Eheh curious, I would be thrilled Would be fun to see if everything I've always studied *in theory* can be made to work.

I mean I would be bored because I couldn't do lots of things I do everyday

Indeed I don't. But this is going a bit far from the original topic: I was just saying that if a code is correct, no further knowledge can compromise it.

But since you don't know that the code really is correct, you cannot make statements about it.

And this is the point: correctness is not "general", but it's very, very specific about some "requirements" or "specification".

Yes. But you have to provide those "requirements" and "specification" and you have to ensure the code is executed within boundaries specified by them. If you don't do that, you're assuming a general correctness. If you say "people fly" then without asserting that you mean that they can control machines that can fly and in remaining conditions people don't fly (yeah well... the might -- straight down) the statement is false. If you say that the result of dividing (/) two integers is an integer then without asserting the denominator isn't 0 your statement is false.

Never said that I said "You couldn't say that MY code is not correct after someone else edited it." which means that after editing you can no longer guarantee the correctness of the original program. Which it's obvious.

But you don't have to edit the code.

int main(int argc, char **argv){
  int b = atoi(argv[1]);
  int a = 7;
  int x = a/b;
  return x;
}

int main(int argc, char **argv){
  int b = atoi(argv[1]);
  int a = 7;
  int x = a/b;
  return x;
}

To copy to clipboard, switch view to plain text mode 

Is this code correct or not? To me you can't say it is correct without showing how you ensure that the program is always ran with a parameter that is not 0. And since in a general case someone may take your code and use it differently than you expect it, you can never assert that and thus the code is incorrect.

[akiross]

Don't tempt me, I'm close to doing exactly that.

Well I can't guess the great wysota can do that : ) From what I can see on this forum, you can freely abandon Qt and start doing something else ([EDIT] Gee in a good sense! : D). But can other people do the same? I can't!

Unfortunately the remaining 90% of people will come and complain the button does something else than they expected.

I wouldn't bet on that... 90% will come and complain at the beginning, later on they would probably get how it works and, in future, they will be the ones - like me - that come to a forum asking if a certain feature exists. Usually you expect something because you're used to it, not because it's counter-intuitive. I'm sure you know as well as me that most users don't like to switch even if the future is bright and better - just because learning, as you said, costs time and effort.

Learn Qt Creator shortcuts, they come in handy, especially the ALT+Left and ALT+Right combos.

Mmmh actually I knew the Back/Forward, but I'm not really loving it. Probably I'm missing something about how it works or I'm just not used to it. Anyway, since you point this out, I'll give it a more deep try.

Well... you can always use precompiled headers and use things such as #include <QtCore>. This saves even more time.

True, but afaik this results in bigger files to compile, slowing down the compilation process. I'm sure that in my personal project I can do that, but I heard of cases in which compiling time was critical (someone told me that he could cut down the compiling time from hours to minutes just by working on include files. This isn't a surprise when it comes to C++ template system).
So, it's a good suggestion in my particular case, but generally speaking this is the kind of automation that may produce bad results if someone don't know what he's doing.

Lots of people (like here) think that including a header file is enough to use external libraries. That's the result of implicit automation provided by IDEs.

I remember I did the SAME exact error when I started to learn C It's like 10 years now, but it's not only a matter of automation: I used to program with notepad and compile by hand, but the manual I was using just didn't mention what a "library" was.

No, you're wrong. A simple situation - C++ is (and will be in forseeable future) compatible with C thus you have to support pure C code.

Sure (err almost: I think Stroustroup said that 99% of the C is compatible with C++ or something like that) but the fact that C++ is more flexible than Java isn't a restriction. I'm saying that, with evolution of C++, new approaches can be used. I'm absolutely not saying that I want to remove such features, but I'm saying that (I think) those can be used differently.

As long as you don't work as a car mechanic, it's fine. It's not fine if such a person starts "repairing" my car.

Eheh but even here we have elite and amateurs. I'm sure Ferrari Corse's mechanics are the best of the best among all mechanics, but probably to fix 50% of the car issues you don't have to know how to build an engine. In some sense, that could suffice: even if you start fixing your car, you would need a long experience before becoming a real expert in car fixing (especially if you plan to practice only on your car, which hopefully don't break so often lol). Here I'm saying that, even when one does it as "professional", there are different degrees. For example, I know a "professional programmer" that does what I can call "trivial work" with PHP and visual basic, but still he has costumers, because his competence is sufficient for some tasks. The market doesn't care if he's the elite or not. Elite, on the other hand, do cares about the quality of its members.

I mean I would be bored because I couldn't do lots of things I do everyday

Ahh ok Well, but surviving and recreating all the known technology is somewhat very appealing, isn't it? Knowing the past and having an occasion to do better things since the beginning! Woot!

But since you don't know that the code really is correct, you cannot make statements about it.

It seems you continue to don't get my point XD Let's say I ask you to write a software to keep data of my company. I need to pay the bill of my workers, so everything I need to do is sum a positive wage of every worker and print something.
If your software crashes with negative wages, it is still correct, because I'm not asking you to handle negative values. This is my point: it doesn't matter if the "absolute behavior" is "unexpected" (and thus, you can call it "wrong"). What it means is that the code is right when you ask it to do what you need to to.
If in a future society we have negative wages, I can't say that your code is wrong, because a(n implicit) specification was that "wages are positive". After the new knowledge (in future), you can say "that program doesn't satisfy our NEW needs", but it's still working and correct for the requirements it was designed for. Without a formal definition, the code is correct iff the output on tested cases is complying with the specification. Of course, this means that if code and tests were poorly programmed, the software may be used in untested conditions (and thus the program will show itself incorrect), but it may also be that the program will be NEVER tested and used outside such conditions and thus it will never reveal to be fallacious. I don't know you, but if a program does always produce the correct result it will be correct - no matter if that "always" covers only 1/10 of the possible inputs. It's still always.

Yes. But you have to provide those "requirements" and "specification" and you have to ensure the code is executed within boundaries specified by them. If you don't do that, you're assuming a general correctness.

No sorry, I can't absolutely agree with that. If no requirements are set, multiple interpretations are legit. Correctness is a function which must depend on requirements and specifications, if you don't provide them, you're not talking about correctness.
This is why, I think, being a requirement engineer is so hard

If you say that the result of dividing (/) two integers is an integer then without asserting the denominator isn't 0 your statement is false.

Actually, in mathematics division is not defined with a denominator = 0, so it's perfectly legal to say "for any integer": talking about "division by 0" is a non-sense. The result simply doesn't exists, so specification is not required.
This doesn't exclude, of course, the fact that you can instruct the computer with a nonsense (i.e. divide by 0) and it will fail.

But you don't have to edit the code.

int main(int argc, char **argv){
  int b = atoi(argv[1]);
  int a = 7;
  int x = a/b;
  return x;
}

int main(int argc, char **argv){
  int b = atoi(argv[1]);
  int a = 7;
  int x = a/b;
  return x;
}

To copy to clipboard, switch view to plain text mode 

Is this code correct or not? To me you can't say it is correct without showing how you ensure that the program is always ran with a parameter that is not 0. And since in a general case someone may take your code and use it differently than you expect it, you can never assert that and thus the code is incorrect.

Your question is really funny, because you didn't provide me the interpretation of "correct".
On one side, I can say that this program is correct for every input: as it returns the correct division between 7 and b, where b is a valid input integer. Also it correctly aborts when b=0 or when atoi() returns 0 for unreadable inputs.
On another side, I could say that if you EXPECT the program not to crash on invalid input, this program is not correct. But, as you see, I had to specify something to EXCLUDE correctness.
You say it's not correct because you're assuming that it's wrong for a program to abort when a division by zero is performed (and note that this assumption is wrong from the code point of view). But since the alternative to crash is to produce a random value, or to hang forever calculating something that can't be calculated, I think program is correct.

Without specifications, programs just can't be wrong... Is like dividing by zero: correctness MUST be defined against a specification. If you don't have a specification (explicit, but also implicit of course), you can't talk about "correctness"... At least you can talk about "behavior depending on the inputs", but you can't classify a behavior as right/wrong without a measurement unit. You can't act illegally without law.