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

Сгенерировать объект с заданными свойствами?

Объект возвращать через параметр, а результат функции - код ошибки?

> Что делать, если функция не нашла объект?
Я бы вернул null.

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

Объект возвращать через параметр, а результат функции - код ошибки

Или наоборот в параметры ввести bool &ok.

Тогда исключение. А как еще?

Вот и я думаю

дело в том, что объект в невалидном состоянии находиться не может. в этом его удоство.

ИМХО, лучше через указатель.

Использовать Option из Scala (оно же монада Maybe из Haskell)

someList find {x => …} getOrElse {…}

ссылку на объект, null.

Добавить в аргументы функции указатель/ссылку «ok»?

> ИМХО, лучше через указатель.

А кто его потом будет грохать. Не люблю я их

скала это совсем другой разговор. но у меня С++

А что возращать?

если ref, как в С++ - то какой объект должен быть первоначально

если возращать указатель - то выше

Ничего не мешает реализовать то же самое на C++. Конечно, паттерн-матчинга не будет, но и без него обойтись можно.

Да, не подумал. Мусор разве что, раз дефолтного объекта нет.

А кто его потом будет грохать

Ну, возвращай «умный» указатель.

> А кто его потом будет грохать.
В смысле грохать?

А кто его потом будет грохать

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

Правильно было бы бросить исключение. Некоторые доказывают, что лучше вернуть код ошибки, но это - не C++-way, а те, кто так делают в C++ - латентные сишники.

Создать отдельно пустой объект? Если там конечно полиморфизЪм...

Возвращай че попало (хоть первый элемент), а результат (найден/ненайден) через out-параметр.

>Правильно было бы бросить исключение

А это точно идеологически правильно использовать исключения в таких случаях? Ведь ненайденый элемент — штатная ситуация.

> Ничего не мешает реализовать то же самое на C++. Конечно, паттерн-матчинга не будет, но и без него обойтись можно.

Ой блин. Это своего городить надо много

> Да, не подумал. Мусор разве что, раз дефолтного объекта нет.

ОБъект должен быть сконструирован - иначае как на него ссылку получить

> В смысле грохать?

Этот объект

> Ну, возвращай «умный» указатель.

Через стек передача оптимальнее и красивее

В чем тогда состоит вопрос удаления?

Да. Тут ты прав. Но потом указатель надо будет разыменовать. Не хочу

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

> Некоторые доказывают, что лучше вернуть код ошибки, но это - не C++-way, а те, кто так делают в C++ - латентные сишники.

в find и contains это действительно не true C++ way

ибо отсутсвие объекта - это не ошибка

> Возвращай че попало (хоть первый элемент)

а если его нет

> Создать отдельно пустой объект? Если там конечно полиморфизЪм...

Возращаем объект класса A. Он не может быть пустым - он не может об этом сигнализировать

Я однозначно за Option. Т.е. возвращать либо Some(object), либо None, None — синглтон.

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

Ага. Это красиво, но сложно.

Да и хранилище внутри должно будет жить с динамическим списком

Да. Имел ввиду указатель. Почему?

free? Что-то я не понимаю. Зачем null уничтожать?

void *p = find_object(by_some_param);

if (p) {
// Тут мы с объектом что-то замутим основываясь на его типе.
// В плюсах же можно динамически определить тип?
free(p);
}

Как-то так? Или что нужно?

> Да. Имел ввиду указатель. Почему?

Не хочу

Можно возвращать не сам объект, а специальную обертку над ним, со свойством valid и методом для получения самого объекта (или оператор преобразования типа перегрузить)

> Как-то так? Или что нужно?

А если при мутении вылетит exception?

> Можно возвращать не сам объект, а специальную обертку над ним

В обертке будет жить указатель

Ну и что? Если вызван метод getValue() а результат невалидный — прервать программу ассертом.

> Ну и что? Если вызван метод getValue() а результат невалидный — прервать программу ассертом.

Не красиво

ЗЫ: ну проблему я решил так же, но это не красиво

Ну ты упрямый, однако :)
Либо спец. итератор по типу std::string::npos, либо object() с дефолтным конструктором, либо сделать нормальный контроль ошибок по типу того, как это красиво сделано в glib, либо следовать пути C++ и исключениям.
Но сам подумай, если результат поиска «не найден» не является ошибкой, это означает, что при вызове функции этот объект со 100%-ой вероятностью должен быть найден, откуда противоречие и это либо ошибка, либо исключение, а значит надо контролировать без выкрутасов.

> если результат поиска «не найден» не является ошибкой, это означает, что при вызове функции этот объект со 100%-ой вероятностью должен быть найден, откуда противоречие

не понял логику

Еще уродливое решение: не возвращать ничего, компилятор будет ругаться, но проглотит.

> Еще уродливое решение: не возвращать ничего, компилятор будет ругаться, но проглотит.

И в runtime упадет?

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

нет. это штатный случай

> Возращаем объект класса A. Он не может быть пустым - он не может об этом сигнализировать

Ну сделай новый класс с одним полем Bool и пусть твой А его наследует. Если в этом поле 1 - это хороший объект, если там 0 - это аналог Nothing, возвращаем объект с нулем. Хотя вообще непонятно - какой смыслизбегать указателей, если в любомслучае тебе придется вернуть указатель7 Просто делаешь некоторый константный объект класса А и он будет null-ом.

А как есть? Рот использовать не хочу.