Jak poprawić stary sposób rzutowania na nowy?

0

Witam, przeglądając przykłady dokumentacji WinScard w przykładzie jest taki sposób postępowania:

LPTSTR          pmszReaders = NULL;
LPTSTR          pReader;
LONG             lReturn, lReturn2;
DWORD         cch = SCARD_AUTOALLOCATE;

lReturn = SCardListReaders(hSC,  NULL,  (LPTSTR)&pmszReaders,  &cch );
```
moje pytanie jest następujące:
Jak poprawić tę zaszłość? Wiadomo, że program się wykona prawidłowo, ale nie mogę wychwycić jak poprawnie zrobić podmianę.
2

reinterpret_cast<LPTSTR>(&pmszReaders), przy czym imo nic tutaj nie zyskujesz.

0

Nie licząc tego, że zejdzie jedno z ostrzeń :p
Czyli nie ma co się przejmować, jak ktoś rzutuje, czy jednak są jakieś reguły, kiedy te nowe sposoby są skuteczniejsze (bo zakładam, że bezpieczniejsze na pewno)?

1

Skuteczniejsze/bezpieczniejsze to tak średnio bym powiedział, ale bardziej widoczne. Przy czym pokazałeś kawałek kodu korzystającego z winapi i notacji węgierskiej, gdzie c-style casty nie kłują aż tak bardzo w oczy, bo i tak zastępują reinterpret_cast. c-cast zamiast const/static cast boli, a tutaj (opinia) - mniej

0

No bo wyrwane żywcem z Dokumentacji MS. Ale jak chcę używać tego u siebie w czymś większym, to już wolałem podpytać, choćby to miała być "sztuka dla sztuki".

2

Ogółem dobrą zasadą przy korzystaniu z bibliotek pisanych w C (a w szczególności winapi z ich windows.h), jest opakowanie używanych funkcji we własne wrappery w C++, z obsługą typów, przeładowań i RAII tam gdzie to sensowne. Wtedy brudy masz w jednym miejscu.

0

To jeszcze jedno pytanie:
jak mam takie egzemplarze jak

case SCARD_E_NO_READERS_AVAILABLE:

i IDE marudzi, że to też jest stary styl, to też mogę to, jak wyżej, opakować?

Nie było pytania - zajrzałem co tam jest w środku, a tam: (DWORD)(-1).

1

Ja jeszcze dodam, że bardzo pożądaną praktyką, jest chowanie wszelkiego zewnętrznego API za interfejsami lub jeśli ktoś jest maniakiem optymalizacji za statycznym polimorfizmem.
Wtedy wszelkie śmieci z WinApi schowają ci się w interfejsie, a dodatkowo można pisać testy, które będą: szybkie, niezależne od systemu i pokryją nietypowe scenariusze (których w innym wypadku nie da się symulować).

Ten twój przypadek z NFC jest doskonałą okazją by tak to robić, bo możesz wtedy uruchomić testy bez fizycznego posiadania czytnika NFC.

1 użytkowników online, w tym zalogowanych: 0, gości: 1