Зато проще с установкой софта — не приходится половину библиотек апдейтить на нужные версии, собирая часть их них на коленке, когда в публичном репозитарии оказывается слишком старая версия dependency.
Возможно, у нас с Вами разный опыт, но в своей жизни, как пользователя, я с таким не сталкивался. Все конфликты разруливали мэйнтейнеры репозиториев и я получал уже работающие пакеты.
Как программисту, мне приходилось собирать свои пакеты с другими версиями библиотек, но это приходилось делать только если была необходимость пропатчить библиотеку какими-либо специфичными для проекта патчами.
CRT — не простая DLL, чтобы к ней применять термин ABI
Правильно! CRT — это такая библиотека, экспортируемые функции которой строго стандартизированы международными стандартами С/С++. Вот именно по этому CRT и должна иметь фиксированный интерфейс, как на уровне API, так и на уровне ABI для стандартизированных функций. И уж тем более не допустима такая самодеятельность, как отсутствие обратной совместимости, из-за чего возможна абсурдная ситуация, при которой одно приложение использует несколько несовместимых между собой CRT.
STL — дело комилятора, а не линковкщика.
И линковщика. Не вся STL помещается в шаблонах и заголовочных файлах. Часть ее вкомпилирована в CRT.
Деградацией является динамической линковка, особенно динамическая линковка CRT.
Почему?
Например, зачем мне в каждый exe-файл проекта статически линьковать по 20-30Мбайт библиотек, если их можно сделать динамическими и тем самым получить дополнительные преимущества, такие как возможность централизованного обновления, отсутствие дублей кода библиотек в памяти и т.д.
Возможно, я чего-то не понимаю в экосистеме Windows, но мне, как разработчику, который пришел из мира Linux, такие подходы к разработке, отсутствие совместимости ABI и отсутствие простого способа указать пути поиска тех же библиотек (RPATH, LD_LIBRARY_PATH) кажутся дикими.
Я несколько неточно выразился. Я имел ввиду библиотеку STL, которую в случае MSVC можно отнести к CRT, да и вроде-бы даже часть кода рантайма С++ находится именно там.
Начиная с MSVC 2005 в STL добавляли различный отладочный функционал (включается/отключается дефайнами _SECURE_SCL, _HAS_ITERATOR_DEBUGGING, _ITERATOR_DEBUG_LEVEL). Я согласен, что этот функционал хорош при отладке, НО он по умолчанию включен в релиз-сборках! Это было-бы не так плохо, если бы включение/выключение этих опций не ломало ABI, но так как ABI ломается, то требуется чтобы во всем проекте эти опции были установлены одинаково.
Выключение этих опций в моем случае давало прирост производительности примерно в 2 раза, что не мало. Вот еще одно мнение по поводу этих опций blogs.warwick.ac.uk/ahazelden/entry/visual_studio_stl/. По сути оно совпадает с моим.
Возможно, но почему тогда в Linux библиотеки (libc, libstdc++) развиваются, а ABI остается стабильным и обратно совместимым на протяжении многих лет? А то, что делает Microsoft скорее напоминает деградацию. Как минимум деградацию производительности.
К сожалению, эта не другая культура разработки. Это бардак разработки. Культура разработки — это когда все взаимодействия зафиксированы на уровне различного рода договоренностей (таких как API, ABI и т.д.). В случае Windows такие договоренности отсутствуют даже в пределах одной программы.
К тому же для С-библиотек сохранять ABI не так сложно. Для С++ сложнее, но для STL-библиотеки не на много.
надо понимать, что каждый модуль имеет свою CRT и надо думать об аллокаторах, не использовать FILE* и пр.
Это было бы можно понять, если бы речь шла о какой-либо собственной разработке Microsoft, но когда речь идет о стандартизированных языках, то очень странно, что даже в пределах одной программы полноценно использовать возможности языка просто опасно.
Концептуально, наверное, можно. На практике для этого потребуются десятилетия. Мы весной вывели из эксплуатации одну системку на RedHat EL 4, так даже там libc была бинарно-совместима с более новыми версиями из RedHat EL 5, SUSE и.т.д. (а вот версия библиотеки С++ — libstdc++ сменилась, так как в RH4 был GCC 3, а в более новых — 4.*). Возможно, я ошибаюсь, но лично я не видел реальных приложений, ситуаций, где такая проблема могла бы возникнуть в Linux.
Проблема dll-hell в Windows, в данном случае, из-за того, что в C-рантайме от MSVC с бинарной совместимостью все очень печально. Правильнее сказать, что между двумя версиями рантайма ее нет вообще. Из-за этого различные exe и dll приходиться линьковать с msvcrt строго определенной версии, так как другие версии просто будут иметь другой ABI.
А такие проблемы с ABI, в одной из основных библиотек Windows, возникают из-за того, что MS никак не может решиться просто реализовать libc и libstdc++ по соответствующим стандартам языков, а все время придумывают свои расширения, объявляют функции устаревшими, включают отладочные проверки в релиз-версиях (при этом отключение этих проверок ломает ABI даже в пределах версии crt) и производят другие действия с аналогично-непонятным смыслом.
Я сейчас тоже вплотную столкнулся с проблемами из-за подобной политики MS, но в моем случае оказалось возможно просто перекомпилировать все зависимые библиотеки со строго одинаковым набором опций компилятора. Но это на текущий момент закрытая разработка, поэтому мы можем позволить себе такие вольности. В открытом или тиражируемом продукте такой подход, скорее всего, будет непозволительной роскошью.
Курсовые работы, проекты, дипломы не являются научно исследовательскими работами. Даже у магистров, обучение которых обязательно имеет исследовательский уклон. По этому, если подходить к вопросу строго по ГОСТу, то государственных стандартов на оформление такого рода работ нет.
При этом вузовский стандарт для учебных работ может базироваться на ГОСТ 7.32-2001. Например, у нас на факультете требуют оформлять учебные работы в соответствии с вышеназванным ГОСТ. Возможно требование использовать стандарты ЕСКД или ЕСПД, но это опять же требования вузов, а не государства.
Если рассматривать структуру дипломных проектов, то она зависит от направления подготовки и присваиваемой квалификации (дипломные работы бакалавров, магистров и инженеров отличаются по своей структуре достаточно сильно). В дипломных работах инженеров разделы БЖ и экономическая часть, насколько мне известно, обязательны. У бакалавров и магистров этих разделов, насколько я знаю, нет. К сожалению, проконсультироваться на счет наличия требования к содержанию дипломов в ГОСах я сейчас не могу, поэтому приходится надеяться, что моя память меня не подводит.
Более того, я бы еще ужесточил требования к содержанию этих разделов, обязательно привязав их содержание к разрабатываемой в рамках диплома системе, а то когда видишь инженеров-пятикурсников, которые искренне не понимают зачем нужно учитывать стоимость сопровождения ПО при оценке разного рода затрат и которые пишут допустимый диапазон температур для офисного работника от +10 до +30 градусов при 8-и часовом рабочем дне, то волосы дыбом встают! Это я в декабре присутствовал на защитах курсовых проектов, которые у пятикурсников нашей кафедры должны перетекать в дипломные проекты.
Да, число университетов в России после 90-х годов стало превышать все мыслимые пределы (а многие из них по уровню подготовки так и остались на уровне ПТУ), но специализация в рамках областей знаний, по моему мнению, все-же не является недостатком. Вас же не смущает наличие разделения на [к|д].т.н., [к|д].э.н, [к|д].ф.-м.н., ...?
Так и идите этим курсом, но не пытайтесь учить преподов, как им правильно вас учить. Вы их не переучите, а себе проблем наживете. На решение этих проблем вы потратите свое время, которое вы могли бы потратить на что-то более важное. На самообразование.
Ну зачем-же так критично? Если подходить к этому вопросу аккуратно, то вполне можно и программу поменять и новые технологии для себя изучить в одно время, что наиболее важно.
Говорю я это основываясь на собственном опыте, который закончился заменой в лабораторных работах по нескольким предметам одного преподавателя таких технологий как MFC и Delphi (сильно устаревших версий, да и на Linux не работают), на Qt, Java или произвольный язык и общим обновлением материала дисциплин.
Так я согласен, но со стороны то все будет выглядеть именно так, как описано в этой, да и во многих других, статьях. Те хотели как лучше, а получили как всегда или еще хуже.
А вообще обидно, когда можешь дать интересные практические задачи (правда с некоторым уклоном в свою специфику), а практически некому…
Как Вы думаете, сколько студентов выберут более сложные темы добровольно? А сколько студентов справится с более сложными темами, если их давать принудительно?
Я пробовал предлагать индивидуальные, исследовательские задания вместо стандартных лабораторных. Но на это практически никто не соглашается, так как это же думать и делать надо, а стандартные лабы можно списать у тех, кто сделал их чуть раньше. Предлагаемые мною исследовательские задачи были из области суперкомпьютерных вычислений, параллельного программирования (в том числе с использованием графических процессоров), алгоритмов и протоколов передачи данных в распределенных системах и т.д.
На ближайший семестр у меня есть несколько вариантов задания для магистров, у которых я буду преподавать, и возможно дипломников, но уверенности в том, что с ними кто-то полностью справится, у меня нет. Задания непосредственно связаны с моей научно-исследовательской работой, так что и практическое применение результатов будет и доступ к оборудованию, при необходимости, организовать можно будет.
Возможно, у нас с Вами разный опыт, но в своей жизни, как пользователя, я с таким не сталкивался. Все конфликты разруливали мэйнтейнеры репозиториев и я получал уже работающие пакеты.
Как программисту, мне приходилось собирать свои пакеты с другими версиями библиотек, но это приходилось делать только если была необходимость пропатчить библиотеку какими-либо специфичными для проекта патчами.
Правильно! CRT — это такая библиотека, экспортируемые функции которой строго стандартизированы международными стандартами С/С++. Вот именно по этому CRT и должна иметь фиксированный интерфейс, как на уровне API, так и на уровне ABI для стандартизированных функций. И уж тем более не допустима такая самодеятельность, как отсутствие обратной совместимости, из-за чего возможна абсурдная ситуация, при которой одно приложение использует несколько несовместимых между собой CRT.
И линковщика. Не вся STL помещается в шаблонах и заголовочных файлах. Часть ее вкомпилирована в CRT.
Бывает. Достаточно посмотреть на любой Linux. В Windows из-за отсутствия совместимого ABI системных библиотек с этим сложнее.
В том-то и проблема, что в MSVC совместимого ABI нет. CRT из VC 10 нельзя подсунуть вместо CRT из VC 9. Да и с совместимостью STL проблемы есть.
Почему?
Например, зачем мне в каждый exe-файл проекта статически линьковать по 20-30Мбайт библиотек, если их можно сделать динамическими и тем самым получить дополнительные преимущества, такие как возможность централизованного обновления, отсутствие дублей кода библиотек в памяти и т.д.
Возможно, я чего-то не понимаю в экосистеме Windows, но мне, как разработчику, который пришел из мира Linux, такие подходы к разработке, отсутствие совместимости ABI и отсутствие простого способа указать пути поиска тех же библиотек (RPATH, LD_LIBRARY_PATH) кажутся дикими.
Начиная с MSVC 2005 в STL добавляли различный отладочный функционал (включается/отключается дефайнами _SECURE_SCL, _HAS_ITERATOR_DEBUGGING, _ITERATOR_DEBUG_LEVEL). Я согласен, что этот функционал хорош при отладке, НО он по умолчанию включен в релиз-сборках! Это было-бы не так плохо, если бы включение/выключение этих опций не ломало ABI, но так как ABI ломается, то требуется чтобы во всем проекте эти опции были установлены одинаково.
Выключение этих опций в моем случае давало прирост производительности примерно в 2 раза, что не мало. Вот еще одно мнение по поводу этих опций blogs.warwick.ac.uk/ahazelden/entry/visual_studio_stl/. По сути оно совпадает с моим.
К сожалению, эта не другая культура разработки. Это бардак разработки. Культура разработки — это когда все взаимодействия зафиксированы на уровне различного рода договоренностей (таких как API, ABI и т.д.). В случае Windows такие договоренности отсутствуют даже в пределах одной программы.
К тому же для С-библиотек сохранять ABI не так сложно. Для С++ сложнее, но для STL-библиотеки не на много.
Это было бы можно понять, если бы речь шла о какой-либо собственной разработке Microsoft, но когда речь идет о стандартизированных языках, то очень странно, что даже в пределах одной программы полноценно использовать возможности языка просто опасно.
Проблема dll-hell в Windows, в данном случае, из-за того, что в C-рантайме от MSVC с бинарной совместимостью все очень печально. Правильнее сказать, что между двумя версиями рантайма ее нет вообще. Из-за этого различные exe и dll приходиться линьковать с msvcrt строго определенной версии, так как другие версии просто будут иметь другой ABI.
А такие проблемы с ABI, в одной из основных библиотек Windows, возникают из-за того, что MS никак не может решиться просто реализовать libc и libstdc++ по соответствующим стандартам языков, а все время придумывают свои расширения, объявляют функции устаревшими, включают отладочные проверки в релиз-версиях (при этом отключение этих проверок ломает ABI даже в пределах версии crt) и производят другие действия с аналогично-непонятным смыслом.
Я сейчас тоже вплотную столкнулся с проблемами из-за подобной политики MS, но в моем случае оказалось возможно просто перекомпилировать все зависимые библиотеки со строго одинаковым набором опций компилятора. Но это на текущий момент закрытая разработка, поэтому мы можем позволить себе такие вольности. В открытом или тиражируемом продукте такой подход, скорее всего, будет непозволительной роскошью.
nginx.org/ru/docs/http/ngx_http_flv_module.html
nginx.org/ru/docs/http/ngx_http_mp4_module.html
При этом вузовский стандарт для учебных работ может базироваться на ГОСТ 7.32-2001. Например, у нас на факультете требуют оформлять учебные работы в соответствии с вышеназванным ГОСТ. Возможно требование использовать стандарты ЕСКД или ЕСПД, но это опять же требования вузов, а не государства.
Если рассматривать структуру дипломных проектов, то она зависит от направления подготовки и присваиваемой квалификации (дипломные работы бакалавров, магистров и инженеров отличаются по своей структуре достаточно сильно). В дипломных работах инженеров разделы БЖ и экономическая часть, насколько мне известно, обязательны. У бакалавров и магистров этих разделов, насколько я знаю, нет. К сожалению, проконсультироваться на счет наличия требования к содержанию дипломов в ГОСах я сейчас не могу, поэтому приходится надеяться, что моя память меня не подводит.
Более того, я бы еще ужесточил требования к содержанию этих разделов, обязательно привязав их содержание к разрабатываемой в рамках диплома системе, а то когда видишь инженеров-пятикурсников, которые искренне не понимают зачем нужно учитывать стоимость сопровождения ПО при оценке разного рода затрат и которые пишут допустимый диапазон температур для офисного работника от +10 до +30 градусов при 8-и часовом рабочем дне, то волосы дыбом встают! Это я в декабре присутствовал на защитах курсовых проектов, которые у пятикурсников нашей кафедры должны перетекать в дипломные проекты.
Да, число университетов в России после 90-х годов стало превышать все мыслимые пределы (а многие из них по уровню подготовки так и остались на уровне ПТУ), но специализация в рамках областей знаний, по моему мнению, все-же не является недостатком. Вас же не смущает наличие разделения на [к|д].т.н., [к|д].э.н, [к|д].ф.-м.н., ...?
Ну зачем-же так критично? Если подходить к этому вопросу аккуратно, то вполне можно и программу поменять и новые технологии для себя изучить в одно время, что наиболее важно.
Говорю я это основываясь на собственном опыте, который закончился заменой в лабораторных работах по нескольким предметам одного преподавателя таких технологий как MFC и Delphi (сильно устаревших версий, да и на Linux не работают), на Qt, Java или произвольный язык и общим обновлением материала дисциплин.
А вообще обидно, когда можешь дать интересные практические задачи (правда с некоторым уклоном в свою специфику), а практически некому…
Я пробовал предлагать индивидуальные, исследовательские задания вместо стандартных лабораторных. Но на это практически никто не соглашается, так как это же думать и делать надо, а стандартные лабы можно списать у тех, кто сделал их чуть раньше. Предлагаемые мною исследовательские задачи были из области суперкомпьютерных вычислений, параллельного программирования (в том числе с использованием графических процессоров), алгоритмов и протоколов передачи данных в распределенных системах и т.д.
На ближайший семестр у меня есть несколько вариантов задания для магистров, у которых я буду преподавать, и возможно дипломников, но уверенности в том, что с ними кто-то полностью справится, у меня нет. Задания непосредственно связаны с моей научно-исследовательской работой, так что и практическое применение результатов будет и доступ к оборудованию, при необходимости, организовать можно будет.