Quote Originally Posted by claudio-cit View Post
lol.....wtf! for me it's just a black box that do that. i just don't care - and i shouldn't - how does it works.
That kind of thinking got you into not knowing what is and is not a class, but ok, this is your choice. Unfortunately if at some point you'll be forced to use a different toolchain than qmake, you'll have to take a screwdriver, unscrew the black box and look what is inside.

i'm not talnking about .h in general. i'm talking about .h generated by qmake. ops.. by uic.
In that case you are wrong. Take a look at the file - it contains a lot of implementation code, actually most of it is the implementation

Entirely true? What is this, philosophy?!?!?
Fuzzy logic, I guess See the previous paragraph for an explanation or dig into the ui_xx.h file and see for yourself.

Does it work an application if I have 2 forms (classes) differents, that do different things, that behave in a different way, composed by different objects, that are incorporated in the same .cpp? I'm pretty sure it doesn't.
Yes, of course. You can implement the whole program in a single cpp file as long as your compiler can read large files. Actually if you take a look at this forum, you'll find lots of example applications that are contained in a single file most often called main.cpp.

If it does, how do you distinguish them?
I don't really understand this question...

If it does, is it safe coding in this way?
Yes, of course. Code readability and modularity is a different issue here, though.


A general remark - don't think of Qt as a separate language or some other special entity - it is just a set of classes written in standard C++, so all C++ rules apply to it. It's files are not in any way special apart from the fact that Qt introduces three new keywords to C++ but at the same time hides them from the C++ compiler, so that the only tool to see and understand them is moc (another part of the "qmake black box" that does most of Qt's "magic").