Всё статическое выполняется на этапе разработки, а всё динамическое - на этапе исполнения. Интерпретация - часть процесса исполнения, поэтому интерпретируемые реализации языков и диалектов ничего истинно статического не поддерживают. Даже если кто то сможет сделать интерпретируемый c и там типизация будет выглядеть как статическая. На самом деле это её динамическая имитация. Значения переменных известны только на этапе исполнения, а константы проверять не надо. Соответственно осмысленная проверка значения может быть только динамической. Ну кроме случаев условной компиляции, но тогда не понятно, откуда такое заковыристое условие условной компиляции.Skwoogey писал(а):А можно слегка приоткрыть завесу слов "Статическая и runtime проверки", пожалуйста? Хочется немного в тему войти.
Как проверить, что число не нан?
Модераторы: Hawk, Romeo, Absurd, DeeJayC, WinMain
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.
Как тогда проверка может быть статической? как на этапе разработки можно проверить, что лежит в переменной, которой даже в памяти не существует пока что? Разницу между интерпретацией и компиляцией я представляю. Разницу между статическим и динамическим выделением тоже. Как проверку к этим привязать не понимаю. Какая разница, что программе проверять, если адрес этого есть?
В переменной? Или в величине? Вот в чём хитрость. Не всякая величина переменна. Есть ещё макросы, литералы и константы, они известны на этапе разработки и могут быть проверены статически. В результате можно, изменив всего несколько символов в одном месте, существенно изменить код, иногда разбросанный по всей программе. Это и есть условная компиляция. Только обычно на c++ проверяется всё таки не значение, а факт существования. Но в принципе можно написать препроцессор, компилятор, или саму среду с поддержкой условной компиляции с условиями на значения. Предусмотрен ли такой вид условной компиляции в более менее распространённых софтинах, тем более включен ли в стандарт, мне не известно. Но в принципе такая условная компиляция возможна. А о переменных на этапе разработки известно только как их зовут, какие у них типы, сколько они должны занимать места в памяти и по каким смещениям и от чего лежат. Ну ещё инициируются ли они и чем именно. Сама программа на момент статических проверок, статического связывания, статической типизации... ещё даже не запущена и ничего проверять не может. Мало того, исполняемого её варианта просто нет, она существует только в исходном тексте, максимум в сыром объектом коде. Поэтому сама разрабатываемая программа занимается только динамическими проверками. Но если она инструментальная, то для приложений, разрабатываемых с её помощью такие проверки будет статическими в том случае, если реализуется компиляция. Но в тех программах статически проверяется другое, вовсе не внутреннее представление макросов, констант и литералов в инструментальной программе. И константа не обязана иметь адрес, например, на многих компилируемых реализациях паскаля значения всех констант, чьи типы вводятся компилятором, подставляются при компиляции. На c++ нет аналога. Типизация этих констант статическая не явная, выглядит похоже на динамическую (и не явная, и динамическая типизация - это типизация на основе значения и в момент получения значения, но не явная статическая типизация - это типизация на основе первого или единственного значения в момент его получения, а динамическая типизация может быть и на основе каждого значения в моменты каждого изменения), что языком c++ не предусмотрено в принципе. Квалификатор const - не то же самое, что заголовок const. На c++ const лишь защищает от изменения нечто, похожее на переменную. Но величины, объявленные в разделе const на паскале - это и не макросы, так как константы во-первых имеют область видимости, а макросы её не имеют, а во-вторых константы хоть как то типизированы, а макросы не типизированы вовсе.
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.
- Romeo
- Сообщения: 3126
- Зарегистрирован: 02 мар 2004, 17:25
- Откуда: Крым, Севастополь
- Контактная информация:
Ты забавный человек. Если ты чего-то не знаешь, то считаешь, что этого не существует. Статические проверки используются в метапрограммировании, и как раз в метапрограммировании и будет полезно использование std::numeric_limits<double>::quiet_NaN(). Подумать только, с 2008 года не мог понять, зачем нужен метод, и за эти 9 лет даже не удосужился погуглить. Ровно как и сейчас не додумался погуглить есть ли в природе статическая проверка. Сионист, такой Сионист...Сионист писал(а):Ну эту то разницу я знаю с 2001-го. С тех пор, как узнал о самом существовании RTTI. Не в отличие ли от Вас? По крайней мере статическую проверку значений смогли сморозить лишь Вы.
Entites should not be multiplied beyond necessity @ William Occam
---
Для выделения С++ кода используйте конструкцию [ code=cpp ] Код [ /code ] (без пробелов)
---
Сообщение "Спасибо" малоинформативно. Благодарность правильнее высказать, воспользовавшись кнопкой "Reputation" в виде звёздочки, расположенной в левом нижнем углу рамки сообщения.
---
Для выделения С++ кода используйте конструкцию [ code=cpp ] Код [ /code ] (без пробелов)
---
Сообщение "Спасибо" малоинформативно. Благодарность правильнее высказать, воспользовавшись кнопкой "Reputation" в виде звёздочки, расположенной в левом нижнем углу рамки сообщения.
Примерно понял. Спасибо.
Ну я ж не философ.Romeo писал(а):Подумать только, с 2008 года не мог понять, зачем нужен метод, и за эти 9 лет даже не удосужился погуглить.
Я про неё давно знаю. Но статическая проверка чего?Romeo писал(а):Ровно как и сейчас не додумался погуглить есть ли в природе статическая проверка. Сионист, такой Сионист...
Зачем? Для выбора того, какой в итоге код нужен, условие слишком заковыристо. Можно и попонятней его определить. Вот резервированный массив даблов - совсем другое дело, нет тех элементов, которые nan. Всё просто и понятно. А как этот nan относится к варианту кода не понятно.Romeo писал(а):и как раз в метапрограммировании и будет полезно использование std::numeric_limits<double>::quiet_NaN()
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.
- Romeo
- Сообщения: 3126
- Зарегистрирован: 02 мар 2004, 17:25
- Откуда: Крым, Севастополь
- Контактная информация:
Сионист, я тебе ещё раз советую почитать о метапрограммировании. Из твоих ответов понятно, что ты вообще не слышал, что это такое.
One more time: если ты не знаешь, для чего что-то нужно, это не значит, что это что-то является бесполезной глупостью. Статическая проверка статического значения времени компиляции - это не фантастика. И свой компилятор для этого писать не нужно. Это уже и так есть в C++.
One more time: если ты не знаешь, для чего что-то нужно, это не значит, что это что-то является бесполезной глупостью. Статическая проверка статического значения времени компиляции - это не фантастика. И свой компилятор для этого писать не нужно. Это уже и так есть в C++.
Entites should not be multiplied beyond necessity @ William Occam
---
Для выделения С++ кода используйте конструкцию [ code=cpp ] Код [ /code ] (без пробелов)
---
Сообщение "Спасибо" малоинформативно. Благодарность правильнее высказать, воспользовавшись кнопкой "Reputation" в виде звёздочки, расположенной в левом нижнем углу рамки сообщения.
---
Для выделения С++ кода используйте конструкцию [ code=cpp ] Код [ /code ] (без пробелов)
---
Сообщение "Спасибо" малоинформативно. Благодарность правильнее высказать, воспользовавшись кнопкой "Reputation" в виде звёздочки, расположенной в левом нижнем углу рамки сообщения.
Вы ломитесь не просто в открытую дверь, а в дверь, в которую уже вошли.Romeo писал(а):если ты не знаешь, для чего что-то нужно, это не значит, что это что-то является бесполезной глупостью. Статическая проверка статического значения времени компиляции - это не фантастика.
Ну есть так есть. В чём проблема? Вот только плавающие типы и так то для сравнение не удобны. МожетRomeo писал(а):И свой компилятор для этого писать не нужно. Это уже и так есть в C++.
Код: Выделить всё
double x=0.5;
double y=1.0/2.0;
if (x==y)
Код: Выделить всё
LET x=0.5
LET y=1/2
IF x=y THEN
Ну есть так есть. В чём проблема? Путать значения с типами помогает как то совсем не это.Romeo писал(а):И свой компилятор для этого писать не нужно. Это уже и так есть в C++.
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.
- Romeo
- Сообщения: 3126
- Зарегистрирован: 02 мар 2004, 17:25
- Откуда: Крым, Севастополь
- Контактная информация:
Я постоянно ловлю себя на том, что забываю в чём именно был вопрос, когда начинаю отвечать на твои сообщения. Очень много воды, по которой ты уплываешь в заоблачные дали. При чём тут бейсик? Кто путает значения с типами? Кто вообще все эти люди? Более того, ты написал страницей раньше, что решение, которое тебе предложили, подходит. Тем не менее ты продолжаешь заниматься словоблудием. Есть конкретная проблема, которая требует рассмотрения?
P.S. В приведённом примере кода на С++ грубейшая ошибка. Два значения с плавающей точкой нельзя сравнивать на равенство. Этому учат ещё в университете в курсе численных методов.
P.S. В приведённом примере кода на С++ грубейшая ошибка. Два значения с плавающей точкой нельзя сравнивать на равенство. Этому учат ещё в университете в курсе численных методов.
Entites should not be multiplied beyond necessity @ William Occam
---
Для выделения С++ кода используйте конструкцию [ code=cpp ] Код [ /code ] (без пробелов)
---
Сообщение "Спасибо" малоинформативно. Благодарность правильнее высказать, воспользовавшись кнопкой "Reputation" в виде звёздочки, расположенной в левом нижнем углу рамки сообщения.
---
Для выделения С++ кода используйте конструкцию [ code=cpp ] Код [ /code ] (без пробелов)
---
Сообщение "Спасибо" малоинформативно. Благодарность правильнее высказать, воспользовавшись кнопкой "Reputation" в виде звёздочки, расположенной в левом нижнем углу рамки сообщения.
Вот именно.Romeo писал(а):P.S. В приведённом примере кода на С++ грубейшая ошибка. Два значения с плавающей точкой нельзя сравнивать на равенство. Этому учат ещё в университете в курсе численных методов.
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.