Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Max White]

Dear god, lern 2 indent. Sorry but it makes the script more quickly readable. Yea, like has already been said, it is reading the value then going over the rest of the body of the loop before checking again. If you want to fix without a break, then in the line before the loop put.
cin >> year;
Then in the line right before the loop ends, throw it in again. Then remove it from the early part of the loop.

Also, if you class covers classes and objects, make some. Your script will look nicer and be more functional.

[Tilla]

This is totally unrelated to your thread Tobel and I apologize but I gotta ask if you are the same Tobel who plays Xsyon, formerly with the Hopi tribe!

[SolarShado]

While I agree that breaks can be ugly (can easily make things hard to follow), in this case it makes sense.
It's immediately obvious what loop is being broken out of, and why. Add a comment on the line with the loop's closing brace to make scanning easier and you're all set.

For some reason, I see it as similar to throwing an exception: an unusual case that disrupts the normal flow of the program.

[Blank Expression]

Also, if you class covers classes and objects, make some. Your script will look nicer and be more functional.

"Yeah, uh, make some classes, 'cause, like, they're better."

There are reasons to use object-oriented programming. "Because you can" isn't one. "Look nicer and be more functional" is so context-free as to be meaningless. If you're going to say something like this you should at least have enough of a grasp to explain why it would look nicer. (As for "be more functional"--that's simply nonsensical.

And this is probably bleedingly obvious to almost everyone except you, but it bears repeating: this isn't script programming.

While I agree that breaks can be ugly (can easily make things hard to follow), in this case it makes sense.
It's immediately obvious what loop is being broken out of, and why. Add a comment on the line with the loop's closing brace to make scanning easier and you're all set.

For some reason, I see it as similar to throwing an exception: an unusual case that disrupts the normal flow of the program.

Breaks aren't exceptional conditions, though, where exceptions...well...are. The rest of your logic seems very sound. (Any time I'm subjected to C++ I really miss named breaks.)

[kg333]

While I agree that breaks can be ugly (can easily make things hard to follow), in this case it makes sense.
It's immediately obvious what loop is being broken out of, and why. Add a comment on the line with the loop's closing brace to make scanning easier and you're all set.

For some reason, I see it as similar to throwing an exception: an unusual case that disrupts the normal flow of the program.

Breaks aren't exceptional conditions, though, where exceptions...well...are. The rest of your logic seems very sound. (Any time I'm subjected to C++ I really miss named breaks.)

Breaks would be rather poor form here, IMO, since the OP's problem is an incorrect implementation of sentinel logic/control.  It would make more sense to just fix the loop.

KG

[Blank Expression]

While I agree that breaks can be ugly (can easily make things hard to follow), in this case it makes sense.
It's immediately obvious what loop is being broken out of, and why. Add a comment on the line with the loop's closing brace to make scanning easier and you're all set.

For some reason, I see it as similar to throwing an exception: an unusual case that disrupts the normal flow of the program.

Breaks aren't exceptional conditions, though, where exceptions...well...are. The rest of your logic seems very sound. (Any time I'm subjected to C++ I really miss named breaks.)

Breaks would be rather poor form here, IMO, since the OP's problem is an incorrect implementation of sentinel logic/control.  It would make more sense to just fix the loop.

KG

Sure. I was talking in a theoretical/design sense, not this particular case. He has bigger problems.

[Cecilff2]

Yeah in this case breaks would be poor form; you're adding extra calculation per loop when it's completely unnecessary(Gotta check that if statement every time).  I mean the calculation of just that is negligible, but it still bugs me.

[zilpin]

Question is already answered, but from a broader program design pattern standpoint I will suggest only using != and == when that is the exact value you want.
If you know that all values below 0 are the 'kicker', use a  >=0.
Also, in C and C++ it is usually better to put the constant on the left.  For example  while( 0<=x )   This prevents accidental assignments.

[SolarShado]

Also, in C and C++ it is usually better to put the constant on the left.  For example  while( 0<=x )   This prevents accidental assignments.

Good point... since C (and I assume C++ as well) doesn't truly have a boolean type and assignments evaluate to the assigned value...

[qwertyuiopas]

It only really matters with == accidentally being typed as =, applying it to everything else would just be for consistancy.

[DJ]

Variable on the left is more readable IMO.

[kg333]

Variable on the left is more readable IMO.

Same, first I've heard of putting the constant on the left, although it makes sense.  Just looks really damn weird.

KG

[Blank Expression]

In some languages and cases it's smarter to use a constant expression as the primary evaluator (though it usually matters less when dealing with operators).

Example: In Java or C#, someString.equals("foo") will throw a NPE if someString == null. "foo".equals(someString) can never throw an NPE because "foo" is the interned object.

[kg333]

In some languages and cases it's smarter to use a constant expression as the primary evaluator (though it usually matters less when dealing with operators).

Example: In Java or C#, someString.equals("foo") will throw a NPE if someString == null. "foo".equals(someString) can never throw an NPE because "foo" is the interned object.

That's pretty clever, actually...any idea if C++ allows a method to be used on a constant in that fashion?  i.e. "foo".equals(someString)?

KG

[SolarShado]

In some languages and cases it's smarter to use a constant expression as the primary evaluator (though it usually matters less when dealing with operators).

Example: In Java or C#, someString.equals("foo") will throw a NPE if someString == null. "foo".equals(someString) can never throw an NPE because "foo" is the interned object.

That's pretty clever, actually...any idea if C++ allows a method to be used on a constant in that fashion?  i.e. "foo".equals(someString)?

KG

I think most C/C++ compilers convert string literals to char[]s (or char*'s, same thing really), making it not an object.
There may be a way to force it though, something like

Code: [Select]

(new string("foo")).equals(var)not sure if that's proper C++, I've been focusing on plain C for now.