|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : Nick Lepehin 2:5020/368.15 21 Dec 2002 00:09:33
To : Dmitry Radishev
Subject : Null Poison fro Perl
--------------------------------------------------------------------------------
16 Dec 02 14:24, Dmitry Radishev wrote to Nick Lepehin:
DR>>> Повторяю. В асме нет удобных штатных средств. В си есть удобное
DR>>> штатное средство - но оно ненадежно, и есть неудобное штатное
DR>>> средство. Лучше бы в си либо не было бы удобного но ненадежного,
DR>>> либо не было бы вообще никакого. А так - имеем что имеем.
NL>> А знаешь, fork удобнее printf'а, параметров гораздо меньше,
NL>> лучше бы c не имел printf'а, не правда ли?
DR> Разумеется да - если, конечно, ты расскажешь как при помощи fork
DR> делать форматированный вывод. Сколько форком не пользовался - не знал,
DR> что не его основе можно изобразить функциональность printf.
Так у strcpy и strncpy тоже функциональность разная, хоть и похожая.
DR> Кстати, заодно не напомнишь, в чем нехорошесть именно printf? В чем
DR> нехорошесть sprintf (и хорошесть snprintf) я знаю, а чем printf так
DR> провинился?
А я не говорю, что printf плохой, так же как не говорю что sprintf или snprintf
плохой. Просто есть места, где можно применять sprintf или strcpy или что там
больше нравится, а есть места гда HАДО применять snprintf, strncpy, и это вполне
адекватно и разумно. О чем я и пытаюсь тебе объяснить уже хрен знает сколько
времени. ТОлько бесполезно все.
NL>> Ты вправе всегда пользоваться функами mem* с тем же успехом что
NL>> и str* ;)
DR> Мне, пожалуйста, mem* аналог strlen и strcat. Я уж, так и быть, не
DR> буду просить mem* аналог snprintf :-) Как только выясняется, что asciz
DR> в конкретной задаче ограничивает - приходится ввиду отсутствия
DR> адекватной штатной замены _весь_ велосипед изобретать заново, а не
DR> просто земенить str* на mem*. К сожалению, нередко такие задачи
DR> появляются уже после начала эксплуатации программы, и поэтому что-то
DR> исправлять уже поздно. А если бы в си были бы человеческие строки -
DR> таких ситуаций было бы меньше.
mem аналог snprintf'а написать не проблема, а mem аналоги strlen'а есть просто
длина массива в переменной, mem аналог strcat'а - memcpy + длина массива в той
же переменной. Заметьте, что работа с mem функами всегда ведеться с явным
указанием длины, кстати. Hе вижу никакого изобретения велосипеда, равно как и
никакого ограничения.
DR>>> Имеет отношение к libc. А то так мы скоро договоримся до того,
DR>>> что "язык за свой рантайм не отвечает", и в си вообще всё прямо
DR>>> и параллельно, и даже asciz почти нигде нет :-)
NL>> Ты правильно сказал - не отвечает язык за конкретный рантайм
NL>> конкретного компилятора, абсолютно. Глюки, которые встречаются в
NL>> рантаймах отдельных
NL>> компиляторов ни в каком страшном сне не могли приснится КиР'ам.
NL>> Давай начнем записывать стандарты в отстои на основе их
NL>> реализаций - весь мир отстоем будет.
DR> Извини, формат const char* (с нулем в конце) разве имеет отношение к
DR> рантайму? А рантайм (пресловутые str* и *printf/scanf) разве не
DR> является частью стандарта на язык? Или КиР разработали только
DR> синтаксис, а базовый рантайм злобные юниксоиды придумали?
Стандарт на язык - это формат вызова функи и формат возвращаемых значений, а
если внутри функи делается какая нибулдь чушь - то это конкретная реализация, а
не стандарт. Hе секрет, что в разных компиляторах те же str* функи внутри могут
бытьреализованы по разному - разные ассемблерный код и тп. Соотв КиР не отвечает
за ошибки, вызванные РЕАЛИЗАЦИЕЙ стандартных фунок.
DR> Hе надо путать глюки конкретных реализаций рантайма и глюки
DR> _спецификации_ рантайма. А рантайм я готов рассматривать отдельно от
DR> компилятора не раньше, чем ты предъявишь компилятор (не для embedded,
DR> а для "ОС общего назначения"), штатно идущий с "альтернативным"
DR> рантаймом.
Какие глюки спецификации рантайма ты знаешь? Именно глюки спецификации, а не
глюки мозгов программера, неправильно использующего рантайм.
Faithfully yours , Nick (nickk@nm.ru)
--- GoldED+/EMX 1.1.5-20614
* Origin: Turtle_Paradize (2:5020/368.15)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
