В С++ есть принцып: не платим за то, что не используем. На этом принципе основаны различные проверки во время компиляции, примеры можно почитать у того же Александреску.
А вот тут вы лукавите. Кое что разработчик API сделать может. Например разработчики libpqxx сделали такой метод, для извлечения результата:
template<typename T > bool pqxx::field::to (T & Obj) const
Отсюда имеем ситуацию:
я как пользователь знаю какие типы должен возвращать запрос;
разработчики API ввели ограничения и сказали явно указывайте тип;
во время выполнения библиотека знает какие типы пришли в запросе, какие типы указал пользователь и делает преобразование типов проверив на возможность такого действия.
У базы данных есть схема, в которой четко прописаны типы. Я привел пример с работой PostgreSQL, там в протоколе содержится информация о типах. Я разрабатываю базу в терминах предметной области и мне удобно опрерировать простым набором объектов, которые соответствуют таблицам.
В случае RPC должна быть некая конвенция о формате и типах данных. Например в случае с JSON-RPC я использую JSON схему для валидации.
SQL-конструкторы появляются в разработке своей ORM, или разработка всяческих конструкторов схем данных. Там действительно схема данных определяется пользователем, а не программистом.
А что тут собственно такого? В задание не сказано использовать NGINX, а простой рабочий прототип можно сварганить за пару часов. Окценты были сразу расставлены:
Верстка не важна, уделяйте основное внимание бэкенду, оформлению кода, мелочам.
Глядя на конечную схему, сразу вспоминается астронавт архитектуры. Архитектура это компромисс между требованиями и имеющимся ресурсами, т.е. вся эта красивая архитектура может не уложиться в бюджет и сроки.
От tutorial'а для молодых коллег ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
Если мы объявляем функцию
а реализацию изолируем в отдельной еденице трансляции extractOCINumber.cpp
то ничего не сломаем. Зато получаем проверку есть ли член-данное, имеет ли оно нужный нам тип, верное смещение данного в классе.
В случае асинхронной утверждение ложно.
А вот тут вы лукавите. Кое что разработчик API сделать может. Например разработчики libpqxx сделали такой метод, для извлечения результата:
Отсюда имеем ситуацию:
и все это без таких сложностей, какие привели вы.
В случае RPC должна быть некая конвенция о формате и типах данных. Например в случае с JSON-RPC я использую JSON схему для валидации.
SQL-конструкторы появляются в разработке своей ORM, или разработка всяческих конструкторов схем данных. Там действительно схема данных определяется пользователем, а не программистом.
Вот пример использования libpqxx
Как понимаю все сводится к копипасту примеров по OpenCV.
Не могут позволить сайт, но могут позволить себе отказоустойчивый кластер?
От tutorial'а для молодых коллег ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
Без уникального контента статья скучная, неинтересная, бесперспективная.