Reflection in C++ - Past, Present, and Hopeful Future - Andrei Alexandrescu - CppCon 2022
ฝัง
- เผยแพร่เมื่อ 6 ก.ค. 2024
- cppcon.org/
---
Reflection in C++ - Past, Present, and Hopeful Future - Andrei Alexandrescu - CppCon 2022
github.com/CppCon/CppCon2022
Aspect Oriented Programming. Metaobject protocols. Intentional programming. AspectC++. OpenC++. C++ metaclasses. Reflection and related technologies already has a long history in the theory and practice of several programming languages, including C++. However, the lofty promises of the 1990s (user-defined language semantics, infinite configurability, ultimate code reuse) failed to materialize in mainstream success.
Within the standard C++ realm, a reflection proposal has had a long and meandering road that is finally converging. Will it be successful? Why is this time different? And most importantly, what's in it for the community - what compelling applications are at the horizon to justify the addition to an already large language core?
This talk explores these questions and several related others. Although you won't take home code and insights that you can put to work tomorrow, you will acquire something that is less urgent but arguably more important: a vision of a better way of writing programs. Think generic programming without the pain, high-leverage generic code, seamless integration with foreign languages, and much more.
---
Andrei Alexandrescu
Andrei Alexandrescu is a Principal Research Scientist at NVIDIA. He wrote three best-selling books on programming (Modern C++ Design, C++ Coding Standards, and The D Programming Language) and numerous articles and papers on wide-ranging topics from programming to language design to Machine Learning to Natural Language Processing to fundamental algorithms. Andrei holds a PhD in Computer Science from the University of Washington and a BSc in Electrical Engineering from University "Politehnica" Bucharest. He is the Vice President of the D Language Foundation.
---
Videos Streamed & Edited by Digital Medium: online.digital-medium.co.uk
#cppcon #programming #cpp - วิทยาศาสตร์และเทคโนโลยี
I've watched enough cppcon videos to know - Andrei Alexandrescu is the one you NEVER want to miss!
Sutter, chandler carruth and his talks never disappoint
I would add Jason Turner to that list, but yes, Andrei is certainly one of the best of the best
@@zohandvir9606 agreed always, good topics and well (interestingly) presented
There is a paradigm that Andrei has proposed before, especially in the context of D programming language, called "design by introspection" and is exactly the reflection use case that he describes in the first half of this talk. I'm glad that he thinks that it can be done in C++ as well. Excellent work!
It's also great that this talk compares C++, D and Rust.
I'm a bit sad that Andrei did not have this talk in person 😥.
A fantastic talk as always! Andrei always delivers informative talks in an easily understood way!
I can't wait for static reflection to be fully-baked and available for use!
Amazing feature! I can't even begin to imagine the kind of libraries we can write using something like this!
Thank you! Value based reflection FTW!
Andrei is always great
His talks are amazing, and this one is no exception
Awesome, compile time reflection, cpp is great
Quite interesting talk, thank you!
However, I must say that I am not a big fan of the proposed operators ^T and [:e:], because the latter one is significantly more complex to type and ^ already has other meanings. I wonder if it wouldn't be possible to just use the so far unused '$' for both : $T gives meta::info value and $e, if e is a meta::info value, just gives back the template name/type. $$T is T while $$e is e. Also, it would be a lot easier to type.
The point about std::stack is so true.
It's extremely rare that you can afford to use just a pure stack where only the top element can be manipulated, it's ultra frequent to have the need to check the top but also top +1 or top +2 to know if you need to for example perform an operation. I always ended up using a vector or a dequeue instead.
Billions and billions of people watching offline :D Gotta love Dr Andrei's confidence :D
This video comes on the heels of the announcement that the current conservative estimate for reflection in C++ is C++29, in 6 years.
I really hope the "compile time for loop" ends up having the syntax "for constexpr" for consistency with "if constexpr" rather than "template for (constexpr" (and the syntax would signify that everything inside the for () brackets should be constexpr). C++ really seems to have a knack for overly wordy, inconsistent syntax. For example, compare the general template syntax to other languages like Rust, Zig, Odin, or Vale. I get the whole thing about decades of legacy and all, but that's one of the things that makes C++ code consistently less readable then other modern languages.
That’s why Herb Sutter is working on an alternate syntax solution.
My impression is that it's intentionally different because it works differently. `if constexper` and `for constexpr` must appear where you can have a statement, and it introduces a scope.
`template for` does not introduce a scope, and can appear in the middle of a `class` definition to add a member.
And a `template for (f(e))` where `f` is a consteval function that returns a list of one item if e is true and a list of 0 items otherwise would be functionally identical to a `template if`, though without an `else` clause.
Now recall the huge discussion around `if constexpr` some years ago. The introduction of a "static if" language feature in a way that would work for C++ gave us the limited `if constexpr` even though having a more general `template if` that could introduce declarations was on the table, and Andrei was certainly lobbying for it. It would pay to revisit the rationale for what was decided on. I'm sure it has some rational based on existing compiler implementation and what could be confidently and correctly implemented in a short time.
can't believe he made it an hour without throwing due shade at concepts
but what if we can have a scope AND a keyword to export or inject the definitions of this scope into an outer scope? It can complicate the lifetime of the injected thing, but still, it's a nice way to reuse existing statements instead of making new stateless versions of the statements
29:52 It's nice that Rust allows you to do exactly that!
45:51 To be more specific, procedural Rust macros come in several flavors and each of them has their their strengths and limitations. Derive macros can only insert new tokens into the AST. Attribute macros can rewrite the tokens corresponding to an item but both input and output code still should be an item in Rust (it can't be `struct MyStruct {` because it requires a closing brace). Even function-like (the most powerful) Rust macros can't produce `struct MyStruct` but they can accept nearly arbitrary syntax.
Very interesting! but why can't you do something like Qt's meta-object system, based on the QObject base class or similar java object ? Or does the inheritance approach have some problems?
_"Qt's meta-object system, based on the QObject base class or similar java object"_
This would just be runtime type information. What is presented in this talk is ability to query, process and generate code at compile time.
C++ needs compile time reflection, so we can get rid of all the preprocessor crimes everyone been committing for 43 years.
Also, the Qt uses preprocessor to implement these things. With the addition of reflection to C++, Qt will be able to use it to implement its things instead of macros.
Could you please provide the accurate subtitles for this video?
Language =defined= reliable (=fixed) means of communications.
very interesting talk, i work with C# and sometimes I use the reflection facilities there, but it's mostly for unit testing code, and never for serious stuff. (and it's runtime, not compile time)
I didn't understand the part about introducing scope, can someone clarify the problem?
Dynamic reflection akin to available in C# is not suitable to many domains where C++ is used. But even C# currently slowly moves towards compile time reflection/code-generation. In general reflection is more suitable for library code and it used a lot in .NET under the hood: all the various XML and JSON serializers, all the design-time support for UI components is done by reflecting user types and querying attributes attached to them. If static reflection comes to C++ it would be used for the same kinds of tasks
@@grigorij81 Exactly. I have been writing my own ORM and reflection is the literally the core technology making it possible and I would love to bring it do C++ as well. And if they are bringing reflection, might as well bring custom attribute too
"never use public inheritance against a value type" at 18:16 Why is that discouraged?
Slicing
@@martinba9629 But wouldn't that be only a problem if tainted_string added some member variables to string? If you do not want to change the class you should be fine right?
@@Knitschi656 When you're inheriting from a value type, you almost never want an "is a" relationship but rather an "implemented in terms of" relationship. Thats public vs private inheritance. Slicing is not the only problem but rather just a symptom of using the wrong type of inheritance. Public inheritence or "is a" inheritance implies that you can substitute the derived class for the base class. This is a baaaaad idea.
For example, in our case of the tainted_string which publicly inherits from std::string, any function which accepts a std::string will now accept a tainted_string making the whole thing completely pointless. Quick, if "s" is a tainted_string what type does "s + s" have? Or in the example where you have a bound_checked_vector that publicly inherits from std::vector, any function which accepts a std::vector now accepts your bound_checked_vector but *bypasses the bound checking*. Is that really what you intended?
Also, did you check that you actually bound-checked every single relevant member function? Oh you did? And when your team updates to C++23 you're going to remember to go back to this class and add a bound-checked version of "insert_range" right? Yeah probably not. When you inherit from something that wasn't designed to be inherited, your code becomes very brittle and susceptible to undefined behavior. That holds even for private inheritance to some degree but *especially* for public inheritance. You're letting somebody else's code just affect the API of your class in ways that you have no idea about.
2.1 Billion of Billions so far ;)
Why did it take so long to introduce proper compile time reflections? Also the syntax looks over complicated, oh well.
I think C++ should have an official Python-inspired scripting language
i dont agree with the notation, type to meta should be similar to decltype
It's actually hard for me to understand this talk. :(
[Finished]: 2.5 Stars
I think this video is not that friendly to a C++ beginner like me. The advice the speaker gave do not come with specific examples of the current C++ usage, so I could not fully understand the necessity of adding these features. I hope more code examples can be given to describe these thoughts.
This feels like it should be illegal
The syntax is absolutely atrocious. What happened to Herb's syntax? It was actually made for humans
The operators "^" and ":" is the Worst idea in C++ by a long shot.
The earlier proposal of "refl_expr" was not very nice but was way better of conveying the meaning.
Currently it looks like reflections will be about as useful as std::regex - aka absolutely broken and useless.
C++ really is going the way that Stroustroup often said he wanted to avoid - some fools in the ivory tower deciding how it should be, making it just more bloated, complex and useless.
24:50, sounds like you finally learned how bad it is to focus only on OO code like c++ does, we C devs sit here amused since we stuck to functional based programming, we want objects, we use struct, we want initialisers, we define them separate from the object, we want long lived buffers & object, we use malloc/realloc or some other common allocation function, yes we have to jump through a few more hoops and be more careful with our pointers but we can do pretty much whatever we want with the data we have, c++ on the other simply shot itself in the foot, chest, hands and is now pointing the gun at it's own head :)
C++ does not only focus on OO like you claim. It has always been a multi paradigm language. C is not functional based programming either. There are many issues with the "solutions" you proposed, which by the way, are also available to C++ devs.
Lol c has nothing to do with functional languages
pdf for this video is not available.