Source

Alt text:

A screenshot from the linked article titled “Reflection in C++26”, showing reflection as one of the bullet points listed in the “Core Language” section

  • JakenVeina@lemm.ee
    link
    fedilink
    English
    arrow-up
    30
    ·
    3 months ago

    It’s the capability of a program to “reflect” upon itself, I.E. to inspect and understand its own code.

    As an example, In C# you can write a class…

    public class MyClass
    {
        public void MyMethod()
        {
            ...
        }
    }
    

    …and you can create an instance of it, and use it, like this…

    var myClass = new MyClass();
    myClass.MyMethod();
    

    Simple enough, nothing we haven’t all seen before.

    But you can do the same thing with reflection, as such…

    var type = System.Reflection.Assembly.GetExecutingAssembly()
        .GetType("MyClass");
    
    var constructor = type.GetConstructor(Array.Empty<Type>());
    
    var instance = constructor.Invoke(Array.Empty<Object>());
    
    var method = type.GetMethod("MyMethod");
    
    var delegate = method.CreateDelegate(typeof(Action), instance);
    
    delegate.DynamicInvoke(Array.Empty<object>());
    

    Obnoxious and verbose and tossing basically all type safety out the window, but it does enable some pretty crazy interesting things. Like self-discovery and dynamic loading of plugins, or self-configuration of apps. Also often useful when messing with generics. I could dig up some practical use-cases, if you’re curious.

    • GetOffMyLan@programming.dev
      link
      fedilink
      arrow-up
      7
      ·
      edit-2
      3 months ago

      You can also optimize this a bit.

      You can use Activator.CreateInstance instead of reflecting and invoking the constructor.

      You can also call MethodInfo.Invoke, you don’t need to create a delegate.

      Also worth noting that Source Generators have replaced the need for reflection in many cases.

      • Zangoose@lemmy.worldOP
        link
        fedilink
        arrow-up
        5
        ·
        3 months ago

        It’s pretty cool when you use it right but it’s also really easy to shoot yourself in the foot with, even by C++ standards. For example, in other languages (I’m coming from Java/C# which both have it) it lets you access private/protected fields and methods when you normally wouldn’t be able to.

        There’s also a noticeable performance penalty over large lists because you’re searching for the field with a string instead of directly accessing it.

        For the times it is necessary (usually serialization-adjacent or dynamic filtering/sorting in a table) to use reflection, it’s faster at runtime than converting an object to a dictionary/hashmap. However, 99% of time it’s a bad call.

        • BatmanAoD@programming.dev
          link
          fedilink
          arrow-up
          6
          ·
          3 months ago

          If you look at the proposal, this is specifically “static reflection”, i.e. compile-time reflection. So it doesn’t actually have any of the downsides you mention, as far as I can tell.