[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Чёртов язык Си!



Dmitrii Kashin -> debian-russian@lists.debian.org  @ Tue, 07 Oct 2014 11:18:35 +0400:

 >>  >> http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Incomplete-Types
 >>
 >>  DK> Спасибо, Артём. Не дочитал, поторопился. =(
 >>
 >>  DK> Кстати, здесь что-то непонятное с терминологией: "You can *define*
 >>  DK> structures, unions, and enumerations without listing their members"
 >>  DK> Я ведь правильно понимаю, что "define" - это "определять", а "объявлять" -
 >>  DK> это "declare"? Или переводить такие слова надо как-то аккуратнее?
 >>
 >> Да, у них там недоработка.
 >>
 >> Но вообще надо понимать, что нет такого языка "GNU C", поэтому
 >> gnu-c-manual не может быть руководством по языку :)

 DK> Мне кажется, справка по реализации должна в точности повторять справку
 DK> по языку, плюс описывать отступления от стандарта и особенности
 DK> компилятора в местах, где стандарт можно понимать двойственно. Это же
 DK> вроде логично.

Вот в том-то и дело, что полностью описывать язык справка по реализации
не обязана.  Достаточно сослаться на стандарт и описать отличия
реализации от стандарта.

 >> Обсуждаемая особенность была в языке C с самого начала, ее можно еще у
 >> Кернигана и Ричи вычитать.  Хотя в наше время по Кернигану и Ричи учить
 >> C уже не очень хорошо, уж очень там много давно снятых ограничений.

 DK> Ну, если Вы это найдёте ещё и у Кернигана-Ритчи, то я совсем со стыда
 DK> сгорю, ибо в отличие от gnu-c-manual этих ребят я читал от корки до
 DK> корки несколько раз. =)

http://www.lib.ru/CTOTOR/kernigan.txt_with-big-pictures.html#80

Ровно такое же место.  Более общего варианта, т.е. когда структура не
определяется вообще, я там тоже не нашел, но он логично следует.  Вполне
возможно, что явно это прописывается в более поздних стандартах, вместе
с особенностями проверки типа в таких ситуациях - а именно, что попытка
передать struct A * туда, где ждут struct B * является ошибкой
независимо от определений A и B.  K&R, я подозреваю, вообще не является
официальным стандартом.

Я подозреваю, что если вдумчиво копнуть приложение A, то даже формально
получится нужный вариант.  Только это надо вместо этого источника взять
какой-нибудь другой, где с форматированием получше.  А то по этой ссылке
формальные определения крайне неудобно читать.

Собственно, из смысла системного языка тут все понятно.  Для того, чтобы
выделить память под указатель на что угодно, передать указатель,
скопировать указатель, достаточно знать, что это указатель.  На что - не
важно.  Чтобы проверить соответствие типов, достаточно знать, как
называется исходный (в смысле, после раскрытия typedef) тип, на который
мы указываем.  Определение этого типа начинает ролять только когда
требуется разыменование.  Если оно не требуется вообще, то и определение
не нужно.


Reply to: