HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Технические вопросы (https://hlfx.ru/forum/forumdisplay.php?forumid=20)
-- [C++] Виртуальный умный указатель?! (https://hlfx.ru/forum/showthread.php?threadid=4886)

[C++] Виртуальный умный указатель?!

Сабж
Насколько (не)оправданно предоставлять из dll виртуальный интерфейс умного указателя?
Допустим, есть интерфейс A (реализация которого владеет массивом объектов B), через который можно получать указатели на объекты B по их именам. Объекта может и не быть в массиве и тогда A вернёт пустой указатель. Имеет ли смысл возвращать вместо него указатель на другой объект с семантикой умного указателя для типов массива B или же разумнее возвращать указатель на сам объект из B и передавать его внутрь уже реализации нашего умного указателя в клиентском коде?

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

__________________

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

Да нормальные указатели, если чётко всё обговорить. Возвращать - не плохо. Плохо когда, как в халфе, когда аргумент на строку в движке считается чем-то константным (ну я статью писал). Вот за такое реально ушы отрывать следовало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

__________________

Он в виде указателя на виртуальный интерфейс передаётся, в том и фишка
Но проблема может возникнуть в другом - либо на каждый IFoo* свой ISmartFoo*, либо один общий, через который, как через бутылочное горлышко, происходит взаимодействие со всеми IFoo*. Ну и есть вариант завести пул умных указателей, что, как по мне, ненужное усложнение. Думаю, что лучше всего - оставить как есть и выдавать указатель на IFoo*, а на другой стороне заворачивать в смарт

__________________

1

// Вы предлагаете так?

2

struct barrel

3

{

4

  int rolls;

5

};

6

7

void DoABarrelRoll(struct barrel *pbarrel)

8

{

9

  pbarrel->rolls++;

10

};

11

12

// Я предоставляю указатель на ООП-интерфейс

13

struct IBarrel

14

{

15

  virtual void DoARoll() = 0;

16

};

17

18

class CBarrel : public IBarrel

19

{

20

public:

21

  void DoARoll(){rolls++;}

22

private:

23

  int rolls;

24

};

25

26

struct IBarrelProvider

27

{

28

  virtual IBarrel *GetBarrel() = 0;

29

};

30

31

IBarrelProvider *gpBarrelProvider = GetBarrelProvider();

32

gpBarrelProvider->GetBarrel()->DoARoll(); // если бочку получать в виде смарта, то можно обращаться прямо так

Ph03n1x
Ещё раз - зачем тут смарты?
Когда спрашивают про возвращение смарта из библиотеки, я представляю что-то вроде такого:

shared_ptr<Foo> get_data( int my_arg )

{

  return shared_ptr<Foo>( new Foo( my_arg ) );

}

__________________

XaeroX
Как раз таки этого я и избегаю, т.к. причину ты сам указал

А я про кастомный смарт, оформленный в виде виртуального интерфейса и не затрагивающий ничего импл-зависимого
Чтобы не нужно было каждый раз проверять на валидность + возвращать дефолтные значения (хардкодные или указанные в арг-ах к функции)

1

IFoo *pFoo = pFooProvider->GetFoo("abc");

2

if(!pFoo)

3

  NULL_PTR_ALARM();

4

5

IFooRef *pFooRef = pFooProvider->GetFooRef("abc");

6

int nBar = pFooRef->GetBar();

7

8

class CFooRef : public IFooRef

9

{

10

public:

11

  void Set(IFoo *apFoo){mpFoo = apFoo;}

12

  IFoo *Get(){return mpFoo;}

13

14

  int GetBar(/*int nDefBar*/)

15

  {

16

    if(mpFoo)

17

      return mpFoo->GetBar();

18

19

    return 0; // nDefBar

20

  };

21

private:

22

  IFoo *mpFoo;

23

};