[shmerl]

What's the reason for ffmpeg to use C, also historic?

[defrost]

Fabrice also wrote the Tiny C compiler, so very much his language of choice ..

For those used to the language it was seen as "lighter" and easier to add OO like abstractions to your C usage than bog down in the weight and inconsistencies of (early) C++

https://bellard.org/

https://en.wikipedia.org/wiki/Fabrice_Bellard

[lelanthran]

> weight and inconsistencies of (early) C++

Since very little is ever removed from C++, all the inconsistencies in C++ are still there.

[maccard]

Every language has inconsistencies, and C is not stranger to that. Much of c++’s baggage is due to C and you carry the same weight. That’s not to say that initialization isn’t broken in C++, but just like many features in many languages (off the top of my head in C - strcpy, sprintf, ctime are like hand grenades with the pin pre pulled for you) don’t use them. There’s a subset of C++17 that to me solves so many issues with C and C++ that it just makes sense to use. An example from a codebase I spend a lot of time in is

    int val;
    bool valueSet = getFoo(&val);
    if (valueSet) {}
    printf(“%d”, val); // oops

The bug can be avoided entirely with C++

    if (int val; getFoo(&val)) // if you control getFoo this could be a reference which makes the null check in getFoo a compile time check
    {}
    printf(“%d”, val); // this doesn’t compile.

[ho_schi]

For C users. And C++ users:

In C++ we can declare variable in the while or if statement:

https://en.cppreference.com/w/cpp/language/while

https://en.cppreference.com/w/cpp/language/if

It's value is the value of the decision. This is not possible with C [1].

Since C++17 the if condition can contain an initializer: Ctrl+F if statements with initializer

https://en.cppreference.com/w/cpp/language/if

Which sounds like the same? Now you can declare a variable and it value is not directly evaluated, you also can compare it in a condition. I think both are neat features of C++, without adding complexity.

[1] Also not possible with Java.

[trelane]

Declaring a variable in a loop or if statement is supported since C99: https://en.wikipedia.org/wiki/C99

Also in Java: https://www.geeksforgeeks.org/for-loop-java-important-points...

[ho_schi]

Regarding Java:

It is possible that you confuse while- and for statements?

[maccard]

No, declaring a variable in a `for` loop is supported in C99 but you can't do if-init.

[ablob]

You could write this in C, no?

  { int val; if (getFoo(&val)) {
    ...
  }}

Both ways of expressing this are weird, but stating that this can't be achieved with C is dishonest in my opinion.

[maccard]

If I reformat this,

    {
        int val; 
        if (getFoo(&val)) {
    
        }
        printf("%d", val);
    }

The bug is still possible, as you've introduced an extra scope that doesn't exist in the C++ version.

Also, this was one example. There are plenty of other examples.

[i_am_a_peasant]

it's not that weird to explicitly limit the scope of certain variables that logically belong together.

But i agree the C++ if(init;cond) thing was new to me.

[maccard]

Like everything in C++, it has it's share of footguns

    if (Foo* f = GetPtr(); f->HasValue()) {} // wrong; f can be null

vs

    if (Foo* f = GetPtr(); f && f->HasValue()){}

Is probably the biggest pitfall. Especially if you're used to this:

    if (Foo* f = GetPtr())
    {
        f->DoTheThing(); // this is perfectly safe.
    }

[tialaramex]

Variables like "valueSet" scream out that the language lacks a Maybe type instead. One of the worst things about C++ is that it's content to basically not bother improving on the C type system.

[maccard]

C++ has optional, but I wanted to demonstrate that you could wrap a C API in a safer more ergonomic way.

If you rewrote it in a more modern way and changed the API

    std::optional<int> getFoo();

    if (auto val = getFoo()) {}

There are lots of improvements over C’s type system - std.array, span, view, hell even a _string_ class

[pjmlp]

I would vouch that C++ has plenty of improvements of C type system, even C++ARM already provided enough improvements that I never liked plain old C, other than that year spent learning C via Turbo C 2.0, before being given access to Turbo C++ 1.0 for MS-DOS in 1993.

The problem is all the folks that insist coding in C++ as if it was C, ignored all those C++ improvements over C.

[rowanG077]

C++ has a maybe type. It's called std::optional.

[uecker]

Here is my experimental maybe type for C: https://godbolt.org/z/YxnsY7Ted

[uecker]

This will be in C2Y and is already supported by GCC 15: https://godbolt.org/z/szb5bovxq

[maccard]

This is one example. Off the top of my head std.array vs "naked" C arrays, string vs const char*, and let's not forget RAII are all features that just make me never want to work with vanilla C ever again.

[uecker]

For me, std.array seem fundamentally inferior compared to C arrays. A good standard string type is indeed missing, but it is also easy to define one. RAII, I can see, but I also some advantages to have explicit resource deallocation visible in the code and it is not really bothering me too much to write this explicitly.

[layer8]

C has less moving parts — it’s more difficult to define a subset of C++ that actually works across all platforms featuring a C++ compiler, not to mention of all the binary-incompatible versions of the C++ standard library that tend to exist — and C is supported on a wider variety of platforms. If you want to maximize portability, C is the way to go, and you run into much fewer problems.

[emmelaich]

Much easier to link / load into other language binaries surely.

[adastra22]

extern “C” works just fine.

[p_l]

Only in certain limited cases, for example, can't have static class instances or anything else that could require calling before a call from "extern C" API.

Also now you have to build enough of a C API to expose the features, extra annoying when you want the API to be fast so it better not involve extra level of indirections through marshalling (hello, KDE SMOKE)

At some point you're either dealing with limited non-C++ API, or you might find yourself doing a lot of the work twice.

[josefx]

Only if your entire API doesn't contain any C++.

[pjmlp]

C is also C++, at least the C89 subset.

[procaryote]

it actually isn't

https://www.stroustrup.com/bs_faq.html#C-is-subset

[pjmlp]

Do you usually post links without reading them?

"In the strict mathematical sense, C isn't a subset of C++. There are programs that are valid C but not valid C++ and even a few ways of writing code that has a different meaning in C and C++. However, C++ supports every programming technique supported by C. Every C program can be written in essentially the same way in C++ with the same run-time and space efficiency. It is not uncommon to be able to convert tens of thousands of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985.

Well written C tends to be legal C++ also. For example, every example in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" is also a C++ program. "