Mikhail писал(а):Алексей, умоляю, больше не пишите мне.
Михаил, если Вы сами не умеете программировать, если у Вас проблемы с математикой, если у Вас проблемы с логикой, если Вы не знаете значений таких слов как "сущность", то зачем Вы пишите на этом форуме?
Есть такие прекрасные профессии, как дворник, портной, повар. Это для Вас будет лучшим выбором.
Судя по всему Ваш опыт программирования настолько узок, что у Вас все программы одинаковы по своей сути. Для этих программ достаточно обычного integer, оптимизированного под конкретную платформу, и Вы думаете, что не бывает других задач. Вот поэтому я и считаю, что программирование - это не Ваша профессия (хотя Вы вполне можете иметь успех в узкой области), Вы чистой воды гуманитарий, с несистемным мышлением.
Добавлено спустя 58 минут 21 секунду:debi12345 писал(а):Оценка цены проверки диапазона если таковую реализовать в рантайме для типов вроде "integer from 0 to 10" или integer{5}. Если задаешь точный диапазон, то подразумевается что будешь его проверять не только на этапе компиляции
Мне кажется, что оценка на вхождение в диапазон, как на этапе компиляции, так в runtime, если и нужна, то очень и очень редко. Я сходу не вспомнил задач, где такое бы требовалось. Если знаете, то расскажите. Такое бывает нужно при вводе, то тогда при выходе нужно генерировать не исключение, а предупреждение для пользователя. Иногда нужно проверять результат вычисления, но опять же нужно не исключение, а выдача сообщений, ранжированных исходя из полученных значений.
Добавлено спустя 27 минут 3 секунды:Если обобщить разговоры про целочисленные типы, то никто не смог опровергнуть предложение (разных авторов), которое можно сформулировать следующим образом:
- есть один целочисленный тип - int или integer (это уже на вкус, мне лично нравится более краткий int).
- к этому целочисленному типу можно применять несколько модификаторов:
- признак беззнаковости (по умолчанию знаковый);
- признак минимальной разрядности, указанный в битах (по умолчанию выбирается оптимальный под конкретную платформу), если указана разрядность отличающаяся от 16, 32, 64, 128, то либо компилятор дает ошибку, либо сам округляет вверх до ближайшего (17 округлит до 32).
- признак фиксирования размера переменной (8, 16, 32, 64), и порядка чередования байтов (BE, LE), что требуется только для описания блоков данных при выполнении ввода/вывода (файл, порт, сеть).
- естественно, что при операциях с целочисленными переменными имеющими разные модификаторы, компилятор будет генерировать дополнительный машинный код для преобразования типов, но для программиста ничего не нужно писать вручную.
С позиции программиста, мы имеем одну сущность (целочисленная переменная), которая имеет вариации по внутренней реализации. Я предполагаю, что в 95% кода будет использоваться только int и int32. Все остальные модифицированные типы нужны, но используются редко, поэтому никакого оверхеда не будет в реальных программах.
С позиции компилятора, каждый модифицированный тип - это отдельная сущность, требующая генерации индивидуального машинного кода. Но когда обсуждается язык программирования высокого уровня, то упрощают жизнь программиста и только программиста, но не компилятора. Поэтому сущности с позиции компилятора обсуждать просто глупо.
Раз зашел вопрос про сущности, то достаточно бессмысленно отделять сущности самого языка и сущности базовых библиотек. С позиции чистой теории - это разные категории. Но с практической позиции, это одно и тоже. Беда практически всех современных языков (в их современной реализации, например, FPC) в том, что сам язык относительно лаконичен, но библиотеки, даже базовые - это полный кошмар, никакой общей логики, применяются совершенно разные подходы. Поэтому в данном случае имеет смысл обсудить не только базовые конструкции языка, но и базовые типы (включая строковые), и базовые библиотеки (хотя бы на уровне требований к ним, и принципа их построения).
Поэтому если задумывать новый язык программирования, то нужно обдумать не только сам язык, но и принципы написания библиотек и работы с ними. Беда современного кода на языке высокого уровня в том, что если ты глубоко не знаешь конкретную библиотеку, которую применил другой программист, то ты по сути не можешь полноценно читать чужой код. В идеале хорошо написанный код, с использованием хороших библиотек, должен являться самодокументированным. То есть для его прочтения не должно требоваться использование справочников и подсказок, вся необходимая информация должна быть иименно в этом коде, в том числе информация о всех "подводных камнях". Конечно, если человек, читающий код, имеет базовые знания о математике, программировании и предметной области решаемой задачи.