4 ms·

In short, the problem is that you can't do: readable code -> [preprocessor transform] -> transformed code -> [apply transformation tool] -> [reverse preprocess

In short, the problem is that you can't do: readable code -> [preprocessor transform] -> transformed code -> [apply transformation tool] -> [reverse preprocessor transform] -> readable code Because both the preprocessor (and potentially arbitrary transformation tool?) are not bijective. Couldn't you add detection for when the reverse transformation isn't bijective, and then report an error in those cases. Just because there are examples of abuse of header files and macros in C++, it doesn't mean all of it is like that -- especially modern C++. So these tools could still work for a lot of cases. Please, don't give up!

pjmlp 11y ago
I heard on CppCast with Dmitri Nesteruk, that CLion is macro aware when doing refactorings, but it was a very complicated process to make it work properly. Since I spend most of my days in JVM/.NET land, I don't have experience how it really works. They keep in memory the whole macro -> expanded C++ code transformation.
gh02t 11y ago
> Couldn't you add detection for when the reverse transformation isn't bijective, and then report an error in those cases. I was thinking something along those lines too, but then it kind of undermines the goal of the hypothetical tool the previous article was proposing. To get programmers on board with adding breaking changes to the standard, I think you really need a tool that works near perfectly (which is the ultimate problem). Large codebases use macros and templates a lot in my experience and if the tool chokes on some those then people are going to be lazy and say "no thanks." My gut instinct is that it'd have to be down in the range 10 errors / 100kloc before "lazy" (read: busy) programmers would accept it. More crucially, it needs to be sure that it recognizes 100% of errors... it can't make any mistakes about when it does decide that a given transformation is correct because bugs introduced by a mistaken translation are probably going to be extremely subtle and difficult to identify. It's a crappy situation. I think the author was right in the previous article that a magical perfect transformation tool could allow them to make serious and beneficial (but breaking) changes to C++, but such a tool is unbelievably difficult to actually make.

pjmlp 11y ago

I heard on CppCast with Dmitri Nesteruk, that CLion is macro aware when doing refactorings, but it was a very complicated process to make it work properly. Since I spend most of my days in JVM/.NET land, I don't have experience how it really works. They keep in memory the whole macro -> expanded C++ code transformation.

gh02t 11y ago

> Couldn't you add detection for when the reverse transformation isn't bijective, and then report an error in those cases. I was thinking something along those lines too, but then it kind of undermines the goal of the hypothetical tool the previous article was proposing. To get programmers on board with adding breaking changes to the standard, I think you really need a tool that works near perfectly (which is the ultimate problem). Large codebases use macros and templates a lot in my experience and if the tool chokes on some those then people are going to be lazy and say "no thanks." My gut instinct is that it'd have to be down in the range 10 errors / 100kloc before "lazy" (read: busy) programmers would accept it. More crucially, it needs to be sure that it recognizes 100% of errors... it can't make any mistakes about when it does decide that a given transformation is correct because bugs introduced by a mistaken translation are probably going to be extremely subtle and difficult to identify. It's a crappy situation. I think the author was right in the previous article that a magical perfect transformation tool could allow them to make serious and beneficial (but breaking) changes to C++, but such a tool is unbelievably difficult to actually make.