It's remarkable that modifying C++ headers is such a chore that it comes up as a reason for getting something done in a tiny fraction of the time for a roughly comparable task.
Couldn't agree more. Though I don't find it all that painful - lots of editors/IDEs have a 'go to header file' shortcut that makes this take a couple seconds at worst.
But then I have repeatedly wondered why IDEs don't seem to have a way to synchronize your cpp changes to your header automatically. Rename function in .cpp -> automagically rename function in .h. That's all you really want a lot of the time.
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.use...
[2] http://r2.ifs.hsr.ch/cdtrefactoring
I'm unaware of anything that can change function prototypes correctly, but maybe eclipse CDT can do it.
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?
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-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.
link taken from here: http://stackoverflow.com/a/13840863
C++ has no future by design.
http://en.cppreference.com/w/cpp/language/except_spec
The fact this is deprecated in c++11 is my personal pet peeve.
I can't reason about what the impact is without putting it in to practice, but given that exception safe C++ can be hard to write and it's deprecated does that mean it's going away in C++14 and what are the implications of that?
The throw() specifier (counter intuitively meaning 'should not throw anything') is everywhere! If it turns out that all the advocacy for using exceptions has resulted in written code that uses deprecated conventions and requires maintenance and re-understanding, then I will be very very disappointed.
C++'s design combines the worst of checked and unchecked exceptions and adds some additional run-time overhead for good measure. Writing exception-safe C++ code is essentially impractical for large C++ programs that include C libraries unless you write your own RAII classes for everything. But then your C++ code is littered with unreadable std::shared_ptr<whatever> everywhere. If C++11 had adopted some Rust-like shorthand syntax for std::shared_ptr and std::unique_ptr, it might actually be palatable.
are you sure about that [1][2], this is what throw() was deprecated for:
[1]http://en.cppreference.com/w/cpp/language/noexcept
[2]http://en.cppreference.com/w/cpp/language/noexcept_spec
Unless I am mistaken, on 32bit platforms exceptions incur a runtime overhead but for 64bit zero cost exceptions were developed, and only incur overhead if they are triggered [3]
[3] http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Exception-Handlin...
I think that any calls to the C library can be handled as followed in an exception safe manner unless I misunderstand you:
EDIT:( I misunderstood you, you meant wrapping resources, what follows is nonsense as a C library isn't going to throw any exception)
void library_function_wrapper()
{
try
{
library_function();
}
catch(...)
{
}
} void f() throw(X, Y)
{
int n = 0;
if (n) throw X(); // OK
if (n) throw Z(); // also OK
throw W(); // will call std::unexpected() at run-time, not a compile-time error
}