Podjęcie CComPtr do funkcji z prototypem surowy wskaźnik

Question

ja jadę przez jakiegoś starszego C++ kod do czynienia z biblioteką komponentów Windows Imaging i zauważyłem to:

void setProperties(IPropertyBag2* const pBag) 
{ 
    pBag->Write(...); 
} 

void other_function() 
{ 
    CComPtr<IPropertyBag2> pBag; 
    //Code to initialize pBag 
    setProperties(pBag); 
} 

Sposób setProperties prostu pisze pęczek właściwości do worka nieruchomości. Kod kompiluje się i działa poprawnie, ponieważ myślę, że wywołuje odpowiedniego operatora typecasting.

Moje pytanie brzmi, czy taki interfejs jest zalecany, czy jest lepszy sposób na przekazanie wskaźnika. Na przykład, jest jakaś różnica (pod względem bezpieczeństwa/wydajność) jeśli podpis został zmieniony na:

void setProperties(const CComPtr<IPropertyBag2>& pBag) 

Answer 1

Wskaźniki surowych interfejsów to kanoniczny sposób pracy z obiektami COM. Są też najbardziej elastyczne. Użycie odwołania do CComPtr spowoduje, że będziesz zawsze korzystać z CComPtr.

Każdy wskaźnik COM, nawet głupi, jest automatycznie inteligentnym wskaźnikiem, ponieważ sam obiekt implementuje AddRef i Release. Jeśli funkcja nie zachowuje kopii wskaźnika, nie ma potrzeby się o to martwić.

Typ CComPtr automatycznie rzuci się do surowego wskaźnika dla wygody.

Answer 2

Nie ma wiele zalet przy użyciu parametru CComPtr (chyba że jest non-const i ty” zamierzam go zmodyfikować). CComPtr jest bardziej przydatny dla zmiennych lokalnych i zmiennych instancji.

Ale można to zrobić, choćby ze względu na styl/konsystencję.