Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastardlyHQ.org
Newsgroups: comp.lang.c++
Subject: Re: 'Graphics' of libwy
Date: Wed, 18 Dec 2024 09:16:17 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <vju3t1$27s6m$1@dont-email.me>
References: <4ffeda4ce7116f70754bcfcaee87cb729081fac3.camel@gmail.com>
 <vjqhau$1ceif$1@dont-email.me> <vjs2do$1p3ce$1@dont-email.me>
 <vjs7a7$1qa1n$1@dont-email.me> <vjs8uq$1qgh4$1@dont-email.me>
 <vjsaa3$1qrhs$1@dont-email.me>
 <vjtvvk$2787g$1@dont-email.me>
Injection-Date: Wed, 18 Dec 2024 10:16:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b92a2220c2b5881bbd8a0c68d935a5ea";
	logging-data="2355414"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18kqAyN9veLUPMpCJ861uBJ"
Cancel-Lock: sha1:kLWnp8tfP8syeYeF29jnh7ma/c8=
Bytes: 2734

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

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

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