Здравствуйте, AeroSun, Вы писали:
M>>>>1) часто на сервере нужно править исходники. Там только текстовый терминал.
AS>>>Шта? AS>>>Какой сервер? К чему он указан? Мы точно про С++ говорим?)
N>>Как раз для софта на C++ такое вероятнее, чем на многих других языках. N>>Причём часто сервер одновременно embedded в смысле малых ресурсов.
AS>Вообще невероятно, из раздела особо фантастичной фантастики. AS>Про embedded — это вообще файспалм. AS>Я понимаю, что про С++ ходит много слухов, но всё на самом деле не так
Ну то есть вы единственный кто с C++ работает, а остальные слухами кормятся? Да, понятно. Только вот интересно, с каким это я языком работаю последние лет 7 достаточно плотно, а то называется он почему-то точно так же, выглядит точно так же, а оказывается совершенно другой...
(А с C — 24 почти непрерывно, для сравнения. Лучше считать этот срок, наверно, потому что фишки C++ тут не принципиальны.)
M>>>>3) Я привык клавитатурой работать быстро, а тут нужно мышкой править через IDE — это дольше и неудобнее. AS>>>Все ИДЕ имеют хоткеи, дублирующие функциональность мышки. И серьёзно — упомянутая разница в скорости работы с мышкой\клавиатурой в процессе разработки не важна в принципе. N>>Зато графика в сотни раз прожорливее по трафику. N>>Хотя это нивелируется тем, что в некоторых IDE можно сделать ремотное управление по ssh+gdb... AS>Это всё из разряда "сделать из буханки троллейбус". Вы выдумываете проблемы, которых в реальной жизни у разработки на С++ не существует.
Ну вот я и говорю — какая-то жизнь одновременно реальная (у меня) и нереальная (у вас). Простите, как ваша планета зовётся?
(Заметьте, я не говорю, что мы так делаем правильно или даже что часто. Это на 99% аварийный режим. Но...)
AS>>>Мой совет — просто научиться пользоваться средствами ИДЕ и данные проблемы уйдут как класс. N>>Её надо по-вашему запускать на целевом хосте, или как?
AS> AS>... не могу понять — это прикол или серьезно спрашивате?)
Серьёзно. Но теперь вижу, что спрашивать не было смысла. Скажите, а до Земли вам сколько лететь?
Здравствуйте, netch80, Вы писали:
N>Ну то есть вы единственный кто с C++ работает, а остальные слухами кормятся? Да, понятно. Только вот интересно, с каким это я языком работаю последние лет 7 достаточно плотно, а то называется он почему-то точно так же, выглядит точно так же, а оказывается совершенно другой...
Видимо да, вы что-то другое делаете и путаете что-то. Так как на С++ на embedded никто не разрабатывает в силу ряда причин, которые выходят за рамки топика. Для этих целей используют кросс-компиляцию.
AS>>>>Мой совет — просто научиться пользоваться средствами ИДЕ и данные проблемы уйдут как класс. N>>>Её надо по-вашему запускать на целевом хосте, или как?
AS>> AS>>... не могу понять — это прикол или серьезно спрашивате?)
N>Серьёзно. Но теперь вижу, что спрашивать не было смысла. Скажите, а до Земли вам сколько лететь?
Софт на С++ в 100% случаев работает на нескольких железках\серверах\телефонах\ и т.д.
Вопрос — вы заново пишите код на каждом устройстве?
Советую что-нибудь почитать про системы контроля версий, билд-системы, системы непрерывной интеграции и т.п.
И вообще про то как разрабатывать софт на С++.
И тогда таких странных вопросов у вас не будет.
Здравствуйте, netch80, Вы писали:
N>(Заметьте, я не говорю, что мы так делаем правильно или даже что часто. Это на 99% аварийный режим. Но...)
Да нет у С++ никакого аварийного режима с правкой исходников на целевом устройстве.
Это же классический троллейбус из буханки.
Это всё мифы перекочевавшие от админов о "горячей правке конфигов на проде". Оно никаким боком не мапится на С++.
Здравствуйте, AeroSun, Вы писали:
AS>Видимо да, вы что-то другое делаете и путаете что-то. Так как на С++ на embedded никто не разрабатывает в силу ряда причин, которые выходят за рамки топика. Для этих целей используют кросс-компиляцию.
В последнем случае, который я вспоминал, было прокси, сидящее где-то у чёрта на куличках в хитроватой железяке и ещё и в контейнере, как сейчас модно, с доступом через три ssh, диска было что-то вроде 40MB, оперативки сравнимо, и компилировать там уже было нереально — а вот влить целиком результат компиляции (с исходниками) и напустить gdb вживую — это как раз то, что помогло поймать ситуацию "пакет шмяк, данные жмяк, zzz event бздынь, важное поле пшшшш, исполнение бряк, о, я вижу проблемные данные!"
Но если бы ресурсов было чуть побольше, как на QA стенде — то и компиляцию бы туда завели без проблем, и CLion какой-нибудь прокинули на remote host всё исполнять аж бегом — и так тоже делали.
В стабильном варианте для юзеров, конечно, всё это пакетируется и контейнеризуется, там не то что gcc, там less не найдёшь без лома и топора. А вот ловить расставив 100500 отладок — чем легче это сделать на месте, тем быстрее...
А у коллеги, вероятно, и контейнеризации нет. В ISP я в основном так делал — но там у меня по стандартной схеме pets vs. cattle были таки pets. Сейчас у юзеров у нас такое не водится, всё-таки повторяемость devops-процесса вкусна переносимостью опыта.
N>>Серьёзно. Но теперь вижу, что спрашивать не было смысла. Скажите, а до Земли вам сколько лететь?
AS>Софт на С++ в 100% случаев работает на нескольких железках\серверах\телефонах\ и т.д. AS>Вопрос — вы заново пишите код на каждом устройстве?
Ну вы таки почему-то отказались понимать изначально, что это всё про специализированный патчинг на месте и про отладку. Хотя можно было просто спросить.
AS>Советую что-нибудь почитать про системы контроля версий, билд-системы, системы непрерывной интеграции и т.п. AS>И вообще про то как разрабатывать софт на С++. AS>И тогда таких странных вопросов у вас не будет.
Не считайте себя единственным знатоком названных вами страшных слов
И до седмижды повторяю: даже там, где основной путь лежит через все эти системы, остаётся 1% на всякое непредвиденное. Главное, чтобы таки не больше 1%.
Здравствуйте, AeroSun, Вы писали:
N>>(Заметьте, я не говорю, что мы так делаем правильно или даже что часто. Это на 99% аварийный режим. Но...)
AS>Да нет у С++ никакого аварийного режима с правкой исходников на целевом устройстве.
У C++ нет, он язык и компилятор. У конкретной софтины в конкретном месте вполне может быть, и происходило неоднократно совсем недавно, ещё детали не стёрлись.
AS>Это же классический троллейбус из буханки. AS>Это всё мифы перекочевавшие от админов о "горячей правке конфигов на проде". Оно никаким боком не мапится на С++.
Года не прошло с конкретной реализации этого "мифа".
Здравствуйте, netch80, Вы писали:
N>В последнем случае, который я вспоминал, было прокси, сидящее где-то у чёрта на куличках в хитроватой железяке и ещё и в контейнере, как сейчас модно, с доступом через три ssh, диска было что-то вроде 40MB, оперативки сравнимо, и компилировать там уже было нереально — а вот влить целиком результат компиляции (с исходниками) и напустить gdb вживую — это как раз то, что помогло поймать ситуацию "пакет шмяк, данные жмяк, zzz event бздынь, важное поле пшшшш, исполнение бряк, о, я вижу проблемные данные!" N>Но если бы ресурсов было чуть побольше, как на QA стенде — то и компиляцию бы туда завели без проблем, и CLion какой-нибудь прокинули на remote host всё исполнять аж бегом — и так тоже делали. N>В стабильном варианте для юзеров, конечно, всё это пакетируется и контейнеризуется, там не то что gcc, там less не найдёшь без лома и топора. А вот ловить расставив 100500 отладок — чем легче это сделать на месте, тем быстрее...
Не важно сколько там конетейнеров, уровней ssh, и т.п. — на С++ никто не ведёт разработку "по месту", разработка всегда идёт на нормальной машине, код заливается в систему контроля версий, он проверяется потом QA или как минимум пишутся юнит\интеграционные тесты, в конец специально выделенный человек (отдел) делает билд, подписывает и деплоит.
Никакого "хотфикса" а-ля "зайти по цепочке ssh по диалапу на северном полюсе и на месте поправить исходники, собрать и задеплоить" в С++ разработке нет от слова вообще.
N>Ну вы таки почему-то отказались понимать изначально, что это всё про специализированный патчинг на месте и про отладку. Хотя можно было просто спросить.
С++ это не скриптовый язык, никакого патчинга в нём никто не делает. При проблеме делается реверт на предыдущий бинарник и вставляется пистон всем ответственным за провтык. Потом, после доработки, выкатывается пофикшенная версия в стандартном режиме.
Потому что С++ код несколько сложнее однострочного скрипта одмина.
А с отладкой ни в каком режиме проблем нет.
N>И до седмижды повторяю: даже там, где основной путь лежит через все эти системы, остаётся 1% на всякое непредвиденное. Главное, чтобы таки не больше 1%.
А я ещё раз настаиваю, что нет даже 1% непредвиденного, чтобы использовать то извращение, что вы предлагаете (держать исходники на целевой\целевых продакт машинах и там билдить).
Ни один менеджер не возьмёт на себя такие риски с нарушением всех инженерных подходов при разработке софта ради непонятно чего.
Здравствуйте, AeroSun, Вы писали:
AS>Не важно сколько там конетейнеров, уровней ssh, и т.п. — на С++ никто не ведёт разработку "по месту", разработка всегда идёт на нормальной машине, код заливается в систему контроля версий, он проверяется потом QA или как минимум пишутся юнит\интеграционные тесты, в конец специально выделенный человек (отдел) делает билд, подписывает и деплоит. AS>Никакого "хотфикса" а-ля "зайти по цепочке ssh по диалапу на северном полюсе и на месте поправить исходники, собрать и задеплоить" в С++ разработке нет от слова вообще.
"Блажен кто верует, тепло ему на свете" (c).
AS>С++ это не скриптовый язык, никакого патчинга в нём никто не делает. При проблеме делается реверт на предыдущий бинарник и вставляется пистон всем ответственным за провтык. Потом, после доработки, выкатывается пофикшенная версия в стандартном режиме. AS>Потому что С++ код несколько сложнее однострочного скрипта одмина.
Аналогично.
AS>А я ещё раз настаиваю, что нет даже 1% непредвиденного, чтобы использовать то извращение, что вы предлагаете (держать исходники на целевой\целевых продакт машинах и там билдить). AS>Ни один менеджер не возьмёт на себя такие риски с нарушением всех инженерных подходов при разработке софта ради непонятно чего.
AS>Не важно сколько там конетейнеров, уровней ssh, и т.п. — на С++ никто не ведёт разработку "по месту", разработка всегда идёт на нормальной машине, код заливается в систему контроля версий, он проверяется потом QA или как минимум пишутся юнит\интеграционные тесты, в конец специально выделенный человек (отдел) делает билд, подписывает и деплоит.
Видимо вы свой опыт привели и думаете, что так делают все. Или просто книжек прочитали как должно быть ? Расскажите хоть где вы так работаете, что у вас целый специальный отдел делает билд ?
я лично работаю
msvc и clang нужный мне функционал без проблем поддерживает
для линукса, видел что и gcc тоже поддерживает, но нужный мне функционал еще не проверял
но даже если и не будет поддерживать, возьму clang
нужные мне фиксы для некоторых С++20 features
там до сих пор partial
хотя в clang уже как минимум два релиза назад заработали, хотя issues на них висят все еще открытыми
M>Для меня основной минус с++
Плюсы веделяются своей историей, и возникшей в связи с этим уже философией. Причем вот мне почему-то кажется точно не без юмора. Т.е. это когда пережив множество историй, можно немного потратить время на одну из них, одна из последних и интересных — некое зависание комитета по стандартизации, от чего случилась некая рЭволюционная ситуация "верхи — не хотят, а низы не могут", низы именно уже не могли.. ждать. Ну а поскольку в плюсы пробралось достаточно много интуитивных α-самцов, низы проломили дно снизу, вверх,... и вот привет, на те boost. Ну я не знаю, как такое можно было замутить где-то в каком нить фреймворке в шарпах, но у нас народ решительный. И первый культурный привет, который я помню — это был compile time typeof участника данного форума, чистый хакинг, как раз в мелочах относительно включаемых шаблонных классов. Потом много было чего интересного.
Но что хочется заметить, что когда слушаешь Страуструпа, то можно почерпнуть, ну кроме плюсового контекста, допустим фразу "без блэкборда не скажу". Вот сидишь ты допустим в стеке задачи, глубоооком таком, минут 15 лично мне только на вкручивание всего контекста в свой уже стек, и приходит приходящий, и ты упс, выпустить жалко, его — стек, а приходящий, ну на столько приходящий, что понимаешь, что этот кандидат математических наук, решил, что я его дипломный руководитель, акстись, — у мине четыре коридорных, не мешай, .. — и на автомате — "без блэкборда не скажу", а в наушники тебе в это время, Монк как говорят иногда музыканты — Фелониус, в фоне. И с перепугу хвать, а где стек? А, воот не потерял, хвост как гвоорится в руках, значит — харрошая фраза, умный человек ведь сказал целый Страуструп. Вот так.
В общем, и целом, — нормально у нас все с плюсами, просто прекрасно. У нас там полный джаз, да, я помню, как мне один джавист на проекте, на котором он кричал, что нет AI, а проект nlp-шный с языком для NLP (просто мой хороший друг не дочитал, что AI есть и для nlp и не обязательно аппроксимационный). Вот он говорил также, что наши шаблоны открыли "как остров", и знаете. Я согласен, джаз тоже так открывали, играют и хотьбыхны, — цвету кожи, неакедимичности, необразованности, .. но зарвались. Забыли отцов основателей.
По делу мне сказать конкретно нечего, после моей извращенной часто практики, где хватаются за все, получается в препроцессоре — делаешь в препроцессоре, получается в шаблонах — вперед. Я вот одного не понимаю, че все пристали к этому бедному препроцессору, хорошая вещь, там столько хороших и ценных практик, что... а — давайте засунем его в АСТ, прям вот не только в llvm. А что ??
Коллеги, на самом деле, мы уже, зрелые ткскть программисты, верим, в то, что ... ну понятно, что хрустит оно тоже, но еще оно и должно быть вкусно. Прежде всего, вот как хамон с пивом. НУ или как допустим бемша свинг сыгранная медески трио (не монком), именно так надо постигать такие темы) тогда и плюсы сказкой будут. ээх хаживал тут иногда, чувак похожий .. джаззер мол. Даже знаете кого ? Колтрейна гиант степ играл, ну ..мне колтрейн просто не оч .. духовики, слишком много звуку отдают, если круто звучит майлс девис (им нравится именно звук трубы, такой тооонкий). Но вообще мы за плюсы. Не надо наездов — лучше предлрожите как добавить
c-time-рефлекшин, тока оно мне ужежь не надо, тут столько вариантов было по нему
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Sm0ke, Вы писали:
S>>При использовании модулей шаблоны как раз нормально размещаются в .cpp файлах.
M>А чем тогда эти .cpp файлы отличаются от .h файлов?
Когда ты инклюдишь .h то компилятор его парсит заново каждый раз.
Когда ты компилируешь .cpp и потом импортишь как модуль, то всё уже скомпилировано и хранится в удобном для компилятора формате. Таким образом компиляция всего проекта происходит быстрее.
Можно даже из STL инклюдов делать модули и импортировать через:
import <iostream>;
И компилятор уже не будет парсить их тоже.
Но есть ограничение. Файл с модулем, который ты импортируешь должен быть уже скомпилирован, иначе компилятор его не найдёт и будет ошибка компиляции.
S>Когда ты компилируешь .cpp и потом импортишь как модуль, то всё уже скомпилировано и хранится в удобном для компилятора формате. Таким образом компиляция всего проекта происходит быстрее.
А чем это отличается от древней статической либы? Которая по сути просто пачка объектников в одном файле.
Здравствуйте, maks1180, Вы писали:
AS>>Не важно сколько там конетейнеров, уровней ssh, и т.п. — на С++ никто не ведёт разработку "по месту", разработка всегда идёт на нормальной машине, код заливается в систему контроля версий, он проверяется потом QA или как минимум пишутся юнит\интеграционные тесты, в конец специально выделенный человек (отдел) делает билд, подписывает и деплоит.
M>Видимо вы свой опыт привели и думаете, что так делают все. Или просто книжек прочитали как должно быть ? Расскажите хоть где вы так работаете, что у вас целый специальный отдел делает билд ?
Ну у меня на прошлой работе было именно так (на текущей ещё не добрался до подробностей). Тут совершенно не секрет — portaone.com, поставка VoIP appliances с биллингом, софтсвичом и сопутствующими компонентами. Разработка ведётся на чём хочешь, но итого софт должен быть проверен на базовые проблемы самим разработчиком на виртуалках, которые реализуют сжатую в один хост полную систему (для особых случаев — в 2-3 хоста), поэтому в зависимости от персональных вкусов используется какой-то ремотный вариант управления из IDE (я брал CLion) или без него (шелл+vim+make уже пригодно во многих случаях). Потом проверка в CI (два набора тестов — от самих девелов и от QA), ревью коллегами, влив в целевую ветку, проверка уже вручную в QA и, если всё хорошо, официальный релиз ветки, а с неё нарезаются инсталляционные и обновительные комплекты (делают девопы из отдела релизов), в виде инсталлятов (загрузочный ISO+USB) и репозитория пакетов (для yum). Софт ставится (набор rpm-пакетиков согласно роли конкретного хоста) и конфигурится (сложная система, прописывает 100500 параметров), и идёт работать. В нормальном режиме девелы не имеют доступа к клиенту, имеет только саппорт через определённые процедуры.
Подробнее в доках на сайте, если интересно.
Это основной путь, который должен соблюдаться по максимуму, но если особая проблема — то включаются и особые процедуры вплоть до доступа на систему клиента с патчингом и сборкой на ней. Вот у меня за последние три года было штуки 4 таких случаев.
Принципиально, что после того, как всё удовлетворено и клиент подтвердил исправление, начинается разбор полётов — код бэкапится, сравнивается с базовой веткой, очищается от дебажной печати, девелопер должен описать в тикет проблему и результаты, по необходимости создаются тикеты на другие вскрытые проблемы...
Что там у коллеги AeroSun, не знаю, но обобщает он совершенно неадекватно. Видимо, опыт в 1-2 проекта специфической направленности не даёт больше данных.
Здравствуйте, Vzhyk2, Вы писали:
S>>Когда ты компилируешь .cpp и потом импортишь как модуль, то всё уже скомпилировано и хранится в удобном для компилятора формате. Таким образом компиляция всего проекта происходит быстрее. V>А чем это отличается от древней статической либы? Которая по сути просто пачка объектников в одном файле.
Тем, что .lib идут в пачке с .h (которые опять же парсятся при инклюде).
А тут только .cpp и никакие .h уже не нужны для импорта.
Но если надо один модуль разделить на файлы, то это делается через партишены. ( имя_модуля:имя_партишена )
Здравствуйте, maks1180, Вы писали:
M>Видимо вы свой опыт привели и думаете, что так делают все. Или просто книжек прочитали как должно быть ? Расскажите хоть где вы так работаете, что у вас целый специальный отдел делает билд ?
Я подозреваю, что опыта у меня минимум на 10 лет больше всех присутствующих. Опыт есть практически во всех отраслях и со всем чем можно (от ембедед до систем на докере)
То, что я описал — происходит кругом так где важна хоть какая-то секьюрность.
Девы не имеют никакого доступа к распространению бинарников.
В самом отделе билда как правило ещё и своя система ответственности.
То, что описывает товарищ netch80 — это тот самый троллейбус из буханки.
Можно фантазировать на подобную тему сколько угодно, но ни один менеджер не возьмет на себя ответственность за подобное.
Скажем, если бы у меня в отделе появился чел с подобной идеей — то первыми вопросами было бы:
1) Может человеку стоит взять отпуск — заработался?
2) кто возьмет на себя ответственность в случае чего?
3) Кто заплатит за время когда разработчик занимается непонятно чем вместо продолжения выполнения своей работы?
4) Если есть секьюрность — то что предлагает и по какому праву в разработчик в таком случае?
Ещё раз — в С++ такого изврата в принципе нет. Делается откат на предыдущий бинарник и начинается разбор полётов. Исправленная версия выкатывается в обычном режиме.
И уж абсолютно никто не держит исходники на целевом устройстве. А идея компилить их в ембедед — это вообще за гранью понимания разработки на С++
M>>Видимо вы свой опыт привели и думаете, что так делают все. Или просто книжек прочитали как должно быть ? Расскажите хоть где вы так работаете, что у вас целый специальный отдел делает билд ?
AS>Я подозреваю, что опыта у меня минимум на 10 лет больше всех присутствующих. Опыт есть практически во всех отраслях и со всем чем можно (от ембедед до систем на докере)
Вы не ответили на вопрос где вы так работаете, что у вас целый специальный отдел делает билд ?
Я вот работал в Майкрософте (США, редмонт) 13 лет назад, даже там я такого не видел...
MA>В общем, минус .h файлов — он же и его плюс. Если .h файлы хорошо оформлены — то с таким кодом, очень приятно работать.
Читать только приятнее, и то не всегда, например значение аргументов (функции) по умолчанию написаны только в h файле, и поэтому в cpp их вообще не видно.
Менять же без IDE жутко неудобно в 2-х местах нужно это делать.
Здравствуйте, maks1180, Вы писали:
M>Для меня основной минус с++ от которого хотелось бы избавиться — это дублирование кода. M>Приходиться одно и тоже писать (название функций) в h и в cpp файлах. И менять тоже нужно в двух местах.
M>1) я пробовал писать всё в h файле (т.е. и тело функций), но тогда возникают проблемы: M>1.1 — если класс A использует класс B и класс B использует класс A — что очень часто бывает в больших проектах. Тогда приходится некоторые функции выносить в cpp.
В таких случаях я применяю "интерфейс" (для C++ это абстрактный базовый класс): https://stackoverflow.com/questions/9756893/how-to-implement-interfaces-in-c
Тогда класс A будет использовать InterfaceB (базовый класс для B) вместо непосредственно класса B.
M>1.2 — проблемы с #define, т.е. если #define определён в cpp после #include, он действует только в одном cpp (обычно один файл cpp = один класс). Если определить #define в h, он будет действовать на все классы которые включены после данного файла.
Для более сложных случаев, вместо макроопределения для функций/типов — применяю ключевое слово using (как задание алиаса для пользовательских типов данных): https://en.cppreference.com/w/cpp/language/type_alias
M>Может быть данные проблемы уже как-то решены, но я об этом не знаю ?
Это не проблемы.
Что же касается названия и аргументов функций, то лббая IDE решает данные вопросы.
