Qt-interest Archive, January 2008
Re: is it possible to have signals as defines ? (offt)
Message 1 in thread
Bo Thorsen wrote:
> On søndag den 9. December 2007, Adam Hawes wrote:
>
>>> #define ADD_LOG_FEATURES \
>>> signals: \
>>> void emitLogInfo( QString infoMessage ); \
>>> void emitLogWarning( QString warningMessage ); \
>>> void emitLogError( QString errorMessage ); \
>>> void emitLogFatal( QString fatalMessage );
>>>
>
> Change this to
>
> enum LogLevel { Info, Warning, Error, Fatal };
>
> signals:
> void emitLog( LogLevel level, const QString& infoMessage );
>
> This way you at least only have to implement one method, and if you add new
> log levels they will automatically be supported. You can put the enum in some
> shared class or namespace.
>
I prefer the approach above not this one. It is not supported
automatically - you have to add the code for it any ways, be it
another "case" in a huge "switch", be it a clear simple method or be it
a "callMethod[methodPointerForTheCase]".
> Always change the specs instead of following them blindly, when there is an
> implementation detail that wasn't thought of when the specs were made.
>
right, agree.
>
>> Wouldn't you be better off creating a pure virtual "log" class and
>> inheriting from that so that you get the signals for "free"?
>>
>
> You can't create a pure virtual class that has signals or slots. The
> declaration of these includes creation of methods and subclassing QObject.
>
> However, you might use interfaces. Search for Q_INTERFACES in assistant for a
> description on how to do this. It's intended for plugins, but I don't see why
> it wouldn't work here as well.
>
> Bo.
>
>
--
[ signature omitted ]
