Здравствуйте, 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, Вы писали:
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>Язык стандарт которого испещерен словами undefined behavior, unspecified behavior и implementation defined behavior анализировать бесполезно.
Почему? Это всего лишь чуть-чуть усложняет разбор исходников и всё. Легко можно ограничить использование языка так, что UB и ID возникать не будут.
Собственно обычно все так и программируют...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Почему? Это всего лишь чуть-чуть усложняет разбор исходников и всё. Легко можно ограничить использование языка так, что UB и ID возникать не будут. E>Собственно обычно все так и программируют...
Для С++ не могут даже сделать нормальный автокомплит и рефакторинг.
А это сильно проще статического анализа кода.
... << 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.
