4 ms·

It's not the editing of the header that's the problem, it's doing the edit correctly so that the program still builds. I call it include hell. In addition cha

It's not the editing of the header that's the problem, it's doing the edit correctly so that the program still builds. I call it include hell. In addition changing a header file can at times trigger a lengthy build. Visual Studio and ctags based 'IDE' style features allow you to go to definitions or declarations fairly easily. Unless I'm mistaken I think the eclipse CDT for c++ can change/refactor file and header as you wish for. [1] [2] [1] http://help.eclipse.org/helios/topic/org.eclipse.cdt.doc.user/tasks/cdt_t_refactoring.htm http://help.eclipse.org/helios/topic/org.eclipse.cdt.doc.use... [2] http://r2.ifs.hsr.ch/cdtrefactoring http://r2.ifs.hsr.ch/cdtrefactoring I'm unaware of anything that can change function prototypes correctly, but maybe eclipse CDT can do it.

Groxx 13y ago
>In addition changing a header file can at times trigger a lengthy build. Well yeah, but that's true for doing it by hand too. If it's that slow, you won't have automatic builds on anyway, and you can usually cancel it if you need the CPU for some other reason (in which case, again, why do you have automatic builds on). And even if it were only a 90% thing, that's a 90% savings. I mean, literally, if you change the name alone, change the header name. You get immediate notification that other locations might need changing if/when the build fails. Similarly for argument order / name (type will probably cause build failures). But all those build failures would happen anyway if you changed it by hand, so it's not any different, just faster. Isn't faster the goal here?
- eliasmacpherson 13y ago
  I'm not making a distinction between manually editing and automated editing of a header file. Both are a PITA. Changing the header name sounds like a reasonable suggestion, but I don't think it's a goer with large projects. The problem with headers is that as soon as you are doing anything beyond trivial you can get in to a big fight with the compiler, leading to the following sorts of problems: http://stackoverflow.com/questions/12573816/what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix http://stackoverflow.com/questions/12573816/what-is-an-undef... When these problems are C++ template related, then you have to remember exactly what you changed and where because even on the intel compiler, the compiler isn't really going to tell you what's wrong.

Groxx 13y ago

>In addition changing a header file can at times trigger a lengthy build. Well yeah, but that's true for doing it by hand too. If it's that slow, you won't have automatic builds on anyway, and you can usually cancel it if you need the CPU for some other reason (in which case, again, why do you have automatic builds on). And even if it were only a 90% thing, that's a 90% savings. I mean, literally, if you change the name alone, change the header name. You get immediate notification that other locations might need changing if/when the build fails. Similarly for argument order / name (type will probably cause build failures). But all those build failures would happen anyway if you changed it by hand, so it's not any different, just faster. Isn't faster the goal here?

eliasmacpherson 13y ago
I'm not making a distinction between manually editing and automated editing of a header file. Both are a PITA. Changing the header name sounds like a reasonable suggestion, but I don't think it's a goer with large projects. The problem with headers is that as soon as you are doing anything beyond trivial you can get in to a big fight with the compiler, leading to the following sorts of problems: http://stackoverflow.com/questions/12573816/what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix http://stackoverflow.com/questions/12573816/what-is-an-undef... When these problems are C++ template related, then you have to remember exactly what you changed and where because even on the intel compiler, the compiler isn't really going to tell you what's wrong.