C++17 upgrades you should be using in your code
Take a look at Julian’s Mastering C++ Templates learning path, for more on getting the most out of new features in both the language and the Standard Library.
https://www.oreilly.com/ideas/c++17-upgrades-you-should-be-using-in-your-code?imm_mid=0f84b7&cmp=em-prog-na-na-newsltr_20171118
https://www.oreilly.com/ideas/c++17-upgrades-you-should-be-using-in-your-code?imm_mid=0f84b7&cmp=em-prog-na-na-newsltr_20171118
closed account (E0p9LyTq)
Interesting stuff, I'm still wrapping my head around what C++11 and C++14 provide for the programmer.
If only we could get noobs to stop thinking using the C library
If only we could get noobs to stop thinking using the C library
rand()/srand() functions are the only way to go, or using using namespace std; makes things easier.
| If only we could get noobs to stop thinking using the C library rand()/srand() functions are the only way to go, or using using namespace std; makes things easier. |
I thinks these are actually the least problems.
The main problems with noobs(at least most of them) are that they don't use the forum search or Google, don't want to read books or articles, can't describe a problem, never heard about "divide and conquer", don't have problem solving skills....
I also suspect that most people don't have a passion for programing and just think about a well paid job they are after.
When I did my first programming course in Pascal 25+ years ago we had to draw a flowchart and show the teacher before we were allowed to write some code. Though I never liked drawing flowcharts it helped to understand and solve a problem.
I guess nowadays students get some task, copy some code Google found for them, paste it here or some other foum to get it fixed, submit it and probably get through their assignment.
Interesting article, I hadn't seen syntax like
before. Although I'm not sure how often I'll really use it.
I like this though, and have used it in code.
The std::variant for type-safe unions is also neat, might have potential.
Personally, I still feel apprehensive about using auto as a return type. I know it's perfectly valid now, but part me of doesn't like that it doesn't show the actual type at a global/namespace-visible level in a statically-typed language. Seems harder to document, especially if for a library, and more prone to having to take time to remember what it's returning. But I have not used any library like that, so my concern might be unwarranted.
Maybe I should force myself to use some of the new features, and then see in a month or two how it feels to go through the new code.
auto [name, age] = get();before. Although I'm not sure how often I'll really use it.
Person2 p2{"mike", 50, {"Newcastle", "UK"}};I like this though, and have used it in code.
The std::variant for type-safe unions is also neat, might have potential.
Personally, I still feel apprehensive about using auto as a return type. I know it's perfectly valid now, but part me of doesn't like that it doesn't show the actual type at a global/namespace-visible level in a statically-typed language. Seems harder to document, especially if for a library, and more prone to having to take time to remember what it's returning. But I have not used any library like that, so my concern might be unwarranted.
Maybe I should force myself to use some of the new features, and then see in a month or two how it feels to go through the new code.
Last edited on
If only we could get noobs to stop thinking using the C library rand()/srand() functions |
What's wrong with
rand()?And please don't answer: "because there are better functions/classes". I'm aware of that.
But if you just need a couple of arbitrary numbers
rand() is perfectly fine.For example, why would I need a highly secure PRNG to make a unit test for a number formatting function?
like:
for(int i=0; i<100; ++i) test_number_formatter(rand());Everything more complex is overkill.
K.I.S.S. !!!!!
closed account (E0p9LyTq)
| What's wrong with rand()? |
The C standard recommends not using it. See the C11 standard, note 295.
http://cpp.indi.frih.net/blog/2014/12/the-bell-has-tolled-for-rand/
The C++ Tutorial[1] on this website is C++98. Mentioning the range-based for loop isn't enough to update it to C++11. If new C++ programmers are to become proficient with the new features of the language, then those have to be showcased to them.
This showcase must include library features such as regex and random. Well they could just look at the Reference and figure it out, yes? Yes, no, maybe but why learn about std::array if the tutorial teaches C-style arrays? Or about std::unique_ptr if the tutorial teaches new[] and delete[]?
Thus I would suggest that there be separate tutorials written for C++98, C++11, C++14 and C++17 (the newest standard being the default opened). The reason is that if standards are not tutorialized individually the reader may become confused as to which features and available/added/deprecated in which standard.
For example C++17 adds an init statement to switch and if. A single C++ tutorial would have to disclaim that this isn't available in C++14 and earlier. If the reader is stuck with a C++11 compiler he wasted time reading about this new feature. If the reader has a C++17 compiler he wasted time reading that the feature isn't available in older standards.
Who's in charge of the Tutorial anyway?
[1] http://www.cplusplus.com/doc/tutorial/
This showcase must include library features such as regex and random. Well they could just look at the Reference and figure it out, yes? Yes, no, maybe but why learn about std::array if the tutorial teaches C-style arrays? Or about std::unique_ptr if the tutorial teaches new[] and delete[]?
Thus I would suggest that there be separate tutorials written for C++98, C++11, C++14 and C++17 (the newest standard being the default opened). The reason is that if standards are not tutorialized individually the reader may become confused as to which features and available/added/deprecated in which standard.
For example C++17 adds an init statement to switch and if. A single C++ tutorial would have to disclaim that this isn't available in C++14 and earlier. If the reader is stuck with a C++11 compiler he wasted time reading about this new feature. If the reader has a C++17 compiler he wasted time reading that the feature isn't available in older standards.
Who's in charge of the Tutorial anyway?
[1] http://www.cplusplus.com/doc/tutorial/
The C++ community would greatly benefit from a tutorial with widespread expert approval. But who has the inclination, expertise, and time to create such a thing?
I'm not even certain it is reasonable to distill the required information into a tutorial, and not a thousand-page textbook.
I'm not even certain it is reasonable to distill the required information into a tutorial, and not a thousand-page textbook.
Eh. rand()'s alright. As long as you don't use it for Monte Carlo methods, cryptography, or online gambling, you'll be alright.
The small range ([0; RAND_MAX]) is easy enough to mitigate by calling rand() repeatedly. Bias isn't a serious problem for most applications if you extend rand()'s output to 32 bits, and anyway is unrelated to the generator itself; you can get bias from modulo with even a TRNG.
Meanwhile, <random> is obnoxious to use. It would be alright if there was a simple generator class that by default handled seeding without my intervention, and that let me get random bits in various forms (e.g. std::uint32_t, double, writing to a buffer, etc.). This is what System.Random from CLR does and it makes easy for normal use. It's fine to have more elaborate interfaces for when you need more control, but getting random numbers is such a common task that I'm shocked there isn't a simple interface for when you just need some randomness without any special considerations. No wonder people keep using rand().
The small range ([0; RAND_MAX]) is easy enough to mitigate by calling rand() repeatedly. Bias isn't a serious problem for most applications if you extend rand()'s output to 32 bits, and anyway is unrelated to the generator itself; you can get bias from modulo with even a TRNG.
Meanwhile, <random> is obnoxious to use. It would be alright if there was a simple generator class that by default handled seeding without my intervention, and that let me get random bits in various forms (e.g. std::uint32_t, double, writing to a buffer, etc.). This is what System.Random from CLR does and it makes easy for normal use. It's fine to have more elaborate interfaces for when you need more control, but getting random numbers is such a common task that I'm shocked there isn't a simple interface for when you just need some randomness without any special considerations. No wonder people keep using rand().
| Meanwhile, <random> is obnoxious to use. |
std::random_device actually has a very user friendly interface, ignoring its problems (such as the entropy method), you can use it as a TRNG out of the box, as long as you don't have a shit compiler that doesn't implement it right. I wonder why other random utilities/engines/generators aren't that straightforward to use.
Last edited on
Isn't std::random_device capable of blocking the thread until the system has gathered enough entropy? That's not really great if you just need to generate some random numbers.
Entropy wouldn't be a problem for a PRNG. I was just talking about how easy to use is
For example:
std::random_device and how convenient would it be to have a similar generator for a PRNG.For example:
|
|
Last edited on
Ah, I misunderstood. I thought you were proposing using std::random_device as a general purpose generator.
Like I said before, I think they should have just copied System.Random's interface.
Like I said before, I think they should have just copied System.Random's interface.
|
|
Last edited on
Topic archived. No new replies allowed.