За несколько лет в одном зале ни разу не сломались две PDP-11, несколько раз ломалась одна СМ-1420, и одна из двух СМ-4 после череды неисправностей в конце концов пошла на ЗИП для второй СМ-4.
А потом в другом зале я за несколько лет ни разу не видел “погоревшими” ни одного из двух HP-1000, которые там и до моего прихода чёрт знает сколько лет отработали, и ни одного из четырёх (два — стоечные, два — “пуфики”) MicroVAX.
Но пределы должны быть у всего. И разумные, желательно.
Автор считает, что 200 строк делают функцию большой и “грязной”? Так он просто больших функций не видел :) В одном чертовски популярном open source продукте (не уверен, что вспомнил точно, а уточнять прямо сейчас лениво, позже повспоминаю, но кажется это ffmpeg. Или нет? Но что-то про мультимедиа. Найду потом) есть функция, в которой почти шесть тысяч строк.
Автор с упорством, достойным и более благородного применения, таскает из статьи в статью отсылку к фразе Э. Дейкстры, которую так криво перевели и изложили (вряд ли удастся достоверно установить, кто именно), что её можно понять даже в совершенно противоположном смысле.
Величайшей победой Запада в холодной войне над СССР был переход на IBM
Если прямо не указать (а в многократно использованном автором варианте прямого указания и нет), то кто угодно может прочитать не только так, как ожидает автор этого “перевода”, но и так, что переход запада на IBM и является величайшей победой в холодной войне.
Только вот Э. Дейкстра на той самой конференции в Риме в 1969 (которая не конференция НАТО, а конференция, спонсированная научным комитетом НАТО) сказал буквально:
I characterized the Russian decision to build a bit-compatible copy of the IBM 360 as the greatest American victory in the Cold War
Как делал я (вторая половина 70-х) в своём малюсеньком, никому неведомом, так как закрытом от всех вплоть до отсутствия на всех, кроме очень секретных, картах страны и сурового неупоминания во Внуково при посадке на Ту-154, городке на 30 тысяч населения: приходил в нужный момент в книжный магазин (в оба), брал там каталоги издательств с их планами выпуска книг на грядущий издательский период, заполнял по открытке на каждую интересную мне книгу, и оставлял их там. Потом ждал. Книжка издавалась, приезжала в наш город, магазин отгружал соответствующие открытки почте, почта приносила открытки мне, я клянчил у мамки копеечку и шёл с открыткой в магазин забирать отложенный для меня экземпляр.
Да, это не работало с книжками про бравых мушкетёров, красавицу маркизу и лихих ковбоев, для этого кроме планов издательства надо было иметь в магазине главное — блат™ Но с книгами от «Мир», «Радио и Связь», «Финансы и Статистика» и прочими издателями интересной нам литературы чаще прокатывало, чем нет. Потому у меня и случилась довольно впечатляющая библиотека, и даже многомудрые дядьки-программисты аж из самой Москвы, коих работало у нас множество, нередко обращались ко мне “Дай на недельку, законспектировать.”
Игорь, я пробежал по диагонали почти весь текст книги, и увидел с одной стороны хороший задел на перспективу, а с другой — графоманский продукт специалиста, который недостаточно квалифицирован в том, о чём он взялся писать.
О графомании текст начинает кричать с первых же строк.
Однако, скорее всего, если ты ещё не погружен в эту тему, этот курс окажется намного глубже, чем ты сейчас ожидаешь.
Все эти присказки “однако”, “скорее всего”, “если ты ещё не...” очень сложно читать, их можно и нужно просто выбросить, они говорят скорее о неуверенности автора собственно текста, и его же огромном желании выглядеть солидно. Графомания как есть.
На Windows имеется компилятор mingw, который заявлен, как порт gcc на Windows.
Вот это “который заявлен как” о чём больше говорит — об опять-таки графомании, или о том, что ты не очень-то хорошо понимаешь, что такое mingw? Во-первых, mingw — не компилятор, а внушительный набор программ, среди которых есть и компилятор. Во-вторых, компилятор gcc в составе mingw не “заявлен как порт gcc на Windows”, а является портом gcc на Windows.
Clang. Данный компилятор имеет другой "путь" компиляции, в процессе которого используется язык llvm
Нет такого языка — llvm. Это буквально “низкоуровневая виртуальная машина” (low level virtual machine), “ассемблером” которой является байткод IR (буквально — language independent intermediate representaion, языково-независимое промежуточное представление).
Про “сигнатуры” я уже комментом выше написал.
Имейте ввиду, что значения чисел в C ограничены, и при их переполнении вы не получите никаких предупреждений или ошибок. (Когда такое происходит, процессор ставит флаг переполнения, но компилятор C для скорости даже не смотрит на него.)
А куда и как при исполнении написанной на C программы может “смотреть” компилятор? Отслеживать переполнения — не компиляторово дело. И это касается любых компилируемых языков. Компилятора к моменту переполнения не существует.
Далее пойдёт обрывочная информация, так как нет полной и чёткой документации о том, как работает компоновщик, и я обнаруживал сюрпризы.
Это к недостаточной квалификации. Игорь, если бы ты хорошо понимал устройство ELF (да и любого из предшественников вроде COFF или даже a.out), у тебя бы было сильно меньше сюрпризов и непоняток с работой линкера. В конце концов, у тебя есть его исходный код, написанный на известном тебе языке, а линкер в сущности своей — не такая уж сложная программа.
Почитаемый мной Э. Дейкстра писал “Использование антропоморфизмов в отношении вычислительных систем — признак профессиональной незрелости.” Компоновщик не лжёт. Никогда.
Резюме: отличная работа для личного использования, как набор шпаргалок, которые мы себе пишем и периодически правим и дописываем. Вот и эту ещё долго править и дописывать. Но как личный набор — действительно отлично. До книги — далеко. Как по форме, так и по содержанию.
Я бы с радостью помог тебе PR'ми, но в нынешнем виде речь может идти скорее не о правках, а о выбросить и переписать с нуля. С использованием либо формализованного, академического языка (скучно читать), либо простого разговорного (трудно писать), но не мозгодробильного микса обоих.
Я бы вообще рекомендовал избегать использования слова “сигнатура” в контексте C. Это абсолютно уместно в контексте C++ среди разработчиков компиляторов, где возможна перегрузка, и внутри компилятора надо иметь компактную и однозначную возможность идентифицировать конкретную функцию. Но для просто пользователей (программистов) в обоих языках всегда было и есть понятие “декларация функции”, “прототип” в конце концов.
int размером 2 байта видится древней экзотикой разве что только тем, кто родился, вырос и намертво прирос к x86 и gcc. 16-битных процессоров ещё куча производится и используется, особенно во всякой там ембедедовщине.
А говорить о реальных размерах типов в C следует опираясь на стандарт — там всё вполне себе формализовано.
Какое ещё выравнивание может быть у битов, неоднократно встречающееся в тексте? В разговорах о data alignment речь может вестись только об адресуемых сущностях. Назовите хотя бы одну архитектуру, пусть даже экспериментальную, в которой адрес есть у каждого отдельного бита в слове. А пока мы можем говорить только о тех единицах информации, которыми оперирует конкретный процессор — обычно это байты, слова, двойные и четверные слова, Важно при этом не только не путать их с конкретными типами в том или ином языке программирования, но и чётко понимать, как эти ЯВУ-типы отображаются на реальные процессорные объекты. Незнакомый с Rust знаток C вполне может наивно полагать, что char — это один байт в памяти, что почти всегда верно для C, и никогда — для Rust.
В том числе и поэтому разговоры о выравнивании почти бесполезны в отрыве от целевой архитектуры. Например, для какого-нибудь i8080 все эти выравнивания, что мёртвому припарка, поскольку время выборки байта по любому адресу — константа; на x86 слово по нечётному адресу будет добываться дольше, чем по чётному; а на LSI-11 эта же ситуация — “дёрнуть” слово по нечётному адресу, просто вызывает trap. На любом суперкомпьютере или на той же популярнейшей архитектуре amd64 необходимо учитывать даже конкретную модель процессора — два Core i7 могут быть ощутимо разными процессорами самым неочевидным для программиста образом. Хотя бы из-за разницы в размерах и организации кэшей. В результате смены процессора вся безопасность thread-safe data structures может рассыпаться, если на конкретном варианте процессора оно вдруг перестало влезать в cache row.
“Опроверг” — это значит, что предоставил убедительные доказательства. Что, понятно, в данной ситуации практически невозможно. Поэтому правильный заголовок этой новости должен гласить “«Яндекс» отрицает”, а не “«Яндекс» опроверг...”
Эти вот DAS, NAS и SAS в смысле Server Attached Storage — это именно про storage, даже не про диски, которых в хранилище (storage) может быть от 1 до много и даже очень много :)
А собственно SCSI — это не storage-интерфейс. Вот у меня, например, слайд-сканер подключается по SCSI.
Популярное “нечто вроде SCSI over Ethernet” — это про iSCSI, видимо? Хотя оно может быть over много что, потому как «i» — это от «ip», и физическая среда передачи команд SCSI тут особо не важна.
Удивляться нечему, параллельный канал с такими пропускными способностями, которые требуются сейчас (и тем более, потребуются завтра) — дорогое удовольствие. Во всех смыслах дорогое.
Ну, справедливости ради, SCSI в историю не только не “активно уходит”, но даже и не особо собирается, если не считать его действительно устаревшую за сорок с лишним лет Parallel-версию. В конце концов, SCSI — это больше протокол взаимодействия, чем физический канал, потому и процветают сегодня SAS (Serial Attached SCSI), UAS *(USB Attached SCSI), SCSI over Fibre Channel Protocol, iSCSI...
Так ведь приведённое мной из древнего СССР ничем сущностно не отличается от того, как нынче в интернетах объясняют “идиотскую парадигму cat/dog person.” О независимости и интроверсии “кошек” и эмоциональной привязанности и экстраверсии “собак.”
Я потому и сказал про огромную свинью в этом вопросе — любую из характеристик что “кошек”, что “собак” собеседующий может легко развернуть против кандидата.
сборка из исходников как ядра так и всей системы целиком вполне возможна силами пользователей, но сие не является ни каким-то особым достижением
Достижение не какое-то особое, конечно, но за почти 30 лет использования FreeBSD я единственный раз столкнулся (по причине power outage в процессе обновления) с фатальным несоответствием userland и kernel. В отличие от Linux, где это случается у многих и регулярно. А с учётом простоты и лёгкости, с которыми нынче (и уже давно) получается из исходников готовая и абсолютно целостная FreeBSD — достижение таки весьма ценное.
Разумеется отличия есть (временами существенные), но с годами их все меньше и меньше и тенденция — к все большей унификации и единообразию.
По-моему, с годами их наоборот становится всё больше и больше, если говорить в контексте “Linux-based OS versus any other Unix-like OS.” Хватило iproute2 и systemd, чтобы куча юниксоидов схватились за головы, восклицая “Линукс! Ты куда?!?!” И тенденция — в сторону “Таки Linux не только не Unix, но и от Unix-like с каждым днём всё дальше и дальше...”
В вопросе про кошку и собаку зарыта огромная свинья, и без раскопок в голове задающего сложно предположить, в какую сторону он развернёт любой из ответов. Как говорится, “оба хуже.” Самый разумный (при всей своей уклончивости) ответ — “Зависит от ситуации” :)
Вопрос происходит из очень-очень старого афоризма — в моих воспоминаниях это где-то на рубеже 70-х..80-х прошлого столетия — “Человек-кошка, в отличие от человека-собаки, никогда не бежит за отходящим автобусом — он знает, что будет следующий.”
25% — это в каком телевизоре сказали? Попробуйте уточнить на государственном портале правовых документов.
С 1-го января повышают 130 штрафов.
1 штраф — в 10 раз (на 900%);
34 штрафа — в 2.25 раза (на 125%);
94 штрафа — в 1.5 раза (на 50%).
И только 10 штрафов остаются без изменений. Расскажите, как у вас 25% получилось?
И от фазы Луны :)
За несколько лет в одном зале ни разу не сломались две PDP-11, несколько раз ломалась одна СМ-1420, и одна из двух СМ-4 после череды неисправностей в конце концов пошла на ЗИП для второй СМ-4.
А потом в другом зале я за несколько лет ни разу не видел “погоревшими” ни одного из двух HP-1000, которые там и до моего прихода чёрт знает сколько лет отработали, и ни одного из четырёх (два — стоечные, два — “пуфики”) MicroVAX.
Но пределы должны быть у всего. И разумные, желательно.
Автор считает, что 200 строк делают функцию большой и “грязной”? Так он просто больших функций не видел :) В одном чертовски популярном open source продукте (не уверен, что вспомнил точно, а уточнять прямо сейчас лениво, позже повспоминаю, но кажется это ffmpeg. Или нет? Но что-то про мультимедиа. Найду потом) есть функция, в которой почти шесть тысяч строк.
Ну, как тут не вспомнить Пола Грэхэма :)
Автор с упорством, достойным и более благородного применения, таскает из статьи в статью отсылку к фразе Э. Дейкстры, которую так криво перевели и изложили (вряд ли удастся достоверно установить, кто именно), что её можно понять даже в совершенно противоположном смысле.
Если прямо не указать (а в многократно использованном автором варианте прямого указания и нет), то кто угодно может прочитать не только так, как ожидает автор этого “перевода”, но и так, что переход запада на IBM и является величайшей победой в холодной войне.
Только вот Э. Дейкстра на той самой конференции в Риме в 1969 (которая не конференция НАТО, а конференция, спонсированная научным комитетом НАТО) сказал буквально:
Почувствуйте разницу.
Как делал я (вторая половина 70-х) в своём малюсеньком, никому неведомом, так как закрытом от всех вплоть до отсутствия на всех, кроме очень секретных, картах страны и сурового неупоминания во Внуково при посадке на Ту-154, городке на 30 тысяч населения: приходил в нужный момент в книжный магазин (в оба), брал там каталоги издательств с их планами выпуска книг на грядущий издательский период, заполнял по открытке на каждую интересную мне книгу, и оставлял их там. Потом ждал. Книжка издавалась, приезжала в наш город, магазин отгружал соответствующие открытки почте, почта приносила открытки мне, я клянчил у мамки копеечку и шёл с открыткой в магазин забирать отложенный для меня экземпляр.
Да, это не работало с книжками про бравых мушкетёров, красавицу маркизу и лихих ковбоев, для этого кроме планов издательства надо было иметь в магазине главное — блат™ Но с книгами от «Мир», «Радио и Связь», «Финансы и Статистика» и прочими издателями интересной нам литературы чаще прокатывало, чем нет. Потому у меня и случилась довольно впечатляющая библиотека, и даже многомудрые дядьки-программисты аж из самой Москвы, коих работало у нас множество, нередко обращались ко мне “Дай на недельку, законспектировать.”
Принципиально отличие в том, что
• C23 — прототип функции, не принимающей параметров;
• до C23 — объявление функции без информации о параметрах.
При том, что хоть в С23, хоть в предыдущих стандартах
равнозначно
То есть, стандарты по-разному трактовали объявление функции, являющееся её же определением, или не являющимся таковым.
Игорь, я пробежал по диагонали почти весь текст книги, и увидел с одной стороны хороший задел на перспективу, а с другой — графоманский продукт специалиста, который недостаточно квалифицирован в том, о чём он взялся писать.
О графомании текст начинает кричать с первых же строк.
Все эти присказки “однако”, “скорее всего”, “если ты ещё не...” очень сложно читать, их можно и нужно просто выбросить, они говорят скорее о неуверенности автора собственно текста, и его же огромном желании выглядеть солидно. Графомания как есть.
Вот это “который заявлен как” о чём больше говорит — об опять-таки графомании, или о том, что ты не очень-то хорошо понимаешь, что такое
mingw? Во-первых,mingw— не компилятор, а внушительный набор программ, среди которых есть и компилятор. Во-вторых, компиляторgccв составеmingwне “заявлен как портgccнаWindows”, а является портомgccнаWindows.Нет такого языка —
llvm. Это буквально “низкоуровневая виртуальная машина” (low level virtual machine), “ассемблером” которой является байткод IR (буквально — language independent intermediate representaion, языково-независимое промежуточное представление).Про “сигнатуры” я уже комментом выше написал.
А куда и как при исполнении написанной на C программы может “смотреть” компилятор? Отслеживать переполнения — не компиляторово дело. И это касается любых компилируемых языков. Компилятора к моменту переполнения не существует.
Это к недостаточной квалификации. Игорь, если бы ты хорошо понимал устройство ELF (да и любого из предшественников вроде COFF или даже a.out), у тебя бы было сильно меньше сюрпризов и непоняток с работой линкера. В конце концов, у тебя есть его исходный код, написанный на известном тебе языке, а линкер в сущности своей — не такая уж сложная программа.
Почитаемый мной Э. Дейкстра писал “Использование антропоморфизмов в отношении вычислительных систем — признак профессиональной незрелости.” Компоновщик не лжёт. Никогда.
Резюме: отличная работа для личного использования, как набор шпаргалок, которые мы себе пишем и периодически правим и дописываем. Вот и эту ещё долго править и дописывать. Но как личный набор — действительно отлично. До книги — далеко. Как по форме, так и по содержанию.
Я бы с радостью помог тебе PR'ми, но в нынешнем виде речь может идти скорее не о правках, а о выбросить и переписать с нуля. С использованием либо формализованного, академического языка (скучно читать), либо простого разговорного (трудно писать), но не мозгодробильного микса обоих.
Удачи!
И да, принимает ли аргументы функция, описание которой не содержит ни описания параметров, ни эллипсиса, зависит от версии стандарта C.
Я бы вообще рекомендовал избегать использования слова “сигнатура” в контексте C. Это абсолютно уместно в контексте C++ среди разработчиков компиляторов, где возможна перегрузка, и внутри компилятора надо иметь компактную и однозначную возможность идентифицировать конкретную функцию. Но для просто пользователей (программистов) в обоих языках всегда было и есть понятие “декларация функции”, “прототип” в конце концов.
int размером 2 байта видится древней экзотикой разве что только тем, кто родился, вырос и намертво прирос к x86 и gcc. 16-битных процессоров ещё куча производится и используется, особенно во всякой там ембедедовщине.
А говорить о реальных размерах типов в C следует опираясь на стандарт — там всё вполне себе формализовано.
Какое ещё выравнивание может быть у битов, неоднократно встречающееся в тексте? В разговорах о data alignment речь может вестись только об адресуемых сущностях. Назовите хотя бы одну архитектуру, пусть даже экспериментальную, в которой адрес есть у каждого отдельного бита в слове. А пока мы можем говорить только о тех единицах информации, которыми оперирует конкретный процессор — обычно это байты, слова, двойные и четверные слова, Важно при этом не только не путать их с конкретными типами в том или ином языке программирования, но и чётко понимать, как эти ЯВУ-типы отображаются на реальные процессорные объекты. Незнакомый с Rust знаток C вполне может наивно полагать, что char — это один байт в памяти, что почти всегда верно для C, и никогда — для Rust.
В том числе и поэтому разговоры о выравнивании почти бесполезны в отрыве от целевой архитектуры. Например, для какого-нибудь i8080 все эти выравнивания, что мёртвому припарка, поскольку время выборки байта по любому адресу — константа; на x86 слово по нечётному адресу будет добываться дольше, чем по чётному; а на LSI-11 эта же ситуация — “дёрнуть” слово по нечётному адресу, просто вызывает trap. На любом суперкомпьютере или на той же популярнейшей архитектуре amd64 необходимо учитывать даже конкретную модель процессора — два Core i7 могут быть ощутимо разными процессорами самым неочевидным для программиста образом. Хотя бы из-за разницы в размерах и организации кэшей. В результате смены процессора вся безопасность thread-safe data structures может рассыпаться, если на конкретном варианте процессора оно вдруг перестало влезать в cache row.
И немного о семантике.
“Опроверг” — это значит, что предоставил убедительные доказательства. Что, понятно, в данной ситуации практически невозможно. Поэтому правильный заголовок этой новости должен гласить “«Яндекс» отрицает”, а не “«Яндекс» опроверг...”
И не ошибался, ведь и RTFM не только популярный ответ на тривиальные вопросы, но и Realtime Traffic Flow Measurement :)
Эти вот DAS, NAS и SAS в смысле Server Attached Storage — это именно про storage, даже не про диски, которых в хранилище (storage) может быть от 1 до много и даже очень много :)
А собственно SCSI — это не storage-интерфейс. Вот у меня, например, слайд-сканер подключается по SCSI.
Популярное “нечто вроде SCSI over Ethernet” — это про iSCSI, видимо? Хотя оно может быть over много что, потому как «i» — это от «ip», и физическая среда передачи команд SCSI тут особо не важна.
Удивляться нечему, параллельный канал с такими пропускными способностями, которые требуются сейчас (и тем более, потребуются завтра) — дорогое удовольствие. Во всех смыслах дорогое.
Ну, справедливости ради, SCSI в историю не только не “активно уходит”, но даже и не особо собирается, если не считать его действительно устаревшую за сорок с лишним лет Parallel-версию. В конце концов, SCSI — это больше протокол взаимодействия, чем физический канал, потому и процветают сегодня SAS (Serial Attached SCSI), UAS *(USB Attached SCSI), SCSI over Fibre Channel Protocol, iSCSI...
bash, в отличие от perl, с текстом работать практически не умеет. В bash-скриптах почти вся работа с текстом осуществляется внешними программами.
Так ведь приведённое мной из древнего СССР ничем сущностно не отличается от того, как нынче в интернетах объясняют “идиотскую парадигму cat/dog person.” О независимости и интроверсии “кошек” и эмоциональной привязанности и экстраверсии “собак.”
Я потому и сказал про огромную свинью в этом вопросе — любую из характеристик что “кошек”, что “собак” собеседующий может легко развернуть против кандидата.
Достижение не какое-то особое, конечно, но за почти 30 лет использования FreeBSD я единственный раз столкнулся (по причине power outage в процессе обновления) с фатальным несоответствием userland и kernel. В отличие от Linux, где это случается у многих и регулярно. А с учётом простоты и лёгкости, с которыми нынче (и уже давно) получается из исходников готовая и абсолютно целостная FreeBSD — достижение таки весьма ценное.
По-моему, с годами их наоборот становится всё больше и больше, если говорить в контексте “Linux-based OS versus any other Unix-like OS.” Хватило iproute2 и systemd, чтобы куча юниксоидов схватились за головы, восклицая “Линукс! Ты куда?!?!” И тенденция — в сторону “Таки Linux не только не Unix, но и от Unix-like с каждым днём всё дальше и дальше...”
В вопросе про кошку и собаку зарыта огромная свинья, и без раскопок в голове задающего сложно предположить, в какую сторону он развернёт любой из ответов. Как говорится, “оба хуже.” Самый разумный (при всей своей уклончивости) ответ — “Зависит от ситуации” :)
Вопрос происходит из очень-очень старого афоризма — в моих воспоминаниях это где-то на рубеже 70-х..80-х прошлого столетия — “Человек-кошка, в отличие от человека-собаки, никогда не бежит за отходящим автобусом — он знает, что будет следующий.”