Why not?
It is the only option to not return an updater*.
It seems to me that the very occurrence of such a question is a sign of not very good design. Your commands are indexed only by symbol. It would be correct to index them by symbol and operand type, so that the findCommand() method returns a reference to the command only when such a symbol exists for a command with that type.
1 Like
Null Pointer Exception is more common with languages like Java, where pointers aren't used in the same explicit way as in C++. In C++ you talk more about "null pointer dereference" which indeed leads to UB and often a segmentation fault or program crash but it's typical for the caller to check if things went OK.
in C++ a null pointer is not such a bad deal as in other languages. it's common for functions to return a null pointer when something did not work. Look at malloc() for example, it does that.
I have used null pointers for different things in the past but only in tightly (air tight as a EE friend remarked on my code in 87-88) controlled situations where every case was completely covered.
It's a lot like dealing with array bounds.
You could write code that checks and corrects/whatever bounds.
Or you could write code that never indexes out of bounds.
I'd rather have a null pointer "exception" that can be handled / prevented than a code crash for "unknown" reason.
2 Likes
yes.
My take on this is that returning the existing object when trying to create a new one with the same attributes does not allow the programmer to catch the error easily. So at least the nullptr lets you catch this and it's an easy test that any programmer allocating memory dynamically should do.
Annoter option (for @Delta_G to consider) would be to add a template parameter which is the max size of the VariableUpdater list so that it could be allocated statically when creating the StreamHandler.
returning a ptr to an existing object seems very common.
but do attributes of an object make it a different object?
When you have only one (singleton) yes but when the function is supposed to deliver a new instance that’s weird. You might end up having two pointers pointing at the same instance without knowing it
Seems to me that this is a condition that the user must know about. So, there must be some type of signal that they can check in order to handle the special case. There’s no way for them to know this if you return a pointer to the existing (possibly incorrect) object. In Big Computer C++, the preferred way to handle it would be to throw an exception that would be caught by the appropriate error handler. That way, the main (non-error condition code) wouldn’t have to deal with all the checking. Most platforms in the Arduino ecosystem don’t offer that option. So, seems to me that nullptr is as good a signal as any.
There's nothing scary about nullptr itself. What you should be afraid of is code that assumes a pointer cannot be null:
Use of a pointer in an interface always indicates the possibility of null values. Otherwise the designer should have used a reference.
1 Like
Seems like the code needs some bullet-proofing. Returning a raw pointer to your internal data structure invites the user to do nasty things like delete the pointer. I also see no provisions to properly dispose of the dynamically-created objects at the end of the structure's lifetime.
Object yes, Class no.
Instantiation, the data space is to me the object. What's in it can change but that address that can be a buffer may also change.
But then to me, that's how they act. The Priesthood likely has a different definition!