On 19/07/2022 20:54, Piotr Gałka wrote:
>> On 19/07/2022 20:08, Piotr Gałka wrote:
>>>> albo, co najważniejsze:
>>>> ModBusProtocol< UartMock > modbus;
>>> Nie rozumiem dlaczego napisałeś, że najważniejsze.
>> Bo testowanie własnego kodu invitro, unittestami, jest waznym etapem
>> pisania jakiegokolwiek kodu, z miganiem diodą włacznie.
> A w jaki sposób z tego co napisałeś wynika, że to dotyczy testowania
> własnego kodu.

Ze słowa "Mock" uzytego w nazwie klasy.

https://en.wikipedia.org/wiki/Mock_object

> Dla mnie to były po prostu trzy wersje użycia tego
> template dla trzech różnych klas. Co takiego szczególnego ma w sobie ta
> trzecia nazwa?

Magiczne zaklęcie znane każdemu, kto kiedykolwiek słyszał o unit
testach. Zawsze podaje taki przykład, aby każdy sobie uzmysłowił, że
*zawsze* masz co najmniej dwie klasy do takiego szablonu: rzeczywistą i
testujacą.

>> W templates "nie muszą być pochodne". Zgodnośc interfejsu badana jest
>> podczas wypełniania szablonu. Jeśli tylko jakaś klasa ma metodę foo()
>> i ktoś chce ją zawołać w momencie specjalizacji szablonem, to
>> zadziała. W dynamicznym polimorfizmie musisz dodawać wartwę interfejsu
>> z metodami wirtualnymi. W statycznym nie. Można by powiedzieć, że
>> statyczny polimorfizm bazuje na "opóźnionej kompilacji, do ostatniej
>> chwili, kiedy już wszystki wiadomo"
> Czyli to co jest wymagane to aby każda z tych klas miała te funkcje
> które zostaną użyte w template.

To nie jest takie trywialne. Powiedzmy, że mniej więcej.

> Poza tym każda może mieć dodatkowo inny zestaw funkcji - to nie robi.

Może. Tak samo w dynamicznym może.

>> Jesteś ograniczony i tak Builderem oraz bratem używającym z niechęcią C.
> Niechęć to była lata temu. Teraz już lubi C.

Można pisac w C jak w asemblerze ;) To może było złudzenie z tym
lubieniem :P

> On po prostu uważał, że ważny jest algorytm, a zapisać go już można w
> dowolnym języku.

Tak też kiedyś myślano. Obecnie mysli się inaczej: ważne jest wyrażenie,
co chcesz uzyskać, aby kompilator dobrał optymalny kod.

Tak właśnie działa C++: tam bardziej określasz co chcesz, a nie jak chcesz.

>> Wątpie, aby cokolwiek z C++11 miało jakąkolwiek wartość przed RAII czy
>> szablonami. Nie warto. No może dla "auto" warto.
> Właśnie "auto" mi się podobało i nie wiem jak się to nazywa, ale takie
> tworzenie w locie (w jednej linijce) klasy z jakąś jedną funkcją (może
> konstruktorem) co się okazało z jakiegoś powodu było często potrzebne i
> wprowadzono nowy sposób zapisu tego w kodzie źródłowym.

Lambda. Niestety lambda w embedded, w restrykcjch związanych ze stosem,
może być lekko nieciekawa, jesli użyjesz jej bezmyslnie. Choć bardzo
często kompilator usuwa lambdę i generuje kod optymalnie. Ogólnie należy
byc ostrożnym. Pod spodem dzieje się sporo dziwnych rzeczy.

>>> A statyczny polimorfizm jest w temacie embedded a tam są środowiska
>>> dostarczane przez producentów procków więc pewnie bardziej aktualne.
>> Nie widuję.
> A myślałem, że jak dostarczają środowisko to tam z definicji będzie
> można pisać w C++.

Raczej nie. C++ w embedded musi się rozpychać w lasie ignorancji.
Naprawdę dużo dobrego zrobiło Arduino, że tylnymi drzwiami wprowadzono
C++. Okaząło się że nie gryzie, działa i to na 8-bit procesorach. Magia.
A miało wybuchać.

>> Nie. Za późno. Jesli mysli asemblerem, to nie przekonasz. Nie próbuj
>> nawet. Jesli robi dobrze to, co robi, to niech robi, to co robi.
> Kiedy Ty od czasu do czasu piszesz o zabetonowanych środowiskach
> siedzących w swoim grajdołku z ubiegłego wieku.

Jesli ktoś ma warsztat który działa, to bym go nie zmieniał.

Rzecz nie w tym, aby zrobić rewolucję, rzecz w tym, aby sobie zdawać
sprawę, że można lepiej. I być może kiedyś małymi krokami dojśc do tego
"lepiej" w praktyce.

Problemem jest postrzeganie "lepiej" jako "gorzej" bo jest poza strefą
komfortu. I z tym walczę. Również u siebie.