Const input parameters

Many of Blenders class constructor and methods do not use the const qualifier for input parameters. This is especially cumbersome if you want to pass a const pointer (eitherway: a constant pointer, or a pointer to constant data) to a method that will only accept a non-const pointer. In such a case, you have to cast away the const, knowing or assuming that the method will not change the pointer or data.

GHOST_EventDragnDrop takes amongst others GHOST_TEventDataPtr data. I doubt that the user provided data has to be modified at some point in the pipeline. If it does indeed, this is not documented.

There are many more cases where input arguments are non-const. Functions should always use const for pure input references or pointers to 1) allow passing read-only memory, 2) signalling that passed data is not changed.

Is there a particular reason, why input parameters rarely use the const qualifier?

Blender is an old old codebase that was not const correct from the start, thing with const correctness is, you either do it right from the start, or you’ll go insane trying to add it later on. You change a parameter on a function here and issues pop up here , there , everywhere, you fix those, and new ones will popup down the chain from that. Adding const correctness later on is real expensive time-wise.

If you look at the commit logs, you can see that @ideasman42 has slowely been chewing away at this

We’ll get there… eventually…

Ghost is a bit of a special case - since changing function signatures requires building Linux/macOS/Windows - to ensure one of them doesn’t fail to build.

While it’s probably OK to make this argument const - there isn’t that much motivation to do minor improvements like this since they need to be tested on all supported platforms.