preprocessor tricks are cute, but there's definitely something to be said for staying completely w/in the language -- I've really come to appreciate this using Go, where I get incredible auto-formatting, rename refactor, and source introspection tools that would not be possible if a preprocessor were standard-issue.
(Of course, Java people have been saying something similar for a long time, but I never could get into it, 'cuz of a bunch of other stuff, like the IDE-centric culture & the language itself)
> but there's definitely something to be said for staying completely w/in the language
The C Pre Processor is defined in the ISO C standard. In order for any implementation to call it self a normative conforming C implementation I has to include a pre processor to spec. The Pre Processor is part of the ISO C language.
All of those things are had quite easily with C. Either as IDE/Editor features or with separate tools such as Clang Complete, Valgrind and many others.
spent a long time w/ c and c++, never found tools anywhere near as good as what i've got now for go.
maybe/probably not impossible, but a lot harder in practice. i have no personal experience, but people that seem to know what they're talking about say a big reason is the preprocessor makes life a lot harder. (and other stuff too, of course, like not having build semantics built into the language, and, for c++, just insane complexity in general.)
obviously the preprocessor is well-defined and standardized, but it still: operates on a totally different semantic level. it really is like two entirely different languages pasted together.
Would you mind listing a few tools you use with go?
I do not have much exposure to go but from what I have seen there is a nice set of introspection libraries. are you talking about tools that use these?
A final note, real time semantic checking of multiple expansion macros has been solved for quite a few years now and is in most IDE's and even in Vim and Emacs. Semantic analysis is done in the comelier, LLVM/Clang lib has given rise to a substantial set of tools that are now quite widely used and solve most of the problems.
And I believe C++17 with concepts is also going to have a dramatic effect on complexity and readability of template error messages.
these days my only c use is via obj-c in xcode, so i may well be unaware of the state of the art for straight c or straight c++ / other tools. xcode's refactorings and jump-to-defn (presumably powered by clang?) are still very flaky for me.
for go, i use:
goimports -- which is gofmt (which is awesome) + auto-adding/removing imports (just a heuristic so not always right, but usually right and quite handy)
godef -- for jumping to definitions
gorename -- for rename refactorings. i have not once gotten this to break code.
oracle -- for showing other things about code, like 'which types implement this interface?'. as far as i can tell, it hasn't lied to me yet.
i use emacs as my editor, which integrates easily w/ all of the above tools.
i'm not sure what libraries power the tools above, but i think it's true that packages like go/types do the heavy lifting and make them relatively easy to write.
> preprocessor tricks are cute, but there's definitely something to be said for staying completely w/in the language -- I've really come to appreciate this using Go,
Wait, doesn't Go use code generation as well? I thought their answer to "we don't have a generics" is to basically run a gen as a preprocessor then generate a bunch of code?
definitely code generation breaks similar things to the preprocessor, but it's got a different set of trade-offs. basically the generated code is there to look at, so rename refactors or jump-to-definition or what have you will work reliably, until you regenerate the code. depending on how the code regeneration works (is it just annotations of existing code?), maybe the regenerated code will work and match the code definition.
from past experience, i view code generation with a healthy amount of skepticism, for the same reasons i'm skeptical of the preprocessor! it's cool, it's powerful, you lose out on a lot.
my impression/experience of go is that codegen is still not widespread. (i haven't seen it much, anyway.)
(Of course, Java people have been saying something similar for a long time, but I never could get into it, 'cuz of a bunch of other stuff, like the IDE-centric culture & the language itself)