Or to clarify that: you would like me to change the entire philosophy of my tutorial, only to cover the C++language better, which is not a focus of the tutorial. I think you are unrealistic.
Or to clarify that: you would like me to change the entire philosophy of my tutorial, only to cover the C++language better, which is not a focus of the tutorial. I think you are unrealistic.
Do first 20 programs a beginner makes need to adhere to all the best practices?
Edit: Of course it is correct C++. All the prorgams will compile and run according to standard C++.
No, I don't expect you to change your tutorial to focus simply on C++. I expect you to use best C++ practices where you cover the C++ bits. That's all.
As much as possible, yes. They are BEGINNERS. They don't know better. You certainly don't want to send someone out there who writes bad C++ code. People pick up whatever they see on the net, you know. So do it right from the beginning. Use the best practices where appropriate.
So, please, will you be so kind to highlight the piece of code from my tutorial that you deem not to be good enough for a beginner.
Ok, that covers many examples. But I think that using operator [] instead of .at() in tutorials and books is quite common. Perhaps you could point to me to some other reputable tutorials or books that employ the .at() operator so early and often to be in accordance with your suggestion.
Edit: If that is such an indispensable best practice, I expact that most other tutorials and books are employing it,too.
You cant find even one? So, all the other books and tutorials are wrong, and you are right?
What can this strange device be?
When I touch it, it gives forth a sound
It's got wires that vibrate and give music
What can this thing be that I found?
Well, that's being kind of literal about it.
is a useful tool because it gives you a specific out of bounds exception (std::vector::at - cppreference.com)Code:std::vector::at()
I would suggest coding in some way like this :
I think at() is slightly slower than just using [] but the safety and error response is worth it in applications you're prototyping or debugging.Code:#define debug std::vector<int> x(1024, -1); #ifdef debug // code using at() method #else // code using [] instead #endif
Ok, Elysia and others, let me say this:
Sometimes it happens that we, people, have some idea, and it is a good idea and we like it. And then we get kind of stuck into that idea, and we are unable to percieve that in some other specific situation our idea is not that good, due to various specific circumstances.
I know that using checked array access is better for beginners. But in C++, there are various circumstances that make that idea hard to employ. We have to be practical. I have made all attempts to mitigate the impact of not using a C++ standard way to do checked vector access. The readers will be instructed to use Visual Studio in Debug mode. Those using Code::Blocks with gcc will be employing _GLIBCXX_DEBUG. I think that more than does it, it is good enough, it practically as good as the real thing. Remember, this is a tutorial for beginners.
Like what? UsingI know that using checked array access is better for beginners. But in C++, there are various circumstances that make that idea hard to employ.is incredibly simple O_oCode:std::vector::at(size_type pos)
I was thinking that there are no really good C++ tutorials for total beginners, so I decided to create one.wut?Perhaps you could point to me to some other reputable tutorials or books that employ the .at() operator so early and often to be in accordance with your suggestion.
O_oLike what? Using is incredibly simple
Simple? Yes, but typing the three extra characters can cause eye strain, carpal tunnel, and athlete's foot.
Soma
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
I'm open for suggestion. Suggest me a better way for beginners to avoid silently introducing an error into their program without using at(). I'm listening.
How the heck is this more practical? You say you're trying to avoid specifically talking about C++, and then you tie yourself down to some specific IDEs and compilers and mess around with defines. Yeah, that's very C++ neutral.
So let me ask you this: are you ever going to change your mind on this? I need to know if I can start ignoring giving you advice since you don't seem to be willing to listen anyway, despite several members here telling you using at() is simpler.
There's no point talking to a wall, obviously.