A simple class derived from QApplication Seg-faults
-
[quote author="Chris Kawa" date="1378200501"]
It is (according to standard) an error in any other function. Some compilers allow it as an extension with a warning( yuck, I wish they hadn't ). The standard allows it only for main.
[/quote]Indeed, but it seems that some compiler producer don't like to follow standards...
-
SGaist,
I will try to paste QtC4YTest_moc.h into this edit box. Previous attempts to insert code have trashed my linefeeds and white space.Notice: I was able to create a simple application with my C4UIB_Window (X11 window) class that implements QWidget. It uses 'XReparentWindow' on winId() of the QWidget. I had to pass the pointer to QApplication so it could be closed with closeAllWindows(). If you are intrested we might start a new post to discuss my approach.
@/****************************************************************************
** Meta object code from reading C++ file 'QtC4Test.h'
**
** Created: Tue Sep 3 09:14:15 2013
** by: The Qt Meta Object Compiler version 62 (Qt 4.6.2)
**
** WARNING! All changes made in this file will be lost!
*****************************************************************************/#include "QtC4Test.h"
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file 'QtC4Test.h' doesn't include <QObject>."
#elif Q_MOC_OUTPUT_REVISION != 62
#error "This file was generated using the moc from 4.6.2. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endifQT_BEGIN_MOC_NAMESPACE
static const uint qt_meta_data_C4Window[] = {// content:
4, // revision
0, // classname
0, 0, // classinfo
0, 0, // methods
0, 0, // properties
0, 0, // enums/sets
0, 0, // constructors
0, // flags
0, // signalCount0 // eod};
static const char qt_meta_stringdata_C4Window[] = {
"C4Window\0"
};const QMetaObject C4Window::staticMetaObject = {
{ &QApplication::staticMetaObject, qt_meta_stringdata_C4Window,
qt_meta_data_C4Window, 0 }
};#ifdef Q_NO_DATA_RELOCATION
const QMetaObject &C4Window::getStaticMetaObject() { return staticMetaObject; }
#endif //Q_NO_DATA_RELOCATIONconst QMetaObject *C4Window::metaObject() const
{
return QObject::d_ptr->metaObject ? QObject::d_ptr->metaObject : &staticMetaObject;
}void C4Window::qt_metacast(const char _clname)
{
if (!_clname) return 0;
if (!strcmp(_clname, qt_meta_stringdata_C4Window))
return static_cast<void>(const_cast< C4Window>(this));
return QApplication::qt_metacast(_clname);
}int C4Window::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
_id = QApplication::qt_metacall(_c, _id, _a);
if (_id < 0)
return _id;
return _id;
}
QT_END_MOC_NAMESPACE
@ -
Just wondering... Are you building your application by hand ?
-
Did you wrote the Makefile yourself ?
-
Ok... Then let's try it the Qt way...
Move your Makefile and _moc.h somewhere safe and run:@
qmake -project
qmake
make
@And start your application again
-
SGaist,
I did get the "Simple derived QApplication" to build and execute with qmake.
We require that the code builds in our current make environment.
What I have discovered is adding the compiler flag "-fomit-frame-pointer" will eliminate the seg-fault. Can you explain how not using this flag will cause a seg-fault ? The following is complete source and build commands:@/usr/lib64/qt4/bin/moc QtC4Test.h -I/usr/include/QtGui -o QtC4Test_moc.cx
g++ -Wall -fomit-frame-pointer -I/usr/include/QtGui QtC4Test.cpp -o QtC4Test -lQtGui -lQtCore -lpthread
@The Source .h:
@#ifndef QTC4TEST_H_
#define QTC4TEST_H_#include <QtGui/QApplication>
#include <QtGui/QLabel>class C4Window : public QApplication
{
Q_OBJECTpublic:
C4Window( int argc, char **argv );
};#endif /* QTC4TEST_H_ */
@The Source .cpp:
@#include "QtC4Test.h"
#include "QtC4Test_moc.cx"C4Window::C4Window( int argc, char **argv ):QApplication( argc, argv )
{
};int main( int argc, char **argv )
{
C4Window c4w( argc, argv );
QLabel qtl( "Hello world!" );
qtl.setVisible(true);
return(c4w.exec());
}
@ -
Then you should analyze the Makefiles generated using qmake. You'll see that there's a lot of setup done for your (i.e. the various flags to match what was used to build Qt) Also, take a look at the mkspec used for your platform.
Since you are testing Qt you should rather go with the documentation examples and demos. Subclassing QApplication is rarely needed and certainly not in your test application. I wonder where you got this code.
-
I am sorry SGaist,
I am confused by your reply.
I am posting here to get some answers to my questions.
I had assumed all of your questions were answered previously in the post.http://qt-project.org/forums/viewreply/141143/
http://qt-project.org/forums/viewreply/141315/Yes, I did analyse the files generated by the qmake process you have suggested.
That is exactly where I got the flag “-fomit-frame-pointer”, it is a difference I found in the qmake build and my build.
Note that the -O2 flags is what I currently use for Qt's g++ compile.
I have systematicly eliminated the other flags in -O2 to determine that “-fomit-frame-pointer”
will provide a successful (non-seg-faulting) build of the example code.I beg to question if it is that important to know where the code came from.
What is provided is complete, so no need to access other resources.
Is there an error in this code?
I have previously questioned if there is a problem deriving from QApplication.
That question was left unanswered so I assumed sub classing QApplication is not a problem.Yes I have been searching for an example of my intended usage of Qt but have not found anything exceptable.
I have explained in this post how I wish to use Qt, and again with no response I assumed there is not a problem with my intentions.
I would appreciate any suggestions for examples that provide a similar implementation of Qt:
"My planed implementation of Qt is “simply” add some widgets to an existing X11 application."
http://qt-project.org/forums/viewreply/141143/Thanks
-
No, it's not important, I am just curious to know.
There is nothing wrong deriving from QApplication, but in the case of this example, it's pretty useless and would only add code to maintain that is not needed from the start.
I don't know the X11 platform enough to give you a definitive answer. I know that Qt provides some classes to embedded a X11 window (using the XEmbed specification) in an application so I suppose the opposite should also be doable.
-
This post is deleted!
