5 ms·

Features like this make me think that C++ is designed by people who think that perfection is reached when there is nothing more to add. As a C developer, I sid

Features like this make me think that C++ is designed by people who think that perfection is reached when there is nothing more to add. As a C developer, I side with Antoine de Saint Exupéry.

cbsmith 11y ago
Sigh... Too often that criticism is leveled at C++ without an understanding of the terrain. I don't think C developers should be sitting on a high horse on this one. C represents a pretty good example of the problem. Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution, so any correct program completely bypasses that infrastructure and/or has a ton of additional code/complexity layered on top of it. That open source basically festered until the C++11 <random> proposal was accepted. The chief proponents of that proposal were, of course, those with the most sophisticated needs & understanding for random functions, and the proposal reflects that. So, the problems with that proposal are arguably a consequence of the flaws in the original C standard. What remains to be done is to harmonize that proposal with something that makes sense to less sophisticated users, who nonetheless have reached the point where their appreciate the problems with C's random functions.
- cperciva 11y ago
  Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution Right, and that function is a mistake in the C standard. It should have been omitted entirely.
  - cbsmith 11y ago
    That would have messed with C++'s goal of providing compatibility for C code. Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.
    - cperciva 11y ago
      You misunderstand me. I think random(3) should have been omitted from the C standard.
      - pcwalton 11y ago
        What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. See, for example, crypto before NaCl came around. (NB: I'm not defending either this C++ standard or random(3).)
        cperciva 11y ago
        What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. Sure... but what happens if you do specify that implementations should be built-in is that a diverse, bewildering ecosystem of broken implementations get built in, and so people who know what they're doing end up eschewing the built-in implementations in favour of shipping with an implementation which they know works. And ultimately you have a standard function which everybody provides for compatibility purposes, but which nobody should ever use. See, for example, random(3). Functionality should be added to standards when we can be confident that every implementation in the next 100 years will get it right, and no sooner.
        marssaxman 11y ago
        I thought NaCl was something related to browser plugins. What is the connection with crypto?
        ori_b 11y ago
        Name collisions: http://nacl.cr.yp.to/ http://nacl.cr.yp.to/ Although, I've never actually seen it used in the wild.
- cbsmith 11y ago
  > That open source Man, autocorrect killed me there. That should be "That open sore".
- JoachimSchipper 11y ago
  random(3) is clearly bad; but contrast this proposal with the simplicity (and security) of OpenBSD's arc4random(), arc4random_uniform(), arc4random_buf().
  - cbsmith 11y ago
    arc4random_uniform() is the only one that really addresses the matters in this proposal, and arc4random_uniform() can't handle values larger than 2^32-1 (and, in fact, thanks to the wonders of overflow, might do some unfortunate things in a variety of cases), and won't produce values greater than 2^32-2. So yeah, not exactly addressing the matter. Of course, that whole arc4* library doesn't have the same challenges as a language standard, which is where a lot of the challenge here comes from.
    - JoachimSchipper 11y ago
      You're not wrong, but let me be more explicit: the problems arc4random_*() solves are the ones I feel are important: good-quality random with no corner cases (e.g. still reliable if you run out of file descriptors, at least on OpenBSD). pick() or shuffle() really are nice, but I'm much more scared of predictable-by-default or predictable-in-corner-cases RNGs than of errors in a hand-rolled pick(). (I don't write code where e.g. std::poisson_distribution would be useful, so I don't feel I have the background to have an opinion on that part of the proposal.) Overflow is something that the programmer always has to keep in mind, unfortunately.
      - cbsmith 11y ago
        Generics and boxed types make overflow a non-concern. The proposal doesn't really care much about distributions. It's intended for people who don't care about random distributions.
        JoachimSchipper 11y ago
        FWIW: generics and boxed types allow you to write code without overflow, but there's plenty of real-world C++ that's full of overflows. Good C uses a small number of types and also avoids overflow... Although we have different concerns, it's clear that a lot of thought has been put into the proposal, and it seems to achieve its/your goals pretty well. Don't let my concerns put you off.
vitalyd 11y ago
I think this is a natural consequence of low-level APIs. Anything deemed worthy of being configured by caller is made into an extensible interface, whether that be through flag arguments or types. Unless some lib is very opinionated on how things should be done, the extension/customization hooks have to exist in one form or another. To satisfy the two camps though (low level control vs "give me some sane default or package up common combinations") someone just writes the higher level API on top.
- cbsmith 11y ago
  It is entirely possible to write a highly configurable interface with sane defaults. Indeed, the proposal in this article goes a long way in that direction.
  - vitalyd 11y ago
    Sometimes the right defaults depend on context unavailable to the low level library author. But irrespective of who provides the higher level API, the bottom line is that there needs to be an API that's most flexible when the flexibility is warranted. This is really in reference to Colin's "nothing more to add" remark.
    - cbsmith 11y ago
      If there is some other context that is unavailable to low the level author, then that default should be provided by whatever higher level is providing said context. C++'s namespaces provide a super convenient mechanism to make that work smoothly.
ubernostrum 11y ago
C with "nothing left to take away" would be assembly. Why don't you switch from C to assembly? Or figure out what you get when there's nothing left to take away from assembly? Or maybe your idea of "just the right amount of stuff" is different from someone else's idea of that, and we could be thankful that the world is able to accommodate more than one opinion on this by providing us with multiple programming languages we can use according to our needs and preferences.
- cperciva 11y ago
  C with "nothing left to take away" would be assembly. C with nothing left to take away is portable assembly.

Features like this make me think that C++ is designed by people who think that perfection is reached when there is nothing more to add. As a C developer, I side with Antoine de Saint Exupéry.

cbsmith 11y ago

Sigh... Too often that criticism is leveled at C++ without an understanding of the terrain. I don't think C developers should be sitting on a high horse on this one. C represents a pretty good example of the problem. Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution, so any correct program completely bypasses that infrastructure and/or has a ton of additional code/complexity layered on top of it. That open source basically festered until the C++11 <random> proposal was accepted. The chief proponents of that proposal were, of course, those with the most sophisticated needs & understanding for random functions, and the proposal reflects that. So, the problems with that proposal are arguably a consequence of the flaws in the original C standard. What remains to be done is to harmonize that proposal with something that makes sense to less sophisticated users, who nonetheless have reached the point where their appreciate the problems with C's random functions.

cperciva 11y ago
Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution Right, and that function is a mistake in the C standard. It should have been omitted entirely.
- cbsmith 11y ago
  That would have messed with C++'s goal of providing compatibility for C code. Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.
  - cperciva 11y ago
    You misunderstand me. I think random(3) should have been omitted from the C standard.
    - pcwalton 11y ago
      What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. See, for example, crypto before NaCl came around. (NB: I'm not defending either this C++ standard or random(3).)
      - cperciva 11y ago
        What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. Sure... but what happens if you do specify that implementations should be built-in is that a diverse, bewildering ecosystem of broken implementations get built in, and so people who know what they're doing end up eschewing the built-in implementations in favour of shipping with an implementation which they know works. And ultimately you have a standard function which everybody provides for compatibility purposes, but which nobody should ever use. See, for example, random(3). Functionality should be added to standards when we can be confident that every implementation in the next 100 years will get it right, and no sooner.
      - marssaxman 11y ago
        I thought NaCl was something related to browser plugins. What is the connection with crypto?
        ori_b 11y ago
        Name collisions: http://nacl.cr.yp.to/ http://nacl.cr.yp.to/ Although, I've never actually seen it used in the wild.
cbsmith 11y ago
> That open source Man, autocorrect killed me there. That should be "That open sore".
JoachimSchipper 11y ago
random(3) is clearly bad; but contrast this proposal with the simplicity (and security) of OpenBSD's arc4random(), arc4random_uniform(), arc4random_buf().
- cbsmith 11y ago
  arc4random_uniform() is the only one that really addresses the matters in this proposal, and arc4random_uniform() can't handle values larger than 2^32-1 (and, in fact, thanks to the wonders of overflow, might do some unfortunate things in a variety of cases), and won't produce values greater than 2^32-2. So yeah, not exactly addressing the matter. Of course, that whole arc4* library doesn't have the same challenges as a language standard, which is where a lot of the challenge here comes from.
  - JoachimSchipper 11y ago
    You're not wrong, but let me be more explicit: the problems arc4random_*() solves are the ones I feel are important: good-quality random with no corner cases (e.g. still reliable if you run out of file descriptors, at least on OpenBSD). pick() or shuffle() really are nice, but I'm much more scared of predictable-by-default or predictable-in-corner-cases RNGs than of errors in a hand-rolled pick(). (I don't write code where e.g. std::poisson_distribution would be useful, so I don't feel I have the background to have an opinion on that part of the proposal.) Overflow is something that the programmer always has to keep in mind, unfortunately.
    - cbsmith 11y ago
      Generics and boxed types make overflow a non-concern. The proposal doesn't really care much about distributions. It's intended for people who don't care about random distributions.
      - JoachimSchipper 11y ago
        FWIW: generics and boxed types allow you to write code without overflow, but there's plenty of real-world C++ that's full of overflows. Good C uses a small number of types and also avoids overflow... Although we have different concerns, it's clear that a lot of thought has been put into the proposal, and it seems to achieve its/your goals pretty well. Don't let my concerns put you off.

vitalyd 11y ago

I think this is a natural consequence of low-level APIs. Anything deemed worthy of being configured by caller is made into an extensible interface, whether that be through flag arguments or types. Unless some lib is very opinionated on how things should be done, the extension/customization hooks have to exist in one form or another. To satisfy the two camps though (low level control vs "give me some sane default or package up common combinations") someone just writes the higher level API on top.

cbsmith 11y ago
It is entirely possible to write a highly configurable interface with sane defaults. Indeed, the proposal in this article goes a long way in that direction.
- vitalyd 11y ago
  Sometimes the right defaults depend on context unavailable to the low level library author. But irrespective of who provides the higher level API, the bottom line is that there needs to be an API that's most flexible when the flexibility is warranted. This is really in reference to Colin's "nothing more to add" remark.
  - cbsmith 11y ago
    If there is some other context that is unavailable to low the level author, then that default should be provided by whatever higher level is providing said context. C++'s namespaces provide a super convenient mechanism to make that work smoothly.

ubernostrum 11y ago

C with "nothing left to take away" would be assembly. Why don't you switch from C to assembly? Or figure out what you get when there's nothing left to take away from assembly? Or maybe your idea of "just the right amount of stuff" is different from someone else's idea of that, and we could be thankful that the world is able to accommodate more than one opinion on this by providing us with multiple programming languages we can use according to our needs and preferences.

cperciva 11y ago
C with "nothing left to take away" would be assembly. C with nothing left to take away is portable assembly.