←back to thread

196 points svlasov | 1 comments | | HN request time: 0s | source
Show context
Dwedit ◴[] No.40851285[source]
Compile time or runtime? Compile time reflection would be completely painless and bloat-free.
replies(3): >>40851300 #>>40851330 #>>40851736 #
thechao ◴[] No.40851736[source]
Having implemented reflection in languages like C(++), before, it is most certainly not bloat-free. There are sorts of 'obvious' things programmers do (like enum-reflection) that end up injecting strings all over the place. The overhead is (worst case) proportional to the source-code size, in those cases. In other cases, you end up with bloat proportional to heavily-utilized template libraries. However, unless the reflection system is very clever, i.e., exposes enough information to the linker to strip duplicate-ish symbols, you end up with a bunch of reflection copies.
replies(2): >>40852644 #>>40852761 #
zarzavat ◴[] No.40852761[source]
I always thought it’s good practice in C/C++ to have only one translation unit in release builds e.g. SQLite amalgamations, instead of relying on LTO. It also speeds up compilation because it isn’t recompiling the same header files over and over again.
replies(2): >>40853586 #>>40854808 #
kccqzy ◴[] No.40853586[source]
It's a cute idea but just not scalable. It doesn't speed up compilation because separate translation units can be compiled independently and cached.
replies(2): >>40855459 #>>40855583 #
zarzavat ◴[] No.40855459[source]
Do things that don’t scale :)

Obviously it’s not suitable for dev builds, I don’t think anyone uses it for that. For release builds you would want to clear caches anyway.

replies(1): >>40859831 #
1. kccqzy ◴[] No.40859831[source]
You don't want to clear caches for release builds. That just makes release builds unnecessarily slow and impedes the flow of Continuous Deployment. You just need to have separate caches for different build flags, including a dedicated cache for release builds.