
The problem with C according to a C++ developer - eatonphil
https://cor3ntin.github.io/posts/c/
======
datameta
The two languages really should be used as different tools as although there
is obviously significant use-case overlap, each excels at its own niche. C++
is quite beyond C with classes. Personally, I think C++ should continue to
evolve far away from C (though as of C++20 we now have C99's designated
initializers). C is "perfect" for what it is, dare I say it. C++ can
incorporate things we've learned from other languages like Rust's memory
safety and be better for it. Though to be fully honest I haven't totally
worked through the revised memory model of C++20 and it would be great if
someone could shed some light on that.

~~~
wahern
> though as of C++20 we now have C99's designated initializers

C++20 only supports a thin imitation of C99's designated initializers. In C99
you can a) mix definition forms (designated and non-designated), b) define
members out of order, and c) override earlier definitions. C++20 doesn't
support any of these. I've often relied on a and c in initializer macros that
provide default, non-0 values that can be overridden (using vararg parameters)
by the user, but many might see that as unclean. The lack of b, however,
significantly diminishes the value of designated initializers: by reordering
struct members you invalidate all uses of designated initializers for that
type in C++20, which means they're useless to minimize the burden of
refactoring.

Also, C++20 doesn't permit designated array initializers, which I've found
very useful for arrays that map, e.g., enums to strings.

------
Stierlitz
Why the problem with C++, it was designed by a committee.

~~~
pjmlp
Like WG14 has been doing for C since ages.

------
sassypotato
C is not a "low-level" language.

~~~
UncleMeat
Definitions shift over time. Yes, C targets an abstract machine. Yes, C
doesn’t give you direct access to hardware. But in the range of widely used
languages C is much “lower level” so it gets that name. Quibbling over the
definition doesn’t add to a conversation but just exists to make somebody look
smarter than the room.

------
GoblinSlayer
>C++ has a stronger type system, and unfortunately using C idioms punch a
giant hole in that type system, and so C compatibility has a cost in terms of
safety.

This may sound like C++ has a strong type system, but it's only a little
stronger than that of C, if at all.

~~~
hellofunk
The C++ type system is vastly stricter than C.

~~~
GoblinSlayer
Dunno, even javascript knows, where an array ends, C++ doesn't.

~~~
alok99
Of course a C-style array in C++ doesn't have a defined end. It doesn't have
an end in C either. But in C++ you don't need to be using those anyway.

Part of the issue is that, while you _can_ use the usual C idioms in C++ (e.g.
a function takes an array and its length as arguments), you don't need to,
especially if you're using C++ correctly. This is one of the points of the
article.

Like hellofunk said, this has nothing to do with the type system. But the
solution to what you're talking about is fundamental C++: use the standard
library.

~~~
nybble41
> But the solution to what you're talking about is fundamental C++: use the
> standard library.

The safety-critical real-time embedded systems where strong static typing
would be most useful often don't _have_ the standard library available. Even
in C it's not unusual to need to justify every line of code in the final
product, which precludes linking against an all-inclusive libc—at best you
might get a vetted subset. The design constraints, too, are often
incompatible: "no vararg functions" (printf), "no recursion" (qsort/bsearch),
"no dynamic memory allocation" (malloc). Where C++ is allowed it is often with
additional restrictions like "no RTTI" and "no exceptions" which would rule
out large portions of the STL, including most collection types. By the time
you take all these coding standard issues into account you generally find that
you're writing in a novel language which is just enough like C++ to cause
confusion. C++ programming for these environments is not like the C++ which is
taught in schools or practiced in other fields. There is a lot to unlearn.

------
misanthropian00
I will continue to say C/C++. To me they are not distinct enough as languages
to truly be considered fully separate and they use the same compilers. The
fact that they use the same compiler is to me a devastating argument. No other
distinct languages use the same compiler.

>A language is also its good practices, patterns, idioms

The usual argument, but I disagree. If programmers don't have freedom of
expression then fuck programming. We should all be free to write our own
programs the way we want and not have to worry about standard practices or
cultures.

~~~
jbarberu
By that reasoning you'd have to add:

\- Ada, D, Delphi, Fortran, Haskell, Julia, Objective-C, Rust, and Swift (if
you go by LLVM)

\- Objective-C, Objective-C++, Fortran, Ada, and Go (if you go by gcc)

It is true that you should have the freedom to write code in any way you want.
Thankfully employers have the freedom to reject your code if you don't follow
their practices. Just like with freedom of speech, you have a right to say
what you want without fear that the government will punish you, that doesn't
mean you're shielded from what other people think of you.

