Nullable<Point3d>Спасибо.
а в C# не допускается присвоить значение null;допускается
Gem.Point3d?равнозначно этому
Nullable<Point3d>
Александр, Вы уверены, что эта конструкция способна вернуть null? :)Код - C# [Выбрать]
private Nullable<Point3d> getPoint3D() { try { return Point3d.Origin; } catch { return null; } }
ЭтоЭто так, но первый вариант гораздо компактнее и на практике именно он обычно используется.Код - C# [Выбрать]равнозначно этому
Gem.Point3d?Код - C# [Выбрать]
Nullable<Point3d>
Александр, Вы уверены, что эта конструкция способна вернуть null?Я показывал пример, чтобы автор вопроса понял суть использования. Мой пример всегда будет возвращать точку начала координат )) Как там будет делать автор - я не в курсе
Это так, но первый вариант гораздо компактнее и на практике именно он обычно используется.Дык само собой разумеющееся )) И я так-же и пишу "компактнее", но в данном ответе написал так все по той же причине - для более полного понимания
Кстати, вместо Nullable часто гораздо удобнее использовать метод с выходным параметромНу насчет удобства это вопрос конечно субъективный, но ИХМО выходные параметры это аттавизм - nullable (или если брать функциональных подход, то опциональный) параметр - это гораздо более гибкий подход (например в отличие от примера выше его можно и передать любому "адресату" с отсутствующим значением) + опять-таки выходной параметр очень плохо дружит с параллельными вызывами, да и просто с нелинейными алгоритмами. В общем я бы не рекомендовал их использовать в принципе, я например, если таковые есть в "сторонних" api - почти всегда "заворачиваю" их в "опциональную" обертку.
И есть маленькое преимущество по ставнению с Nullable - я не создаю новый тип данных и значит не надо писать ".Value"Ваше решение конечно "креативное", но с моей точки зрения "опасное". Про опциональные типы (и как их подвид Nullable) - изначальная логика их в том, что передавать их надо в "первозданном" виде до "развертывания", а когда необходимо сделать проверку на наличие значения, там практически в 100% случаев идет ветвление программы (типа есть у нас значение или нет). Просто в функциональных языках (откуда собственно и "растут ноги" данного механизма), на данный тип всегда есть шаблон проверки, а .Value конечно применять не надо (это просто C# нормально с ними работать не умеет - формально вроде типы такие есть, а обертки для них не предусмотрено концепцией).