Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

abseil.io

Post reply on HN
Print view View original

81–90 of 91 posts

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

#81

Post by flukus »

coldtea wrote: post #78
flukus wrote: post #44

Earlier quoted context omitted.

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.

> 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 ver…

> 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.

Completely disagree, the system dependencies are my dependencies and whenever possible I want to be able to "make install" and have my dependencies update with the rest of my system.

> 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.

Java has always been a "fat VM", it's a platform and not part of the system, so not surprising that it handles it's own. For python/perl/ruby, it used to be quite common to include packages from the OS repository, until they reinvented the wheel. For rust, that's why it's a joke as a "systems language".

> 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.

Entirely doable with existing package managers, just use the -root switch with dpkg or the --prefix switch with rpm or (or configure if you build from source). Typically I only want a small subset of version specific packages.

So why would I want yet another package manager when my existing one is sufficient?

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

#82

Post by Reelin »

kllrnohj wrote: post #80
Reelin wrote: post #79

Earlier quoted context omitted.

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 AP…

> My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. Non-linear blending is very common. Do a CSS gradient, for example, and it'll happen in sRGB gamma space not linear space, giving you incorrect results. Linear should be used more than it is, though, definitely. > I'd just like to point out that in principle, a hypothetical API could handle all programmer interact…

That CSS gradient example seems like a proper foot gun to me - I don't use CSS much, and I would never have expected that.

> If you're from the OpenGL world then you may be thinking of EGL_GL_COLORSPACE_LINEAR_KHR?

...I've just realized, are you talking about the EGL API (as opposed to OpenGL)? I don't actually use that - I nearly always restrict myself to an OpenGL or GLES core profile (no extensions) and use a support library (nearly always GLFW3) to handle all interfacing with the local system in a platform independent manner. It just keeps my code sane and manageable. :)

So for me, to output 8-bit non-linear sRGB colors from a fragment shader I would attach a GL_SRGB8 formatted image to my FBO. Much more typically though I would simply use GL_RGBA8 and output on the range [0, 1].

> Linear isn't a colorspace. Linear is about the gamma function, which is independent of the actual colorspace.

I was very confused by this statement and most of what followed it. After reading a bit, I think I was conflating color spaces and color models. If I understand correctly, all along I've been manipulating a linear RGB color model which was then mapped by my monitor on to (most likely) some approximation of the sRGB color space. So where I said linear earlier, I believe what I meant was any linear RGB color model (not space). Bonus points for using [0, 1] as the interval because it's easy to think about.

What it comes down to is that as a programmer, I just want to get my code working. Linear models on [0, 1] are easy to process and think about - 0 is off, 1 is on, and 0.5 is half way in between. If you want to add things together, you just add them together. Remapping from one range to another is trivial. It all just works. Sure it doesn't match up with human perception the way you might expect, but that's what the graphics API, drivers, a color calibrated display, and possibly some complicated external libraries are for, right? At least in theory.

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

#83

Post by coldtea »

flukus wrote: post #81
coldtea wrote: post #78

Earlier quoted context omitted.

> 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 ver…

> 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. Completely disagree, the system dependencies are my dependencies and whenever possible I wan…

>Completely disagree, the system dependencies are my dependencies and whenever possible I want to be able to "make install" and have my dependencies update with the rest of my system.

You can disagree, but you'd be wrong in anything that a one-map-shop setting working on a single project, and willing to depend on the distro's (or third party distro package manager repos) versions of language libraries and frameworks.

>Entirely doable with existing package managers, just use the -root switch with dpkg or the --prefix switch with rpm or (or configure if you build from source). Typically I only want a small subset of version specific packages.

Typically this is a luxury that software shops with different projects (including older, already installed), different customers, etc., can't have.

>or python/perl/ruby, it used to be quite common to include packages from the OS repository, until they reinvented the wheel

Or until those languages weren't used merely by sys-admins and one-off scripts, but for large project development, and "include packages from the OS repository" wouldn't cut it anymore.

>For rust, that's why it's a joke as a "systems language".

Total non-seguitur. In fact, one of the main goals of C++ (as per the posted roadmap) is to add a package manager.

But the total non-seguitur that "Rust is a joke as a systems language" because it has cargo I think disqualifies anything else that can be said here.

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

#84

Post by blt »

pjmlp wrote: post #61
vlovich123 wrote: post #40

Earlier quoted context omitted.

And yet having coded in Rust, Cargo solves all this bikeshedding. You can of course use your own build system but Cargo is pretty consistently used across the board which finally makes developing in a systems language as easy as Python (like virtualenv & pip but better).

Not really, cargo still doesn't provide an answer for binary libraries, and depending on how the workspace is configured and the projects one is compiling, it may end up compiling the same crates multiple times.

I feel ok about making binary libraries difficult. I want open source to be the easy path. I think the idea of abi compatibility forces a lot of unnecessary overhead on designs. Consider the radical design of TempleOS where everything is c source, jit compiled when run.

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

#85

Post by pjmlp »

blt wrote: post #84
pjmlp wrote: post #61

Earlier quoted context omitted.

Not really, cargo still doesn't provide an answer for binary libraries, and depending on how the workspace is configured and the projects one is compiling, it may end up compiling the same crates multiple times.

I feel ok about making binary libraries difficult. I want open source to be the easy path. I think the idea of abi compatibility forces a lot of unnecessary overhead on designs. Consider the radical design of TempleOS where everything is c source, jit compiled when run.

Which is ok, assuming the Rust community doesn't want to be represented in such markets and doesn't have an issue waiting for cargo building always from source.

Just don't complain about adoption then.

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

#86

Post by steveklabnik »

pjmlp wrote: post #85
blt wrote: post #84

Earlier quoted context omitted.

I feel ok about making binary libraries difficult. I want open source to be the easy path. I think the idea of abi compatibility forces a lot of unnecessary overhead on designs. Consider the radical design of TempleOS where everything is c source, jit compiled when run.

Which is ok, assuming the Rust community doesn't want to be represented in such markets and doesn't have an issue waiting for cargo building always from source. Just don't complain about adoption then.

I think you will be happy sooner rather than later, but I heard about it second hand, so I don’t want to say too much.

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

#87

Post by pjmlp »

steveklabnik wrote: post #86
pjmlp wrote: post #85

Earlier quoted context omitted.

Which is ok, assuming the Rust community doesn't want to be represented in such markets and doesn't have an issue waiting for cargo building always from source. Just don't complain about adoption then.

I think you will be happy sooner rather than later, but I heard about it second hand, so I don’t want to say too much.

Thanks, looking forward to it. :)

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

#88

Post by pcwalton »

coldtea wrote: post #77
AstralStorm wrote: post #65

Earlier quoted context omitted.

It's already there in POSIX C. (Winsocks is almost compatible.) The C++ basic version actually would be good to have. Potentially a basic threaded version too. Unlike graphics which is a moving target, even 2D. Where do you stop? Bezier paths with subdivision and full blended gradient support for those? Nonlinear projections? Fonts? Text composition? If you bite off too much, you end up with the OpenGL problem where…

> The example of a pretty bad implementation of 2D would be a) Cairo b) whatever Android and Chrome uses for drawing. And why, pray tell, are those "pretty bad"?

Cairo and Skia are immediate mode 2D graphics APIs on the JavaFX model. These APIs were designed when CPU rendering without SIMD was the norm and result in messy upload and state change problems when ported to GPUs. Google's heroic work on Ganesh with a relatively enormous team has shown that this API can be made decently fast on GPUs with a ton of work, but I don't see why we should repeat known mistakes for a brand new API that we expect to have many implementations of.

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

#89

Post by geezerjay »

pcwalton wrote: post #32

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, th…

Has nothing been learned from the current package/module ecosystems that were built around modern programming languages? I mean, has boost taught nothing?

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

#90

Post by kllrnohj »

Reelin wrote: post #82
kllrnohj wrote: post #80

Earlier quoted context omitted.

> My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. Non-linear blending is very common. Do a CSS gradient, for example, and it'll happen in sRGB gamma space not linear space, giving you incorrect results. Linear should be used more than it is, though, definitely. > I'd just like to point out that in principle, a hypothetical API could handle all programmer interact…

That CSS gradient example seems like a proper foot gun to me - I don't use CSS much, and I would never have expected that. > If you're from the OpenGL world then you may be thinking of EGL_GL_COLORSPACE_LINEAR_KHR? ...I've just realized, are you talking about the EGL API (as opposed to OpenGL)? I don't actually use that - I nearly always restrict myself to an OpenGL or GLES core profile (no extensions) and use a supp…

> ...I've just realized, are you talking about the EGL API (as opposed to OpenGL)? I don't actually use that - I nearly always restrict myself to an OpenGL or GLES core profile (no extensions) and use a support library (nearly always GLFW3) to handle all interfacing with the local system in a platform independent manner. It just keeps my code sane and manageable. :)

OpenGL/GLES don't directly do anything with color spaces or gamut. It's part of the integration with the windowing system that does it. Which in the mobile usage is typically EGL, but desktop tends to do something else like WGL.

So sounds like you're just punting this decision over to GLFW3, and you're getting whatever behavior it felt like giving you. Which is probably sRGB or linear-sRGB.

> What it comes down to is that as a programmer, I just want to get my code working. Linear models on [0, 1] are easy to process and think about - 0 is off, 1 is on, and 0.5 is half way in between. If you want to add things together, you just add them together.

Easy to think about, but also wrong :)

If you want easy, you want linear extended SRGB, aka scRGB. This gives you [0, 1] in the colors you are typically familiar with. And it means when you display pure white, you're not shoving 1,000 nits into the face of a user with an HDR monitor. But it means your valid range becomes [-0.5, 7.5] instead.

> a color calibrated display

It doesn't matter how calibrated the display is if the source content isn't color aware. When you say glClearColor(1.0, 0.0, 0.0, 1.0), which color red is the display supposed to give you? It'd be broken if it just gave you the reddest-red it can display, because then your colors will never match when going between different gamut displays.

Anything that takes a color must also be given a colorspace or have a well-defined one. Otherwise nothing about color works. And if it's a well-defined single colorspace, that single colorspace needs to cover the entire visible spectrum (which extended sRGB does, but something like DCI-P3 doesn't), otherwise it'll just become obsolete when displays get wider color gamuts.

All the legacy APIs that don't do this just behind your back say "this came from sRGB colorspace" because that's what used to happen. But anything new shouldn't be doing that, because then it won't work with HDR, wide-gamut mobile displays, etc... By which I mean "can't display the full range of colors possible on the display"

Post reply on HN