История изменений
Исправление SZT, (текущая версия) :
На своём. Заметишь оверхед - поговорим.
Только вот на плюсах я вообще не пишу, так что увы. Думаю что Speedup when using the bounds check elimination algorithm из той pdf которую ты читать не хочешь - уже достаточно показывает, какой там оверхед. А написать синтетический пример, где оверхед будет очень большой или наоборот очень маленький - это вообще тривиально, и смысла так делать нет никакого.
Я Ъ, и JAVA меня не интересует от слова никак. Ты хочешь казаться крутым анализатором - расскажи своими словами, а не ссылками кидайся.
Своими словами там так просто не описать, там есть всякие блок-схемы, loop-invariant checks, в общем эти твои «Обёртки над типами с compile-time проверкой диапазона» о которых ты писал - это вообще полная фигня по сравнению с этим (и то оно устраняет далеко не все бесполезные проверки границ). А если использовать нечто вроде Frama-C и добавить контрактов, доказав их через SMT-солверы и систему доказательства теорем Coq, то вообще от проверки границ можно избавиться для любых случаев(Xотя есть всякие undecidable проблемы, где так уже не сделать, увы. Но вряд ли с ними можно столкнуться в реальной жизни (не на синтетических примерах) в контексте проверки границ массива и прочей работы с указателями).
Сам-то как думаешь? Может ты считаешь что там по определению боги?
Я вообще-то у тебя спрашиваю, что ты по этому поводу думаешь. Нечего тут стрелки переводить. Если такой умный - смело иди работай над Webkit за деньги, реализуй там свою инновационную методику избавления от багов, уверен что тебе много денег заплатят за такое. Только я сильно сомневаюсь, что ты в плюсах лучше шаришь чем те, кто пишут этот самый Webkit.
Исправление SZT, :
На своём. Заметишь оверхед - поговорим.
Только вот на плюсах я вообще не пишу, так что увы. Думаю что Speedup when using the bounds check elimination algorithm из той pdf которую ты читать не хочешь уже достаточно показывает, какой там оверхед. А написать синтетический пример, где оверхед будет очень большой или наоборот очень маленький - это вообще тривиально, и смысла так делать нет никакого.
Я Ъ, и JAVA меня не интересует от слова никак. Ты хочешь казаться крутым анализатором - расскажи своими словами, а не ссылками кидайся.
Своими словами там так просто не описать, там есть всякие блок-схемы, loop-invariant checks, в общем эти твои «Обёртки над типами с compile-time проверкой диапазона» о которых ты писал - это вообще полная фигня по сравнению с этим (и то оно устраняет далеко не все бесполезные проверки границ). А если использовать нечто вроде Frama-C и добавить контрактов, доказав их через SMT-солверы и систему доказательства теорем Coq, то вообще от проверки границ можно избавиться для любых случаев(Чотя есть всякие undecidable проблемы, где так уже не сделать, увы. Но вряд ли с ними можно столкнуться в реальной жизни в контексте проверки границ массива).
Сам-то как думаешь? Может ты считаешь что там по определению боги?
Я вообще-то у тебя спрашиваю, что ты по этому поводу думаешь. Нечего тут стрелки переводить. Если такой умный - смело иди работай над Webkit за деньги, реализуй там свою инновационную методику избавления от багов, уверен что тебе много денег заплатят за такое. Только я сильно сомневаюсь, что ты в плюсах лучше шаришь чем те, кто пишут этот самый Webkit.
Исправление SZT, :
На своём. Заметишь оверхед - поговорим.
Только вот на плюсах я вообще не пишу, так что увы. Думаю что Speedup when using the bounds check elimination algorithm из той pdf которую ты читать не хочешь уже достаточно показывает, какой там оверхед. А написать синтетический пример, где оверхед будет очень большой или наоборот очень маленький - это вообще тривиально, и смысла так делать нет никакого.
Я Ъ, и JAVA меня не интересует от слова никак. Ты хочешь казаться крутым анализатором - расскажи своими словами, а не ссылками кидайся.
Своими словами там так просто не описать, там есть всякие блок-схемы, loop-invariant checks, в общем эти твои «Обёртки над типами с compile-time проверкой диапазона» о которых ты писал - это вообще полная фигня по сравнению с этим (и то оно устраняет далеко не все бесполезные проверки границ). А если использовать нечто вроде Frama-C и добавить контрактов, доказав их через SMT-солверы и систему доказательства теорем Coq, то вообще от проверки границ можно избавиться для любых случаев.
Сам-то как думаешь? Может ты считаешь что там по определению боги?
Я вообще-то у тебя спрашиваю, что ты по этому поводу думаешь. Нечего тут стрелки переводить. Если такой умный - смело иди работай над Webkit за деньги, реализуй там свою инновационную методику избавления от багов, уверен что тебе много денег заплатят за такое. Только я сильно сомневаюсь, что ты в плюсах лучше шаришь чем те, кто пишут этот самый Webkit.
Исправление SZT, :
На своём. Заметишь оверхед - поговорим.
Только вот на плюсах я вообще не пишу, так что увы. Думаю что Speedup when using the bounds check elimination algorithm из той pdf которую ты читать не хочешь уже достаточно показывает, какой там оверхед. А написать синтетический пример, где оверхед будет очень большой или наоборот очень маленький - это вообще тривиально, и смысла так делать нет никакого.
Я Ъ, и JAVA меня не интересует от слова никак. Ты хочешь казаться крутым анализатором - расскажи своими словами, а не ссылками кидайся.
Своими словами там так просто не описать, там есть всякие блок-схемы, loop-invariant checks, в общем эти твои «Обёртки над типами с compile-time проверкой диапазона» о которых ты писал - это вообще полная фигня по сравнению с этим (и то оно устраняет далеко не все бесполезные проверки границ). А если использовать нечто вроде Frama-C и добавить контрактов, доказав их через SMT-солверы и систему доказательства теорем Coq, то вообще от проверки границ можно избавиться для любых случаев.
Сам-то как думаешь? Может ты считаешь что там по определению боги?
Я вообще-то у тебя спрашиваю, что ты по этому поводу думаешь. Нечего тут стрелки переводить. Если такой умный - смело иди работай над Webkit за деньги, реализуй там свою инновационную методику избавления от багов, уверен что тебе много денег за это заплатят за такое. Только я сильно сомневаюсь, что ты в плюсах лучше шаришь чем те, кто пишут этот самый Webkit.
Исправление SZT, :
На своём. Заметишь оверхед - поговорим.
Только вот на плюсах я вообще не пишу, так что увы. Думаю что Speedup when using the bounds check elimination algorithm из той pdf которую ты читать не хочешь уже достаточно показывает, какой там оверхед. А написать синтетический пример, где оверхед будет очень большой или наоборот очень маленький - это вообще тривиально, и смысла так делать нет никакого.
Я Ъ, и JAVA меня не интересует от слова никак. Ты хочешь казаться крутым анализатором - расскажи своими словами, а не ссылками кидайся.
Своими словами там так просто не описать, там есть всякие блок-схемы, loop-invariant checks, в общем эти твои «Обёртки над типами с compile-time проверкой диапазона» о которых ты писал - это вообще полная фигня по сравнению с этим (и то оно устраняет далеко не все бесполезные проверки границ). А если использовать нечто вроде Frama-C и добавить контрактов, доказав их через SMT-солверы и систему доказательства теорем Coq, то вообще от проверки границ можно избавиться для любых случаев.
Сам-то как думаешь? Может ты считаешь что там по определению боги?
Я вообще-то у тебя спрашиваю, что ты по этому поводу думаешь. Нечего тут стрелки переводить
Исходная версия SZT, :
На своём. Заметишь оверхед - поговорим.
Только вот на плюсах я вообще не пишу, так что увы. Думаю что Speedup when using the bounds check elimination algorithm из той pdf которую ты читать не хочешь уже достаточно показывает, какой там оверхед. А написать синтетический пример, где оверхед будет очень большой или наоборот очень маленький - это вообще тривиально, и смысла так делать нет никакого.
Я Ъ, и JAVA меня не интересует от слова никак. Ты хочешь казаться крутым анализатором - расскажи своими словами, а не ссылками кидайся.
Своими словами там так просто не описать, там есть всякие блок-схемы, loop-invariant checks, в общем эти твои «Обёртки над типами с compile-time проверкой диапазона» о которых ты писал - это вообще полная фигня по сравнению с этим. А если использовать нечто вроде Frama-C и добавить контрактов, доказав их через SMT-солверы и систему доказательства теорем Coq, то вообще от проверки границ можно избавиться.
Сам-то как думаешь? Может ты считаешь что там по определению боги?
Я вообще-то у тебя спрашиваю, что ты по этому поводу думаешь. Нечего тут стрелки переводить