The bell has tolled for rand() • Hacker News Board

Re: The bell has tolled for rand()

#31

Post by papaf » Thu, Feb 12, 2015, 3:06 PM UTC

forrestthewoods wrote: post #7

jlebar wrote: post #2

Not to focus on a question unrelated to this blog post's point, but * "auto main() -> int" could be just "int main()". * "auto v = vector (20);" could be just "vector v(20)". * "auto print_value = [](auto&& v)" could be (I'd argue should be) "auto print_value = [](const auto& v)". "auto" is useful, "auto" is great. But "auto" is not an end in and of itself. (Bring on the C++(11) haters, blah blah.)

I'm not convinced auto should ever be used for anything other than iterators and anonymous types. There are other instances where it's relatively fine to use. Perhaps a few where it's even slightly better to use. But in C++11 I think it's by far best to limit it to there be explicit cases I mentioned. In C++14 I'll extend support to lambdas in some cases but will need to experiment to say for sure.

Most people think that auto should not be used much, but Herb Sutter recommends that everyone should use it much more. His argument is convincing:

https://github.com/CppCon/CppCon2014/blob/master/Presentatio...

Re: The bell has tolled for rand()

#32

Post by fafner » Thu, Feb 12, 2015, 3:14 PM UTC

EliRivers wrote: post #22

fafner wrote: post #17

Earlier quoted context omitted.

Sorry, but your comment lacks substance because you don't provide any argument for the way you think. Why should it only be used for iterators and anonymous types? There is a pretty good argument for using the auto var = T{val}; style of defining variables. The {}-initialization won't narrow literals. You can find more discussion about this in GotW. Maybe you have a good reason for not liking the style and there cert…

I really, really like knowing what kind of object something is by looking at the code where it is created. I really, really like it. I find it extremely helpful. This sort of thing: auto x = function(); is so unhelpful I find it frustrating and an active impediment when I can look at an object being created and not know what kind of object it is. In some programming languages, knowing what kind of object something is…

Why do you need to know the exact type? Why does it matter so much for C++ but not for other languages? I mean there are templates in C++ and a lot of code even in C++98 was written not knowing the exact type and just assuming or expecting certain properties/methods to work.

Re: The bell has tolled for rand()

#33

Post by forrestthewoods » Thu, Feb 12, 2015, 3:33 PM UTC

fafner wrote: post #17

forrestthewoods wrote: post #7

Earlier quoted context omitted.

I'm not convinced auto should ever be used for anything other than iterators and anonymous types. There are other instances where it's relatively fine to use. Perhaps a few where it's even slightly better to use. But in C++11 I think it's by far best to limit it to there be explicit cases I mentioned. In C++14 I'll extend support to lambdas in some cases but will need to experiment to say for sure.

Sorry, but your comment lacks substance because you don't provide any argument for the way you think. Why should it only be used for iterators and anonymous types? There is a pretty good argument for using the auto var = T{val}; style of defining variables. The {}-initialization won't narrow literals. You can find more discussion about this in GotW. Maybe you have a good reason for not liking the style and there cert…

I specifically referred to C++11. And I believe your example with the T{val} is C++14 so I don't know much about it.

My experience is working on video game engines with other people. As a senior developer a large part of my job is jumping through a wide range of systems written by other people to debug problems, identify ways to increase performance, add features, etc. There's also a lot of code written by people who have moved on to other jobs.

We've had quite a bit of code that was full of autos. In my experience thus far auto has never made code more significantly readable or easier to understand than not using auto. (excluding iterators/lambdas) Not only has auto not made code easier to comprehend the use of auto has made it significantly more difficult to understand on more than a few contexts. If deducing a type as a human reader of text requires backtracing a half dozen calls of code across who knows how many lines of code, and even files, then I'm gonna be justifiably grumpy. It's a huge burden. And for what benefit? Damn near nothing in my experience so far.

Re: The bell has tolled for rand()

#34

Post by [deleted] » Thu, Feb 12, 2015, 3:36 PM UTC

DonHopkins wrote: post #23

unwind wrote: post #10

Earlier quoted context omitted.

Probably part that, part joking reference to the term as used outside computing (see http://www.urbandictionary.com/define.php?term=Mansplain ). I guess the idea is that manual pages can sometimes seem to be intentionally obscure, and kind of proud of it. I don't have an example handy, nor am I even sure I agree, but I think I got the joke, at least. :)

Yes, that was my intent: the manual entry used the term "bad spectral characteristics" condescendingly, instead of actually admitting that rand was a terrible mistake and nobody should ever use it. The effort the manual writer put into rationalizing the bug would have been better put into fixing it. I looked up "mansplaining" on the urban dictionary while writing that, and was disgusted to see that it was full of sex…

[deleted]

Re: The bell has tolled for rand()

#35

Post by arsv » Thu, Feb 12, 2015, 4:11 PM UTC

The title is grossly misleading. It should read "C++17 people choose Boost over std::rand() for their RNG needs" or something like that, a hardly surprising statement since C++17 people would choose Boost for pretty much anything else as well.

In particular, it has little to do with rand() (as in rand(3) from libc), which has its uses as well as well-known alternatives within C world.

As a side note, it's funny to see fresh new C++ code that boils down to srand(readintfrom("/dev/random")), except /dev/random is now given an "abstract standard name" random_device.

And that part about limited seeding options. Beats me Boost (the library) alone won't fit in the memory of a device with 16bit ints, so inability to seed the RNG will be among the least of their problems.

Re: The bell has tolled for rand()

#36

Post by MrDosu » Thu, Feb 12, 2015, 4:18 PM UTC

forrestthewoods wrote: post #33

fafner wrote: post #17

Earlier quoted context omitted.

Sorry, but your comment lacks substance because you don't provide any argument for the way you think. Why should it only be used for iterators and anonymous types? There is a pretty good argument for using the auto var = T{val}; style of defining variables. The {}-initialization won't narrow literals. You can find more discussion about this in GotW. Maybe you have a good reason for not liking the style and there cert…

I specifically referred to C++11. And I believe your example with the T{val} is C++14 so I don't know much about it. My experience is working on video game engines with other people. As a senior developer a large part of my job is jumping through a wide range of systems written by other people to debug problems, identify ways to increase performance, add features, etc. There's also a lot of code written by people who…

This is something an IDE does for you...

Re: The bell has tolled for rand()

#37

Post by forrestthewoods » Thu, Feb 12, 2015, 4:44 PM UTC

MrDosu wrote: post #36

forrestthewoods wrote: post #33

Earlier quoted context omitted.

I specifically referred to C++11. And I believe your example with the T{val} is C++14 so I don't know much about it. My experience is working on video game engines with other people. As a senior developer a large part of my job is jumping through a wide range of systems written by other people to debug problems, identify ways to increase performance, add features, etc. There's also a lot of code written by people who…

This is something an IDE does for you...

In theory, but not in practice. Visual Studio starts off great but it eventually chokes and dies for C++. Tools like Visual Assist can extend the lifetime but eventually it too will fail. This is true for every game and every engine I've ever worked on.

I now do 100% of code editing in Sublime Text. Other people use other text editors. I'm now of the opinion that code bases should be useable and searchable in plaintext form. It's not difficult and even with an IDE makes things better imo.

Re: The bell has tolled for rand()

#38

Post by MrDosu » Thu, Feb 12, 2015, 6:30 PM UTC

forrestthewoods wrote: post #37

MrDosu wrote: post #36

Earlier quoted context omitted.

This is something an IDE does for you...

In theory, but not in practice. Visual Studio starts off great but it eventually chokes and dies for C++. Tools like Visual Assist can extend the lifetime but eventually it too will fail. This is true for every game and every engine I've ever worked on. I now do 100% of code editing in Sublime Text. Other people use other text editors. I'm now of the opinion that code bases should be useable and searchable in plainte…

I would (almost) completely disagree with this.

C++ support in VS is horrible, that's correct, but having the ability to be supported by compiler services that can parse (invalid) code is a major milestone when it comes to handling more complex codebases.

It does not matter how smart you are, the easier it is for you to understand and reason about the code, the more will fit in your head.

Refactoring is just one of the many amazing tools that make me a much better and more productive programmer today then I was without when using vi in the 90s. Add in static analysis, intellisense etc... Every bit of complexity that tooling can hide from you is worth gold.

Reality for C++ is grim though in this regard. Let's hope we get better compiler services for it soon.

Re: The bell has tolled for rand()

#39

Post by forrestthewoods » Thu, Feb 12, 2015, 6:56 PM UTC

MrDosu wrote: post #38

forrestthewoods wrote: post #37

Earlier quoted context omitted.

In theory, but not in practice. Visual Studio starts off great but it eventually chokes and dies for C++. Tools like Visual Assist can extend the lifetime but eventually it too will fail. This is true for every game and every engine I've ever worked on. I now do 100% of code editing in Sublime Text. Other people use other text editors. I'm now of the opinion that code bases should be useable and searchable in plainte…

I would (almost) completely disagree with this. C++ support in VS is horrible, that's correct, but having the ability to be supported by compiler services that can parse (invalid) code is a major milestone when it comes to handling more complex codebases. It does not matter how smart you are, the easier it is for you to understand and reason about the code, the more will fit in your head. Refactoring is just one of t…

I agree that the easier it is to understand and reason about code the better. That's why I'm opposed to most uses of auto. It makes code harder to understand. It might not make code harder to understand if it was used with tools that doesn't exist. But those tools don't exist. I'm constantly re-evaluating my opinions and for auto I keep reaching the same conclusion. I pray that someday new tools are released that make my work life better. When they are some of my re-evaluations, related to auto or otherwise, will certainly change. But sadly that day is not today.

Re: The bell has tolled for rand()

#40

Post by recursive » Thu, Feb 12, 2015, 8:00 PM UTC

DonHopkins wrote: post #23

unwind wrote: post #10

Earlier quoted context omitted.

Probably part that, part joking reference to the term as used outside computing (see http://www.urbandictionary.com/define.php?term=Mansplain ). I guess the idea is that manual pages can sometimes seem to be intentionally obscure, and kind of proud of it. I don't have an example handy, nor am I even sure I agree, but I think I got the joke, at least. :)

Yes, that was my intent: the manual entry used the term "bad spectral characteristics" condescendingly, instead of actually admitting that rand was a terrible mistake and nobody should ever use it. The effort the manual writer put into rationalizing the bug would have been better put into fixing it. I looked up "mansplaining" on the urban dictionary while writing that, and was disgusted to see that it was full of sex…

I mean, in general, if I see the term "mansplain" on the internet with no context, I'm going to assume the usage is in line with what's described on urban dictionary. Just because that's how it's actually predominantly used. This is the first usage I've ever seen that was something else. So it's not totally unreasonable.