Live data from Hacker News

The bell has tolled for rand()

cpp.indi.frih.net

41–44 of 44 posts

Re: The bell has tolled for rand()

#41
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…

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

No, it's C++11.

Re: The bell has tolled for rand()

#42
post #38

Earlier quoted context omitted.

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

Just interested: Do you use static analysis tools (like for example coverity) in the gamedev industry?

Re: The bell has tolled for rand()

#43
post #35

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

Some C++ programmers love writing cross-platform code, with platform including non-UNIX platforms here, so /dev/random just won't work. That's why you'd need an "abstract standard name".

One of the largest user audiences of C++ is game developers, and (excluding mobile) 99% of their target platforms don't have /dev/random, so it's perfectly normal to want an abstract random device.

As a side note, if you've actually read the article through you'd learn that:

1. The Boost.Random stuff entered the C++ standard back in TR1 (published in 2007), way earlier than C++17. 2. Even if your seed is perfectly random, rand() would give you crappy distribution. 3. srand()/rand() is not re-entrant, which makes it a really bad idea to use it in any codebase that has a chance to grow larger one day. 4. Even if the seed is truly random, rand would give you crappy distribution and thus it has no legitimate uses other than making a game where its easy to cheat. 5. None of the rand() alternatives is in the C standard, and most are highly platform-specific. C++, on the other hand, had very good standard random generators for the last 8 years or so, which is very nice for the language that didn't even have standard strings for 15 of its existence.

Re: The bell has tolled for rand()

#44
post #32

Earlier quoted context omitted.

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.

Why do you need to know the exact type?

Okay, YOU tell me what class functions that variable "x" has. Code isn't written just for the compiler to read.

Post reply on HN