6 ms·

Learning Standard C++ as a New Language (1999)

64 points by pcr910303 5y ago

pieterr 5y ago
[1999]
- dang 5y ago
  Added. Thanks!
- bena 5y ago
  Were people of that opinion back in the day? I started* with Pascal, but I then moved to C++ the next semester. I only learned C as essentially a subset of C++. This was like 1996/97. *Although I guess my first programming experience was with DOS/Windows Batch file scripting and some BASIC. Introduction to Programming with Pascal was the first programming language I took in as a class.
  - zwieback 5y ago
    I was, yeah, if you mean using C++ as a better C but being slow to adapt the STL, standard library and associated concepts. We were doing a lot of device driver development and other constrained stuff back then (early 90s) so the "C++ as a higher-level language" vs. "C++ as incrementally improved C" was much discussed. Also, OO vs. generic programming was a hot topic, and still is. It's always hard to extend a language culture to include libraries, as some people will prefer to adapt or roll their own. If it's not automatically part of the language the community will fracture.
deleted 5y ago
[deleted]
cptroot 5y ago
Doesn't this need a (1999) at the end? This is from before C++11.
- dang 5y ago
  Added. Thanks!
deleted 5y ago
[deleted]
hzhou321 5y ago
[Disclaimer: I only read the first part.] Let's say we include in the C standard library a routine, `const char *scan_str(int fd)`, one only need to remember to free the returned string once finished with it. Or we can even get away by using static buffers. All the safety and practical requirement are merely implementation details that "user" needn't care (unless they are the implementor). It appears to me that most of the complexity argument in the article is on the availability of library routines, plus, there is a shift of roles from implementor to user -- we all wear different hats from time to time. The article was from 1999, but similar arguments are still popular today or even more so, that using convenience of library availability as strength in language. A rich standard library plus some implicit notations to using the standard library may have its appeal to some users. For some other, who understands the possibility of million ways of implementing a function and the importance of understanding subtleties, C++ is really too complex to use.
TazeTSchnitzel 5y ago
I think using std::string and so on from the get-go may be sensible if C++ is the language being used for an introduction to programming, in order to not get mired in difficult details. The great complexity of the language stemming from its history makes it not a great language for beginners, though! On the other hand, if you are trying to teach C++ to people who already know how to program, then you want them to be able to understand existing C++ code, not just write new code. So they need to understand the complex parts of the language and why they are like that, and the easiest way to do that is to start where C++ started, i.e. with C.
- zwieback 5y ago
  Totally agree. Coming to C++ nowadays must seem a bit odd compared to other statically typed OO languages (e.g. Java, C# or similar). For oldtimers like myself that learned coding before C++ it's a natural evolution and I can accept C++'s awkwardness as the price to pay for a multi-paradigm language that can still be used as a portable assembler (with some manual labor). I remember the Dr Dobbs article from when it came out and I have to agree that I was still using all the old stdio.h, string.h, etc. functions. To this day streams, which was probably the first thing C programmers had to swallow, seem "unnatural", whatever that might be. For newcomers to C++, now as well as in 1999 when the article was written, you have to really take the time to appreciate what C++ is trying to do. I switch between C#, C++ and Python and C++ programming has a certain feel to it that I think you have to learn (or be forced to) appreciate.
  - tialaramex 5y ago
    You can see how ugly Bjarne's streams are even in this small article, ignore for a moment the strange fact that the Dobbs article uses the wrong operator on the last line. cout << "number of elements = " << buf.size() << ", median = " << median << ", mean = " >> mean >> '\n'; This is clearly improved by just having string formatting (a feature C manages to have, but here's Rust's) println!("number of elements = {}, median = {median}, mean = {mean}", buf.size()); It's OK though, twenty years later C++ managed to get as far as std::cout << std::format("number of elements = {}, median = {}, mean = {}", buf.size(), median, mean) << std::endl;
turndown 5y ago
Interesting article; C++ as “C and then some” was clearly an irresistible marketing term for many of the programmers from that time that I’m sure Bjarne indulged himself in saying once or twice too.
synergy20 5y ago
C++ still mixes with lots of C code especially in the system programming field, i.e. C++ has to use many Posix C calls, C++ does not have its own socket() API replacement for network programming, even C++ thread uses pthread underneath, etc. Unlike other languages, C++ needs quite some C code to get the whole thing working sometimes. I do agree that when you learn C++, you should not focus on its C roots.
- fluoridation 5y ago
  That's rather an inane observation. A program written in any language running on a system with a C API will eventually need to call to C through some kind of foreign function interface in order to interact with the system. C++ just has the peculiarity that its FFI is directly interoperable with C, so much so that it's legal C.
  - nu11ptr 5y ago
    This is an interesting observation, but this also means people will often be expected to call those APIs directly as not everything will warrant a C++ wrapper. In other languages, with their (typically) noisy FFIs, almost no app. programmers use them directly (or at least very sparingly), but instead use a library wrapper written by someone else in their language. I think the point of the OP is that it creates a very unique "blended" experience in C++ vs. other languages and I would agree.
    - fluoridation 5y ago
      The advantage of a wrapper, even when the underlying API call is simple, is that your program can be system-agnostic. You don't need to care at the call site whether the call eventually resolves to pthread_create() or CreateThread(). The implementation has already taken care of it.
      - kllrnohj 5y ago
        That's not nearly the advantage you think it is. For many of these APIs, it's going to be just as easy to have a portable implementation of the pthread's or socket API itself. Simply wrapping an API, but otherwise exposing it as-is (which basically everyone does for threads & sockets) does not gain you any portability whatsoever.
gattr 5y ago
Somewhat related: [1]. A bit provocative title, but it's actually about "teaching (the newcomers) C++ constructs first before going through C-era ones". [1] CppCon 2015: Kate Gregory “Stop Teaching C" (https://www.youtube.com/watch?v=YnWhqhNdYyk https://www.youtube.com/watch?v=YnWhqhNdYyk)
- tialaramex 5y ago
  Right, there have been a few other CppCon talks about this, but the thrust is the same. Kate is an excellent speaker and so hers is a good introduction to the idea if you're (somehow) still of the opinion that the first week of a C++ course ought to be C and she has great motivating examples where doing this her way works out better for everybody. If C++ is in fact this good modern programming language, your C++ programming course should teach that language. If your excuse as to why the programming your students do is lousy is "Well, they didn't learn modern C++" that's your fault, you were supposed to teach that. I actually think there are also important lessons to be learned when trying to teach any programming language as a first language, because beginners are likely to offer some illuminating questions, and that begins with the boilerplate (the Dobbs article calls it "scaffolding" but I think boilerplate is appropriate). The boilerplate in C++ is very bad. I am convinced that it would be less bad (maybe still pretty bad, but less bad than say C) if right early on somebody had sat down with students learning this as a first language and noted down all the warts they run into and set about fixing as many of those warts as possible.
pipeline_peak 5y ago
.
- deleted 5y ago
  [deleted]
not2b 5y ago
This is from 1999 and should not be recommended today, as C++11 was such a huge improvement over C++98/C++03.
- Jtsummers 5y ago
  Some of the specifics, sure, but the premise is still sound: Teach C++ as Standard C++, not C in disguise, or C(++). It would certainly have cleaned up a lot of my former colleagues' code if that had been the case for them (to their credit, many of them also inherited the C(++) code and didn't just make from-scratch C(++) code, but they also didn't take too much time to fix it).
- einpoklum 5y ago
  The specific examples in Bjarne presents aren't affected that much by C++11. But generally you're right, in that one should rely on 1999 materials for learning C++11 - nor 2011 materials for learning C++20 :-)

64 points by pcr910303 5y ago

pieterr 5y ago

[1999]

dang 5y ago
Added. Thanks!
bena 5y ago
Were people of that opinion back in the day? I started* with Pascal, but I then moved to C++ the next semester. I only learned C as essentially a subset of C++. This was like 1996/97. *Although I guess my first programming experience was with DOS/Windows Batch file scripting and some BASIC. Introduction to Programming with Pascal was the first programming language I took in as a class.
- zwieback 5y ago
  I was, yeah, if you mean using C++ as a better C but being slow to adapt the STL, standard library and associated concepts. We were doing a lot of device driver development and other constrained stuff back then (early 90s) so the "C++ as a higher-level language" vs. "C++ as incrementally improved C" was much discussed. Also, OO vs. generic programming was a hot topic, and still is. It's always hard to extend a language culture to include libraries, as some people will prefer to adapt or roll their own. If it's not automatically part of the language the community will fracture.

deleted 5y ago

[deleted]

cptroot 5y ago

Doesn't this need a (1999) at the end? This is from before C++11.

dang 5y ago
Added. Thanks!

deleted 5y ago

[deleted]

hzhou321 5y ago

[Disclaimer: I only read the first part.] Let's say we include in the C standard library a routine, `const char *scan_str(int fd)`, one only need to remember to free the returned string once finished with it. Or we can even get away by using static buffers. All the safety and practical requirement are merely implementation details that "user" needn't care (unless they are the implementor). It appears to me that most of the complexity argument in the article is on the availability of library routines, plus, there is a shift of roles from implementor to user -- we all wear different hats from time to time. The article was from 1999, but similar arguments are still popular today or even more so, that using convenience of library availability as strength in language. A rich standard library plus some implicit notations to using the standard library may have its appeal to some users. For some other, who understands the possibility of million ways of implementing a function and the importance of understanding subtleties, C++ is really too complex to use.

TazeTSchnitzel 5y ago

I think using std::string and so on from the get-go may be sensible if C++ is the language being used for an introduction to programming, in order to not get mired in difficult details. The great complexity of the language stemming from its history makes it not a great language for beginners, though! On the other hand, if you are trying to teach C++ to people who already know how to program, then you want them to be able to understand existing C++ code, not just write new code. So they need to understand the complex parts of the language and why they are like that, and the easiest way to do that is to start where C++ started, i.e. with C.

zwieback 5y ago
Totally agree. Coming to C++ nowadays must seem a bit odd compared to other statically typed OO languages (e.g. Java, C# or similar). For oldtimers like myself that learned coding before C++ it's a natural evolution and I can accept C++'s awkwardness as the price to pay for a multi-paradigm language that can still be used as a portable assembler (with some manual labor). I remember the Dr Dobbs article from when it came out and I have to agree that I was still using all the old stdio.h, string.h, etc. functions. To this day streams, which was probably the first thing C programmers had to swallow, seem "unnatural", whatever that might be. For newcomers to C++, now as well as in 1999 when the article was written, you have to really take the time to appreciate what C++ is trying to do. I switch between C#, C++ and Python and C++ programming has a certain feel to it that I think you have to learn (or be forced to) appreciate.
- tialaramex 5y ago
  You can see how ugly Bjarne's streams are even in this small article, ignore for a moment the strange fact that the Dobbs article uses the wrong operator on the last line. cout << "number of elements = " << buf.size() << ", median = " << median << ", mean = " >> mean >> '\n'; This is clearly improved by just having string formatting (a feature C manages to have, but here's Rust's) println!("number of elements = {}, median = {median}, mean = {mean}", buf.size()); It's OK though, twenty years later C++ managed to get as far as std::cout << std::format("number of elements = {}, median = {}, mean = {}", buf.size(), median, mean) << std::endl;

turndown 5y ago

Interesting article; C++ as “C and then some” was clearly an irresistible marketing term for many of the programmers from that time that I’m sure Bjarne indulged himself in saying once or twice too.

synergy20 5y ago

C++ still mixes with lots of C code especially in the system programming field, i.e. C++ has to use many Posix C calls, C++ does not have its own socket() API replacement for network programming, even C++ thread uses pthread underneath, etc. Unlike other languages, C++ needs quite some C code to get the whole thing working sometimes. I do agree that when you learn C++, you should not focus on its C roots.

fluoridation 5y ago
That's rather an inane observation. A program written in any language running on a system with a C API will eventually need to call to C through some kind of foreign function interface in order to interact with the system. C++ just has the peculiarity that its FFI is directly interoperable with C, so much so that it's legal C.
- nu11ptr 5y ago
  This is an interesting observation, but this also means people will often be expected to call those APIs directly as not everything will warrant a C++ wrapper. In other languages, with their (typically) noisy FFIs, almost no app. programmers use them directly (or at least very sparingly), but instead use a library wrapper written by someone else in their language. I think the point of the OP is that it creates a very unique "blended" experience in C++ vs. other languages and I would agree.
  - fluoridation 5y ago
    The advantage of a wrapper, even when the underlying API call is simple, is that your program can be system-agnostic. You don't need to care at the call site whether the call eventually resolves to pthread_create() or CreateThread(). The implementation has already taken care of it.
    - kllrnohj 5y ago
      That's not nearly the advantage you think it is. For many of these APIs, it's going to be just as easy to have a portable implementation of the pthread's or socket API itself. Simply wrapping an API, but otherwise exposing it as-is (which basically everyone does for threads & sockets) does not gain you any portability whatsoever.

gattr 5y ago

Somewhat related: [1]. A bit provocative title, but it's actually about "teaching (the newcomers) C++ constructs first before going through C-era ones". [1] CppCon 2015: Kate Gregory “Stop Teaching C" (https://www.youtube.com/watch?v=YnWhqhNdYyk https://www.youtube.com/watch?v=YnWhqhNdYyk)

tialaramex 5y ago
Right, there have been a few other CppCon talks about this, but the thrust is the same. Kate is an excellent speaker and so hers is a good introduction to the idea if you're (somehow) still of the opinion that the first week of a C++ course ought to be C and she has great motivating examples where doing this her way works out better for everybody. If C++ is in fact this good modern programming language, your C++ programming course should teach that language. If your excuse as to why the programming your students do is lousy is "Well, they didn't learn modern C++" that's your fault, you were supposed to teach that. I actually think there are also important lessons to be learned when trying to teach any programming language as a first language, because beginners are likely to offer some illuminating questions, and that begins with the boilerplate (the Dobbs article calls it "scaffolding" but I think boilerplate is appropriate). The boilerplate in C++ is very bad. I am convinced that it would be less bad (maybe still pretty bad, but less bad than say C) if right early on somebody had sat down with students learning this as a first language and noted down all the warts they run into and set about fixing as many of those warts as possible.

pipeline_peak 5y ago

deleted 5y ago
[deleted]

not2b 5y ago

This is from 1999 and should not be recommended today, as C++11 was such a huge improvement over C++98/C++03.

Jtsummers 5y ago
Some of the specifics, sure, but the premise is still sound: Teach C++ as Standard C++, not C in disguise, or C(++). It would certainly have cleaned up a lot of my former colleagues' code if that had been the case for them (to their credit, many of them also inherited the C(++) code and didn't just make from-scratch C(++) code, but they also didn't take too much time to fix it).
einpoklum 5y ago
The specific examples in Bjarne presents aren't affected that much by C++11. But generally you're right, in that one should rely on 1999 materials for learning C++11 - nor 2011 materials for learning C++20 :-)