rPman

Использую при работе с IP. Если ipv4 представлен в виде int ip2long легко работать с масками, определять, принадлежит ли ip определённой сети и т.п.
Также РЕДКО использую для описания состояния некоторых свойств классов/сущностей. Например у некоторой сущности есть статус, который может принимать значения: новый, в работе, остановлен, скоро запустится, скоро будет остановлен. Естественно свойство может принимать комбинации статусов - остановлен и скоро запустится или в работе и скоро будет остановлен. На пальцах:
новый 00001
в работе 00010
остановлен 00100
скоро запустится 01000
скоро будет остановлен 10000
Тогда комбинация остановлен и запустится 01100
Вот для проверки каким статусам соответствует поле используются битовые операции

Никакие :) Как резали html в письмах, так и дальше режем... :)

для window вот
(офигенное решение кстати)
https://stackoverflow.com/questions/17246309/get-a...

// make sure it doesn't count my own properties
(function () {
    var results, currentWindow,
    // create an iframe and append to body to load a clean window object
    iframe = document.createElement('iframe');
    iframe.style.display = 'none';
    document.body.appendChild(iframe);
    // get the current list of properties on window
    currentWindow = Object.getOwnPropertyNames(window);
    // filter the list against the properties that exist in the clean window
    results = currentWindow.filter(function(prop) {
        return !iframe.contentWindow.hasOwnProperty(prop);
    });
    // log an array of properties that are different
    console.log(results);
    document.body.removeChild(iframe);
}());

Под какую платформу?
Это собственно главный вопрос. Выбор языка сегодня вторичен.
Кроссплатформенность сегодня это миф, так или иначе вы будете либо идти на компромиссы (часто жестко), или мучатся с каждой ОС по отдельности по факту используя пару десятков общих классов которые вам и в обычном (не кроссплатформенном режиме) никто не мешает собрать под все платформы в отдельный ресурс с той же скоростью.
Выбор платформы
* Если windows ничего не мешает использовать UWP / WPF
* MFC -вы серьезно хотите писать ПО на библиотеках 92го года? да они поддерживаются, но новое что-то писать на этом разве что ради фана, либо что-то специфичное под старые win системы.
* CEF - не сталкивался, но думаю мало что хорошего в идее использовать браузерный GUI и плюсы. (если не для браузера пишите)
* QT, сложный вопрос, есть его ярые поклонники не признающие ничего кроме, но я к нему нейтрален, считаю его устаревшим, хотя для встравиваемых систем и под линукс - да, т.к. практически нет альтернатив часто. Под эти платформы я бы выбрал qt только потому что на нее много информации в интернетах и сообщество имеется.
* под мобильные платформы... все довольно сложно, решений вроде как есть, но я бы сегодня использовал для GUI что-то другое(Например Flutter), а c++ для отдельных модулей ибо - замучаетесь отлаживать.
* Если GUI хочется сложный и необычный/игровой да еще и кроссплатформенно Я бы использовал необычное сочетание UnrealEngine + NoesisGUI, где Unreal решит все проблемы с платформами и производительностью Noesis с разметкой UI. Но придется пожертвовать почти всеми системными функциями на каждый чих делая кастомное решение.

Важные моменты
- Графическая библиотека должна использовать железо на максимум.
т.е. без апаратного ускорения и отрисовкой видеокартой можно выбрасывать все ваши красивости на помойку.
Наверное часто замечали что над GUI постарались, но забыли про производительность.
Если под win попробуйте UWP, он супершустр, если честно быстрее и качественнее него в отрисовке GUI ничего не встречал. Съедает любую сложность GUI при верном подходе для любого устройства ввода-вывода (клавитура/мышь, тач на 20 касаний, сенсорные перья, VR…) Какой-нибудь QT возможности даже и не снятся, хотя вторая много старше.
К сожалению платформа не популярна. Есть небольшая, но вероятность, что сдохнет, т.к. windows маркет не развился. Хотя недавно добавили возможность писать ПО и для обычного десктопа минуя распространение через магазин, но пока все сырое. ну и так же MS выкладывает все потихоньку в openSource это радует.
Хотите стабильности от жизни - берите QT, лет 10 еще точно актуальна будет. Хотите простоты и скорости разработки, UI посовременнее и посложнее - что-то из нового.

- Второй момент, после производительности. Графическая библиотека сегодня - это совместимость с "современным дизайном" .
Что я имею ввиду: когда дизайнер вам дает исходник в Figma/Sketch, иконки в SVG видео в h264 и пр. и вам нужно рассмотреть использование этого всего на устройствах 96-300 dpi где все будет адаптивно и подстраиватся под размеры и ориентацию экрана. Вы не должны испытывать боль заднего прохода. Берете и делаете, т.к. у вас есть для этого инструменты.
Наверное видели супермелкоту в windows программах когда DPI экрана под 300, это как раз MFC, QT и подобные
Про линукс на FullHD планшете 8" это отдельная большая тема беседы. Хотя вроде как в последних сборках имеется поддержка hiDPI устройств.
Тоже самое под мобильные платформы. из-за разнородицы dpi я как раз и рекомендовал использовать что-то вроде Flutter, т.к. он создан для таких устройств, в отличии от многих библиотек допиленных, созданных еще для PC в лохматые года, через костыли говна и палки пытающихся как-то с грехом пополам отрисовать несвойственную ей среду, по пути теряя все преимущества производительности плюсов.
Хотя, справедливости ради, я видел С++ решения которые на мобилках летают суперски, но это уже вопрос профессионализма, крутой барабанщик и на кастрюлях сыграет много лучше новичка, но учится лучше на хорошем и заточенном инструменте.

Тебе надо работать с API youtube. Получив данные о видео, надо будет распарсить ссылку, вытащить параметры и составить ссылку на видео. Ниже будет пример на codepen, там есть весь код, который необходим.

Возможно, установлен маленький буфер журнала ядра.
Передайте ядру параметр log_buf_len=4096K, например.

Задача называется image captioning.
Вот неплохой гайд на Pytorch: https://www.analyticsvidhya.com/blog/2018/04/solvi...

Во первых "использовать один язык программирования" и кросс-платформенность - это две разные вещи. Параллельные.

У языков есть свои плюсы и минусы (и это еще безотносительно кросс-платформенности). Иначе давным-давно был бы один-единственный язык. Идеальный. Хотя бы в пределах одной платформы. Но нет. Языки продолжают появляться.

А теперь про кросс-платформенность:

Платформы сильно разные.
Ну вот, скажите, зачем вам "оконное API" для серверной платформы, где нет GUI?

Попытки написать универсальное решение имеются. Но получаем ограниченную функциональность где-либо. Не учитывание нюансов где либо. Потому что нельзя объять необъятное.

Условно говоря: у Windows для отображения окна функция a, у Linux - b, и нужно на каждой платформе выбирать соответствующую.

Вы забыли, что desktop на Linux может быть сильно-сильно различным.
И даже для Linux нет нормальной кросс-платформенности в GUI.

Если да, то почему нельзя везде использовать один язык программирования?

Почему нельзя.
Можно.
На JavaScript или с QT или использовать JDK.
Однако применимость этих решений - ограничена. Уж очень много где они не идеально вписываются и не подходят ко всем деталям платформы.

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

но тогда необходим слой абстракции. Этот слой подразумевает обращение к API через ту функцию, которой соответствует данная на необходимой платформе? Условно говоря: у Windows для отображения окна функция a, у Linux - b, и нужно на каждой платформе выбирать соответствующую.

Примерно так и делают.

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