Модули — это основная причина, делающая крайне затруднительным использование стороннего кода и невозможным — менеджеров пакетов. Кстати, экспериментальная реализация модулей уже есть в Visual Studio 2015 Update 2. Но она настолько сырая, что пользоваться ею не хочется совсем.
STL ужасен до невозможности после опыта работы с более новыми языками с нормальными библиотеками. Больше всего бесит широкое использование беззнаковых типов и смешение знаковых/беззнаковых. Затем — ужасный iostream с нелогичными перегрузками и форматированием. В качестве прикола пытался написать аналог .NET String на C++ с SubString (с указателями), особенно String.Format с variadic templates. Даже работало и было на порядок удобнее printf и тем более cout.
Ага, я даже пытался замерить это время: из нескольких потоков инкрементил одну и ту же области памяти и считал сумму за секунду.
У меня получилось 175M инкрементов в секунду при одном потоке и всего 47M при 2 и большем числе потоков. Получается, что при инкременте в 4 потока каждый из потоков выполняет инкремент всего 12M раз. Т.е. когда к памяти имеет доступ один поток, получается около 23 тактов на операцию, а когда несколько (например, 4), то значение увеличивается до 300-350 тактов. Для сравнения: простой инкремент — 1-2 такта.
Корни проблем неправильного понимания атомарности растут со старых архитектур. Когда у нас процессор (ядро) был один, то да, любая операция, которая выражалась одной ассемблерной командой, была атомарна. Потому что никто параллельно не мог работать с той же областью памяти. А вот действия, состоящие из несколько команд, могли быть прерваны посередине.
В случае многопроцессорных систем для обеспечения атомарности стало необходимо также блокировать совместный доступ к памяти. Поэтому Interlocked команды используются даже если аргумент влезает в регистр процессора.
Паскаль нужен, чтобы не тратить время на Бейсик. Т.е. идти по цепочке Паскаль -> C -> ASM -> языки высокого уровня.
А вот Delphi для обучения программированию не нужен. Он действительно был актуален 10-15 лет назад, но не за счёт языковых возможностей, а из-за библиотек. Сейчас для тех же целей гораздо актуальнее изучать C#/Java.
Отвечаю про девочку-студентку. Цель заданий — избавиться от типичных ошибок джунов при работе с изображениями: они забывают про диапазон 0-255 и выход из него, иногда выходят за границы массива, в неправильном порядке обходят изображения (из-за чего падает скорость). Только после этого студентам можно ставить более-менее приличные задачи, имеющие хоть и небольшую, но практическую ценность.
Все студенты перед заданием получают теорию (что такое свёртка и как её считать), программу-болванку для работы с изображениями (загрузка и сохранение). Консультируем студентов с удовольствием. Дополнительных материалов (учебники, интернет) навалом. В чём проблема решить простую задачу? Но если человек не может хоть как-то решить даже простую задачу, то такой человек нам не нужен, и тратить своё время на него мы не видим смысла.
А теперь взгляните вот сюда (отдельная библиотека boost.preprocessor):
https://github.com/boostorg/preprocessor/tree/develop/include/boost/preprocessor/tuple
Ну или сюда (кусок из boost.mpl):
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preprocessed/msvc70/map.hpp
В русском и английском многие слова имеют разный смысл. Так, слова «менеджер» и «manager» имеют разный смысл, «девелопер» и «developer» — тоже и т.д. Это вполне естественная эволюция значений слов при заимствовании.
А для философов даже слова «детерминированный» и «определённый» имеют разный смысл.
Начинающий программист должен писать велосипеды для самообучения.
Понятно, что в продакшене нужно использовать готовые проверенные решения, но нет ничего хуже использования готовых решений без понимания, как они устроены изнутри.
Лично я «кодерами» называю программистов, способных писать код, но не обладющих развитым аналитическим мышлением.
Кодер не способен осилить Кнута или Кормена. Кодер не может оценивать эффективность алгоритмов, в результате чего программа может начать тормозить на пустом месте. Кодер не способен решать задачи, где требуется применение математических методов. Кодер не способен придумать или реализовать какой-нибудь алгоритм, и т.д. Идея, надеюсь, понятна.
Например, была у меня пара студентов: с одной стороны, уже подрабатывали разработчиками, с другой — не могли решить элементарные задачи. Одна студентка-разработчица под iOS вообще убила: за год не смогла написать свёртку изображений (функция-велосипед пишется за 5 минут), потому что не понимала, как. Искала готовые решения, пытаясь разобраться с OpenCV, но так и смогла этого сделать. Пришлось в итоге её выгнать.
Да, буст очень запутан. Если внутренности STL ещё можно худо-бедно читать, то в Boost лучше вообще не залезать, и вот почему:
1. Boost кроссплатформенен — мы увидим мешанину из директив препроцессора.
2. Boost позволяет эмулировать возможности новых стандартов C++ на старых компиляторах: например, лямбды, functional, move semantics, variadic templates. Какими костылями и какой ценой это было достигнуто, лучше не смотреть.
3. Время компиляции программы с Boost на порядок выше, чем на STL. У меня есть простой проект с Boost, который делает простую фильтрацию изображений, который компилируется 30 секунд, и аналогичный без Boost, который компилируется за секунду. Если есть возможность отказаться от буста — лучше отказаться.
Но в целом Boost не так плох. Boost можно рассматривать как передний край развития C++. Именно благодаря Boost C++ эволюционирует: вещи из Boost переходят в стандарт C++ и становятся частью STL.
Модель с инклюдами, разделением на заголовочные и исполняемые файлы — это рудимент, тянущийся со времён C. Беда в том, что модули для C++ так и не ввели.
Ну да, если изучать C++ как C с классами — будет просто. Главное, не пытаться потом бить пяткой в грудь, утверждая, что знаешь C++.
> JavaScript — мощный быстрый язык позволяющий буквально всё…
Это вы так пошутили? Это язык без стандартной библиотеки — каждый вынужден использовать сторонние модули. Быстрый — у интерпретируемых языков нет затрат на компиляцию, но скорость выполнения очень низкая. Буквально всё, но только в пределах песочницы, в которой он запущен.
Ну да, у меня сначала был тетрис, потом домино (компьютер меня даже обыгрывал), потом творческий подход к решению задач по обработке изображений в университете (дано задание, решать можно любыми средствами), затем — полноценный бот для онлайн-игры, имеющий сервер обновления и около 50-100 пользователей, ну и потом просто работа.
Всё дело в том, что между «писать на C++» и «эффективно писать на C++» — огромная пропасть.
Ничто не мешает писать на C++ как на C с классами — но в этом случае я бы порекомендовал Java или C# — это уменьшило бы время разработки.
C++ сложен кучей нюансов, которые непременно вылезут в процессе разработки (привет, stackoverflow). Есть ещё C++11 и C++14, которые внесли много нового, в т.ч. и принципиально нового.
И я очень надеюсь, что с введением модулей будет полностью переработана STL.
STL ужасен до невозможности после опыта работы с более новыми языками с нормальными библиотеками. Больше всего бесит широкое использование беззнаковых типов и смешение знаковых/беззнаковых. Затем — ужасный iostream с нелогичными перегрузками и форматированием. В качестве прикола пытался написать аналог .NET String на C++ с SubString (с указателями), особенно String.Format с variadic templates. Даже работало и было на порядок удобнее printf и тем более cout.
У меня получилось 175M инкрементов в секунду при одном потоке и всего 47M при 2 и большем числе потоков. Получается, что при инкременте в 4 потока каждый из потоков выполняет инкремент всего 12M раз. Т.е. когда к памяти имеет доступ один поток, получается около 23 тактов на операцию, а когда несколько (например, 4), то значение увеличивается до 300-350 тактов. Для сравнения: простой инкремент — 1-2 такта.
В случае многопроцессорных систем для обеспечения атомарности стало необходимо также блокировать совместный доступ к памяти. Поэтому Interlocked команды используются даже если аргумент влезает в регистр процессора.
А вот Delphi для обучения программированию не нужен. Он действительно был актуален 10-15 лет назад, но не за счёт языковых возможностей, а из-за библиотек. Сейчас для тех же целей гораздо актуальнее изучать C#/Java.
На предложение показать проблему — ноутбук не с собой.
Ещё и ходила на занятия один раз через два.
Все студенты перед заданием получают теорию (что такое свёртка и как её считать), программу-болванку для работы с изображениями (загрузка и сохранение). Консультируем студентов с удовольствием. Дополнительных материалов (учебники, интернет) навалом. В чём проблема решить простую задачу? Но если человек не может хоть как-то решить даже простую задачу, то такой человек нам не нужен, и тратить своё время на него мы не видим смысла.
А теперь взгляните вот сюда (отдельная библиотека boost.preprocessor):
https://github.com/boostorg/preprocessor/tree/develop/include/boost/preprocessor/tuple
Ну или сюда (кусок из boost.mpl):
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preprocessed/msvc70/map.hpp
А для философов даже слова «детерминированный» и «определённый» имеют разный смысл.
Понятно, что в продакшене нужно использовать готовые проверенные решения, но нет ничего хуже использования готовых решений без понимания, как они устроены изнутри.
Кодер не способен осилить Кнута или Кормена. Кодер не может оценивать эффективность алгоритмов, в результате чего программа может начать тормозить на пустом месте. Кодер не способен решать задачи, где требуется применение математических методов. Кодер не способен придумать или реализовать какой-нибудь алгоритм, и т.д. Идея, надеюсь, понятна.
Например, была у меня пара студентов: с одной стороны, уже подрабатывали разработчиками, с другой — не могли решить элементарные задачи. Одна студентка-разработчица под iOS вообще убила: за год не смогла написать свёртку изображений (функция-велосипед пишется за 5 минут), потому что не понимала, как. Искала готовые решения, пытаясь разобраться с OpenCV, но так и смогла этого сделать. Пришлось в итоге её выгнать.
1. Boost кроссплатформенен — мы увидим мешанину из директив препроцессора.
2. Boost позволяет эмулировать возможности новых стандартов C++ на старых компиляторах: например, лямбды, functional, move semantics, variadic templates. Какими костылями и какой ценой это было достигнуто, лучше не смотреть.
3. Время компиляции программы с Boost на порядок выше, чем на STL. У меня есть простой проект с Boost, который делает простую фильтрацию изображений, который компилируется 30 секунд, и аналогичный без Boost, который компилируется за секунду. Если есть возможность отказаться от буста — лучше отказаться.
Но в целом Boost не так плох. Boost можно рассматривать как передний край развития C++. Именно благодаря Boost C++ эволюционирует: вещи из Boost переходят в стандарт C++ и становятся частью STL.
> JavaScript — мощный быстрый язык позволяющий буквально всё…
Это вы так пошутили? Это язык без стандартной библиотеки — каждый вынужден использовать сторонние модули. Быстрый — у интерпретируемых языков нет затрат на компиляцию, но скорость выполнения очень низкая. Буквально всё, но только в пределах песочницы, в которой он запущен.
Ничто не мешает писать на C++ как на C с классами — но в этом случае я бы порекомендовал Java или C# — это уменьшило бы время разработки.
C++ сложен кучей нюансов, которые непременно вылезут в процессе разработки (привет, stackoverflow). Есть ещё C++11 и C++14, которые внесли много нового, в т.ч. и принципиально нового.