Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А десктопные приложения
А кому нужны десктопные приложения? Клепайте веб приложения, продавайте подписку. Если бы тебе банк предлагал чтоб зайти в кабинет, установить десктопное приложение да ещё с зависимостями да ещё работающее на 1.5 версии венды, как далеко бы ты отправил путешествовать тот банк? Ечли в твоей предметной области ещё никто не додумался сделать веб- то ведь, когда додумается, твоя компания уйдёт из бизнеса.
M>>Чет мне кажется, что вы с предыдущим комментатором не разделяете системный пакетный менеджер и менеджер пакетов языка. S>pip он системный или языковой? NPM? Не знаю что там в го и расте, но сдается мне дела там получше, чем в С++.
pip, npm языковые (однако, когда языки интерпретируемые, тут сложно отличить языковой пакет от системного, более того в обоих языках, по-моему, есть инструменты чтобы впихнуть пакеты зависимостей в разрабатываемый проект и распространять все это вместе). В Go и Rust тоже есть свои пакетные менеджеры. Системные это apt (Debian/Ubuntu), yum/dnf (Fedora, RedHat), "фшоколаде" (Windows), "домашнесваренный" в MacOS.
M>>IMHO, не нужно путать пакетный менеджер языка и пакетный менеджер OS. Первый нужен во время написания проекта (и сборки пакетов для OS пакетным менеджером OS). S>Ну вот такого стандартного (покрывающего значительную часть самых распространенных либ на всех 3 платформах) — нет.
Стандартного нет, есть пакетные менеджеры, которые пытаются закрыть эту задачу — conan+CMake, build2, vcpkg. IMHO, подход, когда есть несколько вариантов и они друг с другом конкурируют, лучше, ибо больше шансов, что получится продукт, удобный всем. В случае стандартного менеджера выше шансы авторитарного решения, которое кому-то будет неудобно (но так как для большинства подходит, то всем будет насрать). В случае конкуренции все менеджеры вынуждены будут покрывать максимальное большое количество вариантов использования и тут разработчик — упертый баран, который делает только то, что ему кажется правильным, со временем станет многим неудобен (но это мое IMHO).
S>Если хочется рассказать что-то интересное по теме, то уместно будет рассказать о CI/CD проекта на С++ с поддержкой 3-х платформ, 3+ компиляторов, генерацией кода и зависимостями типа boost/Qt/etc. Расскажите как у вас такое или подобное организованно.
Вот на таких вопросах я стабильно ступорюсь. Тут не чего рассказывать, на мой взгляд. Есть довольно много инструментов, которые хорошо (не идеально) решают такие задачи: пакетные менеджеры (эти пока на 3-ку, но я бы взял conan + CMake), CI/CD (TeamCity, buildbot). Из них любой сисадмин/DevOps соберет для ваших нужд работающую систему. Будут, конечно, мелкие нестыковки и другие задачи, но все это рутина, решаемая в рабочем порядке. Поэтому мой совет простой — найдите сисадмина/девопса, посадите его в команду разработки и объясните круг задач — постепенно получите идеальное (почти) для ваших задач решение (и это решение сильно зависит от конкретики именно ваших задач, поэтому тут более детально сложно что-то рассказать, т.е. чужой опыт для вас может оказаться совсем нерелевантным и бесполезным).
=============
Дальше offtop.
Лично я не люблю решения типа GitLab, где все вместе.
Недавно заметил, что среди C++ разработчиков есть тяга к осваиванию CI/CD и разных Docker'ов. Вряд ли какой-нибудь frontend разработчик или Android developer станет таким заниматься, но в среде C++ к этому какая-то (необъяснимая для меня) фанатичная тяга. ДевОпс/сисадминство так же как и разработка на C++ требует fulltime занятости в течение лет, чтобы наработать нормальную квалификацию (знания и навыки), но, IMHO, это многие не понимают, потому что не в состоянии оценить сложность задач из-за непонимания их сложности. Недавно слушал доклад, как программисты освоили Docker (для унификации среды сборки) и настроили CI (без CD, как я понял). Слушается примерно так же, как если сисадмин решил заняться программированием на C++ и через пол года, освоив ZeroMQ сделал доклад, как он переписал простое приложение, обменивавшееся данными на голых сокетах с использованием ZeroMQ по технологии publish/Subscribe. Ну, это для него, конечно, достижение, но для любого разработчика — рядовая задача.
Так что мое IMHO, для CI/CD лучше найти сисадмина/девопса, а программисту заняться разработкой. И время не нужно будет тратить и результат получится более надежным. Только девопс должен сидеть с разработчиками и быть в курсе происходящего. Ну и сам принимать решения в своей сфере ответственности и отвечать за них. Нормальный девопс реализует именно то, решение, которое лучше подходит для вашего проекта. Расскажет, как оно работает (в общих чертах) и как им пользоваться.
Здравствуйте, kaa.python, Вы писали:
KP>Тогда почему в продуктах Автодеска (ага, те же самые бешеные деньги за одну рабочую станцию) есть RTTI? Что-то мне кажется, кто-то перемудрил
Да причин может быть вагон.
Манагеры могут быть не в курсе, рядовым разработчикам покласть.
А может и еще проще — компания ориентирована на большие корпоративные продажи, которые измеряются лямами, поэтому на мелкие потери от кряков им попросту покласть с прибором.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, CreatorCray, Вы писали:
S>>А кто судья? CC>Здравый смысл.
Это субъективно и зависит от опыта, квалификации и окружения. Здравый смысл у разработчиков, скажем, Boost.Spirit и Boost.Hana может несколько отличаться от здравого смысла разработчиков ACE или POCO.
CC>Угу, когда простой класс, в котором пара полей и одно единственное применение в проекте с самого начала параметризуется бОльшим колвом template parameters чем там вообще есть типов — это плохо.
Далеко не всегда ситуация настолько тривиальная, чтобы сделать однозначный вывод.
Здравствуйте, CreatorCray, Вы писали:
S>>Но проще же не вникать, а просто сказать про укуренный способ. CC>Он укуренный.
Очень убедительный аргумент. Очевидно, что здесь доказательства из той же оперы, что и в разговоре про здравый смысл как мерило оправданности программирования Александреску-стайл.
CC>Из той же оперы что и перекрытие оператора "запятая".
Оператор запятая плох тем, что а) мало кто знает, что его можно перегружать вообще и b) слишком сложно заметить его применение (и, соответственно, изменение семантики простого на вид кода).
В случае с "сдвинуть и присвоить" (т.е., по сути, явно изменить состояние) это не так. Так что нет, не из этой оперы.
Инженерам нужны.
У некоторых доступ к интернету с рабочего места прикрыт. Тксзть, с т.з. безопасности.
$>Если бы тебе банк предлагал чтоб зайти в кабинет, установить десктопное приложение да ещё с зависимостями да ещё работающее на 1.5 версии венды, как далеко бы ты отправил путешествовать тот банк? Ечли в твоей предметной области ещё никто не додумался сделать веб- то ведь, когда додумается, твоя компания уйдёт из бизнеса.
Детский сад... ты не путай онлайн-банк и САПР. Онлайн редакторы есть и давно, но их удел — простейшие поделки любителей и "просто, чтобы было".
Большие компании не доверяют свои проекты онлайн сервису. Да и веб пока еще не пригоден для таких масштабов.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, smeeld, Вы писали:
S>> Предложение писать новую платформу на С++ никто не поддержал, включая старых бородатых C++-ников.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>$>А кому нужны десктопные приложения? Клепайте веб приложения, продавайте подписку.
SVZ>Инженерам нужны. SVZ>У некоторых доступ к интернету с рабочего места прикрыт. Тксзть, с т.з. безопасности.
Поднимайте приватное облако в локалке и вперёд.
SVZ>$>Если бы тебе банк предлагал чтоб зайти в кабинет, установить десктопное приложение да ещё с зависимостями да ещё работающее на 1.5 версии венды, как далеко бы ты отправил путешествовать тот банк? Ечли в твоей предметной области ещё никто не додумался сделать веб- то ведь, когда додумается, твоя компания уйдёт из бизнеса.
SVZ>Детский сад... ты не путай онлайн-банк и САПР. Онлайн редакторы есть и давно, но их удел — простейшие поделки любителей и "просто, чтобы было". SVZ>Большие компании не доверяют свои проекты онлайн сервису. Да и веб пока еще не пригоден для таких масштабов.
Бла бла бла. SVG, canvas, webgl- и САПР можно прекрасно отрисовывать. При этом, централизованный контроль за доступом к документам к отсутствие вопроса с обновлениями.
Здравствуйте, $$, Вы писали:
SVZ>>У некоторых доступ к интернету с рабочего места прикрыт. Тксзть, с т.з. безопасности.
$>Поднимайте приватное облако в локалке и вперёд.
...рыбы это хладнокровные, покрытые чешуей. Но если бы они были покрыты шерстью, то у них водились бы блохи...
Ты как истинный комсомолец — создаешь себе проблемы и с честью их преодолеваешь.
SVZ>>Детский сад... ты не путай онлайн-банк и САПР. Онлайн редакторы есть и давно, но их удел — простейшие поделки любителей и "просто, чтобы было". SVZ>>Большие компании не доверяют свои проекты онлайн сервису. Да и веб пока еще не пригоден для таких масштабов.
$>Бла бла бла. SVG, canvas, webgl- и САПР можно прекрасно отрисовывать. При этом, централизованный контроль за доступом к документам к отсутствие вопроса с обновлениями.
Надеюсь, ты догадываешься, что САПР это не одна только рисовалка, но и масса всяких вычислений. И тут либо придется числодробить на jscript, либо считать на сервере, и гонять по сети гигабайты данных.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, lpd, Вы писали:
... lpd>Шаблоны, перегрузка операторов были в C++98, лямбды — мелочь. У вас что, древний C++? Сейчас 2019, почему мало умных указателей и move-семантика не на каждом шагу??
+100500
Лично я широко применяю в своих проектах как семантику перемещеный, так и смарт-поинтеры.
На крайняк — для анализа ситуаций с утечкой памяти — есть достаточно простые инструменты: http://valgrind.org https://archive.codeplex.com/?p=vld
lpd>Если серьезно, то претензии к C++ (у меня лично) не к перегрузке операторов, которая там давно, а к более новым фичам: move-семантике, указателям<> вместо сборки мусора.
Ну это — как сказать!
Так, если бы сделали сборку мусора, то это бы привело к возникновению недетерминированных задержек при исполнении кода
И если бухгалтеру некритично — за 5 секунд посчитает отчёт или за 6 секунд, то для системы перехвата ракет — это уже катастрофа...
Здравствуйте, AlexGin, Вы писали:
AG>Они, эти навороты, как ни странно, помогают решать реальные проблемы. AG>ИМХО с ними — программировать на С++ проще (и намного проще), нежели без них.
Это если применять навороты разумно и к месту.
Стиль же "укус Александреску" это когда за наворотами не видно кода.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, lpd, Вы писали: AG>... lpd>>Шаблоны, перегрузка операторов были в C++98, лямбды — мелочь. У вас что, древний C++? Сейчас 2019, почему мало умных указателей и move-семантика не на каждом шагу?? AG>+100500 AG>Лично я широко применяю в своих проектах как семантику перемещеный, так и смарт-поинтеры. AG>На крайняк — для анализа ситуаций с утечкой памяти — есть достаточно простые инструменты: AG>http://valgrind.org AG>https://archive.codeplex.com/?p=vld
Это все годится, если утечка уже возпроизводится. Лучше когда она невозможна в принципе.
lpd>>Если серьезно, то претензии к C++ (у меня лично) не к перегрузке операторов, которая там давно, а к более новым фичам: move-семантике, указателям<> вместо сборки мусора. AG> AG>Ну это — как сказать!
AG>Так, если бы сделали сборку мусора, то это бы привело к возникновению недетерминированных задержек при исполнении кода AG>И если бухгалтеру некритично — за 5 секунд посчитает отчёт или за 6 секунд, то для системы перехвата ракет — это уже катастрофа...
Сборка мусора может быть детерменированная (10 мс). Плата за это — 20-40 процентов производительности и 100 — 300 процентов памяти. Железо нынче не дорогое.
Я не против с++, но стоимость разработки и поддержки на нем очень велика. Его надо выбирать в очень редких случаях. В 90 (или 95-99) процентах есть вариант гораздо лучше.
Здравствуйте, AlexGin, Вы писали:
lpd>>Шаблоны, перегрузка операторов были в C++98, лямбды — мелочь. У вас что, древний C++? Сейчас 2019, почему мало умных указателей и move-семантика не на каждом шагу?? AG>+100500 AG>Лично я широко применяю в своих проектах как семантику перемещеный, так и смарт-поинтеры.
Можно порадоваться за вас, но могли бы вы пояснить, в чем был смысл вашего комментария?
CC>Стиль же "укус Александреску" это когда за наворотами не видно кода.
Стиль Александреску — это параметризация поведения шаблонными типами, которые и реализуют поведение. Пример — аллокаторы из стандартной библиотеки, делетеры и std::less<>. По поводу Александреску развели хайп на ровном месте по причине замудренности его книги. Но там основные сложности связаны с отсутствием вариадик темплейтов в те времена и необходимостью поддержки тогдашнего MSVS и другого легаси, в котором много было либо недоделано либо сделано через альтернативную реальность (ну и тем, что шаблоны — это фукнциональщина с паттерн матчингом и иммутабельностью, что непривычно для императивщиков).
IMHO, упоминание стиля Александреску и его "укусов" — признак пустой болтовни. Потому что в современном C++ его стиль прост и утилитарен для любого прагматика. Если сейчас кто-то не сможет прочитать его книгу (понимая альтернативное мышление фукнциональщины), то он просто профнепригоден. Кнжка Александреску — это примитивизм уровня студента-третьекура, как и его стиль.
P.S. На чистом C тоже можно понаписать такого. Даже конкурсы проводят. Шаблоны C++ только добавляют возможностей для велосипедостроительства и усложнения кода на ровном месте, но это не связано с Александреску. Степень его вменяемости легко понять по последнему докладу на CppCon, где он объясняет, почему алгоритмическую сложность алгоритмов нужно измерять не только в терминах количество операций сравнения и пересылки, но и расстояния между этими элементами, ибо кэш процессора, предсказатель переходов и другие особенности оборудования порвут теорию если не в разы, то на десятки %. Наконец-то хоть кто-то всерьез заявил, что до усрачки оптимизированный алгоритм в реальности может оказаться медленнее "пузырька".
P.P.S. Приношу извинения, если для кого-то это был просто "повод поболтать", а тут я со своим цинизмом и прагматизмом.
Здравствуйте, уважаемый so5team, Вы писали:
AG>>Лично я широко применяю в своих проектах как семантику перемещеный, так и смарт-поинтеры.
S>Можно порадоваться за вас, но могли бы вы пояснить, в чем был смысл вашего комментария?
Здесь уважаемые товарищи (и коллеги по цеху),вещают о том, что C++ не контролирует утечек памяти.
Что на C++ за освобождение памати ответственен разработчик.
С одной стороны — они бесспорно правы.
С другой — есть в современном C++ возможности, правда обеспечиваемые разработчиком, позволяющие утечек памяти избежать.
В то же время, если C++ станет очередным языком с классической системой сборки мусора (GC),
я буду иметь в приложении участки кода, с недетерминированным временем выполнения (что характерно для языков с GC).
$>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>А десктопные приложения
$>А кому нужны десктопные приложения? Клепайте веб приложения, продавайте подписку. Если бы тебе банк предлагал чтоб зайти в кабинет, установить десктопное приложение да ещё с зависимостями да ещё работающее на 1.5 версии венды, как далеко бы ты отправил путешествовать тот банк? Ечли в твоей предметной области ещё никто не додумался сделать веб- то ведь, когда додумается, твоя компания уйдёт из бизнеса.
Оказывается, некоторым настолько нужны, что они даже праздник устроили после того, как переписали свои веб-приложения на C++
Здравствуйте, PM, Вы писали:
PM>$>А кому нужны десктопные приложения? Клепайте веб приложения, продавайте подписку. Если бы тебе банк предлагал чтоб зайти в кабинет, установить десктопное приложение да ещё с зависимостями да ещё работающее на 1.5 версии венды, как далеко бы ты отправил путешествовать тот банк? Ечли в твоей предметной области ещё никто не додумался сделать веб- то ведь, когда додумается, твоя компания уйдёт из бизнеса.
PM>Оказывается, некоторым настолько нужны, что они даже праздник устроили после того, как переписали свои веб-приложения на C++ PM>
