> The discussion about public signals has shown that
> with current C++ and moc techniques it is not possible
> to elegantly solve the problem of protected signals
> with statically checked connection calls.
>
> Because of this I propose that in Qt5 the moc mechanism
> should be expanded by the generation of public headers.
>
> For instance qobject.h:
>
> #ifndef QOBJECT_H
> #define QOBJECT_H
>
> #ifndef QT_NO_QOBJECT
>
> #include <QtCore/qobjectdefs.h>
> #include <QtCore/qstring.h>
> #include <QtCore/qbytearray.h>
>
> // generated by moc into the build directory
> #include <qobject_moc.h>
>
>
> This would give much more flexibility with generated code.
> This extension would add new ways of programming Qt classes
> and would allow new features.
>
> Additionally, relying on generated code is always better
> than on hand written boilerplate code.
>
> I know, many people think this a step in the wrong direction,
> but moccing is a reality in Qt, and Qt never had a C++ purist
> ideology, on the contrary Qt always was very pragmatically.
>
>
> It's time to open another door in C++/Qt development.
>
moc-generated headers would also in the support of templeted
QObjects:
template<class T>
class TObjectGen : public QObject
{
public:
void setT(T* t) { m_t = t; }
T* t() { return m_t; }
private:
T* m_t;
};
template<class T>
class TObject;
Q_QOBJECT_TEMPLATE(TObject, int)
// for all used types moc must be triggered to generate the meta code
// e.g Q_QOBJECT_TEMPLATE(TObject, int) will generate a header
// with this code:
//
// template<>
// class TObject<int> : public TObjectGen
// {
// Q_OBJECT
//
// ***
//
This is only a demonstration, and I haven't tested it with a
compiler.
Peter
--
Ihr GMX Postfach immer dabei: die kostenlose GMX Mail App für Android.
Komfortabel, sicher und schnell: www.gmx.de/android
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
