Вообще-то, 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 и хранения указателя на неё для передачи в качестве параметра. Если нужны несколько функций, связанных только назначением, но не параметрами, тогда и структуры такой не требуется -- просто несколько объявлений лежат вместе в одном заголовке, и всё.
Ну, если брать уж совсем общие случаи, то да -- кроссплатформенного решения нет, придётся писать ручками или тащить реализованное кем-то другим для конкретных платформ.
Что же до ссылки на пример неправильного разбора, то, на первый взгляд, проблема в реализации библиотеки, а не в принципиальной невозможности сделать правильный разбор -- т.е. имеет место баг или недоработка, что можно (и нужно) исправить в следующей версии. Но честно скажу, что глянул бегло, не вникая.
Ну и, кроме того, даже если я прав и это баг в библиотеке, всё равно остаётся проблема обеспечения кроссплатформенности здесь и сейчас, а не когда все баги исправят, -- так что, решение может быть теоретически кроссплатформенным, а на практике -- не совсем... В общем, надо исходить из задачи и из реального списка необходимых платформ, а не пытаться сделать решение "сферическое в вакууме".
Примерно так, да -- "голые" функции (и публично доступные структуры, необходимые для взаимодействия с ними -- для параметров, например, или, как в Вашем примере, только их объявления, но не определения, для сокрытия их содержимого), а не методы (функции) классов. Разве что, при необходимости всё это можно "завернуть" в отдельное пространство имён. Можно, конечно, все их поместить внутрь недокласса -- но особого смысла не вижу.
В заголовочном файле разместить только интерфейсную часть, а всю реализацию, включая внутренние структуры данных, -- в .cpp. Правда, этот способ может быть неудобным/костыльным, если нужно создать несколько однотипных объектов (по сути, наборов данных), не давая при этом доступа к их внутренней реализации. В такой ситуации более правильным, скорей всего, будет использование "недокласса": class/struct с разделением на public/private, но без виртуальных функций и без наследования.
С типичными современными файловыми системами (FAT, NTFS, EXT...) можно, используя std::filesystem::path, доступный в C++17, о чём тут уже сказали. Вот если нужна работа с древними или нестандартными файловыми системами -- там да, проблематично придумать что-то кроссплатформенное. Но в реальной жизни сейчас такое если и встречается, то крайне редко.
Ну, 8080 действительно был очень популярен, и Z80, хотя и превзошёл его по популярности, был программно совместим с 8080 -- собственно, это и стало одной из причин его популярности. Нередко Z80 использовался именно как более быстрая и удобная для электронщика (одно напряжение питания и готовые управляющие сигналы шины) замена 8080, при этом программы оставались старые, рассчитанные на 8080, и не использовали дополнительные возможности Z80,
Слово с точки зрения электронщика действительно связано с аппаратной реализацией, но оно может не соотносится со словом с точки зрения программиста. ЕС-1020 -- архитектурно 32-разрядная машина (Система 360), однако имеет 8-битовое АЛУ и 18-битовую ширину доступа к ОЗУ (16 информационных и два контрольных разряда). ЕС-1050 -- это тоже 32-разрядная машина (та же Система 360), но основное АЛУ там 64 бита, если память не изменяет, а слово памяти -- 72 бита (8 информационных байтов плюс по одному контрольному биту на каждый байт). Ну и чему тут будет равен размер слова, если исходить из аппаратуры, а не архитектуры (т.е. представления машины с точки зрения программиста)? Плюс исторический контекст влияет. Вот отсюда и весь хаос с этим термином.
Точней, Минск-2, -22 и -32. Ну и добавлю, что путаница может возникать ещё и из-за разного представления машинного слова для программиста и электронщика. Скажем, для программиста Система 360 (ЕС ЭВМ) -- всегда 32-разрядная, однако в зависимости от модели память могла быть организована по-разному (у ЕС-1020 ширина доступа -- 18 бит, из коих два -- контрольные разряды для двух информационных байтов, у ЕС-1035 -- 72 бита: 8 информационных байтов плюс восемь разрядов для контроля и коррекции по коду Хэмминга, и т.п.), поэтому электронщик, рассуждая о памяти, мог использовать термин "слово" по отношению к физическому слову памяти, а не в том значении, в котором его использует программист.
Ну а в Системе 360 или в ARM, которые изначально были 32-разрядными, слово -- именно 32 бита, а 16 бит -- полуслово. Поэтому и путаница с этим термином, но автору статьи явно было лень посмотреть на историю разных архитектур.
На момент появления байта US ASCII была 7-битной кодировкой, насколько помню; 8-битной ASCII стал уже в 1970-80-х. RADIX-50 позволял плотнее упаковывать символы для экономии памяти, что было важно для мини-ЭВМ с их небольшой разрядностью (64 Кбайта адресуемой памяти, если говорить про наиболее популярные PDP-11; VAX можно не рассматривать, ибо это уже вторая половина 1970-х). В то же время, эта кодировка очень ограничивала набор символов: собственно, только большие английские буквы, цифры и ещё несколько знаков, что совершенно недостаточно во многих задачах (из-за этого, кстати, столь ограничен был набор допустимых символов в именах файлов на PDP-11). Кроме того, упаковка-распаковка требовали выполнения дополнительных операций, т.е. прилично снижали производительность.
Ну дык смешались в кучу кони, люди...
Вообще-то, 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 и хранения указателя на неё для передачи в качестве параметра. Если нужны несколько функций, связанных только назначением, но не параметрами, тогда и структуры такой не требуется -- просто несколько объявлений лежат вместе в одном заголовке, и всё.
Ну, если брать уж совсем общие случаи, то да -- кроссплатформенного решения нет, придётся писать ручками или тащить реализованное кем-то другим для конкретных платформ.
Что же до ссылки на пример неправильного разбора, то, на первый взгляд, проблема в реализации библиотеки, а не в принципиальной невозможности сделать правильный разбор -- т.е. имеет место баг или недоработка, что можно (и нужно) исправить в следующей версии. Но честно скажу, что глянул бегло, не вникая.
Ну и, кроме того, даже если я прав и это баг в библиотеке, всё равно остаётся проблема обеспечения кроссплатформенности здесь и сейчас, а не когда все баги исправят, -- так что, решение может быть теоретически кроссплатформенным, а на практике -- не совсем... В общем, надо исходить из задачи и из реального списка необходимых платформ, а не пытаться сделать решение "сферическое в вакууме".
Примерно так, да -- "голые" функции (и публично доступные структуры, необходимые для взаимодействия с ними -- для параметров, например, или, как в Вашем примере, только их объявления, но не определения, для сокрытия их содержимого), а не методы (функции) классов. Разве что, при необходимости всё это можно "завернуть" в отдельное пространство имён. Можно, конечно, все их поместить внутрь недокласса -- но особого смысла не вижу.
В заголовочном файле разместить только интерфейсную часть, а всю реализацию, включая внутренние структуры данных, -- в .cpp. Правда, этот способ может быть неудобным/костыльным, если нужно создать несколько однотипных объектов (по сути, наборов данных), не давая при этом доступа к их внутренней реализации. В такой ситуации более правильным, скорей всего, будет использование "недокласса": class/struct с разделением на public/private, но без виртуальных функций и без наследования.
С типичными современными файловыми системами (FAT, NTFS, EXT...) можно, используя std::filesystem::path, доступный в C++17, о чём тут уже сказали. Вот если нужна работа с древними или нестандартными файловыми системами -- там да, проблематично придумать что-то кроссплатформенное. Но в реальной жизни сейчас такое если и встречается, то крайне редко.
Ну, 8080 действительно был очень популярен, и Z80, хотя и превзошёл его по популярности, был программно совместим с 8080 -- собственно, это и стало одной из причин его популярности. Нередко Z80 использовался именно как более быстрая и удобная для электронщика (одно напряжение питания и готовые управляющие сигналы шины) замена 8080, при этом программы оставались старые, рассчитанные на 8080, и не использовали дополнительные возможности Z80,
Слово с точки зрения электронщика действительно связано с аппаратной реализацией, но оно может не соотносится со словом с точки зрения программиста. ЕС-1020 -- архитектурно 32-разрядная машина (Система 360), однако имеет 8-битовое АЛУ и 18-битовую ширину доступа к ОЗУ (16 информационных и два контрольных разряда). ЕС-1050 -- это тоже 32-разрядная машина (та же Система 360), но основное АЛУ там 64 бита, если память не изменяет, а слово памяти -- 72 бита (8 информационных байтов плюс по одному контрольному биту на каждый байт). Ну и чему тут будет равен размер слова, если исходить из аппаратуры, а не архитектуры (т.е. представления машины с точки зрения программиста)? Плюс исторический контекст влияет. Вот отсюда и весь хаос с этим термином.
Точней, Минск-2, -22 и -32. Ну и добавлю, что путаница может возникать ещё и из-за разного представления машинного слова для программиста и электронщика. Скажем, для программиста Система 360 (ЕС ЭВМ) -- всегда 32-разрядная, однако в зависимости от модели память могла быть организована по-разному (у ЕС-1020 ширина доступа -- 18 бит, из коих два -- контрольные разряды для двух информационных байтов, у ЕС-1035 -- 72 бита: 8 информационных байтов плюс восемь разрядов для контроля и коррекции по коду Хэмминга, и т.п.), поэтому электронщик, рассуждая о памяти, мог использовать термин "слово" по отношению к физическому слову памяти, а не в том значении, в котором его использует программист.
Ну а в Системе 360 или в ARM, которые изначально были 32-разрядными, слово -- именно 32 бита, а 16 бит -- полуслово. Поэтому и путаница с этим термином, но автору статьи явно было лень посмотреть на историю разных архитектур.
На момент появления байта US ASCII была 7-битной кодировкой, насколько помню; 8-битной ASCII стал уже в 1970-80-х. RADIX-50 позволял плотнее упаковывать символы для экономии памяти, что было важно для мини-ЭВМ с их небольшой разрядностью (64 Кбайта адресуемой памяти, если говорить про наиболее популярные PDP-11; VAX можно не рассматривать, ибо это уже вторая половина 1970-х). В то же время, эта кодировка очень ограничивала набор символов: собственно, только большие английские буквы, цифры и ещё несколько знаков, что совершенно недостаточно во многих задачах (из-за этого, кстати, столь ограничен был набор допустимых символов в именах файлов на PDP-11). Кроме того, упаковка-распаковка требовали выполнения дополнительных операций, т.е. прилично снижали производительность.