Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently redesigning a college level first semester graduate course on Intro to Programming, in C++. Note the comma; the course is introduction to programming, and C++ just happens to be the vessel used to teach it. Note that I don't have any decision power at the moment over the language selection, so arguments about whether or not C++ is a good introductory language are moot.

Over the past 3 years, I've taught this class as a intro to C++ course, which is how the course was taught previously. However, I have come to realize that teaching things like pointers, C-style strings and arrays, and etc. early in the course does a disservice to the students, who will very likely go on to program in other languages.

This semester, I am leading with references, smart pointers, C++ strings, and vectors, and only covering raw pointers, C strings, and C arrays towards the end of the course as "advanced C++." The goal is to teach programming concepts first, not the intricacies of C/C++.

However, I'm hung up on casting. Based on my previous statement, it would seem logical to dump C-style casts until the end of the semester (if at all, since Stroustrap has indicated they're to be avoided) and to introduce static_cast up front, dynamic_cast when we get to polymorphism, and reinterpret_cast when we're dealing with raw pointers. However, given that most C-derived languages such as C# and Java perform casting using syntax similar to C-style casts, am I preparing students to be confused when they try to work in another language? (Although, the C# as operator does do approximately the same thing as a C++ dynamic_cast.)

share|improve this question

closed as primarily opinion-based by gnat, GlenH7, James McLeod, ChrisF Jan 6 '14 at 21:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

If you are teaching C++ teach C++. Limit the syntax to C++ syntax. The fact C++ supports C-style syntax is something you should mention. C++ code written using C syntax is not C code. It took me many years to realize what my professors in college fail to tell me. I for a long time thought a C++ compiler would compile C code, that isn't that case, most C++ compilers will simply accept the majority of the C language syntax. Based on a comment, you indicate you are dealing with graduate students, so they also should be aware of this fact unless they were told differently. –  Ramhound Dec 30 '13 at 16:06
I would not consider C strings and C-style casts as “advanced C++.” Understanding them is necessary to read a lot of code, yes, but the section title might make people think that it's actually better to use them. (Which may be the case, but only in rare situations.) Could you call that section “historical baggage”? –  Christopher Creutzig Dec 30 '13 at 16:41
@ChristopherCreutzig I absolutely love the idea of a "historical baggage" section; I might toss one onto each section that I teach that comes with a bunch of old stuff. –  David Pfeffer Dec 30 '13 at 21:20
While I think it's sensible of you to focus more on programming in general rather than some specific language, and also that you need to use some actual code (language, platform) to exemplify your teachings, you should really point out the specifics of the example language you're using as compared to other similar (but not identical) languages that exist out there. Think only of the "Java has no pointers" fallacy and how the notions of "pointers" and "references" mean slightly different things in c/c++ and Java. Maybe you can showcase such differences using multiple languages? –  Shivan Dragon Dec 31 '13 at 10:37
@ChristopherCreutzig: Except that "historical baggage" is very inaccurate. I'd opt for "Under the hood" or "What happens inside". Virtually all of the behavior of the abstraction is obvious if you understand the implementation. –  Ben Voigt Mar 9 at 23:54

5 Answers 5

You might consider explaining static, dynamic and reinterpret casts and then having a brief digression on regular C-style casts.

Since regular casts are equal to trying out a range of sequences of C++ casts (more powerful but potentially unsafe), it seems logical to introduce the bricks that make up the whole before explaining it.

Not strictly C++ related but nonetheless useful: give the kids the tools and advice them not to use the hammer on their fingers.

Just my opinion though.

share|improve this answer
+1 These are graduate students, not undergrads. More should be expected of them. –  DFord Dec 30 '13 at 13:48
@DFord In my experience, introductory students in programming are more skilled at the undergraduate level, where this is a first-semester college course, than at the graduate level, where this is a remedial course for CS students who have no prior CS experience. –  David Pfeffer Dec 30 '13 at 14:00

What you teach at this level should depend on what's expected of the graduate student in the next few courses. Thus, you'll likely find your answer by examining the courses that come next in the curriculum.

I would suggest viewing the course material from a language neutral standpoint (i.e. pretend you're teaching the course with Pascal, or pseudo-code) and examine whether you're teaching the student programming fundamentals or idioms of the language at hand at each step of the way -- you want to focus on the language-independent concepts and theories foremost, using the language as a way to provide and demonstrate concrete examples of the topic at hand. So, to answer your question from this perspective, do you need to use raw pointers to teach the concept at hand? If yes, then use them, if not, then don't bother.

If a student doesn't come out of the introductory course understanding basics such as declaring variables, assignment, iteration, flow control, function calls, Boolean evaluations, and basic programming structuring coupled with rudimentary debugging skills, then they will come out of the course behind the eight ball and even more so as a graduate student since he likely won't get the same level of practice as the undergraduates.

If you're getting into memory management, heaps and stacks and how data is stored and retrieved at the system level (are you covering what makes an Integer vs. Float vs. String at the compiler level?), then you'll have to teach pointers and the language constructs that lets a student navigate these waters successfully. But even here, the distinction is you're introducing the concepts of data types first, then providing concrete means of accessing the data with the language's constructs.

Short answer: Build the whole curriculum first in pseudo-code. Then pick the best, clearest construct of the language to support and reinforce the teaching of the concepts. The student will naturally learn and augment their skills with the more advanced language constructs as they encounter the need to use them, and more easily so if they fully grasped the core principles taught.

share|improve this answer
I would agree. Teach the concepts. C and C++ will change over the years. What was a good way 10 years ago to handle pointers is a horrible day today because of of say safe pointers that exist witin the recent revisions of C++. So teach the concepts of how pointers in theory, programming languages and the synax will change, but what makes a pointer a pointer won't change ( at least not until the modern CPU is retired ). –  Ramhound Dec 30 '13 at 16:10

Over the past 3 years, I've taught this class as a intro to C++ course, which is how the course was taught previously. However, I have come to realize that teaching things like pointers, C-style strings and arrays, and etc. early in the course does a disservice to the students, who will very likely go on to program in other languages.

I though that since the publishing of accelerated C++ in 2000, it was well known that an intro to C++ course hadn't to teach pointer arithmetic, C-style strings, arrays and cast, or at least that teaching those things could be pushed to a "advanced things used more often than they should due to historical and compatibility considerations" lesson at the end of the course (as I wrote in a comment, IMHO, the issue with teaching C++ even just as a support language in an introduction to programming is not to find a reasonable subset to use, it is to prepare your students to the variety of code they will meet in the wild)

However, given that most C-derived languages such as C# and Java perform casting using syntax similar to C-style casts, am I preparing students to be confused when they try to work in another language?

Considering that the C-style cast does different things in different languages, I'd tend to think that your students would be more confused by having a single syntax doing different things than the same thing having to be done by a different syntax in different languages.

share|improve this answer

I would advise to first teach ctor-style casts: NewType(oldValue). It generalizes to more than one argument, and the idea isn't entirely foreign to other languages. In C++, these casts are fairly safe. The main exception is slicing, which you probably should explain anyway.

share|improve this answer
I would not call it fairly save, it is equivalent to a C style cast (but unusable with types which don't have a simple type specifier). –  AProgrammer Dec 30 '13 at 15:49
@AProgrammer: The most dangerous casts involve pointer or reference types, which generally are not simple type specifiers (short of a typedef, and I believe you should never typedef a pointer anyway.) –  MSalters Dec 30 '13 at 15:54
I've upvoted you as it is also what I'd do, but with the caveat that I would not state that it is save, I've seen too many people typedefing pointers (and I've even seen cases in C where I agree it was reasonable). The major issue with teaching C++ (even if incidentally while pursuing a more general purpose) is not teaching a reasonable save subset, it is to prepare your students to the variety of existing code they will meet (from other reasonable subsets to absolutely non reasonable idioms going through things which where state of the art when it was designed, 20 years ago). –  AProgrammer Dec 30 '13 at 16:06
@AProgrammer: The context here is rather specific: teaching C++ is not the goal. Hence, being able to read 20 year old code is not relevant. We can safely assume C++11. –  MSalters Dec 30 '13 at 16:25

In my opinion, dynamic_cast and static_cast fall under the "intricacies of C++" category, not C-style typecasting. Just think about trying to explain why you would want multiple ways to typecast when most languages only have one. reinterpret_cast and const_cast should almost never be used, so I wouldn't even bother doing more than making the students aware of them.

On the other hand, the blessing and curse of C++ as a teaching language is that almost everything requires more programmer control and discretion than in other languages, which makes it relatively easy to migrate to other languages. I've never heard of anyone saying something like, "C++ has six different syntaxes for casting, but this language only has one. I'm so confused."

At worst, teaching them C++-style casting is doing them the disservice now of teaching them methods they will never use in other languages. However, overcomplication can also make the daunting task of learning programming seem overwhelming. My wife dropped out of an "Intro to Programming, Java" course even though she was doing quite well, because all the OOP syntax was forced on her but not explained. She erroneously thought she must be doing poorly or else she would understand what a class was and what every part of public static void main meant. Teaching more casting methods than necessary would take the same risk with your students.

share|improve this answer
I assume that dynamic_cast and static_cast are only valid casting when used by a C++ compiler? If so I would agree with most of your answer. I wouldn't agree learning how C++ style casting works in C++ would be a disservice provided the student understands the casting is only valid compiled by X C++ compiler. –  Ramhound Dec 30 '13 at 19:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.