Извините, но для кого эта статья? Опытные разработчики такое проделывают при использовании практически любой серьёзной плюсовой (или сишной) библиотеки. Для тех кто не осилил c++, гугл, stackoverflow и маны — ваша статья не поможет, потому что подобные косяки всё время разные, в зависимости от версии библиотеки, ос, компилятора, фазы луны.
Для нормальной удалёнки нужны либо стабильные технологии дополненной реальности (доработанный google glass, etc.), либо продвинутые 3d сканеры с 3d экранами и прочими штуками для синхронизации двух разных физических мест.
Если я правильно понял, type-traits не про то. Тут не нужно проверять типы, тут нужно проверять, обладает ли класс какой-то функций. Хотя возможно type-traits и это умеет, но вроде нет.
Да ладно, неужели VS не показывает откуда растут ноги у ошибки? gcc про любые ошибки пишет к какой строке пользовательского кода она относится:
/usr/include/c++/4.8/bits/stl_algo.h: In instantiation of ‘void std::sort(_RAIter, _RAIter) [with _RAIter = std::_List_iterator<int>]’:
test.cpp:7:45: required from here
/usr/include/c++/4.8/bits/stl_algo.h:5452:22: error: no match for ‘operator-’ (operand types are ‘std::_List_iterator<int>’ and ‘std::_List_iterator<int>’)
std::__lg(__last - __first) * 2);
Публикация исходных кодов не обязательна. Обязательна публикация объектных файлов, что позволяет писать коммерческие проги с закрытым кодом и не платить за лицензию.
Не согласен. Взять того-же Кормена, или Таненбаума — никакой воды — конкретика высокой концентрации. И читать намного интересней (субъективно) тех-же GoF или МакКонелла.
Суть не в изящности и простоте решения, а как раз в том, что «Вы только что стали незаменимым звеном для работы с сервером». Минусы я уже перечислил выше. Для обеспечения проверки того, что ничего не сломалась есть куча вещей, начиная от автосборки и заканчивая различными видами функционального тестирования. Хотите сделать доброе дело — напишите тест, сделайте мониторинг и подпишите на него разработчиков сервер-сайда. А лучше решите вопрос на организационном уровне и объясните людям что свои поделки нужно хорошенько тестить прежде чем выкатывать куда-либо.
Да будь ваше решение трижды гениальным или изящным — это не отменяет того факта, что это костыль, со всеми вытекающими. И за него кому-то придётся платить — либо непомерно дорогой поддержкой, либо опять таки очень дорогим рефакторингом.
Угу, было бы круто, но на практике человек только думает что решил проблему, а на самом деле всё стало ещё хуже. Для вашего примера — проблема решается не технологическим путём а менеджерским. Правильное решение — заставить команду разрабатывающую сервер-сайд либо обеспечить обратно-совместимый протокол, либо поддерживать клиентскую библиотеку и при любых изменениях в ней — править весь код, её использующий. А то что вы предлагаете — это дорогущий костыль, накапливание технического долга и поощрение раздолбайства. Кто даст гарантии что ваш генератор обработает абсолютно все сценарии дальнейшего изменения сервер-сайда? Кто будет виноват, если клиенты, использующие вашу наколеночную проксю вдруг получат проблемы с тем что какие-то данные не доезжают из за того что ваш генератор не пробросил одно из новых полей? И кто будет оплачивать то, что вы в рабочее время занимаетесь поддержкой сущности, которой в нормальной архитектуре быть не должно, вместо того чтобы решать текущие задачи?
Именно это автор не предлагает. Автор объясняет, почему tcp использовать не нужно. Конкретные причина — допустимость потерь отдельных пакетов и не допустимость задержек, связанных с тем что tcp разруливает потери пакетов и перепосылает их заново.
Всё нормально. Если вы хотите хранить кучу строк — вам же всё равно длину строк надо знать. Для мелких строк размер будет кодироваться прямо в том-же байте, что и префикс. Если кучу мелких чисел — они тоже будут влезать в этот 1 байт. Числа покрупнее будут занимать уже чуть больше байт, но всё равно скорее всего лучше чем оригиналы. Конечно не хаффман но тоже неплохо.
6% овер инфляции + относительная надёжность (наименьшая рискованность по сравнению с другими вариантами) + низкие требования к компетенции в предметной области — looks good. Гаражи — may be. Субъективно кажутся менее надёжным вариантом (хоть и дешёвым).
Да будь ваше решение трижды гениальным или изящным — это не отменяет того факта, что это костыль, со всеми вытекающими. И за него кому-то придётся платить — либо непомерно дорогой поддержкой, либо опять таки очень дорогим рефакторингом.