The State Of GNU's GDB Conversion To C++

[pal666]

[/LIST]
Wow, great reasons guys. Hey, you should just skip the problems and convert to Swift. It's low-barrier and newcomers love it.

unlike you, they are not idiots and understand, that c90 code could be recompiled as c++, but has to be rewritten from scratch as swift

[pal666]

Slightly over my head, but this means that GDB will be able to debug both C++ and C instead of just C?

no, gdb itself got rid of some issues and will be easier to develop. and gdb's debugging of c++ code was significantly improved

[pal666]

Almost all of C++ is zero overhead. Just avoid exceptions

actually exceptions have negative overhead, when you compare them to real c replacement(checking of error result after every function call and propagating errors to caller). but most people are too stupid and compare "error handling using exceptions" vs "no error handling at all"

Edit: foreach is a bad example though, it needs stl or stl-like containers

you are bad c++ programmer though, foreach works with plain arrays http://coliru.stacked-crooked.com/a/9c43f0f0e2a28928

especially if they want to avoid all the STL stuff

which would be really stupid thing, and so gdb does use stl (and std strings which are "stl-like containers")

, and just want some better language features.

most good c++ features are targeted at library writers to allow creation of wonderful libraries. including standard library

[pal666]

Exceptions introduce their own overhead in setting up the catch frame.

exceptions eliminate overhead of checking error results after every function call

Using RTTI (features like dynamic_cast) also adds overhead. Both can be turned off though,

you don't have to turn rtti off, you can just avoid using it. but then you will have to use something else and chances are it will be even slower. turning it off just saves some harddrive space, which is cheap anyway

and there are c++ projects which don't use them.

there is no shortage of stupid c++ projects. luckily gdb is not one of them

[carewolf]

actually exceptions have negative overhead, when you compare them to real c replacement(checking of error result after every function call and propagating errors to caller). but most people are too stupid and compare "error handling using exceptions" vs "no error handling at all"

The C replacment is signals. Exceptions are not for error-handling, it is for handling exceptional application behavior that should result in app shutdown.

you are bad c++ programmer though, foreach works with plain arrays http://coliru.stacked-crooked.com/a/9c43f0f0e2a28928
which would be really stupid thing, and so gdb does use stl (and std strings which are "stl-like containers")

And you are a offensively stupid. To use it you would still need to first declare a wrapper class which is more code than just iterating over it normally. And that is if you have length. Using it with zero terminated arrays would not be good, and they are still unfortunately common in C code.

[carewolf]

exceptions eliminate overhead of checking error results after every function call
you don't have to turn rtti off, you can just avoid using it. but then you will have to use something else and chances are it will be even slower. turning it off just saves some harddrive space, which is cheap anyway
there is no shortage of stupid c++ projects. luckily gdb is not one of them

Apparently there no shortage of developer thinking they know C++ but has no clue. You can't use RTTI if you use plugins. So any project with plugins do not rely on it, because they unlike you, know what they are doing.

[cj.wijtmans]

Exceptions introduce their own overhead in setting up the catch frame. Using RTTI (features like dynamic_cast) also adds overhead. Both can be turned off though, and there are c++ projects which don't use them. virtual functions certainly beat the C approach of 'struct of function pointers'.

Actually exceptions have LESS overhead than C error handling and is much better at error handling and debugging(however it really depends on the implementation tho, vcc exception handling used to suck compared to gcc i dont know about today tho). So again i really cant think of anything that adds needless overhead.

[patstew]

The C replacment is signals. Exceptions are not for error-handling, it is for handling exceptional application behavior that should result in app shutdown.

No, they're for error handling that is not locally recoverable. If they were only to cause the application to shutdown, there would be barely any point in catch{}.

And you are a offensively stupid. To use it you would still need to first declare a wrapper class which is more code than just iterating over it normally. And that is if you have length. Using it with zero terminated arrays would not be good, and they are still unfortunately common in C code.

He literally showed a counterexample without a wrapper class. Using it on a normal C style array works fine and is fairly common.

Apparently there no shortage of developer thinking they know C++ but has no clue. You can't use RTTI if you use plugins. So any project with plugins do not rely on it, because they unlike you, know what they are doing.

Are you thinking of some specific type of plugins? I've written an application with plugins that uses RTTI in a couple of places, I don't really see what the problem is.

[cj.wijtmans]

The C replacment is signals. Exceptions are not for error-handling, it is for handling exceptional application behavior that should result in app shutdown.

That is completely false. For example in a class constructor (using the superior RAII) you dont have proper error handling unless you can poll the state of the object but imho that is not proper design. In a class constructor you throw an exception when something goes wrong. You catch this error ofcourse whenever you can. If you cant then you have a crash... This ensures the flow of the application and that nothing get corrupted. Exceptions ARE error handling. And they make debugging easy.

[pal666]

The C replacment is signals. Exceptions are not for error-handling, it is for handling exceptional application behavior that should result in app shutdown.

did i tell you that you are bad c++ programmer? exceptions is a method of error handling, which indeed best employed for exceptional errors and it has nothing to do with shutdown, though shutdown is one of possible outcomes of error handling. signals btw also have nothing to do with shutdown, just some signals have default shutdown outcome

To use it you would still need to first declare a wrapper class which is more code than just iterating over it normally.

imbecile, i gave you working example without any wrapper classes

And that is if you have length. Using it with zero terminated arrays would not be good, and they are still unfortunately common in C code.

with zero-terminated arrays you will need one tiny templated wrapper for all your plain arrays. like this http://coliru.stacked-crooked.com/a/0e9cb457eb477685
if we are talking about non-trivial project, it is less code than all its "normal" iterations and less chances to make an error by comparing or incrementing wrong value