LINUX.ORG.RU

Сомнения...

 


0

3

Решал одно из упражнений этой книги:
Само упражение
Решение:

#include <stdio.h>

#define FT 30.48
#define INCH 2.54

int main(void) {
	int ftInt;
	float sm;
	double ftDouble, inch;
	printf("Введите высоту в сантиметрах (<=0 для выхода из программы): ");
	scanf("%f", &sm);
	while (sm > 0) {
		ftInt = sm / FT;
		ftDouble = sm / FT;
		inch = ((ftDouble - ftInt) * FT) / INCH;
		printf("%.1f см = %d футов, %.1f дюймов\n", sm, ftInt, inch);
		printf("Введите высоту в сантиметрах (<=0 для выхода из программы): ");
		scanf("%f", &sm);
	}
	printf("Работа завершена.\n");
	return 0;
}
Собственно появились сомнения о правильности в принятии решения, но в голову ничего другого не приходит.

Ответ на: комментарий от Silencer

Если она такое зло советую написать об этом автору книги, указанной в топике, в связи с частым использованием в примерах сей книги этой самой копипасты.

давай ты лучше книгу другую возьмёшь? Очень рекомендую K&R в качестве первой, а не это говно.

Ну и потом Кнута почитай.

emulek
()
Ответ на: комментарий от kim-roader

не трогает свои аргументы и возвращает 0

да? Я забыл уже, как scanf(3) работает, я юзаю свои велосипеды, т.к. обычно мне возможностей scanf не хватает, а этот функционал реализовать можно за 5 минут.

Ну если так, то да, ты прав, необходима проверка.

ЗЫЖ покурил ман, да, так и есть:

RETURN VALUE These functions return the number of input items successfully matched and assigned, which can be fewer than provided for, or even zero in the event of an early matching failure.

The value EOF is returned if the end of input is reached before either the first successful conversion or a matching failure occurs. EOF is also returned if a read error occurs, in which case the error indicator for the stream (see ferror(3)) is set, and errno is set indi‐ cate the error.

нужно проверять EOF и 0.

emulek
()
Ответ на: комментарий от qulinxao

тебе процитировать какое издание K&R?

Такое, где пишут, что С - это НЕ структурный ЯП. А то мужики-то и не знают. Все по старинке считают, что у няшной сишки Paradigm: Imperative (procedural), structured.

archie
()
Ответ на: комментарий от emulek

ну тут я не знаю. Зачем? Всё равно можно _выводить_ только целую часть футов.

По условию задачи футы целые, при печати они тоже целые. Если мне дадут рефакторить подобный код, то я буду удивлен, узнав что футы на самом деле хранятся с дробной частью. По объявлению переменной как double также не видно - целые они или дробные.

Впрочем это все чисто субъективно, здесь спорить не буду.

archie
()
Ответ на: комментарий от archie

Если мне дадут рефакторить подобный код, то я буду удивлен, узнав что футы на самом деле хранятся с дробной частью

тут они очень близко от вывода, сложно будет не заметить. В принципе можно использовать double feets = floor(…);, для удобства поддержки.

ЗЫЖ терпеть ненавижу мешать типы, т.к. не раз наступал на эти грабли(см. выше).

emulek
()
Ответ на: комментарий от archie

передёргиваешь.

если только на твой ответ смотреть так может показаться что я утверждаю что С - неструктурный. В не зависимости от моих убеждений , мой ответ на твой комментарий был на:

Си - это типичный структурный ЯП

тебе процитировать какое издание K&R?

т.е. типичность это «эпично» при обсуждении хитровывернутого switch и отсутствия вложенных функций

Си (с натяжкой) структурный язык, но явно не типичный .

то что с ооп люди знакомятся при помощи «так же типичного(как С типично структурный)» ооп-языка как С++ это уже :(

так теперь явному большинству С - типичен как структурный язык .

всё отлично.

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

Ну я не телепат на 3.14 киломессингов, чтобы догадываться, что именно тебе не понравилось в моей фразе. Вне зависимости от твоих убеждений С - структурный язык, и это факт.

Вот степень «типичности» - это более относительное понятие. Если сравнивать с канонiчными алголами и прочими паскалоидами, то может С и менее типичный. Хотя я не вижу, что в нем прямо такого нетипичного. Управляющие операторы те же самые, процедуры такие же, блочная организация опять же аналогична.

Ну а с С++ все ясно и так. Еще Алан Кей говорил, что он думает про С++ и ООП.

archie
()
Ответ на: комментарий от archie

Ну а с С++ все ясно и так. Еще Алан Кей говорил, что он думает про С++ и ООП.

Вот видишь - и он говорил про С++, а кто говорит про его Smalltalk?

anonymous
()
Ответ на: комментарий от archie

раскрою исходную реакцию

если внимательно посмотреть на предисловие в 1978 издании KR там в предисловии конечно присутствует оммаж структурному программированию (тык это как раз время когда «структурное программирование» попало в/на язык менеджеров, как в 80ых ооп) , но если посмотреть на предшествующие доки по Си , да и на последующую кернигановскую «почему паскаль не мой любимый язык программирования»

то мне видится , что Си это переносимый ассемблер у которого есть возможность писать структурно , а есть возможность игнорировать предыдущую возможность,

вон http://cm.bell-labs.com/cm/cs/who/dmr/chist.html об этом в том числе.

qulinxao ★★☆
()
Ответ на: комментарий от archie

Управляющие операторы те же самые, процедуры такие же, блочная организация опять же аналогична

тем он, что более «свободен», а фактически «не регулярен» те же самые break в конце case|default - самим же автором языка признаны не самыми удачными (уж fallthrow во внуках годнее)

т.е. писать на Си придя со «структурного языка» структурно возможно,

но вот исходно на Си писать культурно , так же научиться трудно

как и научится адекватному программированию когда первый язык PHP

зы. вообще PHP и Си имеет в этом общую черту - быть удобным и адекватным своим пользователям.

как ни крути Си пользовались (уж в конце 1970ых так точно) люди с уже как минимум BS, PHP как известно даётся легко и очевидно без проблем людям которые не факт, что квадратное уравнения решат.

qulinxao ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.