Не нужно никаких проверок — достаточно случайно перемешать линейный список участников, далее первый дарит второму, второй — третьему, ..., последний — первому. Ситуации дарения самому себе (при N>1) и отсутствия дарителя исключены.
Справедливости ради, Mail.ru уже от этого отучилось. Свой процесс найма они неплохо отдебажили.
Подобные проколы — личный косяк HR'а, и судить по ним о компании в целом, наверное, не стоит. Хотя неприятно, конечно, особенно если ты время потратил, приехал и выяснилось, что на вакансию обязательно нужен навык, которого у тебя отродясь не было и в резюме не указано.
Rvalue ссылки имеют смысл, когда объекты передаются по значению (в C# это была бы структура). Это иная парадигма, и там нет проблемы нулевых указателей. Как и при передаче интерфейсов по указателю нет проблемы rvalue ссылок, т.к. указатели тривиально копируются.
Кстати, парадигма передачи объектов по значению, если она реализуется последовательно, — тоже, пожалуй, один из ответов на проблему null.
Вопрос константности в данном случае продиктован требованиями функции. Для не изменяющей объект функции ссылка, конечно, будет константной.
В C++ есть довольно простой способ не писать часть лишних проверок — передача интерфейсов в функцию по ссылке. Тогда внутри самой функции и вызываемых из нее проверки на NULL не нужны (синтаксически), а вызывающему коду приходится явно разыменовать указатель, что для любого программиста красная тряпка и повод железно убедиться, что разыменовываешь не null:
void StartVehicle( Vehicle& object )
{
object.CloseDoors();
RunEngine(object); // void RunEngine( Vehicle& object );
}
void CallerCode()
{
Vehicle* object = FindObjectSomewhere();
if(object) // Проверка только в момент фактического появления неопределенности
{
StartVehicle(*object);
}
}
Недостатки:
Если нужно хранить объект, то это не всегда возможно сделать в ссылке (например, при отложенной инициализации)
Не для всех привычно использовать перегруженные интерфейсы через ссылку.
Это C++.
Пожалуй, в описанном сценарии (передача параметров в функцию) это аналог вашего варианта 2 (NotNull). По-моему, вы его несколько недооценили. Конечно, для полностью нового кода писать везде NotNull (или &) — некоторая морока, но зато на рабочей кодобазе можно потихоньку очищать код, добавляя NotNull снизу вверх, пока указатели с возможно нулевым значением не останутся только на инфраструктурном уровне в местах, где это объективно необходимо.
Не нужно никаких проверок — достаточно случайно перемешать линейный список участников, далее первый дарит второму, второй — третьему, ..., последний — первому. Ситуации дарения самому себе (при N>1) и отсутствия дарителя исключены.
Справедливости ради, Mail.ru уже от этого отучилось. Свой процесс найма они неплохо отдебажили.
Подобные проколы — личный косяк HR'а, и судить по ним о компании в целом, наверное, не стоит. Хотя неприятно, конечно, особенно если ты время потратил, приехал и выяснилось, что на вакансию обязательно нужен навык, которого у тебя отродясь не было и в резюме не указано.
Rvalue ссылки имеют смысл, когда объекты передаются по значению (в C# это была бы структура). Это иная парадигма, и там нет проблемы нулевых указателей. Как и при передаче интерфейсов по указателю нет проблемы rvalue ссылок, т.к. указатели тривиально копируются.
Кстати, парадигма передачи объектов по значению, если она реализуется последовательно, — тоже, пожалуй, один из ответов на проблему null.
Вопрос константности в данном случае продиктован требованиями функции. Для не изменяющей объект функции ссылка, конечно, будет константной.
В C++ есть довольно простой способ не писать часть лишних проверок — передача интерфейсов в функцию по ссылке. Тогда внутри самой функции и вызываемых из нее проверки на NULL не нужны (синтаксически), а вызывающему коду приходится явно разыменовать указатель, что для любого программиста красная тряпка и повод железно убедиться, что разыменовываешь не null:
Недостатки:
Пожалуй, в описанном сценарии (передача параметров в функцию) это аналог вашего варианта 2 (
NotNull). По-моему, вы его несколько недооценили. Конечно, для полностью нового кода писать вездеNotNull(или&) — некоторая морока, но зато на рабочей кодобазе можно потихоньку очищать код, добавляяNotNullснизу вверх, пока указатели с возможно нулевым значением не останутся только на инфраструктурном уровне в местах, где это объективно необходимо.