Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflection in C++14: Explanations

blog.simon-ninon.fr

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Reflection in C++14: Explanations

#11

Post by userbinator »

jlarocco wrote: post #8

I wonder how long it'll be before C++ loses its performance advantages. It used to be low level enough that just using it meant you probably got a pretty good performance boost. But if they keep adding features like variants and reflection, and if people actually start using them, it seems like performance will necessarily decline. Or, if not, other languages will look at C++ to see how they handle these features and…

If C++ "loses its performance advantages" it will entirely be due to the culture and not the language itself, because you can still do inline assembler in C++. I've long believed that the reason why lower-level languages have performance advantages is because their paucity of "rich" features means their users often find simpler, more efficient ways of solving problems.

I've noticed this even between C++ and C - without classes, inheritance, and so forth, you tend to think a lot more about whether you need something class-like before going ahead and doing it, and many times a simple function is all you need.

Adding new features almost certainly invites plenty of advocates who will opine about how much better they are (which is true in some situations), encourating their use, even if not actually necessary. This is problematic when these features make it easy to generate large amounts of inefficient code.

Re: Reflection in C++14: Explanations

#13

Post by petke »

jlarocco wrote: post #8

I wonder how long it'll be before C++ loses its performance advantages. It used to be low level enough that just using it meant you probably got a pretty good performance boost. But if they keep adding features like variants and reflection, and if people actually start using them, it seems like performance will necessarily decline. Or, if not, other languages will look at C++ to see how they handle these features and…

No need to worry. They only adds zero cost abstractions. As in, no abstractions or features are added that have a runtime performance cost compared to the optimal hand crafted solution. The standards committee is very anal about this. Also the "you dont pay for what you dont use" rule applies. (Exceptions might be an exception)

Compile time has gotten worse though with some new features. Hopefully modules will help cut it back a bit.

Re: Reflection in C++14: Explanations

#14

Post by Animats »

So, in the end, you have a system which allows a JSON data structure to call arbitrary C++ functions. Is that a good thing? That JSON is now highly trusted. And do you really want to program in JSON?

This is essentially a rather complicated way to build an interpreter for another language. To display web pages. Sort of like PHP.

This might be worth the trouble if you were using it to allow programmable shaders in a renderer. Those are usually composed of functional blocks strung together, they have to go very fast, and they're composed by people who are artists, not programmers, often through some GUI. There, it might not be overkill.

Re: Reflection in C++14: Explanations

#15

Post by tuyguntn »

I appreciate effort given by author, but sorry it seems like "how to guide":

How to kill your time by making simple things complex, then how to kill more time by maintaining it, then how to kill more and more time for adding one small feature.

Re: Reflection in C++14: Explanations

#16

Post by jjoonathan »

kybernetyk wrote: post #7
Rickasaurus wrote: post #2

Still much grosser than reflection in other languages.

Yes, but reflection usually is an ugly hack anyway and if you have to resort to it something is wrong with your design.

Then why do the solutions people use to work around the absence of reflection always seem to suck so much? They're (in some combination) verbose, highly un-DRY, require spectacular feats of type-system-fu, and at the end of the day they deliver capabilities that come up laughably short of their competition in other languages. I'm still waiting for a member of the "Reflection is Useless" crowd to show me a serialization framework on par with what I find in Java (100% DRY, 100% automatic for POD, 100% override-able without a type repository, 100% devoid of compiler/linker trickery). Or a desktop framework that offers UI design capabilities comparable to the introspection-based ones I find in ObjC, C#, or whatever you want to call the home-brew C++-with-reflection that Qt uses.

Re: Reflection in C++14: Explanations

#18

Post by to3m »

jjoonathan wrote: post #16
kybernetyk wrote: post #7

Earlier quoted context omitted.

Yes, but reflection usually is an ugly hack anyway and if you have to resort to it something is wrong with your design.

Then why do the solutions people use to work around the absence of reflection always seem to suck so much? They're (in some combination) verbose, highly un-DRY, require spectacular feats of type-system-fu, and at the end of the day they deliver capabilities that come up laughably short of their competition in other languages. I'm still waiting for a member of the "Reflection is Useless" crowd to show me a serializati…

Yes. And don't just think about how messy the homegrown alternatives are - note how much effort people go to add them in! It's just such a useful thing to have - serialization; logging; UI generation; automatic scripting language bindings - and that's why people bother.

Re: Reflection in C++14: Explanations

#19

Post by petke »

userbinator wrote: post #11
jlarocco wrote: post #8

I wonder how long it'll be before C++ loses its performance advantages. It used to be low level enough that just using it meant you probably got a pretty good performance boost. But if they keep adding features like variants and reflection, and if people actually start using them, it seems like performance will necessarily decline. Or, if not, other languages will look at C++ to see how they handle these features and…

If C++ "loses its performance advantages" it will entirely be due to the culture and not the language itself, because you can still do inline assembler in C++. I've long believed that the reason why lower-level languages have performance advantages is because their paucity of "rich" features means their users often find simpler, more efficient ways of solving problems. I've noticed this even between C++ and C - witho…

People often think of C++ as a Object oriented language. That a very old fashioned way at looking at it. Most modern C++ code avoids OOP like the plague. For instance the author of STL (The C++ standard template library) calls OOP, philosophically unsound, a hoax.

http://www.stlport.org/resources/StepanovUSA.html

Re: Reflection in C++14: Explanations

#20

Post by devit »

jjoonathan wrote: post #16
kybernetyk wrote: post #7

Earlier quoted context omitted.

Yes, but reflection usually is an ugly hack anyway and if you have to resort to it something is wrong with your design.

Then why do the solutions people use to work around the absence of reflection always seem to suck so much? They're (in some combination) verbose, highly un-DRY, require spectacular feats of type-system-fu, and at the end of the day they deliver capabilities that come up laughably short of their competition in other languages. I'm still waiting for a member of the "Reflection is Useless" crowd to show me a serializati…

The best apprach is to have "reflection" (really, access to the compiler AST or IR) at compile time and generate code from this, since that minimizes the run-time overhead.

See Rust's serde for an example of that for serialization.

Post reply on HN