LINUX.ORG.RU

Хвалёные смарт-поинтеры.

 


0

5

Всем привет!

Сегодня в мире т.н. «modern C++» принято нахваливать смарт-поинтеры. Дескать, это такая крутая технология, которая решает множество проблем. Как это всегда получалось, решение одних проблем порождало решение других проблем. Какие проблемы порождают смарт-поинтеры? Рассмотрим код, который валиден и прекрасно собирается:

struct B {
  virtual B* clone() = 0;
};

struct D : B {
  virtual D* clone() = 0;
};

struct impl : D {
  D* clone() override
  {
    return new impl;
  }
};

int main()
{
  auto b = new impl;
  b->clone();
}

Но стоит только превратить указатели в std::unique_ptr, как всё перестаёт собираться. И вот это уже вызывает смех. Ведь если ув. эксперты, уполномоченные принимать решения в части изменения стандарта, ввели смарт-поинтеры в язык, громогласно заявив при этом, что хватит писать на «голых» указателях, т.к. в современном C++ уже всё на смарт-поинтерах, то почему же тогда с этими хвалёными стандартными смарт-поинтерами ломается ковариантность? :-) C++ как он есть.

А какие вы знаете проблемы со смарт-поинтерами в современном C++?

Ответ на: комментарий от anonymous

О том что в С++ хватает проблем(в том числе и в системе типов) известно давно. Проблемы системы типов С++ начались задолго до появления smart_pointers и решить их в текущей парадигме нереально. Все обновления С++ утежеляют его и добавляют каких-то проблем с обратной совместимостью. И smart_pointers на самом деле больше решают проблем(в управлении памятью) чем привносят(в систему типов). И если ТС не понимает этих моментов, значит он никогда не использовал С++ ни для чего кроме троллирования в интернете.

Aswed ★★★★★
()
Ответ на: комментарий от eao197

При том. См. про отсутствие мозгов.

Т.к. ответа нет, то см. туда сам.

Для совсем тупых: проблема старая и давно известная. С ней редко сталкиваются. А когда сталкиваются, то спокойно решают обходными путями.

Судя по большинству отписавшихся здесь, проблема спокойно не решается. Её даже многие не понимают, потому то и считают данный топик очередным наездом на их любимый и могучий (как им кажется) C++.

Очередное подтверждение, что любимый вами Лисп не может вас прокормить.

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

То, что у меня нет проблем с тем, что я знаю инструмент, которым пользуюсь, и не знаю того, с чем дел не имею.

У меня тоже нет проблем. Научиться писать костыли может каждый. Это хорошо видно на примере самого C++.

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Её даже многие не понимают

Непонимание вполне может быть вызвано невнятным объяснением (что и имеет место быть в данном топике). Но нужно иметь мозги, чтобы это осознать. А ведь мозгов-то и нет.

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

Да, подумать о том, что именно вам говорят, это не смайлики в товарных количествах расставлять.

Это хорошо видно на примере самого C++.

Про C++ это давно известно. Недавно даже вполне годную замену для C++ подвезли, Rust называется. Те, кому C++ отдавил все мозоли, уже спокойно могут забыть про костыли C++.

Удивляет ваше неуемное желание троллить C++.

eao197 ★★★★★
()
Ответ на: комментарий от Dudraug

Ну так и оборачивать их в смарт поинтеры никто не мешает. Придумали проблему на пустом месте...

anonymous
()
Ответ на: комментарий от eao197

Непонимание вполне может быть вызвано невнятным объяснением (что и имеет место быть в данном топике). Но нужно иметь мозги, чтобы это осознать. А ведь мозгов-то и нет.

Кому надо, тот понял. Тем более, что в топике проблема была буквально разжёвана, и её невозможно не понять человеку, который реально работает с C++.

Да, подумать о том, что именно вам говорят, это не смайлики в товарных количествах расставлять.

На смайлики всегда время есть :-)

Про C++ это давно известно. Недавно даже вполне годную замену для C++ подвезли, Rust называется. Те, кому C++ отдавил все мозоли, уже спокойно могут забыть про костыли C++.

Звучит как скорый отказ от C++. А ведь совсем недавно ты говорил, что замены для C++ нет. Забавно.

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Звучит как скорый отказ от C++. А ведь совсем недавно ты говорил, что замены для C++ нет. Забавно.

В вашей тупости и неспособности понимать сказанное нет ничего забавного.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

В вашей тупости и неспособности понимать сказанное нет ничего забавного.

Ну а как тебя понять? Ты говоришь, что Rust - годная замена C++. Ты признаёшь, что C++ состоит из костылей. Тут вывод напрашивается сам собой.

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

К твоему ужасу, «реализовывать амбиции махая метлой» – это составное сказуемое, так как обозначает одно действие, а не два. Возможно, в твоём классе их ещё не проходили. В противном случае переадресую тебе твой же совет:

сходить в школу, взять пару уроков русского языка, а уж потом давать мне советы :-)

К твоему ещё большему ужасу, русский не является для меня родным.

fenris ★★★★★
()
Ответ на: комментарий от azelipupenko

Ну а как тебя понять?

Да, без мозгов понять что-либо сложно.

Ты говоришь, что Rust - годная замена C++.

Да. До недавнего времени в нише нативных языков без GC, с низким потреблением ресурсов и высоким быстродействием были только C, C++ и Ada. Ну, может быть еще FreePascal и какой-нибудь Modula-2.

Сейчас к этому списку добавился еще и Rust. Так что если кому-то нужно работать именно на нативном языке без GC, то Rust вполне себе замена C++ в этой нише.

Ты признаёшь, что C++ состоит из костылей. Тут вывод напрашивается сам собой.

Вывод «не писать на C++» для многих программистов напрашивается чуть ли не с конца 1980-х. А с конца 1990-х и начала 2000-х у подавляющего большинства проблем с тем, чтобы «не писать на C++» нет вообще.

Поэтому C++ используется все реже и реже. Но не исчезает, поскольку a) есть легаси и b) есть все-таки ниши, где он пока что лучший выбор. Для случая b) Rust внесет некоторые изменения, но полностью C++ не заменит.

Как из всего этого следует «скорый отказ от C++»... Это только вы сможете объяснить.

eao197 ★★★★★
()
Ответ на: комментарий от fenris

К твоему ужасу, «реализовывать амбиции махая метлой» – это составное сказуемое, так как обозначает одно действие, а не два.

Не отвертишься. «махая метлой» - это деепричастный оборот. Так что это два.

К твоему ещё большему ужасу, русский не является для меня родным.

Это не имеет значения. Мы сейчас говорим на русском языке.

azelipupenko
() автор топика
Ответ на: комментарий от anonymous

Sun-ch...где он теперь. Секретарша поди сгубила

Санчес бессмертен и стучит в наших сердцах!

vtVitus ★★★★★
()
Ответ на: комментарий от eao197

Да, без мозгов понять что-либо сложно.

Это да.

Сейчас к этому списку добавился еще и Rust. Так что если кому-то нужно работать именно на нативном языке без GC, то Rust вполне себе замена C++ в этой нише.

Ну вот, если это вполне себе замена, то вполне себе и замени.

Поэтому C++ используется все реже и реже. Но не исчезает, поскольку a) есть легаси и b) есть все-таки ниши, где он пока что лучший выбор. Для случая b) Rust внесет некоторые изменения, но полностью C++ не заменит.

a) в легаси нет и не может быть std::unique_ptr<>, потому что смарт-поинтеры ввели в стандарт того, что называется «modern C++». b) Непонятно почему Rust не заменит полностью C++. c) Парадокс. C++ используется всё реже и реже, а стандарты выходят всё чаще и чаще. Прям противоречие какое-то.

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

то вполне себе и замени.

Если от этого будет зависеть благосостояние, то заменим. Пока что нам и с C++ нормально.

a) в легаси нет и не может быть std::unique_ptr<>, потому что смарт-поинтеры ввели в стандарт того, что называется «modern C++».

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

b) Непонятно почему Rust не заменит полностью C++.

Здесь куча причин. Начиная от молодости языка и недостаточной зрелости/наполненности экосистемы, заканчивая, скажем, отсутствием нормального ООП и утиной типизации в шаблонах.

c) Парадокс. C++ используется всё реже и реже, а стандарты выходят всё чаще и чаще. Прям противоречие какое-то.

Парадокс только в вашей тупой башке.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Этой новости уже лет 20, минимум.

Почему «новости»? Это не новость, это утверждение. И да, в книгах по C++ пишут об этих косяках системы типов? А то некоторые из практикующих C++ программистов меньше 20 лет назад родились...

anonymous
()
Ответ на: комментарий от eao197

Если от этого будет зависеть благосостояние, то заменим. Пока что нам и с C++ нормально.

Лол. Если тебя волнует лишь твоё благосостояние, то какова тогда цель твоего появления в данном трэде? Разве тебе не всё равно, как там с ковариантностью в C++? Ведь придёт время, и ты всё равно его заменишь на Rust и забудешь как кошмарный сон.

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

Т.е. следуя этой логике, стандарты пилят для развития легаси. Лозунг даже можно выдвинуть: «делайте легаси на современном C++». Вот же ведь как, оказывается.

Здесь куча причин. Начиная от молодости языка и недостаточной зрелости/наполненности экосистемы, заканчивая, скажем, отсутствием нормального ООП и утиной типизации в шаблонах.

Т.е. без всего этого, по-твоему, на Rust нельзя написать софт, который будет работать точно также, как и софт, написанный на C++? Потребителю не интересно ООП или утиная типизация в шаблонах. Ему даже библиотеки не интересны. Потребителю нужна готовая программа.

Парадокс только в вашей тупой башке.

Лол :-)

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Троллинг тупостью устарел ещё лет 10 назад.

fenris ★★★★★
()
Ответ на: комментарий от Aswed

О том что в С++ хватает проблем(в том числе и в системе типов) известно давно

И что из этого следует? Что не надо эти проблемы озвучивать и обсуждать?

anonymous
()
Ответ на: комментарий от azelipupenko

Если тебя волнует лишь твоё благосостояние, то какова тогда цель твоего появления в данном трэде?

Чем меньше тупых наездов и городских мифов вокруг C++, тем лучше.

Ведь придёт время, и ты всё равно его заменишь на Rust и забудешь как кошмарный сон.

Это время пока еще не пришло. И не факт, что придет в моем случае. Могу просто до этого светлого дня не дожить.

Лозунг даже можно выдвинуть: «делайте легаси на современном C++». Вот же ведь как, оказывается.

Я вам страшное открою: любые успешные языки создаются для того, чтобы на них «делали легаси». Ибо основная часть востребованного и приносящего реальные деньги софта — это легаси. Вне зависимости от языка реализации.

Т.е. без всего этого, по-твоему, на Rust нельзя написать софт, который будет работать точно также, как и софт, написанный на C++?

Можно. И кому-то даже так удобнее. А кому-то — нет, кому-то удобнее на ООП и с утиной типизацией на шаблонах.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Потому, что смайлодаун принес это сюда как новость.

Вообще-то это форум, а не новостная лента. Или для гениев в области C++ это не так?

azelipupenko
() автор топика
Ответ на: комментарий от eao197

Чем меньше тупых наездов и городских мифов вокруг C++, тем лучше.

Какой тупой миф или наезд на C++ в данном топике? Здесь чистая правда. И кому, кстати, лучше?

Я вам страшное открою: любые успешные языки создаются для того, чтобы на них «делали легаси». Ибо основная часть востребованного и приносящего реальные деньги софта — это легаси. Вне зависимости от языка реализации.

А Linux - это легаси? А Windows - это легаси?

Можно. И кому-то даже так удобнее. А кому-то — нет, кому-то удобнее на ООП и с утиной типизацией на шаблонах.

Значит, таки, заменит :-)

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Вообще-то это форум, а не новостная лента.

И поэтому вы начали троллить по поводу древнего баяна. Логично, чё.

Или для гениев в области C++ это не так?

ХЗ, вопрос не по адресу.

Какой тупой миф или наезд на C++ в данном топике?

Стартовое сообщение, как минимум.

И кому, кстати, лучше?

Мне, например.

А Linux - это легаси? А Windows - это легаси?

И то, и другое — да. Сколько еще тупых вопросов у вас в запасе?

Значит, таки, замени

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

И поэтому вы начали троллить по поводу древнего баяна. Логично, чё.

Где я начал троллить?

ХЗ, вопрос не по адресу.

А разве ты не гений C++?

Стартовое сообщение, как минимум.

И где там «наезд» или «тупой миф»?

Мне, например.

Ну так не «наезжай» на C++ и не плоди «мифов» вокруг него.

И то, и другое — да

Другими словами, легаси - это вообще весь коммерческий и некоммерческий софт, приносящий деньги?

Сколько еще тупых вопросов у вас в запасе?

Лол.

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

А твоей логикой что? Она тоже легаси? :-)

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Где я начал троллить?
И где там «наезд» или «тупой миф»?

С самого начала и прямо по тексту:

Сегодня в мире т.н. «modern C++» принято нахваливать смарт-поинтеры. Дескать, это такая крутая технология, которая решает множество проблем. Как это всегда получалось, решение одних проблем порождало решение других проблем.

А разве ты не гений C++?

Нет. Даже на вашем фоне.

Ну так не «наезжай» на C++ и не плоди «мифов» вокруг него.

Я этого не делаю, в отличии от.

Другими словами, легаси - это вообще весь коммерческий и некоммерческий софт, приносящий деньги?

Который старше N лет и над которым поработало более одного человека.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

С самого начала и прямо по тексту:

Сегодня в мире т.н. «modern C++» принято нахваливать смарт-поинтеры. Дескать, это такая крутая технология, которая решает множество проблем. Как это всегда получалось, решение одних проблем порождало решение других проблем.

И где тут миф или наезд? Где тут неправда? Открой любой бложик, любую книгу по «современному C++», и ты увидишь, как смарт-поинтеры преподносятся как одна из главных фич. Но вот, незадача, в ковариантность они не умеют...

Нет. Даже на вашем фоне.

Да ладно. Ты ведь публикуешь такие изысканные техники и приёмы при работе с C++, что их можно смело назвать гениальными.

Я этого не делаю, в отличии от.

Так и я не делаю, в отличии от.

Который старше N лет и над которым поработало более одного человека.

А вот и новый критерий, о котором раньше ты не заявлял. Может быть, ещё какой-то есть критерий в запасе? :-)

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

И где тут миф или наезд? Где тут неправда?

Везде. Начиная с того, что смартпоинтеры стали популяризировать за пару лет до «modern C++» от Александреску.

Но вот, незадача, в ковариантность они не умеют...

Это не проблема конкретно смартпоинтеров. Берем простой пример, в котором есть ковариантность, но нет никакой работы с динамической памятью:

class device_initializer_t {};
class device_t {
public:
    virtual device_initializer_t & initializer() = 0;
};

class first_device_t : public device_t {
public:
    class initializer_t : public device_initializer_t {
    public:
        void start() {}
    };
    initializer_t & initializer() override { return initializer_; }
    
private:
    initializer_t initializer_;
};

class second_device_t : public device_t {
public:
    class initializer_t : public device_initializer_t {
    public:
        void init() {}
    };
    initializer_t & initializer() override { return initializer_; }
    
private:
    initializer_t initializer_;
};

int main() {
    first_device_t first;
    first.initializer().start();
    
    second_device_t second;
    second.initializer().init();
}

И попытаемся применить шаблоны:

template<typename T> struct wrapped_reference_t{
    T * ref_;
    T * operator->() { return ref_; }
};

class device_initializer_t {};
class device_t {
public:
    virtual wrapped_reference_t<device_initializer_t> initializer() = 0;
};

class first_device_t : public device_t {
public:
    class initializer_t : public device_initializer_t {
    public:
        void start() {}
    };
    wrapped_reference_t<initializer_t> initializer() override { return initializer_; }
    
private:
    initializer_t initializer_;
};

class second_device_t : public device_t {
public:
    class initializer_t : public device_initializer_t {
    public:
        void init() {}
    };
    wrapped_reference_t<initializer_t> initializer() override { return initializer_; }
    
private:
    initializer_t initializer_;
};

int main() {
    first_device_t first;
    first.initializer()->start();
    
    second_device_t second;
    second.initializer()->init();
}
И получаем ту же самую проблему. Вот ведь: смартпоинтеров нет, а проблема есть.

Ты ведь публикуешь такие изысканные техники и приёмы при работе с C++, что их можно смело назвать гениальными.

Ничего подобного, там нет ничего сложного. Не говоря уже про более восторженные эпитеты.

А вот и новый критерий, о котором раньше ты не заявлял.

Я вообще и не пытался дать всеобъемлющее определение термину «легаси».

eao197 ★★★★★
()
Ответ на: комментарий от Dudraug

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

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

i36_zubov
()
Ответ на: комментарий от i36_zubov

Нет. Ты просто не так понял проблему.

C++ разрешает при перекрытии(override) виртуального метода вместо указателя на базовый класс вернуть указатель на производный.

В рамках системы типов C++ нельзя заставить работать это правило и для «умных» указателей тоже.

anonymous
()

Кто сказал «костыли»? А, у вас тут с++. Что? Какие, нахер, «умные» указатели? Зачем? C++ unsafe. Хотите safe делайте сами себе safe или пишите на яве/питоне/js/go/что там модно. Да и вообще вспомните unix-way и не доводите ваши проекты до греха, когда хрен поймешь, где просран указатель.

crutch_master ★★★★★
()
- D* clone() override
+ B* clone() override

И всё будет нормально. Зачем тебе вообще возврат точного типа из clone()

Deleted
()
Ответ на: комментарий от Deleted

Зачем вообще возврат точного типа из clone()

Чтобы не терять информацию об интерфейсе, если используется указатель на более специальный интерфейс D, а не на B.

anonymous
()
Ответ на: комментарий от anonymous

Да, верно, хотя мне такое требование пока не встречалось. Тогда вариант с обёртками весьма неплохой workaround

Deleted
()
Ответ на: комментарий от eao197

Везде. Начиная с того, что смартпоинтеры стали популяризировать за пару лет до «modern C++» от Александреску.

Меня не интересуют самопальные смарт-поинтеры до «modern C++ design» от Александреску. (включая тот самопал, который описан в его книге.) И под «modern C++» я подразумеваю C++17, а не то, что описывал ув. Андрей.

И получаем ту же самую проблему. Вот ведь: смартпоинтеров нет, а проблема есть.

Здесь у меня претензий нет. Тут ты сам себе создал проблему, так что тебе и отвечать.

Ситуация со _стандартными_ смарт-поинтерами иная. Вот смотри, голые указатели нормально работают с ковариантностью. Это стандартная фича, оговоренная в стандарте, ещё задолго до введения смарт-поинтеров. Потом вдруг появляется новый стандарт, в котором появляются смарт-поинтеры. Теперь даже если где-то pimpl реализована без использования std::unique_ptr/std::shared_ptr, то это считается дурным тоном, ибо смарт-поинтеры в стандарте, а это значит, что теперь голым указателям места в современном C++ коде нет. Везде и всюду поощряется использование именно смарт-поинтеров, включая возврат значений из функций. Но, как выясняется, при возврате смарт-поинтеров из виртуальных функций, ломается ковариантность. И тут возникает вопрос - а с чего это ради это имеет место быть со стандартными смарт-поинтерами, призванными заменить голые указатели? Неужели нельзя было обеспечить действительно эквивалентное голым указателям поведение? Если нет, то зачем везде и всюду пиар стандартных смарт-поинтеров?

Ничего подобного, там нет ничего сложного. Не говоря уже про более восторженные эпитеты.

Ну да ладно. Пусть попробует кто-нибудь разберётся в твоей вышеприведённой простыне кода, или пусть попробует напишет что-то подобное за несколько минут, как ты. Вряд ли :-)

Я вообще и не пытался дать всеобъемлющее определение термину «легаси».

Кстати, а вот есть такой свежий серверок под названием RESTinio :-) Он тоже легаси? :-)

azelipupenko
() автор топика
Ответ на: комментарий от eao197

отсутствием нормального ООП и утиной типизации в шаблонах

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

Nexmean
()
Ответ на: комментарий от azelipupenko

Пусть попробует кто-нибудь разберётся в твоей вышеприведённой простыне кода

туго доходит, что наследование и шаблоны плохо совместимы?

тогда у меня для тебя плохие новости.

anonymous
()
Ответ на: комментарий от azelipupenko

Ситуация со _стандартными_ смарт-поинтерами иная.

Об этой «иной» ситуации вам лучше поговорить с голосами в своей голове. Это у вас там актуальная реальность отрицается и формируется какой-то свой дивный мир.

Кстати, а вот есть такой свежий серверок под названием RESTinio :-) Он тоже легаси? :-)

Еще нет. Года через 3-4 будет. А вот SObjectizer — да, 100% легаси. Из тех, которые обновляют время от времени.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Об этой «иной» ситуации вам лучше поговорить с голосами в своей голове. Это у вас там актуальная реальность отрицается и формируется какой-то свой дивный мир.

Актуальная реальность такова, что обычные указатели, будучи использованы в качестве типа возвращаемого значения в виртуальных функциях, умеют в ковариантность, а «умные» указатели - не умеют. Это и есть дивный мир C++.

Еще нет. Года через 3-4 будет. А вот SObjectizer — да, 100% легаси. Из тех, которые обновляют время от времени.

Вообще-то, «legasy system» - это софт, подлежащий замене. Просто по определению «legacy system».

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Актуальная реальность такова, что обычные указатели, будучи использованы в качестве типа возвращаемого значения в виртуальных функциях, умеют в ковариантность, а «умные» указатели - не умеют.

Для даунов: это имеет место быть для шаблонов вообще, а не только для смартпоинтеров. И не только для указателей, но и для ссылок.

Вообще-то, «legasy system» - это софт, подлежащий замене.

Legasy — может быть. А вот legacy — это старый софт, подлежит он замене или нет зависит от возможностей эксплуатирующей его организации.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Для даунов: это имеет место быть для шаблонов вообще, а не только для смартпоинтеров. И не только для указателей, но и для ссылок.

Тем хуже для C++.

Legasy — может быть. А вот legacy — это старый софт, подлежит он замене или нет зависит от возможностей эксплуатирующей его организации.

А чем Legasy от legasy отличается? Заглавной буквой?

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Тем хуже для C++.

Хуже всего C++ от того, что смайлодауны на нем софт пишут. Вот это реальная проблема, да.

eao197 ★★★★★
()

А кто-нибудь может мне объяснить, зачем вообще создавать смарты внутри функций?

ИМХО, вполне логично решать что и как хранить именно на вызывающей стороне. Откуда знать классу, какой смарт нужен принимающему коду и нужен ли вообще. Тем более, что с появлением deduction guides даже длинные типы писать не надо.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Ivan_qrt

Если следовать классической ООП'шной традиции «запихивать все локальные переменные в члены и оформлять каждое замыкание отдельным классом со странным именем типа AbstractSingletonFactoryFacade», то тогда вообще не ясно, зачем нужны не только смарт-поинтеры, но и, например, лямбды.

Деды и без лямбд на плюсах воевали!

nezamudich ★★
()
Ответ на: комментарий от nezamudich

Если следовать классической ООП'шной традиции «запихивать все локальные переменные в члены и оформлять каждое замыкание отдельным классом со странным именем типа AbstractSingletonFactoryFacade», то тогда вообще не ясно, зачем нужны не только смарт-поинтеры

Чтобы не забыть удалить объект // К.О.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

c++ неидеален. но в такому случае, что мешает недовольным уже наконец писать на расте? мне вот не нравится жаба, и я не пишу на ней. чего они переживают то.

i36_zubov
()
Ответ на: комментарий от nezamudich

оформлять каждое замыкание отдельным классом со странным именем типа AbstractSingletonFactoryFacade

если писать принципиально через жопу, потому что того требует идолище ООПа, то от С++ еще и не так страдать можно будет.

i36_zubov
()
Ответ на: комментарий от eao197

Хуже всего C++ от того, что смайлодауны на нем софт пишут. Вот это реальная проблема, да.

Ну ничего страшного, не переживай. Лет через 12 внесут на рассмотрение предложение о поддержке ковариантности в смарт-поинтеры. Потом года 4 ещё подумают, всё взвесят тщательно, а потом, глядишь, и появятся в C++ полностью ковариантные смарт-поинтеры. У C++ большое будущее :-)

azelipupenko
() автор топика
Ответ на: комментарий от i36_zubov

но в такому случае, что мешает недовольным уже наконец писать на расте?

Работа, например И я так и не понял, почему нельзя обсуждать недостатки и способы борьбы с их проявлениями.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.