> В-третьих, необходимым условием является так же и то, чтобы право собственности на недвижимость не было долевым — в противном случае вам мимо нотариуса не пройти.
Эммм… это с чегойто вдруг? Совместная собственность с разделением долей — допустим владельцы муж/жена 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ть минут:
То, что написато в оригинале на C поймет практически любой школьник. То, что вы привели на расте — они ни чем не лучше, чем на «C++20». И там и там одинаково хреново.
> Если бы не банальное человеческое любопытство, то так бы и сидели в пещерах высекая искру камень об камень.
Любопытство направленное на исследование до селе неизвестного и неизведанного — да, конечно. Любопытство направленное на исследование результатов чужих любопытств — так себе. На любителя.
Зачем ковыряться в чужих какахах еслиа можно сделать свои, тру правильные? Это куда веселее и интереснее. Пусть потом другие в них ковыряются а я займусь новыми.
Вот это вот все сверху написатое «на C++20» — это на самом деле отличная лакмусовая бумажка. Если вдруг оказывается, что от вас на собеседовании хотят чего-то в этом духе — это отличный повод задуматься «а надо ли оно мне?» и молча под шумок слинять.
Возиться с полями (пусть даже математическими) — это исследование неизвестного.
А вот возиться с фотоаппаратом (пусть даже крутым) — это исследование творения рук человеческих. Это не шаг вперед это топтание на месте. Ничего принципиально нового мы не узнали, правда? Да, аппарат. Да, прошивка. Да, можно разобрать по косточкам. Да, как-то работает. Да, статься получилась прикольная и перевод на уровне. Молодцы.
Но таки вопрос: а зачем собственно :-? Кроме прокачки скилов автора в реверсе я тоже не вижу никакого практического смысла в проделанной работе.
Читаю отзывы в теме почему-то автоматически всплывают в голове объявления о «финском конфискате» :)
Нет, я предполагаю, что в Яндексе сидят совсем не идиоты и если бы они действительно захотели начать продажи с целью продаж — они бы их начали по-другому. На сама модель «впарить хрень по дикой цене» — это как-то так себе.
Эммм… это с чегойто вдруг? Совместная собственность с разделением долей — допустим владельцы муж/жена 50:50 — прекрасно продается и покупается без всякого нотариуса. По крайней мере в бумажном виде.
> Обращаю ваше внимание на тонкость: общая совместная собственность (супругов) может быть продана без нотариуса, а вот общедолевая (допустим те же супруги, но явно по 1/2 доли) — уже нет.
Хм. Ну может быть. Хотя вопрос конечно интересный. Не уверен — нужно посмотреть.
Мы видимо рассматриваем проблему языка с разных колоколен. Я смотрю с сугубо практической стороны. Мне редко приходится на практике применять сложные языковые конструкции C++. Зато я видел тонны, просто тонны кода — как открытого так и в основном коммерческого — где разработчики имели очень, очень отдаленное представление как о культуре ООП так и о культуре С++ в частности. Когда std::auto_ptr<> является недостижимой вершиной а сокрытие данных в классе — назойливой мухой от которой все отмахиваются. Результат подхода легко предсказуем и всегда сбывается на практике. И потом вот это вот все «управляет атомной станцией». Некоторые вещи, кстати, почти без преувеличения.
А вы про какие-то ренжи… Я понимаю желание сделать язык лучше. Но в ситуации, когда львиная доля реальных конечных пользователей языка не в состоянии принять элементарные идиомы которым уже буквально четверть века — какие там нафик ренжи…
Нет, товарищи, не понимаю и понимать не хочу. Категорически отказываюсь! Все геморрои всегда начинаются именно с этих слов. Нафик-нафик. Есть ТЗ — извольте в рамках договоренностей :)
> что тоже вызовет мягко говоря удивление у пользователей.
У пользователей всегда возникнет удивление. Как бы мы не старались. По другому и быть не может. А вот кому они выставят счет — это вопрос. Самый в общем то интересный и насущный. Если исполнитель будет «нувыпонимать» — ммм ну вы понимаете, кому его переадресует заказчик и каково будет исполнителю :)
Не-не-не, господа, позвольте! Задача четко сформулирована в одном единственном предложении. Всякие «то-есть» или «ну может быть» и «было бы неплохо» — это уже за рамками ТЗ. Их можно учитывать а можно не учитывать. На усмотрение исполнителя.
Я сейчас, конечно же, не про итераторы и не про ренжи. Я сейчас сугубо про культуру постановки задачи :) Хотите, чтобы моторная лодка имела функцию вертикального взлета? Пожалуйста! Преодолевала звуковой барьер? Не вопрос! Укажите это явным образом в ТЗ. В противном случае она будет плавать но не более того.
> А еще ваш итератор удовлетворяет критериям только ForwardIterator, но не BidirectionalIterator или RandomAccessIterator, т. е. будет работать только с частью алгоритмов (когда вы сделаете его пригодным для использования с алгоритмами), а с некоторыми алгоритмами будет работать медленнее, чем можно было бы.
А он и не должен. Поскольку:
> Задача формулируется так. Есть класс, содержащий внутри коллекцию std::unique_ptr. Надо выпихнуть наружу возможность пользователям класса перебирать объекты, содержащиеся в коллекции, но без возможности изменить их.
Чему с моей точки зрения приведенный мною пример вполне удовлетворяет, разве нет?
Конечно с этим я согласен! Задачи разные. Я лишь заметил, что когда в очередной раз приводят вроде как спасительный код на серебряной пуле он почему-то на деле оказывается совсем другого цвета. Ни чуть не лучше вот этого всего что плавает рядом.
Не совсем если честно понял это замечание. Каким образом в приведенном мною случае вы сможете поменять возвращенный объект в коллекции :-?
PS: Естественно не прибегая к const_cast-у т.к. это грязный хак по-определению. Решается административными средствами в процессе code review «с последующим лишением премии».
Соглашусь с тем, что заниматься этим мне, допустим, тоже часто не приходится. Какбы ни в первый раз. Тем не менее,
> Вот очень легко формулируемая задача, которая решается в пару строк на ranges, или в десяток строк на Boost.Iterator, а на голом C++ ее вообще обычно не решают никак, потому что сильно сложно.
Приведенный ниже код случайно не устроит отца русской демократии :-? Вот только что поняв задачу буквально накидал за 10ть минут:
То, что написато в оригинале на C поймет практически любой школьник. То, что вы привели на расте — они ни чем не лучше, чем на «C++20». И там и там одинаково хреново.
Любопытство направленное на исследование до селе неизвестного и неизведанного — да, конечно. Любопытство направленное на исследование результатов чужих любопытств — так себе. На любителя.
Зачем ковыряться в чужих какахах еслиа можно сделать свои, тру правильные? Это куда веселее и интереснее. Пусть потом другие в них ковыряются а я займусь новыми.
Просто для кого то это читается как в анекдоте "… а вокруг станки станки" и возникает резонный вопрос — нахуа этим ещё и дома заниматься? :)
А вот возиться с фотоаппаратом (пусть даже крутым) — это исследование творения рук человеческих. Это не шаг вперед это топтание на месте. Ничего принципиально нового мы не узнали, правда? Да, аппарат. Да, прошивка. Да, можно разобрать по косточкам. Да, как-то работает. Да, статься получилась прикольная и перевод на уровне. Молодцы.
Но таки вопрос: а зачем собственно :-? Кроме прокачки скилов автора в реверсе я тоже не вижу никакого практического смысла в проделанной работе.
Нет, я предполагаю, что в Яндексе сидят совсем не идиоты и если бы они действительно захотели начать продажи с целью продаж — они бы их начали по-другому. На сама модель «впарить хрень по дикой цене» — это как-то так себе.