Задачка для ума. Из С++, но язык значения не имеет - главное типизация

В динамическом языке не исключается такая ситуация, что «объект другого типа» изначально был в коллекции, поэтому по нему сложно будет понять, это мы его нашли или это нам его вернули в случае неудачного поиска.

> Аргумент: так деревянее и быстрее.

не правда

> указатели ЗЛО

ЗЛО у тебя между ног.

> это нам его вернули в случае неудачного поиска.

Ну там можно придумать

>> указатели ЗЛО

ЗЛО у тебя между ног.

А мне говорят совсем другое

Да, в том же смолтоке есть методы типа #at:ifAbsent, которым вторым аргументом передаётся блок кода на случай фейла.

> А мне говорят совсем другое

Что, говорят у тебя там УКАЗАТЕЛЬ?

> Что, говорят у тебя там УКАЗАТЕЛЬ?

У меня там как минимум ИНДИКАТОР

язык значения не имеет

func :: [a]->Maybe a

> В этом и весь ужас, что человек написал фрее
В чем ужас? В том что я плюсов не знаю? Считайте это псевдокодом.

Если я правильно понял, то мутение это приведение типов. Ну если исключение там это значит что тип не поддерживается, и это ошибка логики где-то в коде.

любое действие между конструирование/деструктурирвоание и очистой памяти может привезти к утечке ресурсов

errno = EOBJNOTFOUND;
return false;

Возвращать смарт-указатель, который может быть null. Или вообще отключить исключения в опциях компилятора. Ссылками никогда не пользоваться, это ненужное костыльное говно которое было внесено чтобы заставить работать operator[] и унарный operator*.

ссылки - это хорошо, если умело

>ссылки - это хорошо, если умело

Ссылка не может быть null, ссылку нельзя переназаначать другим объектам. Итого, ссылка - это ненужный кастрированный варинт указателя.

ну это в ущербных крестах :)

Усложню условия - не пользоваться указателем

Возвращать объект по значению - плохо. В некоторых языках и возможности такой нет. Так что пусть будет пойнтер.

> Ссылка не может быть null, ссылку нельзя переназаначать другим объектам.

И это хорошо

Итого, ссылка - это ненужный кастрированный варинт указателя.

С соврешенно другой семантикой

> Возвращать объект по значению - плохо.

Почему?

Да не нужен указатель, есть другие возможности. См. выше.

Потому что неясно, пустой он или нет. С таким же успехом можно вернуть код ошибки.

Оставь им их заблуждения.

В данном случае да

>ну это в ущербных крестах :)

В других языках проблем топикстартера не бывает. Возвращают null или nil там какой-нибудь, если вернуть нечего. Ну в хацкеле оборачивают тип в Maybe, да.

вообще это перезагон на фоне шаблона на шаблоне на шаблоне на шаблоне

> Возвращают null или nil там какой-нибудь, если вернуть нечего.

И улетаем в segmentation fault

>> Ссылка не может быть null, ссылку нельзя переназаначать другим объектам.

И это хорошо

С такой логикой и оператор деления это зло, т.к в знаменателе может быть зеро.

> С такой логикой и оператор деления это зло, т.к в знаменателе может быть зеро.

Оно не упадет. Да и деления реже возникает, чем обращение к объекту.

А писать код check_pointer(obj_p)->methosd() - зло

>> Возвращают null или nil там какой-нибудь, если вернуть нечего.

И улетаем в segmentation fault

А там в большинстве случаев и делать нечего кроме как умереть. Вот нужен тебе объект типа mutex. А ОС взяла и не дала его тебе в силу сочетания каких-то внутренних факторов, вернула null. Вариантов дальнейшего успешного продолжения работы без этого мутекса нет. Что делать? Терминатить процесс, чего еще.

Да не нужен указатель, есть другие возможности

References? Суть та же. Только мне сильно не нравится в C++, что references слишком похожи на обычные переменные. Вроде для удобства, но резко снижается ясность кода.

Ссылка в данном случае не подходит, потому что объекта может и не быть.
Ясность кода - это химера.

Бросить исключение - не хочется.

А это и нельзя в общем случае.

Вопрос в том, является ли _нормальной_ ситуация, когда не найден объект. Если да, то точно нельзя исключение. Если нет, то может быть и можно, смотря по обстоятельствам.

вернуть -1 или null

Ясность кода - это химера.

Для компилятора - возможно. Но не для программиста, которому этот код придется менять дет через пять :)

> Вариантов дальнейшего успешного продолжения работы без этого мутекса нет. Что делать? Терминатить процесс, чего еще.

Шикарно. и весь http сервер падает, да еще с хер знает какой ошибкой

Ссылка в данном случае не подходит, потому что объекта может и не быть.

Значит, остается один разумный вариант: pointer.

С++ это постоянная борьба с возможностью отстрелить себе ногу

В большинстве случаев абсолютно пофиг, ссылка ли это или переменная. Если код в порядке.

С++ это постоянная борьба с возможностью отстрелить себе ногу

Это правда. Так что нефиг.

Я уже выше писал: boost::optional.

Слухи об этом сильно преувеличены.

boost::optional

Ага, приплыли :)

А что не так?

возвратить null. Перегибать с исключениями не стоит, исключение можно выкинуть, если дальнейшее выполнение кода функции вызвавшей функцию поиска бессмысленно, т.е. функциональность остального кода метода не допускает отсутствие искомого объекта.
Это типичный совет в любой книге с названием «Effective <подставить свое>».

>и весь http сервер падает, да еще с хер знает какой ошибкой

Если сделать плюсавый враппер под этот мутекс, то данная ошибка превратится в исключение т.к из конструктора просигнализировать об ошибке можно только исключением.

А что не так?

Boost.

Но ведь указатели ИНДИКАТОР^WЗЛО!

Ну пилять, не нравится буст - напиши свое, делается на коленке за пять минут.

Слухи об этом сильно преувеличены.

Зато как пугают.

Если умеешь писать правильно - сложно отстрелить. правда вчера два часа втыкал в сообщение: у объекта а, который не является классом, пытаются вызвать метод

class A {...}; class B{ bool isNull(); }; class C {...};

void f(C c)
{
  B a( A(c) );
  if( a.isNull() )
    ...
  ...
}

А я вам о чем говорю?