Refactoring browsers for C and C++

This is a discussion on Refactoring browsers for C and C++ within the Tech Board forums, part of the Community Boards category; Yes, of course, good old search-and-replace. CTRL-H, CTRL-R, etc. Actually, I have used "search and replace in selection" on occasion. ...

Yes, of course, good old search-and-replace. CTRL-H, CTRL-R, etc. Actually, I have used "search and replace in selection" on occasion. But project-wide search-and-replace, for example renaming a function, tends to go wrong. And prompting you before each replace take way too long and you get bored and click "replace" on something that you shouldn't have without realizing it. Until you try to compile or run it.

Originally Posted by twomers' signature, originally Daved

my code only generates a hundred or so bugs per feature.

Did you know, while researching preprocessor macros (there are an average of 0.6 per line, I think), I found a statistic that stated that every new line of code written has between 2 and 5 bugs in it? Scary.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Elsa requires preprocessed files, so I preprocessed that and tried parsing it with Elsa. It didn't work. g++ 4.1 worked, but not g++ 4.2. Anyway, I then got Elsa to print the elaborated abstract syntax tree. It was 692,000 lines. Ouch.

Not that the abstract syntax tree is very concise. Something like this

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Yes, of course, good old search-and-replace. CTRL-H, CTRL-R, etc. Actually, I have used "search and replace in selection" on occasion. But project-wide search-and-replace, for example renaming a function, tends to go wrong. And prompting you before each replace take way too long and you get bored and click "replace" on something that you shouldn't have without realizing it. Until you try to compile or run it.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Well, "can occur as frequently as" and "an average of" is quite different. One is the maximum per-program average they found, the other would be an average over all the code they looked at. I'll believe the former, but the latter is absurd.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell