single function to accept different parameter types

[jsulm]

@JonB said in single function to accept different parameter types:

I have never heard of such behaviour

see https://en.cppreference.com/w/cpp/language/dynamic_cast

[JonB]

@jsulm
Yes, I know and read that. Like I (and you) said it won't happen on a pointer, and I have never used dyanmic_cast<> on anything but a pointer:

c) Otherwise, the runtime check fails. If the dynamic_cast is used on pointers, the null pointer value of type target-type is returned. If it was used on references, the exception std::bad_cast is thrown.

That's why I suggested how @mzimmers might test a pointer even if he starts with a value type (via &variable)..

P.S.
I note that qobject_cast<>() avoids this by only accepting a pointer-type, no value types!

[J.Hilk]

@JonB said in single function to accept different parameter types:

I have never heard of such behaviour. It is very worrying if dynamic_cast throws an error, it is supposed to be usable to detect whether an object is of a particular class at runtime, and sounds like it is what you are looking for. It is used "millions" of times in worldwide C++ code.

I think it also throws an error when the project is compiled with -fno-rtti or /GR respectively

and at least MSVC only gives a warning during compile time and you know what people do with warnings ^^

[JonB]

@J-Hilk
I don't dispute that compilers may have options to enable it or not, e.g. disable RTTI. But the extract I quoted from cppreference above

c) Otherwise, the runtime check fails. If the dynamic_cast is used on pointers, the null pointer value of type target-type is returned. If it was used on references, the exception std::bad_cast is thrown.

says null pointer returned (if pointer, which is what I was discussing), I don't see it say "undefined behaviour depending on compiler". Just saying.

In any case, I suspect @mzimmers' case is just that a pointer should be passed instead of a value.

[mzimmers]

@jsulm here's my call. I'm including it as a pic so you can see the debugger's locals window.

Vsp is a subclass of Equipment, which is a struct with Q_GADGET enabled.

Is it possible that this error is due to the fact that equipment is being passed in as an argument from QML? I remember reading (but not fully understanding) somewhere about incompatibilities between JS and C++, and the use of emscripten to remedy it. Something about the vtables getting messed up.

EDIT:

I changed my function a bit:

void EquipmentModel::sendPatchRequest(const Equipment &equipment)
{
    const Equipment *ePtr = &equipment;
    const Vsp *vsp = dynamic_cast<const Vsp *>(ePtr);

and this returned a null pointer as @JonB said it would. So, I guess the lesson is you can't use dynamic_cast to downcast references.

Good to know, but...I'm still stuck with how to fix this issue.

[J.Hilk]

@mzimmers well, this works just fine and as expected:

#include <iostream>

// Base class
class Base {
public:
    virtual ~Base() {}
};

// Derived class
class Derived : public Base {
public:
    void sayHello() const {
        std::cout << "Hello from Derived class!" << std::endl;
    }
};

// Function that takes a const reference to a Base object
void func(const Base& base) {
    try {
        const Derived& derived = dynamic_cast<const Derived&>(base);
        derived.sayHello();
    } catch (const std::bad_cast& e) {
        std::cout << "dynamic_cast failed with message: " << e.what() << std::endl;
    }
}

int main() {
    Derived d;
    func(d);  // This will succeed

    Base b;
    func(b);  // This will fail and catch block will execute
}

Hello from Derived class!
dynamic_cast failed with message: std::bad_cast

[mzimmers]

@J-Hilk yes, that works when the caller of func() is a C++ function. When it's coming from QML, I get the bad_cast error.

So, I guess this isn't a C++ problem after all; it does have something to do with the interaction between C++ and QML. I can post something to the QML forum about it.

[mpergand]

@mzimmers
I really don't like the use of dynamic_cast here, seems unsafe.

I definitely do use subclassing; I just didn't show it in my snippet above.

I didn't think about Equipment subclass, but EquipmentModel subclass, like:

void VspEquipmentModel::sendPatchRequest(const Vsp &vsp)

that way, each equipment model receives the right equipment is dealing with.
No more casting is needed.

[mzimmers]

@mpergand that would be an option, but I'm going to have about 40 subclasses of Equipment. I'd really prefer not to have to make 40 subclasses of the model just for this purpose. Plus, I'd have to instantiate the subclass 40 times, with a lot of overhead.

[J.Hilk]

@mzimmers said in single function to accept different parameter types:

@J-Hilk yes, that works when the caller of func() is a C++ function. When it's coming from QML, I get the bad_cast error.

if its coming from qml, and you're passing the object into the call, than you're essentially already passing a pointer, I think.

Try

void EquipmentModel::sendPatchRequest(Equipment *equipment)

[mzimmers]

@J-Hilk said in single function to accept different parameter types:

Try
void EquipmentModel::sendPatchRequest(Equipment *equipment)

I did try that - I get a runtime error about passing incompatible arguments. And, I'm hardly a JS expert, but I don't think there's anything I can do on the QML side to make that signature work.

[mzimmers]

One of my co-workers came up with this workaround:

// would entail one of these routines for each subclass,
// but they would all do the exact same thing.
void EquipmentModel::sendPatchRequest(const Vsp &equipment) {
    sendBaseRequest(equipment);
}

void EquipmentModel::sendBaseRequest(const Equipment &equipment)
{
    if (m_qnrPatch == nullptr) {
        int i = getIndex(equipment.m_uuid);
        if (i == NOT_IN_LIST) {
            continue;
        }
        Equipment &listEntry = *(*m_list)[i];
        equipment.addPatchFields(listEntry, qjo, rolesToKeys); // goes to subclass function.
...

It works. Unless someone comes up with a better idea, I'll close out this topic. Thanks for all the suggestions...