kaa.python пишет: > OCT>Один вопрос: зачем для C++? > > Не поверишь, для улучшения качества ПО.
Для улучшения ПО его сначала нужно переписать не на C++.
Здравствуйте, Maxim S. Shatskih, Вы писали:
N>>Старое, но интересное видео о настоящем и будущем статического анализа программ. N>>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
MSS>Нормальный статический анализ Си++ (сейчас его вроде как нет), с объявляемыми юзером правилами на каком-то хитром языке.
По-моему тут проблема не в быстродействии, а в том, что хитрость этого "какого-то языка" для описания высказываний о программе для C++ совершенно безмерна. Иначе подобный язык уже был бы в наличии.
По-моему для создания развитого и полезного метаязыка сам базовый язык должен быть формализован существенно строже, чем это сделано в стандарте C++. Когда UB объявляется из-за того, что у разработчиков языка так зачесалось, а не по фундаментальным причинам, это даром не проходит.
Здравствуйте, Erop, Вы писали:
E>Почему нет? Заводишь аллокатор на нить на запрос, всё теряешь, то, что захватывает ресурсы, кроме памяти, явнорегишь в специальном месте , тоже на нить и запрос локальном. После того, как запрос отработал -- просто освобождаешь все зарегенные ресурсы и откатываешь состояние аллокатора.
Ибо не C++way и как следствие гемор жуткий.
E>Работаео оченьбыстро, памяти жрёт меньше GC,
При правильной системе типов ГЦ будет именно так и работать.
Только с несколькими оговорками:
0)Система выведет все это сама. Причем еще и подзапросы с которыми можно поступить также найдет.
1)Если запрос зажрет сильно много памяти ГЦ таки приберется. Причем прибераться будет только в куче запроса.
2)Внешние ресурсы будут регаться сами и болие того они (если явно не предпринять препятствующих действий) еще и автоматически будут закрываться сразу после того как перестают быть нужными (по окончании запроса прибъются по любому).
Система типов конечно получается несколько не привычная.
Но весьма простая и понятная.
E>единственая проблема -- совсем никаким раком с STL жить не хочет
А эту пародию на функциональщину в топку по любому.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Erop, Вы писали:
E>Почему "не С++way"? Не STL-boost -- да, а вот С++ так может очень даже неплохо...
Ибо если выкинуть деструкторы от С++ ничего не останется.
E>Ну смысл такой, что в реале и такую систему и ГЦ надо настроить, чтобы было, как в идеале. Просто "С++GC" настроить можно намного круче.
При правильной системе типов мы может за O(1) на этапе компиляции определять граници подзапросов...
E>Ну просто потому, что в кишочки покопаться пускают
E>Обычно хорошо работает другой подход. Если мы таки детектировлаи попу, то мы не тормозное ГЦ пускаем, а всё грохаем, и делаем как-то по другому. Скажем используем менее жрущий память алгоритм обработки запроса, или просто запрос баним или ещё чего. От задачи короче зависит...
В большинстве случаев можно просто спокойно прибраться.
E>Ну так и при таком подходе они "сами" регятся. Ну чиста потому, что библиотека таких объектов так написана. E>Скажем твой CFile при открытии регится, при закрытии/разрушении, дерегится. Ну сосбтвенно и всё.
Нет.
Сами они регятся ибо это в систему типов прошито.
Причем так что в отличии от плюсовых конструкторов с деструкторами не мешает ни замыканиям ни оптимизации хвостовой рекурсии ни точной сборке мусора.
E>Да и так всё хорошо получается, зато на С++.
В топку С++.
E>Вся архитектура железа непосредственно доступна...
Какая еще архитекура С++у доступна?
Не смешите мои тапочки.
Тем болие что архитектуры меняются на глазах и алгоритм который вылизали год назад под конкретный проц будет на новом проце работать не оптимально.
А если учесть что в обозримом будущем нас ожидают тысячи аппаратных потоков на кристалл...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Erop, Вы писали:
E>Почему? Это всего лишь чуть-чуть усложняет разбор исходников и всё. Легко можно ограничить использование языка так, что UB и ID возникать не будут. E>Собственно обычно все так и программируют...
Для С++ не могут даже сделать нормальный автокомплит и рефакторинг.
А это сильно проще статического анализа кода.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, nikov, Вы писали:
N>Старое, но интересное видео о настоящем и будущем статического анализа программ. N>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
Как уже сказал deniok, тут дело больше не в увеличении памяти и быстродействии компьютеров, а в более строгой формализации исходных языков. Чем более они формализованы, тем более они подвержены мат. анализу.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
OCT>Я сколько C++ видел, он тяжело поддаётся введению высокоуровневых фич. OCT>Вот нафига туда тащить сборку мусора и верификацию? Нафига козе баян? OCT>Мыши плакали и кололись, но продолжали есть кактус.
С++ можно ограничить как-нибудь иструкцией кодирования, тогда стразу всё станет сильно лучше.
А вообще да, если брать С++ в полном объёме, то "универсальный всемогутер сделаный через универсальный интерфейс реализации" получается
А вообще-то в С++ есть свои подходы к управлению памятью, которые не хуже, чем GC, а может даже и получше будут. Просто не все ими пользуются...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, yumi, Вы писали:
Y>>Как уже сказал deniok, тут дело больше не в увеличении памяти и быстродействии компьютеров, а в более строгой формализации исходных языков. Чем более они формализованы, тем более они подвержены мат. анализу.
E>Ну транслируй C++ в что-то абсолютно прямое и формальное, скажем на язык "машины слабейших предусловий", или в машину Тьюринга, даже и анализируй себе...
В том-то и беда, что инварианты часто оказываются гораздо более высокоуровневыми. Скажем 50 последовательных мэпов над списком сохранят его длину (или сгенерят исключение); для того чтобы сделать такое утверждение не нужны трансляции в низкоуровневое представление. В C++ аналогом map может служить transform из STL (первая версия, с одним итератором ввода). Можно ли сделать инструмент, который, видя цепочку transform'ов, за O(1) говорил нам, что size контейнера сохраняется? Нет, для этого должно быть стандартизировано алгебраическое описание transform, причем реализация, не удовлетворяющая этому описанию просто не должна компилироваться.
Здравствуйте, WolfHound, Вы писали:
WH>Ибо не C++way и как следствие гемор жуткий.
Почему "не С++way"? Не STL-boost -- да, а вот С++ так может очень даже неплохо...
WH>При правильной системе типов ГЦ будет именно так и работать.
Ну смысл такой, что в реале и такую систему и ГЦ надо настроить, чтобы было, как в идеале. Просто "С++GC" настроить можно намного круче.
Ну просто потому, что в кишочки покопаться пускают
WH>1)Если запрос зажрет сильно много памяти ГЦ таки приберется. Причем прибераться будет только в куче запроса.
Обычно хорошо работает другой подход. Если мы таки детектировлаи попу, то мы не тормозное ГЦ пускаем, а всё грохаем, и делаем как-то по другому. Скажем используем менее жрущий память алгоритм обработки запроса, или просто запрос баним или ещё чего. От задачи короче зависит... WH>2)Внешние ресурсы будут регаться сами и болие того они (если явно не предпринять препятствующих действий) еще и автоматически будут закрываться сразу после того как перестают быть нужными (по окончании запроса прибъются по любому).
Ну так и при таком подходе они "сами" регятся. Ну чиста потому, что библиотека таких объектов так написана.
Скажем твой CFile при открытии регится, при закрытии/разрушении, дерегится. Ну сосбтвенно и всё.
WH>Система типов конечно получается несколько не привычная. WH>Но весьма простая и понятная.
Да и так всё хорошо получается, зато на С++. Вся архитектура железа непосредственно доступна...
E>>единственая проблема -- совсем никаким раком с STL жить не хочет WH>А эту пародию на функциональщину в топку по любому.
Ну с этим я согласен абсолютно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, WolfHound, Вы писали:
WH>Язык стандарт которого испещерен словами undefined behavior, unspecified behavior и implementation defined behavior анализировать бесполезно.
Почему? Это всего лишь чуть-чуть усложняет разбор исходников и всё. Легко можно ограничить использование языка так, что UB и ID возникать не будут.
Собственно обычно все так и программируют...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Старое, но интересное видео о настоящем и будущем статического анализа программ.
Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
N>Старое, но интересное видео о настоящем и будущем статического анализа программ. N>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
Нормальный статический анализ Си++ (сейчас его вроде как нет), с объявляемыми юзером правилами на каком-то хитром языке.
Maxim S. Shatskih пишет: > Нормальный статический анализ Си++ (сейчас его вроде как нет), с > объявляемыми юзером правилами на каком-то хитром языке.
Один вопрос: зачем для C++?
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.
Но для общего случая сделать такой язык для с++ было бы напряжно.
Здравствуйте, nikov, Вы писали:
N>Старое, но интересное видео о настоящем и будущем статического анализа программ. N>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
Работал с Coverity — очень круто. Увеличение быстродействия ей точне не помешает — работает медленнее Intel C++ в режиме максимальной оптимизации.
Имеет место значительная озабоченность корректностью, но она почти
полностью направлена на верификацию программ a posteriori, потому что
опять же это легче укладывается в мечту о полной автоматизации.
Но, разумеется, многие рассматривают верификацию a posteriori как
установку телеги впереди лошади, потому что процедура "сначала
программирование, потом проверка" поднимает насущный вопрос, откуда
берётся программа, подвергающаяся проверке. Если же она выведена, то
верификация сводится к простой проверке вывода.
Аргументируйте несогласие, мне интересно. Чтобы дописать предикаты,
подлежащие проверке, нужно перелопатить весь исходный код. Раз так,
почему бы при этом не переписать его на другой язык? Почему C++?
Я сколько C++ видел, он тяжело поддаётся введению высокоуровневых фич.
Вот нафига туда тащить сборку мусора и верификацию? Нафига козе баян?
Мыши плакали и кололись, но продолжали есть кактус.
Здравствуйте, yumi, Вы писали:
Y>Как уже сказал deniok, тут дело больше не в увеличении памяти и быстродействии компьютеров, а в более строгой формализации исходных языков. Чем более они формализованы, тем более они подвержены мат. анализу.
Ну транслируй C++ в что-то абсолютно прямое и формальное, скажем на язык "машины слабейших предусловий", или в машину Тьюринга, даже и анализируй себе...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, 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 жить не хочет
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, deniok, Вы писали:
D>Нии, то что transform сохраняет size контейнера, это должно быть библиотечное o(1)-time-consuming суждение. Исходный-то пост про статистический анализ и про его временнЫе издержки. То, что я на любом Тьюринг-полном языке могу любую алгоритмическую идею выразить, это я и так знаю
Ну дык на то моща вычислитеоьная и нужна
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
D>>Нии, то что transform сохраняет size контейнера, это должно быть библиотечное o(1)-time-consuming суждение. Исходный-то пост про статистический анализ и про его временнЫе издержки. То, что я на любом Тьюринг-полном языке могу любую алгоритмическую идею выразить, это я и так знаю E>Ну дык на то моща вычислитеоьная и нужна
Ну уж нет.
Мы лучше эту мощу пустим на что-то более полезное чем попытки понять во что выльется неопределенное поведение...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Мы лучше эту мощу пустим на что-то более полезное чем попытки понять во что выльется неопределенное поведение...
Почему "неопределённое поведение"? Что неопределённого в std::transform?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
WH>>Мы лучше эту мощу пустим на что-то более полезное чем попытки понять во что выльется неопределенное поведение... E>Почему "неопределённое поведение"? Что неопределённого в std::transform?
Да причем тут std::transform?
Язык стандарт которого испещерен словами undefined behavior, unspecified behavior и implementation defined behavior анализировать бесполезно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Для С++ не могут даже сделать нормальный автокомплит и рефакторинг.
Что значит "не могут"? Просто большинство программистов используют слишком сложные шаблонные конструёвины...
Если от них таки отказаться (от "не слишком сложных" можно и не отказываться, кстати), то таки всё работает...
WH>А это сильно проще статического анализа кода.
Та же фигня... Просто на С++, если неправильно составить "инструкцию кодировщика" можно всё слишком сильно щапутать.
Но можно же этого и не делать...
Мало того, факт черезмерного запутывания легко выясняется формально. Это при анализе кода можно протсо диагностировать как ошибку...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ну транслируй C++ в что-то абсолютно прямое и формальное, скажем на язык "машины слабейших предусловий", или в машину Тьюринга, даже и анализируй себе...
Ну вот МС не удалось, не меняя языка, оттранслировать С++ в верифицируемый IL.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну вот МС не удалось, не меняя языка, оттранслировать С++ в верифицируемый IL.
Да в полной, так сказать версии, С++ язык неверифицируемый, кто бы спорил
Надо, хотя бы UB все навалидными объявить и шаблонами не злоупотреблять...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Erop пишет: > OCT>Я сколько C++ видел, он тяжело поддаётся введению высокоуровневых фич. > OCT>Вот нафига туда тащить сборку мусора и верификацию? Нафига козе баян? > OCT>Мыши плакали и кололись, но продолжали есть кактус. > > С++ можно ограничить как-нибудь иструкцией кодирования, тогда стразу всё > станет сильно лучше. http://lambda-the-ultimate.org/node/2733
All The King's Horses
And All The King's Men
Couldn't Make C Safe Again
oh wait...it was never safe.
Здравствуйте, nikov, Вы писали:
N>Хотелось бы узнать, какие, по вашему мнению, новые возможности появятся с увеличением памяти и быстродействия компьютеров?
Конечно же, инлайновая (возникающая по мере набора) информация о нарушенных правилах. С возможностью так же, по смарт-тегу, исправить ситуацию одним из предложенных способов.
Возможность прогонять тесты\анализы после _каждого_ запуска компиляции на машине разработчика. В настоящий момент это невозможно, так как _заметно_ медленнее простого запуска компилятора => при малейшей спешке\суете прогоном тестов\анализов будут пренебрегать, а как раз при спешке немудрено напортачить.
Help will always be given at Hogwarts to those who ask for it.