Can C++ programs use C libraries?

Quote:

---

Originally posted by AnthonyMai
OK, let's talk about constructors that would fail. First, you CAN write constructors that would never fail unless catastrophy happens (like some one pulling the power plug or some memory gets over-written). You can postpone resource acquisition to later, after you have constructed the object. Further, even if the constructor can fail, you can report the error using a boolean within the object or even a static variable to indicate the error condition. There is no need to throw an exception.

---

I will not reply to this one since Sef already provided more than enough information of the drawbacks of these solutions...

Quote:

---

Originally posted by AnthonyMai
Let's step back one step, let's say your constructor fails, and you do throw an exception. The question is WHO WILL catch the exception? Let's say you have a global instance of that object. Upon program loading, the constructor of that object gets called and it throws an exception. But it hasn't even started the main() function yet. So even if you have a big try/catch in the main(), you will still not be able to catch the exception!!!

---

First of all...I could reply:

Let's say a constructor sets a boolean flag inside the class. The question is WHO WILL check this flag?

Second thing...global instances. There is nearly no need to define global instances in an object-oriented design...nevertheless I agree that this case would be inappropriate but that is one typical thing of your discussions...just because one case does not work - DOES NOT - mean that the whole thing is bad in general...

Quote:

---

Originally posted by AnthonyMai
I know about the RAII concept. Some one likes it. But I think it is a BAD idea. It mixes three things together: 1.Construction of an object. 2.Acquire resources that the object will be using. 3.Initialize the resource acquired. RAII attempts to do all three things at once.

The reality is you rarely want the three things to happen spontaneously. You may want to construct an object but postpone resource acquisition until when it is actually used.
You may re-acquire new resources or release old ones during the lifetime of an object, without destorying and reconstructing the object. Also, many times you do not want to initialize resource right upon acquisition, or simply is unable to initialize it yet at the moment of acquisition. So, object construction, resource acquisition, resource initialization. These three things rarely happen at the same time. RAII is an ill-formed idea that doesn't fit in the real world.

---

Sorry...but this clearly shows that you did not understand the concept...

Anyway...I knew that this would happen and I will stop right here. We are already off-topic and I will not be part of another one of your endless discussions...

Quote:

---

Because Anthony says so? What about constructors that can possibly fail. Shall we set an error flag in the constructor and hope users check it. Or should we write an "Init()" function instead and hope users call it. And in either case, then what? Have all member functions check an "Init" flag to ensure the object was properly constructed?

---

It is the class auther's responsibility to properly document the usage sequence of the class and make sure the class behaves correctly when used properly. And it is the class user's responsibility to make sure it is constructed and used in the correct way, including remembering to call the Init() function.

In the case where the caller forget to call Init(), IT is a programming BUG and that we know programs with BUGs does NOT work and it does not work and it still does not work, no matter what you do. Only when the programmer identifies the problem, and put in the Init(), will it starts to work.

So I don't understand your above argument. If a program doesn't work because of a bug, it just doesn't work no matter what you do, until the correct bug is identified and fixed. Does throwing an exception help to get things working and turning around error conditions? NO!!!

If you as the user, knows that an object could fail to be constructed, or it is constructed but is not properly initialized to be used. Then it is YOUR responsibility to check to make sure the object is OK, before using it. If you don't check, and there is an error condition, then it is a bug that you should be held responsible for it.

Quote:

---

And none of this even addresses the benefits of exceptions over return codes, not the least of which is the ability to return rich error information. Or how about the countless if/else clauses required of return codes.

---

The question is WHO NEEDS those rich erro information. If I am the application level code 20 layers above the code where an exception is throw because of some sort of "write back cache parity error at cylinder 2003 sector 03", or some other low level techie terminology. WHY should I need to know what it is? And how do you suppose I interpret that "rich error information"? And also how would you expect me to display such an error message, to an end user who is completely computer illiterate and have no idea what it says or whether it is English or not?

The "rich error information" argument is a very weak one. The only layer that hopefully can understand the error from a lower level code is the layer that is right above it. If you propagate it 20 levels up, then they are speaking a totally different language. This is exactly the reason why level-to-level error code return and interpretation is prefered, rather than throwing an exception all the way from low level to the topmost level.

Quote:

---

Let's say my top-level function invokes a series of other functions where the only failure may occur due to a disk write when I'm 20 functions deep. In your scenario there will if/else clauses pulluting the code all the way down the call stack. Every function will have a return code that gets propagated all the way to the top (complicating some functions as well, since some will then have to designate an extra out argument because the return code itself is reserved for success or failure). The top-level function finally gets notified and pops up a message for the user (and what will the message say because only a return code is available - I may want to see the exact args at the point of failure). Using exceptions however, you can set up just one try/catch in the top-level function only. Now no return code is required for trapping success or failure and each function can either be void or use the return code for some other purpose as required.

---

If you know a function could potentially fail, then you have the responsibility of detecting and properly handling the error. Refusing to handling the error code or even make the function call a void function, and let the error that could be well handled and totally recoverable propagate to higher level and become one that is unrecoverable. I guess that is not the right thing to do in programming. My philosophy is try to handle the error and try to recover at every level, and only when you can't recover at your level will you be allowed to propagate the error one level up.

I guess that is also the HR policy of most big organizations. If you have a problem, talk to your direct supervisor first. If he can't hndle it, then you can go up one level to seek a solution. You don't skip your supervisor and directly go to the company CEO like you do in throwing an exception, right?

Quote:

---

Now when the bottom function encounters the error, it simply throws an exception with complete failure info if desired, unlike in the return code case (without resorting to other methods). This is then automatically trapped at the top level function, with RAII automtatically cleaning up things along the way. No checking of return codes or even other try/catch blocks are required *anywhere* except the top-level function. Very clean. Very simple.

---

It is very clean and simple, but not very useful. If you used the level-by-level erro code return mechanism, the error condition could have been recovered and the program continues to run. But now you throw an exception to top level which can do nothing but terminate with a strange messagebox. What's the usage of the lowest level error information, to the topmost level? What can the top level do? It's useless!!!

And, are you trying to tell me that you are treating your end users as your QA testers without pay?

Quote:

---

Originally posted by AnthonyMai
OK, let's talk about constructors that would fail. First, you CAN write constructors that would never fail unless catastrophy happens (like some one pulling the power plug or some memory gets over-written). You can postpone resource acquisition to later, after you have constructed the object. Further, even if the constructor can fail, you can report the error using a boolean within the object or even a static variable to indicate the error condition. There is no need to throw an exception.

---

No. If the ctor fails the object is not created, yet. It does not begin its lifetime until until a successful ctor termination. You may want to read Herb Sutter's "Exceptional C++" and "More Exceptional C++" to learn about object lifetime and failing ctors.

Quote:

---

Let's step back one step, let's say your constructor fails, and you do throw an exception. The question is WHO WILL catch the exception? Let's say you have a global instance of that object. Upon program loading, the constructor of that object gets called and it throws an exception. But it hasn't even started the main() function yet. So even if you have a big try/catch in the main(), you will still not be able to catch the exception!!!

---

If your ptogram is not able to construct a global object then it is very likely not to work at all -- exception caught or not. So a call to exit() is the right thing to do. Don't use a global object if you want to be able to catch exceptions from its ctor.

Quote:

---

I know about the RAII concept. Some one likes it. But I think it is a BAD idea. It mixes three things together: 1.Construction of an object. 2.Acquire resources that the object will be using. 3.Initialize the resource acquired. RAII attempts to do all three things at once.

The reality is you rarely want the three things to happen spontaneously. You may want to construct an object but postpone resource acquisition until when it is actually used.
You may re-acquire new resources or release old ones during the lifetime of an object, without destorying and reconstructing the object. Also, many times you do not want to initialize resource right upon acquisition, or simply is unable to initialize it yet at the moment of acquisition. So, object construction, resource acquisition, resource initialization. These three things rarely happen at the same time. RAII is an ill-formed idea that doesn't fit in the real world.

---

RAII is in most cases not avoidable if you want to write code that suffices the strong exception specification -- that is a commit or rollback specification. Even for the weak exception spec, RAII can massively help leaving the program in a consistent state in case of an exception.

As this tends to become an "Anthony against the rest of the world" discussion (again!), I sugest we stop here.

Quote:

---

Originally posted by AnthonyMai
If you as the user, knows that an object could fail to be constructed, or it is constructed but is not properly initialized to be used. Then it is YOUR responsibility to check to make sure the object is OK, before using it. If you don't check, and there is an error condition, then it is a bug that you should be held responsible for it.

---

And this actually is exactly one of the arguments for using exceptions for constructors... :cool:

Quote:

---

If you as the user, knows that an object could fail to be constructed, or it is constructed but is not properly initialized to be used. Then it is YOUR responsibility to check to make sure the object is OK, before using it. If you don't check, and there is an error condition, then it is a bug that you should be held responsible for it.

---

You're completely missing the point that doing things this way is possible but has severe drawbacks compared to exceptions (discussed ad nauseam already). Furthermore, please explain how to handle a copy constructor and copy assignment operator that can fail. Do you check for an error condition after each assignment for instance? And how do you handle this without a lot of ugly overhead. And what about when it's implicitly called by the compiler. Or if it's being used with a standard library collection, where objects *must* be copy constructible, then what? Since you yourself once claimed that you've "NEVER thrown any exception in my career", then I guess you've never written a class that manages resources or can otherwise fail. If you have then either you're privatizing your copy constructor and copy assignment operator in all such cases (right), or you're having each member function check to see if the class was properly initialized and/or assigned (brutal and if so, then what do you do about it if the object is being managed by a collection), or finally, you yourself are writing code that can fail but aren't doing anything about it (probably). So I guess that "you should be held responsible for it".

Anthony, the reality is that your arguments are incredibly weak and mostly non-existent. In fact, they frequently demonstrate that you either don't understand the issues or you're just incredibly stubborn and can't acknowledge the truth (a mixture of both actually). You don't even address some very important issues like "exception specifications" which completely obliterates your argument that nobody knows who will be catching an exception. I don't believe you were even aware of these before but now you are so you're caught in your own ignorance of the subject and won't even address it. You also point out trivial examples of when something won't work and then claim the whole thing is garbage and should never be used altogether (globals are your strongest argument? come on). And then you continously rant that top-level functions won't know what to do with an error that occurred way down the call stack when all they want to do is *report* it (say, using a virtual "CreateErrorMsg()" function that generates a string from the details). Rich error information may just consist of a string in fact. And for *most* apps, a critical error need only be dealt with by reporting and/or logging it so there's no need to try to recover at the point where it occurs (nor is it possible in many cases). As for the message itself, who are you to say how technical it must be or who will even be looking at it. It can be technical if it's for technical eyes only, or for non-technical users, can consist of a user-friendly message only. The technical details themselves can then be logged somewhere and the proper people can later diagnose it. Why do you keep arguing such asinine points. There is no point debating this at all anymore. You're incapable of dealing with facts.

I said:

Quote:

---

If you as the user, knows that an object could fail to be constructed, or it is constructed but is not properly initialized to be used. Then it is YOUR responsibility to check to make sure the object is OK, before using it. If you don't check, and there is an error condition, then it is a bug that you should be held responsible for it.

---

And Sef said:

Quote:

---

You're completely missing the point that doing things this way is possible but has severe drawbacks compared to exceptions (discussed ad nauseam already).

---

What severe drawback? Is it harder to check one single error return code versus catch one single exception? I don't think so.
Given a choice, do you prefer to write 100 error code checking, or would you rather write 100 try/catch instead?

OK, maybe you don't need to replace each and every return code check with a try/catch. Maybe you can use just one try/catch in the main() program? But it is NOT the same thing. Where when I check all 100 return code, I am handling all error conditions properly and I can always recover from any error that is recoverable, and exit gracefully when I can't. But when you use exception, you could be forced to terminate the whole program when an error that could have been recoverable triggers an exception.

Better yet, just write no try/catch at all. It's easier, you thrown an exception and the OS will catch it for you, right? It makes no difference whether you terminate on your own or the OS terminates you, when you can't recover.

Look, I know having to handle all error conditions at all levels is tedious. But there is no way around it. Either you handle it right at the spot, or you let the top level or even the OS to handle your error. The difference is when I do it in low level I can handle it nicely and recover gracefully, when it escalate to the top level, you have no choice but terminate the whole thing.

Quote:

---

Furthermore, please explain how to handle a copy constructor and copy assignment operator that can fail. Do you check for an error condition after each assignment for instance? And how do you handle this without a lot of ugly overhead. And what about when it's implicitly called by the compiler. Or if it's being used with a standard library collection, where objects *must* be copy constructible, then what?

---

Here is my answer: Just do NOT write a copy constructor, copy assignment operator, or an operator, or a void function, or something else that does not have a way of telling its caller about the error condition, ever, at all. Don't do it! If you know a function could fail, then don't make it a void function. If you know an operation can fail, don't make it an operator, implement it as a regular function with an error return code.

That doesn't mean you can never write a copy constructor or operator. In most cases, you can probably be pretty sure it simply will never fail. For example, copying an integer object to another integer object, will it ever fail?

In other cases it may fail, but the odd is too small, or it is not important whether it fail or not, then no body says you still need the overhead to check the error condition.

You WILL need the "ugly overhead" to check error conditions, if it is a case where it may fail, and it is important to handle failure properly. In such case, you HAVE to handle it. Either you handle it right at the spot where you have the best knowledge to handle it gracefully, or you let the top level or even the OS to handle it in a not-so-graceful way, i.e., forceful termination of the program.

I would prefer to have "ugly overhead".

Here is a question for you, with a, b, c all integers, calculate:
a = b * c;
You know it could fail to get correct result some times (overflow). How do you prefer to handle error condition in this case?

1. It should throw an exception, and I will write a try/catch around every code line like a = b*c;

2.It should throw an exception and I will let the top level code catch it and terminate the program.

3.It's just one none-critical error and I will let the error pass without doing anything.

4.It's a critical error and I will check the value of b and c before hand to make sure it doesn't happen.

Would you rather prefer to see a = b*c throws an exception? Or would you rather prefere 3 and 4 above?

Quote:

---

Since you yourself once claimed that you've "NEVER thrown any exception in my career", then I guess you've never written a class that manages resources or can otherwise fail. If you have then either you're privatizing your copy constructor and copy assignment operator in all such cases (right), or you're having each member function check to see if the class was properly initialized and/or assigned (brutal and if so, then what do you do about it if the object is being managed by a collection), or finally, you yourself are writing code that can fail but aren't doing anything about it (probably). So I guess that "you should be held responsible for it".

---

I explained it already. I have never thrown a single exception in my programming career, though for numerous times I was forced to write code to catch exceptions thrown by others, which I hate.
And I do have to write classes that needs to handle all sorts of error conditions all the time, like a class that fails to open a socket, a class that fails to parse a string due to the corrupted format, a class that fails to open an audio device because it was used already, etc. etc. But I never have to throw an exception, ever!

If you always put tasks that could fail into a regular function which returns error conditions, and always check error conditions where ever appropriate, then I don't see a need for throwing exceptions.

To sum up, just NEVER EVER write fail-able tasks into something where it is unable to report the error. Never write a constructor, operator, copy constructor or void function in a way that can fail. Use a regular function instead, and separate the fail-able portion of the constructor into a separate initialization function.

Sef:
Just one quick easy question for you. If your project gives an "unhandled exception error". Who, within your team of 100+ person who work at 20 different coding levels, would you be talking to, regarding the exception that is thrown but no one catches it? Who do you blame?

Ok, I think we all know where eachother stand now.... Let's remember, this is a forum, not a boxing ring!

Quote:

---

Look, I know having to handle all error conditions at all levels is tedious. But there is no way around it.

---

Yeah there is - you can use C++ exceptions.

There is no universally accepted rule to never use exceptions.

There is no universally accepted rule to always use exceptions.

A good programmer evaluates the tools at hand (exceptions, STL, etc.) within the context of the problem they wish to solve, and uses those tools accordingly.

Regards,
Bassman

P.S.

Quote:

---

Who, within your team of 100+ person who work at 20 different coding levels, would you be talking to, regarding the exception that is thrown but no one catches it? Who do you blame?

---

Tvor. (Simpsons reference) :p

Without getting into the good vs. bad of exceptions directly...

There is one key difference between using a return value for errors and throwing an exception..

When using a return value is it possible for the user of the code to ignore the value and continue processing without taking any corrective action

Exceptions force the user to address address the situation explicitly, or the program will exit (the OS catching the exception).

Therefore I believe that the decision to use exceptions or return codes is highly dependant on what you require of users of the code (even if it is just yourself!).

About 18 months ago, as part of a research project, I did a (automated) code crawl through one of the largest open source sites on the net. Scanning just for WIN32 API calls, I monitored the number of times that the return values were actually checked. The result was that less than 15% of the system calls had their return values checked.

This test was simply done by looking to see if the call was within a conditional statement or had its return value assigned to a variable. No further testing was done to see if the program actually took any action on the value.

At my firm, we have taken the opposite approach and wrapped all Win32API calls (and most other 3rd party libraries) inside of tight in-line classes that convert error codes to exceptions. This forces our users (typically one of our own developers) to address the issue in an appropriate fashion. A nice side effect was that it provided a convient way to inject errors for the QA department...

Quote:

---

If you know a function could fail, then don't make it a void function. If you know an operation can fail, don't make it an operator, implement it as a regular function with an error return code.

---

Which goes against practically every C++ math, matrix, and linear algebra library that has ever been created. Examples (and these are just some examples -- I could have gone on and on, but there is a character limit to posts on CodeGuru):

http://www.techsoftpl.com/matrix/
http://www.netwood.net/~edwin/svmtl/#proposal
http://www.osl.iu.edu/research/mtl/
http://www.robertnz.net/nm10.htm
http://gama.fsv.cvut.cz/~cepek/gmatvec-doc/html/

And just for the heck of it, your favorite -- templates:

http://www.oonumerics.org/blitz/manual/

Now you show me a C++ math library that doesn't use exception handling or overloaded operators. Whatever it is, I can bet double or nothing it started out as a 'C' library and the author(s) wanted to be "cool" and created a C++ class, thinking they were "in with the 90's and OOP programming", but the class really does nothing special "C++"-wise.

Let's cut to the chase and get to the bottom line -- it's obvious to anyone here that you are comfortable with 'C' and 'C' techniques (even if they violate the ANSI C++ standard) to solving problems. At least admit this, so that next time, we all know where you're coming from.

Regards,

Paul McKenzie

Quote:

---

quote:
--------------------------------------------------------------------------------
If you know a function could fail, then don't make it a void function. If you know an operation can fail, don't make it an operator, implement it as a regular function with an error return code.
--------------------------------------------------------------------------------

Which goes against practically every C++ math, matrix, and linear algebra library that has ever been created. Examples (and these are just some examples -- I could have gone on and on, but there is a character limit to posts on CodeGuru):

...

And just for the heck of it, your favorite -- templates:

http://www.oonumerics.org/blitz/manual/

Now you show me a C++ math library that doesn't use exception handling or overloaded operators. Whatever it is, I can bet double or nothing it started out as a 'C' library and the author(s) wanted to be "cool" and created a C++ class, thinking they were "in with the 90's and OOP programming", but the class really does nothing special "C++"-wise.

---

Did I ever say "NEVER use operators" or any thing to that effect? I did NOT. All I am saying is if it is an operator, it should never fail. If it should ever possibly fail, then it should not be an operator, but be implemented as regular function instead.

Now, about math libraries. From a pure mathematics point of view, virtually ALL mathematics problems occured in the engineering world ARE ALWAYS computable and can be carried out WITHOUT an error. You take a 3x3 matrix and multiply it by another 3x3 matrix, you always gets a 3x3 matrix back. Can you give me one example, mathematically, that a 3x3 matrix multiplied by a 3x3 matrix does not yield a 3x3 matrix?

Well in the engineering world, overflow is possible due to limited word length. Still, such anormality would be handled by a CPU generated exception, NOT a C++ exception. Do you ever see a piece of C++ code that checks the value of a and b, and throw an exception if a and b is too big, before carrying out the calculation c = a*b? You don't do that.

Personally I have no objection to usage of operators at all. In one of my projects I used operators extensively to carry out modula mathematics in a piece of encryption related code. Did any of my operator throw an exception? No. Could error ever occur in one of my operators? No. It's pure math so there is not a possibility at all that any of my operator could ever yield an error condition.

There are certain things in the computing world that is virtually guaranteed to always work and never fail. You can always XOR two numbers without checking to make sure it works. You can always add two numbers without worrying about a CPU exception being thrown. You can always multiply two prime numbers of 512 bits and expect the end result to be no more than 1024 bits without error. It is because we have certain elements in computer code that we know always guarantee to work, that programming becomes possible. If that is not true, if every single line of computer code could potentially trigger an exception, including code that throw and catch exceptions, then there is no way of writting computer programs that would work.

And math functions happen to be one of such things.

Quote:

---

There are certain things in the computing world that is virtually guaranteed to always work and never fail. ...
And math functions happen to be one of such things.

---

What is the square root of negative five?

What is log(-1)?

What is tan(90 degrees)?

... were you joking?

Regards,
Bassman

Ever hear of divide by zero errors?

Quote:

---

There is one key difference between using a return value for errors and throwing an exception..

When using a return value is it possible for the user of the code to ignore the value and continue processing without taking any corrective action

Exceptions force the user to address address the situation explicitly, or the program will exit (the OS catching the exception).

---

You are wrong. It is exactly the opposite. If the function I call throws an exception and I did not catch it, you can't blame me. I can turn around and blame the top level programmer for not catch all exceptions thrown 20 levels down under. On the other hand, if the function I call returns an error code, the responsibility of handling the error squarely lays on my shoulder. If I don't handle the error where I should. I can not turn around
and blame Joe.

It's one of the problem with C++ exceptions: The standard leaves it OPTIONAL for any of the upper level code to either catch it or let it propagate further up. So who carries the responsibility of handling the error becomes unclear.

Quote:

---

Therefore I believe that the decision to use exceptions or return codes is highly dependant on what you require of users of the code (even if it is just yourself!).

About 18 months ago, as part of a research project, I did a (automated) code crawl through one of the largest open source sites on the net. Scanning just for WIN32 API calls, I monitored the number of times that the return values were actually checked. The result was that less than 15% of the system calls had their return values checked.

---

If you are to do a statistics of what percentage of code would try to catch an exception right where it occurs, instead of let it propagate several levels up, you would find that the ratio is far below 15%.

Now to defend the 15% figure, while function implementers should ALWAYS return error code where ever failures are possible, function caller are NOT required to always check for errors. In lots of cases, they don't need to check because when operations of previous code lines succeed, then they know by logic that the next function call will surely succeed. In other cases, the error is a none-critical one and can be safely ignored. In still other cases, there is no need to handle the error at all, for example I am exiting the program and I try to release some memory but it fails. What can I do? Hang there indefinitely, or just ignore it and quit anyway?

Considering all those scenaries where error checking is deemed un-necessary, I think the 15% figure is pretty good.

Quote:

---

This test was simply done by looking to see if the call was within a conditional statement or had its return value assigned to a variable. No further testing was done to see if the program actually took any action on the value.

At my firm, we have taken the opposite approach and wrapped all Win32API calls (and most other 3rd party libraries) inside of tight in-line classes that convert error codes to exceptions. This forces our users (typically one of our own developers) to address the issue in an appropriate fashion. A nice side effect was that it provided a convient way to inject errors for the QA department...

---

I thought ASSERT is the tool for debugging and a finished product should not contain stuff that benefits only the debugging. It is just un-ethical to turn the end users machine into your own QA test machine. And end users normally doesn't co-operate.

Also keep in mind, programs that contain exception handling code are generally CONSIDERABLY SLOWER than those that doesn't, due to the extra book-keeping for maintaining exception handling, at each and every function call, even if the exceptions only happen one in a billion.