Приветствую, игппук, вы писали:
и> C>Прямой доступ к памяти и ручные манипуляции указателями это бомба с часовым механизмом. и> вы правы. указатели и прямой доступ к памяти — это игрушки не для детей.
Угу, еще палец невзначай оторвет. Не, ненадо давать детям такое. Пусть в пеесочке вон играются...
Здравствуйте, Pzz, Вы писали:
Pzz>Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
Ты откровенно переврал исходную историю.
Как раз количество смертей на дорогах резко снизилось, но повысилось количество аварий.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
M>>Будут ошибки, связанные не с манипуляцией указателями, а с манипуляцией индексами. Если код перевести на C#, то ошибка никуда не исчезнет, но сразу проявится при запуске.
C>Не будет ошибки — трудноуловимого бага, как в С++, будет исключение с сообщением о том, что индекс за пределами диапазона.
Точно такой же bullshit. При тестировании у тебя не вылетает, и в продакшн идет подукт с этим багом. Вот клиенту полегчает от эксепшена.
Да еще если код у тебя без debug-info, да еще если обфускированный, то сообщение об ошибке не поможет локализовать ситуацию даже через user feedback.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Это зависит. Если говорить по жабу и .НЕТ то да. А если почистить систему типов и добавить зависимые типы то там можно и некорректные алгоритмы отлавливать.
Вроде как в .NET 4.0 появились Code Contracts. Чем .NET классы с code contracts отличаются от зависимых типов?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>Вроде как в .NET 4.0 появились Code Contracts. Чем .NET классы с code contracts отличаются от зависимых типов?
Примерно тем же самым чем статическая типизация отличается от динамической.
Мало того что Code Contracts могут делать лишь часть того на что способны ЗТ но даже для этой части нет гарантии того что проверки будут статическими.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Примерно тем же самым чем статическая типизация отличается от динамической. WH>Мало того что Code Contracts могут делать лишь часть того на что способны ЗТ.
Можно примеры таких фич?
WH>Но даже для этой части нет гарантии того что проверки будут статическими.
Вроде как Code Contracts это в первую очередь статические проверки (есть опция проверять в рантайме, но это не основное их предназначение).
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>Можно примеры таких фич?
WH>>Но даже для этой части нет гарантии того что проверки будут статическими.
nme>Вроде как Code Contracts это в первую очередь статические проверки (есть опция проверять в рантайме, но это не основное их предназначение).
Почитай хотя бы этот документ. http://download.microsoft.com/download/C/2/7/C2715F76-F56C-4D37-9231-EF8076B7EC13/userdoc.pdf
Там от слова runtime в глазах рябит.
Например этот тип при помощи горы кода может быть (я не уверен и проверять лень) получится нарисовать на Code Contracts
type IndexedMesh[Vertex : #, vertexCount : uint, indexCount : uint]
vertices : array[Vertex, vertexCuont];
indices : array[uintLimited[vertexCount], indexCount];
end
Но ты гарантированно получишь кучу проверок времени исполнения.
2.7 Quantifiers
Limited support is available for quantifiers within contracts. We support only those forms which are executable at runtime. This currently means that the range of quantification must be effectively computable.
Also, the “body” of each quantification must be an expression, i.e., not contain any loops or assignment statements. 2.7.1 ForAll
Universal quantifications are written using Contract. ForAll . ...
А этот код Code Contracts вообще никак проверить не смогут
for (i in mesh.indices.Indices)
def vertex = mesh.vertices[mesh.indices[i]];
...
end
В тоже время ЗТ не только все проверят на этапе компиляции но и гарантированно не вставят проверки времени исполнения ибо есть формальное доказательство их не нужности.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Модульные тесты и "безопасные" языки - хорошо.
WH>Но ты гарантированно получишь кучу проверок времени исполнения. WH>
WH>2.7 Quanti?ers
WH>Limited support is available for quanti?ers within contracts. We support only those forms which are executable at runtime. This currently means that the range of quanti?cation must be effectively computable.
WH>Also, the “body” of each quanti?cation must be an expression, i.e., not contain any loops or assignment statements.
WH>2.7.1 ForAll
WH>Universal quanti?cations are written using Contract. ForAll . ...
В общем понятно. Для generic типов в .NET в качестве generic параметра можно передать только тип (т.е. нельзя передать int например). Отсюда невозможность статической проверки коллекций.
Можно сделать обёртку над массивом что-то вроде ArrayOfUintLimited, то что происходит в нутри неё придётся самому проверять, но такой код
WH>
WH>for (i in mesh.indices.Indices)
WH> def vertex = mesh.vertices[mesh.indices[i]];
WH> ...
WH>end
WH>
будет проверяться статически.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[12]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>В общем понятно. Для generic типов в .NET в качестве generic параметра можно передать только тип (т.е. нельзя передать int например). Отсюда невозможность статической проверки коллекций.
В общем случае одних int'ов не хватит.
Нужна возможность использовать значения любых типов.
Причем значениями времени компиляции тоже не обойтись.
Должна быть возможность параметризовать типы значениями времени исполнения.
А это уже зависимые типы получаются.
nme>Можно сделать обёртку над массивом что-то вроде ArrayOfUintLimited, то что происходит в нутри неё придётся самому проверять,
Вот так ты и будешь для каждого частного случая рисовать костыли с кучей проверок времени исполнения.
nme>но такой код WH>>
WH>>for (i in mesh.indices.Indices)
WH>> def vertex = mesh.vertices[mesh.indices[i]];
WH>> ...
WH>>end
WH>>
nme>будет проверяться статически.
Конечно же не будет.
Ибо для этого тебе придется объяснить компилятору что в массиве indeces лежат индексы массива vertices, а Code Contracts такие зависимости отследить не в состоянии.
Quantifiers не подходят ибо работают только во время исполнения.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
nme>>В общем понятно. Для generic типов в .NET в качестве generic параметра можно передать только тип (т.е. нельзя передать int например). Отсюда невозможность статической проверки коллекций. WH>В общем случае одних int'ов не хватит. WH>Нужна возможность использовать значения любых типов. WH>Причем значениями времени компиляции тоже не обойтись. WH>Должна быть возможность параметризовать типы значениями времени исполнения. WH>А это уже зависимые типы получаются.
Это понятно, а про int я написал, что это только пример.
WH>Вот так ты и будешь для каждого частного случая рисовать костыли с кучей проверок времени исполнения.
Это тоже итак понятно, т.к. вытекает из предыдущей проблемы.
WH>Конечно же не будет. WH>Ибо для этого тебе придется объяснить компилятору что в массиве indeces лежат индексы массива vertices, а Code Contracts такие зависимости отследить не в состоянии. WH>Quantifiers не подходят ибо работают только во время исполнения.
А в чём проблема? Code contracts конечно не могут проверить(статически) существования элемента в коллекции , но в данном случае это вроде как и не нужно. Элементы Indices вроде просто должны удовлетворять условию 0 <= index < vertexCount. А с этим Code contracts вполне способны разобраться.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
BTW Статическую проверку для коллекций можно организовать и без ЗТ, но только для иммутабельных типов. В Spec# можно было обьявлять иммутабельность в виде контракта, но в Code contracts на данный момент это не реализовано.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
WH>>А это уже зависимые типы получаются. nme>Это понятно, а про int я написал, что это только пример.
Те тебе понятно что зависимые типы таки нужны?
WH>>Вот так ты и будешь для каждого частного случая рисовать костыли с кучей проверок времени исполнения. nme>Это тоже итак понятно, т.к. вытекает из предыдущей проблемы.
Насчет кучи проверок времени исполнения тоже возражений нет.
nme>А в чём проблема? Code contracts конечно не могут проверить(статически) существования элемента в коллекции , но в данном случае это вроде как и не нужно. Элементы Indices вроде просто должны удовлетворять условию 0 <= index < vertexCount. А с этим Code contracts вполне способны разобраться.
А давай ты повторишь этот код на Code contracts так чтобы не было проверок времени исполнения.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
nme>>А в чём проблема? Code contracts конечно не могут проверить(статически) существования элемента в коллекции , но в данном случае это вроде как и не нужно. Элементы Indices вроде просто должны удовлетворять условию 0 <= index < vertexCount. А с этим Code contracts вполне способны разобраться. WH>А давай ты повторишь этот код на Code contracts так чтобы не было проверок времени исполнения.
Да, похоже ты прав. Помоему, теоретически ничего не мешает провести статическую проверку в данной ситуации, но видимо процесс слишком трудоёмкий. С ЗТ ситуация по лучше, там ограничения хранятся внутри типа uintLimited, а не снаружи, как в ArrayOfUintLimited.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>Да, похоже ты прав. Помоему, теоретически ничего не мешает провести статическую проверку в данной ситуации, но видимо процесс слишком трудоёмкий.
Нут так бег на костылях ни к чему хорошему ни когда не приводил...
nme>С ЗТ ситуация по лучше, там ограничения хранятся внутри типа uintLimited, а не снаружи, как в ArrayOfUintLimited.
Самое смешное что uintLimited ничего кроме собственно значения не хранит. Те sizeof uint == sizeof uintLimited[x].
И это простейший пример.
Сами по себе ЗТ способны проверять куда более интересные конструкции.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Сами по себе ЗТ способны проверять куда более интересные конструкции.
Мне тут стало интересно как проверить такую конструкцию:
Есть например тип
class MyType
{
public T1 a;
public T2 b;
}
т.е. есть класс с двумя полями, типы полей это мутабельные типы. Далее мы хотим задать зависимость b от а, это можно сделать? Я полагаю для этого потребуется заменить T2 на DT2<a> и в конструкторе MyType передавать а как параметр в тип DT2.
Далее рассмотрим такой код:
MyType mType = ...;
var A = mType.a;
var B = mType.b;
Поймёт ли компилятор, что для А и В выполняется тоже отношение, что для a и b? Например если мы передадим A и B в какую-то функцию, а там будет соответствующая проверка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[18]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>т.е. есть класс с двумя полями, типы полей это мутабельные типы. Далее мы хотим задать зависимость b от а, это можно сделать? Я полагаю для этого потребуется заменить T2 на DT2<a> и в конструкторе MyType передавать а как параметр в тип DT2.
Извини я не могу ничего сказать по столь абстрактному примеру.
Можешь придумать что-то более конкретное?
nme>Поймёт ли компилятор, что для А и В выполняется тоже отношение, что для a и b? Например если мы передадим A и B в какую-то функцию, а там будет соответствующая проверка.
А тут нет никакой разницы с обычной статической типизацией.
А и В будут тех же типов что a и b. Таким образом с А и В можно делать все то что можно делать с a и b.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
nme>>т.е. есть класс с двумя полями, типы полей это мутабельные типы. Далее мы хотим задать зависимость b от а, это можно сделать? Я полагаю для этого потребуется заменить T2 на DT2<a> и в конструкторе MyType передавать а как параметр в тип DT2. WH>Извини я не могу ничего сказать по столь абстрактному примеру. WH>Можешь придумать что-то более конкретное?
Ок, пусть так
class MyType
{
public int a;
public int b;
}
от b требуется чтобы оно было больше a. Считаем что a и b мутабельны (т.е. не опираемся на их иммутабельность).
nme>>Поймёт ли компилятор, что для А и В выполняется тоже отношение, что для a и b? Например если мы передадим A и B в какую-то функцию, а там будет соответствующая проверка. WH>А тут нет никакой разницы с обычной статической типизацией. WH>А и В будут тех же типов что a и b. Таким образом с А и В можно делать все то что можно делать с a и b.
Тут дело не в типах a и b, а в том что эти типы содержат информацию о том что а < b. Поймёт ли компилятор, что A < B?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[20]: Модульные тесты и "безопасные" языки - хорошо.
nme>class MyType
nme>{
nme> public int a;
nme> public int b;
nme>}
nme>
nme>от b требуется чтобы оно было больше a. Считаем что a и b мутабельны (т.е. не опираемся на их иммутабельность).
Так не получится.
А вот если а неизменяемое тогда можно.
В прочем практика показывает что при переходе на функциональные языки количество изменяемых данных резко падает. Причем при разработке на всех языках.
nme>Тут дело не в типах a и b, а в том что эти типы содержат информацию о том что а < b. Поймёт ли компилятор, что A < B?
Да.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, nme, Вы писали:
nme>>
nme>>class MyType
nme>>{
nme>> public int a;
nme>> public int b;
nme>>}
nme>>
nme>>от b требуется чтобы оно было больше a. Считаем что a и b мутабельны (т.е. не опираемся на их иммутабельность). WH>Так не получится. WH>А вот если а неизменяемое тогда можно. WH>В прочем практика показывает что при переходе на функциональные языки количество изменяемых данных резко падает. Причем при разработке на всех языках.
Ну для неизменяемых типов можно и code contracts допилить до паритета по возможностям с ЗТ. Фактически code contract это тоже самое, что ЗТ. Просто описание ограничений происходит несколько по разному. В языках с ЗТ все ограничения торчат наружу, в code contracts всё спрятано во внутрь типа, но суть таже. Подход code contracts более походит на традиционны стиль написания программ, но с ЗТ гораздо легче отслеживать ограничения.
