[OT] Quick intro to C++ for a Python and C user?

[Grant Edwards]

Would anybody care to recommend online C++ resources for a long time C
and Python user? (I'm also familiar with Smalltalk, Scheme, FORTRAN,
bash, Javascript, and a variety of assembly languages.)

I have a C++ library to which I need to add a couple minor
wrappers/extensions. I've already done the same for the C version of
the library. Writing test suites for C libraries using Python/ctypes
is pretty cool.

After googling a bit, I found several recommendations for the book
"Thinking in C++" by Bruce Eckel. I've skimmed through it, and it's
_way_ too long-winded. It takes him 200+ pages before he gets to data
encapsulation and 600+ pages before he introduces inheritence. The
writing is also a bit too condesending for my taste:

You literally take the form of the existing class and add code to
it, without modifying the existing class. This magical act is
called _inheritance_, and most of the work is done by the compiler.

Magical act?

Seriously?

 

[Neil Cerutti]

Would anybody care to recommend online C++ resources for a long
time C and Python user? (I'm also familiar with Smalltalk,
Scheme, FORTRAN, bash, Javascript, and a variety of assembly
languages.)

The best book I know of to get you writing useful C++ quickly is
Accelerated C++ by Koenig/Moo. It's not free online, though. It
starts with an excellent introduction to using the STL and works
it's way slowly down the abstraction ladder to using pointers and
inheritance last of all.

Iterators turn out to be an excellent starting point for learning
pointers, though since you already know C that won't do you as
much good.

 

[Paul Rubin]

Would anybody care to recommend online C++ resources for a long time C
and Python user? (I'm also familiar with Smalltalk, Scheme, FORTRAN,
bash, Javascript, and a variety of assembly languages.)

Stroustrup's web site has lots of good stuff on it. I also like his C++
book "The C++ Programming Language" in preference to the many me-too
books that are out there. He also has another C++ book that I haven't
looked at but which sounded interesting. C++ is quite a bit different
from those other languages you mention in that contemporary C++ style
revolves a lot more around a reasonably serious static type system with
typed generics. By comparison, C and Fortran have minimal static type
systems and Smalltalk, Python, etc. have none at all.

 

[Grant Edwards]

The best book I know of to get you writing useful C++ quickly is
Accelerated C++ by Koenig/Moo. It's not free online, though. It
starts with an excellent introduction to using the STL and works
it's way slowly down the abstraction ladder to using pointers and
inheritance last of all.

Oops. I should have mentioned this is for embedded systems programming
so templates in general (and STL in particular) are probably off the
table.

 

[Grant Edwards]

Would anybody care to recommend online C++ resources for a long time C
and Python user? (I'm also familiar with Smalltalk, Scheme, FORTRAN,
bash, Javascript, and a variety of assembly languages.)

I have a C++ library to which I need to add a couple minor
wrappers/extensions. I've already done the same for the C version of
the library. Writing test suites for C libraries using Python/ctypes
is pretty cool.

I stumbled across an undergrad CSci lesson that showed in a couple
pages how to subclass something and add a couple methods. All I
needed to do was add four methods containing two lines of code each.

Unfortunately, I had to muck about with the original library's code to
change a couple things from "private" to "protected" to allow me to
extend the class to do what needed to be done. Every time I have to
do anything with C++ (once every handfull of years) it feels like
swimming against the current...

It probably would have been simpler to just add the code to the
original library's implementation, but that would have introduced a
"backwards" dependency in the system's libraries.

 

[Paul Rubin]

Oops. I should have mentioned this is for embedded systems programming
so templates in general (and STL in particular) are probably off the
table.

Templates are how C++ does generics and I'd expect them to appear in be
used in embedded programming as well as elsewhere. They can bloat up
the code if you're not careful (if function f has several parameters,
you can end up with a separate, specialized copy of f for every
combination of types that f is called with in the program), but in the
typical monomorphic situation they don't add any overhead. I'm not sure
about the situation with STL. Anyway, templates aren't terribly hard to
understand.

 

[Paul Rubin]

Unfortunately, I had to muck about with the original library's code to
change a couple things from "private" to "protected" to allow me to
extend the class to do what needed to be done. Every time I have to
do anything with C++ (once every handfull of years) it feels like
swimming against the current...

I think this is what's called "the expression problem" and it's a
perennial sore point in statically typed PL design. Different languages
have different approaches to dealing with it. I'm no C++ expert so I
don't know what the gurus would say for your particular situation. But,
I do get the impression that PL mavens now tend to think that OO and
inheritance was a 1990's thing that didn't work out as well as expected,
that Java is a painful wreck because of it, and that C++ culture has
moved somewhat away from OO in favor of template-based generics.

 

[Neil Cerutti]

Templates are how C++ does generics and I'd expect them to
appear in be used in embedded programming as well as elsewhere.
They can bloat up the code if you're not careful (if function f
has several parameters, you can end up with a separate,
specialized copy of f for every combination of types that f is
called with in the program), but in the typical monomorphic
situation they don't add any overhead. I'm not sure about the
situation with STL. Anyway, templates aren't terribly hard to
understand.

Moreover, if you don't plan to take advantage of templates or
inheritance, then you could as well write C++ compatible C and be
pretty happy with the results.

 

[Roy Smith]

Moreover, if you don't plan to take advantage of templates or
inheritance, then you could as well write C++ compatible C and be
pretty happy with the results.

Well, C++ still gives you constructors, destructors, and the ability to
write class-specific operators.

But, you'd be missing one of C++'s biggest selling points; safe
containers. Even if you never explore anything in STL beyond std:string
and std:vector, you will have saved yourself a world of buffer overflow
pain.

 

[Grant Edwards]

I've only worked on the perphery of a couple embedded projects that
used C++, but it seems to be farily common practice to prohibit the
use of templates in embedded code. The problem seems to be that
people writing C++ code don't really understand the language, how
templates work, or (in general) the implications of the code they
write. So, you have to prohibit anything that can be easily misused
or cause non-obvious problems.

For exaple (quoting from http://en.wikipedia.org/wiki/Embedded_C++):

Embedded C++ is a proper subset of C++. The following language
features have been removed:

Multiple inheritance
Virtual base classes
Run-time type information (typeid)
New style casts (static_cast, dynamic_cast, reinterpret_cast and const_cast)
The mutable type qualifier
Namespaces
Exceptions
Templates

Some people go further and prohibit any run-time object creation.

Bingo. In my experience, many (if not most) C++ programmers don't
understand enough of the language to realize what "being careful"
means.

Moreover, if you don't plan to take advantage of templates or
inheritance, then you could as well write C++ compatible C and be
pretty happy with the results.

Well, there are other C++ features that C doesn't have (e.g.
exceptions -- but they're often prohibitted in embedded programming as
well).

Personally, I think C++ is an awful language in general and a _really_
awful language for embedded systems work.

 

[Neil Cerutti]

I've only worked on the perphery of a couple embedded projects that
used C++, but it seems to be farily common practice to prohibit the
use of templates in embedded code. The problem seems to be that
people writing C++ code don't really understand the language, how
templates work, or (in general) the implications of the code they
write. So, you have to prohibit anything that can be easily misused
or cause non-obvious problems.

I cheerfully agree that programmers ignorant of C++ should not
write programs in it. But furthermore, they should also not
define a subset of C++ for use in embedded programming.

 

[Grant Edwards]

I cheerfully agree that programmers ignorant of C++ should not
write programs in it. But furthermore, they should also not
define a subset of C++ for use in embedded programming.

I fully agree that programmers ignorant of C++ should not write
programs in it. However C++ is a vast, complex, and dangerous
language -- and industry doesn't seem to be willing to limit itself to
using the seven people on the planet who understand it.

I'm only half joking...

It seems to me that you need to know far more about C++ to use it
safely than you need to know about most other languages to use them
safely.

 

[Ethan Furman]

I fully agree that programmers ignorant of C++ should not write
programs in it. However C++ is a vast, complex, and dangerous
language -- and industry doesn't seem to be willing to limit itself to
using the seven people on the planet who understand it.

I'm only half joking...

Ah -- so there's actually 14?



~Ethan~

 

[Roy Smith]

C++ is a vast, complex, and dangerous language -- and industry
doesn't seem to be willing to limit itself to using the seven people
on the planet who understand it.

I'm only half joking...

Half joking, indeed. I happen to know for a fact that there are
*fourteen* people on the planet who understand it.

 

[Neil Cerutti]

Half joking, indeed. I happen to know for a fact that there
are *fourteen* people on the planet who understand it.

One of its greatest contributions to computer science were
Glassbarrow's C++ puzzles. They likely couldn't have been as
challenging in any other language.