Вроде бы в C++17 хотят добавить возможность определить размеры управляющей структуры для STL структур — если сделают, то будет портабельный способ использовать пул для shared_ptr/list/map и т.д.
Для данного описанного случая (особенно если weak_ptr для этого типа объектов не нужен) может оказаться лучшим выходом переделка shared_ptr на intrusive_ptr.
Их это не волнует. Вообще любая блокировка — это подмена трафика, а уровень вмешательства — это уже детали.
Мобильные операторы еще хуже врезаются со своими «мобильными помощниками» и сливом информации об абоненте.
Тролль понял, что бабла срубить не удастся, и попросил суд прекратить дело, чтобы не тратить больше ресурсы на проигрышный процесс и чтобы не получить решение не в свою пользу. ЛК выиграла просто за счет того, что не поддалась, а приняла вызов и стала скрупулезно защищаться от каждой из нападок тролля. В результате по сути проиграли все — и тролль, потративший сколько-то денег на процесс, и ЛК, потратившая туеву кучу тех же денег на тот же процесс. Выиграл только суд и восточный округ Техаса.
Мне непонятно, почему статья говорит в качестве профита про «судебный прецедент», если решения суда по существу не было. Тот факт, что истец отказался от этого дела, вряд ли можно использовать в качестве весомого аргумента по другому делу.
> «доступна из других мест». Не доступна. Примеры приводил.
Мы ходим по кругу. Ну давайте еще раз. В вашем примере есть файл, скажем, 3rdparty/ffmpeg/libavutil/sha512.c. Хочется узнать, кто автор. Хм, откуда взяли этот файл? Может быть из (внезапно) ffmpeg? Идем на гитхаб, смотрим в репозиторий ffmpeg, находим там этот файл и смотрим его историю. Готово, задача решена.
The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn't post it until 1999, use 1998). You should add the proper year for each release; for example, “Copyright 1998, 1999 Terry Jones” if some versions were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names.
…
\author serge — никак не работает
2016 Иванов Сергей — тоже не работает.
Copyright 2016 Иванов Сергей — работает.
PS: и еще раз — дискуссия с моей стороны изначально велась без учета особенностей копирайта. Если отбросить всё, что связано с копирайтом, то остается только информация об авторе, которая доступна из других мест, или не имеет значения вообще
Я имел в виду буквально то, что написал — что именно та или такая же строчка комментария смысла не имеет. Про вопросы правового характера я тогда вообще не думал и спорил исключительно в разрезе того, что эта строчка не дает полезной информации ни для истории изменений, ни для того, чтобы найти контакты к кому-то, кто этим кодом занимается и поддерживает.
Я как бы совершенно наоборот заметил. Правда, https://www.gnu.org/licenses/gpl-howto.en.html со мной не совсем согласны, но и с вами тоже. В любом случае надо указывать имя автора, а не ник, и год публикации. Если нет этих атрибутов — это не заявление о копирайте с правовой точки зрения, и его можно спокойно вырезать.
Давайте определимся — к моему первоначальному комментарию есть какие-либо возражения, помимо правовых вопросов? Если есть — давайте обсудим. Если нет — то я считаю, что Doxygen команда author сама по себе не несет правовых последствий, равно как и Doxygen команда copyright.
Пример из того же FFMpeg (в заголовке каждого файла):
> You should have received a copy of the GNU Lesser General Public
> License along with FFmpeg; if not, write to the Free Software
> Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
В самой лицензии есть требование, что каждая копия программы или ее части должна сопровождаться полной копией лицензии. Соответственно, если «взяли только исходные файлы» и не положили куда-то в другое место в исходниках копию лицензии, то лицензия нарушена (если заимствующий проект уже под той же лицензией, то, конечно, не обязательно).
Копирайт — штука, не эквивалентная авторству; некоторые проекты требуют явного отказа от копирайта в пользу какой-либо компании.
А теперь самое главное:
> ///@author idimm
это не копирайт и не лицензия, а просто комментарий об авторе кода. Который, по-моему, не имеет смысла. Я выдал аргументы, почему так считаю. Аргументов о противном пока не видел. Расскажите, пожалуйста, в чем польза этого комментария? Как вам он может быть полезен и для чего вы эту информацию можете использовать?
Ну извините, это не open source, а какой-то говнокод. Любые нормальные проекты либо вообще не включают в свое дерево другие библиотеки (а требуют их как зависимости), либо берут все дерево целиком со всеми файлами и просто подтачивают билд-машинерию под свои нужды (и трекают все изменения в своем репозитории).
Брать только *.[ch]* — это как минимум некорректно по отношению к разработчикам, а как максимум — нарушает лицензию. К примеру, тот же GPL требует включить в каждый файл преамбулу, а в проект — полный текст лицензии. Взять файлы с преамбулой, выкинуть файл с текстом лицензии и распространять результат — нарушение прав разработчиков.
С прагматичной точки зрения — пусть есть такой проект. Даже в нем очевидно, что файлы из каталога tinyxml относятся к tinyxml (да и в самих файлах написано, что это tinyxml); всё, можно закрывать проект и идти на сайт tinyxml — там вся информация по ответственным людям есть. Зато неочевидно, что весь код в этих файлах был написан авторами tinyxml, т.к. хрен его знает, что в этом проекте натворили еще, помимо собственно «кражи» кода из чужих проектов.
И даже в этом примере информация о собственно авторе файла (физическом лице) не нужна. Максимум нужно знать проект, к которому относится файл (а ее обычно пишут как часть лицензионной преамбулы).
Особенно это относится к Open Source:
1) Подавляющая часть проектов использует систему контроля версий, и по git/mercurial/whatever репозиторию можно всегда посмотреть полную историю файла — кто написал первую версию, кто и что поправил и т.д. В случае git даже посылка изменений через патчи сохраняет правильную историю. Запись в заголовке файла в лучшем случае дублирует информацию, в худшем — просто недостоверна. Исключение составляют проекты со «сложной» историей — странные форки, мержи и т.д., когда информация из оригинального репозитория может быть утеряна
2) Большая часть проектов также содержит файл README, или CREDITS, или MAINTAINERS, или что-то похожее, который указывает на людей, отвечающих за проект или за интересующую его часть.
3) Как продолжение мысли из предыдущего пункта — очень часто в Open Source человек, который когда-то написал файл, уже давно им не занимается, а занимаются другие люди.
Не стоит доверять сообщениям компилятора, который ЭТО обзывает небезопасным. И уж тем более не надо втыкать костыли типа
> printf( "%s", «Hello, world!» );
> ///@file hello_world.cpp
Бессмысленно — это часть метаданных файла, и ее не стоит дублировать в данных файла. Особенно если учесть, что файл потом могут переименовать
> ///@author idimm
Бессмысленно — если уж мы тут следуем лучшим практикам, то эта информация есть в системе контроля версий. Особенно если учесть, что файл потом могут редактировать другие люди
Про devtoolset слышал, но не очень в курсе, как обстоят дела с установкой собранных таким образом программ на другие машины. Тащить devtoolset как пререквизит не комильфо.
Если еще учесть, что у нас помимо gcc/linux/x86 есть еще кросскомпиляция на gcc/linux/arm и компиляция msvs/windows/x86 (и куча third-party библиотек, не дающих обновиться на visual studio 2015), то апгрейд компилятора становится задачей, требующей очень серьезного подхода. А ограничения имеющихся компиляторов дают о себе знать — то в одном regex криво работает, то в другом инициализация статических локальных переменных не атомарна, и т.д.
Костыль с include_next и /FI — в принципе, решение; если понадобится, то будем использовать.
Ну это какие-то розовые очки. К примеру, вот у нас самый распоследний CentOS 7, с ним идет gcc 4.8. Поддержкивается почти весь C++11, поддержки C++14 нет вообще. Вот у нас есть Visual Studio 2013 — снова то же самое: большая часть C++11 есть (по крайней мере те части, что и хотелось бы иметь), С++14 нет совсем.
Подпихнуть свои костыли можно, но это в реальных проектах дело не вполне тривиальное — надо во все файлы включать один общий хедер. Чем это городить, проще уж new воткнуть
К сожалению, make_unique появился только в C++14, так что людям, которые еще не перешли на него, приходится использовать std::unique_ptr ptr = new T(...);
Под провайдером я и подразумеваю издателя. Ну, к примеру, большая часть HLS-вещаний, с которыми я сталкивался, зашифрована по AES-128. Даже если это вещание эфирного канала. На уровне протокола, естественно, при этом используется HTTP без SSL/TLS. Клиентским устройствам приходится тратить ресурсы на декодирование видеопотока, но никакой выгоды клиенту от этого нет.
Если передавать через TLS/SSL, то хотя бы ваш провайдер/сосед/дядяВася не узнает, что именно вы смотрите.
В этом разрезе было бы интересно примерить влияние других новшеств на экологию. Переход с H264 SD на HEVC FHD (а то и 4K) нехило увеличивает нагрузку на всё — и на кодирующие фермы, и на каналы передачи данных, и на миллионы декодирующих устройств. Любые накладные расходы HTTP/2 на фоне 20-мегабитного видеопотока не просто малозначительны — они вообще незаметны. Надо подкинуть «зеленым» идею требовать запрета видеопотоков выше 1 мбита!
На самом деле провайдеры мультимедиа-контента обожают его шифровать (т.к. это позволяет сделать более развесистый DRM), но они очень не любят шифровать сессию, в которой он передается (т.к. на конфиденциальность клиента им плевать, а вот на загрузку серверов CDN — нет).
Для данного описанного случая (особенно если weak_ptr для этого типа объектов не нужен) может оказаться лучшим выходом переделка shared_ptr на intrusive_ptr.
Мобильные операторы еще хуже врезаются со своими «мобильными помощниками» и сливом информации об абоненте.
Мне непонятно, почему статья говорит в качестве профита про «судебный прецедент», если решения суда по существу не было. Тот факт, что истец отказался от этого дела, вряд ли можно использовать в качестве весомого аргумента по другому делу.
Мы ходим по кругу. Ну давайте еще раз. В вашем примере есть файл, скажем, 3rdparty/ffmpeg/libavutil/sha512.c. Хочется узнать, кто автор. Хм, откуда взяли этот файл? Может быть из (внезапно) ffmpeg? Идем на гитхаб, смотрим в репозиторий ffmpeg, находим там этот файл и смотрим его историю. Готово, задача решена.
The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn't post it until 1999, use 1998). You should add the proper year for each release; for example, “Copyright 1998, 1999 Terry Jones” if some versions were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names.
…
Always use the English word “Copyright”; by international convention, this is used worldwide, even for material in other languages. The copyright symbol “©” can be included if you wish (and your character set supports it), but it's not necessary. There is no legal significance to using the three-character sequence “©”, although it does no harm.
\author serge — никак не работает
2016 Иванов Сергей — тоже не работает.
Copyright 2016 Иванов Сергей — работает.
PS: и еще раз — дискуссия с моей стороны изначально велась без учета особенностей копирайта. Если отбросить всё, что связано с копирайтом, то остается только информация об авторе, которая доступна из других мест, или не имеет значения вообще
Давайте определимся — к моему первоначальному комментарию есть какие-либо возражения, помимо правовых вопросов? Если есть — давайте обсудим. Если нет — то я считаю, что Doxygen команда author сама по себе не несет правовых последствий, равно как и Doxygen команда copyright.
> You should have received a copy of the GNU Lesser General Public
> License along with FFmpeg; if not, write to the Free Software
> Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
В самой лицензии есть требование, что каждая копия программы или ее части должна сопровождаться полной копией лицензии. Соответственно, если «взяли только исходные файлы» и не положили куда-то в другое место в исходниках копию лицензии, то лицензия нарушена (если заимствующий проект уже под той же лицензией, то, конечно, не обязательно).
Копирайт — штука, не эквивалентная авторству; некоторые проекты требуют явного отказа от копирайта в пользу какой-либо компании.
А теперь самое главное:
> ///@author idimm
это не копирайт и не лицензия, а просто комментарий об авторе кода. Который, по-моему, не имеет смысла. Я выдал аргументы, почему так считаю. Аргументов о противном пока не видел. Расскажите, пожалуйста, в чем польза этого комментария? Как вам он может быть полезен и для чего вы эту информацию можете использовать?
Брать только *.[ch]* — это как минимум некорректно по отношению к разработчикам, а как максимум — нарушает лицензию. К примеру, тот же GPL требует включить в каждый файл преамбулу, а в проект — полный текст лицензии. Взять файлы с преамбулой, выкинуть файл с текстом лицензии и распространять результат — нарушение прав разработчиков.
С прагматичной точки зрения — пусть есть такой проект. Даже в нем очевидно, что файлы из каталога tinyxml относятся к tinyxml (да и в самих файлах написано, что это tinyxml); всё, можно закрывать проект и идти на сайт tinyxml — там вся информация по ответственным людям есть. Зато неочевидно, что весь код в этих файлах был написан авторами tinyxml, т.к. хрен его знает, что в этом проекте натворили еще, помимо собственно «кражи» кода из чужих проектов.
И даже в этом примере информация о собственно авторе файла (физическом лице) не нужна. Максимум нужно знать проект, к которому относится файл (а ее обычно пишут как часть лицензионной преамбулы).
Кроме того, зачем нужно первоначальное авторство файла? Как пример — замечательный 165Kb файл ffmpeg.c из одноименного проекта. Сверху как часть преамбулы GPL написано «Copyright © 2000-2003 Fabrice Bellard». Ну вот первоначальный автор указан, а толку с того? 13 лет с тех пор прощло, Беллард уже лет 10 как не касался FFmpeg вообще, файл был переписан чуть более, чем полностью десятками людей (буквально, git blame показывает, что за авторством Белларда в этом файле остались только пустые строчки и строчки из одного символа скобочки).
Про GPL — подозреваю, требует такое для защиты от «включения дурака» по типу «ой а я не знал что этот файл был под лицензией, на нем же не написано».
1) Подавляющая часть проектов использует систему контроля версий, и по git/mercurial/whatever репозиторию можно всегда посмотреть полную историю файла — кто написал первую версию, кто и что поправил и т.д. В случае git даже посылка изменений через патчи сохраняет правильную историю. Запись в заголовке файла в лучшем случае дублирует информацию, в худшем — просто недостоверна. Исключение составляют проекты со «сложной» историей — странные форки, мержи и т.д., когда информация из оригинального репозитория может быть утеряна
2) Большая часть проектов также содержит файл README, или CREDITS, или MAINTAINERS, или что-то похожее, который указывает на людей, отвечающих за проект или за интересующую его часть.
3) Как продолжение мысли из предыдущего пункта — очень часто в Open Source человек, который когда-то написал файл, уже давно им не занимается, а занимаются другие люди.
Не стоит доверять сообщениям компилятора, который ЭТО обзывает небезопасным. И уж тем более не надо втыкать костыли типа
> printf( "%s", «Hello, world!» );
> ///@file hello_world.cpp
Бессмысленно — это часть метаданных файла, и ее не стоит дублировать в данных файла. Особенно если учесть, что файл потом могут переименовать
> ///@author idimm
Бессмысленно — если уж мы тут следуем лучшим практикам, то эта информация есть в системе контроля версий. Особенно если учесть, что файл потом могут редактировать другие люди
Если еще учесть, что у нас помимо gcc/linux/x86 есть еще кросскомпиляция на gcc/linux/arm и компиляция msvs/windows/x86 (и куча third-party библиотек, не дающих обновиться на visual studio 2015), то апгрейд компилятора становится задачей, требующей очень серьезного подхода. А ограничения имеющихся компиляторов дают о себе знать — то в одном regex криво работает, то в другом инициализация статических локальных переменных не атомарна, и т.д.
Костыль с include_next и /FI — в принципе, решение; если понадобится, то будем использовать.
Подпихнуть свои костыли можно, но это в реальных проектах дело не вполне тривиальное — надо во все файлы включать один общий хедер. Чем это городить, проще уж new воткнуть
Если передавать через TLS/SSL, то хотя бы ваш провайдер/сосед/дядяВася не узнает, что именно вы смотрите.