Re: "Linus Torvalds Was (Sorta) Wrong About C++"
On 3/12/2015 8:20 PM, JiiPee wrote:
On 12/03/2015 19:34, Christopher Pisz wrote:
On 3/12/2015 1:39 PM, Richard wrote:
[Please do not mail me a copy of your followup]
Johannes Bauer <dfnsonfsduifb@gmx.de> spake the secret code
<mdq0hn$3fd$1@news.albasani.net> thusly:
All Linus is saying is that he WON'T. Judging from the amount of
extrodinarily shitty C++ code I have seen in my life, I kind of
understand why.
The vast overwhelming majority of shitty C++ code I've seen is written
by people who keep writing C code and calling it C++.
I second that emotion.
I remember me learning first C 1996 January. Then I found C++ and never
after that even considered doing a project with C (well only if no other
options, like embedded). Why use a language with less options? :) So its
kind of interesting to see some saying C is better than C++....the way
they think is so different.
because, not everyone needs so many options...
even with C, there are features that hardly anyone ever uses anymore:
trigraphs; old K&R style declarations; ...
features which are simply rarely used, such as bitfields...
features which were added later, but still rarely used:
digraphs (why were these even added?);
variable-length-arrays, _Complex and _Imaginary, ...
...
but, on the other side, there are some very frequently used features in
C which are painful in some other languages:
function pointers;
walking arrays using pointers, offsetting via arithmetic, ...;
...
where, for example, these few items make coding in many Java-like
languages considerably more painful than doing so in C.
now, for C++ vs C, main things one most often feels are lacking in C:
classes, but most use-cases can be done (slightly less prettily) with
structs (including rudimentary single-inheritance and doing things
similar to Java-style interfaces). (actually, if someone understands how
something like COM+ works, or what the C++ compilers do internally, they
are a good part of the way there...).
operator overloading, but the usual C solution is static-inlines with
reasonably terse names, ex:
static inline vec3d v3dAdd(vec3d a, vec3d b) { ... }
then, if C++ is used, the overloaded operators can be shorthands:
"c=a+b;" vs "c=v3dAdd(a, b);"
in other cases, a header can be used to optionally collapse longer
(fully qualified) names to shorter names via macros (yes, not quite
namespaces, but often "good enough").
templates, but these can often be loosely approximated via macros.
other cases, like overloaded functions, are usually handled with
type-suffixes on the function names.
likewise, references typically become explicit pointers, ...
so, in general, most of the same basic stuff can be done in either language.
though, C and C++ have differences in terms of idiom, so the way
something would be done in one language will often be "bad style" in the
other.
while a person could bemoan the lack of nice syntax for doing things, in
many of these cases it usually isn't really that huge of an issue.
in other cases, the typically more stable ABIs or further reaching
compiler support (on esoteric targets), or relative ease of plugging
custom code generators into compiled C vs compiled C++ machine code,
...., may outweigh the costs of doing things in straight C.
though, yes, C++ is also a lot nicer for doing general application
development type stuff.
and, on the extreme other end, when doing something one-off, there may
be cases where one debates whether to write some code in C... or forego
the use of an MCU entirely and just do all this crap with analog and/or
discrete logic, and whether to do things "properly" and with more
expensive parts (and/or needing parts one doesn't have on-hand), or just
being like "screw it" and generating hundreds of watts in waste heat and
needing to cool the thing via having it be submerged in water and
insulated via silicone caulk (say, because it is all analog electronics
operating the transistors in linear range, rather than digital
electronics doing stuff via PWM signals).
well, and optimally needing 10 or 12 AWG wire but being like "well, 14
will probably work"...