Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
1. Неявных приведений типов: (YourClass) myobject
2. Явных приведений типов: (myobject as YourClass)
3. Проверок типов: myobject is YourClass
4. Интроспекции: myobject.GetType()
5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам
Здравствуйте, naf2000, Вы писали:
N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет: N>1. Неявных приведений типов: (YourClass) myobject N>2. Явных приведений типов: (myobject as YourClass) N>3. Проверок типов: myobject is YourClass N>4. Интроспекции: myobject.GetType() N>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам
Если отказаться от ООП — наверно можно C считается "ЯП с жесткой типизацией"? Да и на С# можно при желании в процедурном стиле наваять достаточно сложную программу.
Только точно не нужно.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет: N>1. Неявных приведений типов: (YourClass) myobject N>2. Явных приведений типов: (myobject as YourClass) N>3. Проверок типов: myobject is YourClass N>4. Интроспекции: myobject.GetType() N>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам
Здравствуйте, naf2000, Вы писали:
N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
Можно. На Haskell программы так и пишутся. Причём довольно сложные: компиляторы, системы контроля версий.
Здравствуйте, Temoto, Вы писали:
N>>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет: N>>1. Неявных приведений типов: (YourClass) myobject
Типа нельзя привести int к double? Ты поясни, какие именно типы нельзя приводить. А то вот ты хочешь поделить 3 на 5, а в доброй половине языков это будет 0 потому что целочисленная арифметика. И если ты хочешь получить плавающий результат, то тебе так или иначе придется приводить аргумент к плавающему типу.
N>>2. Явных приведений типов: (myobject as YourClass)
То же самое.
N>>3. Проверок типов: myobject is YourClass
В рантайме или во время компиляции?
N>>4. Интроспекции: myobject.GetType()
См. №3.
N>>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам
Исключения — удобный инструмент сообщения об ошибках. Можно, конечно, написать все на кодах возврата, но зачем?
В общем, непонятна цель ограничений. Это какие-то реальные ограничения или так, поговорить?
Здравствуйте, naf2000, Вы писали:
N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет: N>1. Неявных приведений типов: (YourClass) myobject N>2. Явных приведений типов: (myobject as YourClass) N>3. Проверок типов: myobject is YourClass N>4. Интроспекции: myobject.GetType() N>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам
Интересно, в контексте этих ограничений является ли вызов унарного конструктора в С++ явным приведением типов?
Если нет, замена (YourClass) myobject на YourClass(myobject) — воркэраунд на первое ограничение.
Здравствуйте, naf2000, Вы писали:
N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет: N>1. Неявных приведений типов: (YourClass) myobject N>2. Явных приведений типов: (myobject as YourClass) N>3. Проверок типов: myobject is YourClass N>4. Интроспекции: myobject.GetType() N>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам
Видел и участвовал на плюсах в проектах-миллиониках, где не используется dynamic_cast<>, а в меньших по размерам проектах не используется и подавно. Даже сложно сходу придумать, где бы dynamic_cast<> был нужен в плюсах, в отсутствии остальной метаинформации.
Жесткое, в стиле C приведение если и используется, то где-нить в протоколах, сериализованные структуры собирать/разбирать, ибо такое приведение получается гораздо эффективней, чем читать побайтно и сдвигать 8 раз (на x64), вместо того, чтобы сразу прочесть машинное слово.
Ну и еще можно вспомнить про размеченные объединения (алгебраические типы). Их можно сделать жестко-типизированными и безопасными в использовании даже для С, но это именно способ динамической типизации, реализованный в рамках инструментария статической.
Здравствуйте, vdimas, Вы писали:
V>Ну и еще можно вспомнить про размеченные объединения (алгебраические типы). Их можно сделать жестко-типизированными и безопасными в использовании даже для С, но это именно способ динамической типизации, реализованный в рамках инструментария статической.
Разве это не динамическая диспетчеризация, которую предоставлют механизмы сопоставления с образцом?
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, naf2000, Вы писали:
N>>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
N>Можно. На Haskell программы так и пишутся. Причём довольно сложные: компиляторы, системы контроля версий.
Ну там Type Test заменяется неполным\wildcard паттерном в функции.
Напрмер
data T = A|B|C
f :: T -> a
f A = ...
f _ = ...
фактически функция f эквивалентна конструкции
if (t is A) {} else {}
Только PM оптимизирован для таких операций, а type test в ООП наоборот.
Здравствуйте, minorlogic, Вы писали:
M>Скажу больше, надо стараться именно так и писать все время.
M>Только по приведению типов я не понял , считается ли приведения потомку к предку неявным приведением ?
Нет, это использование принципа подстановки на практике.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, minorlogic, Вы писали:
M>>Скажу больше, надо стараться именно так и писать все время.
M>>Только по приведению типов я не понял , считается ли приведения потомку к предку неявным приведением ?
H>Нет, это использование принципа подстановки на практике.
Мгм ... ну тогда именно так и необходимо писать , а вы пишете по другому (вопрос не лчно к hardcase а риторически )?
Здравствуйте, hardcase, Вы писали:
V>>Ну и еще можно вспомнить про размеченные объединения (алгебраические типы). Их можно сделать жестко-типизированными и безопасными в использовании даже для С, но это именно способ динамической типизации, реализованный в рамках инструментария статической.
H>Разве это не динамическая диспетчеризация, которую предоставлют механизмы сопоставления с образцом?
Да как не назови, но реально в рантайм проверяется тип и происходит ветвление согласно признака типа, существующего в памяти рядом с полезными данными. В любом случае, это динамический полиморфизм, примерно как вызов виртуального метода.
Чем же такой подход отличается от обычных скриптовых нетипизированных языков? Лишь тем, что еще в статике задаются ограничения мн-в типов значений, принимаемых в динамике. Например, подтипом дотнетного System.Object является любой дотнетный тип (кроме unsafe указателей), а подтипом варианта Хаскеля — лишь ограниченное множество типов, перечисленное в виде конструкторов варианта.
Здравствуйте, nikov, Вы писали:
N>Можно. На Haskell программы так и пишутся. Причём довольно сложные: компиляторы, системы контроля версий.
Вряд ли алгебраические типы попадают под понятие "жесткой типизации". Это же абсолютные аналоги VARIANT из COM. Но ведь упомянутый VARIANT по общему мнению за динамическую фичу COM-а сходил. Или надо было вопрошающему определить для нас своё понимание "жесткой типизации".
В общем, это всё рантайм полиморфизм, и мы имеем лишь различные механизмы его реализации: где-то в виде виртуальных ф-ий, где-то в виде алгебраических типов, а где-то в виде ссылки на полное описание типа, как в managed или скриптовых языках. И в общем случае, что можно написать на одной системе с рантайм-полиморфизмом, можно в очень похожем виде (т.е. без дорогостоящей эмуляции отсутствующих фич) написать на другой системе с рантайм-полиморфизмом.
Здравствуйте, vdimas, Вы писали:
V>>>Ну и еще можно вспомнить про размеченные объединения (алгебраические типы). Их можно сделать жестко-типизированными и безопасными в использовании даже для С, но это именно способ динамической типизации, реализованный в рамках инструментария статической.
V>Чем же такой подход отличается от обычных скриптовых нетипизированных языков? Лишь тем, что еще в статике задаются ограничения мн-в типов значений, принимаемых в динамике.
Отличие языков со встроенной поддержкой алгебраических типов данных от языков, в которых происходит их эмуляция существующими средствами (Си)в том, что первые умеют (и об уже говорилось) делать консервативные предположения: проверять целостность сопоставления с образцом, тогда как вторые языки делать этого не умеют и оставляют программисту возможность ошибиться.
Здравствуйте, hardcase, Вы писали:
H>Отличие языков со встроенной поддержкой алгебраических типов данных от языков, в которых происходит их эмуляция существующими средствами (Си)в том, что первые умеют (и об уже говорилось) делать консервативные предположения: проверять целостность сопоставления с образцом, тогда как вторые языки делать этого не умеют и оставляют программисту возможность ошибиться.
Это зависит от реализации алгебраических типов. Например, там где доступ к членам варианта реализован через статически компилируемый визитор (очень похоже на диспетчеризацию ф-ий в Хаскеле), то линкер просто не скомпилирует программу, если не будут даны определения для всех типов, составляющих вариант, или же, аналогично использования хаскелевского терма '_', не будет дано некоторого определения по-умолчанию.
Там только единственный слабый момент в этой архитектуре — это случай использования одного и того же типа внутри варианта более одного раза, но с разными дискриминаторами.
Решается с помощью способности С++ специализировать шаблоны константами. Т.е. вариант мог бы быть типизирован не просто типом хранимого значения, а парой: значение дискриминатора+тип. И все без дополнительных расходов в рантайм.
Здравствуйте, vdimas, Вы писали:
V>Вряд ли алгебраические типы попадают под понятие "жесткой типизации". Это же абсолютные аналоги VARIANT из COM. Но ведь упомянутый VARIANT по общему мнению за динамическую фичу COM-а сходил. Или надо было вопрошающему определить для нас своё понимание "жесткой типизации".
V>В общем, это всё рантайм полиморфизм, и мы имеем лишь различные механизмы его реализации: где-то в виде виртуальных ф-ий, где-то в виде алгебраических типов, а где-то в виде ссылки на полное описание типа, как в managed или скриптовых языках. И в общем случае, что можно написать на одной системе с рантайм-полиморфизмом, можно в очень похожем виде (т.е. без дорогостоящей эмуляции отсутствующих фич) написать на другой системе с рантайм-полиморфизмом.
В общем, если в программе есть if, то она тоже пролетает.
Здравствуйте, jazzer, Вы писали:
N>>>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам J>Исключения — удобный инструмент сообщения об ошибках. Можно, конечно, написать все на кодах возврата, но зачем?