On Mon, Oct 22, 2007 at 08:33:16AM +0200, Lars Gullik Bjønnes wrote:
> | But I am aware of your opinions.
> |
> | That does not mean I share it. We go through all sorts of trouble to
> | make boost usable within LyX up to bundling the latest and greatest,
> | and even that needs to be patched sometimes, and even that causes
> | irregular behaviour and bloats compilation. On the other hand, you
> | consider Qt not acceptable outside frontends/* without giving reasons
> | above a "real dislike".
>
> One of the things I dislike about Qt (in general) is the super slow
> adoption of the standard and how it recreates and adds to the standard
> with no intention of trying to move the standard closer to what Qt
> needs. And with the upcoming new standard I belive that is only likely
> to get worse.
One of the things I like about Qt is the pragmatic approach.
Example 1:
std::string e.g. is a mess, interface-wise,
functionality-wise, performance-wise (compilation and use).
QString 'just works' for all practical purposes. And it is so much
more convienient to use
if (str.endWith("xyz"))
[Or maybe if (str.endsWith(QLatin1String("xyz"))) if one wants
to be explicit on the encoding]
instead of whatever std::string provides (inspite of its fat interface).
I am not even sure what the most efficient method is. Something like
string const suffix = "xyz";
if (string(str, str.size() - suffix.size()) == suffix)
perhaps. Perhaps not.
Example 2:
Instead of having ridiculous requirements like 'std::list::splice()
is O(1)' resulting in 'std::list::size() is O(n)'
{ return std::distance(begin(), end()); }
the common case should be optimized.
Example 3:
Qt is "feature complete" for quite a few applications. I do not need
a networking library, I do not have to know how to start processes
on different systems, I do not need to know where and how to store
persistent settings, I do not need to find a library to handle
signals and slots, serialization, and to a certain degree even
introspection. *sigh*
Wrt to 'moving the Standard closer to what Qt needs': I guess you
know the people in the committee good enough to know that any
proposal coming from the outside is nearly impossible to get considered,
let alone becoming part of the Standard.
Instead we have things like 'main does not need a return' in the
Standard, or 'export' which nobody could properly implement in almost
a decade.
I gave up trying talking to these people a few years ago as this turned
out to be complete waste of time. And note that this was well before I
even tried to use Qt, so I was certainly not biased at that time.
[Since we are at it: Right now I consider the Committee rather a threat
then a boon for the very existance of C++. A glacial progress on
non-issues, no progress for important issues, and in the meantime
things like C# get into a shape were they are considered "usable"
- and pushed as that by the big guns]
> OTOH boost have a pretty good track record in this respect, quite a
> few of the boost libraries and boost initiated changes will be in the
> next version of the standard.
There are two things really good in boost: The smart pointers, and
regexps. Apart from that boost is rather 'medium quality' if not worse.
Letting 'boost::filesystem::exist' throw is simply intolarable.
Andre'
