Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Uczenie się "systemowego" C (gcc) na podstawie Linuxa/Unixa

lukagrom 11 Gru 2017 13:46 288 9
  • #1 11 Gru 2017 13:46
    lukagrom
    Poziom 15  

    Pytanie jak w temacie. Przeglądam kilka książek poświęconym tematyce programowania w C w Linuxie, gdzie omawiane są zagadnienia związane z pisaniem aplikacji w C obejmujących przykłady oscylujące wokół wykorzystywania kompilacji, bibliotek, procesów, wątków, sygnałów, urządzeń, wywołań systemowych, systemu plików, wykorzystanie w kodzie asemblera, bezpieczeństwa i różnych funkcji wewnętrznych unixowych. Na chwilę obecną ta wiedza jest już "archaiczna" i znajduje jedyne uzasadnienie w pasji poznawczej, czy też dzięki znajomości tych technik i umiejętności, można coś zawojować? (rynek pracy, zlecenia , podstawa do wyjścia w jakieś nowe obszary, etc.)

    0 9
  • #2 11 Gru 2017 14:33
    3029369
    Użytkownik usunął konto  
  • #3 11 Gru 2017 14:53
    lukagrom
    Poziom 15  

    Coś jest na rzeczy - google- programowanie jądra - pierwsza oferta - "programista jądra Linux/Android" - znajomość gcc(debugger, komplator,linker,make), C/C++, algorytmika, schematy elektr, -11 tys (Warszawa)

    0
  • #4 11 Gru 2017 15:31
    3029369
    Użytkownik usunął konto  
  • #5 11 Gru 2017 15:41
    lukagrom
    Poziom 15  

    Chyba więc "Język ANSI C" z 1978r Ritchiego i Kernighana niekoniecznie oddawać na makulature.

    0
  • #6 11 Gru 2017 16:23
    JacekCz
    Poziom 36  

    lukagrom napisał:
    Pytanie jak w temacie. Przeglądam kilka książek poświęconym tematyce programowania w C w Linuxie, gdzie omawiane są zagadnienia związane z pisaniem aplikacji w C obejmujących przykłady oscylujące wokół wykorzystywania kompilacji, bibliotek, procesów, wątków, sygnałów, urządzeń, wywołań systemowych, systemu plików, wykorzystanie w kodzie asemblera, bezpieczeństwa i różnych funkcji wewnętrznych unixowych. Na chwilę obecną ta wiedza jest już "archaiczna" i znajduje jedyne uzasadnienie w pasji poznawczej, czy też dzięki znajomości tych technik i umiejętności, można coś zawojować? (rynek pracy, zlecenia , podstawa do wyjścia w jakieś nowe obszary, etc.)


    Pracując poza kernelem Linuxa chyba dwa razy w życiu musiałem przeczytać kod C z głęboko unixowym/posixowym API (w celu spatchowania czy obejścia). MIlion lat temu nawet spatchowałem sobie jakiś sterownik (w wersji alfa siedział manualny błąd, akurat sam siebie podał na tacy). Warto wiedzieć "o co kaman" na poziomie czytania kodu.

    Podobnie jak zwichnięcie nauki C na mikroprocesorach, na głębokim API uniksowym tez źle się uczyć samego języka.
    Dodano po 3 [minuty]:
    Pong.Chu napisał:
    Elektroda to słabe miejsce na takie pytania nie znajdziesz tutaj ludzi mogących dać Ci odpowiedź...


    ale za to w makrach do offisa rozwijanych metodyką Copiegoi & Pasta, oraz budowaniu prowizorek ... eldorado
    Dodano po 2 [minuty]:
    lukagrom napisał:
    Chyba więc "Język ANSI C" z 1978r Ritchiego i Kernighana niekoniecznie oddawać na makulature.


    a z lat 80tych może być?
    Nie był jeszcze wtedy ANSI.

    Język poszedł do przodu, sens jest ten sam.
    Chyba najdalsze od współczesności jest ówczesne definiowanie funkcji z typami argumentów w body (nawet nie pamiętam dokładnie jak to się pisało)
    Zdecydowanie ten obszar warto pochwalić, nauka samego języka. Tam chyba tylko wzmianka jest na temat ioctl() , żeby wiedzieć, że gdzieś dzwonią.

    0
  • #7 11 Gru 2017 16:28
    lukagrom
    Poziom 15  

    "Body" to chyba w HTML-u, argumenty funkcji C chyba nie podlegały ewolucji zapisu.

    0
  • #8 11 Gru 2017 16:31
    JacekCz
    Poziom 36  

    lukagrom napisał:
    "Body" to chyba w HTML-u, argumenty funkcji C chyba nie podlegały ewolucji zapisu.


    ok, niekoniecznie 'body' w ścisłym sensie, ale coś w tym rodzaju.

    Kod: c
    Zaloguj się, aby zobaczyć kod

    wklejka jest za StackOverflow, ale umiejscowienie w epoce chyba prawidłowe.
    W konsekwencji (chyba) kompilatory nie mogły wychwycić rozbieżności typów, stąd ówczesne defaulty "wszystko, co nie zadekalrowane to ineteger" itd)

    Realne kompilatory (Borland czy MS) ok 1985-87 już to akceptowały w konwencji ANSI. Starszej konwencji nie znam w własnego klepanego kodu, tylko właśnie z książki WNT.

    0
  • #9 11 Gru 2017 16:41
    lukagrom
    Poziom 15  

    Mnie już zniechęca na samym początku -getopt_long, tą podstawową funkcję dla przetwarzania lini poleceń, pisali ewidentnie obcy, Za cienki jestem w te klocki, pozostawiam bystrzejszym.

    0
  • #10 11 Gru 2017 16:46
    JacekCz
    Poziom 36  

    lukagrom napisał:
    Mnie już zniechęca na samym początku -getopt_long, tą podstawową funkcję dla przetwarzania lini poleceń, pisali ewidentnie obcy, Za cienki jestem w te klocki, pozostawiam bystrzejszym.


    ZTCP nigdy, na żadnym etapie podobne funkcje nie były w rdzeniu biblioteki standardowej (ani posixowej itd), tylko w dodatkowych utilsach. Było sporo rozwiązań, niektóre całkiem przyjemne. Nawet nie wiem dokładnie, o której mówisz.
    Rdzeń języka to argc, argv.

    0