An include with a HTTP URL is a scary abomination straight put of hell. Please tell me that this is a compiler explorer specialty (which would still be cursed, but in a cool way) and not a GCC feature (which would be an absolute nightmare).
I see there's an issue in the tracker to get more accurate data, and since it's using an under dev feature in compilers, it's not going to be definitive, but any rough numbers?
I don't have any numbers, but it is pretty slow. You can try making some edits in Compiler Explorer to see for yourself (though that of course has some impact from network requests).
One reason is that, like you said, the feature is still new. Additionally I made pretty liberal use of the std::ranges library in my implementation which has notoriously bad compile times. That could be an area to improve upon.
Another may be a bit more structural. If you want to call myObj.foo() via reflection, you have to linearly search members_of(myObj) for the one named "foo", and then call that. Actual compilers I assume use some kind of hash table.
The hand-waving solution is "put it in a PCH", but I am hoping to put some more effort into optimizing build time here in the future.
This library tries its best to mitigate that, catching common errors and whatnot, but it can definitely still happen. C++ doesn't have full token injection yet, so it avoids some of the more common pitfalls, if incidentally.
As an aside, you may want to check out Jai's approach. I believe everything you generate statically gets turned into a file by the compiler for debugging purposes, which it provides references to in the output.
I don’t really like much about C++ anymore, but I still enjoy reading C++ articles and listening to C++ podcasts, and I would consider it beautiful. Oftentimes the things I dislike about it are also the beautiful things. The term “beautiful mess” seems appropriate.
It’s a bit like a well-kept Victorian home. The amount of work, money, and dealing with discomfort that goes into maintaining one isn’t something I really want to experience for myself. But the amount of skill and craftsmanship that it takes to preserve one is still impressive, and I have to appreciate the respect for history and the care that goes into balancing it with modern concerns.
And talking to people who do live the life is always a great learning experience.
I find it hard to see a language as beautiful that’s grown too complex for a single person to hold a complete mental model of.
I used to think that was a personal limitation, until I saw an interview with Bjarne explaining that he used to understand all of it but at this point it’s too big, no one can anymore.
That is exactly what I was thinking. I was a seasoned C++ programmer and always loved reading articles like this. I can't imagine I will every write my own C++ code again -- or in any language. I now program with English specifications now and I am 10000% times more productive.
Try it on Compiler Explorer: https://godbolt.org/z/91dj5jeGW
Check out the source code: https://github.com/RyanJK5/rjk-duck
An include with a HTTP URL is a scary abomination straight put of hell. Please tell me that this is a compiler explorer specialty (which would still be cursed, but in a cool way) and not a GCC feature (which would be an absolute nightmare).
in the first example:
```
10: rjk::duck<Container> c{std::vector<int>{1, 2, 3}};
11: c.size(); // 3
12:
13: c = std::string{"hello"};
```
Does the assignment on line 13 call the destrucor for the vector of ints created on line 10?
What's compilation time like when using it?
I see there's an issue in the tracker to get more accurate data, and since it's using an under dev feature in compilers, it's not going to be definitive, but any rough numbers?
I don't have any numbers, but it is pretty slow. You can try making some edits in Compiler Explorer to see for yourself (though that of course has some impact from network requests).
One reason is that, like you said, the feature is still new. Additionally I made pretty liberal use of the std::ranges library in my implementation which has notoriously bad compile times. That could be an area to improve upon.
Another may be a bit more structural. If you want to call myObj.foo() via reflection, you have to linearly search members_of(myObj) for the one named "foo", and then call that. Actual compilers I assume use some kind of hash table.
The hand-waving solution is "put it in a PCH", but I am hoping to put some more effort into optimizing build time here in the future.
Reflections, especially static ones, are horrible for debugging.
Depends pretty much on the language and IDE tooling being used.
Those against IDEs, well they already voted against good tooling in first place.
This library tries its best to mitigate that, catching common errors and whatnot, but it can definitely still happen. C++ doesn't have full token injection yet, so it avoids some of the more common pitfalls, if incidentally.
As an aside, you may want to check out Jai's approach. I believe everything you generate statically gets turned into a file by the compiler for debugging purposes, which it provides references to in the output.
The things people describe as "beautiful" never cease to amaze me...
...but, as they say, beauty is in the eye of the beholder!
I don’t really like much about C++ anymore, but I still enjoy reading C++ articles and listening to C++ podcasts, and I would consider it beautiful. Oftentimes the things I dislike about it are also the beautiful things. The term “beautiful mess” seems appropriate.
It’s a bit like a well-kept Victorian home. The amount of work, money, and dealing with discomfort that goes into maintaining one isn’t something I really want to experience for myself. But the amount of skill and craftsmanship that it takes to preserve one is still impressive, and I have to appreciate the respect for history and the care that goes into balancing it with modern concerns.
And talking to people who do live the life is always a great learning experience.
Beauty in C++ may be most similar to lipstick on a pig, but we try our best.
I find it hard to see a language as beautiful that’s grown too complex for a single person to hold a complete mental model of.
I used to think that was a personal limitation, until I saw an interview with Bjarne explaining that he used to understand all of it but at this point it’s too big, no one can anymore.
this is the most disgusting programming language ever invented!
I think that is perl, but I share what you mean, as more features they add, as uglyer it gets.
are we still hand writing code?
That is exactly what I was thinking. I was a seasoned C++ programmer and always loved reading articles like this. I can't imagine I will every write my own C++ code again -- or in any language. I now program with English specifications now and I am 10000% times more productive.