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

[user4592357]

in my oop class exam i got the question in title from my teacher.
he asked on the example of strings - QString has a lot of methods that std::string doesn't. does it mean the std::string class is incomplete from perspective of oop? or it's enough and it's the QString that has more functionality than needed?

i'm not sure about the answer because i think if it's the standard then it should be enough (otherwise the missing things would be added), but then, there are times that i need something like QString::arg method which std::string doesn't have and that's when i think that maybe std::string isn't actually "oop-complete".

so can someone shed a light?

[aha_1980]

@user4592357

What's complete or not mostly depends on your needs. If you look up Qt's bugtracker you find lots of suggestions what can be added to the library.

The std library evolves much slower and provides much less functions - they mostly provide the "basic" things - too few for my taste.

And honestly - you cannot compare QString and std::string. std::string is more like QByteArray, while QString is an Unicode string.

[JonB]

@user4592357
One thing: whatever the relative coverage of QString vs std::string, I don't think their "in/completeness" has a particularly "OOP" significance.

[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.