Discussion:
Interest Digest, Vol 86, Issue 14
(too old to reply)
r***@logikalsolutions.com
2018-11-27 13:39:51 UTC
Permalink
So what you found is true, but only part of the truth. std::enable_if_t
is C++11, and that's officially required to build Qt Creator since 2014.
gcc 4.8.4 was good enough until 2017, i.e. has been given a grace period
of more than two years.
Ah grace period. Spoken like someone who believes LTS means whatever
you want on any given second of any given day.
Even if the version requirement for gcc weren't documented please note
that the relation 'can-be-build-with' is not transitive.
"Creator version X can be build with Qt version Y" and "Qt version Y can be
build on OS version Z" does not imply "Creator version X can be build
out-of-the-box on OS version Z".
Spoken like an automated test which was simply there to check the box
rather than actually test anything.
Please note also that "not out-of-the-box" does not necessarily mean it
cannot be done. Asking Google for "ubuntu 14.04 gcc" gives as third hit
https://gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91,
apparently giving instructions to get a gcc 6.1 on Ubuntu 14.04.
Spoken like someone whose never worked in a production environment
restricted to official repos. The bulk of the serious development
using Qt are such environments, not idiot phone apps.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Julius Bullinger
2018-11-27 14:02:06 UTC
Permalink
[...]
Off-topic: Your e-mail client is broken and creates a new thread for
every reply. As this is annoying, can you please fix it?

Thank you.
r***@logikalsolutions.com
2018-11-27 14:36:46 UTC
Permalink
Past few days I've been using a Web portal for email. My appologies. I
only have my regular email client on the weekends.
Post by Julius Bullinger
[...]
Off-topic: Your e-mail client is broken and creates a new thread for
every reply. As this is annoying, can you please fix it?
Thank you.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Ulf Hermann
2018-11-27 14:04:12 UTC
Permalink
Post by r***@logikalsolutions.com
Spoken like someone whose never worked in a production environment
restricted to official repos. The bulk of the serious development using
Qt are such environments, not idiot phone apps.
A production environment for serious development that restricts you to a
four year old version of Ubuntu and still allows you to run an
unreleased Qt Creator built from git today is an ... interesting setup,
to say the least.
Sérgio Martins
2018-11-27 14:09:56 UTC
Permalink
Post by r***@logikalsolutions.com
So what you found is true, but only part of the truth. std::enable_if_t
is C++11, and that's officially required to build Qt Creator since 2014.
gcc 4.8.4 was good enough until 2017, i.e. has been given a grace period
of more than two years.
Ah grace period. Spoken like someone who believes LTS means whatever
you want on any given second of any given day.
QtCreator is not LTS.

Regards,
Sergio
r***@logikalsolutions.com
2018-11-27 14:35:05 UTC
Permalink
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.
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.
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
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.
Experience actually shows that this is a terrible misfeature of foreach.
Apart from the obvious performance argument, apart from the teachability
problem I have already stated, the implicit copy makes it very very hard
to reason about loop invariants.
For instance, the copy makes it impossible in the general to simply
replace foreach with a range-based for -- the loop could be coded in a
way that relies on the copy to take place, thus it is safe to modify the
original container from within the body. Given that the actual
modification could be hidden behind several levels of function calls,
one is going to have a very hard time tracking down what is going on in
a given foreach, and if it's safe at all to replace it with a for.
This isn't hearsay; such loops were actually found when getting rid of
foreach usages from within Qt.
Unlike God at the creation of the universe, foreach has an installed
base. It wasn't unteachable nor was it unlearnable. While people did
stumble a bit trying to delete items using foreach(). 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.
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
Loading Image...
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.
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.
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. Maybe you spent far too much time with the
spherical cow? We are still on the topic of the horribly misguided and
uneducated attempt of replacing Qt containers "under the hood" with
std:: containers. As part of that discussion one must take into
account how memory is utilized and how the containers are navigated.
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. 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? (Stop inhailing the spherical cow and
actually do it.)

Well, you probably won't. It would shatter your tiny little universe.
Here's a snippet.

=====
Iterators:

begin
Return iterator to beginning (public member function )

end
Return iterator to end (public member function )

rbegin
Return reverse iterator to reverse beginning (public member function )

rend
Return reverse iterator to reverse end (public member function )

cbegin
Return const_iterator to beginning (public member function )

cend
Return const_iterator to end (public member function )

crbegin
Return const_reverse_iterator to reverse beginning (public member
function )

crend
Return const_reverse_iterator to reverse end (public member function )


Capacity:

empty
Test whether container is empty (public member function )

size
Return container size (public member function )

max_size
Return maximum size (public member function )


Element access:

operator[]
Access element (public member function )

at
Access element (public member function )


Modifiers:

insert
Insert elements (public member function )

erase
Erase elements (public member function )

swap
Swap content (public member function )

clear
Clear content (public member function )


=====

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

A surgical robot will have a clinical trial period of up to 7 years.
There will be 1-3 years of software development in front of that. The
entire codebase may well be built with an OpenSource version of Qt but
the NDA will be for 15 years.

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/

These (sans the Japanese death ray) are real systems which use real
software engineering, not one of the 32767 flavors of AGILE hacking on
the fly which are out there. They have the ability to save and take
lives. When they use an OpenSource version of Qt for development (many
still using 4.x and some 3.x) the powers which be at Qt cannot and do
not hear it. The NDA prevents this knowledge from leaking out and
sadly, Qt doesn't get steered in the correct direction because of
them. All the powers that be get to hear about are the worthless idiot
phone apps who are all trying to hit the app store lottery. Because of
this reality massive resources were wasted on bringing QML to life and
the bulk of the development focus shifted to idiot phones and Web.
2) Qt licensing
Every Tom,
[snip -- massive, off-topic licensing rant that I won't really comment upon]
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.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
André Pönitz
2018-11-27 18:27:06 UTC
Permalink
Post by r***@logikalsolutions.com
Please note also that "not out-of-the-box" does not necessarily mean it
cannot be done. Asking Google for "ubuntu 14.04 gcc" gives as third hit
https://gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91,
apparently giving instructions to get a gcc 6.1 on Ubuntu 14.04.
Spoken like someone whose never worked in a production environment
restricted to official repos. The bulk of the serious development
using Qt are such environments, not idiot phone apps.
You are apparently not restricted to "official repos" as you are
trying to build Qt Creator from source.

Exactly the same process ("compile something from source") would
give you a contemporary compiler that would be able to build Creator
from source.

So basically your "problem" is completely made up by your self-imposed
restrictions that "allows" you to build this but not that.

Andre'
r***@logikalsolutions.com
2018-11-27 18:47:15 UTC
Permalink
Post by André Pönitz
Post by r***@logikalsolutions.com
Please note also that "not out-of-the-box" does not necessarily mean it
cannot be done. Asking Google for "ubuntu 14.04 gcc" gives as third hit
https://gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91,
apparently giving instructions to get a gcc 6.1 on Ubuntu 14.04.
Spoken like someone whose never worked in a production environment
restricted to official repos. The bulk of the serious development
using Qt are such environments, not idiot phone apps.
You are apparently not restricted to "official repos" as you are
trying to build Qt Creator from source.
Exactly the same process ("compile something from source") would
give you a contemporary compiler that would be able to build Creator
from source.
So basically your "problem" is completely made up by your self-imposed
restrictions that "allows" you to build this but not that.
No. It's really simple. Things which (potentially) impact the product,
like installing a compiler from a PPA, aren't allowed. This is the
norm on most projects for me. As a general rule, nobody cares about
the editor you wish to use. It ordinarily has no potential to impact
the product. One site did ban Visual Studio though. A developer was
editing with Visual Studio under Windows then compiling in the VM from
a shared directory. Somehow he ended up checking in a header file
starting with an uppercase letter but included via lowercase in all of
the source files. Something about the underlying type of the volume
not being case sensitive. Broke things badly for the next pull. After
that everyone had to use "an editor" in the build environment.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
André Pönitz
2018-11-27 20:22:24 UTC
Permalink
Post by André Pönitz
Post by r***@logikalsolutions.com
Please note also that "not out-of-the-box" does not necessarily mean it
cannot be done. Asking Google for "ubuntu 14.04 gcc" gives as third hit
https://gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91,
apparently giving instructions to get a gcc 6.1 on Ubuntu 14.04.
Spoken like someone whose never worked in a production environment
restricted to official repos. The bulk of the serious development
using Qt are such environments, not idiot phone apps.
You are apparently not restricted to "official repos" as you are
trying to build Qt Creator from source.
Exactly the same process ("compile something from source") would
give you a contemporary compiler that would be able to build Creator
from source.
So basically your "problem" is completely made up by your self-imposed
restrictions that "allows" you to build this but not that.
No. It's really simple. Things which (potentially) impact the product, like
installing a compiler from a PPA, aren't allowed.
This is the norm on most projects for me. As a general rule, nobody cares about the
editor you wish to use. It ordinarily has no potential to impact the product.
Fine.

Nobody forces you to use a self-built compiler for your product, this was
about having a compiler to build Qt Creator.

Yes, that would increase your personal effort to get this Creator from 2018
on Ubuntu 14.04 working, but that effort is dwarfed by the effort you spent
on your messages here, so that hardly can be the limiting factor in the game.

Andre'
Filip Piechocki
2018-11-27 20:39:45 UTC
Permalink
I don't understand it. This new compiler is needed to build QtC on Ubuntu
14.04. You said, that you can have whatever editor you want, but cannot use
anything that changes the product. But wait, this new GCC will be used to
build the QtC, not the product. Or maybe Ubuntu 14.04 system image is your
product? Or am I missing something here...

Filip
Post by r***@logikalsolutions.com
Post by André Pönitz
Post by r***@logikalsolutions.com
Please note also that "not out-of-the-box" does not necessarily
mean it
Post by r***@logikalsolutions.com
Post by André Pönitz
Post by r***@logikalsolutions.com
cannot be done. Asking Google for "ubuntu 14.04 gcc" gives as
third hit
https://gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91,
Post by r***@logikalsolutions.com
Post by André Pönitz
Post by r***@logikalsolutions.com
apparently giving instructions to get a gcc 6.1 on Ubuntu 14.04.
Spoken like someone whose never worked in a production environment
restricted to official repos. The bulk of the serious development
using Qt are such environments, not idiot phone apps.
You are apparently not restricted to "official repos" as you are
trying to build Qt Creator from source.
Exactly the same process ("compile something from source") would
give you a contemporary compiler that would be able to build Creator
from source.
So basically your "problem" is completely made up by your self-imposed
restrictions that "allows" you to build this but not that.
No. It's really simple. Things which (potentially) impact the product,
like
Post by r***@logikalsolutions.com
installing a compiler from a PPA, aren't allowed.
This is the norm on most projects for me. As a general rule, nobody
cares about the
Post by r***@logikalsolutions.com
editor you wish to use. It ordinarily has no potential to impact the
product.
Fine.
Nobody forces you to use a self-built compiler for your product, this was
about having a compiler to build Qt Creator.
Yes, that would increase your personal effort to get this Creator from 2018
on Ubuntu 14.04 working, but that effort is dwarfed by the effort you spent
on your messages here, so that hardly can be the limiting factor in the game.
Andre'
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
r***@logikalsolutions.com
2018-11-27 22:59:10 UTC
Permalink
Post by Filip Piechocki
I don't understand it. This new compiler is needed to build QtC on Ubuntu
14.04. You said, that you can have whatever editor you want, but cannot use
anything that changes the product. But wait, this new GCC will be used to
build the QtC, not the product. Or maybe Ubuntu 14.04 system image is your
product? Or am I missing something here...
Filip
Post by André Pönitz
Yes, that would increase your personal effort to get this Creator from 2018
on Ubuntu 14.04 working, but that effort is dwarfed by the effort you spent
on your messages here, so that hardly can be the limiting factor in the game.
Andre'
Andre',

This is not about effort or great need. I'm shocked so many people
cannot fathom working in an environment where you are not allowed to
change out the C/C++ compiler willy-nilly. Gospel truth, I completed
what I needed to do on 14.04 for the next weeks. I used Sublime Text 3
like I said I would. Other than when I'm at home working on my own
stuff, over the course of my 30+ years in IT, I do not recall being in
a work environment where I was allowed to change the C/C++ compiler
out at will. Even if it is/was/might be allowed here, changing the
compiler out just to get an editor would be an extreme risk. It could
potentially undo tons of work which has already went into
creating/testing the Debian and ISO construction worlds as well as the
multi-platform deployment testing.

Filip,

Unknown. If that PPA was/is a backport which installs a new compiler
over the top of the existing system compiler, then yeah, the wheels
are off the cart. If that PPA installs off in some obscure corner
where QtCreator wouldn't automagically find it while configuring kits
and projects, __maybe__ it's okay. Assuming nothing got put into a
standard search path where it accidentally got picked up.

Be off-line for a bit. Other team has release going live tomorrow
morning then my stuff starts churning through the system.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Scott Bloom
2018-11-28 00:55:09 UTC
Permalink
I couldn’t agree more with Roland's concerns here.

I am stuck on Qt 5.5 because of the QWebKit debacle....

I am finally moving on to VS 2017 + a newer GCC, that I can consistently build QWebKit with only minor mods to the build-webkit script. But we build all our code with Wall and warnings as errors.

It’s a 4-6 week project to move code to a different compiler... Some of the warnings are valid, and surprising.. Some are overly pedantic, and a pain.. But we have to verify code changes don’t introduce new issues...

While I understand the "want" to move to a new compiler.. and I do love many of the modern c++ advantages. For a core library such as Qt to FORCE a new compiler, leaves many stuck on older versions

Scott

-----Original Message-----
From: Interest <interest-***@lists.qt-project.org> On Behalf Of ***@logikalsolutions.com
Sent: Tuesday, November 27, 2018 14:59
To: Filip Piechocki <***@gmail.com>
Cc: ***@lists.qt-project.org
Subject: Re: [Interest] Interest Digest, Vol 86, Issue 14
Post by Filip Piechocki
I don't understand it. This new compiler is needed to build QtC on
Ubuntu 14.04. You said, that you can have whatever editor you want,
but cannot use anything that changes the product. But wait, this new
GCC will be used to build the QtC, not the product. Or maybe Ubuntu
14.04 system image is your product? Or am I missing something here...
Filip
Post by André Pönitz
Yes, that would increase your personal effort to get this Creator
from 2018 on Ubuntu 14.04 working, but that effort is dwarfed by the
effort you spent on your messages here, so that hardly can be the
limiting factor in the game.
Andre'
Andre',

This is not about effort or great need. I'm shocked so many people cannot fathom working in an environment where you are not allowed to change out the C/C++ compiler willy-nilly. Gospel truth, I completed what I needed to do on 14.04 for the next weeks. I used Sublime Text 3 like I said I would. Other than when I'm at home working on my own stuff, over the course of my 30+ years in IT, I do not recall being in a work environment where I was allowed to change the C/C++ compiler out at will. Even if it is/was/might be allowed here, changing the compiler out just to get an editor would be an extreme risk. It could potentially undo tons of work which has already went into creating/testing the Debian and ISO construction worlds as well as the multi-platform deployment testing.

Filip,

Unknown. If that PPA was/is a backport which installs a new compiler over the top of the existing system compiler, then yeah, the wheels are off the cart. If that PPA installs off in some obscure corner where QtCreator wouldn't automagically find it while configuring kits and projects, __maybe__ it's okay. Assuming nothing got put into a standard search path where it accidentally got picked up.

Be off-line for a bit. Other team has release going live tomorrow morning then my stuff starts churning through the system.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

_______________________________________________
Interest mailing list
***@lists.qt-project.org
https://lists.qt-project.org/listinfo/interest
Thiago Macieira
2018-11-28 02:39:51 UTC
Permalink
On Tuesday, 27 November 2018 17:32:17 PST Giuseppe D'Angelo via Interest
Post by Scott Bloom
While I understand the "want" to move to a new compiler.. and I do love
many of the modern c++ advantages. For a core library such as Qt to
FORCE a new compiler, leaves many stuck on older versions
But no one is talking about changing the compiler used for your
application. The suggestion is about getting a new compiler (somehow),
simply in order to build a more recent version of Qt Creator. Keep using
the existing toolchain and Qt version for your product.
But yes, Qt will force you to move to a new compiler, when you upgrade Qt. If
you can upgrade Qt, then you can upgrade the rest of your libraries and
toolchain.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
Bernhard Lindner
2018-11-27 19:52:44 UTC
Permalink
Post by André Pönitz
So basically your "problem" is completely made up by your self-imposed
restrictions that "allows" you to build this but not that.
Could you guys please stop picking on each other? That is disgusting!

Telling someone, his concerns and problems would be "made up" is only slightly less rude than that repeated "spherical cow" discourtesy!

It appears to me that this discussion could be very fruitful for both sides! But currently it does not help at all.

PLEASE comes back to interesting, useful technical details soon!

PS: Roland, did I understand you correctly that you are allowed to use Qt and C++ for functional safety projects? That astonishes me.
--
Regards,
Bernhard Lindner
Continue reading on narkive:
Loading...