Default values for constructor parameters II


#1

Continuing the discussion from Default values for constructor parameters:

Although this was closed by Jules (May 2017) it’s not actually fixed. Fundamental, very annoying forcing you to do member initialisation in the ctor body. Please fix this!


#2

That was just closed because we were closing ancient threads, and this one is from 2009.

I’m struggling to understand exactly what the problem is - can you explain a bit more clearly?


#3

Pre-condition: create a GUI component in Projucer.

  1. Select the component .cpp file, then the ‘Class’ tab.
  2. Enter a parameter with a default value in the ‘Contrsructor Params’ box, e.g. mParam = 0
  3. Select the ‘Code’ tab (.cpp) and the generated code will show the problem, e.g. MyClass::MyClass (mParam = 0){… which fails to compile and should read MyClass::MyClass (mParam /= 0/) or similar.

Note: the header file generates correctly, i.e. MyClass(mParam = 0);

Please let me know if you need anything further.


#4

Oh, I think you’re expecting a bit too much there from the GUI builder, it’s not intended to exhaustively handle all possible c++ syntax that you might want to use, it’s just for quickly throwing ideas together. The easy fix is just to not use default parameters, which aren’t a particular great idea anyway, especially in constructors.


#5

This is good to understand. I’m currently assessing JUCE for use on a new project and was under the impression that I should use the Projucer for project management. From what you are saying it is merely a prototyping tool and not meant for commercial use - correct?
BTW: I don’t agree with your easy fix. If a code generator ties my hands from language use it quickly loses popularity and its efficacy.


#6

Please don’t confuse the Projucer’s project management with its GUI builder!

Yes, absolutely use the projucer for project management - that’s its purpose.

But the GUI code gen stuff is basically a legacy GUI builder that I made over 10 years ago, which we’ve kept alive because people still rely on it, but we’re not actively developing that bit. For serious GUI work, we’d encourage you to hand-code it yourself using more modern techniques like Flexbox, etc. We’re brainstorming other new, more modern ways (e.g. with scripting, reactive style etc) that we can make GUI design easy in the future, but it won’t involve this GUI builder!


#7

Thanks for the clarification and speedy reply!