C++17 constexpr Compile-time Ray Tracer (2017)

Re:C++17 constexpr Compile-time Ray Tracer (2017) by jcelerier on Tuesday October 30, 2018 @02:19PM (#18339759)

> My point is, this mismatch between how flexible the technique we're using is versus how much flexibility we actually need

well, most of the software I use every day have some sort of plug-in interface which is done at some point by loading a .dll at runtime and getting derived instances of a base type defined in the host app.

[ Parent | on HN ]

Re:C++17 constexpr Compile-time Ray Tracer (2017) by phaedrus on Tuesday October 30, 2018 @04:09PM (#18340845)

That's a very good point. It might be question of high versus low level. From a video I watched today (the rest of the video is worth watching, too, but the following stand-alone quote is apropos): "Polymorphism and interfaces have to be kept under control. I don't believe that their role is in a very low level system like interpolating a couple of numbers in the animations, but they have their place in high level systems, in client facing APIs. They are amazing if you do a type of plug in and you really need some type of dynamic polymorphism."

https://youtu.be/yy8jQgmhbAU?list=WL&t=2553

[ Parent | on HN ]

Re:C++17 constexpr Compile-time Ray Tracer (2017) by blt on Tuesday October 30, 2018 @05:08PM (#18341289)

For sure, this is one of the legitimate uses of runtime vtable-based polymorphism. But it's also unnecessary if you assume the user is able to recompile the program.

[ Parent | on HN ]