Comments 111
А есть ли смысл изучать сейчас плюсы, если есть Go? Действительно интересно.
Изучать стоит то, на чем собираешься работать.
А знание основ С++ дает возможность более легкого вхождения в изучение другого ЯП.
Знание основ хоть какого-нибудь ЯП даёт возможность более лёгкого вхождения в изучение другого ЯП.
В моем вопросе речь была совершенно про другое. Я не спрашивал про первый язык. Вопрос был именно про Go vs С++, в контексте того что у Go сообщество развивается стремительно, интересные запросы по работе. Так же не в одной статье видел про то что на данный момент лучше изучать Go чем С++. Поэтому и спросил у автора поста, учитывая его опыт.
Во-первых, на C++ уже написано очень много кода — тот же Chromium. Или Кликхаус. Ну и разные сервисы в больших компаниях, в которые вам может захотеться поконтрибьютить изнутри. Сюда же можно отнести большое комьюитини и огромное количество библиотек под разные платформы.
Во-вторых, Go стремится к низкому порогу входа, и из-за этого некоторые задачи на нём решаются более многословно. (Но местами Go, безусловно, компактнее.)
Мне пока не кажется, что один язык полностью заменит другой. Скорее, будет как с Java или C#, и каждый займёт свою нишу.
Поглядим лет через 50 :)
s/Go/Rust
Небольшая надежда есть только на то, что где-нибудь в США кто-то топнет ногой и скажет «всё, блин, ПО для атомных станций и самолётов больше писать на сишке нельзя, только Rust или что-то с не меньшей степенью защиты». Вот тогда да, появятся и вакансии и проекты.
Мозилла явно не в лучшей форме, чтобы его тянуть, а больше он особо никому и не нужен.
А вы можете так нагло не врать? Если уж на то пошло, Rust изначально был разработан Грейдоном Хоаром в качестве личного проекта, к спонсированию которого Mozilla подключилась значительно позднее. А помимо Mozilla, Rust используется в проде у Cloudflare, Amazon, Dropbox, NPM, 1Password и ещё дофига других компаний, так что нет, Rust в обозримом будущем с таким количеством заинтересованных в нём лиц никуда не денется.
Вам придётся изучать и C и C++ хотя бы уже для того, чтобы писать рабочие и качественные обертки для интеропа раста с массой уже существующих библиотек на этих языках (если вы в бизнес-проекте заикнетесь про RIIR всего подряд, вашему руководству это вряд ли понравится), а также отлаживать интероп в случае необходимости. В идеале хорошо бы изучить ещё и ассемблер, если в ваши задачи входит написание высокопроизводительного кода — вам придётся периодически пялиться в asm output, понимать, что там происходит и что там "не совсем так".
У нас на работе у парочки джунов Rust — первый язык. У нас RIIR во все щели, мы им даем переписывать сишные утилиты. С они не знают, читают код чисто семантически, без понимания тонкостей всех приседаний. А для оберток и интеропа надо уметь читать. И то, не С, а документацию.
Вот бы на собеседовании в Яндексе был вопрос про while do и ты такой — "ну вот представьте, есть в холодильнике торт… "
Другое дело, что про while знают почти все, а вот когда нужно новичку за десять минут объяснить устройство сложной продакшен-архитектуры — тут и аналогия с тортиками подойдёт :)
Суть задачи — даются два вещественных числа и нужно написать равны ли они, а если не равны, то их разницу.
Показывает свое решение — код прошел 10 тестов из 31. Смотрю на код — вроде все верно. Если равны, то сообщение; если одно число больше, то вычитаем из большего меньшее.
В логике ошибок не вижу. Говорит, что причины ошибок указаны такие:
Вы не считаете размер половинок вещественным числом
Вы неправильно обрабатываете случай, когда первая часть больше
Вы неправильно обрабатываете случай, когда первая часть меньше
В результате оказалось, что товарищ в коде делал:
cout << to_string(a-b); // выведет, например «0.900000»
А надо было:
cout << a-b; // выведет, «0.9».
Говорит, что вроде в лекциях упоминали или использовали именно to_string. Про точность в ответе в задаче я не увидел.
Учитывая, что ситуация один-в-один гуглится прям сразу, то выглядит это не хорошо. Особенно для одной из первых задач.
За исключением этого момента курс хвалил, но опять же занимается еще не долго, посмотрим, что скажет в конце.
Это явный баг, поправим.
1) Рваное повествование, зачастую блоки не связаны с друг другом и повествование очень поверхностное и постоянно прыгает в разные темы и обратно, но радует что хоть и поверхностно но все необходимые темы затронуты.
2) Очень много ошибок в тренажере.
3) Очень долго отвечает поддержка и не в тему часто.
4) Очень мало времени с преподавателем, всего один час за 2 недели, а все остальное время как хочешь так и выкручивайся ищи и читай сам, иногда именно немного и не сразу помогает наставник или студенты. Например в других местах каждое занятие проводит учитель и проверяет так же учитель с которым можно что то обсудить в отличие от тестов.
5) Основной проект всего курса строго фиксированный и с сильно навязанным кодом, если с чем то не согласен то нет возможности внести изменения, так как проверяет выходную работу каждого спринта с начала автоматический тест, который ни кто переписывать не собирается. Например учат что существует только одна кодировка ASCII и что символы выше 127 не обрабатываются и в коде спокойно не используются cctype а берется прямо c >= '\0' && c < ' '; Хотя на самом деле существует множество кодировок и даже если ограничиться ASCII то символ 127 \x7F \177 backspace character (DEL) обрабатывается как обычная буква.
6) Нет возможности выбирать себе нагрузку. Например нельзя параллельно выбирать себе еще темы если есть свободное время(но есть небольшой раздел с заданиями не относящимися к темам курса, где можно что то порешать совместно). Весь курс разбит на жесткие спринты и дедлайны. Например в других местах есть возможность брать несколько направлений одновременно, если есть возможность заниматься больше времени.
И еще много проблем с которыми нужно работать.
Но в целом это лучший курс который можно найти в российском интернете, в других местах нет такого размаха интересных и актуальных тем по C++
Спасибо за фидбек.
Сделать хороший курс по плюсам — действительно олимпиадная задачка: нужно удерживать множество факторов в голове, чтоб в итоге подготовить в обозримые сроки уверенного джуниор-разработчика, а не просто знающего плюсы. Мы лавируем между этими условиями, но иногда обходим подводные камни не с первого раза.
Ваш отзыв мы отдельно обсудим с командой и, если вы готовы, вернёмся с вопросами к вам лично, чтобы вместе обсудить, что можно улучшить.
Сначала дают нотацию, всегда заврешать с «endl», а потом сами же ее и нарушают, так, что ни один тест в задании не проходит. (проверил, испраивли, теперь принимает и с и без «endl»)
Дальше некоторые задачки с оч скудными условиями. В том же 3 уроке, про for всё оч неочеивдно, и вроде логично на реагировать на лог и дополнять условия (брутфорсим вместо внятной поставленой задачи), но доходит до того, что лог никаких ошибок не выдает кроме как «Задача прошла 14/15 проверок» — называется побудь экстрасенсом. (проверил, с июля единственное изменение — выдает «Задача прошла 15/16 проверок»)
Тех поддержка не то что долгая, а для нее практикум как побочка, просто в доп нагрузку. По началу отписки вместо ответов. И скорее пришлют готовый ответ (код), чем дадут на тесты глянуть (точнее без «скорее», так и сказали что тесты показать не могут).
Что ему делать в таком случае? Или на практике все не так плохо?
Ваши сомнения отчасти оправданы: студентам всё же придётся узнать про new и delete; не только для понимания внутреннего устройства контейнеров, но и для чтения страшного кода.
Но я считаю, что не так всё и страшно, чтобы готовить к этому с самого начала. Гугление может привести как к старому коду, так и к смелому эксперименту с C++23. Поэтому в числе прочего важно научить, скажем, смотреть в нужное место на cppreference вместо рандомных поисковых запросов.
Я своим на каждую тему рассказываю: вот вы будете её гуглить, вам будет выпадать такая-то и такая-то фигня (гуглю самостоятельно перед лекцией), вот её читать не надо потому и потому.
Например, если вам в теме "наследование" вам начинают рассказывать, что яблоко наследуется от фрукта, а вентилятор — от электрического двигателя, и вы не понимаете, почему их игрушечный пример без виртуальных функций хоть какое-то отношение к реальности имеет — это нормально, никакого не имеет. Или если где-то написано iostream.h/conio.h — бегите оттуда. А вот ISO C++ FAQ и cppreference читать как раз можно и нужно тренироваться.
У меня к вам вопрос, а как вы учите студентов пользоваться вектором правильно. В моём мире 100% людей работающих с плюсами (и даже сеньоры) иногда да возьмут да и сохранят указатель/ссылку на элемент вектора, а потом возьмут да и добавят новый элемент в вектор, а потом поработают с ссылкой. Я думаю для вас не секрет, что это довольно часто нормально сработает, но вот иногда все будет печально. Так вот как ваши студенты воспринимают первые встречи с УБ и как вы их учите с ними справляться? Учить с++ и не учить как жить в мире с УБ это пустая трата времени и вашего и студентов, а потом ещё и того парня который будет это все чинить.
Не автор, но отвечу: на первой же лекции минут 15-30 посвящается UB и вбиванию в головы запрета на мышление "тут ошибка, но очевидно же, что компилятор поведёт себя так и так" с кучей интерактивных примеров под разными ОС и компиляторами, сравнением с другими языками и фразой про то, почему так.
И дальше регулярно напоминаю каждый раз, когда возникает очередное UB, что нельзя полагаться, что оно проявится ровно таким образом, и что программа может упасть вообще через пять минут в другом месте.
Как ловить — показываю санитайзеры, Valgrind, статический анализ (предупреждения компилятора, clang-tidy, cppcheck), обязательная компиляция под разными компиляторами. Это, разумеется, всё равно покрывает далеко не всё, так что на лекциях регулярно всплывают UB, которые вообще никем не ловятся и молча ломают программу. Иногда. А иногда не ломают. Типичный пример — static initialization order fiasco.
Студенты, как я понимаю, грустят, выживают и делают мемы или проникаются и пытаются возглавить в учебных целях, а что ещё делать.
Что я имею ввиду ?- упражнение типа перечислите все ошибки, которые вы можете найти в таком то
Есть ещё один навык который я называю умением читать код — перед тем как
Ну и самое частое люди обычно находят место в коде куда нужно добавить новый функционал и прямо туда его и фигачат сплошной простыней, а то что используются разные уровни абстракции вообще ни каких сомнений не вызывает. Вот пример для наглядности
void implementLotsOfLogicHere()
{
DoHighLevelA();
DoHighLevelB();
// new code added here
Container anotherViewOnTheData;
while (x: container)
{
if(x == ...)
{
anotherViewOnTheData.push_back( Y{ x } );
}
}
callback(anotherViewOnTheData);
// previous code conitnue
DoHighLevelC();
}
И это еще идеально если DoHighLevelX кто-то уже написал, а в реальности там вместо этих функций тоже смесь кода с разной степенью абстракции — в одной строчке зарождение вселенной, а рядом байтики копируется в цикле из одного вектора в другой.
Если вы еще и читать код ваших студентов учите, то это прямо вообще респект и уважуха.
Ваш комментарий содержит уйму полезных и важных идей.
Про часть из них уверенно скажу, что да, учим. Во второй половине курса есть тема (вот прямо сейчас делаем) про красоту кода, читаемость, масштабируемость и работу с чужим кодом. И одна из задач там — взять чужой сложный код, доработать его под себя и отдать на ревью. Другая задача — взять небольшую чужую библиотеку и приспособить её под нужды своего большого проекта. И тоже отдать на ревью.
Простите за рекламу, но наличие на курсе ревьюеров — это заметное преимущество Практикума перед Курсерой. К слову, я сам в своё время учил C++, проводя ревью студентов :)
У вас похоже действительно годный курс. У меня есть пара пожеланий, пожалуйста не продвигайте использование shared_ptr и любой другой инкарнации — это просто ад, большинство девелоперов в независимости от их опыта имеют ложные ожидания при использовании шаредных указателей, в реальном мире люди ожидают предопределенный порядок вызова деструкторов в многопоточном коде который шарит указатель. Это проблема номер 2, а проблема номер 1 и вообще ошибка на миллиард это деструкторы — опаснее кода в с++ не найти. Колл стэк значительно более половины всех крашей содержит вызов хотя бы одного деструктора. Так хохмы ради проведите опрос среди ваших сеньоров и спросите, а какой код в деструкторы НЕ УБ, т.к. примерно 146% кода в дестукторах из реального мира содержит хотя бы одно уб. Для проверки истинности ответа рекомендую либо стандарт либо тоже самое, но для людей cppreference. Самое печальное обе проблемы поставляются в комплекте.
самое главное объяснять что далеко не любой деструктор это RAII
Это вы про что?
Ресурсом может быть память (new — выделили, delete — освободили), файл (open — открыли, close — закрыли). Да и то насчет файла уже можно поспорить. Особо больше новых ресурсов и не придумать даже. Почти все остальные сущности в программе ресурсом не являются (ну по крайней мере, в тех программах, где слишком много деструкторов)
(т.к. на код ревью в реальности нет доступа ни к исходникам ни к IDE)
На CodeReview есть (и должен быть) доступ и к исходникам и к IDE.
Другое дело, что на практике: если тебе пришлось выкачивать ветку, чтобы разобраться что же CodeReview делает — это признак что в процессе что-то не так (да может быть это сложная задача в сложной предметной области, но на каждую такую «необходимую» сложную задачу приходится несколько где человек просто поленился нормально разбить свои правки).
Завезли :) Это не в самом-самом начале, но довольно рано.
А при первом знакомстве с вектором показываем, что при выходе за границы вас не поймают за руку — и это плата за эффективность.
А какой язык стоит изучать? А не знаю, мы дошли до того, что теперь нет единого стандарта на компилируемый язык программирования.
А так ли оно плохо, это метапрограммирование в с++?
Покажите мне другой язык который умеет то-же самое без привлечения рантайма и с прогнозируемыми накладными расходами? Раст обещал доступ к AST стабилизировать еще до версии 1.0, одноко продвинулись они пока не сильно.
Вы вроде какой-то исследовательский проект пилили за спасибо? Похоже деньги заканчиваются, а спасибо чето не очень вкусное и надо идти добывать масло на хлеб. Я бы тоже хотел свой "Раст" запилить, но… Подожду маленько. Вы хоть "отчёт" о своем исследовании опубликуйте, а то и непонятно "стоило" оно того или нет, понятное дело что вам в кайф, но нам то со стороны виднее.
Половины матерных слов из вашей статьи я не понимаю за не именем соответствующего бэкграунда, но суть мне вроде бы далась. Было бы интересно почитать в переводе на простой и понятный программистский язык. Примеры в ведении были очень хороши и рассказали мне больше чем вся остальная часть. Скажу сразу, что всю мякотку с лемами теоремами и корректностью я даже не пытался осилить. Мне нравится идея жидких типов, но мне это интересно только с точки зрения как это реализовать. Меня вполне устроит знать, что где то кто-то доказал, что это не чушь суть доказательства меня не волнует. Не могли бы вы подсказать где найти код/описание как реализовать эти типы, на каком нибудь народном языке, а не на вашем птичьем агдесе, в котором вот честно вообще нихера не понять.
Не могли бы вы подсказать где найти код/описание как реализовать эти типы, на каком нибудь народном языке, а не на вашем птичьем агдесе, в котором вот честно вообще нихера не понять.
Если реализовать — вы же первым будете возмущаться, фигли тут так много кода и вообще так всё сложно навёрнуто.
К моему сожалению я не могу уловить суть реализации. Слишком большой порог чтобы понять как оно работает мне сначало нужно выучить основы Идриса, спасибо конечно за пример, но для меня сегодня это эквивалентно отсутствию примера. Навряд ли я найду мотивацию изучать Идрис в обозримом будущем.
А где и как были описаны эти системы типов?
Справедливости ради — GHCi рантайм TH не отменяет, про остальные не в курсе как они работают, но подозреваю что там та же история с VM внутри, а это не честное сравнение.
Трудно сказать реализовано TH делает мета-программирование как то принципиально лучше чем C++, тут скорее вопрос что высыпается в консоль когда в шаблонах ошибка. Скорее всего что-то более удобоваримое чем из c++98, а вот с кодом на концептах сравние уже интереснее звучит.
В части компилируемости принимается, мне казалось что в результате генерируется подобие шитого кода с интегрированным в бинарь легковесным рантаймом.
Касательно второго примера -это кодогенерация а не мета программирование.
В свою очередь кодогенерация не прибита к AST а значит сгенерировать что то под конкретные вызовы функций не получится. В этом плане TH крут как раз тем что он совмещает эти концепции, и можно написать шаблон в духе «если передана функция от 2х аргументов скачай json с интернета»
moc это не валидный аргумент, moc завезли во времена когда поддержка мета-программирования популярными на тот момент компиляторами была «не очень». В современном С++ от moc можно избавиться, но т.к. его синтаксис не соответсвует принятому в С++ придётся все эти мета-определения переписывать, а бизнес не очень любит переписывать, так что moc остаётся.
Позволит, если язык, на котором описываются преобразования, достаточно мощен.
Язык тут не причем, можно парсинг джсона и на шаблонах c++ написать, но компилятор не позволяет вам читать файлы во время компиляции.
Берёте libclang…
Так можно и парсилку джсона из вашего примера сделать, к языку C++ это отношение не имеет.
Как? Без макросов только
С макросами, т.к. это единственный способ получить одновременно и имя символа и его строковое представление (нужно для мок объекта), но макросы это часть языка описанная в стандарте. Все еще интересно?
Да я почитал проползал, это вообще ни о том. Я имел ввиду выполнение произвольного кода на с++ как часть компиляции произвольного кода на с++. Я так понимаю это то что умеет хаскель. Что то мне подсказывает для этого интерпретатор с++ должен быть встроен в компилятор или есть другие подходы к этому? Т.е. сложность задачи сводиться к созданию интерпретатора.
На практике нет ничего сложного получить содержимое файла для компиляции — берем условный bin2c, и добавляем его вызов в систему сборки.
Другое дело — выполнить условный fopen во время компиляции — тут надо и окружение c++ запустить, и слинковаться, и разрулить как то глобальные переменные. А теперь представьте что это все происходит в кросс-компиляторе, и объявление того же fopen не совпадает с системным, и например нужна еще другая пачка дефайнов.
но компилятор не позволяет вам читать файлы во время компиляции.
#include «data.json»
C++ изучать, во-первых, поздно
Напомнило, как Остап Бендер бегал по киностудии, пытаясь продать свой сценарий и ему отвечали, что он не подходит для немого кино, так как его уже нет и не подходит для звукового кино, так как его ещё нет. Так и тут — плюсов, оказывается, уже нет, но на их месте тоже пока ещё ничего нет. Ни Rust, ни Go не заняли нишу, а писать всякие там операционки, базы данных и браузеры на чём-то надо.
И почему-то всякие там операционки до сих пор пишутся на си без плюсов. Странно, да?
Ядра, но не юзерспейс. Вот код терминала Windows, вод код калькулятора Windows — это всё плюсы.
А у ядра огромное использование. Даже плюс одна инструкция к коду вызова какой-нибудь функции выделения памяти или переключения потоков — это какие-то невероятные цифры потерь в мировом масштабе, учитывая распространённость ОС и количество вызовов подобных функций каждую секунду.
Только на плюсах можно написать ещё более эффективный код чем на Си.
Я говорю в контексте ядра ОС.
C++ поддерживает почти весь синтаксис Си, а его компилятор столь же эффективен на Си подмножестве (да и обычно это один и тот же компилятор). А так как С++ более развит, есть места где его компилятор может лучше оптимизировать код.
Это конечно если не ударяться в создание фабрики фабрик классов и не обмазываться стандартной библитекой.
ПС
А уж как интересно, когда у вас в C-структуре есть паддинг (заполненный мусором) и вы считаете одинаковые элементы разными ;)
Тут мне кажется есть несколько оснований:
- Легаси.
- Зачем что-то переписывать? Существующие ОС не развиваются прям семимильными шагами, что новый код приходит тоннами. Си на минималках знают все, соответсвенно и патчи прислать могут и т.д.
- Нет специалистов. Ну нет столько людей, которые одновременно знают и умеют в планировщики/ФС/драйвера и т.д., и при этом, являются фанатами С++/rust/haskell и вообще языковой темой.
- Си — это основа основ. Это то, что лежит поверх железа и предоставляет минимальный API/ABI. И даже если ядро ОС будет написано на С++/Rust, то оно будет предоставлять тупые сисколы которые идеально будут соответсвовать Си. Да и вообще Сишное ABI — это стандарт для взаимодействия между разными языками.
github.com/AnthonyCalandra/modern-cpp-features
Стараюсь студентов сразу приучать к осмысленному именованию переменных, обговариваем с ними о соглашении как хорошо писать и как плохо писать код, нормы оформления.
Считаю этот момент тоже важным при обучении программированию.
В статье этого нет, в курсе есть.
Есть и ревьюеры, которые принимают все достаточно большие задачи, и отдельная тема про красивый и масштабируемый код.
1. Размер единичного отступа составляет 2 пробела. Для форматирования кода не используются символы табуляции.
2. Фигурные скобки {} располагаются на отдельной строке и имеют тот же отступ, что и соответствующий им заголовок функционального блока — декларация функции либо условие if / switch / for / while.
3. Параметры функций располагаются на отдельной строке, имеют префикс _и предваряются двойным отступом относительно заголовка функции.
4. Отсутствие в коде неиспользуемого функционала (выражений либо переменных, закомментированных участков устаревшего или отладочного кода)
Имхо вот как раз форматирование кода не имеет с креативностью вообще ничего общего. И правила форматирования должны быть зафиксированы, но так, чтобы о них не думать от слова совсем (ну то есть использовать автоформаттеры).
А вот с тем, что каждый пишет код как хочет и не придерживается единого стиля — не соглашусь. Разработка одиночками ушла немного в прошлое. Сейчас всё больше работа в команде. Поэтому нужно вырабатывать в командах единые правила, иначе будет сложно собирать единый код из разных кусочков.
Во-первых, это было в 2007 году, за 4 года до выхода стандарта С++11, а значит относилось к С++ версии 1998 года(!). Трудно не согласиться с тем, что это был ужасный язык.
Во-вторых, это был ответ на письмо, которое начиналось вот так: «When I first looked at Git source code two things struck me as odd 1. Pure C as opposed to C++. No idea why. Please don't talk about portability, it's BS.». Что он должен был ответить человеку, который начинает разговор с фразы «твой код — дерьмо, потому что не С++»?
Ну и в третьих, это был разговор с программером из Microsoft, идеологическим, так сказать, врагом (ну по крайней мере так это выглядело в 2007 году).
Справедливости ради, там всё-таки заявление, что "Мне кажется странным, что тут Си вместо плюсов. Почему? И нет, не говорите про проблемы с переносимостью, это бред.". Или я чего-то не понимаю?
От себя: сама цитата в основном про то, что у плюсов ниже порог вхождения, что приводит (по мнению Линуса) к более низкому качеству контрибуций от тех, кто пишет на нём. К самому языку там претензий, кроме как "на нём проще писать лютую хрень, чем на Си", не высказывается.
Внутрь цикла while надо добавить: «откусить кусок торта; отойти от холодильника» — иначе, если в холодильнике есть торт, цикл бесконечный
О обучении есть 2 подхода:
- Вы рассказываете теорию, а потом ставите задачу для проверки усвоения.
- Вы ставите задачу и подсказываете обучающемуся что надо изучить для решения этой задачи.
2-й подход более эффективен но требует другой инфраструктуры. Сразу нужны и книги и оборудование/наглядный материал. По этому практически везде используется не особо эффективный 1-й подход.
C++ в Практикуме. Как обучить студентов плюсам, не отпугивая