Compiler does not produce .o file , just a moc_.o and moc_.cpp files.

ddze

thanks man too, appreciate very much.

ddze

Unfortunately , seems like I have a problem with creating a static lib. Because of the internal dependency on an interface class. Basically, the static linking assumes that all of the classes can be instantiated, but in my case one of them holds an interface - therefore producing an error "incomplete type". Now I would have to add new classes into the static library which progresses from worse to terrible.

Is there any way to force the compiler to produce an object file by modifying the Makefile ?

kshegunov

@ddze
If you can't build a static library you'll never be able to use the object files as well, since a static library is a number of object files put together (but with no stub or loader information). So I suggest to look up how to fix the static library build.

Because of the internal dependency on an interface class. Basically, the static linking assumes that all of the classes can be instantiated, but in my case one of them holds an interface - therefore producing an error "incomplete type".

This doesn't make any sense. You put everything related to your QGraphicsView derived class in the static library, the abstract base class as well and that's all there is to it. "Incomplete type" comes from the compiler, and in all probability means you've forgotten to include a header.

Is there any way to force the compiler to produce an object file by modifying the Makefile ?

It should produce them in any case, as the linker needs those, it's a matter of where, not if.

ddze

@kshegunov

so, you mean that is allowed to place an interface class into a static library?

I searched that question and found nothing really meaningful relative to my case. So it is important to know since I am stack with a question whether is possible to fix the problem with the static library holding the interface class or I would have to look for alternative strategy.

the line where it fails is an event handler in the derived QGraphicsView definition.

IBase *source = qobject_cast<IBase*>(event->source());

which compiles and links perfectly in another program but fails to compile in the static library with a messages :

error: static assertion failed: qobject_cast requires the type to have a Q_OBJECT macro
#define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), Message)

and

error: incomplete type 'ObjType {aka IBase}' used in nested name specifier
return static_cast<T>(ObjType::staticMetaObject.cast(object));

So, for some reason requires either the interface to posses a Q_OBJECT MACRO ( which I find that makes no sense to insert a MACRO in an interface class - maybe I miss something ) or that the instance is a live object at the point of assignment. ( the derived QGraphicsView class holds the MACRO in its declaration).

kshegunov

@ddze

so, you mean that is allowed to place an interface class into a static library?

First, let me clarify a thing:
What do you mean when you say an interface class?

In C++ there's the abstract class (such that has at least one pure virtual function), and an abstract class that only has pure virtual functions usually is called an interface (class). In any case if you are deriving from QObject then you should put the Q_OBJECT macro in each of your subclasses.
That said, qobject_cast is only for classes that derive from QObject, so if IBase is not a QObject descendant, well then, you can't use qobject_cast!

Kind regards.

ddze

@kshegunov

interface class -> a class with all virtual functions assigned a zero.

in my case IBase is a pure virtual Abstract class , no MACROS , no inheritance from QObject. But, a derivative of the IBase also derives from the QGraphicsObject , so it is possible to compile and link the code. I know that because it does in another project.

Hopefully, it clarifies the situation a little.

kshegunov

@ddze
Then you can't do this:

qobject_cast<IBase*>(event->source())

If you need to cast to that base pointer, then use ordinary dynamic_cast.

ddze

@kshegunov ,

I have resolved it , that line of the code served only as check that an instance of the IBase exists prior to proceeding further.

By removing that line and subsequent lines that check for the NULL pointer compiles and I will have to sort "eventual" point of failure by different mean.

Still, not sure why that line compiles in another program.

Kind Regards

kshegunov

@ddze

Still, not sure why that line compiles in another program.

This seems doubtful, but it doesn't matter. I'm glad it works and for this particular case you could use:

dynamic_cast<IBase*>(event->source())

instead of qobject_cast and everything should compile and run fine.

Cheers!

ddze

@kshegunov ,

normally I do , I do not know why I did not try that one in this case. probably I had thought it was not the type casting causing the trouble. Though , when I think about it , it is actually very relevant.

Good about this is to learn that the Abstract classes may be part of the static libs.

ddze

@kshegunov ,

dynamic_cast did not work, but the reinterpret_cast compiled ok.

kshegunov

@ddze

dynamic_cast did not work, but the reinterpret_cast was ok.

You shouldn't use reinterpret_cast, it's not for that purpose. What's the problem with the dynamic_cast?

ddze

@kshegunov

here is the ...

error: cannot dynamic_cast 'event->QDragEnterEvent::<anonymous>.QDragMoveEvent::<anonymous>.QDropEvent::source()' (of type 'class QObject*') to type 'class IBase*' (target is not pointer or reference to complete type)
IBase source = dynamic_cast<IBase>(event->source());
^

seems like that dynamic_cast cannot cast if the object is not instantiated completely ...

kshegunov

@ddze

IBase source = dynamic_cast<IBase>(event->source());

I don't see the stars ...! dynamic_cast works only on pointers (or references), so this line is quite simply invalid. You can't have polymorphic cast on an object, it just doesn't make sense. You can however do it on a pointer to that object.

IBase * source = dynamic_cast<IBase *>(event->source());

Should work just fine.

ddze

@kshegunov

here is the line IBase *source = dynamic_cast<IBase*>(event->source()); , not the pointer

kshegunov

@ddze
Okay then, your previous post didn't reflect that. Anyway, have you included the header where the IBase class resides?

PS:
Oh, I see, because you pasted the code as text, and the forum parser recognised the the asterisks and made the text italic ... heh.

ddze

@kshegunov

you are 100% correct , it was the header file missing .... . The other project has the header IBase , that is why it compiles .... probably I deleted it accidentally or by trying the things out. (Should use a diff from now on)

ddze

once on this topic , what would happen if one has a cross-reference include headers ?

I noticed few times that only if I declare a class forward declaration skipping an include of the header to be able to compile. Would in that case be ok to use reinterpret_cast as the dynamic_cast may needed the full header?

probably this applies

An expression of integral, enumeration, pointer, or pointer-to-member type can be converted to its own type. The resulting value is the same as the value of expression. (since C++11)

Ref: reinterpret_cast

kshegunov

@ddze
No, not at all. dynamic_cast is polymorphic cast, it goes looks up the virtual table and makes safe casting for object pointers. reinterpret_cast is a different kettle of fish entirely, it just switches from one "interpretation" of data to another (whence the name). So it's completely legal to cast pretty much anything with reinterpret_cast but it's a bad idea, because it can be quite error-prone.

You can do this:

struct SomeStruct
{
    int a;
    double b;
    QString x;
};

SomeStruct * variable = new SomeStruct;
char * bytes = reinterpret_cast<char *>(variable);  //< This is valid, compiles and runs just fine. Only problem is, you may accidentally modify memory that's not yours ...

And you have the whole structure as an array of bytes ... but it's ill advised to do such things in general. reinterpret_cast is similar to the functionality the union provides.
So as rule of thumb, do not use reinterpret_cast.

ddze

@kshegunov

Thanks a lot.