The "market" was defined as "operating systems for x86 compatible computers", which restricted the market in a manner that excluded Apple from the calculation.
Local variables, when not placed in registers can be allocated on a stack, even in a basic block inside of a function, hence the goto can jump into another stack frame because many of them can exist inside of a single method.
Compilers handle this correctly.
btw: An expected error? What?
It is a failure that you know may occur and can handle.
Expected error: File not found Expected error: Invalid user input Expected error: Website is not responding
Unexpected error: Out of memory Unexpected error: My window handle is no longer valid Unexpected error: A core component is missing
You're probably using goto's where you should be using a simple if().
I'm probably not. My use of gotos is typically restricted to ensuring that methods hit a common exit point. Until someone shows me a better way of handling the "if failure cleanup & return" pattern, I will continue using them for it.
Objects may get destroyed when they go out of context (which also happens when you just return from the method), but non-stack allocated resources are not cleaned up. Exceptions handle that pattern about as well as the if failed cleanup pattern ("if (failed) { cleanup operations; return; }"), which is to say, poorly.
You are also assuming that information carryover is necessary or useful (which it isn't for a function which returns no result and is stuck catching exceptions it threw itself).
Finally, you are ignoring the performance implications of throwing exceptions like crazy in C++ code.
Jumping out of nested loops has its pros and cons. If your loops have a significant amount of code dedicated to managing when break should be called, odds are using a goto to jump out of it will not hurt perf much and it will aide maintainability. Again, I'm not advocating its use in all situations, just the appropraite ones.
I deal primarily with C++ on a day-to-day basis. I try to stay current with the various languages that exist, so I can speak with some intelligence about other languages and make appropriate decisions regarding what language to use when starting a new project.
I agree with your next two paragraphs regarding the use of exceptions in both Java and C++. Java's implementation of exception handling does not typically involve generating an interrupt, which makes it far more acceptable to use than in C++. Java's implementation of exceptions has its own set of drawbacks which I won't get into because it isn't relevent to our discussion here.
I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.
The logic behind this: If there isn't enough ram to perform an allocation, what makes you think there is enough to allocate for an exception? If the exception can fit in ram, great, you can handle the condition gracefully. If it can't, you would never get an opportunity to handle it gracefully. If you try to handle it both ways (throw if you can, return NULL if you can't) you just made your code twice as complicated for no reason.
Me: While anything allocated on the stack will be destroyed when an exception is thrown You: C++ exception handling was specifically designed to make this not true.
I think you inserted a "not" while reading.
Yes, you do, by design.
You only get the opportuntity to clean up if you catch the exception. Terminating your method by throwing an exception does not give you the opportunity to clean up after the error condition. While you can catch the exception in your method, cleanup, and then re-throw, you end up with the problem you 'solve' by eliminating the 'goto cleanup' in the first place.
What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.
SEH (differentiated from the normal kind of exception handling provided by most C++ compilers) doesn't call the destructors of any objects allocated on the stack.
Exceptions in C++ are for handling serious machine failures, not software errors
Agreed. My arguement was that C++ exceptions should not be used to control a functions exit or to guarantee cleanup of allocated resources, so I think we are pretty much in agreement.
There is a difference between 'normal' C++ exception handling and structured exception handling (SEH). SEH is lower level than what you typically see with C++, and doesn't give you all of the niceties that C++ lops of top of it.
You should do some research of your own before claiming that I don't know what I"m talking about.
void MyFunction() {
char *szString = new char[25];// do something
if (somethingfailed)
return;// do something else
delete [] szString; }
szString leaks.
Now, that can be modified as follows:
void MyFunction() {
char *szString = new char[25];// do something
if (somethingfailed)
{
delete [] szString;
return;
}// do something else
delete [] szString; }
Now imagine you've got 20 "somethingfailed" type conditions in your method. Now imagine that the cleanup code is non-trivial. And then imagine you need to make a change in that cleanup code... This gets ugly very fast.
There are lots of ways to 'work around' this sort of problem. All of them, IMO, are unacceptable for various reasons. Either they perform poorly, are hard to maintain, can have unobvious side effects, don't work in all but simple cases, or are obtuse (ie: result in WTF comments from people trying to figure out what is happening).
The cost of "throwing" an exception includes the cost of handling it. This includes object construction, generating a software interrupt, switching to OS code, unwinding the stack, and the various calls used to determine if there is a handler present which can handle the exception at the current stack level (which may or may not contain a trivial amount of code; it is the equivelent of a function call for each catch statement you may have, with a lot of logic thrown on top of it to convert the data made available with the exception into the form your C++ code expects).
There is no way in hell that takes 8-10 cycles. Most likely you're measuring the number of cycles taken by the instructions used to generate the exception, which would include allocating the exception object and an instruction to generate the interupt.
I'm not even considering the overhead imposed by registering/unregistering exception handlers for various blocks...
As I said, used sparingly and correctly, they are a good thing. Used to ensure an exit block is hit in a method before returning, they are very readable and compiler optimization is uneffected. Typically, when not used to perform iterative actions gotos do not effect compiler optimizations which is why I said I get concerned if I see it jump up in the code. Very rarely will I accept code with a goto that doesn't jump to an error handler, as other constructs are better suited to the task the programmer is trying to accomplish.
Exceptions are appropriate for error handling when you encounter an error you can't handle, or for when a deep stack of nested calls needs to be cancelled out to some root level.
They are not appropriate (with they way they are implemented in C++) for handling common expected errors or for making code inside of a method more 'tidy'. The cost of throwing and handling exceptions is gigantic (it starts off by generating an interrupt, to give you a bit of an idea). Pure virtual function calls are cheap in comparison.
They described a different way to do something that has been done for decades. This allows you to compare and contrast the traditonal way of doing it to the AOP way of doing it.
What kind of crack are you smoking? If it doesn't support a C64 it is unreasonable? If I can't use it with an old IBM mainframe it is unreasonable? If their code examples don't compile and my old Atari ST it is unreasonable?
You just described a standard where optional extras can be added to the format. When you're dealing with things like photographs, very little is 'optional' -- most of it is required to correctly render the image. Your standard is worthless in this case, and is still poses the same problems I just described.
Technology being used in digital cameras these days is not static. It is evolving rapidly. Any 'standard' you come up with to represent unprocessed data will restrict development of that technology.
I use RAII to free resources in a deterministic order all the time. You might not have total control, you still have a lot of control. And if you really need total you control you can just handcode it.
And in the process your code just got a lot more complicated. Because now you use RAII in some places, and hand coding in other places. It gets worse if you do both in the same function, as then there is a large amount of confusion about when, where, and how certain resources are being removed. And don't get me started about what happens when someone manually cleans up RAII objects to enforce ordering, which tends to confuse the living hell out of people (ie: code maintainability and clarity is reduced).
Something else that hasn't been mentioned is side effects of RAII objects can sometimes be non-obvious. People tend to get used to treating them as the primitive types that they are, when really they are a wrapper class for a primative type. Sometimes the operations performed on that primative type have a non-obvious side effect, which leads to 'mysterious' bugs that people spend hours tracking down.
A good example of this is using RAII to manage a BSTR type. If you pass the RAII object into some method and a copy constructor is called to clone the object, you start off ok. The problem is once that method completes, the destructor on the RAII object is called. This calls a system method that overwrites the last error result, which was just set by the method you called. So your code ends up reporting a failure of ERROR_SUCCESS because you used an RAII type. This type of problem isn't limited to RAII types, but it is most unexpected with this sort of type due to the expectations of a person using it.
There are other variations of this problem involved with trashing the results of method calls you can make (imagine your function has a BSTR RAII type in it, and you set the last error information before you return; the destructor for that RAII type will trash your last error result).
When resources are interdependent than this should reflect in the design: they probably should be released in the same destructor.
Once you exceed a certain level of functionality, you're not using RAII -- you're writing a class framework. While I'm not opposed to writing class frameworks to wrap complicated functionality and represent it in a simple fashion, I am opposed to writing class frameworks to manage simple operations.
Eh...tomatoe, tomato...:p You're right; I get the two terms mixed up occasionally -- it isn't a problem in my head because the concept I'm thinking of is correct, though it can be confusing for anyone trying to make sense of what I'm saying...
This is actually the first I've heard of it. It is actually rather intriging, as it would seem to be an interesting solution to a problem I've been recently trying to cope with -- relating to keeping elements of a user interface in sync with what is happening among several objects inside the software.
Right now there is a mess of calls inside the core of the software the twiddles elements of the UI where appropriate. It is a maintenance nightmare.
Thus far my focus has been isolating the interaction between the core components and the UI to a simple event/notification-like interface, paired with some simple 'decision/permission' state objects. That doesn't sound too far off from what AOP does under the hood...
As the goto statement does not exist in Java, it is a given that we're talking about C++.
While anything allocated on the stack will be destroyed when an exception is thrown, any resources allocated during execution will leak (ex: handles or memory allocated on the heap). As the data on the stack is deallocated (the very items which were referencing the afore mentioned resources), you never get an opportunity to clean up after the error condition. To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.
Not to mention the complications that arise when SEH is thrown into the mix (destructors are never called on objects allocated within an SEH block)...
Obviously you can write code to work around that. However, it is far more complicated and error prone than ensuring that the flow of execution always hits the end of the method.
Then, there is the overhead of actually throwing an exception... making a pure virtual function call is cheap in comparison.
Gotos in C++ are limited to the same method, so no stack problems there.
Exceptions incur an obscene performance hit, and should be used for 'exceptional' conditions and not expected/handled errors. You also have to worry about the case where someone else adds another exception handler that inadvertantly 'catches' your thrown exception (which makes for maintainance problems later down the road).
The goto operation can be rather useful if used sparingly and correctly. If I see a goto jump up (earlier in the function) instead of down, I tend to get worried. But it is useful to break out of nested loops or complicated logic statements.
It is also exceedingly useful for error handling, in that it allows you to skip the bulk of a function and still hit the cleanup section of the function. This gives you two things: 1) you avoid a deep, deep mess of nested if statements 2) you eliminate duplication of code in error handlers (and the bugs that occur later on when someone forgot to update one of those handlers to release some resource they just added)
It's an example, geeze. It is obviously going to be contrived and simple so that someone unfamiliar with the concepts being demonstrated will be able to understand it.
Slashdot Mirror
The "market" was defined as "operating systems for x86 compatible computers", which restricted the market in a manner that excluded Apple from the calculation.
Local variables, when not placed in registers can be allocated on a stack, even in a basic block inside of a function, hence the goto can jump into another stack frame because many of them can exist inside of a single method.
Compilers handle this correctly.
btw: An expected error? What?
It is a failure that you know may occur and can handle.
Expected error: File not found
Expected error: Invalid user input
Expected error: Website is not responding
Unexpected error: Out of memory
Unexpected error: My window handle is no longer valid
Unexpected error: A core component is missing
You're probably using goto's where you should be using a simple if().
I'm probably not. My use of gotos is typically restricted to ensuring that methods hit a common exit point. Until someone shows me a better way of handling the "if failure cleanup & return" pattern, I will continue using them for it.
Objects may get destroyed when they go out of context (which also happens when you just return from the method), but non-stack allocated resources are not cleaned up. Exceptions handle that pattern about as well as the if failed cleanup pattern ("if (failed) { cleanup operations; return; }"), which is to say, poorly.
You are also assuming that information carryover is necessary or useful (which it isn't for a function which returns no result and is stuck catching exceptions it threw itself).
Finally, you are ignoring the performance implications of throwing exceptions like crazy in C++ code.
Jumping out of nested loops has its pros and cons. If your loops have a significant amount of code dedicated to managing when break should be called, odds are using a goto to jump out of it will not hurt perf much and it will aide maintainability. Again, I'm not advocating its use in all situations, just the appropraite ones.
This statement is wrong in nearly every aspect.
The C standard defines the size of short, int and long as:
sizeof (short) = sizeof (int) = sizeof (long)
At no point is an explicit size defined/fixed.
Resources include things other than money.
Throwing a billion dollars at the problem doesn't do you any good if your lobbyists can't get any more time face time with senators.
I presume that Java is your home language?
I deal primarily with C++ on a day-to-day basis. I try to stay current with the various languages that exist, so I can speak with some intelligence about other languages and make appropriate decisions regarding what language to use when starting a new project.
I agree with your next two paragraphs regarding the use of exceptions in both Java and C++. Java's implementation of exception handling does not typically involve generating an interrupt, which makes it far more acceptable to use than in C++. Java's implementation of exceptions has its own set of drawbacks which I won't get into because it isn't relevent to our discussion here.
I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.
The logic behind this: If there isn't enough ram to perform an allocation, what makes you think there is enough to allocate for an exception? If the exception can fit in ram, great, you can handle the condition gracefully. If it can't, you would never get an opportunity to handle it gracefully. If you try to handle it both ways (throw if you can, return NULL if you can't) you just made your code twice as complicated for no reason.
Me: While anything allocated on the stack will be destroyed when an exception is thrown
You: C++ exception handling was specifically designed to make this not true.
I think you inserted a "not" while reading.
Yes, you do, by design.
You only get the opportuntity to clean up if you catch the exception. Terminating your method by throwing an exception does not give you the opportunity to clean up after the error condition. While you can catch the exception in your method, cleanup, and then re-throw, you end up with the problem you 'solve' by eliminating the 'goto cleanup' in the first place.
What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.
SEH (differentiated from the normal kind of exception handling provided by most C++ compilers) doesn't call the destructors of any objects allocated on the stack.
Exceptions in C++ are for handling serious machine failures, not software errors
Agreed. My arguement was that C++ exceptions should not be used to control a functions exit or to guarantee cleanup of allocated resources, so I think we are pretty much in agreement.
There is a difference between 'normal' C++ exception handling and structured exception handling (SEH). SEH is lower level than what you typically see with C++, and doesn't give you all of the niceties that C++ lops of top of it.
You should do some research of your own before claiming that I don't know what I"m talking about.
Here is what happens in your scenario:
// do something
// do something else
// do something
// do something else
void MyFunction()
{
char *szString = new char[25];
if (somethingfailed)
return;
delete [] szString;
}
szString leaks.
Now, that can be modified as follows:
void MyFunction()
{
char *szString = new char[25];
if (somethingfailed)
{
delete [] szString;
return;
}
delete [] szString;
}
Now imagine you've got 20 "somethingfailed" type conditions in your method. Now imagine that the cleanup code is non-trivial. And then imagine you need to make a change in that cleanup code... This gets ugly very fast.
There are lots of ways to 'work around' this sort of problem. All of them, IMO, are unacceptable for various reasons. Either they perform poorly, are hard to maintain, can have unobvious side effects, don't work in all but simple cases, or are obtuse (ie: result in WTF comments from people trying to figure out what is happening).
The cost of "throwing" an exception includes the cost of handling it. This includes object construction, generating a software interrupt, switching to OS code, unwinding the stack, and the various calls used to determine if there is a handler present which can handle the exception at the current stack level (which may or may not contain a trivial amount of code; it is the equivelent of a function call for each catch statement you may have, with a lot of logic thrown on top of it to convert the data made available with the exception into the form your C++ code expects).
...
There is no way in hell that takes 8-10 cycles. Most likely you're measuring the number of cycles taken by the instructions used to generate the exception, which would include allocating the exception object and an instruction to generate the interupt.
I'm not even considering the overhead imposed by registering/unregistering exception handlers for various blocks
As I said, used sparingly and correctly, they are a good thing. Used to ensure an exit block is hit in a method before returning, they are very readable and compiler optimization is uneffected. Typically, when not used to perform iterative actions gotos do not effect compiler optimizations which is why I said I get concerned if I see it jump up in the code. Very rarely will I accept code with a goto that doesn't jump to an error handler, as other constructs are better suited to the task the programmer is trying to accomplish.
Exceptions are appropriate for error handling when you encounter an error you can't handle, or for when a deep stack of nested calls needs to be cancelled out to some root level.
They are not appropriate (with they way they are implemented in C++) for handling common expected errors or for making code inside of a method more 'tidy'. The cost of throwing and handling exceptions is gigantic (it starts off by generating an interrupt, to give you a bit of an idea). Pure virtual function calls are cheap in comparison.
They described a different way to do something that has been done for decades. This allows you to compare and contrast the traditonal way of doing it to the AOP way of doing it.
What kind of crack are you smoking? If it doesn't support a C64 it is unreasonable? If I can't use it with an old IBM mainframe it is unreasonable? If their code examples don't compile and my old Atari ST it is unreasonable?
Agreed -- which is what I'm trying to point out.
You just described a standard where optional extras can be added to the format. When you're dealing with things like photographs, very little is 'optional' -- most of it is required to correctly render the image. Your standard is worthless in this case, and is still poses the same problems I just described.
Technology being used in digital cameras these days is not static. It is evolving rapidly. Any 'standard' you come up with to represent unprocessed data will restrict development of that technology.
I use RAII to free resources in a deterministic order all the time. You might not have total control, you still have a lot of control. And if you really need total you control you can just handcode it.
And in the process your code just got a lot more complicated. Because now you use RAII in some places, and hand coding in other places. It gets worse if you do both in the same function, as then there is a large amount of confusion about when, where, and how certain resources are being removed. And don't get me started about what happens when someone manually cleans up RAII objects to enforce ordering, which tends to confuse the living hell out of people (ie: code maintainability and clarity is reduced).
Something else that hasn't been mentioned is side effects of RAII objects can sometimes be non-obvious. People tend to get used to treating them as the primitive types that they are, when really they are a wrapper class for a primative type. Sometimes the operations performed on that primative type have a non-obvious side effect, which leads to 'mysterious' bugs that people spend hours tracking down.
A good example of this is using RAII to manage a BSTR type. If you pass the RAII object into some method and a copy constructor is called to clone the object, you start off ok. The problem is once that method completes, the destructor on the RAII object is called. This calls a system method that overwrites the last error result, which was just set by the method you called. So your code ends up reporting a failure of ERROR_SUCCESS because you used an RAII type. This type of problem isn't limited to RAII types, but it is most unexpected with this sort of type due to the expectations of a person using it.
There are other variations of this problem involved with trashing the results of method calls you can make (imagine your function has a BSTR RAII type in it, and you set the last error information before you return; the destructor for that RAII type will trash your last error result).
When resources are interdependent than this should reflect in the design: they probably should be released in the same destructor.
Once you exceed a certain level of functionality, you're not using RAII -- you're writing a class framework. While I'm not opposed to writing class frameworks to wrap complicated functionality and represent it in a simple fashion, I am opposed to writing class frameworks to manage simple operations.
Eh...tomatoe, tomato ... :p You're right; I get the two terms mixed up occasionally -- it isn't a problem in my head because the concept I'm thinking of is correct, though it can be confusing for anyone trying to make sense of what I'm saying...
Complicated as in ... complicated. Not simple. So I suppose both of your comparisons apply.
"goto" is a functional operation. Its use is not OOP related; it modifies the flow of execution through a function.
Thus, AOP is the OOP equivelent of a functional GOTO.
This is actually the first I've heard of it. It is actually rather intriging, as it would seem to be an interesting solution to a problem I've been recently trying to cope with -- relating to keeping elements of a user interface in sync with what is happening among several objects inside the software.
Right now there is a mess of calls inside the core of the software the twiddles elements of the UI where appropriate. It is a maintenance nightmare.
Thus far my focus has been isolating the interaction between the core components and the UI to a simple event/notification-like interface, paired with some simple 'decision/permission' state objects. That doesn't sound too far off from what AOP does under the hood...
The use of RAII breaks down when resources must be freed in a deterministic order, or worse, when resources are interdependent.
As the goto statement does not exist in Java, it is a given that we're talking about C++.
... making a pure virtual function call is cheap in comparison.
While anything allocated on the stack will be destroyed when an exception is thrown, any resources allocated during execution will leak (ex: handles or memory allocated on the heap). As the data on the stack is deallocated (the very items which were referencing the afore mentioned resources), you never get an opportunity to clean up after the error condition. To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.
Not to mention the complications that arise when SEH is thrown into the mix (destructors are never called on objects allocated within an SEH block)...
Obviously you can write code to work around that. However, it is far more complicated and error prone than ensuring that the flow of execution always hits the end of the method.
Then, there is the overhead of actually throwing an exception
You could, if you want hard to read slower code...
Gotos in C++ are limited to the same method, so no stack problems there.
Exceptions incur an obscene performance hit, and should be used for 'exceptional' conditions and not expected/handled errors. You also have to worry about the case where someone else adds another exception handler that inadvertantly 'catches' your thrown exception (which makes for maintainance problems later down the road).
The goto operation can be rather useful if used sparingly and correctly. If I see a goto jump up (earlier in the function) instead of down, I tend to get worried. But it is useful to break out of nested loops or complicated logic statements.
It is also exceedingly useful for error handling, in that it allows you to skip the bulk of a function and still hit the cleanup section of the function. This gives you two things:
1) you avoid a deep, deep mess of nested if statements
2) you eliminate duplication of code in error handlers (and the bugs that occur later on when someone forgot to update one of those handlers to release some resource they just added)
Let's say you've got objects a, b, and c.
Objects a and b do something useful (the core of the application)
Object c (an aspect) wants to perform an operation when something happens in object a (a concern).
Object c (an asepct) also wants to do different things when something happens in object a and b (crosscutting a concern).
I look at this as a really complicated event notification system. Comments calling this 'goto for OOP' also seems rather appropriate.
It's an example, geeze. It is obviously going to be contrived and simple so that someone unfamiliar with the concepts being demonstrated will be able to understand it.