Witam,
Piszę komunikator TCP/IP i muszę przesyłać obiektu różnego typu, do tego wykorzystuję serializator i zamieniam na tablicę bajtów.
Problem pojawia się w momencie deserializacji. Mogę spodziewać się 5 różnych typów obiektów. W jaki sposób określić jaki to będzie typ w celu deserializacji? Gdy przesyłałem do tej pory tylko jeden typ nie było problemu bo rzutowałem tylko na ten typ, co w przypadku wielu różnych typów?
Dziękuję za odpowiedzi.
- Rejestracja:ponad 16 lat
- Ostatnio:prawie 10 lat
- Postów:21
0
- Rejestracja:prawie 12 lat
- Ostatnio:prawie 9 lat
- Postów:47
0
Nie wiem czy to najlepsze wyjście, ale możesz wrzucić if'y, a w nich sprawdzać tak:
if (zmienna is Twoj_typ)
rzutowanie na Twoj_typ i deserializacja;
edytowany 1x, ostatnio: tom
B3rt
też już o takim rozwiązaniu myślałem, ale czy to jest poprawne rozwiązanie?
tom
pewne jest, że powinno działać, a czy jest poprawne, za mało wiem żeby osądzać ;)
0
Tak, to jest poprawne rozwiązanie. Ewentualnie możesz stworzyć wspólny interfejs (może być pusty), który będzie implementować każdy obiekt, który będziesz przesyłał i wtedy przy odbiorze powiedzmy 10 obiektów możesz stworzyć listę w takiej postaci List<NazwaInterfejsu> obiekty, a później w razie potrzeby sprawdzać i rzutować na zasadzie :
if(obiekt is JakasKlasa) {
JakasKlasa zrzutowany = obiekt as JakasKlasa;
}
OK, będę sprawdzać - dzięki za upewnienie.

- Rejestracja:około 17 lat
- Ostatnio:dzień
- Lokalizacja:Wrocław
0
niezalogowany napisał(a):
if(obiekt is JakasKlasa) {
JakasKlasa zrzutowany = obiekt as JakasKlasa;
}
Kompletnie bezsensowny kod.
Gdy sprawdziliśmy za pomocą is
, że obiekt jest instancja JakasKlasa
, to nie ma sensu używać as
tylko zwykłego rzutowania. Z drugiej strony, is
wewnętrznie wykonuje as
, więc nie zawsze ma sens.

Za to jest ładny. Mi się dużo bardziej podoba
zmienna as Foo
zamiast (Foo)zmienna
, więc ubolewam że to pierwsze ma specjalne znaczenie a drugie powinno być stosowane domyślnie
.

a to drugie nie jest szybsze?

Krótka odpowiedź to
to skomplikowane
. CLR definiuje dwa opcody - isinst
i castclass
. Kiedy test się powiedzie (rzutowanie jest dozwolone) oba są równoważne. Jeśli nie, castclass
rzuca wyjątek a isinst
umieszcza null. Za to is
jest implementowane jako (a is B) <=> ((a as B) != null). Oba są konwertowane przez JIT do (odpowiednio) JIT_IsInstanceOf oraz JIT_ChkCast i oba korzystają z nieudokumentowanej struktury RuntimeTypeHandle. I teraz zostaje pytanie która z tych metod jest wydajniejsza - tu już trzeba by benchmarkować, ale roboty mają w zasadzie tyle samo.