On Thursday 21 January 2010 01:30:30 P Zoltan wrote: > I've started writing a testbench for the math classes in ktechlab [1]. At > the attempt of compiling an error popped up, complaining about some > declarations in kdebug.h [2]. The latter one is part of KDE, AFAIK version > 3, so that is an issue here. Yes, it's KDE3.. Seems, you are trying to print something of the wrong type here. You need to overload the stream operator for that type (if it's not a KDE/Qt type) to use it with kdDebug(). I've never done that, so you should consult the Qt documentation (kdDebug() should behave similar to qDebug() in this matter)
> The question is, what should be done? Port the code to KDE4 or use > standard (or Qt's) output methdos, which remove the dependency of math > related classes on KDE (this is the logical way for me). > When something works, I'll push it to git; also change the files in SVN? > > What's your opinion? I'd suggest the following: Since you need to implement the test-cases, anyway. Why not doing it using Qts testing framework. You can use the recent API of the math classes and implement it as Qt4 test-cases. You might want to borrow some ideas and code from some of KDEs test-cases (may be KDevPlatform test- cases would be a good start). You should do all that on a local copy of the kde4-port branch in my repository. I can help creating cmake code to automatically run the tests. After finishing the tests, or during writing them.. or whenever, the math-classes should be ported to use KDE4/Qt4 classes. Since KDE will be a dependency anyway, I don't see the point, why we shouldn't use it. Do we really want to make parts of the project independent from KDE/Qt? I don't know of any projects, other then KTechLab, that could re-use our code. kDebug() from KDE4 has quite some nice features, so I always use it when printing debug-output. It's easily possible to hide/show debug-output from different components, during runtime. (see kdebugdialog) And it will not produce any object code when compiled in release mode. So there are 2 benefits when writing the tests for KDE/Qt4: (1) we got some nice test cases and can automatically run them from cmake (2) math-related classes are ported to Qt4 and can be used, soon I don't think, we should invest much of our time into creating new code for the kde3 version, any longer. > [2] > /usr/include/kdebug.h:183: error: declaration of \u2018operator<<\u2019 as > non-function > /usr/include/kdebug.h:183: error: expected \u2018;\u2019 before > \u2018(\u2019 token > /usr/include/kdebug.h:193: error: expected `;' before > \u2018kdbgstream\u2019 > /usr/include/kdebug.h:193: error: declaration of \u2018operator<<\u2019 as > non-function > /usr/include/kdebug.h:193: error: expected \u2018;\u2019 before > \u2018(\u2019 token > /usr/include/kdebug.h:202: error: expected `;' before \u2018void\u2019 > /usr/include/kdebug.h:240: error: expected \u2018,\u2019 or > \u2018...\u2019 before \u2018&\u2019 token > /usr/include/kdebug.h:240: error: \u2018kdbgstream& > kdbgstream::operator<<(int)\u2019 cannot be overloaded > /usr/include/kdebug.h:143: error: with \u2018kdbgstream& > kdbgstream::operator<<(int)\u2019 bye then julian
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
