About teaching/learning C++
Do you think it makes sense for newbies to learn old idioms (e.g. manual memory management, functors, for with iterators) before learning the new ones, or is it just a waste of time?
(For the purposes of this discussion, let's ignore the fact that there's still code out there written in those idioms.)
(For the purposes of this discussion, let's ignore the fact that there's still code out there written in those idioms.)
closed account (E8A4Nwbp)
I would say an argument for this being nugatory is the very first sentence of your post,
"old". a good portion of those are becoming obsolete.
apart from that, I personally would argue for.
[] It isn't arduous
[] They still provide an insight on what one may come across when learning c++, as their name and definition of course inexplicitly imply other things.
[] May make communication regarding a c++ matter easier
EDIT: Speaking of idioms, I really "made my bed and am laying in it" with this forum. Due to my past here, this post will be reported, and disregarded.
| learn old idioms |
apart from that, I personally would argue for.
[] It isn't arduous
[] They still provide an insight on what one may come across when learning c++, as their name and definition of course inexplicitly imply other things.
[] May make communication regarding a c++ matter easier
EDIT: Speaking of idioms, I really "made my bed and am laying in it" with this forum. Due to my past here, this post will be reported, and disregarded.
Last edited on
Learning old idioms is worse than a waste of time for a beginner.
C++11 and C++17 changed the language significantly so learning the newer features as early as possible is very much needed. Teaching later older ways.
The following is just a personal observation/rant so can be ignored if desired:
TL;DR. +--------------------------------------------------------------------------+
C++ has a whole slew of containers, why teach C arrays before someone learns about a vector or a C++ string?
Why continue to teach using the C library to generate random when C++ has quite a suite of templated classes and functions for that purpose?
I'd have to opine one of the reasons why modern C++ (C++11 and later) is ignored is:
Changing the curriculum is time consuming. The old idioms still work, so why change what isn't broken could be the reason.
"This is how I learned, so should everyone else."
I am a self-taught programming hobbyist. Still learning since C++ keeps evolving.
One of the ways I learn is by writing code and written lessons as if I were writing a "Talk to me like I'm a 3 year old!" curriculum. I've been doing this since before 2004. Even going so far as to create a "learn programming" website using FrontPage 2000.
Admittedly much of the verbiage and code is from "learn to program" books I have purchased over the years. Most of the non-digital books were written and published before C++11 was finalized, so older paradigms and idioms are rampant.
As part of my learning experience I "adapt" pre-C++11 code to C++11 standards. Most of the time sloppily.
For example, in a for loop written to walk through a vector, coded to not use iterators, I'd rewrite it for iterator use. If the loop used iterators by writing out the entire verbiage to designate the iterator I'd "streamline" it with
So "my teaching method" uses the old idioms first method.
After reading posts from others suggesting learning simple C++ constructs like
When there are C++ constructs I use them. <random> and <chrono> libraries to generate random numbers instead of srand/rand.
I see better ways to write code here by "the experts" and I use that code in other source I write.
This is really a rant:
A newbie posts code, asking for help. For instance a problem using arrays or C-strings.
It bothers me no end when they flat-out reject suggestions to use C++ containers or std::string because "I haven't learned that yet."
Some even get hostile and nasty at people helping for not following instructions only the OP knows.
C++11 and C++17 changed the language significantly so learning the newer features as early as possible is very much needed. Teaching later older ways.
The following is just a personal observation/rant so can be ignored if desired:
TL;DR. +--------------------------------------------------------------------------+
C++ has a whole slew of containers, why teach C arrays before someone learns about a vector or a C++ string?
Why continue to teach using the C library to generate random when C++ has quite a suite of templated classes and functions for that purpose?
I'd have to opine one of the reasons why modern C++ (C++11 and later) is ignored is:
Changing the curriculum is time consuming. The old idioms still work, so why change what isn't broken could be the reason.
"This is how I learned, so should everyone else."
I am a self-taught programming hobbyist. Still learning since C++ keeps evolving.
One of the ways I learn is by writing code and written lessons as if I were writing a "Talk to me like I'm a 3 year old!" curriculum. I've been doing this since before 2004. Even going so far as to create a "learn programming" website using FrontPage 2000.
Admittedly much of the verbiage and code is from "learn to program" books I have purchased over the years. Most of the non-digital books were written and published before C++11 was finalized, so older paradigms and idioms are rampant.
As part of my learning experience I "adapt" pre-C++11 code to C++11 standards. Most of the time sloppily.
For example, in a for loop written to walk through a vector, coded to not use iterators, I'd rewrite it for iterator use. If the loop used iterators by writing out the entire verbiage to designate the iterator I'd "streamline" it with
auto.So "my teaching method" uses the old idioms first method.
After reading posts from others suggesting learning simple C++ constructs like
std::string and std::vector, as well as now reading several digital books on C++11/C++14/C++17 I am in the process of revising my "lessons." To a more "learn modern C++" as much as possible first. std::vector and std::string before standard arrays and C-strings.When there are C++ constructs I use them. <random> and <chrono> libraries to generate random numbers instead of srand/rand.
I see better ways to write code here by "the experts" and I use that code in other source I write.
This is really a rant:
A newbie posts code, asking for help. For instance a problem using arrays or C-strings.
It bothers me no end when they flat-out reject suggestions to use C++ containers or std::string because "I haven't learned that yet."
Some even get hostile and nasty at people helping for not following instructions only the OP knows.
Last edited on
This post: http://www.cplusplus.com/forum/general/265422/ is a good example of why teaching old idioms is hurting newbies.
I'd bet the OP hasn't been taught anything about std::string or std::set.
Learning the logic of removing duplicates/manipulating container contents could be done easily with a std::vector full of C++ strings.
I'd bet the OP hasn't been taught anything about std::string or std::set.
Learning the logic of removing duplicates/manipulating container contents could be done easily with a std::vector full of C++ strings.
I am torn on this.
the pros of learning old stuff are low, but they are good reasons:
1) the ability to read, understand, modify, maintain, etc old code, of which there are reams online and at many companies.
2) understanding how things are done. Pointers and memory management are useful things to understand: how can a new guy understand what is really happening when a vector resizes itself and kills performance if they have never understood the underlying concepts? A programmer who can't write their own simple vector-like class can't fully understand the gotchas of getting it to perform well or why it suddenly isn't doing what is needed.
3) Filling in the gaps: how can a programmer without the background implement a tree or graph? They can get a 3rd party library of course, but who writes those? Someone has to do it. What if they have to suddenly change to a language that needs the STL to be hand-rolled, like C or whatever?
I know I cheated in mentioning existing code, but without that mention, its not a fair question IMHO.
the cons are obvious too... you won't be actually DOING this stuff by hand and there are a LOT of other important things to be learning, making these things lower in priority maybe?
To me its like saying elementary school math is a waste of time. Without it, you can fake understanding the higher level stuff by doing a process you have been shown, but you don't really understand it deep inside. Maybe that is enough to get the job done. Maybe, it could also cause you to miss mars entirely with your spacecraft.
That said, I think many schools spend way, way too much time on c-strings, pointers, and arrays and other stuff from the C++ 1990 days. A little background in these things to someone who has had a couple of classes in coding already is all that is needed. A week, or 2 weeks on a 2/day a week class, could cover all the old school stuff that matters well enough to get the concepts across and have the students do enough exercises to see what they need to see.
the pros of learning old stuff are low, but they are good reasons:
1) the ability to read, understand, modify, maintain, etc old code, of which there are reams online and at many companies.
2) understanding how things are done. Pointers and memory management are useful things to understand: how can a new guy understand what is really happening when a vector resizes itself and kills performance if they have never understood the underlying concepts? A programmer who can't write their own simple vector-like class can't fully understand the gotchas of getting it to perform well or why it suddenly isn't doing what is needed.
3) Filling in the gaps: how can a programmer without the background implement a tree or graph? They can get a 3rd party library of course, but who writes those? Someone has to do it. What if they have to suddenly change to a language that needs the STL to be hand-rolled, like C or whatever?
I know I cheated in mentioning existing code, but without that mention, its not a fair question IMHO.
the cons are obvious too... you won't be actually DOING this stuff by hand and there are a LOT of other important things to be learning, making these things lower in priority maybe?
To me its like saying elementary school math is a waste of time. Without it, you can fake understanding the higher level stuff by doing a process you have been shown, but you don't really understand it deep inside. Maybe that is enough to get the job done. Maybe, it could also cause you to miss mars entirely with your spacecraft.
That said, I think many schools spend way, way too much time on c-strings, pointers, and arrays and other stuff from the C++ 1990 days. A little background in these things to someone who has had a couple of classes in coding already is all that is needed. A week, or 2 weeks on a 2/day a week class, could cover all the old school stuff that matters well enough to get the concepts across and have the students do enough exercises to see what they need to see.
Last edited on
closed account (E8A4Nwbp)
| To me its like saying elementary school math is a waste of time. Without it, you can fake understanding the higher level stuff by doing a process you have been shown, but you don't really understand it deep inside. Maybe that is enough to get the job done. Maybe, it could also cause you to miss mars entirely with your spacecraft. |
std::vector isn't much use with MPI. If you want to use high-performance computing then you haven't much choice but to use manual memory management - and learn to use it well.
For beginners though, it is good to show how convenient many features of c++ are.
Depends if you are teaching "programming" or "c++", and also if you are teaching engineers (who want to solve a numerical problem) or computer scientists (who want to create very robust software).
For beginners though, it is good to show how convenient many features of c++ are.
Depends if you are teaching "programming" or "c++", and also if you are teaching engineers (who want to solve a numerical problem) or computer scientists (who want to create very robust software).
So at times you support regurgitation?
absolutely. You don't have to understand the string class's memory management to write hello world. You don't even have to understand it by the end of your first class in programming.
I can even give a real world example. My current task at work is to do a ~10 step process over and over. Its not even code, its setup of infrastructure connectivity. I came in late and was told what to do. I spent a week knocking out my group of setups without a clue what I was really doing. Then I went back over it once I had them all done to figure out the big picture. It wasn't important to understand it up front, it was important to get the stuff working asap.
absolutely. You don't have to understand the string class's memory management to write hello world. You don't even have to understand it by the end of your first class in programming.
I can even give a real world example. My current task at work is to do a ~10 step process over and over. Its not even code, its setup of infrastructure connectivity. I came in late and was told what to do. I spent a week knocking out my group of setups without a clue what I was really doing. Then I went back over it once I had them all done to figure out the big picture. It wasn't important to understand it up front, it was important to get the stuff working asap.
Last edited on
| std::vector isn't much use with MPI. |
Of course that brings up the difference(s) between teaching C++ for beginners and learning what the language can do for experts.
The difference(s) between introductory classes, vs. intermediate or advanced.
| newbies to learn old idioms |
set the criteria. IMO.
closed account (E8A4Nwbp)
| [quote]You don't have to understand the string class's memory management to write hello world |
#include when you write that
| Why continue to teach using the C library to generate random when C++ has quite a suite of templated classes and functions for that purpose? |
One compelling argument in favor of teaching old idioms that comes to mind is that understanding how a feature is implemented may be helpful to understand when to use it or when not to use it, or why a feature is the way it is and what problem it's meant to solve.
For example, to someone who's never written a function-local functor, a lambda may seem like it's doing magic, rather than just performing some syntactic sugar.
| One compelling argument in favor of teaching old idioms that comes to mind is that understanding how a feature is implemented |
I agree, but not as the first thing a newbie is taught. Do they really need to know how std::string or std::vector is implemented in their first class, or the first week/month?
Does someone learning how to drive need to know all the intricate details of how the vehicle works?
Teach USAGE first, then later can under-the-cover details be filled in as needed.
How C is taught isn't how C++ should be.
| I was thinking about language features, rather than library features. |
To a newbie learning C++ from the ground up, zero prior experience, that is a distinction that has little to no relevance IMO.
Expose them to what the language standard offers, or continue teaching C++ as if it were pre-C++98.
The libraries enhanced the language immensely. Beginners don't need to know SQUAT about the language evolution. CS students with some experience, go for it.
If I were to teach a noob, it would be the basics of std::string and std::vector before arrays and C strings.
I see a lot of homework questions here are related to algorithms and C style code implementation requirements.
Obviously this is what teachers teach young programmers in schools today, even though you will rarely need these things since modern C++ already implements a lot of useful idioms and wraps "raw" C style code.
even though I dislike to learn these low level language features, it definitely good to learn and teach them because you will have easy time to read code other people wrote such as library implementations.
and most import, how can anyone say he knows the language if it does not understand legacy code or does not have practice to implement some algorithm?
I think it's all boils down to *understaing the language* not how useful that may be.
Obviously this is what teachers teach young programmers in schools today, even though you will rarely need these things since modern C++ already implements a lot of useful idioms and wraps "raw" C style code.
even though I dislike to learn these low level language features, it definitely good to learn and teach them because you will have easy time to read code other people wrote such as library implementations.
and most import, how can anyone say he knows the language if it does not understand legacy code or does not have practice to implement some algorithm?
I think it's all boils down to *understaing the language* not how useful that may be.
Teaching beginners with zero programming experience low level language features is like trying to create a 23rd century mnemonic memory circuit with stone knives and bearskins.
https://www.youtube.com/watch?v=yfJXd0rSCqo
https://www.youtube.com/watch?v=yfJXd0rSCqo
I feel that there are some stuff that's old but good to know, and some that should just be tossed in the garbage. Like qsort (C function) and c-style strings are some of those obsolete relics. However, memory management seems to be an important thing to learn because it can be useful as well as teach you about how things work under the hood.
What should be and shouldn't be taught can be broadly divided like this:
To NOT Be Taught: Things that are obsolete due to better compilers, changed hardware, and rarely used anymore - mainly due to it being a hacked together solution before a "proper" solution was implemented (like c-style strings before actual strings).
To BE Taught: Things that aren't used as frequently due to lack of a need or advancements in tech, but still continue to reflect the current hardware coded on.
This is broad and can end up categorizing a few things wrong, but in the end, anything that knowing about will make you understand better how hardware and code work and interact is good. Anything that doesn't do that and has been replaced by better and more convenient means should likely be tossed out.
I can't count how many times my current professor makes us code someone a specific way and I simply think to myself, "Why?" The assignment doesn't serve to make us better programmers or to understand the relationship between code and hardware or anything like that. Just a program that literally teaches an obsolete coding concept.
Out with the old and in with the new I suppose.
What should be and shouldn't be taught can be broadly divided like this:
To NOT Be Taught: Things that are obsolete due to better compilers, changed hardware, and rarely used anymore - mainly due to it being a hacked together solution before a "proper" solution was implemented (like c-style strings before actual strings).
To BE Taught: Things that aren't used as frequently due to lack of a need or advancements in tech, but still continue to reflect the current hardware coded on.
This is broad and can end up categorizing a few things wrong, but in the end, anything that knowing about will make you understand better how hardware and code work and interact is good. Anything that doesn't do that and has been replaced by better and more convenient means should likely be tossed out.
I can't count how many times my current professor makes us code someone a specific way and I simply think to myself, "Why?" The assignment doesn't serve to make us better programmers or to understand the relationship between code and hardware or anything like that. Just a program that literally teaches an obsolete coding concept.
Out with the old and in with the new I suppose.
I am not saying old idioms (C way of doing things when there are C++ alternatives) should not be taught. I am saying they shouldn't be taught as the first thing to newbies.
Obviously the notions of data types, variables and the basic arithmetic operators are not exclusive to C++, so those need to be taught real early.
Teach 'em the basics of, for instance, std::vector and std::string before teaching regular arrays and C strings.
Crawl, Walk, Run, Fly. Learning to decipher older code is not something a newbie should be expected to do.
That is an intermediate skill.
Later, when the C way of doing arrays, C strings, random numbers, etc. is taught, explain why C++ created alternatives. And how using those alternatives can create more robust code.
Obviously the notions of data types, variables and the basic arithmetic operators are not exclusive to C++, so those need to be taught real early.
Teach 'em the basics of, for instance, std::vector and std::string before teaching regular arrays and C strings.
Crawl, Walk, Run, Fly. Learning to decipher older code is not something a newbie should be expected to do.
That is an intermediate skill.
Later, when the C way of doing arrays, C strings, random numbers, etc. is taught, explain why C++ created alternatives. And how using those alternatives can create more robust code.
Last edited on
Like qsort (C function) and c-style strings are some of those obsolete relics.
To NOT Be Taught:
One of the tools I use at work requires c-strings. I get a c-string from it, and I give a c-string back. There isnt much point in copying it to a string for a 3 or 4 line function. Before this, I interfaced to a fair number of microdevices that also spoke C-string, and there again it was a real time processing need so a copy just to make it a string was of no value. I only copy to string if I need something I can't do efficiently in C, which is rare, but a few of the functions are a bit more complex and did need this.
The reason stuff out in the wild (devices, other software, etc) do this is because any real programming language can manage a c-string. It may be clunky in some of them, but they can all figure out how to shovel the bytes and stop at the zero. The add-ons or software that talks to the hardware etc can be in any of hundreds of languages, and most of them won't grok C++ string. They can all eat c-string. So that is what is used. That and c++ strings are more challenging to work with via process communications.
Obsolete? Garbage? Not at all. C-strings will outlive everyone here.
Not a good way to write pure c++ code in a self contained c++ only environment? Now we can talk... and that I can agree to.
Rand... now there is something that I could happily see thrown in the garbage.
Qsort as well. Those work in c++ because they are inherited from C. They don't belong.
To NOT Be Taught:
One of the tools I use at work requires c-strings. I get a c-string from it, and I give a c-string back. There isnt much point in copying it to a string for a 3 or 4 line function. Before this, I interfaced to a fair number of microdevices that also spoke C-string, and there again it was a real time processing need so a copy just to make it a string was of no value. I only copy to string if I need something I can't do efficiently in C, which is rare, but a few of the functions are a bit more complex and did need this.
The reason stuff out in the wild (devices, other software, etc) do this is because any real programming language can manage a c-string. It may be clunky in some of them, but they can all figure out how to shovel the bytes and stop at the zero. The add-ons or software that talks to the hardware etc can be in any of hundreds of languages, and most of them won't grok C++ string. They can all eat c-string. So that is what is used. That and c++ strings are more challenging to work with via process communications.
Obsolete? Garbage? Not at all. C-strings will outlive everyone here.
Not a good way to write pure c++ code in a self contained c++ only environment? Now we can talk... and that I can agree to.
Rand... now there is something that I could happily see thrown in the garbage.
Qsort as well. Those work in c++ because they are inherited from C. They don't belong.
Last edited on