Рабочее, плюсовое, малозначимое, но яркое

[dememax]

void MediaLookupTable::generateNewName(char* mediumName,
				       unsigned /*maxLen*/) {
  // We should really use snprintf() here, but not all systems have it
  sprintf(mediumName, "liveMedia%d", fNameGenerator++);
}

Comments

[alll]

Вот так и рушатся цивилизации. ;)

Re: Вот так и рушатся цивилизац

[dememax]

Да, "всего лишь видеопоток с сервака - хотел посмотреть..." ;-)

Re: Вот так и рушатся цивилизац

[itman.livejournal.com]

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

Re: Вот так и рушатся цивилизац

[dememax]

Ой, Лёня, не суди их строго, задним умом - мы все гении. :-)
Библиотечка - старая, на большом количестве платформ работает, куча известного софта на неё завязана, ...
Это такой, знаешь, стиль, типа компонента Scintilla, когда от плюсов по минимуму берут.

Там есть другие "замечательные" приёмы, которые меня вгоняют в грусть, типа:

• header

    Boolean& deleteWhenUnreferenced() { return fDeleteWhenUnreferenced; }

• source

    fServerMediaSessions->Remove(serverMediaSession->streamName());
    if (serverMediaSession->referenceCount() == 0) {
      Medium::close(serverMediaSession);
    } else {
      serverMediaSession->deleteWhenUnreferenced() = True;
    }

Как-то для операторов, особенно через индексы my_map[] = value; - присвоение вполне нормально, но когда ты вызываешь функцию и ей присваиваешь значение, то это выглядит для меня не совсем гладко. Там ещё кое-что есть, но это уже так, ...

Re: Вот так и рушатся цивилизац

[(Anonymous)]

>Ой, Лёня, не суди их строго, задним умом - мы все гении. :-)

Это правда, Си++, кстати, у людей вызывает большую аллергию, отсюда все эти printf и пр в исходниках. Если бы язык развивался бы с нуля, не было всего этого. Но у меня нет для вас паралелльной вселенной. Скорее всего, эти экзерсисы будут медленно и мучительно умирать вместе с кодом, который, скажем, в 2030-ом году не будет собираться, если в нем есть printf, sprintf, и пр... Предвижу, правда, кудесников, которые напишут библиотечки с printf, sprintf...

[vaddimka.livejournal.com]

Как-то странно видеть классы и спринтф в одном коде )

[vaddimka.livejournal.com]

а, понял, прочитал комменты

Ну суть понятна, но

[fatoff.livejournal.com]

but not all systems have it

Not all compilers? How old that compiler in the system is?

ffmpeg & live555

[dememax]

Слушай, а ты же - копался в ffmpeg.
А в этой библиотеке - не приходилось?
Вроде, из той же области...

Re: Ну суть понятна, но

[dememax]

В файлах, выдержки из которых я тут уже приводил, я вижу

// Copyright (c) 1996-2016 Live Networks, Inc.  All rights reserved.

Можно ещё заглянуть сюда для прочей информации: http://live555.com/liveMedia/
Например, там сказано:

This code forms a set of C++ libraries for multimedia streaming, using open standard protocols (RTP/RTCP, RTSP, SIP). These libraries - which can be compiled for Unix (including Linux and Mac OS X), Windows, and QNX (and other POSIX-compliant systems) - can be used to build streaming applications.

Мне доводилось в жизни работать только на FreeBSD, SunOS, Windows и Linux. Вполне допускаю, что в какой-нибудь из даже этих есть проблемы с какими-нибудь вызовами до 2000-го года.

Re: ffmpeg & live555

[vaddimka.livejournal.com]

live555 не помню, в ффмпеге копался да

Re: Вот так и рушатся цивилизац

[dememax]

Аллергия и язык - не пересекаются, думаю. У меня аллергию вызывает некоторая конструкция (не знаю, следили ли вы за моими публикациями), а у других - нет: http://mpd.livejournal.com/88636.html

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

А так, да, в реальной жизни видел конструкции вида

if (s.compare("abc") == 0)

для s - типа std::string. И ведь найдутся люди, для которых это - хорошо, см. мою ссылку.

Re: Ну суть понятна, но

[fatoff.livejournal.com]

В Windows sprintf точно не из системы, а из конкретного сишного рантайма, который либо динамически, либо статически линкован с исполняемым модулем.

В Linux, как понимаю, раз можно хостить более одного компилятора, тоже не часть системы?

Re: ffmpeg & live555

[dememax]

ffmpeg имеет свою кодовую базу для реализации RTxP.
Например, GStreamer через набор gst-plugins-good использует именно ffmpeg, а уж сколько тех, кто сидит на GStreamer - я молчу.

С другой стороны, mplayer и vlc для реализации потокового видео - используют именно live555.

Кто ещё из распространённых существует, кто реализует RTSP/RTP/RTCP, кого можно использовать на халяву?

Или ты сейчас - в другой области работаешь?

Re: ffmpeg & live555

[vaddimka.livejournal.com]

Я примерно полтора года как напрямую видео не занимаюсь, приходилось на броадкастиг стандарты смотреть, но не более.
С RTP не работал, он мне не нравится, реализовывал свои решения для коррекции потерь при передаче и т.п.

Re: Ну суть понятна, но

[dememax]

В Линукс - это часть glibc: https://github.com/lattera/glibc/blame/master/stdio-common/sprintf.c
Либо той реализации стандартной библиотеки Си, на которой сидит система, это не всегда glibc, иногда это даже смесь нескольких, т.к. на старте системы на динамическую линковку полагаться - нельзя, компилируются статически с какой-нибудь маленькой реализацией си-библиотеки.

[great-mahatma.livejournal.com]

Абсолютно нормально, всегда так делаю. Не пользоваться же этими убогими istream, ostream и не менее уродливыми << и >>. Руки бы оторвал не только тому, кто использует исключительно потоки, но и тому, кому в голову пришла безумно шизофреническая мысль вообще придумать подобное уродство.

[vaddimka.livejournal.com]

Я очень надеюсь что вы при этом используете snprintf :)

[great-mahatma.livejournal.com]

Ну это естественно и это само собой, snprintf тут наше всё.

И возвращаясь к потокам. Программа (если это можно назвать программой) делает две абсолютно одинаковые вещи. Первая через стандартный И НАШЕ ВСЁ printf, а вторая через потоки, по всем канонам C++:

-+-
#include
#include
#include

using namespace std;

int main()
{
int i = 0x1234abcd;
printf("0x%016X (%d)\n", i, i);

cout << "0x"
<< setfill('0')
<< setw(16)
<< hex
<< uppercase
<< i
<< " ("
<< dec
<< i
<< ")"
<< endl;
return 0;
}
-+-

Внимание, вопрос! Какой вариант предпочтёт нормальный и адекватный человек? А какой вариант предпочтёт больной C++ человек с ярко выраженным фимозом мозга?

Сколько я не видел учебников по C++ (начиная с самого Страуструпа, да) складывается впечатление что их пишут/писали как раз шизофреники, навязчиво навязывая всем вновь обращённым неофитам пользоваться этим << и >> уродством.

[great-mahatma.livejournal.com]

Как в этом ЖЖ делать так чтобы он даже не пытался форматировать то, что было отформатировано до него? Убрал, гад, все мои красивые отступы в предыдущем сообщении и выровнял всё по левому краю, придурок! Да ещё всё что было include поубивал вместе с угловыми скобками, все cstdio, iomanip и iostream, урод!

[vaddimka.livejournal.com]

для этого тег

    обычно работает

:)

[vaddimka.livejournal.com]

* тег pre :))

[vaddimka.livejournal.com]

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

я не считаю стримы вершиной удобства, файловые стримы вообще достаточно неудобны, но прямо так отказываться от них тоже смысла мало, в конце концов оператор << никто не монополизировал, любой волен сделать там конкатенацию или что еще в любом удобном для него виде, без использования STL например

поэтому snprintf/printf все-таки скорее пережиток прошлого, который если и использовать, то четко понимая почему и зачем. плюс, те же аргументы при переходе с 32-бит на 64 (size_t anyone?) нужно кастовать в определенный тип чтобы использовать в принтфах, неудобно и опять-таки дает возможность программисту ошибиться

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

[great-mahatma.livejournal.com]

А ну-ка проверю работает или нет...

#include 
#include 
#include 

using namespace std;

int main()
{
    int i = 0x1234abcd;
    printf("0x%016X (%d)\n", i, i);

    cout << "0x"
         << setfill('0')
         << setw(16)
         << hex
         << uppercase
         << i
         << " ("
         << dec
         << i
         << ")"
         << endl;
    return 0;
}

В режиме "ПРОСМОТР" сработало. Как запостится уж не знаю.

[great-mahatma.livejournal.com]

В своих проектах я один ;-) А когда я был не один (давно это было) на C++ вообще ничего не делалось, только pure C, только хардкор! Но стримы я считал и считаю порождением сатаны. Нужно и должно кастовать всё правильно, тогда и проблем не будет.

[madf.livejournal.com]

Прямо вот как у меня на работе :)
Особенно доставляют у нас template-free доморощенные контейнеры (у них у всех суффикс TF, шобы значимее!) в которых все через ж... То есть через void* и веру.

[madf.livejournal.com]

Кстати по поводу „not all systems have it“. У меня есть живой пример системы которая не умеет double гнать в std::ostream. И не такая она и старая — где-то из 2006-го года родом.

Re: Вот так и рушатся цивилизац

[great-mahatma.livejournal.com]

Я обычно делаю


if (!strcmp(s.c_str(), "abc")


когда s типа string, и не в моей библиотеке, и исходников нет чтобы string заменить на религиозно правильный char* Мне так нравится.

Re: только pure C, только Ñ Ð°Ñ€Ð´ÐºÐ¾Ñ€!

[dememax]

Нифига вы тут камментов накидали!

Да, до сих пор помню, как ты про конструкторы-деструкторы мне говорил в своё время, ...

Re: для большей части кода, логÐ�

[dememax]

Плюсую.

Re: template-free доморощенные контейне�

[dememax]

По-моему, если только из-за легаси можно это терпеть.

Re: не умеет double гнать в std::ostream

[dememax]

Жесть!!!

Re: только pure C, только Ñ Ð°Ñ€Ð´ÐºÐ¾Ñ€!

[great-mahatma.livejournal.com]

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

Re: template-free доморощенные контейне�

[madf.livejournal.com]

Именно что легаси. На них вся система завязана, а это почти гигабайт исходных кодов...

Re: template-free доморощенные контейне�

[dememax]

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

Но легаси в гигабайт исходников - это сильно, конечно! :-)

Re: Вот так и рушатся цивилизац

[dememax]

> когда s типа string, и не в моей библиотеке

А проще всего, когда всё же s - типа std::string, записать if (s == "abc") - это и короче, и понятнее. ;-)

А ещё std::string может содержать и нули. А когда строки очень длинные - то и размер помогает, который у std::string всегда с собой, а для char * - придётся strlen() таки вызвать каждый раз. ;-)

Re: Как в этом ЖЖ делать так чтоÐ

[dememax]

RTFM!
http://www.livejournal.com/support/faq/26.html

А уж если ты хочешь научиться пользоваться HTML, то главное - знать, что амперсе́нд ("&"), меньше ("<") и больше (">") - всегда в его коде воспринимаются специальным образом, их надо "экранировать": "&amp;", "&lt;" и "&gt;", соответственно.

Re: Ну суть понятна, но

[dememax]

Кстати, случайно наткнулся на новость, что gcc теперь поддерживает musl:

https://gcc.gnu.org/gcc-6/changes.html#linux

Стал смотреть, а с какими libc реализациями эта библиотека у меня в Gentoo стоит в списке, вот отрывок из описания пакета для абстрагирования реализации:

RDEPEND="!prefix? (
		elibc_glibc? ( sys-libs/glibc:2.2 )
		elibc_musl? ( sys-libs/musl )
		elibc_uclibc? ( || ( sys-libs/uclibc sys-libs/uclibc-ng ) )
		elibc_FreeBSD? ( sys-freebsd/freebsd-lib )
	)"

Т.е., кроме монстра glibc, я на своей системе могу, как минимум ещё две реализации выбрать: musl и uclibc. Правда, gcc ещё и Bionic C library поддерживает, но у меня - не Андрюша.
А вот, соответственно, реализация семейства *printf* из musl:

http://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c

а это из uClibc:

https://git.uclibc.org/uClibc/tree/libc/stdio/vsnprintf.c

В общем, с одной стороны - ещё тот зоопарк (по отношению к ВыньДОС и ОпиумОС), зато - выбор и свобода! ;-)
Короче, «присоединяйтесь, барон, незаметно присоединяйтесь»!!! :-D

Re: Ну суть понятна, но

[fatoff.livejournal.com]

Меня удивляет, как Линукс при всё разброде и шатании сохраняет логическую цельность. Типа, притащил в систему позиксную программу в исходном коде с зависимостями только от C runtime, компилируй, запуская.

Re: Ну суть понятна, но

[dememax]

Как раз из-за этого и сохраняет: кому-то надоел монстр-рантайм glibc - переключился на минималистическую альтернативу. Монстр заметил, что народ - сваливает, давай как-то реагировать.
Сейчас и с компиляторами под линухом стало так.

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