Printable View
I understand, and yes, the pow thing was part of the project that referred to the chapter on loops, so it was part of the practice. However we had to use about 6 to 8 more loops in the same project, so it wasn't clear to me that we had to do something so trivial using a loop until a friend told me.
And although I see quite clearly why fgets is a much more safe apporach and good practice, we haven't been taught it yet, so I'm not going to risk a point off my project just for being more correct.
Neither did I mean that you should, but rather suggesting that the teacher(s)/helper(s) should be able to "hide" the fact that you haven't got to fgets() in the book, and explain that "gets() is no good, use this for of fgets() instead" - without actually explaining all the ins and outs of how it works and why it's so much better. Get to WHY it's better when you get to that part of the book [and explaining how and why this is important, somewhere in the education too!].Quote:
Originally Posted by Leftos
--
Mats
It would seem to me that you're on the wrong course then. Since you already know some stuff, and have the sense to go digging for information yourself, you're already a step above the noobs who have to be spoon-fed all the way.
> Herbert Schildt's Teach Yourself C
Well if this is the reference text, then everybody is on the wrong course.
Schildt is famous for many many low-quality publications.
Now THAT is madness. Gets is very dangerous because it can very easily create buffer overruns. Gets should never, ever be used. It should not even be teached!Quote:
Originally Posted by Leftos
It never fails to amaze me how teacher and books learn people to use gets or other unsafe functions.
As matsp mentioned there, fgets(buffer, size, stdin) is the same as doing gets(buffer) and it much, much safer. Gets is just a dumb version of fgets, basically.
Complain at those who teach you if you want, but please, use fgets or at the very least learn how to use it. In a real application you should NEVER use gets.
And btw, even for school projects, it can be dangerous as soon as you run the application. It can even crash. Doesn't look good, does it?
I fully understand the risk of gets and the usefullness of fgets. And from what I've learned today, come the day I start programming in C for anything besides uni's projects, I'll use fgets. But for now, I don't want my grade lowered just because I'm using something I've not been taught.
Complain at your teacher, though. Always a good thing. Tell them not to teach dangerous stuff.
For some reason computer science is fraught with bad instructors. Some of the absolute worst designed code I've ever seen was written by CS Ph. D's. These people are well versed in arcane topics and understand computer science and mathematics really well, but they have very little engineering skill. I don't mean to make a blanket statement. I have also seen some incredibly good code.Quote:
Originally Posted by Leftos
In my experience it is impossible to change these people's opinions no matter how wrong they are. Especially in the lower-numbered classes, the instructors sometimes don't even use the languages they are teaching. The best you can do is give them what they expect while keeping in mind that you are actually using bad techniques. Write a version for yourself that does it right. I wish it wasn't this way, but it's how it is. For now.
Here's something I don't understand. Well, another thing. Given the input is 7.6...
...gives 75.999999, while...Code:float a;
scanf("%f", &a);
printf("%f", a * 10);
...gives 76.000000. Why is that?Code:float a;
scanf("%f", &a);
a = a * 10;
printf("%f", a);
A better all-around check:
Output: 7.600000 75.999999 76.000000 75Code:float a, b;
int inta;
scanf("%f", &a);
b = a * 10;
inta = (int)(a * 10);
printf("%f %f %f %d", a, a * 10, b, inta);
because the calculation is done a little bit differently - or the conversion from float to double is done differently [all floating point parameters to printf are double] , perhaps. You probably will find other cases where there are differences.Quote:
Originally Posted by Leftos
Actually, I reproduced the results you got on my machine, and there is a difference between the two code-sets is:
This stores the value back in a, and then loads it and stores it as a double on the stack for printf. In the "just multiply a by ten", the red code is not present, meaning the more precise double value is stored onto the stack. Note that the precision of (x87) floating point calculations is decided at the store stage, not during the actual calculation.Code:fmulp %st, %st(1)
fstps -4(%ebp)
flds -4(%ebp)
fstpl 4(%esp)
I do apologize if you don't fancy reading assembler code and understanding what it means - but there's no way to explain the behaviour in any other way.
--
Mats
Don't worry. I'm glad you're still answering to my issues and explaining so well.
So the correct way to do floating point calculations would be outside functions such as printf. Here is the loop that made the program work on my computer too.
Thanks for all the help and info anyway, it's been very helpful. A little testing always helps and in this case taught me something.Code:do
{
printf("Dwse vathmo %dou ma8hth: ", i + 1);
scanf("%f", &vathmoi[i]);
vathmoi10 = vathmoi[i] * 10;
}
while ((int)(vathmoi10) != vathmoi10 | vathmoi[i] < 0 | vathmoi[i] > 10);
I'm still wondering, though, about why the other exercise with the inverted string doesn't work on my computer but works on the server.
Quote:
Originally Posted by Leftos
The red code above is broken in two senses:
1. It's comparing an integer with a float, which is likely to fail under some circumstances [you just don't KNOW what those circumstances may be] due to floating point not being precise.would be a better solution.Code:fabs((int)(vathmoi10) - vathmoi10) > 0.01
2. You are using bitwise or rather than logical or, which isn't quite the same thing - it sort of works OK for this case, but it's the wrong thing to do here. Use || instead of | and all will be fine.
As someone else suggested:
should probably beCode:char linet[strlen(line)];
char linet2[strlen(line)];
Although both are a bit dubious as they are extensions to gcc, so won't work on other compilers. Perhaps this is the best solution:Code:char linet[strlen(line)+1];
char linet2[strlen(line)+1];
You also should set the end-marker of linet2 to zero - currently you just leave it to whatever it happens to be. Since different machines have different "stuff" sitting around in stack-based locations, what actually ends up at the end of the string is completely random, and on one machine it may be zero, on another some other value, so you get "random failyures" - it may even be different for different length strings.Code:char linet[200];
char linet2[200];
--
Mats
I made it work. Thanks. I declared linet and line2 as 200 in size (can't declare after gets, obviously, and we haven't practiced subroutines yet), and made sure to add '\0' to linet2 on position strlen(linet). Now any string works.
Thanks everyone, you've been really helpful!