I have seen C++ messes that I would hate to see in CF, but then it is well
known that you see current CF code as a mess in itself, so perhaps it has
potential for cleaning up the code...
Well, that is one of the points of the rewrite I'm proposing, indeed...
I depend on trunk not being
Seems like a sort of odd decision since most recent conversations have
seemed to have decided that more content and less code work is what is
really needed to be done, but this seems to be a big code project...
Yes, it has the potential to be ambitious.
And just given the size and
Well, one thought, is there any reason Qt-core as opposed Boost C++
perhaps? If I understand correctly, they provide similar faculties but
Boost C++ also provides some rather nice looking python bindings that
may make it far easier to move cfpython to a C++ code style.
I'm not saying
quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:50:17 +0100:
So why Qt:
- cross-platform
- well tested through KDE and many applications - has all the basics we
need: strings (including shared strings for memory reduction unless I'm
mistaking), sockets, file / directory, threads and locks,
Le lundi 24 novembre 2008, Alex Schultz a écrit :
That said, a little searching shows that if we want similar automagical
wrapping and go with Qt-core, apparently QtScript (an ECMAScript based
scripting language which has been included in the Qt toolkit since
4.3.0), appears to be able to
Le lundi 24 novembre 2008, Lalo Martins a écrit :
Before anyone gets the impression I'm turning this into a Boost holy
war... let me reiterate I don't feel that strongly about it, just
answering Nicolas' questions here.
snip
I see two good reasons for Nicolas favouring Qt over Boost:
- He's
6 matches
Mail list logo
