1. ## Beginner!

Hello!

I'm trying to make a bulls function! On average I would like it to hit the Bull 70% of the time and the other 30% (miss) between 1 to 20. As you can see I have the basic code, but I'm just learning so don't really understand what each part does.

Code:
```int Bull()
{
int percent = rand()%100; //lower percent is more throws needed
int r = rand()%100; //lower r is less throws needed
if(r<percent)        // hit
return 50;
else            // miss
return 1 + rand()%20;
}```

2. Important notes on rand():
rand( value % 100 ) is in the range 0 to 99
rand( value % 100 + 1 ) is in the range 1 to 100
rand( value % 30 + 1985 ) is in the range 1985 to 2014

Everything else in the code seems self explanatory, tell me if it isn't.

First you need to seed your rand in order to get different results each time you start the program. If you don't everytime you start the program it will be the same result, as illustrated in this example:
Code:
```#include <iostream>
#include <cstdlib>

using namespace std;

int main()
{
int range_hit = 17;
int r = rand()%20;
cout << "Random number is " << r << endl;

if(r<=range_hit)
{
cout << "The bull was hit!";
}

else
{
cout << "Aww you missed";
}

return 0;
}```
Here is the seeded code, this chnages the rand to coresond to miliseconds on your computerclock:
Code:
```#include <iostream>
#include <cstdlib>
#include <time.h>

using namespace std;

void seedrnd(void);

int main()
{
seedrnd();

int range_hit = 16;
int r = rand()%20;
cout << "Random number is " << r << endl;

if(r<=range_hit)
{
cout << "The bull was hit!";
}

else
{
cout << "Aww you missed";
}

return 0;
}

void seedrnd(void)
{
srand((unsigned)time(NULL));
}```
I'm not very good so there might be a mistake...

3. Originally Posted by JonathanS
rand( value % 100 ) is in the range 0 to 99
rand( value % 100 + 1 ) is in the range 1 to 100
rand( value % 30 + 1985 ) is in the range 1985 to 2014
This is either a mistake or some very misleading notation.
You mean something like:
Code:
```value = rand() % 100;
value = rand() % 100 + 1;
value = rand() % 30 + 1985;```
Originally Posted by JonathanS
correspond to miliseconds on your computer clock
time() usually returns seconds (usually since Jan 1, 1970), not milliseconds.

And in this code
Originally Posted by JonathanS
Code:
```        int range_hit = 16;
int r = rand()%20;
if(r<=range_hit)```
The if condition actually has a 17 out of 20 (85%) chance of being true.

Since Valdo wants a 70% chance of a bullseye, this would be a good way of doing it:
Code:
```if (rand() <= (RAND_MAX / 10) * 7) {
// 70% chance of executing this block
}
else {
// 30% chance of executing this block
}```

4. Originally Posted by JonathanS
I'm not very good so there might be a mistake...
srand call should be
Code:
`srand((unsigned int)time(nullptr));`
It's important to stay up-to-date.

5. Originally Posted by Elysia
srand call should be
Code:
`srand((unsigned int)time(nullptr));`
It's important to stay up-to-date.
but only if your compiler supports it. if he's using code blocks, there's a real possibility that the compiler is gcc 3.4.5, which is from 2004. gcc 4.6 (the first gcc to support nullptr) is available for mingw (I'm only guessing at the platform, because code blocks also runs on linux and mac(?)), but for a beginner, installing it may not be a trivial task.

6. We must keep pushing users to upgrade to the latest versions, otherwise we'll all be stuck using old technologies and standards all the time. Unacceptable.
A good way to find out if users are using an old version is to use new standards and features. If it doesn't work... well, upgrade.
Besides, upgrading gcc is trivial on Code::Blocks. On Windows, it's just to download latest mingw and extract over the old mingw in the Code::Blocks installation directory.
On Linux... well, you really have to know how to do stuff like this to use Linux, you know?

7. If you're so worried about using NULL then you really should start using the "correct" casting methods as well. The use of C style casts should also be avoided.

Jim

8. We must keep pushing users to upgrade to the latest versions, otherwise we'll all be stuck using old technologies and standards all the time.
O_o

I call your "Unacceptable." and raise you "exported templates".

No compiler is ever going to fully support C++11 for the same reason that no compiler ever fully supported C++98. (The closest two still had several small issues.) That doesn't mean we will be "stuck using old technologies"; in time, as more compilers move to support C++11 features, we'll have a firm understanding of which bits are problematic and which bits are widely available. That's the real world real programmers have to deal with.

Suggesting that people always use `nullptr' without a C++11 "disclaimer" is unacceptable. I have no problem with `nullptr'. (Part of the functionality can be emulated and wrapped behind a macro.) However, a lot of C++11 simply isn't going to be widely available for a bit. (I don't know of a press release of anything, but I've heard that Microsoft has no intentions of ever supporting variadic templates.) Telling people to always write new code without a "disclaimer" is putting them into a position where they might have to rewrite code because the vendor of the compiler they use has no intention of providing a given feature.

I know you are probably going to say something about obtaining a compiler from a different vendor or a new version of a compiler from the same vendor. That's not really practical; some platforms are tightly bound to a given compiler. Even if that is practical for all other reasons, the code becomes artificially limited to smaller subset of compilers.

Look at it by example: you have a post with an example where someone created an empty destructor for a class because they needed that destructor to be virtual. (That's pretty standard practice in C++98.) I jump in and say "use `default' functions". That sounds like great advice... until you actually try it because it only works in three compilers. (Well, you could say four but two are based on "EDG".) I'd be sending people down a painful path for almost no reason.

Seriously, what would people do with "You shouldn't write a named function for use by constructor, that's what delegates are for."? "GCC" and "Clang" are awesome, but even they don't cover every target.

I'm not saying that you shouldn't recommend new C++11 features. (I'm not even saying that you should prefer older methods.) I am saying that you need to weigh your suggestion against the fact that widely available support for most of C++11 is still a few years down the road and note the features newness in any event.

I mean, I could write you a compile-time tuple managed by a "DSEL" by walking syntax trees without resorting to macro hacks that would make your head swim. (I'm not joking; it would confuse the crap out of you.) Unfortunately, no one compiler completely supports all the C++11 features I would need. I only expect "Clang", "EDG", and "GCC" to ever get there.

Heck, look at all the great stuff you can do with a simple `constexpr' that used to be the domain of ridiculously complex and ugly meta-programming. It is a great feature. (It is actually a better feature than a lot of the features that exist to soften the burden.) You still will not catch me recommending it unless the target is mostly, or exclusively, "GCC" supported.

Soma

9. Originally Posted by phantomotap
Suggesting that people always use `nullptr' without a C++11 "disclaimer" is unacceptable.
Abso-f'ing-lutely!

10. I get your point, but nullptr is supported by the two (probably) most popular compilers. I find that reason enough to recommend it. If you get something for free when upgrading, then why not?
If people can't use something because they are stuck with a compiler that does not support it, then that's fine. But it should not stop us from recommending features that are widely supported based on the chance that someone just might not be able to use it. Better to recommend it and backtrack if it turns out it can't be done.

Also, most people who ask for help here aren't professionals. Most. They are hobbyists or students, and to them, suggesting it doesn't seem so bad. Many of them aren't stuck with esoteric compilers (I'm looking at you, Turbo C(++)!). And those who are, are typically stuck because of a dumb school and can begin properly coding once they get out of the dumb class they're in.

Like I said, pushing the standard, I feel is more important than worrying about issues you bring up.
Also pushing other people to recommend new features, or make them understand they exist, is also important.
We want to move on. We don't want to be stuck in the past.

11. Originally Posted by Elysia
On Linux... well, you really have to know how to do stuff like this to use Linux, you know?
No you don't.
The latest compiler is usually in the repo within a few weeks of release, and c::b is automatically configured to use it as the environment variables remain same.

12. Then there's even less to worry about. I was thinking you'd have to update manually, and by that, downloading and updating from some software system.

13. Originally Posted by Elysia
Then there's even less to worry about. I was thinking you'd have to update manually, and by that, downloading and updating from some software system.
Partly true for non-rolling systems though.
It just is a matter of adding a ppa url (for Debian derivatives) and clicking on update.

14. Better to recommend it and backtrack if it turns out it can't be done.
You can't make that decision.

That's not "should", that's "can't".

That's a judgement call you literally can not make.

I can't make it either. The only person that can know if potentially needing to rewrite code justifies using a new language feature is the programmer. Simply noting that the feature is new puts that decision where it belongs.