Ok, that's scary, I would accept C for such a job but C++ provides too many opportunities for things to go wrong in strange and difficult to find ways.
Are you kidding? Accept C but reject C++? That's completely ridiculous.
"Well, the scout leader's fire control computer should have returned fire at the MIG. It should have, but the C-programmed fire control software cast the void* target object to a ... well, a seagull_t object. I guess you could say that the scout leader was shot down when a seagull fired a radar-guided missile at him. That's pretty funny, right? Right?"
Of course maybe I'm just wrong to want type safety of any kind.
It seems like I've seen this type of C-bashing (vs. C++) recently, and I don't understand it. How is well-written modern C less type-safe than C++? I define that as something along the lines of "using the latest language specification, making judicious use of all features possible, turning on extra-strict compiler warnings and errors."
To address your specific scenario, you could just as well cast a void* to seagull_t* in C++ as you can in C, can't you? I'll admit to not being totally up-to-snuff on the different casts available in C++, but IIRC C-style casting still works.
I didn't realize that distinction, so it's good to know. Still, as I originally assumed, I confirmed that gcc with `-Wall -Werror -std=c99` flags won't compile an initialization of a "struct seagull * " with a value of type "struct enemy * ", or passing a mismatch of those types to a function. If those would be the main reasons to use C++, I'd personally rather just use C with extra checks. But to be fair, maybe that's because I'm not very comfortable with C++, to the point that I didn't notice it checks pointer types.
Yes. In C, conversion between object pointer types requires a cast, but conversion from void pointer to object pointer does not; in C++, both conversions require a cast.
Conversion from void pointer to object pointer would be very a bit annoying to warn about in general, as it's so commonly used in C. And if you always use casts, that also hide other types of error (see, e.g., http://c-faq.com/malloc/mallocnocast.html).
I'm sure there are compilers (and possibly gcc/clang can do it, too...) that will warn you about this stuff without needing you to switch to C++.
Linus Torvalds once quipped (in a discussion over Git) that "even if the choice of C over C++ had no other benefits than keeping the C++ programmers out, that in itself would be a huge reason to prefer C".
Torvalds' criticism of C++ is lazy thinking, but the schadenfreude that non-C++ developers exult in from his criticism is just plain dumb.
Go back and read Torvalds' screed (here's a link http://harmful.cat-v.org/software/c++/linus). Aside from some sloppy hand-wavy arguments about how he feels icky 'trusting' standard libraries, is he actually criticizing C++? Where in that mess of half-congealed reasoning is mention of multiple-inheritance or operator overloading, or any of the other classic C++ mis-features?
Torvalds is a systems-programmer and he detests the greedy-method design-as-we-implement approach to development that C++ application programmers wanted to bring to git. But, guess what? That pretty much describes application developers working in every development language in common use today.
You program in Java? Chances are Torvalds thinks you're a hack unworthy of working on git or linux. Ruby? Probably even worse. Javascript? Don't make me laugh. Torvalds even refers to you - yes, you - as "some CS people".
You can write the containers as a ".x" file, which is just C with all of the type names replaced by a macro name. Then you #include the .x file where needed, #define the type before, then #undef it after. Token pasting in the C preprocessor makes for unique names, so multiple container types can be used in the same namespace.
