В твоём посте одна сплошная уверенность в том, что ты - прав, а он - неправ. Ты, значит весь такой молодой, умный, модный, а он - такой весь дурак, пишет костыли, не юзает модные вещи... Странно, что тимлид - он, а нет, тебя это не смущает? Ведь ситуация до боли стандартная. У меня тоже раз в полгода попадается джуниор, который вместо выполнения порученной ему задачи, начинает тянуть в проект всякое модное дерьмо, мотивируя это тем, что «мы в 2017 года делаем так», «все юзают же реакт/ангуляр/монгу/херонгу/докер/херокер/что угодно еще», лишь бы это было современно, стильно и молодёжно". А все потому, что ума не хватает думать не только о том, какую бы херню втащить в проект, а еще о том, что кто-то должен это поддерживать, обновлять после криворуких школьников-мейнтейнеров, отвечать за стабильную и надежную работу ПО...

Ума должно хватать понимать, что не надо программировать в стиле «а вот смотрите, как можно!» или «а вот смотрите, как еще можно сделать!». Руководитель должен прежде всего делать так, чтобы ПО работало и выполняло свою работу, а не следить, чтобы не дай бог там был немодный на ЛОРе язык.

Да, там выше про то что буст можно сконфигурить под себя написали. Если действительно всё так как обещают, то время увеличится не сильно.

Я не говорю, что я умнее моего тимлида. У него здоровый опыт разработки, у меня в разы меньше, не спорю. На пост тимлида на данных момент я не претендую и не могу претендовать ввиду моей низкой квалификации. Но это не отменяет того факта, что в каких-то вопросах он может ошибаться, а я могу быть прав.

Ещё раз: что плохого в том, что вместо написания своих наколенных поделок использовать уже написанное и проверенное временем решение? Вы можете это мне обьяснить? Я не пытаюсь притащить в проект какие-то хипстерские вещи. Boost - это довольно серьезная либа, которая активно мейнтенится. Много вещей в стандарт тянется именно с буста. И от этого будущий переезд бустовая реализация -> стандартная реализация довольно безболезненный: меняем namespaces и делаем некоторые переименования. Например, тот же filesystem емнип перекочевал в стандарт практически без изменений.

Насчёт выполняло работу. Вы, безусловно, правы. Но я внесу некоторую ясность - выполняло работу это значит, чтобы работало правильно. Текущее решение: это свои примитивные костыли, в которых довольно много ошибок(по крайней мере было, так как уже чего пофикшено). То, что я предлагаю: использовать решение, проверенное временем на других проектах и лишённое различных детских болезней. Стоит один раз интегрировать и пользуйся дальше на здоровье. Никто не будет апдейтить буст каждую версию - в этом нет никакого смысла.

Где я неправ?

WinAPI, обёрнутое ifdef для Вин платформы. И потихоньку начинает появляться своя какая-то реализаиция для linux. Только, к сожалению, не двух функций.

значит, появляется кроссплатформа. и вот уже на основании этого вам нужно искать нормальную кроссплатформенную библиотеку, а не городить свои костыли. потому что у каждого юзера будет своя архитектура, своя система, свои тараканы. и чем дальше - тем сложнее будет поддержка велосипедов в таком состоянии, чтобы у всех всё работало.

тут уже вопрос даже не в оптимальности, а вообще в возможности поддерживать и развивать такой код дальше.

а я расскажу, как это выглядит и будет выглядеть дальше: написали кое-как - и работает. Бага всплыла - отдебажили, заткнули фиксом, и дальше живём до следующей баги.

Велосипедисты вы там? Или это своя железка?

не, у нас нет своего железа.

почему до сих пор не примеров плохого кода тимлида и того, чем вы предлагаете заменить?

Каждое решение вопроса «велосипедить» или «тащить внешнюю зависимость» должно быть индивидуально и зависеть от задачи.

Если можно быстро что-то навелосипедить и не тащить лишнюю зависимость, то лучше велосипедить, просто потому что поддерживать свой код и вносить в него изменения проще, чем чужой.

Если же велосипед сам начинает напоминать буст, только кривой и бажный, то конечно стоит подумать о новой зависимости.

Важен баланс.

хотя бы просто потому, что у же описал, как оно устроено. Выкидывать вот так вот код, который в коммерческом проекте... При всём моём уважении, мне за это могут по шапке надавать неплохо. А врать про устройство кода мне всё равно не имеет смысла.

Я предлагаю заменить самописные костылики на WinAPI на Boost.Filesystem.

Если бы там была одна-две функции, я бы даже рот не открывал и спокойно использовал то, что есть.

Я же вижу, что функционал расширяется, и всё больше и больше напоминает несчастную корявую копию Boost. Filesystem.

Я предлагаю заменить самописные костылики на WinAPI на Boost.Filesystem.

Кинь ему ссылку - http://en.cppreference.com/w/cpp/filesystem.

Поверьте, уже кидал и не раз :)

Тогда просто забей, более разумного довода ты не найдешь.

вы же не о бизнеслогике ведете речь, а о файловых операциях. неужели там что-то эдакое? к тому же вы говорите что правите коммиты тимлида, то есть явно намекаете на ущербность его кода. где пример исправлений, чтоб все поняли наконец что тимлид уже не тот?

а по шапке за поднятие данной темы вам значит не надают?

в маздай стандарты С++ довозят на оленях

в gcc, тогда, на черепахах :)

Я не нарушаю NDA, не рассказывая тонкостей реализации и не сливаю исходники. А просто прошу совета на довольно общую тему.

Ничего эдакого там нет. Ну как бы я не намекаю, а открыто говорю, что в этих велосипедах были (есть) ошибки. По мере возможностей они исправляются (в основном благодаря cppcheck && pvs-studio).

Я никак не могу, зачем он это делает (NIH?), и стараюсь убедить его, что мол есть же Boost.Filesystem, юзай его. Ответ таков: Boost тяжёлый, тянуть не хочется да и вообще лень.

Boost тут ни при чём, я такую фигню слышал постоянно - нам не нужно X оно тяжёлое и оверкилл. В итоге всегда рождался монстр ничуть не менее тяжёлый и гораздо более костыльный. НО! Деньюжки-то осваиваются, работа кипит... Так что не учи тимлида щи варить.

Стандартные библиотеки хороши но не всегда, есть куча мест где они нужны - и столькоже где они не нужны. У нас обратная практика, новый проект стартует на стандартных библиотеках (тотже boost, openssl, jrtp, QT/GTK и тд) - после того как проект устаканился (по функциональности) и начал жить полноценной жизнью - начинаем потихоньку выпиливать либы и заменять своими велосипедами (не все конечно а по необходимости).

Все правильно твой тимлид делает.

boost — это свалка различного качества библиотек. Конкретно взятый filesystem — помойка из помоек, где единственной полезной вещью является конкатенация путей.

Свое юзают по двум причинам:

1. «так исторически сложилось»: сначала нужно было делать что-то на одной платформе, причем в разных местах приложения, так что во избежании копипаста написали пару функций/классов. Для новой платформы было воткнуть пару ifdef-ов вообще не проблема. Кстати замечено, что бусты, qt и прочее говно больше любят как раз новички, которые абсолютно не разбираются в платформоспецифичных API.
2. «зачем что-то менять»: «так исторически сложилось» и теперь все работает — зачем что-то менять? Тем более, что свое говно решает свои проблемы, а «кроссплатформенные API» мало где хорошо себя показывают за пределами hello world-ов.

он пишет свои костыли, потому что ему так удобнее. обычно тимлид пишет 100500 строк кода, и он основа небольших проектов. И если ему так удобнее значит так и должно быть. Будешь тимлидом будешь тянуть бусты, а студни рядом будут постить в свои пейсбуки - почему тимлид такой отсталый и тянет какой-то потный буст, хотя все нормальные пацаны используют ххх.

я как главный разраб, тоже много чего модного отметаю от своих проектов ибо мне так удобнее.

pvs-studio - вот оно что Семёныч, а я то думал будет интересно

С помощью статического анализа пофиксили довольно много багов. Так что не вижу в этом ничего плохого

не не, ты продолжай. тут вчера просто драма была, а я сцуко выпил и играю в конспиролога.

Раз такой тимлид - с большой вероятностью он написал ещё несколько кусков буста. Если так, то надо собрать эти велосипеды в кучу и показать, как элегантно всё это заменяется одним де-факто стандартным фреймворком. Нормальный тимлид порадуется уменьшению кодовой базы.

Пока что мы слышали о ситуации со слов джуна.

Проще систему на uclibc или dietlibc перевести, дописав туда до кучи необходимую функциональность (и НЕ дописав то, из-за чего glibc такое bloatware)

К чему полумеры? musl!

2 ТС. У вас CI есть? Тесты? Система сборки и тестирования максимально автоматизирована? Проекты и подпроекты поделены на отдельные репозитории, которые красиво связаны друг с другом без дублирования-копипасты исходников между репами?

Обычно, когда чего-то боятся втащить в проект - это следствие безобразиия в организации проекта. CI и автоматические тесты неотъемлемая часть проекта, любого. Без этого у ответственных за проект образуется множество комплексов, неврозы и *.sln файлы.

А неприятие буста - это следствие. Такое же, как неприятие c++14, или нового компилятора.

Как убедить тимлида притянуть в проект Boost

Похить его ребёнка.

часть функционала написана на C#

они (ваши дотнет разрабы) фреймворк тоже переписывают, и ORM руками пилят? Если нет - как-то не последовательно, срочно писать самим весь System.*!

Откуда такая может быть ненависть к Boost?

Ну буст правда тяжелый, очень жирное header-only у него. На не ssd довольно сильно может увеличить время компиляции.

благодаря cppcheck && pvs-studio

Всё встало на свои места. Один спамер отлетел, теперь второй с рекламой этого вареза подтянулся.

очень малая часть функционала написана на C#.

Почему бы тогда не использовать все эти вещи из .net? Проект я так понимаю все равно clr?

Ойвей, если бы все было так прозаично, как Вы пишите. У меня в каждой второй вакансии по городу требования на знания или опыт работы с этими всеми «модными хернями».

перестань плакать и открой для себя precompiled headers.

и да: «долго» - это несколько часов сборки на билд-сервере. а остальное - мелочи жизни.

велосипед сам начинает напоминать буст, только кривой и бажный

вот буст не видел, он точно прямой и весь такой безбажный?

проект организован ужасно. CI нет, тесты на этом проекте поломаны (занимаюсь восстановлением). Красивых связей нет.

лол, я сказал всего лишь, что юзал. Никакой рекламы.

C# часть тоже на мне

ну не сказать, что он безбажный. Всегда можете открыть их трекер и посмотреть, что там висит.

Ну и сорцы можете выкачать и глянуть сами.

сорцы можете выкачать и глянуть сами.

А потом поправить сами...

Ну, значит ты сначала скажи тимлиду, что время съэкономленное на написание велосипедов, нужно потратить на организацию проекта.

Потом, если твой тимлид непробиваем, нужно донести это до начальника твоего начальника, начиная со слов: «Я тут замерил примерное время развертывания рабочего места разработчика с нуля - оно равно 1.5 месяца. Это только что бы проект подгрузился в IDE, собирать еще не пробовал. При этом требуются сакральные устные знания Ивана Иваныча, который (получил права на мотоцикл | женился | заболел неизличимой болезнью и скоро умрет).» Дальше, начальник начальника берет разговор в свои руки и ведет его в конструктивное русло. Либо, значит, маломальски эффективная работа отдела разработки нужна только тебе в этой фирме и остается смириться и получать зарплату либо увольняться.

Не берут Qt потому что дорого

что???

я с лицензированием Qt не слишком знаком

видно :)

но насколько я знаю, для коммерческой разработки нужно покупать

не знаешь :)

Бесплатно юзать можно, только если линковать не статически

нет, но разве дин линк это проблема? а C# же ты не пытаешься статически юзать

Всё относительно. (c)

А тимлид не лезет в C#, да?

На счет лицензии Qt ты совершенно не прав, но вот про Boost - твои мысли здравые, если хочешь заменить наколенные велосипеды на проверенные решения. Тему не читал, насколько сложный у вас код, который хочется заменить на буст?

У кого-то триггер сработал.

Есть две основные причины не использовать буст:

• Непортабельные (более чем под n платформ) велосипеды обычно эффективнее (вопрос надо ли оно ну и в радиусе кривизны)
• Инфраструктура - тянуть буст это допиливать CI, пакеты, инструкции пользователя и т.д.

В общем, если нет цели сделать mvp в кратчайшие сроки, и оплачивают написание велосипедов, то есть не нулевой шанс что он всё делает правильно.

Долго - это даже лишние пару минут на рабочей машине.