Я думаю, что он работает скорее потому что, никому не интересна винда на серверах :)
А Redis все таки — сторадж, пусть и для небольших объемов данных.

Не совсем — там во многих странах лидирует Facebook

Ммм… Тем что они решают совершенно разные задачи? А так же тем, что JetBrains еще не умеют C++?

Я все понимаю, но данный вопрос и так прекрасно разобран в «Алгоритмы: построение и анализ» с более простым и коротким доказательством.

По вашей формуле получается, что дешево, но очень быстро — это качественно.

bool PersonsList::compareByJobName( const Person& person1, const Person& person2 )
{
    Job& job1=getJobById(person1.job_id);
    Job& job2=getJobById(person2.job_id);
    return job1<job2;
}

void PersonsList::sortByJob(){
    using namespace std::placeholders;
    stable_sort(persons.begin(),persons.end(), std::bind(&PersonsList::compareByJobName, this, _1, _2));
}

Легко, вот пример на чистом C++ без сторонних библиотек :) Даже студия, вроде, уже научилась так делать.

Ни разу не писал на PHP, но почему-то кажется, исходя из наличия метода password_get_info(), что в $hash хранится алгоритм, и эти сведения используются в password_verify

Ничего не понял.

1. Для std::unordered_set/unordered_map вторым/третьим шаблонным параметром передается функтор хеширования
2. Стандартный std::hash обязан удовлетворять требования функции хеширования
3. В стандарте имеется std::hash<string>, который удовлетворяет условиям функции хеширования
4. Для любого сложного типа достаточно специализировать std::hash<T>
5. std::unordered_set/unorderd_map реализованы через хеш-таблицы

Так почему же это не hash_map?

В стандарте и реализациях STL есть unordered_map

Jolla лучше операционкой. В общем, я его предзаказал, поэтому как только получу в руки — смогу сказать подробнее.

Эти бинари находятся в пакетах inotify-tools и libinotifytools0 в Debian/Ubuntu, возможно автор их просто взял оттуда.

Например Ejudge — для проверки задач в ACM-стиле (то есть дается файл с входными данными, решение участника проверяется на различных тестах и пишет ответ в файл, ваш чекер сверяет его ответы из файла с эталоном по вашим алгоритмам)

В моем уютном мире я пользуюсь 64-битной Ubuntu уже 4 года, весь софт за некоторым проприетарным исключением все это время стоял 64-битный. Даже более того, Debian официально поддерживает не только такие распространенные архитектуры как x86 и amd64 (начиная с 2005), но и такие как powerpc (2000), armel (2009) и sparc (1999).

У Microsoft (насколько я себе представляю) и у людей пишущих под винду никогда не было особого понимания, что существует что-то кроме традиционной x86 архитектуры, поэтому часто происходили ошибки вида присваивания указателя к целому числу, что на 64-битных системах приводило к неопределенному поведению. Возможно еще возникали проблемы из-за того, что в функции люди передавали по указателю что-то вроде long, вместо DWORD, что в принципе работало, но не соответстовало документации. Далее, до совсем недавнего времени в Windows были большие проблемы с 64-битными системами сборки, еще пару лет назад 64-битного рабочего mingw фактически не было, MSVS Express включал (а может еще и включает, не знаю) в себя только 32-битный компилятор и т.д… По поводу win-специфичных 64-битных проблем, я думаю, Andrey2008 смог бы рассказать лучше чем я.

Но все эти проблемы не касаются Unix/Linux/MacOS миров. Оригинальный Unix и GNU изначально писались с пристрелом на различные платформы. Linux еще с 1995 года стал поддерживать отличные от x86 платформы (Alpha, SPARC и MIPS). MacOS за свою историю уже пережила 3 переезда (PowerPC -> x86 -> amd64).

Так это не проблема языка, а отсутствие знаний (в частности стандарта и межпроцессорных особенностей). Если писать без нарушения стандарта (там где нужно гарантировать размер — использовать int*_t типы), использовать сетевой формат для передачи чисел (между PowerPC/Arm/x86), то никаких проблем не может быть в принципе.

А в чем хоть какая-нибудь сложность в написании кода под разные процессорные архитектуры на Си/С++? Этот язык изначально создавался, чтобы как раз таких проблем не было.

Jingle предусматривает реализацию VoIP поверх UDP, так что для передачи аудио/видео TCP не используется нигде, кроме самой инициализации соединения.

А вас не напрягало использование XML внутри бинарных данных, запакованных внутри других бинарных данных?) В частности так устроены XTraz'ы (через которые шлются x-статусы).

Многие Jabber библиотеки пишутся с использованием XPath, где документом является каждая отдельно пришедная станза с сервера, все отлично работает и парсится.

Есть же уже XEP, который позволяет прикреплять к сообщению все это.