Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » U++ community news and announcements » Gearing up for 2022.1 release...
Re: Gearing up for 2022.1 release... [message #58258 is a reply to message #58251] Wed, 06 April 2022 12:05 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13976
Registered: November 2005
Ultimate Member
Klugier wrote on Tue, 05 April 2022 12:21
mirek wrote on Sun, 03 April 2022 19:36
Klugier wrote on Sun, 03 April 2022 15:43
Hello Mirek,

I also proposed bumping C++ standard from c++14 to c++17. However, this could be done in the next release. There are a lot of risks here in context of compilation on various platforms.

Even if we do not have any features that particularly targets c++17 we should compile with that standard and our users should have access to it by default. Also, maybe this is a bug, but for MSVC we do not force any standard. It is always latest. I think it should change and we should target exactly the same standard as for GCC and CLANG.

Klugier


Yeeah, I was thinking about it a lot, problem is we have so far universal package for Posixes and we are not 100% sure c++17 compliant compiler is there. I think we would need to add detection code before adding -std=c++17 to options, which is sort of complicated and quirky.


Hello Mirek,

What about chaning approch? If it doesn't compile you could always back to older stable release of Upp. The old systems shouldn't hold us back and keep with old standard. We could make 2022.1 last official release with c++14 and the next one will be c++17.

The C++14 was introduced in 2017 in our code base. 3 years after official standard announcement. Right now we are 5 years after c++17. There is no consistency here.

Klugier



Uhm, now we are mixing 2 things I guess:

(1) C++ that is required by U++
(2) default C++ setting of build methods

So far I was speaking about (2). As for (1) I do not as of now see anything in C++17 that would make U++ codebase significantly better (cleaner, shorter, faster), so IMO it is not worth it to break U++ for old systems yet.

I could go with (2), but that would require detection system for posix install. IDK, maybe running "c++ -std=c++17" and detecting the error code would do the job?

Mirek
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: 2022.1rc1
Next Topic: 2022.1rc2
Goto Forum:
  


Current Time: Thu May 09 06:09:50 CEST 2024

Total time taken to generate the page: 0.02463 seconds