are c++ standard implementations "incomplete" or does qt have more than is needed?

user4592357

the string was just an example, what about QVector, QList? they carry another concept of detaching which doesn't exist in standard library's implementations.

by the way, we used qt classes as examples of how class hierarchies should and shouldn't be written, for example we discussed that it's not a good design that the base class e.g. QEvent, knows about event types - something that are defined by derived classes.

Asperamanca

The way I understand, std containers mostly depend on copy elision and return value optimization. That means that you will rarely need to copy a container, if you observe a few rules when writing code.

Qt containers hail from a time when C++ did not yet have these optimizations. So they used a different approach: Make it cheap to copy values of containers, as long as both copies share the same data.

You could say these are different approaches to solve the same problem.

As for the design of Qt libraries: I am sure the developers would love to undo some decisions they (or their predecessors) made 10 or 15 years ago. But Qt is about long term compatibility, so you cannot simply change the design.

EDIT: Out of curiosity: What better alternative was discussed in the QEvent-case?

VRonin

@user4592357 said in are c++ standard implementations "incomplete" or does qt have more than is needed?:

for example we discussed that it's not a good design that the base class e.g. QEvent, knows about event types - something that are defined by derived classes.

Disagree: QEvent is designed to be downcast, it's basically a variant for all events so it must know the type of event.

A better example of this is QAbstractSeries where the design massively restricts the ability of users to implement custom series types

incomplete from perspective of oop

Please define OOP completeness

user4592357

@VRonin
completeness is mentioned as one of qualities of well designed system in grady booch's object oriented analysis and design with applications book, chapter 3.6:

By complete, we mean that the interface of the class or module captures all of the
meaningful characteristics of the abstraction. Whereas sufficiency implies a minimal
interface, a complete interface is one that covers all aspects of the abstraction.
A complete class or module is thus one whose interface is general enough to be
commonly usable to any client. Completeness is a subjective matter, and it can be
overdone. Providing all meaningful operations for a particular abstraction overwhelms
the user and is generally unnecessary since many high-level operations
can be composed from low-level ones. For this reason, we also suggest that
classes and modules be primitive.

VRonin

@user4592357 said in are c++ standard implementations "incomplete" or does qt have more than is needed?:

Completeness is a subjective matter

I think this is key.

In my opinion QString has more functionality that is needed. arg() is a good example as it's only necessary for Qt's internationalisation system but if you only look at the theory and focus on QString that method is a worse operator+. std::string on the other hand I think errs towards the "minimal" definition

user4592357

@VRonin
yeah, by the above definition, std::string is the sufficient implementation, a basic plain string type, whereas QString, as @aha_1980 mentioned, is a unicode string.

anyways, from the answers i got and from what i concluded is that std::string is sufficient by itself, however lacks some useful functionality, for example, for me one is a split() function. and QString can be considered complete, however at some points it's doing more than needed, e.g. the setNum() function and its overloads.

Asperamanca

@VRonin said in are c++ standard implementations "incomplete" or does qt have more than is needed?:

@user4592357 said in are c++ standard implementations "incomplete" or does qt have more than is needed?:

Completeness is a subjective matter

I think this is key.

In my opinion QString has more functionality that is needed. arg() is a good example as it's only necessary for Qt's internationalisation system but if you only look at the theory and focus on QString that method is a worse operator+. std::string on the other hand I think errs towards the "minimal" definition

I agree that QString has a bit extra around the waist, but personally, I find 'arg()' extremely useful.

VRonin

@Asperamanca said in are c++ standard implementations "incomplete" or does qt have more than is needed?:

I find 'arg()' extremely useful

See https://forum.qt.io/post/423430 and the 3 posts following that

Asperamanca

@VRonin said in are c++ standard implementations "incomplete" or does qt have more than is needed?:

@Asperamanca said in are c++ standard implementations "incomplete" or does qt have more than is needed?:

I find 'arg()' extremely useful

See https://forum.qt.io/post/423430 and the 3 posts following that

I'm not sure I found everything you wanted me to find behind that link, because the only information I took home is that .arg() is slower than other ways to concatenate strings. Which is good to know if you write performance-sensitive code.

VRonin

From the docs link:

A similar problem occurs when the numbered place markers are not white space separated:
QString str;
str = "%1%3%2";
str.arg("Hello").arg(20).arg(50); // returns "Hello500"
str = "%1%2%3";
str.arg("Hello").arg(50).arg(20); // returns "Hello5020"
Let's look at the substitutions:

First, Hello replaces %1 so the string becomes "Hello%3%2".

Then, 20 replaces %2 so the string becomes "Hello%320".

Since the maximum numbered place marker value is 99, 50 replaces %32.

Thus the string finally becomes "Hello500".

kshegunov

@user4592357 said in are c++ standard implementations "incomplete" or does qt have more than is needed?:

by the way, we used qt classes as examples of how class hierarchies should and shouldn't be written, for example we discussed that it's not a good design that the base class e.g. QEvent, knows about event types - something that are defined by derived classes.

Yes, in theory. However theory and practice often enough don't meet under gracious circumstances. You could in principle go all in and define the event as polymorphic and upcast it with dynamic_cast define some interface for god knows what reason and derive from it. While theoretically correct there's practically no need to do that, nor is it beneficial. You'd force indirections through pointers/references and add a call overhead through the vtables where there's no real need for that. All other things equal, the events are too simple to really benefit from a unified interface and the overhead "the theory" dictates. Just be practical.
my 2c.