[pandaman]

>Of course it would, that was one of the design goals of C++. >C90 is mostly a C++98 subset, except for stronger type conversion rules (no implicit void* conversions), precedence order for operator ?: and typedef/struct namespaces.

I think either I don't understand something you are trying to say or you are confused. C being a subset of C++ (one of design goals) does not imply C++ is a subset of C. C++ code in general cannot be compiled with C compiler without rewriting.

>Yes, but COM is also callable from C by design. Also I have seen many codebases that have restricted C++ code to calling DX APIs, with everything else being compilable by a C compiler as well.

You have blah->Foo(bar); in C++. In C it won't compile by any design. That code has to be rewritten as blah->vtbl->Foo(blah,bar). It is not C code as you claimed. It won't compile with C compiler. It's C++.

>> Could you explain exactly how this works? ... >1 - Rename .c translation units to .cpp, .cxx, .C

I asked how type checking disappears in this process, not how you compile C with C++....

>PGO data generated by the JIT compiler gets updated after each application execution and is used as input for optimization selection just like in an AOT compiler by a multi-stage compiler.

How can a JIT compiler obtain the PGO data in the first place? Is it running under profiler all the time? You realize that you've just refuted your claim about performance not being affected, right?

[pjmlp]

You are the one not understanding what it means to pick C code and compile it with a C++ compiler, minus the semantic differences.

Should I enumerate all of them to make you happy?

> You have blah->Foo(bar); in C++. In C it won't compile by any design. That code has to be rewritten as blah->vtbl->Foo(blah,bar). It is not C code as you claimed. It won't compile with C compiler. It's C++.

Nothing prevents you to write COM calls in C++ code just like in C, blah->vtbl->Foo(blah,bar). The code won't stop compiling.

> I asked how type checking disappears in this process, not how you compile C with C++....

The whole point was about writing C like code with a C++ compiler.

> How can a JIT compiler obtain the PGO data in the first place? Is it running under profiler all the time? You realize that you've just refuted your claim about performance not being affected, right?

By using a multi-stage JIT compiler with different levels of optimization and making use of multi-cores.

99% of the applications are never able to saturate all cores to the point it matters to the overall performance.

I have always been on the Pascal and C++ side against C since the early 90's on BBS and USENET.

So this type of disbelief against better tooling is not strange to me.

Cry Engine, Unreal (C++ with GC), Unity, MonoGame, with their separation between lower level C++ and higher level languages, and the way those engines are being adopted by Sony, Nintendo, Microsoft, Amazon, Google speak for themselves.

Just like C and Pascal overtook Assembly, C++ overtook C, something else will overtake C++.

[pandaman]

Ok, you completely lost me on the point you are trying to make wrt "C compiled with C++" however I wholeheartedly agree with your penultimate paragraph.

Sony and Nintendo do not use these engines, MS might be making the new Gears with UE though, rest of their first party don't. Amazon and Google have one successful game between themselves (and that's a mobile game). All these engines bring to the industry are indies and mobile games. UE actually lost quite a lot of AAA they had in UE3 times. Epic's and Crytec's own games don't do quite well (Crytec is not even making payroll). So yeah, looks like C++ games do not have much to worry about.

[pjmlp]

> Ok, you completely lost me on the point you are trying to make wrt "C compiled with C++" however I wholeheartedly agree with your penultimate paragraph.

Use the platform C++ compiler, but write code only the language subset common to C, that could even be compiled by a plain C90 compiler.

The only exception being, wrapping C++ SDK APIs into C like wrappers.

A pattern I have seen too often.

Dismissing indies is the wrong attitude, they were the first ones to adopt C and Pascal, C++, Objective-C and nowadays C#, Swift, Java.

Sony does use C# a lot on their internal tools.

Nintendo uses Unity for prototyping.

Microsoft and Google are using Unity and Unreal a lot for their VR work.

All of them invited MonoGame developers and supported them porting MonoGame into their platforms (PS4, Switch, UWP Xbox).

C++ might not go away, people still write games in C and Assembly, but it will become that very thin bottom layer at the engine architecture diagram.

Just give it time, eventually even all major C compilers became written in C++.

[pandaman]

>A pattern I have seen too often.

And I have not seen ever. I have seen some C games (like Quake) but never worked on one. And I've been working in games since 90s.

>Sony does use C# a lot on their internal tools.

And now we are in the theretory of "console games are written on PC!!!1! So there!". Sony also uses Perl and Python on their servers and their movie studios use a lazy evaluated shader language. Does it mean games are switching to any of these soon to you?

>Nintendo uses Unity for prototyping.

And probably play Pokemon Go, also written in Unity! I see the pattern now... it's all clear.

>Microsoft and Google are using Unity and Unreal a lot for their VR work.

Listen. Unity has it's uses. If anything it keeps indies off the streets and provides artists with a way to earn a quick buck. I am not against Unity. It's just silly to imagine it has any chance competing with the traditional game industry tools. Saying so and so uses unity for something, which is not a game does not make the point I imagined you arguing here. Which is C# displacing C++ in games. Elon Musk likely uses Unity so there. Can't beat the old Musk.

But it still does not matter anything at all for the people who had been writing games in C++.