[Feature Request] Automatic Class generator

[Tloz]

Hello. Few days ago, I went back to C for an old project and I used Code::Block which has an interesting feature that creates the main part of your classes, just by asking you the members, writing them into the code, and adding getters and setters.

Here is a snapshot of the window that does it:

!http://i15.servimg.com/u/f15/16/17/33/57/captur11.png(class generator)!

This would be really time saving in qtCreator.

Thank you!

[tobias.hunger]

Please file feature requests in the "bug tracker":https://bugreports.qt-project.org/ .

The bug tracker makes sure that the relevant developers will see your suggestion. That is far from guaranteed here in the forum:)

[Tloz]

Well, thank you for the advice.
If an admin goes here, maybe he can lock the topic...

[utcenter]

Doesn't seem like that good of an idea - a lot of features are redundant and unnecessary, others are missing. All in all, such a tool might end up making a developer forget how to write classes, or never really learn in the case of a newbie, which will be the kind of person most tempted to use it in the first place.

[tobias.hunger]

I do not really like the UI either, but this dialog offers some things that are not available in Qt Creators new class dialog.

I do not think that setter/getter thing is a good UI... having some QuickFix to add getters/setters for a member variable makes more sense to me. That way the same mechanism is available when initially creating a class as well as when adding members to existing classes.

[DerManu]

QtCreator has a different approach to such things, in my opinion. Right-Click->Refactor, or faster, Alt+Return. So It would be really great to have that refactoring option on a member variable Create Getter and Setter which adds the needed getters/setters in .h and .cpp at the appropriate locations. Further, it may also create an appropriate Q_PROPERTY line.

The tricky part becomes positioning. QtCreator should try to understand the way the person writes his classes, i.e. look through the specific class header and find a bunch of "set[A-Z][A-Za-z]+\s*(" lines. This is the location of the setters, and the refactoring mechanism should add its setters there, probably in the order in which it finds the member variables (so it will need to parse them into an ordered list, too, and correlate that order with the order of the found setter functions in a fuzzy, robust manner). Then it needs to extract the position of the getters by looking for a bunch of functions that are named like the parts after "set" in the setter functions, with first letter lower case. That's the position of the getters and the mechanism shall add its getter there, again respecting the order of member variables.
The getter/setters in the .cpp file should be placed in the correct positions, too, and not just at the end of the file (this is already done relatively well via the current refactoring option when writing a new method declaration).
Further, there are many options, so It will probably also need an extra options page. For example, I only use const& parameters in the setters when it's a complex type, i.e. QRect and QString but not with int and double. Of course, the refactoring mechanism would only be of use to me, if it respects that, too. Else I'd have to correct all the output which will be as annoying as writing setters/getters myself. And options like having the default getter to just add the definition in the header, returning the member variable in one line: someType someValue() const { return mSomeValue; }.

I've done a quick search whether there's an easy plugin interface for adding own refactoring actions, but haven't found one yet...

[utcenter]

[quote author="Tobias Hunger" date="1359191066"]I do not think that setter/getter thing is a good UI…
.[/quote]

A while back I posted an idea about "integrating property support tighter in Creator, with a degree of boilerplate code generation":http://qt-project.org/forums/viewthread/23684/, but it didn't seem to catch any attention.

About that UI - doesn't the compiler like... always generate the big three defaults, even if you don't specify them? Also, I don't see how this dialog would help in the case of something like multiple inheritance.

Overall, I don't think CodeBlocks is that good of a role model, it is a dead and heavily dated IDE, whose feature set is hardly exemplary.

[tobias.hunger]

utcenter: Of course not, it is not in the bug tracker:-) I did read it, but I don't have any additional comments to make and then I promptly forgot all about it...

[utcenter]

Well, unlike some other people, I would not rush into suggesting something just for my sake - had the idea attacked more interest here, then I'd consider it worthy to forward as an official feature request. But something as significant as enforcing a naming convention, albeit the most useful and used one, is most certainly not a trivial matter that can go without discussing.