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

> Возвращаются объекты разного типа?

Возвращается «Maybe a», это полиморфный тип. «a» там может быть любым типом, в зависимости от ситуации.

man abort

Тонко.

Два господина этому чаю.

> Зачем?

За тем что это решение задачи.

> Ну я о том же

Очевидно, если условия задачи требуют, чтобы объект был сконструирован, и одновременно с этим требуют, чтобы он сконструирован не был, то задача некорректна, т.к. решения не существует.

Тогда все понятно. И, пожалуй, не очень интересно.

Я знаю решение твоей проблемы! Просто перепиши свою функцию в continuation-passing-стиле - то есть добавь к ней параметром указатель на функцию принимающую объект типа, соответствующего результату данной и в случае успеха вызывай из этой функции функцию по переданному указателю с найденным элементом. Что-то типа:

void find (prop p, list l, my_fun_type f) {
 ...
 if (...) f(x); 
}

гы

>Понятие пустого объекта нет.

При желании ты можешь даже завести пустой типизированный объект, но в плюсах это будет чрезжопие с шаблонами

_________

//wfrr

Почему плохо вернуть индекс или -1 при отсутствии объекта?

Почему плохо вернуть индекс или -1 при отсутствии объекта?

Тем, что индекс имеет тип std::size_t?

Сделать его int как в Qt?

А метод должен вернуть std::string, ага?

делаем так:

[code]Res<T>{ T getValue() boolean isNull() }[/code]

и возвращаем его сколько влезет и вылезет.

_________

//wfrr

это одна из кривостей Qt-шных контейнерных классов, не надо её повторять.

Ну так это и есть boost::optional (Maybe, Option из других языков).

Почему кривость? (просто интересно.)

Может лучше SIZE_MAX?

А как ты себе представляешь отрицательный размер массива?

Лол, месье получает приз.

Никак :) Но с практической точки зрения что int, что std::size_t почти одно и тоже, например:

std::size_t idx = 0;
vec[idx-1]; // кто мне здесь даст по рукам до того как случиться что-то очень плохое?

P.S. Maybe вещь годная...

> с практической точки зрения что int, что std::size_t почти одно и тоже, например:

С практической точки зрения, ты путаешь _размер_ массива и _смещение_ в нем.

sizeof(int) = sizeof(size_t)?

a[2147483647+10]

(int)2147483647+10?

Возможно, поясни мысль.

> sizeof(int) = sizeof(size_t)?

да

(int)2147483647+10?

-2147483639

К чему все это?

> sizeof(int) = sizeof(size_t)?

да

необязательно.

Поставь, наконец, задачу формально! Без слов «хочется»

В любом случае: хоть unsigned int более правильно для размеров и индексов, но жизнь это не упрощает, а ограничения создает... Unsigned int в целом (и std::size_t в частности) не нужен.

Здесь, похоже, решение уже подсказали, но еще раз: в функцию, которая занимается поиском, передавать callback, который будет вызван, если поиск удался, и не будет вызван, если поиск не удался. Проблема с временем жизни результатов поиска решается автоматически: результат передается в callback на стеке, и жив, пока callback-функция не вернет управление.

typedef void (*TOnSearchSuccess)(void* userdata, const SearchResult& result);

void Search(arguments, TOnSearchResult cb, void* userdata);

но жизнь это не упрощает, а ограничения создает...

Итераторы ещё лучше.

std::size_t

Он нужен, т.к. позволяет писать код не привязанный к конкретной платформе.

Чем это лучше константного итератора кроме уродования кода?

В любом случае: хоть unsigned int более правильно для размеров и индексов, но жизнь это не упрощает, а ограничения создает...

int тоже создаёт ограничения - он позволяет индексировать только часть массива (для справки, на amd64, sizeof(int) == 4, т.е. массив ограничен 2^31 эелментами).

> int тоже создаёт ограничения - он позволяет индексировать только часть массива (для справки, на amd64, sizeof(int) == 4, т.е. массив ограничен 2^31 эелментами).

Я, наверное, не совсем понятно выразился: я не против std::size_t как yet another fucking pseudonym, я против того, что оно unsigned. Хотя про «на amd64, sizeof(int) == 4» не знал, спасибо. Конечно, признаю, в Qt косяк, но в stl тоже косяк (с std::size_t как unsigned).

в stl тоже косяк (с std::size_t как unsigned)

В STL используются итераторы, и знаковость std::size_t там не нужна. Кстати, я как-то совсем забыл про std::ssize_t, он как-раз знаковый.

Семантически возвращение «пустого итератора» эквивалентно возвращению пустого объекта, т.ч. в определенном смысле это противоречит условию (так или иначе появляется понятие «пустого объекта», пусть даже объекта другого типа). Затем, кто-то должен будет управлять временем жизни итератора. Что касается «уродования кода» - не вполне ясно, что Вы имеете в виду. В зависимости от ситуации и используемых библиотек можно сделать лаконичнее, я просто схему привожу. А вообще - man iteratee, http://www.haskell.org/haskellwiki/Enumerator_and_iteratee

Семантически возвращение «пустого итератора» эквивалентно возвращению пустого объекта

Не пустого итератора, на итератора на элемент, следущий за последним, так что эквивалентности нет.

По смыслу это эквивалентные вещи. Что за «последний элемент», откуда он возьмется? Если «последнего элемента» нет, - чему равен итератор, следующий за ним? Так или иначе, вам нужно будет ввести некоторое искусственное значение - в данном случае для итератора.

Что более важно, до каких пор ваш итератор должен оставаться валидным? В STL итераторы остаются валидными, пока жив контейнер, и плюс еще известные ограничения в зависимости от типа контейнера. В условии об этом ничего не сказано. Соответственно, решение, основанное на том, чтобы возвращать итератор из контейнера STL, будет так или иначе ограничивать реализацию поиска: в общем случае контейнер нельзя будет изменять, пока клиент не воспользуется итератором, который ему вернули. Эти детали протокола невозможно учесть в API. Напротив, идиома iteratee полностью свободна от всевозможных «дополнительных соглашений».