Hi Marc, I agree with a lot of your points. Performance is important to me. I won't get bogged down in the specifics, because way too much energy has already been wasted on this (and related) threads I think, so I'll just say a few things.
On Thu, Jun 6, 2019, at 10:45 AM, Mutz, Marc via Development wrote: > IMO, that hits the nail on the head: we have an obligation to our users > to use the most efficient data structure (and, by extension, looping > construct) we possibly can, and can't just pop in the first data > structure that comes to mind. The thing is, loops are easy to use. Containers are easy to use. You might know the STL like the back of your hand - I will be the first to admit that I don't. I write loops, I don't use find_if. I commit many other sins like this on a daily basis. The same is true I'm sure of many other pieces of the STL, or indeed, any other software. However, to make myself feel a little less awful, I will add that I am sure that I'm not alone here, and I think that is why some people have been pushing back a bit on the point of abstraction. Using the specific example of QMap: It's one thing to know not to use a QMap for a small container; it's another issue altogether to have an easily usable alternative that can be used in place of it, especially if the container is supposed to be exposed to another component, for example. It's simply less reading/writing/cognitive effort to bang out container usage than the alternative. That is generally the purpose of abstractions, after all. > IMNSHO, you can optimize for readability in your own app and see whether > you sustain in the market. In a library, used on millions of machines > every day, spending 8KiB (or 4KiB, or just 1KiB) just to use a slightly > less noisy code version is - sorry - selfish. If you contribute to Qt, > you should be putting yourself in the service of it's users. Again, I'll emphasize that I don't disagree with the point that you are making. I just think that you may want to consider that various enablers can make your life easier in that you have to write a lot less grumpy size-reducing patches, and a lot less mails arguing your point. That is one of the points of Qt, after all: that you make it easier for other people to write better code faster. > I have the feeling that some participants of these discussions thought > they joined an adulation club for Qt API lovers instead. I don't agree with this kind of attack, though, even if it was not directed at any one individual by name. Let's (_everyone_) please keep the mailing list a pleasant place to read (and write). -- Robin Burchell ro...@crimson.no _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
