Изначально проверка была написана с учетом возможно разных размеров size_t и long — оба значения по умолчанию были бы неявно приведены к одному и тому же беззнаковому типу достаточного размера.
Не просто создают новое, а объявляют старое безнадежным и ожидают, что новое само собой будет лучше. Вместо старых проблем получают новые, плюс в новом коде непременно будут новые (свежие, если вам так приятнее) ошибки, какое-то время правят, потом «новое» опять объявляют безнадежным, процесс продолжается бесконечно.
Почему в первом случае передача паспортных данных к вам на сервер считается безопасной, при этом во втором случае передача данных на сервер Aviasales считалась бы небезопасной?
Хотели сделать акцент на том, что данные передаются только в наш сервис распознавания. При этом передача выполняется по защищенному SSL каналу и на стороне сервиса данные автоматически удаляются вскоре после окончания обработки и не хранятся ни в нашем сервисе, ни в сервисе Aviasales.
Кстати, решения для распознавания российских автомобильных номеров у вас нет?
Не всегда, но часто стоит. Если вы только описываете проблему, то вы рассказываете «как правильно», а если исправляете ее — то показываете. Разработчикам нужно уметь и то, и другое. Владельцам проекта нужно заметно больше усилий для того, чтобы по описанию сделать исправление, чем для того, чтобы оценить готовое исправление.
Да, но очень часто многочисленные мелкие дефекты нигде не отмечены, например, потому что их быстрее исправить, чем описывать, или потому что они не «не так уж важны», чтобы тратить на них время, в результате их можно найти только в самом коде.
По-моему, когда бы добавляете тесты к существующему коду, это скорее дополнение, чем разработка с нуля. Да, объем этой работы может быть самым разным в зависимости от того, насколько велик объем кода, есть ли уже тесты и в каком они состоянии.
Категорически с вами не согласен, что нужно в «академическом» коде оставлять типичные ошибки вроде неправильной работы оператора присванивания при присваивании объекта самому себе. Тем более не стоит оправдывать их сферическими юнит-тестами в вакууме, которые вряд ли будут отдельно проверять, что присваивание объекта самому себе правильно работает, — хотя бы потому что в случае непрохождения более сложного теста поиск ошибки может занять довольно много времени. Наконец, если вы так легко относитесь к неопределенному поведению, компилятор может с одинаковым удовольствием доломать и ваш код, и юнит-тест, который вы написали к этому коду.
destruct_data() приведет к вызову m_data->~data(), в результате объект по адресу m_data будет разрушен, далее вызовется another.move_data_to(m_buffer), а это приведет к вызову m_data->move_to(address). Поскольку объект один и тот же, m_data содержит адрес только что разрушенного объекта. Вызов нестатического метода ранее разрушенного объекта приводит к неопределенному поведению (за редкими исключениями, например, случая, когда деструктор тривиальный, но тут, очевидно, не тот случай).
object& object::operator = (object const& another)
{
destruct_data(); // здесь нужно вызвать деструктор
m_data = another.move_data_to(m_buffer);
return *this;
}
Неправильно отработает, если попытаться присвоить объект самому себе (явно написать a=a или, что потом сложнее искать, использовать два указателя, привязанные к одному и тому же объекту).
Получается, необходимо обеспечить активной молниезащите питание даже лучшее, чем вычислительным мощностям. Иначе при отключившейся из-за отсутствия питания защите удар молнии может привести к необратимому выводу вычислительных мощностей из строя, в то время как пропадание питания вычислительных мощностей привело бы только к временному их отключению и потере несохраненных данных.
Этот #define предписывает препроцессору подставить вызовы memset(), которые компилятор сможет потом оптимизировать по месту.
Нет, пока такого решения у нас нет.
Не стоит характеризовать неопределенное поведение словами «ничего страшного не будет»? Вот пример того, как компиляторы используют неопределенное поведение для оптимизации и в результате «ломают» (на самом деле — доламывают изначально сломанный) код.
object& object::operator = (object const& another) { destruct_data(); // здесь нужно вызвать деструктор m_data = another.move_data_to(m_buffer); return *this; }Неправильно отработает, если попытаться присвоить объект самому себе (явно написать a=a или, что потом сложнее искать, использовать два указателя, привязанные к одному и тому же объекту).