Поддерживаю, делать настолько похожие ключевые слова — не лучшая идея.
Я уж молчу про то, как легко слово «констекспр» произносится вслух -_-' Но говорить вслух «констекспр!» будет вообще невозможно.
«Констекспрбанг»? «Констэкспр экскламейшн марк»? «Констэкспр восклицательный знак»?
Я про элемент uvch264src узнал буквально вчера вот из этой статьи и просто попробовал убрать второй поток. И он просто пропал, без всяких проблем. Видоискателем я его вслед за этой статьей и называю (ну и пад называется vfsrc — viewfinder, видимо).
Я, конечно, не уверен, что камера его вообще не отсылает при этом (и сходу не знаю даже, как это проверить, перехватывать usb-траффик разве что?), но выводиться он никуда не выводится.
Это вы пишете, как в ROS взять видео с usb-камеры. Статья про то, как взять прямо с камеры видео, сжатое в h264, и переслать на другой комп по сети. И к ROS'у видео нужно прикручивать уже там, когда оно по сети принялось.
И usb_cam, насколько я знаю, может брать с камеры только сырое видео или mjpeg, а h264 — не умеет. Хотя это даже и не важно, ибо см. выше.
Раз уж я в этом поучаствовал, то добавлю от себя:
1) Почему-то конкретно с этой камерой просто взять v4l2src прокатывало только локально. Если передавать видео через udpsink (даже на локалхост), на приемнике получался один зеленый кадр — и все.
2) Вопреки написанному в статье про uvch264src:
Панель видоискателя может быть подключена к фейклинку, если она не нужна, но я не думаю, что ее можно отключить. По крайней мере, это впечатление, что я читаю оригинальный пост в блоге KaKaRoTo.
Отключилась она легко, я просто убрал из пайплайна источник src.vfsrc и queue.
Собственно, этот вариант и приведен в конце статьи, он заработал по сети и «видоискатель» не выводит.
Я про House of Leaves узнал из xkcd и совершенно на автомате закинул на читалку.
Очень было странно временами натыкаться целые моря бредового текста, буквы, пробелы, все в кучу.
Только когда дочитал, начал гуглить, увидел фотографии страниц и расстроился. Теперь вот даже не знаю, ту ли книгу я читал?
Это резонно, конечно, но как-то я не был готов к тому, что diff и date будут работать не так, как обычно. Подробностей уже не помню, к сожалению, помню только, как я страдал -_-
Ваш вариант по-прежнему не отвечает на вопрос, что делать, если пользователю нужно не заранее определенное в enum'е значение, а свое. Умножать на базовое значение, видимо?
Ладно, спор явно пошел о вкусах, но лично мне вызов
myCycle cycle(MS_01*2*60*60*1000, true);
кажется менее понятным, чем
myCycle cycle( 2_h, 0_min, 0_sec, 0_msec, true);
Ну и переопределять операторы для enum, так чтобы выходить за пределы этого самого enum'a по-моему фе.
Окей, я бы в любом случае переделал бы API. Если есть std::chrono — то пусть функции принимают std::chrono::milliseconds, если chrono нет, то просто сделать несколько функций (или перегрузок), чтобы они принимали только миллисекунды, секунды и миллисекунды, минуты и т.д.
Enum, на мой взгляд, должны использоваться, когда все допустимые значения можно заранее перечислить — это ведь перечислимый тип. Тут же константами сделаны только какие-то заранее определенные величины, которые просто автору понравились, но допустимые значения ими не ограничиваются.
И если пользователю захочется задать интервал например, в 4 минуты (для которых константы нет), то ему придется руками писать 4*60*1000, что, на мой взгляд, выглядит плохо и непонятно.
Которые, если немножко подумать, вообще ни к селу ни к городу не нужны ни в каком виде. Ардуино уже поддерживает С++11, в котором есть std::chrono и стандартные литералы для единиц времени.
Enum, на мой взгляд, тут все равно не просится, ведь никакого перечисления тут нет, это числа, количества миллисекунд. Не будь неявного приведения типа, этот enum пришлось бы каждый раз кастовать к числу (потому что функция, куда эти константы суют, может принимать любое количество миллисекунд, а не только заранее перечисленные здесь).
Насколько мне известно, если вам нужна просто константа, то у define только одно преимущество — его существование можно проверить через #ifdef. Ну и передефайнить, если вдруг захотелось.
Но тут-то зачем?
Позволю себе выразить сомнение в том, что в 2018 году в коде на С++ все еще допустимо использовать #define для определения простых констант, да еще в заголовочном файле, вместо namespace и const.
Ну и вместо стражей включения стоит использовать #pragma once, учитывая, что компилятор ее поддерживает, а вопрос переносимости вообще не стоит.
Как вам сказать… Если это у человека хобби такое, и ему просто нравится этим заниматься, то на здоровье. Если к этому принуждают некие обстоятельства непреодолимой силы — политика компании, легаси, пистолет у виска, то тут тоже все понятно.
Но если AVR (и особенно ассемблер) тащат в продакшен просто по привычке, то таки да, нахожу. Я уже достаточно страдал из-за людей, которые пишут километровые ассемблерные программы без единого комментария и потом сами в них ничего найти не могут; используют процы без отладочного разъема, которые каждый раз выпаивать нужно, чтобы прошить; добровольно используют архитектуры, для которых есть только компилятор С89, да еще не полностью поддерживающий стандарт и тому подобное.
Я считаю, что это очень плохо и стараюсь подобное искоренять. Я не спорю, что есть области, в которых нужно программировать на ассемблере и упихивать код в сотни байт, а ножек у проца может быть не больше восьми, но они достаточно редки.
Да, я знаю; примерно раз в полгода открываю этот тред.
Грустно, что очень многих вещей, которые уже есть в С++ (или в D), ждать еще очень очень долго. Многих, подозреваю, вообще можно не дождаться, типа static if, поскольку их изначально не закладывали.
Ле вздох.
В С++ 20 может быть приедут шаблонные wide_integers произвольной длины. Очень жаль, что в Rust все еще не приехали дженерики с аргументами-не типами, и аналогичную штуку не сделать :(
Я уж молчу про то, как легко слово «констекспр» произносится вслух -_-' Но говорить вслух «констекспр!» будет вообще невозможно.
«Констекспрбанг»? «Констэкспр экскламейшн марк»? «Констэкспр восклицательный знак»?
Гуглить тоже очень тяжело будет.
Я, конечно, не уверен, что камера его вообще не отсылает при этом (и сходу не знаю даже, как это проверить, перехватывать usb-траффик разве что?), но выводиться он никуда не выводится.
И usb_cam, насколько я знаю, может брать с камеры только сырое видео или mjpeg, а h264 — не умеет. Хотя это даже и не важно, ибо см. выше.
1) Почему-то конкретно с этой камерой просто взять v4l2src прокатывало только локально. Если передавать видео через udpsink (даже на локалхост), на приемнике получался один зеленый кадр — и все.
2) Вопреки написанному в статье про uvch264src:
Отключилась она легко, я просто убрал из пайплайна источник src.vfsrc и queue.
Собственно, этот вариант и приведен в конце статьи, он заработал по сети и «видоискатель» не выводит.
Да, я с тех пор уже понял, что let a: int лучше, синтаксис указателя на функцию получается на порядок чище.
Очень было странно временами натыкаться целые моря бредового текста, буквы, пробелы, все в кучу.
Только когда дочитал, начал гуглить, увидел фотографии страниц и расстроился. Теперь вот даже не знаю, ту ли книгу я читал?
Ладно, спор явно пошел о вкусах, но лично мне вызов кажется менее понятным, чем
Ну и переопределять операторы для enum, так чтобы выходить за пределы этого самого enum'a по-моему фе.
Enum, на мой взгляд, должны использоваться, когда все допустимые значения можно заранее перечислить — это ведь перечислимый тип. Тут же константами сделаны только какие-то заранее определенные величины, которые просто автору понравились, но допустимые значения ими не ограничиваются.
И если пользователю захочется задать интервал например, в 4 минуты (для которых константы нет), то ему придется руками писать 4*60*1000, что, на мой взгляд, выглядит плохо и непонятно.
Которые, если немножко подумать, вообще ни к селу ни к городу не нужны ни в каком виде. Ардуино уже поддерживает С++11, в котором есть std::chrono и стандартные литералы для единиц времени.
Enum, на мой взгляд, тут все равно не просится, ведь никакого перечисления тут нет, это числа, количества миллисекунд. Не будь неявного приведения типа, этот enum пришлось бы каждый раз кастовать к числу (потому что функция, куда эти константы суют, может принимать любое количество миллисекунд, а не только заранее перечисленные здесь).
Но тут-то зачем?
Ну и вместо стражей включения стоит использовать #pragma once, учитывая, что компилятор ее поддерживает, а вопрос переносимости вообще не стоит.
Но если AVR (и особенно ассемблер) тащат в продакшен просто по привычке, то таки да, нахожу. Я уже достаточно страдал из-за людей, которые пишут километровые ассемблерные программы без единого комментария и потом сами в них ничего найти не могут; используют процы без отладочного разъема, которые каждый раз выпаивать нужно, чтобы прошить; добровольно используют архитектуры, для которых есть только компилятор С89, да еще не полностью поддерживающий стандарт и тому подобное.
Я считаю, что это очень плохо и стараюсь подобное искоренять. Я не спорю, что есть области, в которых нужно программировать на ассемблере и упихивать код в сотни байт, а ножек у проца может быть не больше восьми, но они достаточно редки.
Как-то так.
Грустно, что очень многих вещей, которые уже есть в С++ (или в D), ждать еще очень очень долго. Многих, подозреваю, вообще можно не дождаться, типа static if, поскольку их изначально не закладывали.
Ле вздох.