denominator > 0 ? result=numerator/denominator : result=0;
Well, when the instructor saw it, he nearly flipped! To him, it was as bad as if I''d sprinkled gotos and labels and everything all over the place. Now, I thought the ?: operator was a handy way to avoid writing 5-6 lines of if/else stuff, but apparently its "too confusing". In my opinion, if you keep it simple, it isn''t hard to read; its just another part of C/C++ syntax. Maybe its just me though, since I don''t think anyone has difficulty reading the code they just wrote.
Anyway, what is everyone''s opinion on this? Avoid ?: at all costs, or is its occasional use ok?
Conditional operator... really so bad?
While working on a project for one of my CS classes, I decided to use the ?: operator for something simple, along the lines of:
You''re the one writing your program. If you want to use elusive operations, then you go right ahead and do that. As long as you don''t have trouble reading it, who the hell cares?
If you plan on sharing your code, however, I suggest keeping is as high-level as possible to make it easy for all to read. Your instructor must have some emotional problems to flip out over an operator, but he does have a point inasmuch as sharing code.
Outside class, your instructor can go to hell. Do whatever makes you happy.
If you plan on sharing your code, however, I suggest keeping is as high-level as possible to make it easy for all to read. Your instructor must have some emotional problems to flip out over an operator, but he does have a point inasmuch as sharing code.
Outside class, your instructor can go to hell. Do whatever makes you happy.
GDNet+. It's only $5 a month. You know you want it.
I can see your instructor''s point. Until I fully began to understand C/C++, I wished programmers would use code like this because it was easier for me to understand what was happening.
I imagine that it is a personal preferance though.
Although one thing that isn''t referenced is; has that operator already been discussed in class or did you use it before s/he had a chance to explain it to you? My teachers in school always got mad at me when I did something before they could explained it to me.
Regards,
Jumpster
float result = 0.0f;if (denominator != 0.0f) result = (float) numerator / denominator;
I imagine that it is a personal preferance though.
Although one thing that isn''t referenced is; has that operator already been discussed in class or did you use it before s/he had a chance to explain it to you? My teachers in school always got mad at me when I did something before they could explained it to me.
Regards,
Jumpster
Regards,JumpsterSemper Fi
Well, as long as it isn''t complex, or goto, its probably ok, although, switch would also be ok for avoiding if''s.
-----------------------------
A wise man once said "A person with half a clue is more dangerous than a person with or without one."
The Micro$haft BSOD T-Shirt
-----------------------------
A wise man once said "A person with half a clue is more dangerous than a person with or without one."
The Micro$haft BSOD T-Shirt
-----------------------------A wise man once said "A person with half a clue is more dangerous than a person with or without one."The Micro$haft BSOD T-Shirt
December 12, 2000 09:57 PM
Writing out the if-then-else statement is usually preferable to using the ?: operator; it''s generally more readable and maintainable.
First off, if you''re going to use the ?: operator (which is an expression), DON''T use it like an if-then-else statement (the first example); use it as an expression (the second example). The result is usually clearer and simpler.
However, in general, the last example is the clearest. (Sources? Read any number of good books on software engineering.) It''s the easiest to maintain and the easiest to grasp in the quickest time.
Less typing != maintainable code. Less typing != more efficient code.
Finally, there is at least one case I can think of where you MUST use the ?: operator. Constructor initializers in C++ requires an expression, and therefore if you need a conditional parameter to the initializer, you have to use ?: (since if-then-else is a statement).
denominator > 0 ? result = numerator / denominator : result = 0; result = (denominator > 0) ? (numerator / denominator) : 0; if (denominator > 0) result = numerator / denominator;else result = 0;
First off, if you''re going to use the ?: operator (which is an expression), DON''T use it like an if-then-else statement (the first example); use it as an expression (the second example). The result is usually clearer and simpler.
However, in general, the last example is the clearest. (Sources? Read any number of good books on software engineering.) It''s the easiest to maintain and the easiest to grasp in the quickest time.
Less typing != maintainable code. Less typing != more efficient code.
Finally, there is at least one case I can think of where you MUST use the ?: operator. Constructor initializers in C++ requires an expression, and therefore if you need a conditional parameter to the initializer, you have to use ?: (since if-then-else is a statement).
have you seen this?
pointer||pointer->drawmodel();
height||(height+1);
rotation>360&&(rotation-=360);
thats really funny, the ?: is no problem
we wanna play, not watch the pictures
pointer||pointer->drawmodel();
height||(height+1);
rotation>360&&(rotation-=360);
thats really funny, the ?: is no problem
we wanna play, not watch the pictures
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia
My Page davepermen.net | My Music on Bandcamp and on Soundcloud
Hm, I don''t know guys. There seems to be a lot of sentiment against this, but where I work it''s absolutely no problem at all. We use ? : all the time.
Believe it or not, goto also has its place. If you''re coding straight C, you don''t have exceptions or stack unwinding; goto is a great way to tear down a complicated initialization if there''s an error.
Realistically, you should know and be able to use the entire language. As long as you''re not doing hugely complicated comparisons (i.e. nested comparisons), ? : is fine. There are many reasons to not use a technique in C/C++, but "other people may not know about it" is NOT an acceptable reason. Performance and maintainability should be the major criteria, and I''m sorry, but I don''t think using ? : makes things less maintainable.
However, as a practical situation, you need to get through class & pass, so do whatever the instructor says. "Nod & Smile", that''s how I got through school.
In fact, I have a coworker who''s interning right now, taking compilers & operating systems at his school. His OS instructor gave out a sheet at the beginning of class of "Things not to do in C++", among which he included operator overloading, multiple inheritence, and templates (including the entire STL). Since he uses these things daily as a professional, it was pretty hard for him to relent, but he did. You just gotta lie down and do whatever the prof wants to get through school. Just remember that the real world is nothing like the university.
Believe it or not, goto also has its place. If you''re coding straight C, you don''t have exceptions or stack unwinding; goto is a great way to tear down a complicated initialization if there''s an error.
Realistically, you should know and be able to use the entire language. As long as you''re not doing hugely complicated comparisons (i.e. nested comparisons), ? : is fine. There are many reasons to not use a technique in C/C++, but "other people may not know about it" is NOT an acceptable reason. Performance and maintainability should be the major criteria, and I''m sorry, but I don''t think using ? : makes things less maintainable.
However, as a practical situation, you need to get through class & pass, so do whatever the instructor says. "Nod & Smile", that''s how I got through school.
In fact, I have a coworker who''s interning right now, taking compilers & operating systems at his school. His OS instructor gave out a sheet at the beginning of class of "Things not to do in C++", among which he included operator overloading, multiple inheritence, and templates (including the entire STL). Since he uses these things daily as a professional, it was pretty hard for him to relent, but he did. You just gotta lie down and do whatever the prof wants to get through school. Just remember that the real world is nothing like the university.
quote: Original post by Stoffel
Hm, I don''t know guys. There seems to be a lot of sentiment against this, but where I work it''s absolutely no problem at all. We use ? : all the time.
Believe it or not, goto also has its place. If you''re coding straight C, you don''t have exceptions or stack unwinding; goto is a great way to tear down a complicated initialization if there''s an error.
Realistically, you should know and be able to use the entire language. As long as you''re not doing hugely complicated comparisons (i.e. nested comparisons), ? : is fine. There are many reasons to not use a technique in C/C++, but "other people may not know about it" is NOT an acceptable reason. Performance and maintainability should be the major criteria, and I''m sorry, but I don''t think using ? : makes things less maintainable.
Agreed that ?: and goto''s are not "evil" do have their place.
However, I DO think that ?: is not very maintainable. ?: works great for just if/else statements, but what if in the future you to add a condition and make it an if/elseif/else statement? Nested ?:''s are very ugly and hard to maintain, IMO.
I don''t mind reading ?: as long as you know that it will only ever be just one condition. On the other hand, I just spend the extra 1.5 seconds to type out the normal form and perhaps save myself time in the future.
- Houdini
- Houdini
Which of the following is more readable?
I would like to add that the instructor in mention should go to hell. He should''ve at least explained his point of view.
// kU, kR, kD, kL, currently determine whether// a particular arrow key is being held down.// The player''s current direction is in PlayerDir.// Which direction should the player now move?// with ?:PlayerDir = (kU == kD)? (kL == kR)? PlayerDir // no change : kL? 3 : 1 : kU? 0 : 2// without ?:if(kU == kD)then if(kL != kR)then if(kL)then PlayerDir = 3 else PlayerDir = 1 elseelse if(kU)then PlayerDir = 0 else PlayerDir = 2;
I would like to add that the instructor in mention should go to hell. He should''ve at least explained his point of view.
It could probably be said that if a language has a feature in, it is probably there to be used. Therefore, there is nothing wrong with using the tertiary ? operator. You could cite exceptions like goto - but even that has an odd use.
I agree with the first AP, as the way in which you structured your ? operation is more cryptic than usual (see AP''s second line of code, for a possible better way to write it).
-Mezz
I agree with the first AP, as the way in which you structured your ? operation is more cryptic than usual (see AP''s second line of code, for a possible better way to write it).
-Mezz
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement