ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
965849 Топик полностью
Связанные сообщения
TypingMultidimensionalCppMetaprogramming
Вы просто не умеете его готовить. Я бы мог бесконечно показывать примеры, но это непробиваемо. Сразу авторитетно докажут, что у ...2022-09-30
Embedded Template Library (iar arm 9.20.4)2022-05-18
Наброшу.2021-12-06
В C++ доступна вся C-библиотека. Когда C++ сам себе разумеется нет, а как ты себе представляешь? Можешь написать свою реализацию...2020-09-23
Ты хочешь static_if, которого в C++ в чистом виде нет. constexpr if это совсем не то, т.к. он неизбежно будет компилиров...2020-07-02
В общем случае может быть 2-3 подхода перечисленных ниже. В базе всегда SFINAE -- шаблон откидывается и просматриваются следующи...2020-07-02
Надо понимать, что класс -- это не структура. Применительно к C++ мне больше нравится слово тип. Тип -- это сущность существующа...2020-04-26
C#, Java и тем более Javascript -- это совсем другой код, нежели C++. На порядок менее оптимальный, если конечно задача не своди...2019-12-19
С языком очень даже связано. Компилирующие языки со статической типизацией (C++, C#, Java, C, Pascal) пропускают гораздо меньше ...2019-12-17
Не совсем. C++ -- это уход в сторону _типизированных_ ЯВУ, а Java или C# -- подвижка в сторону "управляемого кода" и что наиболе...2019-11-03
Да конечно, ну вот расскажи, как оно работает -->2019-10-25
Мне какой-то куб для Renesas вспомнился, лет 6 тому назад. Они хвалились, что у них код компилится сразу, как его пишешь. В итог...2019-10-25
Увы, часто нет. Ардуины не просто так возникли. МК подросли и стали возможны другие подходы к разработке. Видно же что делается:...2019-03-03
Не соглашусь, во-первых я чётко подвёл к мысли, что возможны разные классификации, существование одних не запрещает другие. И ес...2019-03-03
С этого стоило и начинать. С того, что язык скриптовый. И это уводит совсем в другую сторону, практически в параллельную вселенн...2019-03-01
Для этого просто существуют разные языки! Смотри вторую ссылку: 2017-11-29
Утиная типизация - это оно? -> -->2017-11-28
EvgenyCD! Смотри ссылку! Я понял, что это круче чем swig, например, в определённых обстоятельствах. Правда руки применять надо...2017-02-09
Это свойство практически любого языка с динамической типизацией. Здесь питон притянут за уши. Но это НЕГАТИВНОЕ свойство для бол...2010-01-13
fk0, легенда (19.12.2019 02:28, просмотров: 1339) ответил RxTx на 2.
Я говорю про другую типизацию. Не про int или long, и даже не про int или char*. Программа на ООП-языке существует в рамкой некой модели, где есть понятие типа как класса и возможных операций над типами. И существует во-первых возможность выбора операции, диспетчеризации метода, в зависимости от типа самого класса, возможность автоматического преобразования типа, возможность выбора перегруженной функции, во-вторых не все операции применимы для всех типов, не у всех типов есть определённые функции. И попытка совместить несовместимое кончается в одних языках ошибкой компиляции, а в других ошибкой во время исполнения. Последнее намного хуже, т.к. протестировать все возможные пути исполнения программы -- невозможно. Для ПО определённого класса такое поведение недопустимо, для ПО других классов (развлекательная веб-страничка) -- даже не критично. Нужно понимать, что в C++ многомерный язык программирования. По меньшей мере трёхмерный. И есть несколько реально ортогональных пространств понятий. И пространство типов, существующее во время компиляции, и которое только может быть воображаемо во время исполнения -- одно из них. Я про эти типы. Параллельно и независимо существуют данные, которые могут представляться в двух ипостасях, реальной (constexpr), существующей во время компиляции, или мнимой, когда сущность обретается только в момент исполнения. И конечно данные тоже имеют какой-то layout в памяти и связанный с ними тип структуры, но этот не тот тип, а другой из ортогонального измерения. Ещё есть макросы C-процессора, они тоже из своего ортогонального пространства. И не нужно всё мешать в кучу. У голого C нет пространства типов, C -- двухмерный язык программирования. У него есть только пространство типов как layout в памяти, причём оно совсем уж "плоское" -- в отличии от C++ вложенные типы невозможны, пространств имён нет, и разделение возможно только на уровне единицы компиляции. Хотя даже в этом плоском пространстве разные типы (структуры) -- различимы и подсунуть другой тип в функцию, например, не удастся. И что важно, пространство типов в C++ позволяет задавать правила по автоматическому выбору функций на основе типов заданных аргументов, вычислению самих типов в зависимости от других типов или констант, вычислению констант (значений) на основе других значений или типов. На неком уже декларативном языке. Вот здесь -- метапрограммирование. Когда задаётся набор правил и по заданным правилам и входным данным генерируется программа (результат интересно разглядывать на https://cppinsights.io/). А в голом C нужно всё конкретно расписывать руками (императивное программирование). Что естественно легко в простейших случаях и невозможно чуть в более сложных -- становится сложно, объёмно, и в ход идут друге решения. И вот в C#/Java, для сравнения, механизм типов есть, но ограничен на уровне C++ 90-х годов. Полиморфизм ограничен виртуальными функциями (с диспетчеризацией во время исполнения, со спотыканиями оптимизатора на каждом уровне косвенности), есть наследование (причём нет множественного наследования, только интерфейсы). Есть пользовательские преобразования типов. Но сами типы уже неизменны в том виде как написаны программистом, динамическое, в момент компиляции, создание типов, вычисление типов на основе данных или других типов -- невозможно, вообще любые вычисления в пространстве типов -- невозможны. Только так же как в C# нет макропроцессора. Т.е. программа компилируется как написана, никакого метапрограммирования. Я не уверен про Java, может быть там есть бОльшие возможности, знаком с этим языком поверхностно. Но во всяком случае в C#/Java есть понятие различимых типов данных и компилятор может проверить и выдать ошибку о несоответствии, а если код скомпилировался, то скорей может корректно работать. А в скриптовых языках, в Javascript, в Python -- это не так. Там код даже если скомпилируется в байткод, и в JIT-код, то может выдать ошибку будучи запущенным, из-за того, что применили какую-либо непредусмотренную операцию над как бы другим типом, хотя там все типы -- Object, String и integer, условно говоря. И это реальная проблема, как я сказал выше, невозможно протестировать абсолютно все сценарии. Значит любая более-менее сложная программа на скриптовом языке будет изобиловать багами. И самое важное, о них нельзя узнать заранее, как в случае языков со статической типизацией, где такие баги не проходят дальше компилятора. И есть ещё ньюансы, exception safety, например. Пытаясь что-то программировать на питоне можно сталкиваться с постоянно возникающими именно уже в момент исполнения ошибками (вплоть до синтаксических, perl по-моему имеет более "надёжный" компилятор), в частности вызванными чем-то вроде отсутствия записи с данным ключём в словаре и т.п. И после знакомства с C++ совершенно непонятно как так можно писать сколько-нибудь надёжные программы: в C++ я знаю, что если есть функция, то либо она noexcept, и она как-то не сработает и возможно вернёт ошибку, либо она может вызвать исключения, и об этом известно из документации, декларации и т.п. и я могу писать try-catch вокруг. А в питоне любая функция может свалить программу. Конечно, кто-то скажет, что лучше пусть свалит -- заодно и исправишь. А я опять отвечу, что все случаи протестировать невозможно, и проблема возникнет обязательно когда не нужно, а не в тесте. И хуже когда это делают безобидные библиотечные функции. В принципе в perl/tcl похожая ситуация, только натыкаться на проблемные случаи приходится почему-то реже, не знаю почему.
[ZX]