Programowanie w C

Tu można porozmawiać na dowolny temat nie koniecznie związany z tematyką maszyn i CNC

upanie
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 12
Posty: 1965
Rejestracja: 15 sty 2011, 09:26
Lokalizacja: Wyszków

Re: Programowanie w C

#31

Post napisał: upanie » 15 lis 2022, 14:45

Jak dla mnie, to kolejny język dla debili, dla których procesor to czarna skrzynka, do której nie wolno zaglądać, bo i tak się nie zrozumie...
Cóż, "programiści" którzy niczego nie rozumieją, ale pamiętają co trzeba napisać żeby zadziałało, to prawdziwa plaga.
Generalizujesz ale fakt, że są i tacy programiści. Tak samo jak są różni ślusarze, nauczyciele, lekarze, itd. Język programowania nie ma z tym nic wspólnego.

Zacznij się uczyć rusta to zrozumiesz, że nie jest dla debili.
Jak chcesz wiedzieć więcej to czemu nie ale ile razy poznawałeś implementację funkcji printf albo malloc? Pewnie nigdy jak większość bo i po co? Nieznajomość implementacji bibliotek i jednocześnie ich używanie nie świadczy o debiliźmie a wręcz przeciwnie.
Napisz tak z kilkadziesiąt firmware-ów na mikrokontrolery, które są bogate w funkcjonalność (prawdziwą funkcjonalność a nie wysyłanie znaków po uarcie) a odechce Ci się poznawania ich od środka.
Takie bzdety o świadomości działania procesora, na który pisze się soft opowiadają ludzie, którzy bawią się a nie robią tego zawodowo. Sam tak kiedyś mówiłem ale już dawno mi przeszło. "Pod maskę" zaglądam tylko wtedy kiedy muszę i nie zwiedzam całej komory silnika tylko ten fragment, który akurat sprawia problemy bo na więcej szkoda czasu firmowego a prywatny mam od czego innego.

Dodane 46 sekundy:
allegro8228 pisze:
15 lis 2022, 14:35
W drewnie i metalu :)
Kurcze a myślałem, że w warsztacie.


czilałt...

Awatar użytkownika

grg12
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 8
Posty: 1670
Rejestracja: 03 sty 2007, 14:27
Lokalizacja: Wiedeń

Re: Programowanie w C

#32

Post napisał: grg12 » 15 lis 2022, 15:01

tuxcnc pisze:
15 lis 2022, 13:53

Jak dla mnie, to kolejny język dla debili, dla których procesor to czarna skrzynka, do której nie wolno zaglądać, bo i tak się nie zrozumie...
Cóż, "programiści" którzy niczego nie rozumieją, ale pamiętają co trzeba napisać żeby zadziałało, to prawdziwa plaga.
Nie da się oceniać języka na podstawie "hello World" (może poza brainfuckiem i podobnymi żartrami) - gdyby było inaczej wszyscy byśmy pisali w perlu albo pythonie. Rust powstał jako narzędzie do rozwiązywania konkretnych problemów np. pisania bezpiecznych, wielowątkowych programów. W przeciwieństwie do C potrzebne do tego elementy są dostępne na poziomie składni języka a nie biblioteki dzięki czemu kompilator może wychwycić więcej błędów.
Oczywiście - możesz powiedzieć że dobry programista uzyska ten sam poziom bezpieczeństwa używając c i pthread a reszta świata powinna się dokształcić zamiast tracić czas na tworzenie nowych narzędzi ale to niezbyt realistyczne podejście...

Awatar użytkownika

tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 12
Posty: 7861
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: Programowanie w C

#33

Post napisał: tuxcnc » 15 lis 2022, 15:25

upanie pisze:
15 lis 2022, 14:45
Napisz tak z kilkadziesiąt firmware-ów na mikrokontrolery, które są bogate w funkcjonalność (prawdziwą funkcjonalność a nie wysyłanie znaków po uarcie) a odechce Ci się poznawania ich od środka.
Takie bzdety o świadomości działania procesora, na który pisze się soft opowiadają ludzie, którzy bawią się a nie robią tego zawodowo.
Co się tak uparłeś udowodnić że gówno wiesz i niczego nie rozumiesz?
Masz tu fragment mojego kodu:

Kod: Zaznacz cały

if (TIM2->CR1 & 0x10)
  {
          timer2_ovf-=0xFFFF;
  }
  else
  {
          timer2_ovf+=0xFFFF;
  }
To jest procedura obsługi przerwania z licznika pracującego w trybie enkodera kwadraturowego procesora STM32F401.
Zapewne tego nie widzisz i nie rozumiesz, ale znajomość wewnętrznej budowy procesora znakomicie uprościła kod.
Nigdy się nie dogadamy, bo ja programować uczyłem się w assemblerze 8080 i mam alergię na "programistów", którzy bez struct i this nawet LED-em nie potrafią pomrugać...


upanie
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 12
Posty: 1965
Rejestracja: 15 sty 2011, 09:26
Lokalizacja: Wyszków

Re: Programowanie w C

#34

Post napisał: upanie » 15 lis 2022, 15:42

tuxcnc pisze:Co się tak uparłeś udowodnić że gówno wiesz i niczego nie rozumiesz?

Kolejna konstruktywna i przemyślana krytyka.

Co Ty tym kawałeczkiem kodu próbujesz udowodnić? Że jest taki za***isty, że go nie zrozumiem?
Otóż ten kawałek nigdy by nie przeszedł review znawco. Używasz magic namberów i nie umiesz tego samego napisać prościej w jednej linii.
Wstyd przez wielkie F. Nie znasz się to się wtrącaj się gdy dorośli rozmawiają.

Jeszcze raz: Napisz tak z kilkadziesiąt firmware-ów na mikrokontrolery, które są bogate w funkcjonalność (prawdziwą funkcjonalność a nie wysyłanie znaków po uarcie) a odechce Ci się poznawania ich od środka.

Po tym co pokazałeś spokojnie twierdzę, że nawet nie stałeś blisko prawdziwego programisty i nigdy nie stworzyłeś jakiegoś "prawdziwego" programu. Prawdziwy to taki, który realizuje jakąś złożoną funkcjonalność, wykonuje jakaś prawdziwą robotę, którą zamówił klient. Pierdółek jakie sobie dziubiesz na boku nie nazywaj programowaniem a dłubaniem.

To tak jakbym ja mówił doświadczonemu ślusarzowi, że gówno wie i niczego nie rozumie i pokazał mu wywiercony otwór w kawałku aluminium i to jeszcze trochę krzywo. Żenua.
czilałt...

Awatar użytkownika

tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 12
Posty: 7861
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: Programowanie w C

#35

Post napisał: tuxcnc » 15 lis 2022, 15:54

upanie pisze:
15 lis 2022, 15:42
nie umiesz tego samego napisać prościej w jednej linii
Umiem (?:), tylko nie lubię, bo czytelność stawiam wyżej od zaoszczędzenia kilku znaków.
Natomiast Ty popisujesz się klasycznym buractwem, czyli jak się nie masz do czego przypieprzyć, to się czepiasz ortografii.
Tylko tutaj akurat kod jest napisany poprawnie, zgodnie ze standardem, a jak się Tobie nie podoba, to wyłącznie twój problem.


upanie
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 12
Posty: 1965
Rejestracja: 15 sty 2011, 09:26
Lokalizacja: Wyszków

Re: Programowanie w C

#36

Post napisał: upanie » 15 lis 2022, 16:01

Śmieszny jesteś.
czilałt...

Awatar użytkownika

tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 12
Posty: 7861
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: Programowanie w C

#37

Post napisał: tuxcnc » 15 lis 2022, 16:03

upanie pisze:
15 lis 2022, 16:01
Śmieszny jesteś.
Idź sobie pobiegać.
EOT.

Awatar użytkownika

grg12
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 8
Posty: 1670
Rejestracja: 03 sty 2007, 14:27
Lokalizacja: Wiedeń

Re: Programowanie w C

#38

Post napisał: grg12 » 15 lis 2022, 18:38

tuxcnc pisze:
15 lis 2022, 15:25

Kod: Zaznacz cały

if (TIM2->CR1 & 0x10)
  {
          timer2_ovf-=0xFFFF;
  }
  else
  {
          timer2_ovf+=0xFFFF;
  }
Pozwolę sobie skrytykować:
1. Kod jest kompletnie nieprzenośny.
2. Nie zawiera komentarza wyjaśniającego co dokładnie robi i dlaczego - jeśli dasz go komuś kto nie zna tego konkretnego procesora tak dokładnie jak ty albo dostanie go bez informacji na jaki proc jest przeznaczony to... będzie wesoło
3. Jest prawdopobne że nowoczesny kompilator zoptymalizowałby kod bez twojej "pomocy" :)

Awatar użytkownika

tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 12
Posty: 7861
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: Programowanie w C

#39

Post napisał: tuxcnc » 15 lis 2022, 19:27

grg12 pisze:
15 lis 2022, 18:38
1. Kod jest kompletnie nieprzenośny.
Jest nieprzenośny i taki ma być, bo odwołuje się do unikalnego sprzętu.
grg12 pisze:
15 lis 2022, 18:38
2. Nie zawiera komentarza
Zawiera. Złośliwie i z premedytacją go pominąłem.
grg12 pisze:
15 lis 2022, 18:38
3. Jest prawdopobne
Nie jest.

Ogólnie to ten kod miał być tylko przykładem, że nie tylko warto znać budowę procesora na który się pisze kod, ale nawet czasem jest to konieczne.
Tutaj (STM32) jest na przykład taka heca, że procesor jest 32-bitowy, ale licznik tylko 16-bitowy. Skąd ktoś traktujący procesor jako "czarną skrzynkę" ma wiedzieć jakiego typu zmiennych użyć?
Oczywiście ktoś piszący program na peceta nie musi wiedzieć co to jest tablica deskryptorów, ale jakieś ogólne pojęcie o budowie procesora mieć trzeba, choćby żeby wiedzieć dlaczego bardzo podobny kod wykonuje się dziesięć razy wolniej...


drzasiek90
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 7
Posty: 1760
Rejestracja: 25 kwie 2016, 11:58
Lokalizacja: Jodlowa
Kontakt:

Re: Programowanie w C

#40

Post napisał: drzasiek90 » 15 lis 2022, 19:51

A ja podzielam zdanie obu panów :)
Generalnie tendencję do tworzenia programistów oderwanych od sprzętu są. To nic złego, jeśli chodzi o programowanie w systemie. Natomiast jeśli chodzi o programowanie uC, to zazwyczaj jest to ściśle związane ze sprzętem (nie tylko uC) i moim zdaniem oderwać od sprzętu się tego nie da.
Kod tego typu co przedstawił tux jest rzeczywiście beznadziejny, ponieważ nie ma żadnego usprawiedliwienia aby wpisywać do rejestru (czy zmiennej) w taki sposób a tym bardziej, aby sprawdzać flagę w taki sposób.
Od tego są definicje poszczególnych bitów, zawierające ich nazwy. Odszukanie potem w dokumentacji, co było ustawione jest o wiele prostsze. A kompilator i tak to zamieni na to samo.

Co do przenośności kodu. Ja mam takie obserwacje, że przenośność kodu na uC to tylko takie chwytliwe hasełko, mające na celu zachęcić do używania bibliotek. Same biblioteki nie są złe, pod warunkiem, że nie zawierają błędów i używa się je świadomie. Ale tak naprawdę, uC używa się konkretnie pod dane zastosowanie, typowo związane z peryferiami które uC posiada i ze sprzętem towarzyszącym.
Ja z założenia od początku pisałem na rejestrach, ale nie tak radykalnie jak to przedstawił tux. Używam do tego definicji, które do tego zostały stworzone i powodują, że kod jest przejrzysty i czytelny (dla mnie dużo bardziej czytelny niż w przypadku używania bibliotek) i nigdy nie miałem problemów, żeby fragment kodu przenieść na inny uC (oczywiście w ramach rodziny).

Ale wracając do początku,
Jak kiedyś nie było gotowych środowisk do STM32 tak teraz mamy ich nadmiar, między innymi CUBE. Jest to dobrodziejstwo ale i przekleństwo, ponieważ tworzy z programisty klikacza. Zamiast zaglądnąć do manuala i ustawić kilka rejestrów, wyklikuje konfogurację i w gruncie rzeczy nie ma pojęcia jak i co ustawił. Następnie przechodzi do pisania programu traktując sprzęt jak abstrakcję. Wszystko fajnie, dopóki działa. Ale jak pojawiają się problemy, coś nie działa, pewne zależności to taki programista/kilkacz nie umie sobie z tym poradzić, przecież wyklikał wszystko dobrze.

Dlatego moim zdanie, tworzenie warstwy abstrakcyjnej-owszem ale na oprogramowaniu, gdzie program to w większości algorytmy oderwane od sprzętu. Natomiast jeśli tworzy się program który bezpośrednio steruje sprzętem, moim zdaniem im poziom niższy tym kontrola i przewidywalność większa.

ODPOWIEDZ Poprzedni tematNastępny temat

Wróć do „Na luzie”