[Interest] chasing a standard

Tue Nov 27 17:02:04 CET 2018

Il 27/11/18 15:35, roland at logikalsolutions.com ha scritto:
> 
> Quoting Giuseppe D'Angelo:
> 
>>>
>>> No, by wrappers I mean something like QMap becoming nothing more than
>>> a header file with all of the existing methods either mapping directly
>>> to their std:: counterparts or stubbed out.
>>
>> The idea is that 99% of the methods will map directly to the std::
>> counterparts (acting on the std container under the hood), so indeed
>> they'll be very easy stubs, but implicit sharing will be kept. So
>> nothing to fear in that regard.
>>
> There are __tons__ to fear in that regard. Using the standard
> container under the hood is illconceived.

And the technical arguments for this are...?

>>> Do the std:: classes offer
>>> implicit sharing along with delayed/shallow/copy-when-needed behavior?
>>
>> Since C++11 the Standard disallows copy on write for the implementations
>> of its containers (including strings).
>>
> so it will break much

I'm now seriously thinking you're trolling this mailing list, and 
thinking of calling a moderation on you.

"So" means there's an implication of sorts. Where does this implication 
come from?

>>> Let's spend a few moments and chat about foreach() while we are at it.
>>> The C++11 counterpart is range-based for loops.
>>>
>>> https://en.cppreference.com/w/cpp/language/range-for
>>>
>>> Both have their place and both operate differently.
>>
>> No; foreach today does not have a place any longer.
> 
> Foreach still has a place and, more importantly, has an installed base.

The installed base can migrate away to the new tools, or (as already 
stated SEVERAL times already) copy and paste foreach's definition in 
their projects and keep using it. "Has an installed base" isn't a 
compelling argument for API evolution; ballast needs to be dropped from 
time to time, because development bandwidth is finite.

> Unlike God at the creation of the universe, foreach has an installed
> base. 

See above.

> It wasn't unteachable nor was it unlearnable. 

I did not say it's UNteachable, I said it's DIFFICULT to teach. Stop 
altering other people's positions for the sake of your own argument.

> While people did
> stumble a bit trying to delete items using foreach(). 

Or mutate elements, or understand that it is expensive when used on a 
"wrong" container, or understand that it's a macro so you will struggle 
with commas into it, or...

> Foreach() has a
> place. It allows logic which needs a copy to exist and still be clean.
> Range based for loops can be used on things which cannot be copied or
> where a copy is not needed for the logic.

Because taking a copy explicitly is nonsense -- never heard of that in 
C++. It must be impossible to do.

>> And what's so complicated with "the logic to make and destroy a copy"?
>>
>> auto copy = original;
>> for (whatever : copy) body;
> 
> Ah yes, the spherical cow argument.
> https://en.wikipedia.org/wiki/Spherical_cow
> https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Spot_the_cow.gif/220px-Spot_the_cow.gif

Ah yes, the "I don't know what to answer technically, so I'll come up 
with a bunch of random links and make it personal" argument. Works every 
time.

>>> Let's be honest here. Most programmers suck at iterators. Many times
>>> they are the correct solution, but, most of us will change our design
>>> to avoid them.
>>
>> "Most" of us is an unjustified over-generalization.
>>
> 
> It's highly justified. Someone offering up the spherical cow argument
> should be well aware of it. Speaking as someone who writes an award
> winning technical book series.
> 
> http://theminimumyouneedtoknow.com/
> 
> With a title on Dr. Dobb's developer reading list
> http://www.drdobbs.com/tools/developers-reading-list/232500396?pgno=6
> 
> and someone who ends up working with/training the kids my clients hire
> right out of school where they've been fed a lot of spherical cow but
> little in the way of real world education, the bulk of developers on
> this planet suck at iterators.

Find better developers, then. I'm glad to work with colleagues and 
customers that are perfectly comfortable with iterators.

>>> Well we did until the Qt containers made them rather
>>> easy.
>>
>> How did Qt containers make iterators easy exactly? To my book, Qt
>> containers made iterators _harder_, for instance all the dangers related
>> to mixing const and non-const iterators.
>>
> They made it easier, especially for the younger developers. In large
> part by obfuscating the fact they were using iterators and by
> providing foreach() which meant the number of situations where they
> actually had to use them were greatly reduced.

You state "by obfuscating the fact they were using iterators and by 
providing foreach()", so, apart from foreach, where's the part where Qt 
obfuscates the fact that you're using iterators, thus making "it" easier?

>>> Yes, STL has made their map() class rather close to QMap, but,
>>> it's not the same.
>>>
>>> http://www.cplusplus.com/reference/map/map/
>>
>> 1) What has std::map to do with *ANY* of this? Why do you keep changing
>> topic randomly in the body of the same email?
>>
>> 2) The only touching point between std::map and QMap in history is
>> C++2a's std::map::contains. Saying that someone "made map close to QMap"
>> is an historical false.
>>
> 
> I didn't change the topic. 

So let me quote the original email again:

> Most programmers suck at iterators. Many times  
> they are the correct solution, but, most of us will change our design  
> to avoid them. Well we did until the Qt containers made them rather  
> easy. Yes, STL has made their map() class rather close to QMap, but,  
> it's not the same.

Discussion about foreach and iterators => random jump to discuss 
std::map vs QMap.

> Maybe you spent far too much time with the
> spherical cow? 

Personal insults again? Ok...

> We are still on the topic of the horribly misguided and
> uneducated attempt of replacing Qt containers "under the hood" with
> std:: containers. 

It's very very important for all of us that you keep saying that and 
never bring an ounce of technical argument. But by all means, bring more 
links!

> This includes navigation via foreach(), which must remain because it
> has a rather significant installed base which might one day need to
> move forward and because of the tool it is. 

See above (2).

> It also includes the
> discussion of iterators which many developers suck at and few are
> anywhere near as good as they think.
> 
> So, if QMap were to be replaced "under the hood" by std::map and had
> one scrolled down to the Member functions seciont of the provided
> link, what would they see? 

Ok, so, let's follow this down. Hypothesis: QMap gets replaced by 
std::map under the hood, and I open a community website about std::map. 
What would I see?

Well, a safe bet would be: std::map's community documentation.

What have we learned from this thought experiment? I'm not sure. 
Probably to stop trying to understand your reasoning.

> (Stop inhailing the spherical cow and
> actually do it.)

Personal insults again.

> Well, you probably won't. It would shatter your tiny little universe.

Personal insults again (3).

> Here's a snippet.

[snip]

For the record:

1) You copy and pasted (some) APIs from a random community website

2) Those APIs are just the C++11 ones (because that particular community 
website is not being updated); the entirety of C++17 and C++2a std::map 
APIs are missing.

3) std::map in C++ is a formal specification, not (just) an API dump.

> Gee, what happens when one looks at the doc for QMap?
> 
> http://doc.qt.io/qt-5/qmap.html
> 
> While you see many more methods in QMap, that core API is the same. We
> don't have the crbegin() and crend() as well as a few other things and
> we have many more than are listed on that link.

And the conclusion is that it's thus perfectly possible (and sensible) 
to reimplement QMap on top of std::map, given that the "core API is the 
same". Did you forget to make your point here?

>>> I realize the focus for the Qt project in general is worthless QML and
>>> Web Web Web, but, the stuff which makes all our lives better doesn't
>>> use any of that. There are two horrible things driving that focus.
>>
>> And once more, a nice combo of false statements and free-style FUD!
> 
> True statements which are neither false nor FUD.

They're false, and they're FUD. Dispute this one again and I'll raise 
moderation.

>>> 1) non-disclosure agreements
>>
>> Can you please re-read yourself and realize how complete and utter
>> nonsense this sounds?
>>
>> "Non-disclosure agreements are driving the focus for the Qt Project
>> [towards QML and web]"
>>
>> Besides the fact that it's a *lie*, of course. The Qt Project doesn't
>> have mandate any NDA whatsoever.
>>
> 
> Have you ___EVER___ worked in the real world on a real project? I'm
> serious. You sound just as clueless as a career academic.

Personal insults once more, and once more the art of changing topic. You 
didn't AT ALL address what you originally stated about the Qt Project 
issuing NDAs, which was the original (completely false) statement.

Basically these threads are becoming a constant:

You: <false statement>

Someone else: <that statement is false>

You: <software engineering, licensing, recipe for mac&cheese, personal 
insult, 22 links, open source, more software engineering, marginally 
touching the original topic (without however addressing the very exact 
statement), personal insults again, discussion about containers work in 
Java>

> Developers working on the facial recognition systems today, using a
> version of Qt (I was contacted about taking the project, but didn't)
> WILL NOT BE ABLE TO PUBLICLY DISCUSS IN ANY MEANINFUL WAY WHAT THEY
> DID WITH QT UNTIL THE ENTIRE PROJECT IS DECLASSIFIED which may not be
> while you're still alive. The Japanese "death ray" experiments during
> WWII didn't get declassified until some time in the early 2000's.
> https://airminded.org/2010/01/24/a-japanese-death-ray/

Pfft, I can say it even *today*! I work on chemtrails dispersion systems 
on airplanes, for mass population mind control. All the UIs are built 
using Qt and Linux, and developed using AGILE! It might not be enough to 
go to the Moon, but boy oh boy isn't it just exquisite for this use case.

> It's completely on-topic. This is qt-interest and right now the Qt
> licensing model is chasing the standard of the late 1980s through
> early 1990s where people all tried to get royalties. Off the top of my
> head I don't know of any of those companies which still exists today.
> Ones which chased a royalty licesning model that is.

Sure, licensing discussions are perfectly on topic with iterators.

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181127/6e590447/attachment.bin>