Бесплатный CLion?
Два дня до момента, когда моя среда разработки, где я мучаю Си++, превратится в тыкву. С преподавательской лицензией меня обломали, попробую другой путь — податься на бесплатную лицензию как бесплатный проект.
Казалось бы дело в шляпе, но там надо показать регулярные коммиты за три месяца, а у меня пока ещё и месяц не прошёл. Но я придумал план, надёжный, как швейцарские часы, — два месяца рефакторинга. Буду перетаскивать очевидные сишные части на Си++. Начал со строк — переписываю сишные указатели на нормальный std::string.
Придётся, видимо, пока взять в качестве редактора VSCode, вот только он не IDE. Ну а какой выбор? В процессе знакомлюсь с тем, что умеет Си++. Смотрите какая прелесть:
std::ostream &operator<<(std::ostream &os, const Colors &color) {
static const std::map <Colors, std::string> colorNames = {
{RESET, "39;49m"},
{BLUE, "01;34m"},
{GREEN, "01;32m"},
{CYAN, "01;36m"},
{RED, "01;31m"},
{MAGENTA, "01;35m"},
{YELLOW, "01;33m"},
{WHITE, "01;37m"},
{BLACK, "01;30m"},
};
os << "\033[" << colorNames.at(color);
return os;
}В Си это была большая функция с оператором switch, которая выводила на экран последовательности для переключения цвета, её надо было вызывать отдельно каждый раз. На Си++ всё удобнее:
std::cout << YELLOW << mess[2] << std::flush;Рраз и строка жёлтая. YELLOW тут у меня — значение перечисляемого типа Colors.
Vscode — не ide? Нет:) он ide, и фичей у него побольше чем в пайчарме. Особенно в части отладки в докере, или по ssh, или в мультиязыковой отладке.
Надо только не забыть войти во вкладку расширений, и кликнуть инсталл на расширении для С++. И будет всё идешное: отладчик, навигация по коду и прочее что мы любим.
Я ставил плагины, но возможно я действительно просто не умею его готовить. Он мне даже код форматировал как в JS, а не как в Си++.
Вместо std::string лучше использовать std::string_view или даже const char *. А для истинных ценителей — std::array<char, 7>.
Мне тут чатгпт подсказывает, что std::string_view без копирования и изменения. Это интересно, а std::array<char, 7> зачем?
От char * я как раз стараюсь уйти, чтобы удобнее было работать со строками и избежать проблем с выделением памяти и освобождением.
Это как? Мусташи в египетском стиле, а не на следующей строке, как прадеды завещали, что-ли?
Наоборот, ставит на следующую строку.
Надеюсь, никогда не придется работать там, где кодстайл требует скобку на той же строке.
А по делу: в современном с++ рекомендуется использовать enum class. Придется, конечно, везде писать Colors::yellow, зато общее пространство имён не загрязняется и отсутствует возможность случайного неявного преобразования в целочисленные типы.
Почему? Это же дело привычки и ничего более.
Я смотрел на него, но так многословно получается (( Загрязнять глобальную зону плохо, но но ведь у этого «плохо» есть аргументация — конфликты имён, а тут откуда им взяться?
На мой взгляд, склеивание управляющего оператора и последующего кода очень сильно ухудшает читаемость, особенно в случае многострочных условий в if. Пора расстаться с этим наследием текстовых дисплеев.
Конечно, каждый может выбирать инструменты сообразно масштабу задачи, но хороший с++ в силу своей сложности всегда был не только языком, но и набором практик, призванных сделать его более безопасным.
Впрочем, тут говорит мой профессиональный опыт работы с большими проектами и участие в собеседованиях, где приходится быстро оценивать, насколько кандидат знаком с современным состоянием языка и сколько времени уйдет на обучение и кодревью.
На мой взгляд, это не так. Я в разных языках сталкиваюсь с разными правилами форматирования кода, на любое из них перестаёшь обращать внимание, главное, чтобы они были.
Да, размер проекта очень сильно сказывается, так же как и работа в команде или одному. В той или иной ситуации оправданными могут быть прямо противоположные практики. Я на работе не буду применять большинство практик (наш проект почти два десятилетия существует и над ним работает очень много людей), которые использую у себя в блоге.
Я понимаю, что с хорошо развитым языком, как правило, идут и хорошие практики, но у них всегда есть аргументация, — «не используем то-то, потому что»… Мне кажется загрязнение глобальной зоны видимости здесь не существенный аргумент — я один в проекте и эту зону контролирую единолично.
Кирилл, держите ваши бляцкие «практики» при себе!
«Наследие текстовых дисплеев» напрочь засело мусором в вашей тупой башке; гниёт, воняет и никак не хочет оттуда высраццо!
Жаль… Очень жаль.
Поистине Титанического Терпения вашим коллегам, что по неосмотрительности али недоразумению вляпались в работу с вами.
Давайте снизим градус, всё-таки.
abrakadabr80, ну, мои коллеги хотя бы не получают в свой адрес потоки немотивированной агрессии...
Но может быть вы все же раскроете мысль — что не так с принятыми в индустрии практиками, основанными на специально добавленных в язык для большей безопасности возможностях?
Jetbrains выдаёт all products license тем кто проходит их курсы.
Пройти 3 раздела в бесплатном https://hyperskill.org/tracks/41?category=8 и пришлют лицензию на месяц. Через месяц пройти следующие три. В качестве временного решения годится
О, спасибо, хороший способ!