[the_hoffa]

I'm not sure if you mean to have a /s in there, but personally I never really liked reflection.

C# had it but it was also in part because it interop'd with .NET which had C++.NET, VB.NET, F#.NET, VBScript.NET, ASP.NET, Core.NET, Web.NET, Net.NET and so much more .. reflection was an "easy" way to have other dev's interact with each others code as a type of "contract".

I really like C# and what it can do, but having to check if a particular method exists within an external dependency is in part what lead to "dll-hell" .. it's the antithesis to an API and a "software contract" .. honestly it feels like C++26's "reflection" is more an answer to the ABI issue that has plagued C++ since its inception.

If C++ really wants to help "game-engines" or make actual strides, then it should add basic GUI support to the language itself. That'd kill off 90% of the other framework/libraries out there.

As with other parts of the language, you don't -have- to use it .. and since it's trying to be the next Java in it's eternal update path, why not add GUI support at a language level ??? Hell the std::thread just calls pthread_create or CreateThread under the hood anyways, just with a 15+ high stack frame .. why not add GUI!?

[spacechild1]

> If C++ really wants to help "game-engines" or make actual strides, then it should add basic GUI support to the language itself.

This feels like a total non-sequitur. What does GUI have to do with component and property systems?

> why not add GUI!?

Because that is 100% out of scope for the C++ standard library. Also, I don't even want to imagine what a GUI library designed by committee would look like...

[the_hoffa]

Agree it's a non-sequitur; as is any idea of "game-engine" code in C++ (as the post I replied to mentioned), hence the argument.

And 100% out of scope of C++, like the std::thread?? I've worked on many an embedded system that has no concept of threads, yet the C++ committee decided to add the std::thread as a part of the STL in C++11 instead of agree on a standard ABI. So why not GUI's, or sockets, or any other more "common" modern idiom?

If you don't want to imagine what a GUI library designed by committee would look like, I'd argue what a language like C++ looks like designed by committee (6 versions in 10 years).

[kllrnohj]

> If C++ really wants to help "game-engines" or make actual strides, then it should add basic GUI support to the language itself. That'd kill off 90% of the other framework/libraries out there.

Find me a single language that has an included GUI that anyone uses. I'll wait.

Even VB.NET, for which building GUIs was its entire reason to exist at all, has multiple GUIs officially, they couldn't even stick to one.

This is absolutely a terrible idea for a language, any language, to engage with at a language / standard library level.

[pjmlp]

Smalltalk-80 when it was at Xerox PARC, Objective-C at NeXT, VB (native version, not .NET), Hypercard.