Это вы такое процентное соотношение придумали, зачем мне его понимать? Я считаю, что нормальный компилятор побольше может. По крайней избавит от получения висячего указателя на ровном месте.
чувак, ты нормальнывй вообще?
99,(9) данных известны только в рантайме.
Сложности с отслеживанием нити разговора?
да. мне сложно отслеживать направление твоей мысли по односложным ответам.
у меня создалось впечатление,
что направление твоей мысли - задом-на-перед.
я предлагаю использовать ссылки там,
где ожидается работа с реальным объектом
и
вообще не иметь проблем с невалидными указателями.
ты же считаешь вещь полезной на случай,
если найдется такой идиот, который зачем то сначала решит использовать указатель,
а затем нужно ему помочь не налажать с nullptr
Что тогда предлагаете делать? Уповать на то, что другие догадаются, что автор задумал поле непустым, хотя там обычный указатель? Или комментарий для поля писать: "The m_parent must be not_null."?
да.
я уповаю на то, что парень которого я взял в команду
догадается как правильно работать с нашей кодовой базой.
я уповаю на то, что нормальный здравомыслящий человек без труда догадается,
что ежели по задумке у ребенка всегда должен быть родитель,
то родитель никак не может быть nullptr.
и для этого даже в код смотреть не нужно.
в чем ущербность not_nul подхода?
глупо и бессмысленно пытаться делать защиту от идиотов.
Мда... не зря я недолюбливаю майкрософтовский компилятор
. Попробуйте собрать этот код в gcc или clang.
суть в том, что на практике в обоих случаях (и с ссылками, и с указателями) можно ничайно допустить ошибку.
суть в том, что есть простой способ превентивно не позволить программисту допустить ошибку.
способ простой и кросс-платформенный.
просто используй ссылки там,
где по смыслу нужно работать с реальным объектом,
и если объект не должен быть временным - просто запрети временные.
обратил внимание: звучит как Капитанство?
Ага, каждый раз писать лабуду типа "static_assert(!::std::is_rvalue_reference<parent&&>::value, "temporary objects prohibited"); это "просто"
.
да. каждый раз.
если ты хочешь писать грамотный, надежный, качественный код.
вот пример из моего реального кода.
он очень простенький, но иллюстрирует идею.
namespace detail
{
template<class s, dfor_lvalue_string(s&&)>
constexpr decltype(auto) c_str(s&& text) noexcept
{ return text.c_str(); }
template<class s, dfor_array_of_symbols(s)>
constexpr decltype(auto) c_str(const s& arr) noexcept
{ return arr; }
template<class s, dfor_pointer_to_symbol(s)>
constexpr auto c_str(const s& ptr) noexcept -> const auto*
{
assert(ptr);
return ptr;
}
} //namespace detail
обрати внимание: тут не статик_ассерт,
здесь концепт, основанный на SFINAE
если бы чувак смог ничайно запихать временную строку,
то в результате он бы получил указатель на уже протухший объект.
однако концепт dfor_lvalue_string исключает функцию из компиляции
если ей передать rvalue. ничайная ошибка полностью исключена.
и вот подобные концепты я использую каждый раз,
когда у функции есть какие либо важные ограничения.
это не просто увеличивает читабельность кода.
это позволяет исключить саму возможность ошибки.
концепты позволяют недопустить саму возможность возникновения ошибки.
а не пытаются как твой not_null пытаться бороться с последствиями идиотизма.
По публичному интерфейсу:
C++ (Qt)
struct child
{
template<class parent>
child(parent&& mother, parent&& father) noexcept;
template<class parent>
void setParents(parent&& mother, parent&& father) noexcept;
...
};
пользователи класса подумают, что могут передавать объекты в любом виде (по значению, по lvalue ссылке, по rvalue ссылке)
нет, не подумают.
если, конечно, у пользователей нет шизофрении,
и они не больны клиническим идиотизмом.
обычно, психически здоровые пользователи класса child знают,
что это за класс, и зачем он нужен.
они осознают, что они пытаются сделать.
вот нафига вообще может понадобится передавать ребенку временный объект родителя???
как такое вообще может прийти в голову?
от ничайных ошибок защитит статик-ассерт.
Напрямую коррелирует. Вариант с gsl::not_null вы, похоже, так и не пробовали. Даже интересно, как майкрософтовский компилятор там себя поведёт.
не пробовал.
просто глядя на код, я предполагаю, что никакой разницы нет.
однако запустить его и опробовать на деле у меня не получилось.
https://rextester.com/DPGZ73051а поскольку, сейчас мне очевидно, что этот инструмент не нужнен,
то я не стал утруждать себя думками как заставить его работать.
но ты можешь сам продемонстрировать:
предоставить код и ссылку на он-лайн компилятор.
онлайн rextester умеет жоссии, шланг, и студийный каэль.
Чтобы долго не объяснять, что такое "
абстрактная фабрика". Поэтому и написал "такую абстрактную фабрику, как например
QItemEditorFactory". Не именно её, а "такую как", чтобы был наглядный пример перед глазами. Не думал, что с пониманием этого предложения могут возникнуть сложности.
человек, ты идею то вразумел, нет?
тебе не нужен not_null, что бы гарантировать, что выданнный сторонним апи объект валидный.
просто получи его на руки.
тут же проверь валидность.
а дальше используй по обычной схеме: где нужен объект, туда передаём ссылку.
И ФСЁЁЁ.
казадлось бы, и причем тут какие то абстрактные фабрики?
