7 ms·

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

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 2y ago
> 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 2y ago
  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).
  - thom 2y ago
    People are going to build plugin and component systems whether we like it or not. People have massive investments in C++ whether we like it or not. These two concerns often intersect in game engines, apologies if that felt off topic.
    - the_hoffa 2y ago
      Nah! I agree that plugin/component systems will be built out, no matter the language, more just trying to point out that C++, as-is-designed, in my opinion, seems like they're trying to go that route without actually going that route :| I'm more saying we should cut out the middle-man (as it were). The difference between C++03 and C++26 is, at a language/STL level, ultimately negligible when it comes to what I can "really do" with the language if I started in 03 .. and I don't mean that 26 doesn't "add more", but if I started with 03 and didn't have threading, file handling, delegates (std::function), sockets, graphics, and so much more, I'd likely use something that wrapped all of that (a plugin/component system) ... and switching away from that with an "antiquated" code base would be really hard at this point. Using 03 with a library and then just making it compile with C++26 doesn't really "add much", and switching away from that component system to C++26 requires design, building, testing, etc. etc. :| And even if I'm starting with C++26 now (assuming my compilers are actually compliant, stable, non-breaking, ABI resilient and/or are actually available across the various platforms I want to target), while it does give me a lot more of a feature-set, how much of that is actually viable from an efficiency (CPU/memory) perspective over just proper/decent C++03/11 (I say 11 because of the threads) ...?? I know it's also up to the individual programmer using C++ to actually "do it good", so it's more just an old-man-yelling-at-clouds rant (observation) at how C++ is evolving, lol! To be clear: not trying to be argumentative, I regularly work in C++ and enjoy it over many other languages .. just "saying" is all, hehe :)
      - thom 2y ago
        Gotcha, totally fair points. It is an inherently conservative approach to standards, to take workarounds and pragmatic solutions that are already available within the community, and provide slightly cleaner (perhaps debatable) baked-in versions. You're right it doesn't add much, but at the same time... I feel the ick factor reducing with each release and my enjoyment of the language has grown over the years. I would certainly love to see those features used in common libraries and frameworks, but for practical reasons I suspect they think the same way you do, which is entirely valid.
kllrnohj 2y ago
> 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 2y ago
  Smalltalk-80 when it was at Xerox PARC, Objective-C at NeXT, VB (native version, not .NET), Hypercard.
  - kllrnohj 2y ago
    That list would be like saying "Java on Android". A single platform's narrow usage of a language != language's standard library having it.
    - pjmlp 2y ago
      It is the standard library on the platform, of course it counts. Get Smalltalk-80 reference manual without the UI documentation of its standard library, and no, GNU Smalltalk is not a complete implementation.
      - igouy 2y ago
        "The standard does not attempt to specify areas where current implementations differ in significant ways. In particular, as the goal statement implies, we did not include graphics, user interface, or database accessing objects in the library." 1997 DRAFT ANSI Smalltalk Standard https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-ind...
        2y ago

spacechild1 2y ago

> 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 2y ago
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).
- thom 2y ago
  People are going to build plugin and component systems whether we like it or not. People have massive investments in C++ whether we like it or not. These two concerns often intersect in game engines, apologies if that felt off topic.
  - the_hoffa 2y ago
    Nah! I agree that plugin/component systems will be built out, no matter the language, more just trying to point out that C++, as-is-designed, in my opinion, seems like they're trying to go that route without actually going that route :| I'm more saying we should cut out the middle-man (as it were). The difference between C++03 and C++26 is, at a language/STL level, ultimately negligible when it comes to what I can "really do" with the language if I started in 03 .. and I don't mean that 26 doesn't "add more", but if I started with 03 and didn't have threading, file handling, delegates (std::function), sockets, graphics, and so much more, I'd likely use something that wrapped all of that (a plugin/component system) ... and switching away from that with an "antiquated" code base would be really hard at this point. Using 03 with a library and then just making it compile with C++26 doesn't really "add much", and switching away from that component system to C++26 requires design, building, testing, etc. etc. :| And even if I'm starting with C++26 now (assuming my compilers are actually compliant, stable, non-breaking, ABI resilient and/or are actually available across the various platforms I want to target), while it does give me a lot more of a feature-set, how much of that is actually viable from an efficiency (CPU/memory) perspective over just proper/decent C++03/11 (I say 11 because of the threads) ...?? I know it's also up to the individual programmer using C++ to actually "do it good", so it's more just an old-man-yelling-at-clouds rant (observation) at how C++ is evolving, lol! To be clear: not trying to be argumentative, I regularly work in C++ and enjoy it over many other languages .. just "saying" is all, hehe :)
    - thom 2y ago
      Gotcha, totally fair points. It is an inherently conservative approach to standards, to take workarounds and pragmatic solutions that are already available within the community, and provide slightly cleaner (perhaps debatable) baked-in versions. You're right it doesn't add much, but at the same time... I feel the ick factor reducing with each release and my enjoyment of the language has grown over the years. I would certainly love to see those features used in common libraries and frameworks, but for practical reasons I suspect they think the same way you do, which is entirely valid.

kllrnohj 2y ago

> 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 2y ago
Smalltalk-80 when it was at Xerox PARC, Objective-C at NeXT, VB (native version, not .NET), Hypercard.
- kllrnohj 2y ago
  That list would be like saying "Java on Android". A single platform's narrow usage of a language != language's standard library having it.
  - pjmlp 2y ago
    It is the standard library on the platform, of course it counts. Get Smalltalk-80 reference manual without the UI documentation of its standard library, and no, GNU Smalltalk is not a complete implementation.
    - igouy 2y ago
      "The standard does not attempt to specify areas where current implementations differ in significant ways. In particular, as the goal statement implies, we did not include graphics, user interface, or database accessing objects in the library." 1997 DRAFT ANSI Smalltalk Standard https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-ind...
      - 2y ago