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

21–30 of 37 posts

Re: Reflection in C++14: Explanations

#21

Post by something123 »

Yikes.. I'm going to have to reread this later to grok it better. I think it's nice that the language has added all these new features (though the macros at the end tell me it's not enough..) - but I keep feeling like the direction of the language post-C++11 has been steered by library developers with these more and more difficult to digest features. Features that you don't end up using every day, and so they never really sink in.

There are plenty of simpler things I'd like them to tackle before. Just in the past week of work two examples come to mind (just to illustrate that there are still issues)

- I was trying to get some function calls to inline and had to fight the compiler for half the day to get it to inline them for me (I still don;t understand why it's okay that the compiler ignored the inline keyword. Can't we assume that I as the developer will know what's best if I explicitly put the keyword there?)

- Then the next day I had the opposite problem where a branch was being inlined even though I wanted a if(/rare event/){ jump to some method}. Again the language provides no tools for me to accomplish that

There are tons of issues with the standard library containers and data locality that have been ignored too.

C++ is THE high performance language - can we spend some time on performance and stop pretending that there isn't room for improvement on that front?

Re: Reflection in C++14: Explanations

#22

Post by [deleted] »

devit wrote: post #20
jjoonathan wrote: post #16

Earlier quoted context omitted.

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.

[deleted]

Re: Reflection in C++14: Explanations

#23

Post by Svenstaro »

maikklein wrote: post #6
Svenstaro wrote: post #3

I applaud your effort and I actually like your result but this just shows how much we need real reflection in C++17. I like to use C++ for its performance and the recent standards were a big leap in the right direction but reflection just isn't one of C++'s strengths.

Afaik reflection doesn't make it into C++17.

Nuuuh. :(

Re: Reflection in C++14: Explanations

#24

Post by fauigerzigerk »

So here's my advice on the writing an article like this: Show the result first, then explain how you arrived there!

Otherwise some readers will end up frustrated with the solution after absorbing tons of detail, and others will have given up even though they might have liked the result.

Re: Reflection in C++14: Explanations

#25

Post by robohamburger »

It makes sense to consider what you make configurable especially when it is this expensive. I can't imagine routes change that much and when they do they probably change with code.

This seems like the kind of yak shaving that can really ruin a perfectly good project.

That isn't to say configuration doesn't have its place! One of the reasons I love python and interpreted languages is it is very easy to do when you need it.

Re: Reflection in C++14: Explanations

#26

Post by fauigerzigerk »

petke wrote: post #13
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 c…

I think the term "zero cost abstraction" is a bit misleading. Abstraction means that developers don't have to think about some lower level aspects that they would have given some thought otherwise. That tends to result in inefficiencies.

For instance, C programmers will think a lot more about the size of buffers, how big they need to be, can they be fixed size, can they be reused, etc, because expanding them is often a manual task. In C++ it's so easy to do things like this even though it could be done much more efficiently:

  string parse(const string& data) {
    stringstream result;
    for (char c : data) {
      if (someCondition(c)) {
        result

Re: Reflection in C++14: Explanations

#27

Post by Elv13 »

I had to write some introspection system for a project a while ago. It wasn't the same use case and calling by name wasn't even required. It was more about handling random object from an unified interface issue.

Anyway, here is an extreme oversimplified introspection engine I just wrote. It only implement creating wrapper "generic" object by class name. While we both used some of the same tricks, I have a few more that make introspection simpler. My implementation also work on embedded systems without a working "dynamic_cast" and C++ runtime type identifier.

https://gist.github.com/Elv13/715fb1b3dc4b774a06ca

Edit: Just to clarify, this is a much smaller subset of what you implemented in the blog post, but it can be extended into a full introspection system using more lambdas maps and variadic template tricks.

Re: Reflection in C++14: Explanations

#28

Post by green7ea »

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.

There are use cases for which reflection is very useful. Things like automatic serialization are an obvious example. There's also automatic printing of complex types, automatic guis (think unity).

There are a few use cases which aren't very obvious like having a vector for each element in a structure instead of having a vector of the structure. This greatly improves cache locality and can be a great gain in performance for some applications.

Of course this is more introspection which is a specific case of reflection but all these examples are definitely not 'ugly hacks' and could greatly improve C++ as a language.

Re: Reflection in C++14: Explanations

#29

Post by iabacu »

userbinator wrote: post #9

I didn’t want the developer to declare his routes by writing C++ code ...in a web framework in C++ , where presumably the developer would need to write C++ anyway to make use of it? This article is quite long and complex No kidding. And to me, all that complexity just screams "you're doing it wrong." I read this article all the way to the end, and was disappointed to find that, after all that code, it ends with a sin…

I’d prefer to have a simple JSON configuration file... followed by a pile of unnecessary complexity in the form of new semantics on how to declare and tie things together.

I highly doubt that this is making author's developers life easier.

More likely, it's just an over-engineering indulgence, that happens to make one's job more secure.

Re: Reflection in C++14: Explanations

#30

Post by petke »

fauigerzigerk wrote: post #26
petke wrote: post #13

Earlier quoted context omitted.

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 c…

I think the term "zero cost abstraction" is a bit misleading. Abstraction means that developers don't have to think about some lower level aspects that they would have given some thought otherwise. That tends to result in inefficiencies. For instance, C programmers will think a lot more about the size of buffers, how big they need to be, can they be fixed size, can they be reused, etc, because expanding them is often…

I dont think I agree. Abstraction in my view is (mostly) about removing implementation details that dont change from one implementation to another. Its about removing boilerplate until just the fundamental features of the implementations remain. It would be a bad abstraction if details (low level or otherwise) that do change, are removed.

Im not sure I get your example. Are you implying that this C++ code is inefficient because the allocation for result is not done in advance? If you know the size of result in advance, there is no reason to use a stream for result. You can simply use std::string and reserve.

Post reply on HN