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