Introjucer / Projucer doesn't mark 'paint' and other GUI components' methods as override


#1

new Xcode keeps giving me warnings on jucer auto-generated code, like:

‘paint’ overrides a member function but is not marked ‘override’
‘resized’ overrides a member function but is not marked ‘override’

etc…


#2

But it does add ‘override’…? The code to do it is in GeneratedCode::getCallbackDeclarations()


#3

i just checked again and the auto-generated stuff seems to be working fine.

it’s when you create a new project in the projucer, the override is not always there. I didn’t test everything, but seems it is not there for the GUI app.


#4

Ah, maybe an override missing from the new file templates. Will have a look.


#5

Exactly, overrides are also missing when creating a new Component in the Projucer.


#6

It should really be marked final rather than override if we are being stickers. Many things marked override should really be marked final.

I’m guessing there is some legacy support issue, so …

#if CPP_VER < 11
    #define final override
#endif

mmm yummy :fearful:

π

PS Might be nice if we could point ProJucer to an optional folder containing custom templates, so we could write our own templates…


#7

Huh? I think you’re confused there - final and override do extremely different things!


#8

Yes, but surely you want it to do the final thing. i.e. To mark template methods as override would imply the possibility of subclassing the (main content) component. Which would be rather strange…

π


#9

Well, it’s not unimaginable that someone would inherit. There’s certainly no reason why you’d want to actively stop people from doing that.


#10

A rule of thumb is to do final on classes that don’t have a virtual destructor. But there are always legitimate exceptions. Really depends on the class.


#11

But it is a template. It doesn’t actively stop people from doing anything, because they can edit the text.

The purpose of a template is to anticipate the most common usage, which would be a final main content component.

π


#12

The purpose of ‘final’ is to help people by stopping them using classes in stupid ways.

Inheriting from a Component class is an unusual but totally legitimate thing to do. Making it final would help nobody at all, and would stop some people doing what they need to.


#13

It doesn’t stop anyone doing anything – if someone is planning to create a derivable main content component, they can just replace that final with override. it’s a dozen keystrokes.

Also since the template is meant to be beginner friendly, isn’t there more risk of beginners doing stupid things? Surely no beginner is going to want a derivable main content component, but anyone experienced enough to want that can obviously change a couple of keywords.

In my own code, I replace the override with final every time I create a new template file. I made the observation in case it was an oversight (e.g. the template had not been revised for C++11).

π


#14

It’s impossible to change that code, because if it’s part of the template and will be overwritten each time the user re-saves it. So whatever goes in there mustn’t stop people doing what they need to.


#15

…to get back to the override: I think it is missing, if I click “Add New Component (split in cpp and header file)”.
I found the getCallbackDeclarations(), but don’t know, where the callbacks array is populated…


#16

yes, it seems it’s still missing in there :
extras/Projucer/Source/BinaryData/jucer_NewComponentTemplate.h
extras/Projucer/Source/BinaryData/jucer_ContentCompTemplate.h

the “overrides” are also missing in :
extras/Projucer/Source/ComponentEditor/ui/jucer_ComponentOverlayComponent.h


#17

Ah, didn’t spot those. Thanks, will tidy them up!