Старое, но интересное видео о настоящем и будущем статического анализа программ.
Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
N>Старое, но интересное видео о настоящем и будущем статического анализа программ. N>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
Нормальный статический анализ Си++ (сейчас его вроде как нет), с объявляемыми юзером правилами на каком-то хитром языке.
Maxim S. Shatskih пишет: > Нормальный статический анализ Си++ (сейчас его вроде как нет), с > объявляемыми юзером правилами на каком-то хитром языке.
Один вопрос: зачем для C++?
Здравствуйте, Maxim S. Shatskih, Вы писали:
N>>Старое, но интересное видео о настоящем и будущем статического анализа программ. N>>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
MSS>Нормальный статический анализ Си++ (сейчас его вроде как нет), с объявляемыми юзером правилами на каком-то хитром языке.
По-моему тут проблема не в быстродействии, а в том, что хитрость этого "какого-то языка" для описания высказываний о программе для C++ совершенно безмерна. Иначе подобный язык уже был бы в наличии.
По-моему для создания развитого и полезного метаязыка сам базовый язык должен быть формализован существенно строже, чем это сделано в стандарте C++. Когда UB объявляется из-за того, что у разработчиков языка так зачесалось, а не по фундаментальным причинам, это даром не проходит.
D>По-моему тут проблема не в быстродействии, а в том, что хитрость этого "какого-то языка" для описания высказываний о программе для C++ совершенно безмерна. Иначе подобный язык уже был бы в наличии.
Ну есть всяческие тулзы которые решают частные случаи..
The linux kernel developers use a tool originally written by Linux Torvalds for static analysis — sparse.
Sparse has some features targeted at kernel development — for instance spotting mixing up kernel and user space pointers and a system of code annotations.
Но для общего случая сделать такой язык для с++ было бы напряжно.
kaa.python пишет: > OCT>Один вопрос: зачем для C++? > > Не поверишь, для улучшения качества ПО.
Для улучшения ПО его сначала нужно переписать не на C++.
Здравствуйте, nikov, Вы писали:
N>Старое, но интересное видео о настоящем и будущем статического анализа программ. N>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
Работал с Coverity — очень круто. Увеличение быстродействия ей точне не помешает — работает медленнее Intel C++ в режиме максимальной оптимизации.
Здравствуйте, nikov, Вы писали:
N>Старое, но интересное видео о настоящем и будущем статического анализа программ. N>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
Как уже сказал deniok, тут дело больше не в увеличении памяти и быстродействии компьютеров, а в более строгой формализации исходных языков. Чем более они формализованы, тем более они подвержены мат. анализу.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Имеет место значительная озабоченность корректностью, но она почти
полностью направлена на верификацию программ a posteriori, потому что
опять же это легче укладывается в мечту о полной автоматизации.
Но, разумеется, многие рассматривают верификацию a posteriori как
установку телеги впереди лошади, потому что процедура "сначала
программирование, потом проверка" поднимает насущный вопрос, откуда
берётся программа, подвергающаяся проверке. Если же она выведена, то
верификация сводится к простой проверке вывода.
Аргументируйте несогласие, мне интересно. Чтобы дописать предикаты,
подлежащие проверке, нужно перелопатить весь исходный код. Раз так,
почему бы при этом не переписать его на другой язык? Почему C++?
Я сколько C++ видел, он тяжело поддаётся введению высокоуровневых фич.
Вот нафига туда тащить сборку мусора и верификацию? Нафига козе баян?
Мыши плакали и кололись, но продолжали есть кактус.
OCT>Я сколько C++ видел, он тяжело поддаётся введению высокоуровневых фич. OCT>Вот нафига туда тащить сборку мусора и верификацию? Нафига козе баян? OCT>Мыши плакали и кололись, но продолжали есть кактус.
С++ можно ограничить как-нибудь иструкцией кодирования, тогда стразу всё станет сильно лучше.
А вообще да, если брать С++ в полном объёме, то "универсальный всемогутер сделаный через универсальный интерфейс реализации" получается
А вообще-то в С++ есть свои подходы к управлению памятью, которые не хуже, чем GC, а может даже и получше будут. Просто не все ими пользуются...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, yumi, Вы писали:
Y>Как уже сказал deniok, тут дело больше не в увеличении памяти и быстродействии компьютеров, а в более строгой формализации исходных языков. Чем более они формализованы, тем более они подвержены мат. анализу.
Ну транслируй C++ в что-то абсолютно прямое и формальное, скажем на язык "машины слабейших предусловий", или в машину Тьюринга, даже и анализируй себе...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, yumi, Вы писали:
Y>>Как уже сказал deniok, тут дело больше не в увеличении памяти и быстродействии компьютеров, а в более строгой формализации исходных языков. Чем более они формализованы, тем более они подвержены мат. анализу.
E>Ну транслируй C++ в что-то абсолютно прямое и формальное, скажем на язык "машины слабейших предусловий", или в машину Тьюринга, даже и анализируй себе...
В том-то и беда, что инварианты часто оказываются гораздо более высокоуровневыми. Скажем 50 последовательных мэпов над списком сохранят его длину (или сгенерят исключение); для того чтобы сделать такое утверждение не нужны трансляции в низкоуровневое представление. В C++ аналогом map может служить transform из STL (первая версия, с одним итератором ввода). Можно ли сделать инструмент, который, видя цепочку transform'ов, за O(1) говорил нам, что size контейнера сохраняется? Нет, для этого должно быть стандартизировано алгебраическое описание transform, причем реализация, не удовлетворяющая этому описанию просто не должна компилироваться.
Здравствуйте, deniok, Вы писали:
D>В том-то и беда, что инварианты часто оказываются гораздо более высокоуровневыми. Скажем 50 последовательных мэпов над списком сохранят его длину (или сгенерят исключение); для того чтобы сделать такое утверждение не нужны трансляции в низкоуровневое представление. В C++ аналогом map может служить transform из STL (первая версия, с одним итератором ввода). Можно ли сделать инструмент, который, видя цепочку transform'ов, за O(1) говорил нам, что size контейнера сохраняется? Нет, для этого должно быть стандартизировано алгебраическое описание transform, причем реализация, не удовлетворяющая этому описанию просто не должна компилироваться.
Какие проблемы? Вырази этот предикат на C++ тоже, всё оттранслируй и докажи себе что этот предикат тревиален...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>А вообще-то в С++ есть свои подходы к управлению памятью, которые не хуже, чем GC, а может даже и получше будут. Просто не все ими пользуются...
Нет таких подходов в С++.
А если впомнить про Cache-Conscious и нашествие многоядерников которое будет только усугубляться... то вобще труба.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Erop, Вы писали:
E>Какие проблемы? Вырази этот предикат на C++ тоже, всё оттранслируй и докажи себе что этот предикат тревиален...
Нии, то что transform сохраняет size контейнера, это должно быть библиотечное o(1)-time-consuming суждение. Исходный-то пост про статистический анализ и про его временнЫе издержки. То, что я на любом Тьюринг-полном языке могу любую алгоритмическую идею выразить, это я и так знаю
Здравствуйте, WolfHound, Вы писали:
WH>Нет таких подходов в С++. WH>А если впомнить про Cache-Conscious и нашествие многоядерников которое будет только усугубляться... то вобще труба.
Почему нет? Заводишь аллокатор на нить на запрос, всё теряешь, то, что захватывает ресурсы, кроме памяти, явнорегишь в специальном месте , тоже на нить и запрос локальном. После того, как запрос отработал -- просто освобождаешь все зарегенные ресурсы и откатываешь состояние аллокатора.
Работаео оченьбыстро, памяти жрёт меньше GC, единственая проблема -- совсем никаким раком с STL жить не хочет
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Почему нет? Заводишь аллокатор на нить на запрос, всё теряешь, то, что захватывает ресурсы, кроме памяти, явнорегишь в специальном месте , тоже на нить и запрос локальном. После того, как запрос отработал -- просто освобождаешь все зарегенные ресурсы и откатываешь состояние аллокатора.
Ибо не C++way и как следствие гемор жуткий.
E>Работаео оченьбыстро, памяти жрёт меньше GC,
При правильной системе типов ГЦ будет именно так и работать.
Только с несколькими оговорками:
0)Система выведет все это сама. Причем еще и подзапросы с которыми можно поступить также найдет.
1)Если запрос зажрет сильно много памяти ГЦ таки приберется. Причем прибераться будет только в куче запроса.
2)Внешние ресурсы будут регаться сами и болие того они (если явно не предпринять препятствующих действий) еще и автоматически будут закрываться сразу после того как перестают быть нужными (по окончании запроса прибъются по любому).
Система типов конечно получается несколько не привычная.
Но весьма простая и понятная.
E>единственая проблема -- совсем никаким раком с STL жить не хочет
А эту пародию на функциональщину в топку по любому.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ибо не C++way и как следствие гемор жуткий.
Почему "не С++way"? Не STL-boost -- да, а вот С++ так может очень даже неплохо...
WH>При правильной системе типов ГЦ будет именно так и работать.
Ну смысл такой, что в реале и такую систему и ГЦ надо настроить, чтобы было, как в идеале. Просто "С++GC" настроить можно намного круче.
Ну просто потому, что в кишочки покопаться пускают
WH>1)Если запрос зажрет сильно много памяти ГЦ таки приберется. Причем прибераться будет только в куче запроса.
Обычно хорошо работает другой подход. Если мы таки детектировлаи попу, то мы не тормозное ГЦ пускаем, а всё грохаем, и делаем как-то по другому. Скажем используем менее жрущий память алгоритм обработки запроса, или просто запрос баним или ещё чего. От задачи короче зависит... WH>2)Внешние ресурсы будут регаться сами и болие того они (если явно не предпринять препятствующих действий) еще и автоматически будут закрываться сразу после того как перестают быть нужными (по окончании запроса прибъются по любому).
Ну так и при таком подходе они "сами" регятся. Ну чиста потому, что библиотека таких объектов так написана.
Скажем твой CFile при открытии регится, при закрытии/разрушении, дерегится. Ну сосбтвенно и всё.
WH>Система типов конечно получается несколько не привычная. WH>Но весьма простая и понятная.
Да и так всё хорошо получается, зато на С++. Вся архитектура железа непосредственно доступна...
E>>единственая проблема -- совсем никаким раком с STL жить не хочет WH>А эту пародию на функциональщину в топку по любому.
Ну с этим я согласен абсолютно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, deniok, Вы писали:
D>Нии, то что transform сохраняет size контейнера, это должно быть библиотечное o(1)-time-consuming суждение. Исходный-то пост про статистический анализ и про его временнЫе издержки. То, что я на любом Тьюринг-полном языке могу любую алгоритмическую идею выразить, это я и так знаю
Ну дык на то моща вычислитеоьная и нужна
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
