All streams
Search
Write a publication
Pull to refresh
@ianzagread⁠-⁠only

User

Send message
> В-третьих, необходимым условием является так же и то, чтобы право собственности на недвижимость не было долевым — в противном случае вам мимо нотариуса не пройти.

Эммм… это с чегойто вдруг? Совместная собственность с разделением долей — допустим владельцы муж/жена 50:50 — прекрасно продается и покупается без всякого нотариуса. По крайней мере в бумажном виде.

> Обращаю ваше внимание на тонкость: общая совместная собственность (супругов) может быть продана без нотариуса, а вот общедолевая (допустим те же супруги, но явно по 1/2 доли) — уже нет.

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

Мы видимо рассматриваем проблему языка с разных колоколен. Я смотрю с сугубо практической стороны. Мне редко приходится на практике применять сложные языковые конструкции C++. Зато я видел тонны, просто тонны кода — как открытого так и в основном коммерческого — где разработчики имели очень, очень отдаленное представление как о культуре ООП так и о культуре С++ в частности. Когда std::auto_ptr<> является недостижимой вершиной а сокрытие данных в классе — назойливой мухой от которой все отмахиваются. Результат подхода легко предсказуем и всегда сбывается на практике. И потом вот это вот все «управляет атомной станцией». Некоторые вещи, кстати, почти без преувеличения.

А вы про какие-то ренжи… Я понимаю желание сделать язык лучше. Но в ситуации, когда львиная доля реальных конечных пользователей языка не в состоянии принять элементарные идиомы которым уже буквально четверть века — какие там нафик ренжи…
Ну на самом деле само по себе количество строк кода — это не самый важный критерий. При прочих равных я бы предпочел двадцать строк кода но тупого и понятного основной массе одной, к которой без поллитры даже не подходить.
> Ну т. е., помимо формулировки задачи, вы же понимаете,

Нет, товарищи, не понимаю и понимать не хочу. Категорически отказываюсь! Все геморрои всегда начинаются именно с этих слов. Нафик-нафик. Есть ТЗ — извольте в рамках договоренностей :)

> что тоже вызовет мягко говоря удивление у пользователей.

У пользователей всегда возникнет удивление. Как бы мы не старались. По другому и быть не может. А вот кому они выставят счет — это вопрос. Самый в общем то интересный и насущный. Если исполнитель будет «нувыпонимать» — ммм ну вы понимаете, кому его переадресует заказчик и каково будет исполнителю :)
> 0 Там вообще-то есть специальное уточнение: «Т. е. вернуть пару итераторов,...»

Не-не-не, господа, позвольте! Задача четко сформулирована в одном единственном предложении. Всякие «то-есть» или «ну может быть» и «было бы неплохо» — это уже за рамками ТЗ. Их можно учитывать а можно не учитывать. На усмотрение исполнителя.

Я сейчас, конечно же, не про итераторы и не про ренжи. Я сейчас сугубо про культуру постановки задачи :) Хотите, чтобы моторная лодка имела функцию вертикального взлета? Пожалуйста! Преодолевала звуковой барьер? Не вопрос! Укажите это явным образом в ТЗ. В противном случае она будет плавать но не более того.
> Ваш итератор не будет работать со стандартными алгоритмами.
> А еще ваш итератор удовлетворяет критериям только ForwardIterator, но не BidirectionalIterator или RandomAccessIterator, т. е. будет работать только с частью алгоритмов (когда вы сделаете его пригодным для использования с алгоритмами), а с некоторыми алгоритмами будет работать медленнее, чем можно было бы.

А он и не должен. Поскольку:

> Задача формулируется так. Есть класс, содержащий внутри коллекцию std::unique_ptr. Надо выпихнуть наружу возможность пользователям класса перебирать объекты, содержащиеся в коллекции, но без возможности изменить их.

Чему с моей точки зрения приведенный мною пример вполне удовлетворяет, разве нет?
> Вы не мешайте в одну кучу задачи «вывести в цикле» или сделать итератор/генератор. Результат конечно похож, но это всё же не одно и тоже. Эти абстракции как раз для того, чтобы решать проблемы, описанные для C кода в статье.

Конечно с этим я согласен! Задачи разные. Я лишь заметил, что когда в очередной раз приводят вроде как спасительный код на серебряной пуле он почему-то на деле оказывается совсем другого цвета. Ни чуть не лучше вот этого всего что плавает рядом.
> И в отличие от публичного наследования итератора такой код нельзя хакнуть и поменять элементы — а это между прочим условие задачи.

Не совсем если честно понял это замечание. Каким образом в приведенном мною случае вы сможете поменять возвращенный объект в коллекции :-?

PS: Естественно не прибегая к const_cast-у т.к. это грязный хак по-определению. Решается административными средствами в процессе code review «с последующим лишением премии».
> Кто вспомнит, когда в последний раз писал свои итераторы на голом C++? Я пожалуй в последний раз так делал никогда, только с использованием Boost.Iterator.

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

> Вот очень легко формулируемая задача, которая решается в пару строк на ranges, или в десяток строк на Boost.Iterator, а на голом C++ ее вообще обычно не решают никак, потому что сильно сложно.

Приведенный ниже код случайно не устроит отца русской демократии :-? Вот только что поняв задачу буквально накидал за 10ть минут:
#include <iostream>
#include <memory>
#include <list>

struct Item
{
    Item(const Item&) = delete;
    Item &operator = (Item&) = delete;

    explicit Item(int value) : value(value) {}

    int value;
};

inline std::ostream &operator << (std::ostream &os, const Item &item)
{
    return os << std::dec << item.value;
}

template <class T>
class Storage {
private :
    using PtrList = std::list<std::unique_ptr<T>>;

public :
    void addItem(std::unique_ptr<T> item)
    {
        items_.push_back(std::move(item));
    }

    class const_iterator {
    public :
        explicit const_iterator(typename PtrList::const_iterator it) : it_(it) {}

        const T& operator * () const noexcept
        {
            return *it_->get();
        }

        bool operator != (const const_iterator &src) const noexcept
        {
            return it_ != src.it_;
        }

        const_iterator operator ++ () noexcept
        {
            it_++;
            return *this;
        }

    private :
        typename PtrList::const_iterator it_;
    };

    const_iterator begin() const noexcept
    {
        return const_iterator(items_.begin());
    }

    const_iterator end() const noexcept
    {
        return const_iterator(items_.end());
    }

private :
    PtrList items_;
};

int main()
{
    Storage<Item> storage;

    for (int i = 0; i < 10; i++) {
        auto item = std::make_unique<Item>(i);
        storage.addItem(std::move(item));
    }

    for (const auto &item : storage) {
        std::cout << "Item " << item << std::endl;
    }

    return 0;
}

Читабельность кода конечно просто зашкаливает :)

То, что написато в оригинале на C поймет практически любой школьник. То, что вы привели на расте — они ни чем не лучше, чем на «C++20». И там и там одинаково хреново.
По фотографиям фабрик — ох не Тесла! А значит не феншуй и хайп не получится.
> Если бы не банальное человеческое любопытство, то так бы и сидели в пещерах высекая искру камень об камень.

Любопытство направленное на исследование до селе неизвестного и неизведанного — да, конечно. Любопытство направленное на исследование результатов чужих любопытств — так себе. На любителя.

Зачем ковыряться в чужих какахах еслиа можно сделать свои, тру правильные? Это куда веселее и интереснее. Пусть потом другие в них ковыряются а я займусь новыми.
> А статья — замечательная. От количество комментариев из серии «зачем» я тихо недоумеваю.

Просто для кого то это читается как в анекдоте "… а вокруг станки станки" и возникает резонный вопрос — нахуа этим ещё и дома заниматься? :)
Вот это вот все сверху написатое «на C++20» — это на самом деле отличная лакмусовая бумажка. Если вдруг оказывается, что от вас на собеседовании хотят чего-то в этом духе — это отличный повод задуматься «а надо ли оно мне?» и молча под шумок слинять.
Эмм… и что вы можете предложить более конструктивного по дороге на работу :-?
Даже если бы это был не перевод — шансы что 0 отнюдь не нулевые. Если мы конечно же имеем ввиду рабочие лейки.
Возиться с полями (пусть даже математическими) — это исследование неизвестного.

А вот возиться с фотоаппаратом (пусть даже крутым) — это исследование творения рук человеческих. Это не шаг вперед это топтание на месте. Ничего принципиально нового мы не узнали, правда? Да, аппарат. Да, прошивка. Да, можно разобрать по косточкам. Да, как-то работает. Да, статься получилась прикольная и перевод на уровне. Молодцы.

Но таки вопрос: а зачем собственно :-? Кроме прокачки скилов автора в реверсе я тоже не вижу никакого практического смысла в проделанной работе.
Читаю отзывы в теме почему-то автоматически всплывают в голове объявления о «финском конфискате» :)

Нет, я предполагаю, что в Яндексе сидят совсем не идиоты и если бы они действительно захотели начать продажи с целью продаж — они бы их начали по-другому. На сама модель «впарить хрень по дикой цене» — это как-то так себе.
А если я с семьей то мне, очевидно, нужна уже хотя бы трешка -> вот мы и подходим плавно к московским 100тыр/мес за аренду квартиры… :)

Information

Rating
Does not participate
Registered
Activity