MAMEWorld Forums - Programming - Re: IPT_TILT1 through IPT_TILT4

> It's valid for the value to be NULL as long as you don't ask to use it. Calling
> machine() means you're going to use it, so it's normal you get a runtime error. The
> real question is why whatever method you're using to get at the names calls
> machine(), and whether it's really necessary.
>
> OG.

The way the class is written, it is possible for a device_t to be in a state such that any call to machine() will always blow up. If it returned a pointer to a machine instead of a reference, then at least the device_t class could represent that it doesn't have a machine yet to the caller by returning NULL. As it stands, device_t is a timebomb until it gets its machine.

As it turns out, calling name() on an ioport_field tries to get the current ioport_manager, by calling manager() on the containing ioport_port, which itself calls machine() on the containing device_t. That blows up because of this code.

But calling name() on an ioport_field before there is a machine is perfectly valid - or at least, it used to be, until Aaron Giles' C++-ification struck again. Calling name() on a field without having instantiated a machine is how the info stuff (that dumps XML descriptions of all games) would display, for example, a button's name. I noticed that the info stuff has been adapted to not call name() of fields any more, and thus never shows button names; or maybe it never did, I'm not sure.

Anyway, *my* code calls ioport_field::name() without a machine, and it used to work. And I'm not saying that it's such a big deal for there to be bugs in software, every software developer makes bugs. The thing that is a little irritating is that the bugs are cropping up because of a C++ coding style that just invites trouble. There is a reason that encapsulation is one of the most important features of C++. Making methods that will break without warning unless the caller has some special knowledge of some global state is an encapsulation violation.

Well after an hour or two of investigating this and coming to a better understanding of how the code works, I "fixed" it by adding a has_manager() method to ioport_field and ioport_port, and a has_machine() method to device_t. Then I made ioport_field() call has_manager() and do the right thing if there is no machine (return NULL) rather than blowing up.