Сообщение Re[13]: Почему CLion и VS не предупреждают? от 04.05.2023 9:08
Изменено 04.05.2023 9:13 serg_joker
Re[13]: Почему CLion и VS не предупреждают?
Здравствуйте, so5team, Вы писали:
TB>>Мне казалось что для этого используются статик методы, создающие объект
S>Простенький пример:
S>[...]
В этом примере место создания `unique_ptr` находится вне worker, хоть и в дружественном классе.
T4r4sB предполагает, что такое как бы и должно решаться статик методами (и решается, но с оговорками, см. комментарии):
т.е. проблема в том, что нам нужно вызвать `make_unique<worker>`, а уж он-то и не может добраться к нашему закрытому конструктору.
Решается либо через new, как в примере, либо через passkey idiom
Сделать `make_unique<worker>` другом, вроде как, нельзя.
TB>>Мне казалось что для этого используются статик методы, создающие объект
S>Простенький пример:
S>[...]
В этом примере место создания `unique_ptr` находится вне worker, хоть и в дружественном классе.
T4r4sB предполагает, что такое как бы и должно решаться статик методами (и решается, но с оговорками, см. комментарии):
class worker {
friend class manager;
int i_;
worker(int v) : i_{v} {};
public:
static std::unique_ptr<worker> Create(int v) {
#if 0
// This one fails because `make_unique` tries to access private Ctor
return std::make_unique<worker>(v);
#else
// We are enforced to use `new` in this case.
return std::unique_ptr<worker>{new worker(v)};
#endif
}
int i() const noexcept { return i_; }
};
т.е. проблема в том, что нам нужно вызвать `make_unique<worker>`, а уж он-то и не может добраться к нашему закрытому конструктору.
Решается либо через new, как в примере, либо через passkey idiom
Сделать `make_unique<worker>` другом, вроде как, нельзя.
Re[13]: Почему CLion и VS не предупреждают?
Здравствуйте, so5team, Вы писали:
TB>>Мне казалось что для этого используются статик методы, создающие объект
S>Простенький пример:
S>[...]
В этом примере место создания `unique_ptr` находится вне `worker`, хоть и в дружественном классе.
T4r4sB предполагает, что такое как бы и должно решаться статик методами (и решается, но с оговорками, см. комментарии):
т.е. проблема в том, что нам нужно вызвать `make_unique<worker>`, а уж он-то и не может добраться к нашему закрытому конструктору.
Решается либо через new, как в примере, либо через passkey idiom
Сделать `make_unique<worker>` другом, вроде как, нельзя.
TB>>Мне казалось что для этого используются статик методы, создающие объект
S>Простенький пример:
S>[...]
В этом примере место создания `unique_ptr` находится вне `worker`, хоть и в дружественном классе.
T4r4sB предполагает, что такое как бы и должно решаться статик методами (и решается, но с оговорками, см. комментарии):
class worker {
friend class manager;
int i_;
worker(int v) : i_{v} {};
public:
static std::unique_ptr<worker> Create(int v) {
#if 0
// This one fails because `make_unique` tries to access private Ctor
return std::make_unique<worker>(v);
#else
// We are enforced to use `new` in this case.
return std::unique_ptr<worker>{new worker(v)};
#endif
}
int i() const noexcept { return i_; }
};
т.е. проблема в том, что нам нужно вызвать `make_unique<worker>`, а уж он-то и не может добраться к нашему закрытому конструктору.
Решается либо через new, как в примере, либо через passkey idiom
Сделать `make_unique<worker>` другом, вроде как, нельзя.