У них корпоративный блог, они имеют право вставлять рекламу в свои посты. Другое дело, что если она будет навязчивая, то там уже без разницы, качественный продукт или нет =)
сколько у нас в СКБ Контуре сложилось пар в рамках одной команды
Что-то мне не кажется, что заведение личных отношений на работе сколько-то хорошая идея. У вас есть примеры знакомых, которые завели служебный роман и были после этого счастливы?
По-моему, практика зачастую показывает обратное. Возможно у вас в фирме какой-то статистический выброс с исключениями)
К ностальгии Brutal Doom очень слабое отношение имеет. Это неплохая игра сама по себе, но лично у меня с тем самым думом она не ассоциируется. К слову, сегодняшние стримеры по думу редко обращают на него внимание. Очень много мелких деталей в геймдизайне, которые приближают игру скорее к современным играм.
Невероятно подробная и содержательная статья! Можно сказать, полноценное исследование на тему робомобилей! Побольше бы таких статей. Мог бы я оставить такой коммент.
А даже если повезет, и ты его найдешь и отладишь, то остается три варианта:
1. поддерживать свой форк с фиксом (такое себе удовольствие)
2. убедить разработчиков принять твой патч в апстрим
2.1. нет, мы в таких исправлениях не заинтересованы
2.2. в исправлениях заинтересованы, но качество кода не очень, допилите плиз
2.3. качество вроде ок, мы подумаем чтобы включить ваш патч когда-нибудь… не сейчас
3. разработчики таки примут этот патч (ура, радуга и бабочки).
Для того чтобы доводить до 3 пункта нужно быть а) упертым б) скилловым. в) шарить в проекте
К сожалению, это немногим удается. (у меня обычно ни одного из этих 3 пунктов нет, поэтому застреваю где-то на 2-х пунктах)
Это не легкое противоречие, это реальное противоречие
Да ладно?)
видимо весь бюджет съемки девиц ушел
Понимаю ваше возмущение, но вот так говорить лишнее, токсично как-то. Ворчание из серии «зачем проводить субботники с высадкой саженцев, лучше бы дороги ремонтировали» — уверен эти ресурсы независимы, и сколько девиц не снимай, меньше или больше статей от этого не становится.
Откажитесь от гендерных подарков, если того не подразумевает деятельность компании или праздник. Не стоит девочкам дарить, к примеру, ручки с розовыми хвостиками, а парням — их же в виде дула от танка.
И потом хоба! — календарь с полуобнаженными девушками. Легкое противоречие, не находите?
я бы не назвал include_directories устаревшей, она может быть использована в некоторых случаях: когда ты делаешь порт под какой-то тулчейн, в котором компилятор автоматически не знает про необходимые пути к стандартной библиотеке (ембедед gcc тулчейн, с несколькими возможным целями для разных девайсов — с хидрами вроде watchdog и тп).
В таком случае include_directories в файле тулчейна вполне может использоваться.
Прочитал Mastering Cmake. Из того что узнал для себя — все-таки можно делать плагины, Loadable Commands называются — уж как я не пробовал искать в гугле подобное поведение! Надо будет поковыряться, что с ними можно вытворить (к слову, даже когда я в багтрекере cmake спрашивал про подобную функциональность, мне ничего не сказали).
По поводу best practices — да вот хз. Есть некоторые хорошие советы, например разделы про портирование на новую платформу и кросскомпиляцию — они зачетные.
А в остальном… тема взаимодействия кастомных целей и команд вообще слабо раскрыта.
Ой-ей, я уже сам не рад, что ящик Пандоры с этим обсуждением открыл :D
Поддерживаю antoshkka хотя бы в том, что С++ компилятор может дать большую типобезопасность без увеличения размера выходного кода (даже с отключенными исключениями и RAII).
Может быть, вышеприведенные примеры и не убедят закоренелого сишника, но по крайней мере помогут человеку, который уже знаком с обоими языками, и думает на чем писать проект под embedded — на C или на урезанном C++.
Что-то не понял, приведенный фрагмент кода не нужно генерировать, это ж объявление которое вы можете использовать и снаружи, и внутри. В чем проблема?
Для enum можно использовать блок #ifdef INTERNAL_COMPILATION для определения значений для внутреннего пользования.
Но в любом случае, у меня ощущение какого-то глобального просчета в проектировании интерфейса, ибо через одну «дырку», которую видит пользователь не должны ходить и публичные значения, и какие-то секретные.
Для меня это звучит как примерно «если в функцию fopen в качестве mode передать „пыщь-пыщь“, то будет удалена вся файловая система».
В хорошем публичном интерфейсе не должно быть никаких скрытых параметров.
Но повторюсь, если волей «исторически сложилось» такие параметры нужны — они заключаются в ifdef блоки.
dllimport — да, через макрос. Если нужна поддержка win.
Баг — разновидность дефекта. Дефекты может вносить кто угодно. Изначально ветка комментов началась с того что баги вносят только разработчики. О чем спор?
Опечатка? В чем косяк проектирования?
Я про то, что обычно вполне конкретный человек получает
-макеты от дизайнера
-спеки аналитика
-DoD-ы от продакт оунера
и именно он воплощает ошибки в программе)
Ни разу не слышал чтобы просчеты на этапе постановки задачи кто-то называл «баги», это именно косяки, просчеты, ошибки проектирования, и тп.
«баг дизайна?» если у вас такой существует — то тогда я просто мягко с вами соглашусь и не буду дальше спорить, вопрос только в терминологии и не более.
Согласен с комментатором выше — наличие тулчейна на боевом сервере — запрещено многими политиками.
Я молчу уже про всякие ембедед промышленные штуки где может быть тупо 64 мб памяти на все про все, и линкер там тупо не запустится =)
Я внимательно следил за всей вашей веткой, решил все же высказаться.
Какие-то из этих объектов предназначены только для того, чтобы быть использованными внутри библиотеки (например для реализации межпотокового хранилища объектов). Какие-то же наоборот, должен использовать пользователь для того, чтобы передать какие-то параметры в функции и\или иметь контроль над внутренним состоянием библиотеки.
Именно эти внешние объекты (функции, макроопределения, константы, перечисления, структуры, объединения и прочие типы данных) должны быть во внешнем заголовочном файле, который будет подключать пользователь. Испокон веков кто-то создавал руками два файла, дублируя код и имея вероятность забыть исправить какой-то тип; кто-то (например как поступил я), написал свою систему сборки, в которой нужный для внешнего header файла объект помечается слово EXPORT и он автоматически оказывается в генерируемом файле. Судя по всему cmake обещает подобную функциональность. Как ее использовать?
Публичный интерфейс (хедер) в случае использования его снаружи библиотеки и изнутри должен полностью совпадать.
То что не используется снаружи — помещается в приватные хедеры (неэкспортируемые функции, макросы, и тд).
Внутри библиотеки мы используем и публичные и приватные хедеры.
Далее, если одна и та же функция должна быть скомпилирована по-разному в зависимости от ее использования (как в случае динамического экспорта в VC), то для таких нужд необходимые символы отмечаются макросом. обычно это что-то вроде LIBNAME_EXPORT или LIBNAME_API.
Определение этого макроса можно помещать как в этом же публичном хидере, ручками
// я про вот такие блоки
# ifdef utk_qt_BUILD
/* We are building this library */
# define UTK_QT_EXPORT __declspec(dllexport)
# else
/* We are using this library */
# define UTK_QT_EXPORT __declspec(dllimport)
# endif
# endif
, либо вынести в генерируемый export_some_lib.h, который создавать на основе имени библиотеки. cmake автоматически создаст нужный дефайн для того чтобы предварять имена символов, а так же дефайн, который нужно будет передавать в качестве определения при сборки цели библиотеки (cmake это тоже может сделать автоматически).
Не вижу ни одного реального кейса чтобы «копировать определения из одного хидера в другой».
Что-то мне не кажется, что заведение личных отношений на работе сколько-то хорошая идея. У вас есть примеры знакомых, которые завели служебный роман и были после этого счастливы?
По-моему, практика зачастую показывает обратное. Возможно у вас в фирме какой-то статистический выброс с исключениями)
1. поддерживать свой форк с фиксом (такое себе удовольствие)
2. убедить разработчиков принять твой патч в апстрим
2.1. нет, мы в таких исправлениях не заинтересованы
2.2. в исправлениях заинтересованы, но качество кода не очень, допилите плиз
2.3. качество вроде ок, мы подумаем чтобы включить ваш патч когда-нибудь… не сейчас
3. разработчики таки примут этот патч (ура, радуга и бабочки).
Для того чтобы доводить до 3 пункта нужно быть а) упертым б) скилловым. в) шарить в проекте
К сожалению, это немногим удается. (у меня обычно ни одного из этих 3 пунктов нет, поэтому застреваю где-то на 2-х пунктах)
Да ладно?)
Понимаю ваше возмущение, но вот так говорить лишнее, токсично как-то. Ворчание из серии «зачем проводить субботники с высадкой саженцев, лучше бы дороги ремонтировали» — уверен эти ресурсы независимы, и сколько девиц не снимай, меньше или больше статей от этого не становится.
И потом хоба! — календарь с полуобнаженными девушками. Легкое противоречие, не находите?
я бы не назвал include_directories устаревшей, она может быть использована в некоторых случаях: когда ты делаешь порт под какой-то тулчейн, в котором компилятор автоматически не знает про необходимые пути к стандартной библиотеке (ембедед gcc тулчейн, с несколькими возможным целями для разных девайсов — с хидрами вроде watchdog и тп).
В таком случае include_directories в файле тулчейна вполне может использоваться.
По поводу best practices — да вот хз. Есть некоторые хорошие советы, например разделы про портирование на новую платформу и кросскомпиляцию — они зачетные.
А в остальном… тема взаимодействия кастомных целей и команд вообще слабо раскрыта.
Поддерживаю antoshkka хотя бы в том, что С++ компилятор может дать большую типобезопасность без увеличения размера выходного кода (даже с отключенными исключениями и RAII).
Может быть, вышеприведенные примеры и не убедят закоренелого сишника, но по крайней мере помогут человеку, который уже знаком с обоими языками, и думает на чем писать проект под embedded — на C или на урезанном C++.
Что-то не понял, приведенный фрагмент кода не нужно генерировать, это ж объявление которое вы можете использовать и снаружи, и внутри. В чем проблема?
Для enum можно использовать блок #ifdef INTERNAL_COMPILATION для определения значений для внутреннего пользования.
Но в любом случае, у меня ощущение какого-то глобального просчета в проектировании интерфейса, ибо через одну «дырку», которую видит пользователь не должны ходить и публичные значения, и какие-то секретные.
Для меня это звучит как примерно «если в функцию fopen в качестве mode передать „пыщь-пыщь“, то будет удалена вся файловая система».
В хорошем публичном интерфейсе не должно быть никаких скрытых параметров.
Но повторюсь, если волей «исторически сложилось» такие параметры нужны — они заключаются в ifdef блоки.
dllimport — да, через макрос. Если нужна поддержка win.
Я про то, что обычно вполне конкретный человек получает
-макеты от дизайнера
-спеки аналитика
-DoD-ы от продакт оунера
и именно он воплощает ошибки в программе)
Ни разу не слышал чтобы просчеты на этапе постановки задачи кто-то называл «баги», это именно косяки, просчеты, ошибки проектирования, и тп.
«баг дизайна?» если у вас такой существует — то тогда я просто мягко с вами соглашусь и не буду дальше спорить, вопрос только в терминологии и не более.
Я молчу уже про всякие ембедед промышленные штуки где может быть тупо 64 мб памяти на все про все, и линкер там тупо не запустится =)
Публичный интерфейс (хедер) в случае использования его снаружи библиотеки и изнутри должен полностью совпадать.
То что не используется снаружи — помещается в приватные хедеры (неэкспортируемые функции, макросы, и тд).
Внутри библиотеки мы используем и публичные и приватные хедеры.
Далее, если одна и та же функция должна быть скомпилирована по-разному в зависимости от ее использования (как в случае динамического экспорта в VC), то для таких нужд необходимые символы отмечаются макросом. обычно это что-то вроде LIBNAME_EXPORT или LIBNAME_API.
Определение этого макроса можно помещать как в этом же публичном хидере, ручками
, либо вынести в генерируемый export_some_lib.h, который создавать на основе имени библиотеки. cmake автоматически создаст нужный дефайн для того чтобы предварять имена символов, а так же дефайн, который нужно будет передавать в качестве определения при сборки цели библиотеки (cmake это тоже может сделать автоматически).
Не вижу ни одного реального кейса чтобы «копировать определения из одного хидера в другой».
если нужно после установки придать другие имена хидерам, другое дело — это делается как в libc++
github.com/llvm-mirror/libcxx/blob/master/include/CMakeLists.txt
так и в Qt, например.
Само содержимое хедеров не меняется.
про публичный хидер на 3000 строк — ну и заинклюдить в нем все необходимые подфайлы, делов-то)