Не нужно никаких проверок — достаточно случайно перемешать линейный список участников, далее первый дарит второму, второй — третьему, ..., последний — первому. Ситуации дарения самому себе (при N>1) и отсутствия дарителя исключены.
Спасибо, прочел. Не лишено смысла, но пара ссылок на документацию — это явно не та поддержка. которая требуется годами. В целом, аргументация "почему у нас подписочная модель оплаты" у PVS очень слабая (поддержка, добавление новых правил, ...) и искусственная, призванная заменить настоящую мотивацию "нам надо больше денег". Поэтому дальше обсуждать ее, наверное, бесполезно.
Казалось бы, если продукт содержит логические бомбы и с ним нельзя работать без постоянной поддержки, то его качество вызывает большие сомнения и покупать его себе дороже.
При этом мой небольшой опыт работы с PVS Studio говорит, что это вполне нормальный подукт, которым можно пользоваться без посторонней помощи. Отсюда вопрос — что именно входит в ту поддержку, без которой не обойтись, какие операции, какая помощь? Может, я пропустил какие-то важные ее возможности, с которыми от студии был бы гораздо больший профит?
Знаете, написать приложеньку для такого трюка стоит по времени гораздо дешевле, чем стоимость годовой лицензии на человека (в составе команды из 10 человек). Впрочем, в моей, например, компании, даже и в git это можно было бы залить без проблем. Но совесть. Поэтому сидим без лицензии (один год попользовались, профит меньше ожидаемого, продлевать не стали).
По-моему, вашу — действительно очень здравую и хорошую — задумку с бесплатным использованием лучше продвигать и обсуждать в терминах совести, а не игры в кошки-мышки.
Справедливости ради, 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) и отсутствия дарителя исключены.
Спасибо, прочел. Не лишено смысла, но пара ссылок на документацию — это явно не та поддержка. которая требуется годами. В целом, аргументация "почему у нас подписочная модель оплаты" у PVS очень слабая (поддержка, добавление новых правил, ...) и искусственная, призванная заменить настоящую мотивацию "нам надо больше денег". Поэтому дальше обсуждать ее, наверное, бесполезно.
Казалось бы, если продукт содержит логические бомбы и с ним нельзя работать без постоянной поддержки, то его качество вызывает большие сомнения и покупать его себе дороже.
При этом мой небольшой опыт работы с PVS Studio говорит, что это вполне нормальный подукт, которым можно пользоваться без посторонней помощи. Отсюда вопрос — что именно входит в ту поддержку, без которой не обойтись, какие операции, какая помощь? Может, я пропустил какие-то важные ее возможности, с которыми от студии был бы гораздо больший профит?
Знаете, написать приложеньку для такого трюка стоит по времени гораздо дешевле, чем стоимость годовой лицензии на человека (в составе команды из 10 человек). Впрочем, в моей, например, компании, даже и в git это можно было бы залить без проблем. Но совесть. Поэтому сидим без лицензии (один год попользовались, профит меньше ожидаемого, продлевать не стали).
По-моему, вашу — действительно очень здравую и хорошую — задумку с бесплатным использованием лучше продвигать и обсуждать в терминах совести, а не игры в кошки-мышки.
Справедливости ради, Mail.ru уже от этого отучилось. Свой процесс найма они неплохо отдебажили.
Подобные проколы — личный косяк HR'а, и судить по ним о компании в целом, наверное, не стоит. Хотя неприятно, конечно, особенно если ты время потратил, приехал и выяснилось, что на вакансию обязательно нужен навык, которого у тебя отродясь не было и в резюме не указано.
Rvalue ссылки имеют смысл, когда объекты передаются по значению (в C# это была бы структура). Это иная парадигма, и там нет проблемы нулевых указателей. Как и при передаче интерфейсов по указателю нет проблемы rvalue ссылок, т.к. указатели тривиально копируются.
Кстати, парадигма передачи объектов по значению, если она реализуется последовательно, — тоже, пожалуй, один из ответов на проблему null.
Вопрос константности в данном случае продиктован требованиями функции. Для не изменяющей объект функции ссылка, конечно, будет константной.
В C++ есть довольно простой способ не писать часть лишних проверок — передача интерфейсов в функцию по ссылке. Тогда внутри самой функции и вызываемых из нее проверки на NULL не нужны (синтаксически), а вызывающему коду приходится явно разыменовать указатель, что для любого программиста красная тряпка и повод железно убедиться, что разыменовываешь не null:
Недостатки:
Пожалуй, в описанном сценарии (передача параметров в функцию) это аналог вашего варианта 2 (
NotNull). По-моему, вы его несколько недооценили. Конечно, для полностью нового кода писать вездеNotNull(или&) — некоторая морока, но зато на рабочей кодобазе можно потихоньку очищать код, добавляяNotNullснизу вверх, пока указатели с возможно нулевым значением не останутся только на инфраструктурном уровне в местах, где это объективно необходимо.