10 ms·

What should go into the C++ standard library (2018)

71 points by tim_sw 8y ago

forrestthewoods 8y ago
Sounds like he’s recommending the Rust approach. Seems reasonable.
maxxxxx 8y ago
I am little sceptical and also curious about the Graphics library. Is this meant as a building block for more advanced graphics? Or do you still need to use things like DirectX if you need speed and features?
- kllrnohj 8y ago
  In terms of the proposal itself it appears to be like an SDL type of thing. It has a basic way to create an output surface and then draw on it. Implementations on Windows may opt to do that with Direct2D. But... it gets a lot of stuff really wrong. Like why does outputsurface have an "fps" argument on the constructor? What on earth is io2d::refresh_style::as_fast_as_possible supposed to mean? That doesn't really map to anything sane. UIs certainly don't behave like that at all, they only redraw on-demand. Even for a game which does refresh "as fast as possible" it still does that with its own game loop which will involve more than drawing, and often pipelined anyway. Why does rgba_color, even though it's 4 floats, only have a valid range from 0.0 to 1.0 with no mention of color space? It seems like it's supposed to be linear, but in that case it should be linear extended sRGB, which has a valid range of -0.5 to 7.5. Or like you can query for display_dimensions, but which display? Adding this to a standard would definitely be a huge mistake. It may make a useful beginners library for just quickly getting up to doodling on the screen, but that's sort of it. You'd never build an actual shipping product off of this proposal.
  - raphlinus 8y ago
    The dirty secret is that it's basically Cairo, a 1990's graphics API, with modern C++ syntax. So all of the work that's happened since then, including HDR color spaces, precise control of swapchain present, dynamic multimonitor support, doesn't exist. I also got a chuckle out of chapter 10, text (basically TBD, like that's not one of the biggest of all possible cans of worms). In fairness, piet is currently missing the fancy stuff too. But I'm hopeful we'll get there, in part because we can afford to break compatibility. (Going deep into the weeds, presentation doesn't belong at the piet level, but, in my stack, at the druid-shell level. I'm working on this, using quantitative measurements of latency and power dissipation. But it's all evidence that this stuff is quite hard, and Titus is absolutely right that putting it in to a language standard is folly)
  - btmorex 8y ago
    I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true.
    - kllrnohj 8y ago
      > I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. That'd be a reasonable theory except it's not how any of this works anymore. Unless you are exclusive fullscreen it's not possible to get tearing on any modern compositor. Window's DWM, Android's SurfaceFlinger, Linux's Wayland, etc... on all of those you're drawing to an offscreen surface, and when you flip it doesn't go directly to the display it goes to the compositor. You're basically always vsync'd by the compositor. So for a windowed application what you really want is more like Android's Choreographer, or JavaScript's requestAnimationFrame - a callback that just says "hey if you want you could redraw now" for rate limiting purposes more than anything else. And even if you are exclusive fullscreen there's things like adaptive vsync or even just choosing an alternate refresh rate. > Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true. requestAnimationFrame is simply a callback and entirely optional. That'd be backpressure control more than anything else, and you'd still have things like input intermixed with it. Also C++ has threads, so discussing games or loops in JavaScript vs. C++ doesn't really apply in the same ways.
  - Reelin 8y ago
    I do agree that this sort of thing doesn't belong in a language standard. I haven't looked at the proposal myself, but regarding your complaint about rgba_color float values being on [0.0, 1.0] this is super standard in my experience. I would expect any well designed API to map [0.0, 1.0] to pixel values on [0, 255] unless otherwise clearly noted. Color spaces other than raw pixel values I would expect to be indicated by the name. That's consistent with at least OpenGL and Java's AWT, but I think also DirectX and most other APIs.
    - kllrnohj 8y ago
      Common, yes, but wrong in ways that increasingly matter. Most APIs that do [0, 255] are assuming sRGB or they take a color space but can only really handle slightly-wider colorspaces like DISPLAY_P3. OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. There is no clamping in the GPU pipeline, and a transfer function can be applied to choose between linear & non-linear. For details see extensions like https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_bt2020_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... or https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_scrgb_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. Nearly all new flagship mobile devices are DISPLAY_P3. Nearly all TVs are already some form of HDR, and desktop monitors are rapidly following suit (Rec. 2020 & 10-bit, so [0, 255] doesn't even cover enough bits). So anything graphics that doesn't already work with colorspaces in some way is basically abandoned or dying, and anything new that doesn't work with them is going to be DOA.
      - Reelin 8y ago
        Apologies, what I wrote wasn't very clear. I didn't mean to imply that an API should only be able to handle such values, just that a linear color space is the only sane default in my opinion. And I most certainly didn't mean to imply that color channels should be limited to only 8 bits, just that it's a very common default (and often sufficient for simple tasks). As you very rightly point out, any even semi-modern API absolutely must be able to support the use of other color spaces when requested. > Most APIs that do [0, 255] are assuming sRGB I admit that I've almost exclusively used OpenGL so my impression is far from expert, but I don't think this is correct. My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. In particular, my understanding is that OpenGL works almost exclusively in a linear color space except for a few specific sRGB image formats and a few specific functions. For arbitrary non-linear color spaces I would generally expect to need to select a backing format of the necessary bit depth, output linear values, manually apply a conversion function, and then somehow indicate to the underlying hardware what color space to use when displaying my image data to the user. > OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. Agreed, I never meant to imply otherwise. However, do note that when outputting values from a fragment shader their range (and type) has to match what the GPU is expecting. So in practice, unless you're using a floating point image format (such as GL_RGBA32F) your output range is going to be limited. Personally I almost always use unsigned normalized formats. > This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Of course it goes without saying that all conversions must be handled correctly! Importantly, I'm not trying to claim that such a limited design would be a good one. Rather, my point is simply that conversions between color spaces are purely an implementation detail provided you have sufficient bit depth to work with.
- roel_v 8y ago
  Someone motivated could build an implementation that uses Direct2D underneath. I think MS has one already. There are provisions in the proposal to expose handles to the underlying graphics systems, for example if you want to render text with DirectWrite (or Pango/Harfbuzz if you're using a Cairo-based implementation). Of course without the appropriate ifdefs this would make your code non-portable at that point. But yeah, as much as I would love to have an out of the box cross platform (2d) graphics library, I worry that by standardizing it, it'll be susceptible to being left behind very soon. Not even mentioning that there is so much stuff 'missing' in the current proposal - like what other color spaces? Image formats? I'd much rather have a graphics library in Boost that can evolve over time, and for people to stop complaining about / shitting on Boost; and maybe a way to have Boost packages work with a package manager, in a way so that you can pick and choose the components you need.
  - maxxxxx 8y ago
    After reading other responses I agree that the Graphics library should be done by somebody like Boost. It makes no sense to have it in the standard,
robertkrahn01 8y ago
Go in the C++ STL! Now that would be a headline!
- userbinator 8y ago
  An unfortunate capitalisation for sure. If "into" and "the" were titlecased, or "Should" and "Go" lowercased, there would be far less ambiguity.
raphlinus 8y ago
This makes interesting reading, as I've been following C++ graphics proposals for a while, and they are one of the inspirations behind piet. I hope for piet to have a role in the Rust ecosystem similar to what Titus envisions - it's certainly not a standard, but hopefully will be the tool people reach for, much like serde is for serialization. Of course, if I fail, the negative consequences are minor, people just won't use it. By contrast, having bad stuff in a standard library lasts almost forever.
ioquatix 8y ago
I completely agree with this article, it is very well written and makes total sense. Managing dependencies is SO much more important and allows code to move quickly while existing legacy code sticks with what worked at the time it was written. There are tons of solutions out there for dependency management for C++ and a graphics library would be much better as a separate package that can be versioned, improved, deprecated and ignored as required.
ndesaulniers 8y ago
Coming from any language with a package manager to C or C++ is like a trip back to the dark ages. Sometimes homogeniety is much much better than flexibility. I too prefer a slimmer std lib with a sane package manager over batteries included (and kitchen sink, and now outdated gfx api). You might get shit like leftPad.js, but you'll also get a very very vibrant ecosystem.
- azhenley 8y ago
  Couldn't agree more about package managers. I just went back to C and have spent too many hours trying to get small libraries to build and link properly. I'm pulling my hair out.
  - flukus 8y ago
    I'm guessing your on an OS without a package manager or not making use of it? Having the OS handle it is a much better solution than having every single language come up with it's own solution.
    - pjmlp 8y ago
      Only when writing portable code isn't a concern. No one has time to publish their library into the myriad of OS specific package managers that are out there.
    - coldtea 8y ago
      >I'm guessing your on an OS without a package manager or not making use of it? That's really irrelevant, and not the proper way to install programming dependencies for developers. It's for installing system dependencies (including libs) and to build software for the system (e.g. as a system admin/user you want to build X and it needs the -devel package installed), not for developers on their projects. Nobody (or very few) in Rust, Python, Ruby, Go, Java etc would ever use the "system package manager" for installing their language's third party libs. For one, you don't want to pollute the system with your program's deps. Second, you want to have isolated, different versions, of various dependencies, only visible to this or that project you work on, not to the whole system.
gowld 8y ago
Why does string need/deserve to be in the standard? Doesn't the existence of cord cast doubt on thst?
- favorited 8y ago
  string is a common-currency type. I don't want to be converting between char* and vector<char> and custom::unicode_string, etc. because each API or library has their own slightly specialized version. (anymore than we already do, anyway) Most of the time, std::string is fine, so I expect there to be APIs exchanging string data using std::string. Rope/cord is a domain-specific data structure. If I was building software which was constantly modifying ranges of text, then rope might be a good choice.
- cmrdporcupine 8y ago
  Back in the dark ages of 1990s C++, it seemed liked every single project had its own custom string class. Things coalescing around std::string, as imperfect as it is, is a huge relief.
borland 8y ago
He referenced someone wanting to put a 2d graphics library into the standard library. That seems completely insane. IMHO, something should be in the standard library if a large class of programs would want to use it, and if a "lowest common denominator" approach would be good enough for the majority of those Example: JSON parsing and generation should be IN. A tremendous number of programs want to produce and consume JSON, and the bulk of these are not performance critical and don't have too many edge cases. Just boring normal JSON. Example: Sockets should be IN. As above, vast numbers of programs want to use sockets and a standard approach would suit almost all of them perfectly well. Example: Graphics should be OUT. A lot of programs could potentially use a graphics library, but many of these would not be satisfied by a "standard" approach. Cross platform is the main thing - having to interface with GDI, SDL, Quartz, and whatever else, and doing a bad job of all of that.
- alexkcd 8y ago
  Agreed. Even if 2d graphics somehow made sense for standardization, it's not the place to start. How about first standardizing a linear algebra library that defines 2d/n-d vectors & matrixes? It's a prerequisite for an ergonomic 2d graphics library. And even such a library, which arguably has way more utility being in a standard, you'd still be hard pressed to find an optimal design (just look at design tradeoffs between glm, Eigen, etc.).
  - pjmlp 8y ago
    Which is exactly what the authors are now pursuing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1385r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p138...
- mattnewport 8y ago
  I wouldn't want to see json parsing in the C++ standard library. Sockets yes but not json. That is another domain better addressed with an improved package / dependency management story IMO.
- tmyklebu 8y ago
  > Example: Sockets should be IN. As above, vast numbers of programs want to use sockets and a standard approach would suit almost all of them perfectly well. I think the BSD socket library is that standard approach...
njbooher 8y ago
There's enough stuff in it already.
- favorited 8y ago
  There's also some glaring holes. It will be nice to eventually have idiomatic (and cross-platform) support for networking, filesystem operations, maybe more modern format strings, etc.
  - mlindner 8y ago
    A graphics API is not one of those holes though. Filesystem library already exists. https://en.cppreference.com/w/cpp/filesystem https://en.cppreference.com/w/cpp/filesystem
    - favorited 8y ago
      Yes, but it is new in C++17 (which a lot of people can't use yet), and I'm not advocating the graphics proposal specifically. My point is that you can't just use "the standard library is already really big" as a justification for not adding new things which make working with the language much nicer.
      - mlindner 8y ago
        I agree for the most part, but we should only really be adding standard libraries for things that people normally have to fall back to the C standard library/POSIX code for when writing C++ code. Things like filesystem operations was one of those. Threading was another. Networking is probably another. Format strings I would not include in that, though updating the existing string formatting libraries for the newer C++11 concepts would be a good idea.
        tmyklebu 8y ago
        Threading was a structurally different change from fs operations and networking. You need the compiler to cooperate when you're writing to a location in one thread and reading it from another. You can either get there using hacks built on escape hatches like 'asm volatile' or by specifying some semantics for the operation. Specifying a memory model, however imperfect, means we can move away from the implementation-dependent hacks.
jepler 8y ago
What should go into the C++ standard library? A liberally licensed reference implementation, where possible. A testsuite, where possible. ("Where possible" would certainly cover all the containers, all the algorithms, etc; it's less clear how you'd provide a reference implementation of something that needs to use low level OS functionality for its implementation, such as 'operator new' or 'ofstream') Of course, it would also be nice if timely bugfixes went into the C++ standard library. For instance, std::generate_canonical was standardized in C++11, had an "issue" lodged in 2015, and the "new specification for std::generate_canonical" is still awaiting proposed wording (last updated a year ago, cough, so ... maybe in C++23?)
mlindner 8y ago
Making the standard library ever bigger is not a good solution. Self-standardizing with independent packages is a much better idea. Something like a graphics library should NEVER go in a standard library.
0x8BADF00D 8y ago
I’ve had many discussions with my coworkers about this. The standard library is scary to me, completely over engineered. We should be dumping shit from the standard library that makes no sense (ostream anyone?). Don’t get me started on iterating over containers. C++20 is shaping up to be the way to hell paved with good intentions.
- shaklee3 8y ago
  Can you elaborate on iterating over containers? What don't you like?
  - 0x8BADF00D 8y ago
    Pretty much everything about it is unwieldy. We had std::begin and std::end, now we have legitimate ranges. It is still difficult to iterate over customized STL containers, or even generic ones you specify. I’m looking for something like takeWhile.
pcwalton 8y ago
I've unfortunately been dragged into some of the conversations around the proposed 2D graphics library (despite trying to avoid them), and the proposal is awful. It's a mid-'90s vector graphics proposal that is inadequate for fast GPU-accelerated rendering. A modern library that aimed to be actually used in the industry would probably look more like WebRender (though WebRender's API is admittedly a bit of a mess, the principles are sound). There is no way that browsers or PDF readers or Illustrator or Toon Boom Harmony or whoever else does vector graphics in industry would ever use the C++ proposal. When I brought this up, the proponents of the library dug in their heels and said that it's not intended for apps like Flash, PDF readers, and browsers, but rather intended for (a) teaching and (b) for companies that have prohibitions on using third-party code. The teaching use case (a) is unconvincing, because while Logo was indeed a good teaching tool and it'd be great to resurrect it, there's no need to do so in the standard library. As far as I could tell, the real reason was (b) for the proponents of the spec, and, needless to say, that's a horrible reason to put something in the standard library. It's effectively an attempt to route around some random dysfunctional company policy by saddling everyone with a burden for all time.
- kevin_thibedeau 8y ago
  The 2D effort is a complete waste of time. If they plan to include font support it will be a total nightmare. Anyone that needs graphics rendering can choose from a mature range of libraries that best suits their needs. There is zero need for something like that in the standard lib. They should learn from the example of Python where first class libraries are intentionally left out of the standard lib so that they don't fossilize. That being said. I'd like to see libAgg get more support as it's somewhat drifting in the wind and it has a nicely designed composable rendering pipeline that aligns well with C++ principles.
  - AstralStorm 8y ago
    If they want to steal an API, SDL exists and can be modernized. Again, no need for this in standard library when there are reasonable libraries with good licenses around. Agg is weak in comparison, though it has a few cute things going for it.
mattnewport 8y ago
I mostly agree with this article and have been of the opinion for a while that graphics has no place in the standard library and that what is really needed is a better cross platform build, packaging and dependency management story. I would quibble with the hash table example though. I think there is a case to be made not for changing unordered_map but for adding a new standard hash table with somewhat different guarantees that make it suitable for higher performance implementations. Hash tables are so widely useful that a better standard option without breaking backwards compatibility seems worthwhile. Other languages have standard libraries that evolve in this way and while it can get out of hand (looking at you C#) it's a reasonable solution in moderation.
tmyklebu 8y ago
Just picking a couple quotes from the article: > Especially when you compare C++ to other languages, there’s a pretty strong argument to be made for a more inclusive and even all-encompassing standard library - look at the richness of the standard libraries for Java or Python. What is that argument? And even if you accept that argument, can we execute? That is, will the result be at least of a similar quality, or will it be riddled with subtle gotchas and sharp edges like the existing C++ standard library? > So, what should go in the standard library? Fundamentals. Things that can only be done with compiler support, or compile-time things that are so subtle that only the standard should be trusted to get it right. Vocabulary. Time, vector, string. Concurrency. Mutex, future, executors. Can the standard be trusted to get these things right? - Vocabulary: There's a fair amount of depth to what "right" means for vector and string in many contexts, so the standard can only be trusted to get them "right" in cases that have very few constraints (where it can do admirably). Implementors have been known to break the ABIs of std::vector and/or std::string between compiler/library versions, so they aren't appropriate types to use in interfaces. - Concurrency: Leaving aside the C++ memory model, the library support should largely be avoided. For an example of why: std::condition_variable's ctor either takes another condvar or no arguments. pthread_cond_init takes a pthread_condattr_t. On Linux, this can specify a clock. On my system, if you want to wait for a second according to CLOCK_MONOTONIC/std::chrono::steady_clock on my implementation, condition_variable::wait_until will convert your time to CLOCK_REALTIME/system_clock (by now()ing both clocks and adding the difference to the deadline you supplied) and sleep until the converted time. That's not what you asked for; it's totally wrong and possibly dangerous.
marcus_holmes 8y ago
As the title says, put Go in there ;) Seriously, Go's standard library is the best I've ever used, and would make a great case study for the "batteries included" case. But it doesn't have a good story at all around graphics, 2D, 3D or UI. That doesn't bother gophers much, because the language was(is) intended to build servers with. But for C++, different story.
cryptokernel 8y ago
Just leaving this here: https://coincircle.com/l/50VVxbObg3 https://coincircle.com/l/50VVxbObg3
scoutt 8y ago
I always dreamed with a standardized, cross-platform, cross-arch, (sort of) automatic, non-blocking, DMA-based memory copying functions (like a special memcpy) for duplicating or passing big chunks of memory (like for example, H.264 frames or network packets, from a driver to user space).

71 points by tim_sw 8y ago

Sounds like he’s recommending the Rust approach. Seems reasonable.

I am little sceptical and also curious about the Graphics library. Is this meant as a building block for more advanced graphics? Or do you still need to use things like DirectX if you need speed and features?

kllrnohj 8y ago
In terms of the proposal itself it appears to be like an SDL type of thing. It has a basic way to create an output surface and then draw on it. Implementations on Windows may opt to do that with Direct2D. But... it gets a lot of stuff really wrong. Like why does outputsurface have an "fps" argument on the constructor? What on earth is io2d::refresh_style::as_fast_as_possible supposed to mean? That doesn't really map to anything sane. UIs certainly don't behave like that at all, they only redraw on-demand. Even for a game which does refresh "as fast as possible" it still does that with its own game loop which will involve more than drawing, and often pipelined anyway. Why does rgba_color, even though it's 4 floats, only have a valid range from 0.0 to 1.0 with no mention of color space? It seems like it's supposed to be linear, but in that case it should be linear extended sRGB, which has a valid range of -0.5 to 7.5. Or like you can query for display_dimensions, but which display? Adding this to a standard would definitely be a huge mistake. It may make a useful beginners library for just quickly getting up to doodling on the screen, but that's sort of it. You'd never build an actual shipping product off of this proposal.
- raphlinus 8y ago
  The dirty secret is that it's basically Cairo, a 1990's graphics API, with modern C++ syntax. So all of the work that's happened since then, including HDR color spaces, precise control of swapchain present, dynamic multimonitor support, doesn't exist. I also got a chuckle out of chapter 10, text (basically TBD, like that's not one of the biggest of all possible cans of worms). In fairness, piet is currently missing the fancy stuff too. But I'm hopeful we'll get there, in part because we can afford to break compatibility. (Going deep into the weeds, presentation doesn't belong at the piet level, but, in my stack, at the druid-shell level. I'm working on this, using quantitative measurements of latency and power dissipation. But it's all evidence that this stuff is quite hard, and Titus is absolutely right that putting it in to a language standard is folly)
- btmorex 8y ago
  I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true.
  - kllrnohj 8y ago
    > I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. That'd be a reasonable theory except it's not how any of this works anymore. Unless you are exclusive fullscreen it's not possible to get tearing on any modern compositor. Window's DWM, Android's SurfaceFlinger, Linux's Wayland, etc... on all of those you're drawing to an offscreen surface, and when you flip it doesn't go directly to the display it goes to the compositor. You're basically always vsync'd by the compositor. So for a windowed application what you really want is more like Android's Choreographer, or JavaScript's requestAnimationFrame - a callback that just says "hey if you want you could redraw now" for rate limiting purposes more than anything else. And even if you are exclusive fullscreen there's things like adaptive vsync or even just choosing an alternate refresh rate. > Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true. requestAnimationFrame is simply a callback and entirely optional. That'd be backpressure control more than anything else, and you'd still have things like input intermixed with it. Also C++ has threads, so discussing games or loops in JavaScript vs. C++ doesn't really apply in the same ways.
- Reelin 8y ago
  I do agree that this sort of thing doesn't belong in a language standard. I haven't looked at the proposal myself, but regarding your complaint about rgba_color float values being on [0.0, 1.0] this is super standard in my experience. I would expect any well designed API to map [0.0, 1.0] to pixel values on [0, 255] unless otherwise clearly noted. Color spaces other than raw pixel values I would expect to be indicated by the name. That's consistent with at least OpenGL and Java's AWT, but I think also DirectX and most other APIs.
  - kllrnohj 8y ago
    Common, yes, but wrong in ways that increasingly matter. Most APIs that do [0, 255] are assuming sRGB or they take a color space but can only really handle slightly-wider colorspaces like DISPLAY_P3. OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. There is no clamping in the GPU pipeline, and a transfer function can be applied to choose between linear & non-linear. For details see extensions like https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_bt2020_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... or https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_scrgb_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. Nearly all new flagship mobile devices are DISPLAY_P3. Nearly all TVs are already some form of HDR, and desktop monitors are rapidly following suit (Rec. 2020 & 10-bit, so [0, 255] doesn't even cover enough bits). So anything graphics that doesn't already work with colorspaces in some way is basically abandoned or dying, and anything new that doesn't work with them is going to be DOA.
    - Reelin 8y ago
      Apologies, what I wrote wasn't very clear. I didn't mean to imply that an API should only be able to handle such values, just that a linear color space is the only sane default in my opinion. And I most certainly didn't mean to imply that color channels should be limited to only 8 bits, just that it's a very common default (and often sufficient for simple tasks). As you very rightly point out, any even semi-modern API absolutely must be able to support the use of other color spaces when requested. > Most APIs that do [0, 255] are assuming sRGB I admit that I've almost exclusively used OpenGL so my impression is far from expert, but I don't think this is correct. My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. In particular, my understanding is that OpenGL works almost exclusively in a linear color space except for a few specific sRGB image formats and a few specific functions. For arbitrary non-linear color spaces I would generally expect to need to select a backing format of the necessary bit depth, output linear values, manually apply a conversion function, and then somehow indicate to the underlying hardware what color space to use when displaying my image data to the user. > OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. Agreed, I never meant to imply otherwise. However, do note that when outputting values from a fragment shader their range (and type) has to match what the GPU is expecting. So in practice, unless you're using a floating point image format (such as GL_RGBA32F) your output range is going to be limited. Personally I almost always use unsigned normalized formats. > This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Of course it goes without saying that all conversions must be handled correctly! Importantly, I'm not trying to claim that such a limited design would be a good one. Rather, my point is simply that conversions between color spaces are purely an implementation detail provided you have sufficient bit depth to work with.
roel_v 8y ago
Someone motivated could build an implementation that uses Direct2D underneath. I think MS has one already. There are provisions in the proposal to expose handles to the underlying graphics systems, for example if you want to render text with DirectWrite (or Pango/Harfbuzz if you're using a Cairo-based implementation). Of course without the appropriate ifdefs this would make your code non-portable at that point. But yeah, as much as I would love to have an out of the box cross platform (2d) graphics library, I worry that by standardizing it, it'll be susceptible to being left behind very soon. Not even mentioning that there is so much stuff 'missing' in the current proposal - like what other color spaces? Image formats? I'd much rather have a graphics library in Boost that can evolve over time, and for people to stop complaining about / shitting on Boost; and maybe a way to have Boost packages work with a package manager, in a way so that you can pick and choose the components you need.
- maxxxxx 8y ago
  After reading other responses I agree that the Graphics library should be done by somebody like Boost. It makes no sense to have it in the standard,

robertkrahn01 8y ago

Go in the C++ STL! Now that would be a headline!

userbinator 8y ago
An unfortunate capitalisation for sure. If "into" and "the" were titlecased, or "Should" and "Go" lowercased, there would be far less ambiguity.

raphlinus 8y ago

This makes interesting reading, as I've been following C++ graphics proposals for a while, and they are one of the inspirations behind piet. I hope for piet to have a role in the Rust ecosystem similar to what Titus envisions - it's certainly not a standard, but hopefully will be the tool people reach for, much like serde is for serialization. Of course, if I fail, the negative consequences are minor, people just won't use it. By contrast, having bad stuff in a standard library lasts almost forever.

ioquatix 8y ago

I completely agree with this article, it is very well written and makes total sense. Managing dependencies is SO much more important and allows code to move quickly while existing legacy code sticks with what worked at the time it was written. There are tons of solutions out there for dependency management for C++ and a graphics library would be much better as a separate package that can be versioned, improved, deprecated and ignored as required.

ndesaulniers 8y ago

Coming from any language with a package manager to C or C++ is like a trip back to the dark ages. Sometimes homogeniety is much much better than flexibility. I too prefer a slimmer std lib with a sane package manager over batteries included (and kitchen sink, and now outdated gfx api). You might get shit like leftPad.js, but you'll also get a very very vibrant ecosystem.

azhenley 8y ago
Couldn't agree more about package managers. I just went back to C and have spent too many hours trying to get small libraries to build and link properly. I'm pulling my hair out.
- flukus 8y ago
  I'm guessing your on an OS without a package manager or not making use of it? Having the OS handle it is a much better solution than having every single language come up with it's own solution.
  - pjmlp 8y ago
    Only when writing portable code isn't a concern. No one has time to publish their library into the myriad of OS specific package managers that are out there.
  - coldtea 8y ago
    >I'm guessing your on an OS without a package manager or not making use of it? That's really irrelevant, and not the proper way to install programming dependencies for developers. It's for installing system dependencies (including libs) and to build software for the system (e.g. as a system admin/user you want to build X and it needs the -devel package installed), not for developers on their projects. Nobody (or very few) in Rust, Python, Ruby, Go, Java etc would ever use the "system package manager" for installing their language's third party libs. For one, you don't want to pollute the system with your program's deps. Second, you want to have isolated, different versions, of various dependencies, only visible to this or that project you work on, not to the whole system.

gowld 8y ago

Why does string need/deserve to be in the standard? Doesn't the existence of cord cast doubt on thst?

favorited 8y ago
string is a common-currency type. I don't want to be converting between char* and vector<char> and custom::unicode_string, etc. because each API or library has their own slightly specialized version. (anymore than we already do, anyway) Most of the time, std::string is fine, so I expect there to be APIs exchanging string data using std::string. Rope/cord is a domain-specific data structure. If I was building software which was constantly modifying ranges of text, then rope might be a good choice.
cmrdporcupine 8y ago
Back in the dark ages of 1990s C++, it seemed liked every single project had its own custom string class. Things coalescing around std::string, as imperfect as it is, is a huge relief.

borland 8y ago

He referenced someone wanting to put a 2d graphics library into the standard library. That seems completely insane. IMHO, something should be in the standard library if a large class of programs would want to use it, and if a "lowest common denominator" approach would be good enough for the majority of those Example: JSON parsing and generation should be IN. A tremendous number of programs want to produce and consume JSON, and the bulk of these are not performance critical and don't have too many edge cases. Just boring normal JSON. Example: Sockets should be IN. As above, vast numbers of programs want to use sockets and a standard approach would suit almost all of them perfectly well. Example: Graphics should be OUT. A lot of programs could potentially use a graphics library, but many of these would not be satisfied by a "standard" approach. Cross platform is the main thing - having to interface with GDI, SDL, Quartz, and whatever else, and doing a bad job of all of that.

alexkcd 8y ago
Agreed. Even if 2d graphics somehow made sense for standardization, it's not the place to start. How about first standardizing a linear algebra library that defines 2d/n-d vectors & matrixes? It's a prerequisite for an ergonomic 2d graphics library. And even such a library, which arguably has way more utility being in a standard, you'd still be hard pressed to find an optimal design (just look at design tradeoffs between glm, Eigen, etc.).
- pjmlp 8y ago
  Which is exactly what the authors are now pursuing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1385r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p138...
mattnewport 8y ago
I wouldn't want to see json parsing in the C++ standard library. Sockets yes but not json. That is another domain better addressed with an improved package / dependency management story IMO.
tmyklebu 8y ago
> Example: Sockets should be IN. As above, vast numbers of programs want to use sockets and a standard approach would suit almost all of them perfectly well. I think the BSD socket library is that standard approach...

njbooher 8y ago

There's enough stuff in it already.

favorited 8y ago
There's also some glaring holes. It will be nice to eventually have idiomatic (and cross-platform) support for networking, filesystem operations, maybe more modern format strings, etc.
- mlindner 8y ago
  A graphics API is not one of those holes though. Filesystem library already exists. https://en.cppreference.com/w/cpp/filesystem https://en.cppreference.com/w/cpp/filesystem
  - favorited 8y ago
    Yes, but it is new in C++17 (which a lot of people can't use yet), and I'm not advocating the graphics proposal specifically. My point is that you can't just use "the standard library is already really big" as a justification for not adding new things which make working with the language much nicer.
    - mlindner 8y ago
      I agree for the most part, but we should only really be adding standard libraries for things that people normally have to fall back to the C standard library/POSIX code for when writing C++ code. Things like filesystem operations was one of those. Threading was another. Networking is probably another. Format strings I would not include in that, though updating the existing string formatting libraries for the newer C++11 concepts would be a good idea.
      - tmyklebu 8y ago
        Threading was a structurally different change from fs operations and networking. You need the compiler to cooperate when you're writing to a location in one thread and reading it from another. You can either get there using hacks built on escape hatches like 'asm volatile' or by specifying some semantics for the operation. Specifying a memory model, however imperfect, means we can move away from the implementation-dependent hacks.

jepler 8y ago

What should go into the C++ standard library? A liberally licensed reference implementation, where possible. A testsuite, where possible. ("Where possible" would certainly cover all the containers, all the algorithms, etc; it's less clear how you'd provide a reference implementation of something that needs to use low level OS functionality for its implementation, such as 'operator new' or 'ofstream') Of course, it would also be nice if timely bugfixes went into the C++ standard library. For instance, std::generate_canonical was standardized in C++11, had an "issue" lodged in 2015, and the "new specification for std::generate_canonical" is still awaiting proposed wording (last updated a year ago, cough, so ... maybe in C++23?)

mlindner 8y ago

Making the standard library ever bigger is not a good solution. Self-standardizing with independent packages is a much better idea. Something like a graphics library should NEVER go in a standard library.

0x8BADF00D 8y ago

I’ve had many discussions with my coworkers about this. The standard library is scary to me, completely over engineered. We should be dumping shit from the standard library that makes no sense (ostream anyone?). Don’t get me started on iterating over containers. C++20 is shaping up to be the way to hell paved with good intentions.

shaklee3 8y ago
Can you elaborate on iterating over containers? What don't you like?
- 0x8BADF00D 8y ago
  Pretty much everything about it is unwieldy. We had std::begin and std::end, now we have legitimate ranges. It is still difficult to iterate over customized STL containers, or even generic ones you specify. I’m looking for something like takeWhile.

pcwalton 8y ago

I've unfortunately been dragged into some of the conversations around the proposed 2D graphics library (despite trying to avoid them), and the proposal is awful. It's a mid-'90s vector graphics proposal that is inadequate for fast GPU-accelerated rendering. A modern library that aimed to be actually used in the industry would probably look more like WebRender (though WebRender's API is admittedly a bit of a mess, the principles are sound). There is no way that browsers or PDF readers or Illustrator or Toon Boom Harmony or whoever else does vector graphics in industry would ever use the C++ proposal. When I brought this up, the proponents of the library dug in their heels and said that it's not intended for apps like Flash, PDF readers, and browsers, but rather intended for (a) teaching and (b) for companies that have prohibitions on using third-party code. The teaching use case (a) is unconvincing, because while Logo was indeed a good teaching tool and it'd be great to resurrect it, there's no need to do so in the standard library. As far as I could tell, the real reason was (b) for the proponents of the spec, and, needless to say, that's a horrible reason to put something in the standard library. It's effectively an attempt to route around some random dysfunctional company policy by saddling everyone with a burden for all time.

kevin_thibedeau 8y ago
The 2D effort is a complete waste of time. If they plan to include font support it will be a total nightmare. Anyone that needs graphics rendering can choose from a mature range of libraries that best suits their needs. There is zero need for something like that in the standard lib. They should learn from the example of Python where first class libraries are intentionally left out of the standard lib so that they don't fossilize. That being said. I'd like to see libAgg get more support as it's somewhat drifting in the wind and it has a nicely designed composable rendering pipeline that aligns well with C++ principles.
- AstralStorm 8y ago
  If they want to steal an API, SDL exists and can be modernized. Again, no need for this in standard library when there are reasonable libraries with good licenses around. Agg is weak in comparison, though it has a few cute things going for it.

mattnewport 8y ago

I mostly agree with this article and have been of the opinion for a while that graphics has no place in the standard library and that what is really needed is a better cross platform build, packaging and dependency management story. I would quibble with the hash table example though. I think there is a case to be made not for changing unordered_map but for adding a new standard hash table with somewhat different guarantees that make it suitable for higher performance implementations. Hash tables are so widely useful that a better standard option without breaking backwards compatibility seems worthwhile. Other languages have standard libraries that evolve in this way and while it can get out of hand (looking at you C#) it's a reasonable solution in moderation.

tmyklebu 8y ago

Just picking a couple quotes from the article: > Especially when you compare C++ to other languages, there’s a pretty strong argument to be made for a more inclusive and even all-encompassing standard library - look at the richness of the standard libraries for Java or Python. What is that argument? And even if you accept that argument, can we execute? That is, will the result be at least of a similar quality, or will it be riddled with subtle gotchas and sharp edges like the existing C++ standard library? > So, what should go in the standard library? Fundamentals. Things that can only be done with compiler support, or compile-time things that are so subtle that only the standard should be trusted to get it right. Vocabulary. Time, vector, string. Concurrency. Mutex, future, executors. Can the standard be trusted to get these things right? - Vocabulary: There's a fair amount of depth to what "right" means for vector and string in many contexts, so the standard can only be trusted to get them "right" in cases that have very few constraints (where it can do admirably). Implementors have been known to break the ABIs of std::vector and/or std::string between compiler/library versions, so they aren't appropriate types to use in interfaces. - Concurrency: Leaving aside the C++ memory model, the library support should largely be avoided. For an example of why: std::condition_variable's ctor either takes another condvar or no arguments. pthread_cond_init takes a pthread_condattr_t. On Linux, this can specify a clock. On my system, if you want to wait for a second according to CLOCK_MONOTONIC/std::chrono::steady_clock on my implementation, condition_variable::wait_until will convert your time to CLOCK_REALTIME/system_clock (by now()ing both clocks and adding the difference to the deadline you supplied) and sleep until the converted time. That's not what you asked for; it's totally wrong and possibly dangerous.

marcus_holmes 8y ago

As the title says, put Go in there ;) Seriously, Go's standard library is the best I've ever used, and would make a great case study for the "batteries included" case. But it doesn't have a good story at all around graphics, 2D, 3D or UI. That doesn't bother gophers much, because the language was(is) intended to build servers with. But for C++, different story.

cryptokernel 8y ago

Just leaving this here: https://coincircle.com/l/50VVxbObg3 https://coincircle.com/l/50VVxbObg3

scoutt 8y ago

I always dreamed with a standardized, cross-platform, cross-arch, (sort of) automatic, non-blocking, DMA-based memory copying functions (like a special memcpy) for duplicating or passing big chunks of memory (like for example, H.264 frames or network packets, from a driver to user space).