I suppose next you'll tell me that either you don't understand it so it shouldn't be done or that because it's hard people should give up.

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

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

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

    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.

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.

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

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

My post was about while and if and you repeatingly bring up for. The for statement is another statement.

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

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

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

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

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

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

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

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

    std::optional<int> getFoo();

    if (auto val = getFoo()) {}

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

Good luck to WG14 (or maybe a faction within it?) as they seem to have decided to go make their own C++ competitor now, it's a weird time to do that, but everybody needs a hobby.

I hope you realize that this is example does not need any complex C++ features.

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.

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

"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. "

That is rather dated, they do things like explicitly cast the void* pointer returned by malloc, but point out in the appendix that ANSI C dropped the cast requirement for pointer conversions involving void, C++ does not allow implicit void conversions to this day.

The "well written" remark is relevant.

Many style guides will consider implicit void conversions not well written C.

Naturally we are now on C23, and almost every C developer considers language extensions as being C, so whatever.

So using casts that hid implicit int declarations for years is "well written"?

> Many style guides will consider implicit void conversions not well written C.

I could not find a "Many" guide, Linux Kernel and ffmpeg seem to advocate against pointless casts.

> Naturally we are now on C23,

So irrelevant to the creation time of ffmpeg and only applicable to intentionally non portable libraries.

all the time -- I call it "crowd-sourcing intelligence" :-)

> Well written C tends to be legal C++ also

and python2 can be written to be compatible with python3, but neither is a subset of the other

If you have normal, non-virtual instance methods you are better off making it a normal function with some class centric naming pattern, e.g. JSON_Parse(JSON* self, const char* json).

If you want to emulate virtual functions from C++ you are better off storing a single pointer to a statically allocated vtable of function pointers (1 instance per class), that way your instance structs are smaller at the cost of an extra indirection per virtual call. You could also go the Rust route and use a large pointer type (pointer to object + pointer to vtable) for polymorphic objects that avoids a longer dependency chain at the cost of larger object pointers.

Mass immigration and increasing wealth disparity are much more relevant.