To add to what was alluded to by Koren, C++ has a standard library with a ton of easy to use functionality depending on what you want. Not as simple as the above method, but for more advanced programs whenever you need it.
You can put in in the dice function too...
int Roll(const int nbsides) {
static bool init=false;
if (init == false) {
srand(time(NULL));
init = true;
}
return rand() % nbsides;
}#include <random>
std::default_random_engine generator;
int roll(int sides)
{
std::uniform_int_distribution<int> distribution(1,sides);
return distribution(generator); // generates number in the range 1..6
}As far as I remember, rand() itself is not thread safe. What are you talking about, srand in a thread or rand itself?
That's actually a bit dramatic, I think, or I miss something... Obviously, you don't want to reseed often, especially with something so weak than time(NULL). Seeding twice may cause issues, should you for example require several random numbers elsewhere in the same second and calling this in the middle. I suspect it won't cause too many issues in many cases, though.
I agree, your example is what I use most of the time, but he said "easiest". It usually takes me a couple try to get the correct command when I need it (and I don't have my memorandum handy). And isn't the support still not perfect?
I'm not sure that's a good way to look at things, you'll also get a lot of junk in code if people are just copying solutions found on stackexchange and similar sources... The comment about seeding that follow actually proves it, I think.
The library can still call rand(), especially if it calls srand() before...
This is the kind of things I keeps as snippets... I often code in bullet trains, for example, and I don't want to rely on being able to reach the Internet ^_^
How is the support? I barely use anything else than g++ and cland, currently...
Fair enough...
Even then, it's still not a great idea- there's other, much better sources of randomness that can be used in C programs or kernel modules. Linux developers generally recommend using /dev/{u}random, or get_random_bytes() if you're in a module. There's generally always something that provides a better source of randomness than what rand() would provide.
I had this problem my first two and a half years of college CS courses. In some cases, I would put enough pressure on the other group members early enough that they'd drop the course (and then merge with another group who also had members drop), or in other cases just muscle through it. It's not working having to spend more hours fixing up someone else's broken code than just writing it yourself.
That must've been literal hell.
As one example, I struggled to find any information about what precompilation actually did for handlebars and nunjucks. Marko was the only templating engine for which I could find any sample output. Though, once I saw what Marko was doing, nunjucks made a lot more sense to me. I gave Handlebars one last look-over, and decided it would require more research to figure out how it worked, so I installed nunjucks.
I was looking at express-session, which is less clear about how the secret is used.
<div class="entry">
<h1>{{title}}</h1>
<div class="body">
{{body}}
</div>
</div>var context = {title: "My New Post", body: "This is my first post!"};<div class="entry">
<h1>My New Post</h1>
<div class="body">
This is my first post!
</div>
</div>int main(void) {
std::string name;
std::cout << "What is your name? "
std::cin >> name;
std::string::size_t space = name.find_first_of(' ');
std::string::size_t next = name.find_first_not_of(' ', space);
std::cout << name[0] << "." << name[next] << "." << std::endl;
}I don't really agree with that. Performance was a consideration, but ultimately I picked nunjucks because I felt I understood it better than handlebars. My impression is that it's actually a little slower.
I trust the authors of the argon2 C library. It's new, but has been carefully reviewed. Unfortunately, the author of the recommended javascript bindings for the library appears to have made a few mistakes in terminology. I believe I encountered a bug as well. Given that it handles passwords, I want to be sure those issues are not indicative of deeper problems with the integration.
I'm curious how you should handle "Theo de Raadt". T.R.?
That poor child.
I find a couple of those rules a bit strict. I'm curious to know whether people stick to it down to the letter...
alpha = 1.23
beta = 2.34
psi = 3.45
gamma = 4.56
tau = 5.67alpha = 1.23
beta = 2.34
psi = 3.45
gamma = 4.56
tau = 5.67E221 is certainly one of the more commonly overlooked errors in most PEP 8, and people usually won't care if you violate it in a case like this. It's still good to check for though, as sometimes you'll use it somewhere you didn't intend/doesn't match the case you presented. A lot of well written code will have some number of PEP 8 violations, but that number is usually very small.
I do, and it can be a nightmare, especially on papier, but most of the time, coding conventions (especially capitalization choices) aren't the worst offenders.
a, b, f, k, l, j = 0, 1, -7, len(L), [ (1,) ], "Hello World"def Search(s) :
if s[0] == '1' and s[1] == '1' :
for i in range(2, len(s)) :
if s[i] == '0' :
return '110'
if s[0] == '0' or s[1] == '0' :
for i in range(1, len(s)-1) :
if s[i] == '1' and s[i+1] == s[i] :
return '011'
return None
Wow do you grade them based on whether they work or not? That sounds really frustrating. If we hand something in, either it has automatic tests for correctness (then the grader just grades based on style/readability) or if it's on paper, we have to write a natural explanation + mathematical proof that it works.
I must at least know whether it works or not... It can be akward because they're beginners, and sometimes have really strange ideas. I sometimes type the answers to check limit cases to avoid headaches ^_^
That's exactly it: I knew the idea, but it wasn't suggested, and since they've only had 15-20h of lessons and as much practice on computers, starting from scratch, I wasn't expecting such an answer.
But in a similar assignement, we had automated test suites. Half of the tests were looking for proof of cheating, not correctness. ^_^ 3 groups out of 4 had at least parts that weren't theirs... It could be OK if they had understanded it when they added it in their project, but most of the time, they didn't :/