3 ms·

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

• armchairhacker 2y ago
  Compile-time (“static reflection”)
• shortrounddev2 2y ago
  RTTI is a super vital feature for deserializing without having to generate code or write a ton of tedious boilerplate. I'd be very happy with RTTI in C++ and my life would be instantly easier if there were RTTI in typescript so I didn't have to use any of the hacky solutions out there for deserializing JSON on backends without RTTI. I suppose C++'s template system might be able to generate JSON deserializers with static reflection as well
  • chongli 2y ago
    You don't need RTTI to deserialize data in a clean way. What you need is return-type polymorphism. Haskell has this and it makes writing serializers and deserializers symmetric and totally painless.
    • fooker 2y ago
      Return type polymorphism and inheritance doesn't mix very well. Swift got into this mess early in it's lifecycle and it's type checking is still more expensive than the rest of the compiler combined, and unpredictable on top of that.
      • chongli 2y ago
        Yeah if you ask me, inheritance is the one to go. Every time. Inheritance just makes things more complicated. It’s not a great tool of abstraction.
      • Maxatar 2y ago
        C++ has both return type polymorphism and inheritance. What it doesn't have is the kind of type inference that Haskell has. Its type inference is very limited.
        • fooker 2y ago
          You can't have two functions that differ in just the return type in C++
          • slaymaker1907 2y ago
            You can sort of do it so long as the return type is a template parameter. template<typename T> T my_construct() { T result; return result; }
            • account42 2y ago
              That's not polymorphism as that template parameter won't be deduced in any context and you will always have to explicitly instantiate the template.
              • Maxatar 2y ago
                That is still polymorphic, but as I mentioned C++ does not do the kind of type deduction that Haskell supports so you do have to explicitly instantiate the template. However, you can instantiate it based on context, for example using decltype.
              • gpderetta 2y ago
                challenge accepted: https://gcc.godbolt.org/z/bGdP79aEj https://gcc.godbolt.org/z/bGdP79aEj edit: you get pseudo call-by-name as a bonus.
          • pritambaral 2y ago
            You can, if you abuse C++ enough. I needed this very thing for a custom DSL. struct PolyReturn { const int value; operator int() const { return value; } operator bool() const { return value > 0; } }; https://cppinsights.io/s/f0b9976f https://cppinsights.io/s/f0b9976f
  • comex 2y ago
    > I suppose C++'s template system might be able to generate JSON deserializers with static reflection as well It definitely can, and it will be faster and more type-safe than doing it at runtime. But if you do want to do it at runtime, well, it's possible to implement runtime reflection as a library on top of compile-time reflection, so someone will probably do that.
• thechao 2y ago
  Having implemented reflection in languages like C(++), before, it is most certainly not bloat-free. There are sorts of 'obvious' things programmers do (like enum-reflection) that end up injecting strings all over the place. The overhead is (worst case) proportional to the source-code size, in those cases. In other cases, you end up with bloat proportional to heavily-utilized template libraries. However, unless the reflection system is very clever, i.e., exposes enough information to the linker to strip duplicate-ish symbols, you end up with a bunch of reflection copies.
  • rerdavies 2y ago
    extern templates address the issue of having multiple instances of a template being expanded inline, with only minimal mess and fuss. (A way to prevent inlining of templated code would have been nice too).
  • zarzavat 2y ago
    I always thought it’s good practice in C/C++ to have only one translation unit in release builds e.g. SQLite amalgamations, instead of relying on LTO. It also speeds up compilation because it isn’t recompiling the same header files over and over again.
    • kccqzy 2y ago
      It's a cute idea but just not scalable. It doesn't speed up compilation because separate translation units can be compiled independently and cached.
      • zarzavat 2y ago
        Do things that don’t scale :) Obviously it’s not suitable for dev builds, I don’t think anyone uses it for that. For release builds you would want to clear caches anyway.
        • kccqzy 2y ago
          You don't want to clear caches for release builds. That just makes release builds unnecessarily slow and impedes the flow of Continuous Deployment. You just need to have separate caches for different build flags, including a dedicated cache for release builds.