Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

Where "mixing C/C++" is helpful:

- I "mix C in with my C++" projects because "sqlite3.c" and ffmpeg source code is written C. C++ was designed to interoperate with C code. C++ code can seamlessly add #include "sqlite3.h" unchanged.

- For my own code, I take advantage of "C++ being _mostly_ a superset of C" such as using old-style C printf in C++ instead of newer C++ cout.

Where the "C is a totally different language from C++" perspective is helpful:

- knowing that compilers can compile code in "C" or "C++" mode which has ramifications for name mangling which leads to "LINK unresolved symbol" errors.

- knowing that C99 C23 has many exceptions to "C++ is a superset of C" : https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B...

The modern fmt-inspired std::print and std::println etc. are much nicer, preserving all the type checking but losing terrible ideas like stored format state, and localisation by default. The biggest problem is that today C++ doesn't have a way to implement this for your own types easily, Barry illustrates a comfortable way this could work in C++ 26 via reflection which on that issue closes the gap with Rust's #[derive(Debug)].

I’m not sure about the stdlib version, but with fmtlib you can easily implement formatters for your own types. https://fmt.dev/11.0/api/#formatting-user-defined-types

This disn't stop with <iostream>, they keep doing it - the latest example I can think of is std::ranges operations being "piped" with |.

cin >> a;

Then the program goes berserk as soon as the first non-number is read out of standard input. All the other "cin >> integer" lines are immediately skipped.

Yes, I know about error checking, clearing error condition, discarding characters. But it's a whole lot of stuff you need to do after every single "cin>>" line. It makes the simplicity of cin not worth it.

   fscanf (STDIN, "%d", &a);

in both cases, you need error checking (which you "know about").

It's more code, sure, but it buys you a lot of good things. I/O is hard.

I believe Rust has adopted similar idioms. I’ve heard the overall idea referred to as Railway-oriented programming.

In C++ you could implement it with exceptions, though they bring in a bunch of their own baggage that you don’t have to deal with when using monads.

I agree. It's lunacy. just be explicit and use functions or equivalent like literally every other language.

You check error for the whole batch.

Type safe input/output stream types and memory backed streams served on a silver plate is a pretty decent improvement over C.

* Performance

* Support for localization (as the format string and positions of values to format differ between languages).

* Code reuse & dogfooding - the data structures used in iostreams are not used elsewhere, and vice-versa

* C and OS interoperability - as you can't wrap a stream around a FILE* / file descritor

* bunch of other stuff...

iostreams work, but are rather crappy.

The less C the merrier.

If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with.

    > If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with.

The only reason why iostreams are slow is because of its incompatible buffering scheme, and the fact that C and C++ need to stay in sync when linked together. And that brand of slow is still faster than other languages, except sometimes those that delegate i/o to pure C implementations.

Hindsight is 20/20, remember that. Streams are not that bad of an idea and have been working fine for decades. You haven't named a problem with it other than the fact the operators are used for other stuff in other contexts. But operator overloading is a feature of C++ so most operators, even the comma operator, can be something other than what you expect.

>The biggest problem is that today C++ doesn't have a way to implement this for your own types easily, Barry illustrates a comfortable way this could work in C++ 26 via reflection which on that issue closes the gap with Rust's #[derive(Debug)].

You can trivially implement input and output for your own types with streams.

You appear to be a Rust guy whose motive is to throw shade on C++ for things that are utterly banal and subjective issues.

     struct Foo {
       int a;
       float b;
       std::string c;
     };


     Foo foo;
     std::cout << foo;

The C library headers for libraries I write often include C11/C99 stuff that is invalid in C++.

Even when they are in C89, they are often incorrect to include without the include being in an `extern "C"`.

Many C++ coders are oblivious to those differences (myself included before I switched from 'mainly C++' to 'mainly C') because they think that the C subset of C++ is compatible with 'proper' C, but any C code that compiles both in a C++ and C compiler is actually also a (heavily outdated) subset of the C language (so for a C coder it takes extra effort to write C++ compatible C code, and it's not great because it's a throwback to the mid-90s, C++ compatible C is potentially less safe and harder to maintain).

For instance in C++ it's illegal to take the address of an 'adhoc-constructed' function argument, like:

    sum(&(bla_t){ .a = 1, .b = 2, .c = 3, .d = 4 });

Interestingly, Objective-C leaves its C subset alone, so it is always automatically compatible with the latest C features without requiring a new 'ObjC standard'.

The pre-processor original compiler, before the GCC fork, would leave everything else alone, blindly copying into the generated C file.

It takes a little bit of an effort to make a header work on C and C++. A lot less effort than making a single Python file work with Python 2 and 3.

Almost seamlessly. You have to do

  extern “C” {
    #include "sqlite3.h"
  }

It's telling that every compiler toolchain that compiles C++ also compiles C (for some definition of "C"). With compiler flags, GCC extensions, and libraries that are kinda-sorta compatible with both languages, there's no being strict about it.

_My_ code might be strict about it, but what about tinyusb? Eventually you'll have to work with a library that chokes on `--pedantic`, because much (most?) code is not written to a strict C or C++ standard, but is "C/C++" and various extensions.

Absolutely true. I generally insist on folks learning C and C++ interoperability before diving in to all the "Modern C or C++" goodness. It helps them in understanding what actually is going on "under the hood" and makes them a better programmer/debugger.

See also the book Advanced C and C++ Compiling by Milan Stevanovic.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

> it is hard to say no to you, and I’m sorry to say it. But we have to choose a focus, and our focus is to implement (the standard) and innovate (with extensions like everyone but which we also contribute for potential standardization) in C++.

I mean, yeah if it came from a two member team at a startup, sure focus on C++, understandably. But Microsoft, what happened to "Developers! Developers! Developers!"?

The change of heart was the new management, and the whole Microsoft <3 FOSS.

Indeed, and yet here we are with C23

> The change of heart was the new management, and the whole Microsoft <3 FOSS.

Yeah, agree. To me the turning point was when they created WSL.

This is how I managed to sneak C++ into an embedded C codebase. We even created some templates for data structures that supported static allocation at compile time.

Yes you can do it less cleanly with macros or inline functions. But you can't do it performantly with struct and function pointers.

But having the "class" keyword is nice. Having built in support for member functions is nice.

Sometimes a person just wants the simplicity of C++ 2003.

(In reality I was working on a project where our compiler only supported C++ 2003 and we had a UI library written in C++ 2003 and honestly pure C UI libraries kind of suck compared to just sprinkling in a bit of C++ sugar.)

    > You can do anything in C that you want to.

C++ imo doesn't offer anything compelling for the embedded usecase. Especially not considering all the footguns and politics it brings.

You can of course be strict and diligent about it but if you are you are pretty much just writing C anyway. Better to do it explicitly.

Allowing the use of the C++ standard library has been one of my biggest regrets (not that it was my decision to make, I fought it).

One of the most compelling things C++ offers to embedded use case is moving runtime initialization to compile-time initialization by liberally using constexpr functions. You literally ask the compiler to do work that would otherwise be done at runtime.

But without exceptions it is mostly syntactic sugar anyway.

If compile time initialization is the most compelling usecase I'll rest my case. Good feature, yes! Hardly worth switching language for.

There's an effort to extract the good parts and make it work for embedded use cases or even bring them into C. Khalil Estelle on WG21 has been working on an experimental, deterministic runtime for exception handling, to give one example. Constexpr is an example of the latter that's now showing up in C23.

But why would you do that if you have an instrument that lets you work at the same level as C, but with methods provided as a proper abstraction that maps exactly to what you'd have written yourself anyway?

I guess what you're really asking is what are the best or most common ways to do OO in C?

Where can I find something about objects being "think of your code as representing the state and interactions of objects" honesty totally new to me.

So no, certainly I'm not asking ways to do OO in C. But it seems to be more definitions of object orientation as I thought...

If you do that, you'll notice that, for example, encapsulation is not a part of that de facto definition, because languages like Python and (until recently) JavaScript lack it, despite being considered OO.

Indeed, the only two things that appear to be consistently present in all OO languages are: 1) some notion of object identity as distinct from object state, and 2) runtime polymorphic dispatch.

I’m scratching my head how you think this is materially different than what you described in your first para. s/state/data and s/interactions/methods.

If anything though I would say the GP is more aligned with the classic definition as it highlights the focus is more on the messages (interactions) themselves rather than the implementation.

Another big one that I always forget C still doesn't support is function overloading.

Just like one doesn't use Typescript to keep writing plain old JavaScript, then why bother.

Sooo... yeah... I should definitely change company!

My god. That's amazing.

Why is that?

If you're asking why people use pre-increment by default instead of post-increment, it's mostly historical. The early C compilers on resource-constrained platforms such as early DOS were not good at optimization; on those, pre-increment would be reliably translated to a simple ADD or INC, whereas code for post-increment might generate an extra copy even if it wasn't actually used.

For C++ this was even worse with iterators, because now it depended on the compiler's ability to inline its implementation of postfix ++, and then prove that all the copies produced by that implementation have no side effects to optimize it to the same degree as prefix ++ could. Depending on the type of the underlying value, this may not even be possible in general.

The other reason is that all other unary operators in C are prefix rather than postfix, and mixing unary prefix with unary postfix in a single expression produces code that is easy to misunderstand. E.g. *p++ is *(p++), not (*p)++, even though the latter feels more natural, reading it left-to-right as usual. OTOH *++p vs ++*p is unambiguous.

You get it!

    while(*d++ = *s++)
      ;
 

    loop:       move.b  (a0)+,d0
                move.b  d0,(a1)+
                bne     loop
 

    loop:       mov     al,[rsi]
                mov     [rdi],al
                inc     rsi     ; extra instruction!
                inc     rdi     ; extra instruction!
                cmp     al,0
                jne     loop
 

Only on very rare occasions I need post increment semantics.

And in those cases I prefer to use a temporary to make the intent more clear

If the pre- or post-increment behaviour isn't actually needed, I prefer `x += 1` though.

But I write ; i++){ and seeing it the other way round throws me off for a minute, because I think, as you put it, why would you use those very particular semantics?

But I guess this is only a semantic argument.

The difference is that i++ has to keep a copy to the original around as the return value is the pre-increment value, while with ++i that isn't needed as the resulting value is being returned.

In the for loop that shouldn't matter as a) for an integer it is essentially for free (it is just reordering when the relevant register is set) and b) that value is hopefully optimized out anyways by the compiler, however as there are cases where it matters some people prefer the ++i style, some just think it looks better.

for(auto it = begin(v); it != end(v); ++it)

I miss it when switching between C/++ and other languages.

  void remove_char(char *s, char c) {
    size_t i, j;

    for (i = j = 0; s[i] != '\0'; i++)
      if (s[i] != c)
        s[j++] = c;
    s[j] = '\0';
  }

There are also idioms for stack manipulation using them: "stack[sp++] = pushed" and "popped = stack[--sp]".

C code does a lot of incrementing and decrementing by one, and so having dedicated syntax for it is convenient.

1. prefix incr/decr precedence: "stack[--sp]"

2. postfix incr/decr precedence: "s[j++]"

3. i have no particular preference for the precedence and am just using a shorthand I inherited from my ancestors whose use cases are no longer relevant to me: "i++" in your for loop

My rank speculation is that C programmers get in a habit of #3 and then forget to consider precedence in an expression where it matters.

In any case, it would be interesting to do a scan of github to see how often prefix and suffix incr/decr had to get switched up in a bugfix patch.

    void strcpy(char *s, char *t)
    {
        while (*s++ = *t++)
            ;
    }

https://news.ycombinator.com/item?id=41647843

https://news.ycombinator.com/item?id=38938402

https://stackoverflow.com/questions/562303/the-definitive-c-...

I like "Effective C" over "Modern C" because it's more engaging ... "Modern C" is super rigorous and feels a bit like reading an annotated spec of the language, which is what an expert may need, but makes for a dull read for a casual C user like me.

--

1: https://nostarch.com/effective-c-2nd-edition

"_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now.

[1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" and "nullptr" just reeks of C++.

That said, Modern C is an incredible book, I have been using it for C99 (which I intend to continue sticking to).

_BitInt(N) isn't typically used directly but typedef'ed to the width you need, e.g.

    typedef _BitInt(2) u2;

AFAIK defer didn't actually make it into C23?

I'm also more on the conservative side when it comes to adding features to the C standard, but IMHO each of the C23 additions makes sense.

One of the few advantages of ISO standardization is you can just read the associated papers to answer questions like this: https://wg21.link/p2312

The quick bullet points:

* Surprises when invoking a type-generic macro with a NULL argument.

* Conditional expressions such as (1 ? 0 : NULL) and (1 ? 1 : NULL) have different status depending how NULL is defined

* A NULL argument that is passed to a va_arg function that expects a pointer can have severe consequences. On many architectures nowadays int and void* have different size, and so if NULL is just 0, a wrongly sized argument is passed to the function.

For starters, you have to #include a header to use it.

stddef.h on the other hand is required by most to get size_t

If I want to live on cutting edge I would rather use C++2x or Rust rather than C.

Am I missing something? What benefit this supposedly modern C offers?

For the cutting edge I would recommend Zig btw, much less language complexity than both modern C++ and Rust.

One good but less visible side effect of C23 is that it harmonizes more syntax with C++ (like ... = {} vs {0}) which makes it a bit less annoying for us C library maintainers to support the people how want to compile their C code with a C++ compiler.

The microcontroller toolchains are generally built on top of GCC, so they get the features for free. There are some proprietary C compilers that are chronically lagging behind, but they are not nearly as important as they used to be two decades ago.

also, unless you're targeting embedded or a very wide set of architectures, there's no reason why you couldn't start using C23 today

I cannot remember the last time I saw C99 used. C codebases generally use C11 or C17, and C++ code bases use C++20

Also 8 and 16 bit embedded toolchains are certainly not on C11 / C17, they can hardly afford full C89.

Why would I rather step into the world of C++ just to deal with that?

This interacts in the obvious way with refusing to correct mistakes after the fact for fear of breaking user code.

I don't believe anyone has written a paper along the lines of "let's not bother with the existing practice part anymore", it's more an emergent feature of people following local incentive structures.

A lot of stuff in the C++11 standard library was based on widespread use of Boost. Since then, I don't know. Also, were things like templates and lambdas implemented as compiler extensions before standardization? I don't know, but I doubt it. Maybe "we're a committee of people who will decide on a thing and we hope you like it" was always the norm in many ways.

https://stackoverflow.com/questions/58815959/include-binary-...

    xxd --include <file>

#embed would be much nicer

I suspect that decades of C being effectively frozen have caused the userbase to self-select to people who like C exactly the way it is (was), and don't mind supporting ancient junk compilers.

Everyone who lost patience, or wanted a 21st century language, has left for C++/Rust/Zig or something else.

So, C23? ... that's nice and all, but, let's talk about it in 20 years or so T_T

[1]: https://github.com/eyalroz/printf

D does not decay arrays, so D has array bounds checking.

Note that array overflow bugs are consistently the #1 problem with shipped C code, by a wide margin.

This isn’t strictly true, a C implementation is allowed to associate memory-range (or more generally, pointer provenance) metadata with a pointer.

The DeathStation 9000 features a conforming C implementation which is known to catch all array bounds violations. ;)

That actually really does exist already with CHERI CPUs, whose pointers are tagged with "capabilities," which catch buffer overruns at runtime.

https://tratt.net/laurie/blog/2023/two_stories_for_what_is_c...

https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/

    int main() {
        int a[3];
        return foo(a);
    }

    > gcc test.c
    > ./a.out

D: int foo(int[] a) { return a[5]; }

    int main() {
        int[3] a;
        return foo(a);
    }

    > ./cc array.d
    > ./array
    core.exception.ArrayIndexError@array.d(1): index [5] is out of bounds for array of length 3

How to fix it for C:

https://www.digitalmars.com/articles/C-biggest-mistake.html

  int foo(int (*a)[6]) { return a[5]; }
  int main() {
  int a[3];
    return foo(&a);
  }

  int foo(int n, int (*a)[n]) { return (\*a)[5]; }
  int main() {
    int a[3];
    return foo(ARRAY_SIZE(a), &a);
  }
  /app/example.c:4:38: runtime error: index 5 out of bounds for 
 type 'int[n]'

The holy grail is runtime access to the length, which means an array would have to be backed by something more elaborate.

https://godbolt.org/z/PnaWWcK9o

The what now?

I personally find that googling stuff provides not much connection to the subject of study, very impersonal and try to avoid it.

For example I did google the concept, and found this https://github.com/cousteaulecommandant/ds9k.

Which is not trivial to parse, bing posited the answer as authoritative, and if you look at the code it is really nothing, it seems to be a folklore concept, and as such, it is much more aptly transmitted by speaking to a human and getting a live version than by googling an authoratitative static answer.

In release fast mode, unsigned overflow/underflow is undefined in Zig whereas in C it wraps.

:-)

Of course C has many UBs that Zig doesn't have, so C is far less safe than Zig, especially since you can use ReleaseSafe in Zig..

>Possible undefined behavior ranges from ignoring the situation completely with unpredictable results ... or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message)

So a compiler is absolutely welcome to make undefined behavior safe. In fact every compiler I know of, such as GCC, clang, MSVC has flags to make various undefined behavior safe, such as signed integer overflow, type punning, casting function pointers to void pointers.

The Linux kernel is notorious for leveraging undefined behavior in C for which GCC guarantees specific and well defined behavior.

It looks like there is also the notion of unspecified behavior, which gives compilers a choice about the behavior and does not require compilers to document that choice or even choose consistently.

And finally there is what you bring up, which is implementation defined behavior which is defined as a subset of unspecified behavior in which compilers must document the choice.

  3.1.2.5 Types

  [...] A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type.

1) https://gcc.gnu.org/projects/cxx-status.html#:~:text=C%2B%2B...

Of course, it's still C.

> Is the usage of single linked lists still prevalent as the main container type?

As far as I can remember, the C standard library has never had any functions that used linked lists. Nor are there any container types, linked lists or otherwise, provided by C. So I'd say this is a question about how people teach and use C, not related to the language -- or language spec version -- itself.

I see comments like yours everywhere all the time and I seriously think you have a very unhealthy emotional relationship with this topic. You should not have that much hate in your heart for a programming language that has served us very well for many decades and still continues to do so. Even if C was literally all bad (which imho isn't even possible), you shouldn't be that angry at it.