uman

Gah! Why must people use C++ as C + classes?!?! This annoys me to no end! Hey, developers, when you write C++:

1) You don't have to use return codes to indicate errors! We have exceptions!
2) You don't have to declare all your variables at the top of the block!
3) for(int i=0;...) works fine!


Gah!

Edit: Sorry but I just had to get this off my chest. I'm having to read some "C++" code, and this is pissing me off!

kurifu

Actually there is nothing wrong with returning errors codes when using C++, infact I find--and a lot of people will agree--that exceptions in C++ are really only useful in very specific circumstances, I prefered using standard error codes returned from a class as opposed to throwing exceptions, especially if you want tolerant code...

With exception you still have to catch the acception even if you want to silently ignore an error, otherwise the application will catch it and before you know it no more execution.

About the defining variable at the top of the code block, you are right... the compiler is smart enough to check the entire block of code and instantiate all values on your stack as soon as the code block is entered, but typically not putting these variables at the top produces ugly and un-organized code, I actually recommend that this is done in C++ unless there is a circumstance where it is less confusing and cleaner to not do this (not very usual).

for( int i = 0; ... ) is actually very fine, I would recommend this as opposed to declaring i in the parent scope, this only makes send of course, but what I would like to point out is that unless you are using unary operators, you should always have spaces pro-ceeding and pre-ceeding the operator, as I used in my example.

__________________
Clifford Matthew Roche <geek@cliffordroche.com>
Web Hosting: http://www.crd-hosting.com
Consulting: http://www.crdev-consulting.com

uman

well this works fine:


try
{
some_function_that_returns_an_error_you_want_to_ignore();
}
catch(...){}

The problem comes when you have a function that returns a positive or negative integer, and anything is valid. Then, oops, what are you going to use as an error code?

On the "variables at the top" thing, I like it better when a variable is defined before it is used. That way, you don't have to scroll to the top to look at its definition. Personal preference, I guess.

Yeah I agree one should say "for(int i = 0; ...)" instead of what I had, but you see my point :-P

DaWei

Bruce Eckel's "Thinking in C++", Volume 2, has good material regarding the choice of using exceptions or more localized error tests.

I agree that the location of variable declaration should be governed by clarity and, possibly, stack usage. Bear in mind, however, that there are still a couple zillion working (but non-compliant) compilers that don't get the scoping right for the "for (int i = ....)" thangy.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

grumpy

Sure, but as kurifu said, there is nothing wrong with using error codes.

Exceptions are most valuable when an error occurs that must be recovered from and the code that can do recovery is a long way from the code that detects the error (eg far up the call stack).

Error codes are most valuable in circumstances when an error occurs, but the impact of that error is minor. They are also valuable if it is reasonable, in some circumstances, for the caller to ignore the error.

As an example where throwing of exceptions is employed too much, we can look at file operations in the JDK. Throwing an exception is, for example, used to report basic things such as failing to open a file or encountering end of file. Why should a programmer have to change simple logic like this (pseudo-code);
[PHP]
while (eof not encountered)
{
if data successfully read from file then
process data from file;
}
[/PHP]
to something like
[PHP]
while (eof not encountered and error_flag == false)
{
error_flag = false;
try
{
read data from file;
process data from file;
}
catch (...)
{
error_flag = true;
}
}
[/PHP]
I personally fail to see that forcing a programmer to use the second form (by throwing exceptions on errors that are readily recoverable) is inherently better. I would be interested to see you try to justify an argument that this approach is always better.
Sure. But there is nothing preventing it either. One of the nice things about C++ is that it allows the programmer to make a choice. And sometimes declaring all variables at the top of a block is a good choice.
Not always. There are C++ compilers, dating from days when the C++ standard was draft, that did not support this construct in the same way that is now standard. And a lot of code of that vintage (mid 1990s) could therefore not use such constructs.

And it was only relatively recently (over the last 3 years or so) that Microsoft made a concerted effort to comply with the C++ standard. Compilers before that time (i.e. up to VC++ version 6) did not support such constructs. Anyone who cared about porting to windows therefore had a hard case justifying not using the sort of coding that you are ranting about.

There is no point cursing programmers who made the best use they could of the tools they had available. You can't change history, and neither can they.

Ancient Dragon

I'm not an oo pursist -- I don't see everything as objects even though they could be. I once worked with someone so had to make objects out of everything in sight -- and made a simple prgram very complicated. I use c++ classes where they make sense and otherwise use standard C structures or functions.

As for exceptions -- I never throw exceptions in my own code, and use try/catch blocks only when I know a library function might throw an exception. Filling a program with hundreds (or maybe thousands) of try/catch blocks seems -- well -- horrendous and god-awful to read.

There are some situations when the return value is used in a switch statement so that specific actions can be taken for each error.

grumpy

That is not the intent of exceptions. In fact, a need to have lots of try/catch blocks in code is usually a danger sign: most times, sensible construction of code (eg ordering of operations) is enough to make code exception safe without having to have try/catch blocks sprinkled everywhere.

Bjarne Stroustrup gave quite an interesting discussion in Appendix E of his book "The C++ Programming Language", 3rd Edition. The material is fairly lengthy, but (if you stick with it) it gives a lot of useful discussion on how to better write code that will work correctly if exceptions are thrown. A link is here.

Yep. If exceptions are used to report errors in such cases, the code to make those decisions can become much more complex than it needs to be.

uman

Yeah I agree that exceptions aren't the silver bullet of error handling. But yeah don't just consider me an extremely anal psycho or something, there are lots more examples of this person doing unnecessarily C-style stuff in his code, I just chose 3.

grumpy

My point is that, rather than ranting, look at why the person did it. It may have been done that way deliberately, even if the code isn't as "pure" as you would like. Code that meets requirements correctly is king. If what you are ranting about is the fact that code is not as "pure" as you think it could be, and if the code gets changed in response, the new code may fail to meet some requirement (eg support for an old compiler version on another machine). Code that fails to meet requirements is no longer king. And if you cause that situation .....

Ancient Dragon

Been there, done that. May years ago when I was fairly new I thought I knew more then the original programmer, so I decided to "improve" and "enhance" his code. Well my version was total crap, and I tossed it into the bit bucket before anyone had a chance to see it