Path: news.eternal-september.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c++
Subject: Re: 'Graphics' of libwy
Date: Wed, 18 Dec 2024 13:58:02 +0100
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <vjugsq$2a3dg$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>
 <vju3t1$27s6m$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 18 Dec 2024 13:58:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d60357c14df3531c321ff0882880aedd";
	logging-data="2428336"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18JHlM8c4UeljLPvX8g4UJQGXYTG8Rzlqo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:w6YcXxD0/1vcMOOogrIeyF+UZMw=
In-Reply-To: <vju3t1$27s6m$1@dont-email.me>
Content-Language: en-GB

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.