Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: C++ standards  (Read 56212 times)

0 Members and 1 Guest are viewing this topic.

dabbertorres

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
Re: C++ standards
« Reply #45 on: September 10, 2018, 12:39:11 am »
Oof, guess I'm blind. Thanks.

Gleade

  • Jr. Member
  • **
  • Posts: 55
    • View Profile
Re: C++ standards
« Reply #46 on: October 15, 2018, 01:48:48 am »
- take latest versions supported by the main compilers you work with, only considering their very latest version. You're talking about future so it's not the time to even consider non-latest compilers. And deduce standard C++ you case use from that
- don't ask yourself if you need latest usable standard, just use it, you don't want to spend again time to decide whether standard should be upgraded if you could have done it 3 years earlier for the same price
I'm not sure if this is directed generally at everyone participating in the discussion or directed at SFML's development. SFML isn't just a tool we use. There's no company or one entity behind SFML that would define what is required or not, instead we're dependent on the community and there are some who would be left behind if we just ignored C++ standards.

Sure, the argument can also be made the other way around, that not moving forward with the standard just means we're push other people away. But if that's the case, then that's their decision. Everyone can use SFML, whether you use a new standard or not, it's up to you to decide if it's a game breaker that the library doesn't use modern C++ internally. Where as if we just picked C++17, because I'm using it right now, many won't even be able to compile SFML anymore and it would not be their decision.

If you're just a consumer of libraries and C++ in order to build end user applications, then sure, just go with it, as long as your team/business allows it, but once you write code for others, you can't just ignore their requirements.

I'm quoting this entire post to give my post context.

Where as if we just picked C++17, because I'm using it right now, many won't even be able to compile SFML anymore and it would not be their decision.

Who is "many"? Have there been surveys to reflect who is using what standard/compiler? I'd be curious to know how many users of SFML are using legacy hardware/compilers.
Also; wouldn't using a compiler not up-to-date be a choice in the 99% of cases?

I think a decision shouldn't be based on assumptions.


But in our case, we really need to modernize the code base. The main advantage is easier maintenance, and consistency with new code (which will be written using modern C++). Writing unit tests first (which is what we're doing) will help there, to ensure no regression while rewriting the code.

This to me is the perfect answer.

markand

  • Newbie
  • *
  • Posts: 6
    • View Profile
    • Email
Re: C++ standards
« Reply #47 on: October 24, 2019, 03:08:08 pm »
My $0.02, I think C++17 is the way to go. SFML 3 is not about to be released anytime soon and we're almost in 2020.

C++17 is even available in Visual Studio, Android and in major distributions. I think there is no good reasons to stick with C++11 or C++14.

Major features that C++17 offers:

  • destructured bindings (utterly convenient to do const auto [x, y] = getPosition())
  • std::variant
  • std::optional
  • std::string_view
  • if / switch initializers

Nexus

  • Moderator
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
Re: C++ standards
« Reply #48 on: June 17, 2020, 10:36:02 pm »
What I wrote almost 2 years ago:
When choosing a standard, we need to decide:
  • Who are we targeting? Does our main user base have access to recent compilers?
  • What newer C++ features can SFML directly benefit from?
  • When would SFML 3 emerge?
The last point is important. If we were to choose C++14 at this very moment, it's already "outdated" by 4 years. Add to that the time until SFML 3 is ready.

And SFML 3 is still nowhere. So I'm no longer sure if this should be the criterion.

Would we even require a major version to add more modern C++ features?
A new C++ version is a breaking change only w.r.t. old compilers, it's not breaking client code. Intuitively, it appears to me that a typical SFML user has access to an at most 3 years old compiler (to support C++17).

My suggestion:
  • Start from C++17 -- it's old enough to have decent compiler support but also has helpful stdlib additions
  • Include support from SFML 2.6 or (depending on time to implement) 2.7
  • Use features mainly to add nicer APIs (move ctors, conversion from std::chrono/std::filesystem/...) and simplify internal implementations (lambdas, unique pointers)
SFML 2.6/2.7 could then be seen as a "proof-of-concept" of more modern features, and maybe based on that, we learn how to improve APIs for SFML 3.

Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

eXpl0it3r

  • Moderator
  • Hero Member
  • *****
  • Posts: 9941
    • View Profile
    • development blog
    • Email
Re: C++ standards
« Reply #49 on: June 17, 2020, 11:07:27 pm »
Given the time frame C++17 is what we're aiming for already, but with SFML 3.
Refactoring code without breaking API/staying SFML 2 compatible is an unnecessary burden.

I suggest you take a look at the currently planned Roadmap: https://en.sfml-dev.org/forums/index.php?topic=24372.0
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Nexus

  • Moderator
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
Re: C++ standards
« Reply #50 on: June 18, 2020, 11:10:40 pm »
Thanks for the link, I missed that latest update. SFML 3 planned directly after 2.6 changes things of course.

I've added some more concrete suggestions (so far mostly on the C++ side) directly in the other thread.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

Nexus

  • Moderator
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
Re: C++ standards
« Reply #51 on: March 03, 2021, 07:30:35 pm »
I elaborated the existing points in the C++17 solution design and added a few new ones. After discussing with eXpl0it3r, the plan is that we have a basic design on each feature before jumping into implementation. This will communicate clearly how we want to change things, and avoid that e.g. move semantics is implemented by 5 people in 6 different ways.

What I wrote down is a suggestion from my point of view, with the main criteria for inclusion being a) ease of use and b) pragmatism (don't change what helps no one). Things are not set in stone.

There are also quite a few open points, feel free to leave feedback! :)
Regarding move semantics, please use the dedicated thread.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re: C++ standards
« Reply #52 on: March 04, 2021, 12:37:58 am »
Nice to see some activity happening here! Also I agree with most of the points here and I'm particularly glad that we won't overuse modern constructs like trailed return types or noexcept.

Quote
Occurrences of unscoped enumerations (enum) should generally be replaced with scoped enumerations. We would use the enum struct variant, not enum class, as enums come much closer to a "bundle of data" than "object-oriented entity with methods".

Can't agree with that one. I think "enum struct" is very obscure and more people use "enum class". For example, if you pick almost any modern C++ book - "Effective Modern C++", "C++17 The Complete Guide", "The C++ Programming Language", etc - all of them use "enum class" for their examples and don't even mention "enum struct" at all.
More examples:
Google C++ standards
C++ Core Guidelines
cppreference - "enum struct"s are mentioned, but "enum class" are used in examples.

Quote
override and final
final is mostly pointless in my opinion. override is very good - it should be added everywhere, because it's a clear indication where something is overriding base-class virtual function + it adds additional compile-time checks that function signatures match.


Quote
using everywhere, or just for templates
I think using should be used everywhere instead of typedef as using is much clearer in every possible way, but especially for function pointers and multi-word types. Some examples:

typedef unsigned char Uint8;
// can become
using Uint8 = unsigned char;

typedef void(*ContextDestroyCallback)(void*);
// can become
using ContextDestroyCallback = void(*)(void*);
 



Also it would be nice to have something about attributes like [[nodiscard]], [[maybe_unused]] and [[deprecated]]. They can be helpful for improving API's clarity (and when we'll need to deprecate something in the future).
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Nexus

  • Moderator
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
Re: C++ standards
« Reply #53 on: March 04, 2021, 09:21:54 am »
Thanks for the feedback!

enum struct vs. enum class: I don't have a very strong opinion here. Both are terrible cases of keyword recycling, and I guess the entire reasoning to even allow two variants is the old "I want to use struct whenever I can use class (except in template parameter lists)". I thought being public and data-only might be closer to struct, but let's see what others think here :)

final: what I definitely want to avoid is annotating classes final for no reason. It's one of the "wrong default" issues C++ has (like explicit, const, noexcept...), and the lack of it doesn't imply "this class is designed for inheritance". Regarding final for methods, it probably only makes sense when it's actively harmful to further override a method.

override: yes, I agree it should be used everywhere.

using: good point about the clarity.
I honestly think sf::UintN/IntN types should go too, there's no reason to maintain them with <cstdint>.

Attributes: absolutely agree, especially [[deprecated]] is great. Was thinking about them yesterday, but didn't know where to put it.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

fallahn

  • Sr. Member
  • ****
  • Posts: 444
  • Buns.
    • View Profile
    • Trederia
Re: C++ standards
« Reply #54 on: March 04, 2021, 01:52:47 pm »
final Can also help with devirtualization and offers performance increases in certain cases:

https://devblogs.microsoft.com/cppblog/the-performance-benefits-of-final-classes/

 

anything