Плюс, критика временами проистекает из-за использования языков, где без сборки мусора обойтись невозможно, -- т.е. где разработчик вынужден поступать так, как требует язык, а не так, как было бы правильней в конкретной ситуации. Но, вообще говоря, глупо ругать инструмент (хоть язык, хоть сборщик мусора), если его используют для неподходящей задачи.
Скорей, концепции, используемые на уровне машинного языка и ассемблера, как его прямого отражения, являются куда более простыми и поэтому лёгкими для восприятия. Ну и, кроме того, Це++ -- один из наиболее сложных и запутанных языков программирования, с сильно неоднозначным для нетренированного взгляда синтаксисом и т.д. и т.п. (попробуй пойми без предварительного знакомства с языком, где массив указателей, а где -- указатель на массив; а вот в Паскале с подобными вещами никаких проблем из-за более ясного синтаксиса).
Ну, IBM ещё в конце 19 века возникла, хотя и не под этим названием. Ну а насчёт статьи можно заметить, что в том же 1967-м, когда мы выкатили БЭСМ-6 с её 1 млн оп/с, CDC выкатила свою очередную машину -- кажись, 6600, но точно не помню. Её процессор был первым суперскалярным в истории и в пике выдавал до 10 млн. оп/с. Так что у буржуинов всю жизнь техника была не хуже нашей, хотя и неправильно говорить, что мы только и занимались, что воровали, -- истина, как обычно, где-то между.
Да и про влияние выравнивания и его необходимость тоже. Скажем, на IA-32 (x86) базовый набор команд не требует какого-либо выравнивания операндов, но производительность от этого таки зависит. А вот операнды SSE уже должны быть выровнены в обязательном порядке, если правильно помню. А в ARMах допустимость невыровненных операндов зависит от разновидности архитектуры. Ну и т.д. и т.п.
Вообще, сколько тактов выполняется та или иная команда и насколько они могут совмещаться, зависит и от команды, и от конкретной реализации. Даже концептуальный порядок, предполагающий, что команды выполняются строго по одной и строго последовательно, работает лишь до определённого предела -- но это уже зависит не от реализации, а от архитектуры. Хелловорлд на асме, как правило, можно написать, не углубляясь в эти мелочи, а вот что-то более-менее сложное...
Причём у упоминаемого здесь ARM слово как раз 4 байта, а 2 байта -- это полуслово. Кстати, 64-разрядной является архитектура ARMv8-A, а вот все более ранние, а также ARMv8-M -- 32-разрядные.
А ещё биты могут нумероваться не справа налево, а наоборот (0 -- старший): так дело обстоит в ИБМовской Системе 360 и её потомках, включая современную z/Architecture.
С IBM сравнение не вполне корректное. Для них IBM PC была, по сути, игрушкой, и от железа они отнюдь не отказались -- они отказались именно от персоналок. Ну а мэйнфреймы z/Architecture выпускаются до сих пор -- это, вероятно, самая старая их компьютерных архитектур в мире (растёт из Системы 360, анонсированной в 1964-м, и сохраняет с ней совместимость на уровне прикладного кода).
Вообще-то, 4004 -- отнюдь не первый массовый ЦП. Это первый доступный (не секретный) микропроцессор, но компьютеры к моменту его появления выпускались уже порядка 25 лет -- и все они имели центральные процессоры. Ну а что они были выполнены (и ещё достаточно долго выполнялись) на целой куче деталек, а не в виде единственной микросхемы -- это технические подробности, а не принципиальное различие.
А у американцев в том же 1967-м пошла в серию одна из машин CDC -- не помню точно, какая именно модель, но зато помню, что она имела первый в истории суперскалярный процессор и, естественно, была многократно сложней БЭСМ-6. И ничего, работала-с. Так что никакой фантастики в создании сложных систем "в древности" нет. Правда, квалификация тогдашнего среднего разработчика и современного различалась, подозреваю, даже не в разы, а на порядки.
Есть лицензии свободного ПО, которые запрещают свободное использование?
Не знаю, как современная версия GPL, а старые версии налагали крайне жёсткие ограничения -- не менее жёсткие, чем у проприетарного софта. Фактически, они делали невозможным использование того же Линуха во многих коммерческих проектах (хотя всё равно использовали, просто тщательно прятали концы в воду, чтобы, например, не раскрывать те модификации, которые вносили в Линух). А вот лицензия BSD, кажется, реально свободная: используй как хошь, в т.ч. можешь модифицировать, не открывая твой код, и т.д. и т.п.
не совсем корректная отсылка к целым числам в плане знака числа: целые-то хранятся в дополнительном коде, а вещественные -- в прямом, о чём стоило б сказать явным образом; кроме того, у вещественных есть знак мантиссы (собственно знак числа), а есть знак порядка (замаскированный из-за использования смещённого порядка);
некоторый бардак с хронологией, из-за чего возникает впечатление, что некоторые игры не работали на некоторых видюхах в 1960-70-е, хотя сие имело место, на самом-то деле, в 2000-х, и не из-за формата представления вещественных чисел как такового (IEEE 754 уж давно стандартом стал), а из-за разного набора обеспечиваемых аппаратных возможностей. DirectX, конечно, в каждой своей версии требует наличия некоего минимума, но производители вольны добавлять необязательные возможности по своему усмотрению;
не нашёл упоминания нормализации чисел. Вообще, думаю, неплохо было бы пошагово расписать выполнение арифметических операций, чтоб читателю было бы понятнее, как числа обрабатываются машиной;
можно было б для полноты картины упомянуть, что вещественные числа не всегда представляются как в степени 2 -- например, в Системе 360 используется степень 16, из-за чего при равном числе битов диапазон много шире, а вот точность хуже;
говоря о IEEE 754, неплохо б сказать, что лишь часть стандарта обязательна к реализации. Так, в зависимости от платформы выбор способа округления может предоставляться, а может и не предоставляться, ненормализованные числа могут поддерживаться, а могут превращаться в нуль, и т.д. Понятно, что статья вводная, но упомянуть о потенциальных проблемах стоило б, чтоб, кому оно интересно или надо, стал бы копать вглубь (и знал бы, в какую именно сторону).
А с чего взяли, что секционные микросхемы Am29xx (превратившиеся у нас в серию 1804) -- по лицензии Интел? Сама Интел их не выпускала; у неё был свой секционный комплект i3xxx (у нас превратился в серию 589), но он ничего общего, кроме секционности, с АМДшным не имел.
Ну так потому Микрософт и взлетела, что её шеф, даже не будучи сам великим программистом, разбирался в этом виде деятельности и мог грамотно нанимать специалистов. В принципе, то же самое относится к любой технической компании. HP тоже была крута, пока ей рулили Хьюлетт и Паккард Ну а в чём разбираются финансисты, кроме как в распиле бабла? (Понятно, что бывают исключения -- но они лишь подтверждают правило)
"Еще раз: вы не сможете нормально размещать экземпляры таких непрозрачных структур на стеке или внутри других объектов."
(не пойму, как здесь делать цитаты...)
1) Это не всегда нужно -- например, правильней может быть хранение именно указателя на объект, а не самого объекта.
2) С эффективностью это не очень-то связано. Если Вы передаёте в функцию сам объект, Вы как раз теряете в эффективности, а если всегда передаётся только указатель, то зачем хранить объект в стеке? Особенно объект потенциально долгоиграющий, который должен сохраняться при выходе из функции, где он создаётся, а соответственно, создаваемый в динамически выделяемой памяти, а не в стеке? (То же открытие классического файла).
"Инкапсуляция к этому отношения не имеет вообще."
Имеет. То, что функции не связаны между собой параметрами, не означает, что между ними нет никакой внутренней связи. Скажем, несколько функций, выводящих разную информацию через один и тот же отладочный интерфейс.
Я ж и говорю: это может быть неудобно/костыльно. Надо из задачи исходить. Скажем, если нужно реализовать несколько связанных между собой достаточно низкоуровневых функций -- типа классического ввода-вывода в стиле C, -- то нет никакой нужды объединять их в класс, достаточно непрозрачной структуры а-ля FILE и хранения указателя на неё для передачи в качестве параметра. Если нужны несколько функций, связанных только назначением, но не параметрами, тогда и структуры такой не требуется -- просто несколько объявлений лежат вместе в одном заголовке, и всё.
Ну, если брать уж совсем общие случаи, то да -- кроссплатформенного решения нет, придётся писать ручками или тащить реализованное кем-то другим для конкретных платформ.
Что же до ссылки на пример неправильного разбора, то, на первый взгляд, проблема в реализации библиотеки, а не в принципиальной невозможности сделать правильный разбор -- т.е. имеет место баг или недоработка, что можно (и нужно) исправить в следующей версии. Но честно скажу, что глянул бегло, не вникая.
Ну и, кроме того, даже если я прав и это баг в библиотеке, всё равно остаётся проблема обеспечения кроссплатформенности здесь и сейчас, а не когда все баги исправят, -- так что, решение может быть теоретически кроссплатформенным, а на практике -- не совсем... В общем, надо исходить из задачи и из реального списка необходимых платформ, а не пытаться сделать решение "сферическое в вакууме".
Примерно так, да -- "голые" функции (и публично доступные структуры, необходимые для взаимодействия с ними -- для параметров, например, или, как в Вашем примере, только их объявления, но не определения, для сокрытия их содержимого), а не методы (функции) классов. Разве что, при необходимости всё это можно "завернуть" в отдельное пространство имён. Можно, конечно, все их поместить внутрь недокласса -- но особого смысла не вижу.
Плюс, критика временами проистекает из-за использования языков, где без сборки мусора обойтись невозможно, -- т.е. где разработчик вынужден поступать так, как требует язык, а не так, как было бы правильней в конкретной ситуации. Но, вообще говоря, глупо ругать инструмент (хоть язык, хоть сборщик мусора), если его используют для неподходящей задачи.
Скорей, концепции, используемые на уровне машинного языка и ассемблера, как его прямого отражения, являются куда более простыми и поэтому лёгкими для восприятия. Ну и, кроме того, Це++ -- один из наиболее сложных и запутанных языков программирования, с сильно неоднозначным для нетренированного взгляда синтаксисом и т.д. и т.п. (попробуй пойми без предварительного знакомства с языком, где массив указателей, а где -- указатель на массив; а вот в Паскале с подобными вещами никаких проблем из-за более ясного синтаксиса).
Ну, IBM ещё в конце 19 века возникла, хотя и не под этим названием. Ну а насчёт статьи можно заметить, что в том же 1967-м, когда мы выкатили БЭСМ-6 с её 1 млн оп/с, CDC выкатила свою очередную машину -- кажись, 6600, но точно не помню. Её процессор был первым суперскалярным в истории и в пике выдавал до 10 млн. оп/с. Так что у буржуинов всю жизнь техника была не хуже нашей, хотя и неправильно говорить, что мы только и занимались, что воровали, -- истина, как обычно, где-то между.
Да и про влияние выравнивания и его необходимость тоже. Скажем, на IA-32 (x86) базовый набор команд не требует какого-либо выравнивания операндов, но производительность от этого таки зависит. А вот операнды SSE уже должны быть выровнены в обязательном порядке, если правильно помню. А в ARMах допустимость невыровненных операндов зависит от разновидности архитектуры. Ну и т.д. и т.п.
Вообще, сколько тактов выполняется та или иная команда и насколько они могут совмещаться, зависит и от команды, и от конкретной реализации. Даже концептуальный порядок, предполагающий, что команды выполняются строго по одной и строго последовательно, работает лишь до определённого предела -- но это уже зависит не от реализации, а от архитектуры. Хелловорлд на асме, как правило, можно написать, не углубляясь в эти мелочи, а вот что-то более-менее сложное...
Причём у упоминаемого здесь ARM слово как раз 4 байта, а 2 байта -- это полуслово. Кстати, 64-разрядной является архитектура ARMv8-A, а вот все более ранние, а также ARMv8-M -- 32-разрядные.
А ещё биты могут нумероваться не справа налево, а наоборот (0 -- старший): так дело обстоит в ИБМовской Системе 360 и её потомках, включая современную z/Architecture.
В общем, косяков по мелочи найти можно немало.
С IBM сравнение не вполне корректное. Для них IBM PC была, по сути, игрушкой, и от железа они отнюдь не отказались -- они отказались именно от персоналок. Ну а мэйнфреймы z/Architecture выпускаются до сих пор -- это, вероятно, самая старая их компьютерных архитектур в мире (растёт из Системы 360, анонсированной в 1964-м, и сохраняет с ней совместимость на уровне прикладного кода).
Ну дык смешались в кучу кони, люди...
Вообще-то, 4004 -- отнюдь не первый массовый ЦП. Это первый доступный (не секретный) микропроцессор, но компьютеры к моменту его появления выпускались уже порядка 25 лет -- и все они имели центральные процессоры. Ну а что они были выполнены (и ещё достаточно долго выполнялись) на целой куче деталек, а не в виде единственной микросхемы -- это технические подробности, а не принципиальное различие.
А у американцев в том же 1967-м пошла в серию одна из машин CDC -- не помню точно, какая именно модель, но зато помню, что она имела первый в истории суперскалярный процессор и, естественно, была многократно сложней БЭСМ-6. И ничего, работала-с. Так что никакой фантастики в создании сложных систем "в древности" нет. Правда, квалификация тогдашнего среднего разработчика и современного различалась, подозреваю, даже не в разы, а на порядки.
Не знаю, как современная версия GPL, а старые версии налагали крайне жёсткие ограничения -- не менее жёсткие, чем у проприетарного софта. Фактически, они делали невозможным использование того же Линуха во многих коммерческих проектах (хотя всё равно использовали, просто тщательно прятали концы в воду, чтобы, например, не раскрывать те модификации, которые вносили в Линух). А вот лицензия BSD, кажется, реально свободная: используй как хошь, в т.ч. можешь модифицировать, не открывая твой код, и т.д. и т.п.
Угу, то была VAX/VMS.
Ну, про это я писать не стал, поскольку сие касается программирования, а не внутреннего устройства конкретной модели.
Сама по себе статья, конечно, полезна. Но:
очень много ошибок в плане русского языка;
не совсем корректная отсылка к целым числам в плане знака числа: целые-то хранятся в дополнительном коде, а вещественные -- в прямом, о чём стоило б сказать явным образом; кроме того, у вещественных есть знак мантиссы (собственно знак числа), а есть знак порядка (замаскированный из-за использования смещённого порядка);
некоторый бардак с хронологией, из-за чего возникает впечатление, что некоторые игры не работали на некоторых видюхах в 1960-70-е, хотя сие имело место, на самом-то деле, в 2000-х, и не из-за формата представления вещественных чисел как такового (IEEE 754 уж давно стандартом стал), а из-за разного набора обеспечиваемых аппаратных возможностей. DirectX, конечно, в каждой своей версии требует наличия некоего минимума, но производители вольны добавлять необязательные возможности по своему усмотрению;
не нашёл упоминания нормализации чисел. Вообще, думаю, неплохо было бы пошагово расписать выполнение арифметических операций, чтоб читателю было бы понятнее, как числа обрабатываются машиной;
можно было б для полноты картины упомянуть, что вещественные числа не всегда представляются как в степени 2 -- например, в Системе 360 используется степень 16, из-за чего при равном числе битов диапазон много шире, а вот точность хуже;
говоря о IEEE 754, неплохо б сказать, что лишь часть стандарта обязательна к реализации. Так, в зависимости от платформы выбор способа округления может предоставляться, а может и не предоставляться, ненормализованные числа могут поддерживаться, а могут превращаться в нуль, и т.д. Понятно, что статья вводная, но упомянуть о потенциальных проблемах стоило б, чтоб, кому оно интересно или надо, стал бы копать вглубь (и знал бы, в какую именно сторону).
А с чего взяли, что секционные микросхемы Am29xx (превратившиеся у нас в серию 1804) -- по лицензии Интел? Сама Интел их не выпускала; у неё был свой секционный комплект i3xxx (у нас превратился в серию 589), но он ничего общего, кроме секционности, с АМДшным не имел.
Ну так потому Микрософт и взлетела, что её шеф, даже не будучи сам великим программистом, разбирался в этом виде деятельности и мог грамотно нанимать специалистов. В принципе, то же самое относится к любой технической компании. HP тоже была крута, пока ей рулили Хьюлетт и Паккард Ну а в чём разбираются финансисты, кроме как в распиле бабла? (Понятно, что бывают исключения -- но они лишь подтверждают правило)
"Еще раз: вы не сможете нормально размещать экземпляры таких непрозрачных структур на стеке или внутри других объектов."
(не пойму, как здесь делать цитаты...)
1) Это не всегда нужно -- например, правильней может быть хранение именно указателя на объект, а не самого объекта.
2) С эффективностью это не очень-то связано. Если Вы передаёте в функцию сам объект, Вы как раз теряете в эффективности, а если всегда передаётся только указатель, то зачем хранить объект в стеке? Особенно объект потенциально долгоиграющий, который должен сохраняться при выходе из функции, где он создаётся, а соответственно, создаваемый в динамически выделяемой памяти, а не в стеке? (То же открытие классического файла).
"Инкапсуляция к этому отношения не имеет вообще."
Имеет. То, что функции не связаны между собой параметрами, не означает, что между ними нет никакой внутренней связи. Скажем, несколько функций, выводящих разную информацию через один и тот же отладочный интерфейс.
Я ж и говорю: это может быть неудобно/костыльно. Надо из задачи исходить. Скажем, если нужно реализовать несколько связанных между собой достаточно низкоуровневых функций -- типа классического ввода-вывода в стиле C, -- то нет никакой нужды объединять их в класс, достаточно непрозрачной структуры а-ля FILE и хранения указателя на неё для передачи в качестве параметра. Если нужны несколько функций, связанных только назначением, но не параметрами, тогда и структуры такой не требуется -- просто несколько объявлений лежат вместе в одном заголовке, и всё.
Ну, если брать уж совсем общие случаи, то да -- кроссплатформенного решения нет, придётся писать ручками или тащить реализованное кем-то другим для конкретных платформ.
Что же до ссылки на пример неправильного разбора, то, на первый взгляд, проблема в реализации библиотеки, а не в принципиальной невозможности сделать правильный разбор -- т.е. имеет место баг или недоработка, что можно (и нужно) исправить в следующей версии. Но честно скажу, что глянул бегло, не вникая.
Ну и, кроме того, даже если я прав и это баг в библиотеке, всё равно остаётся проблема обеспечения кроссплатформенности здесь и сейчас, а не когда все баги исправят, -- так что, решение может быть теоретически кроссплатформенным, а на практике -- не совсем... В общем, надо исходить из задачи и из реального списка необходимых платформ, а не пытаться сделать решение "сферическое в вакууме".
Примерно так, да -- "голые" функции (и публично доступные структуры, необходимые для взаимодействия с ними -- для параметров, например, или, как в Вашем примере, только их объявления, но не определения, для сокрытия их содержимого), а не методы (функции) классов. Разве что, при необходимости всё это можно "завернуть" в отдельное пространство имён. Можно, конечно, все их поместить внутрь недокласса -- но особого смысла не вижу.