[Parseval]

Cześć,

Napisałem interfejs dla fizycznych interfejsów pod #linux . Interfejs zawiera dwa kontenery pełniące rolę buforów. Następnie stworzyłem klasę implementującą Serial Port, która dziedziczy publicznie po Interfejsie te bufory. Czy da się lepiej przekazać typ buforów do interfejsu tak, żeby klasa SerialPort nie musiała implementować wszystkich metod jako template? Jedynę co potrzebuję, to zrobić template w metodzie write(), żeby określić typ danych.

Tutaj wstawiam pseudokod: pastebin
Celowo pominąłem implementację metod dla uproszczenia. Obiekt SerialPortu chciałbym tworzyć na przykład tak:

SerialPort< std::vector > serial;

#programista15k #programowanie #cpp

[MamCieNaHita]

@Parseval: segregacja interfejsów, robisz osobno interfejs sender i receiver

[Parseval]

@MamCieNaHita: Mógłbyś rozwinąć? Jak mogłoby to wyglądać?

[MamCieNaHita]

@Parseval:
1. skoro potrzebujesz tylko metody write, to powinieneś mieć interfejs który ma tylko metodę write(patrz np. istream i ostream)
2. po co ci ten bufor w interfejsie? to nie jest interfejs jak ma jakieś pola
3. możesz zrobić jakiś polimorficzny interfejs na bufor, albo zrobić coś w stylu std::function które opakowuje bufor.

[Parseval]

@MamCieNaHita ogólny zamysł jest taki, że będzie istniała jakaś klasa do obsługi danego typu urządzeń, które mogą gadać po kilku interfejsach fizycznych (np. Serial, CAN itp.). Chciałem, żeby ta klasa obsługi urządzenia posiadała klasę bazową (co nazwałem interfejsem), a przez konstruktor był podpinany konkretny interfejs fizyczny, który będzie operował na kontenerach przekazanych przez template. Problem jest w tym, że staram się napisać kod na różne platformy i kontenerem może być specyficzny kontener

[SpinOff]

@Parseval: Wydaje mi się że mieszanie dwóch typów polimorfizmu jest powodem twoich problemów. Jeśli chcesz mieć tam szablon, to nie baw się we wspólne interfejsy, tylko zrób wszystko statycznie (szablonami). Jeśli chcesz mieć wspólny interfejs to wywal szablon. Poczytaj sobie o wzorcu o nazwie "most".

[keton22]

@Parseval: zakładam że to tak 'dla nauki' ale problem jest znany i opisany szeroko.

Pierwsze primo nie generalizuj za szybko.
Będziesz zawsze gadać z konkretnym sprzętem np. akcelerometrem XYZ123. Czyli będziesz musiał mieć do niego driver bo wewnątrz jest mikroarchitektura diametralnie różna od twojej.
To jest dobry punkt centralny w myśleniu. 'w górę' udostępnia on dane o np. ilości kroków, rodzaju wykonywanej aktywności i przyspieszeniu w 3 osiach, itd. więc to

[Parseval]

@keton22: Tak, to mój projekt.

Dzięki za rady, postaram się to wcielić w życie.

[Parseval]

No i się pobugiłem.

Ścianą okazuje się metoda write(), która przyjmuje jako argument interfejs kontenera, który jest szablonem.
Podobnie metoda GetReadBufferReference(), która zwraca interfejs kontenera. Nie mam pomysłu jak to pogodzić bez duplikowania kodu.

[keton22]

@Parseval: może zobacz jak to się robi np. https://github.com/BoschSensortec/BME280_driver i jak tu jest wyabstrakcjonowana komunikacja. Potem możesz to sobie popakować w obiekty. Alternatywnie w kernelu jest iio API i drivery.