Ok, it`s not 50 lines, it`s 47 :)
My sample was not about resource management.
It was about error handling.
Do you have ideas about error handling ?
Printable View
Ok, it`s not 50 lines, it`s 47 :)
My sample was not about resource management.
It was about error handling.
Do you have ideas about error handling ?
Sure, if you count the reusable code with that. If you are looking at it from the method level, we've got 3 lines that does everything your original logic did. This is an important distinction. When you are debugging, after you know ResourceAquirer works, you can ignore it wherever it is used. You can ignore all that code and more quickly zero in on the real problem.Quote:
Originally posted by arkadi
Ok, it`s not 50 lines, it`s 47 :)
Your example was about resource management and error handling. And so was my answer. If you encounter an error in my example, you can simply return. Any allocated memory will be freed via the destructor call. Same goes for a thrown exception.Quote:
My sample was not about resource management.
It was about error handling.
Do you have ideas about error handling ?
Jeff
Yes, your code could be reused and some libraries implements that.Quote:
Sure, if you count the reusable code with that.
But it is not part of standard libraries yet.
What could you do if resource is file or socket handle ?
I quess you will improve your "ResourceAquirer".
What you do if clean-up is: close handlers and
after that remove one of temporary files or directories ?
Could your code be yet universal ?
Yes, you can do it universal.
All that end-up with pretty complex library that do everything.
The kind of my code is frequent case for test programs.
Do you think to add your library on each your test ?
Do you think the code using some monstrous library wroten
by unknown author is simplier than 10 strokes of simple code
that uses "goto" ?
I'm not talking about writing a standard library. I'm talking about using well-understood and accepted techniques to manage memory and handle errors. Avoiding goto is just a nice side-effect.Quote:
Originally posted by arkadi
Yes, your code could be reused and some libraries implements that.
But it is not part of standard libraries yet.
I would write a Socket class. I would write a File class. These classes would control the allocation and deallocation of system resources.Quote:
What could you do if resource is file or socket handle ?
I quess you will improve your "ResourceAquirer".
Correct, however I don't like the idea of doing too much in destructors. You have to be very careful that destructors never ever throw exceptions or cause exceptions to escape.Quote:
What you do if clean-up is: close handlers and
after that remove one of temporary files or directories ?
Could your code be yet universal ?
Yes, you can do it universal.
Not complex. It does not have to do everything. As your software needs more functionality, it can be added.Quote:
All that end-up with pretty complex library that do everything.
I think it would make perfect sense to reuse this for test programs.Quote:
The kind of my code is frequent case for test programs.
Do you think to add your library on each your test ?
I don't know where you get "monstrous" from, or where you get "unknown author" from. Software projects have source control with history. Good code has comments and follow accepted idioms (in this case, RAII).Quote:
Do you think the code using some monstrous library wroten
by unknown author is simplier than 10 strokes of simple code
that uses "goto" ?
Yes, I think a Socket class that wraps calls specific to the application you are working on is "simpler" than doing it by hand each time.
Your code is not exceptions safe. The memory will not be freed if an exception occurs. Your code cannot be reused (aside from copy and paste). Your code is not self-documenting. If it was in a class called "Socket" in a method called "open", you know what it's trying to accomplish even before you examine the code. But the best part is, you may never even have to look at the code! If this class is used elsewhere correctly, you can feel pretty confident that it works correctly.
Yes! It's simpler!
Jeff
The use of more than one statement with any of the "good" keywords require braces, which mark the code section affected by the keyword. goto has no such requirement, and in fact it might be impossible to place such braces if there is more than one goto.
There are a few gotos in the MS CRT implementation of printf (actually output, which lies at the heart of all the *printf functions) btw.
Nice argument.Quote:
There are a few gotos in the MS CRT implementation of printf
In g++ implementation you have it even more
( see "iovprintf.c"::_IO_vfprintf ).
But lets get back to theoretical issues.
If author of code is not hired few years, its name in documentation is almost meaningless.Quote:
I don't know where you get "monstrous" from, or where you get "unknown author" from.
Hence I stand on "unknown author".
About "monstorous" ... well, at it start it must not be.
It could be rather big.
With few iterations it can become monstour, but if you do
some hard administrative effort, you can avoid that for few years.
About RAII. Here is a quote from http://www.hackcraft.net/raii site (I hope you trust that site while talking of RAII):
There are some other drawbacks if class is not "tested, trusted, and well known".Quote:
However once the class is tested, trusted, and well known these can be stepped over and the task of stepping through code is simplified.
The problem appear when none of that prerequirements are valid.
If you prepear basis for some application that will be in OO design, you will be able to prepear "tested and trusted" library.
But even you switch to other project I have a suspect if you
could be able to use the same code.
Finally:
1. You have to create library.
2. You perform non-trivial administrative effort to keep it consistent in all projects.
Question is what you get back ?
1. Less code is for sure not - your library is code too, even if it is standard for you.
2. Argues with other developers that don`t like your implementation.
For example thay don`t like your naming convention :)
3. Hence library is not trusted and not sure if tested,
you get trobles in debugging logic code for other developers.
Your peace of troubles you get while implementing the library :)
#2 is invalid - I'm sure you get a lot more arguments with other developers if you use goto.
#1 is not so sure. If it's something very common (like smart pointers), you get a lot more back than you put in.
#3 isn't so sure either. A simple RAII class is very easy to implement.
If they don`t have to bother with your code at all, they have nothing to argue about.Quote:
I'm sure you get a lot more arguments with other developers if you use goto.
The difference form smart pointers (like ATL) is that smart pointer classes are tested by vendor and trusted by each developer after it`s own positive expirience with it.Quote:
If it's something very common (like smart pointers), you get a lot more back than you put in.
Usually yes, but you have to do it.Quote:
A simple RAII class is very easy to implement.
And as any code it can be buggy :)
Again it`s matter of testing and trust.
i think if you write a function with many goto
1.you will not be able to understand your function when you saw the function you writed many days ago.
2.ussually lead to fault
I now in high school but my C++ book says so many goto not good, i think iit not be good to use,
Sincerely
Jeff
What if you're on a team?Quote:
If they don`t have to bother with your code at all, they have nothing to argue about.
Answer for JeffAust17 and IntoWind:
goto is dangerose thing and must be used with extreme
care and ONLY if you exactly know what for you need it.
In most cases it can and should be replaced with other
language forms.
That`s why you will never find in C book for beginers
advice to use goto. It will be very bad advice.
For CornedBee:
The best team for man is a man himself.Quote:
What if you're on a team?
The program should be devided to modules and modules to functions.
The module (I guess in your case classes :) must be self defined
peace of code with well defined external interface.
The similar rule for function - it have to do one thing and to do it best.
All that general rules of any design that allow several people to share code.
If you do the function with "goto"`s with well defined parameters and well defined behaviour, the maintanance will not be a problem even by other programmers.
On other hand if you do seemingly simpler function, but with interface that is big library - here you have a problem. Specially if that library is not too mach tested and trusted.
I disagree. While you may be only one working on your module NOW, in the future someone else from the team might be transferred to help you out. In general, because programmers can shift, a single coding standard should be agreed upon for all modules and all code before the actual start of coding. And then you have to justify the use of gotos for the other developers.
Have you guys read the debate earlier in this thread between Galathaea and jfaust? I believe their arguments and conclusion are worth noting:
Quote:
Originally posted by jfaust
goto is an unconditional branch that is separated from the reason for the branch. Other control structures have the reason built in.
Jeff
The reason why goto's should be avoided is that a goto branch is not connected to the logic of the branch, leading to maintainablity problems and the increased likelyhood of bugs.Quote:
Originally posted by galathaea
jfaust, I concede to your superior debate move. Absolutely! It makes absolute sense. Because it should be a design principle that one should keep a branch connected to the logic of the branch. And so, this design principle invalidates the use of goto ever. Of course, I could argue that one could still use goto if the branch condition is connected to the goto in a complete statement group (if, goto) but then you have maintainability issues. Brilliant!
** galathaea spins melodramatically at the fatal shot to the heart **
Whispered, last gasp: "I have been fell by the greater rhetorics of jfaust. All should follow his advice. Never use goto."
Fine but what does it mean? Separated from what logic. A goto is used to interrupt the normal flow of other control structures, but so is a break statement. There's no difference in principle. It's just that break has got a fancy name and become accepted over time. It's still a goto, as structured programming affectionados can tell you.Quote:
Originally posted by KevinHall
The reason why goto's should be avoided is that a goto branch is not connected to the logic of the branch, leading to maintainablity problems and the increased likelyhood of bugs.
To use a goto once in a while as an extended break (jump to the exit point of a block) isn't the end of the world. It can even improve code because it can reduce the structural complexity of for example nested loops.