Dragging C++ into the Modern era - Guy Davidson - Meeting C++ 2017

[@guydunton1134]

I saw the original of this talk at ACCU last year. It’s interesting to see how both this talk and the graphics proposal have come along since then. The talk is a lot better now that it focuses on the proposal. The proposal itself also feels a lot more C++ like now that the backend is implementation defined. Well done Guy in pushing this proposal forwards.

[@thestickbot]

As I am a 2D game programmer, this is definitely relevant for me and it is a very interesting proposal. But I kind of feel like the focus of this talk was a bit off. Instead of naming all the classes of the library, talking about how shapes are connected, showing non-graphics code from an Asteroids clone and talking about the history of displays, I would have liked to hear more about: - A motivation for the title of the talk. How does having standard support for graphics correlate to being in the modern era? - Why would I use this instead of SDL? I would really love to use a modern C++ library rather than the very C-like SDL, but SDL is so solid that I need to be convinced that this can match it. - A better answer about the scope of the proposal. Does it handle windows and window events, or is it strictly rendering? As Guy talked about input, I'm assuming that the library will be the owner of the windows which it draws on. - Input. I know it's not done yet, but if the graphics library owns a window, it's probably responsible for window events, which means it handles input as well. Once again, could the input capabilities of this library be as good as the brilliant input handling in SDL? What about gamepad support and all that? - Game consoles. If it is part of the standard, I would assume I could use it on any game console as well. But then input handling comes up again. Game consoles might have pretty different input than PCs, so maybe input should be completely separate from rendering somehow? - UI programming for non-game applications. The talk barely mentions anything other than games. Would this be useful for cross-platform UI libraries? I think Guy did well with the points he talked about, but it's just that the talk didn't really focus much on what really interests me. It was nice to see some example code, though!

[@MeetingCPP]

I think for input it should be the same as it is for the drawing apis: these are customization points which are specified by the implementation or user. We standardize an interface, not an implementation.

[@thestickbot]

Yeah, absolutely. But still, different input devices require different interfaces, so I guess you would end up with different input libraries anyway. But if different input methods could be externally hooked up with a standardized window in a practical way, that would be really cool. Also, of course input can be completely separate from a window anyway, but some input is usually generated as events to the window.

[@MrAbrazildo]

- Alpha per pixel or surface/canvas? - Will it work with C++11 right away? - No 64 bit color, is that right?

[@ratgr]

-Alpha per pixel -no, i think they are trying to push in to c++20 (wouldn't bet on it, more like > c++23), still as it can be downloaded as a library there may be backports -Not in the default implementation, (can use custom one) PS. not involved on the project, i just browsed the code a little

[@MrAbrazildo]

I asked about C++11 because most compilers "stopped" on it. A C++20/23 could be incompatible.

[@ratgr]

gcc, clang, msvc, intel-compiler are all pretty near full c++17, avr-g++(based on gcc) is following pretty close so "most compilers"?

[@MrAbrazildo]

Hm... then I'll have to look why my Linux doesn't upgrade my C++ compilers.

[@ratgr]

yeah, depending on your distro they may come with a pretty old compiler, i think ubuntu ships with gcc-5 that is mostly c++14 complete using the flag -std=c++1y