Re: 'Graphics' of libwy

On 18/12/2024 10:16, Muttley@DastardlyHQ.org wrote:

On Wed, 18 Dec 2024 09:09:22 +0100
David Brown <david.brown@hesbynett.no> wibbled:

On 17/12/2024 17:53, Muttley@DastardlyHQ.org wrote:

You don't want a library that only works with the latest bleeding edge

versions

of C++. IMO C++ 2011 would be a reasonable oldest version.
>

>
I'd much rather have one that takes advantage of relatively modern C++
features than one that re-invented these same features in their one
special ways - which is what you see with these older libraries.  I'd

 A lot of companies systems don't have their compilers upgraded if consistency
are whats required. A security company I worked at a few years ago only
went up to C++14 because they didn't want any nasty security hole surprises
if they upgraded the compiler and started using the new features (or even the
older ones).

Sure.  There are many reasons for not upgrading tools, and/or not changing standards - some good reasons, some bad reasons.  I have never been a fan of upgrading just for the sake of upgrading.  But in the case of a gui toolkit, I think there is a lot to be gained from more modern C++.

 

new, well-designed modern C++ gui library, I'd want to see concepts,

 Ugh. Concepts and constraints are yet another syntatic soup solution to a
problem almost no one has except in various academic ivory towers.
 

Let's just call that a matter of opinion and move on.

But if the C++ committee were to make a standard C++ gui library as part
of the C++ standard, then it would by definition be part of a later C++
standard.  So if it was targeted for C++29, then of course it could rely
on all the language and library features of standard C++ up to and
including C++29.

 Well they won't because sensibly they realise graphics capabilities are so
variable - or non existent - between systems that there's absolutely no point
trying to develop a standard library for it.

Yes, that's what I have been saying.

I was surprised they even
included a threading library given on various embedded systems threading is
not available. Plus its inconsistent - why multithreading but no multiprocess?
 

Threading in C11 and C++11 was too little, too late.  And it doesn't take into account the significantly different threading systems used in different OS's.  For embedded systems, how is anyone supposed to use a threading library that doesn't handle priorities, stack size, and the like?
I am not surprised they /tried/ to have a standard thread library.  And some of it could, I am sure, be useful to some people.  But I expect most people use system-specific thread libraries in practice.
I think trying to standardise a C++ gui library would be like standardising threading, but orders of magnitude worse.