Хотите, поведаю, почему так?
NULL, как известно это дефайн для 0. Автор где-то нашел кусок [г]кода, где 3 и 4 параметры передавались как NULL. Ну с винапи древним кодом такое встречается повсеместно.
Потом как порядочный человек, думает «ну блин, на дворе 17 год, адекватные люди давно nullptr используют». И заменяет NULL везде на nullptr. Но к его сожалению, код не компилится (алилуйя, ради этого nullptr и придумали). Автор возвращает NULL в тех местах, где не собралось, в итоге имеем, что имеем)
Да, только в случае с человеком там примерно как с ядром Linux без возможности применения патчей на лету — пропатчить-то можешь, но запустить только на новом устройстве. Пока что =)
скиньте ссылку на видео, я прошарил всю выдачу на LTT по запросу «4К» не нашел такого теста (скорее наоборот там видео из серии «4к для гейминга не уперся»)
Очень много вопросов вызывает «увидеть разницу». Повторюсь, если это пожатое видео (а почти все тесты на нем), разница будет почти наверняка (и не обязательно будет в пользу 4К, кстати говоря). Если просто показать человеку 2 стоп кадра и сказать — ты видишь здесь отличия — я почти уверен что большинство скажут — «да».
я не хочу сейчас выяснять что и при каких обстоятельствах было пожато, каким кодеком и битрейтом, поэтому и написал, что я бы поверил секте адептов 4К, если бы эксперименты проводились
а) на несжатом видео (можно и пожертвовать пару сотен Гб для эксперимента-то),
б) это должно быть слепое тестирование. (А то люди и про вино в красивой бутылке говорят «о да, я чувствую здесь насыщенный выдержанный вкус»).
в) это видео должно быть, а не стоп-кадры, в которые можно долго вглядываться)
Я знаю, что это выглядит созданием большого количества ограничений, но я просто как «исследователь» хочу отсечь все факторы кроме одного — повышенная плотность пикселей. Да, при чтении текста на 4К монитора разница будет заметна, я не спорю. Но тут особенность в том что текст мы читаем областью сетчатки с наибольшей плотностью «пикселей» =)
Теперь о геймерах) Геймеры это точно не средние люди, они гораздо лучше чувствуют артефакты сжатия от предсказания движения, разницу между 30 и 60 fps и пр. Давайте еще летчиков истребителей в выборку брать, что уж)
Вообще, как справедливо комментатор ниже заметил, у человека есть некоторый предел углового размера элемента, который может восприниматься отдельно от соседнего.
4К-запись в FullHD (720p) от FullHD (720p) записи в FullHD (720p)
Поясните, что вы имеете в виду?
1) видео записанное в 4К с конским битрейтом, и потом отрескейленное на 720 экран
и
2) видео сразу пожатое в 720 и отображаемое на 720 экране
?
Если да, то так себе тест, очевидно в первом случае качество картинки будет выше) давайте я вам предложу такой эксперимент
1) записать 4К видео в lossless.
2) пережать его в FullHD (1080p) lossless.
Оба видео показать группе добровольцев на 4К и FullHD экранах соответственно (в идеале еще чтобы добровольцы не знали где какой экран), и спросить, видят ли они различия.
Моя внутренняя ванга подсказывает что 9 из 10 разницы не заметят, может я и ошибаюсь.
«85 пунктов бы значило, что вы не можете решить довольно простые логические задачи, которые могут решить 80% людей» ну в целом да, так оно и есть.
У меня порой бывают трудности с созданием логики в коде, я иногда путаю || и &&, true и false. но с построением общей структуры программы проблем нет =)
Стоп, если я кому-то скажу, что на работе видел Сергея Брина условно, это нарушение NDA? Или речь только про тех сотрудников что не являются публичными лицами? Впервые слышу про такое, насколько это вообще с законами соотносится?
IQ это вы загнули конечно. У меня например IQ около 85, и я работаю старшим разработчиком. Я думаю, связь весьма опосредованная, низкий IQ отнюдь не мешает работать программистом.
То что я выше посмотрел по ссылке, не рефлексию больше напоминает, а generator expressions, которые позволяют ast менять, очень для метаклассов будут полезны. Но это точно не C++23, как Саттер сказал. Может быть какой-то TS к 26 году разве что.
«Берёшь либу и не знаешь, что от неё ожидать»
Пока для меня, основная боль как разработчика, это не то что в С++ нет какой-то там поддержки utf-8, а то что сторонние кроссплатформенные C библиотеки просто используют fopen/stat и т.п. которые разумеется на Win работают, но без поддержки юникода.
— ffmpeg/vidstab
— opencv — весь файловый api
— glog
— dlib
(первое что за минуту в голову пришло, тысячи их)
Да, патчи-то наложить недолго, но е-ёмое, не понимаю я разработчиков библиотек, под винду эти функции существуют два десятка лет, вы делаете «кросплатформенность» и забиваете на поддержку юникода в FS? что с вами не так?
MS, сделайте уже поддержку setlocale(«utf-8»), чтобы fopen работал как везде, это не лечится)
1. Ну это претензии к конкретному проекту — с любым проектом может быть такое что сборка под Windows находится в сыром/полуподдерживаемом состоянии, не только с CMake. Даже с предельно выскокоуровневым qbs в исходниках qtc периодически были коммиты «починка сборки под win», хотя там разработчики активно на всех платформах сидят.
2. полностью поддерживаю. Вся внутренняя кухня cmake — что скрипты, что исходники — адовый ад.
3. Генерируемый код на то и есть таковой, чтобы его не нужно было читать глазками) Впрочем, по своему опыту могу сказать — я почти всегда использую генератор Ninja — там в 1 файле Rules складываются, в основном — все параметры. Вполне очень наглядно и читаемо, попробуйте. Я пока отлаживал свою систему распределённой сборки, а также вспомогательные утилиты (типа msbuild2ninja) очень активно использовал раскуривание генерируемого cmake ninja-файла, все вполне наглядно.
Про сырость — впечатление обманчивое, т.к. cmake используется очень давно в куче продакшн систем, и в целом хорошо себя зарекомендовал — хорошая стабильность в плане регрессий, хорошая совместимость (люди последовательно мигрировавшие с какого-нибудь 2.8.11 до 3.12 меня поймут). Он попахивающий, если лезть внутрь, но не сырой)
А вот тут речь уже о том что фичи стандартной библиотки тянутся медленнее)
Компилятор — «да! да здравствует новый стандарт!», его реализация STL — «подождите, пожалуйста помедленнее, я запсваю» =)
Если не брать штуки по constexpr — то большая часть мажорных нововведений как раз по части компилятора, я думаю с ними проблем не возникнет.
в любом случае, согласитесь, что 5% отдельных фич, с которыми проблемы, это не та вещь про которую можно ныть «ой беда, 10 лет теперь стандарт реализовывать будут».
C++ это такой язык, что даже не будь изкоробочной поддержки в стандартной библиотеке чего угодно, это бы не привело его к провалу.
Существующая практика такова, что почти всегда для реализации нужных функций нужны сторонние библиотеки.
С точки зрения стиля кодирования я бы вообще не рекомендовал где-то сильно рассчитывать на глобальность переменных, т.к. может быть такая ситуация:
— Написал вспомогательный cmake-файл, в нем поменял CMAKE_CXX_FLAGS, например. Функций в нем нет.
— Потом спустя какое-то время, пишется функция, и в ней включается этот файл. Сюрприз-сюрприз, после выхода из функции CMAKE_CXX_FLAGS останутся прежними.
Поэтому rule of thumb я бы сформулировал «не используйте запись в глобальные переменные cmake для передачи информации между частями скрипта».
В случаях, когда это позарез надо, использовать явно set(… CACHE… "" FORCE)
Вы неправы. Начиная с С++14, поддержка максимум на год задерживалась. Другое дело, что если концепты вы можете начать использовать сразу после появления их поддержки в тулчейне, то вот с модулями не все так просто) минимум ждать поддержки и в системах сборки, а максимум — во всех используемых вами библиотеках.
Ну вот сейчас 2018 год, С++17 полностью (по крайней мере на словах) 3 популярных компилятора поддерживают. У нас все проекты собираются с флагами 17 стандарта.
Благодаря регулярным и предсказуемым релизам, разработчики компиляторов могут как раз быстрее реализовывать фичи. Т.е. в 2019 заморозят набор фич, и к 20 году большая часть в том или ином виде будет реализована со спец флагами в компиляторах. Для концептов, контрактов и модулей, кстати, флажки или экспериментальные ветки уже есть.
Дело не в отдельный аттрибутах (я про них не упоминал). Уверен, разработчики смогут справиться. Речь о том что разные имена в ABI, и это не покрыть фичами языка (либо создавать новый ABI которым никто не будет пользоваться).
Хотите, поведаю, почему так?
NULL, как известно это дефайн для 0. Автор где-то нашел кусок [г]кода, где 3 и 4 параметры передавались как NULL. Ну с винапи древним кодом такое встречается повсеместно.
Потом как порядочный человек, думает «ну блин, на дворе 17 год, адекватные люди давно nullptr используют». И заменяет NULL везде на nullptr. Но к его сожалению, код не компилится (алилуйя, ради этого nullptr и придумали). Автор возвращает NULL в тех местах, где не собралось, в итоге имеем, что имеем)
Очень много вопросов вызывает «увидеть разницу». Повторюсь, если это пожатое видео (а почти все тесты на нем), разница будет почти наверняка (и не обязательно будет в пользу 4К, кстати говоря). Если просто показать человеку 2 стоп кадра и сказать — ты видишь здесь отличия — я почти уверен что большинство скажут — «да».
я не хочу сейчас выяснять что и при каких обстоятельствах было пожато, каким кодеком и битрейтом, поэтому и написал, что я бы поверил секте адептов 4К, если бы эксперименты проводились
а) на несжатом видео (можно и пожертвовать пару сотен Гб для эксперимента-то),
б) это должно быть слепое тестирование. (А то люди и про вино в красивой бутылке говорят «о да, я чувствую здесь насыщенный выдержанный вкус»).
в) это видео должно быть, а не стоп-кадры, в которые можно долго вглядываться)
Я знаю, что это выглядит созданием большого количества ограничений, но я просто как «исследователь» хочу отсечь все факторы кроме одного — повышенная плотность пикселей. Да, при чтении текста на 4К монитора разница будет заметна, я не спорю. Но тут особенность в том что текст мы читаем областью сетчатки с наибольшей плотностью «пикселей» =)
Теперь о геймерах) Геймеры это точно не средние люди, они гораздо лучше чувствуют артефакты сжатия от предсказания движения, разницу между 30 и 60 fps и пр. Давайте еще летчиков истребителей в выборку брать, что уж)
Вообще, как справедливо комментатор ниже заметил, у человека есть некоторый предел углового размера элемента, который может восприниматься отдельно от соседнего.
Поясните, что вы имеете в виду?
1) видео записанное в 4К с конским битрейтом, и потом отрескейленное на 720 экран
и
2) видео сразу пожатое в 720 и отображаемое на 720 экране
?
Если да, то так себе тест, очевидно в первом случае качество картинки будет выше) давайте я вам предложу такой эксперимент
1) записать 4К видео в lossless.
2) пережать его в FullHD (1080p) lossless.
Оба видео показать группе добровольцев на 4К и FullHD экранах соответственно (в идеале еще чтобы добровольцы не знали где какой экран), и спросить, видят ли они различия.
Моя внутренняя ванга подсказывает что 9 из 10 разницы не заметят, может я и ошибаюсь.
У меня порой бывают трудности с созданием логики в коде, я иногда путаю || и &&, true и false. но с построением общей структуры программы проблем нет =)
Обычно люди «хорошими» называют людей которые такое же мировоззрение, как и они, используют. «свой» => «хороший».
Пока для меня, основная боль как разработчика, это не то что в С++ нет какой-то там поддержки utf-8, а то что сторонние кроссплатформенные C библиотеки просто используют fopen/stat и т.п. которые разумеется на Win работают, но без поддержки юникода.
— ffmpeg/vidstab
— opencv — весь файловый api
— glog
— dlib
(первое что за минуту в голову пришло, тысячи их)
Да, патчи-то наложить недолго, но е-ёмое, не понимаю я разработчиков библиотек, под винду эти функции существуют два десятка лет, вы делаете «кросплатформенность» и забиваете на поддержку юникода в FS? что с вами не так?
MS, сделайте уже поддержку setlocale(«utf-8»), чтобы fopen работал как везде, это не лечится)
2. полностью поддерживаю. Вся внутренняя кухня cmake — что скрипты, что исходники — адовый ад.
3. Генерируемый код на то и есть таковой, чтобы его не нужно было читать глазками) Впрочем, по своему опыту могу сказать — я почти всегда использую генератор Ninja — там в 1 файле Rules складываются, в основном — все параметры. Вполне очень наглядно и читаемо, попробуйте. Я пока отлаживал свою систему распределённой сборки, а также вспомогательные утилиты (типа msbuild2ninja) очень активно использовал раскуривание генерируемого cmake ninja-файла, все вполне наглядно.
Про сырость — впечатление обманчивое, т.к. cmake используется очень давно в куче продакшн систем, и в целом хорошо себя зарекомендовал — хорошая стабильность в плане регрессий, хорошая совместимость (люди последовательно мигрировавшие с какого-нибудь 2.8.11 до 3.12 меня поймут). Он попахивающий, если лезть внутрь, но не сырой)
Компилятор — «да! да здравствует новый стандарт!», его реализация STL — «подождите, пожалуйста помедленнее, я запсваю» =)
Если не брать штуки по constexpr — то большая часть мажорных нововведений как раз по части компилятора, я думаю с ними проблем не возникнет.
в любом случае, согласитесь, что 5% отдельных фич, с которыми проблемы, это не та вещь про которую можно ныть «ой беда, 10 лет теперь стандарт реализовывать будут».
Существующая практика такова, что почти всегда для реализации нужных функций нужны сторонние библиотеки.
Посмотрите на Boost.Text, может вам понравится:
www.youtube.com/watch?v=944GjKxwMBo
p.s. я даже не буду комментировать «провал» языка который живет 30 лет и загибаться не планирует.
— Написал вспомогательный cmake-файл, в нем поменял CMAKE_CXX_FLAGS, например. Функций в нем нет.
— Потом спустя какое-то время, пишется функция, и в ней включается этот файл. Сюрприз-сюрприз, после выхода из функции CMAKE_CXX_FLAGS останутся прежними.
Поэтому rule of thumb я бы сформулировал «не используйте запись в глобальные переменные cmake для передачи информации между частями скрипта».
В случаях, когда это позарез надо, использовать явно set(… CACHE… "" FORCE)
Ну вот сейчас 2018 год, С++17 полностью (по крайней мере на словах) 3 популярных компилятора поддерживают. У нас все проекты собираются с флагами 17 стандарта.
Благодаря регулярным и предсказуемым релизам, разработчики компиляторов могут как раз быстрее реализовывать фичи. Т.е. в 2019 заморозят набор фич, и к 20 году большая часть в том или ином виде будет реализована со спец флагами в компиляторах. Для концептов, контрактов и модулей, кстати, флажки или экспериментальные ветки уже есть.