C Lernen



  • Hallo Zusammen,
    und zwar möchte Ich sehr gerne die Programmiersprache C lernen dazu habe ich folgendes Buch entdeckt http://de.wikibooks.org/wiki/C-Programmierung was haltet Ihr von dem Buch? Ist es ganz ok zum lernen oder eher nicht wenn nein welches Buch könnt ihr mir da empfehlen?
    Arbeiten tue ich mit Netbenas und MinGW.
    Gruß
    n122vu



  • Ich finde das Buch vom Erlenkötter sehr gut, weil es recht ordentlich didaktisch aufgebaut ist, nicht teuer, nicht zuviel, aber weniger ist mehr in diesem Fall. Allenfalls ein wenig zu alt, das macht aber nichts.



  • C ist doch komplett nutzlos, lern lieber C++.



  • Naja nutzlos würde ich nicht sagen. oder warum werden imme rnoch viele Programme (auch im UNIX Umfeld) in C geschrieben? Bestimmt nicht weil es nutzlos ist.



  • Weil die Leute zu stur sind, auf C++ umzusteigen. Niemand verwendet heutzutage freiwillig C, ausser Fanatiker und Leute die fuer Plattformen schreiben, die keinen C++ Compiler haben.



  • Kellerautomat schrieb:

    C ist doch komplett nutzlos, lern lieber C++.

    Es ist wie mit der Schönheit: liegt immer im Auge des Betrachters.

    Für manche Sachen benutzt man einfach kein C++. Oder hast du schon mal einen buffer overflow exploit in C++ gesehen? Ich nicht.

    Deine Sicht der Welt scheint begrenzt zu sein.

    EDIT:
    Entweder du kannst Assembler und C und stehst drauf oder du bist einfach nur ein - naja, Kellerautomat.



  • EOP schrieb:

    Für manche Sachen benutzt man einfach kein C++. Oder hast du schon mal einen buffer overflow exploit in C++ gesehen? Ich nicht.

    Das liegt aber nicht am Mangel an C++, dort wäre es genauso möglich.
    Es ist lediglich die "Sturheit" wie Kellerautomat schrieb bzw. das Umfeld/die Gewohnheit das so zu verwenden. Insofern hast du schon recht, das man für manche Sachen kein C++ verwedent; es gibt aber keinen* rationalen Grund für C++ gegenüber C.

    *Außer jetzt vielleicht Compiler-Support. Schaltet man Exceptions und RTTI ab und liest die Spezfikation von VTable seines Compilers, weiß man genau, was C++ macht. Und essentielle Features wie Templates und Syntaxzucker wie Memberfunktionen und public/private wirken sich nicht auf den Assemblercode aus.



  • C ist fuer manche Programme ganz gut geeignet und wenn ich mal irgendwas in assembler schreibben muss, gehe ich das erstmal in C durch und konvertiere dann. Ich bin auch der Ansicht, dass jeder Programmierer C koennen sollte, wenn auch nicht alle Sonderregeln und nicht alle Patterns.
    Das nervige ist aber, dass in C jedes kleine prograemmchen seine eigenen verketteten listen, hastables und manchmal auch noch eigene strings und dynamische arrays mitbringt, weil es dank fehlender generics kaum universell brauchbare standardlibraries gibt. Das ist schwierig zu lesen, auch wenn das C programmierer gerne anders sehen wollen, fehleranfaellig und schnell ist es auch nicht immer.



  • Nathan schrieb:

    es gibt aber keinen* rationalen Grund für C++ gegenüber C.

    1. Wenn du eine C ABI brauchst. Du könntest jede Datei in ein extern "C" {} wrappen. Wenn sowieso die ganze Schnittstelle C-kompatibel bleiben muss, dann kannst du dir zwar schon überlegen C++ zu verwenden, aber in C ist das weniger Aufwand.
    2. Man wird nicht verleitet, falsche C++-Features zu verwenden. Dieses Argument von Linus ist trotz allem richtig. Sich auf C zu beschränken macht den Code für Anfänger leichter lesbar (da weniger Features), hält ihn einheitlich (da es nicht tausend Paradigmen gibt, ein Problem anzugehen) und macht den Assembler-Code besser vorhersehbar. Und nichts ist besser als eine Coding-Guideline, die vom Compiler enforced wird.

    Es gibt Gründe C statt C++ zu verwenden, auch wenn es nicht sehr viele sind.

    Es gibt noch viel mehr Gründe, C statt C++ zu lernen.

    Und es gibt auch viele Gründe [Programmiersprache X] statt C++ zu verwenden.



  • Marthog schrieb:

    Das nervige ist aber, dass in C jedes kleine prograemmchen seine eigenen verketteten listen, hastables und manchmal auch noch eigene strings und dynamische arrays mitbringt, weil es dank fehlender generics kaum universell brauchbare standardlibraries gibt.

    Es ist sehr einfach, generische verlinkte Listen zu schreiben. Nur können C++-Programmierer das nicht in C, weil sie intrusive Listen verlernt haben. Schau im Linux-Kernel nach, wie man verlinkte Listen generisch macht.



  • Marthog schrieb:

    C ist fuer manche Programme ganz gut geeignet und wenn ich mal irgendwas in assembler schreibben muss, gehe ich das erstmal in C durch und konvertiere dann. Ich bin auch der Ansicht, dass jeder Programmierer C koennen sollte, wenn auch nicht alle Sonderregeln und nicht alle Patterns.

    Guter Punkt.

    Ich hab früher auch oft erst Programme in C geschrieben und mir dann den assembler-output von TurboC angesehen und optimiert (war ne gute Funktion von TurboC).

    Ich kann auch nicht sämtliche Regeln und Sonderregeln von C.
    Macht aber nix, ich kann funktionierende Programme in C scheiben.

    Ob mein Stil jetzt Unwissenheit ist und Anderen die Tränen in die Augen und den Schweiß auf die Stirn treibt oder gar beabsichtigter Quatsch ist, bleibt dem geneigten Leser überlassen.

    Ich hab jedenfalls meinen Spaß dabei und hoffentlich auch ein oder zwei members.



  • bindingwriter schrieb:

    Nathan schrieb:

    es gibt aber keinen* rationalen Grund für C++ gegenüber C.

    1. Wenn du eine C ABI brauchst. Du könntest jede Datei in ein extern "C" {} wrappen. Wenn sowieso die ganze Schnittstelle C-kompatibel bleiben muss, dann kannst du dir zwar schon überlegen C++ zu verwenden, aber in C ist das weniger Aufwand.

    Trotzdem kann man die Implementierung in C++ schreiben, die wird dann einfacher. Insbesondere bei Bibliotheken mit kleinem Interface aber Unmenge an Implementierung (z.B. Interpreter).

    2. Man wird nicht verleitet, falsche C++-Features zu verwenden. Dieses Argument von Linus ist trotz allem richtig. Sich auf C zu beschränken macht den Code für Anfänger leichter lesbar (da weniger Features), hält ihn einheitlich (da es nicht tausend Paradigmen gibt, ein Problem anzugehen) und macht den Assembler-Code besser vorhersehbar. Und nichts ist besser als eine Coding-Guideline, die vom Compiler enforced wird.

    Gut, das mag sein. Aber auf der anderen Seite hat man auch nicht die richtigen. Und da hätte ich es lieber so rum.

    Es gibt noch viel mehr Gründe, C statt C++ zu lernen.

    Und es gibt auch viele Gründe [Programmiersprache X] statt C++ zu verwenden.

    Beide Punkte habe ich nie abgestritten. C zu können, so Lowlevel zu denken, ist hilfreich.

    bindingwriter schrieb:

    Marthog schrieb:

    Das nervige ist aber, dass in C jedes kleine prograemmchen seine eigenen verketteten listen, hastables und manchmal auch noch eigene strings und dynamische arrays mitbringt, weil es dank fehlender generics kaum universell brauchbare standardlibraries gibt.

    Es ist sehr einfach, generische verlinkte Listen zu schreiben. Nur können C++-Programmierer das nicht in C, weil sie intrusive Listen verlernt haben. Schau im Linux-Kernel nach, wie man verlinkte Listen generisch macht.

    Ich glaube die meisten guten C++ Programmierer können verkettete Listen im Schlaf schreiben. Der Punkt ist aber, dass diese Dinge nicht in der Standardbibliothek sind. Die C-Standardbibliothek ist extrem klein.



  • Nathan schrieb:

    bindingwriter schrieb:

    Nathan schrieb:

    es gibt aber keinen* rationalen Grund für C++ gegenüber C.

    1. Wenn du eine C ABI brauchst. Du könntest jede Datei in ein extern "C" {} wrappen. Wenn sowieso die ganze Schnittstelle C-kompatibel bleiben muss, dann kannst du dir zwar schon überlegen C++ zu verwenden, aber in C ist das weniger Aufwand.

    Trotzdem kann man die Implementierung in C++ schreiben, die wird dann einfacher. Insbesondere bei Bibliotheken mit kleinem Interface aber Unmenge an Implementierung (z.B. Interpreter).

    Trotzdem kann es bei grossem Interface und wenig Implementierungslogik von Vorteil sein, C zu verwenden. Ist eine Nische, aber kann vorkommen.

    Nathan schrieb:

    bindingwriter schrieb:

    Marthog schrieb:

    Das nervige ist aber, dass in C jedes kleine prograemmchen seine eigenen verketteten listen, hastables und manchmal auch noch eigene strings und dynamische arrays mitbringt, weil es dank fehlender generics kaum universell brauchbare standardlibraries gibt.

    Es ist sehr einfach, generische verlinkte Listen zu schreiben. Nur können C++-Programmierer das nicht in C, weil sie intrusive Listen verlernt haben. Schau im Linux-Kernel nach, wie man verlinkte Listen generisch macht.

    Ich glaube die meisten guten C++ Programmierer können verkettete Listen im Schlaf schreiben. Der Punkt ist aber, dass diese Dinge nicht in der Standardbibliothek sind. Die C-Standardbibliothek ist extrem klein.

    Man schreibt doch nicht alles selbst. Wer in C nur die Standardbibliothek verwendet, hat dazu vielleicht Gründe (µC), aber es ist durchaus möglich eine fertige generische verlinkte Liste aus einer Bibliothek zu holen.
    (Und ich schrieb oben nicht, dass C++-Programmierer keine verlinkte Liste schreiben können, sondern gar nicht wissen, was eine intrusive Liste ist)



  • bindingwriter schrieb:

    Nathan schrieb:

    Trotzdem kann man die Implementierung in C++ schreiben, die wird dann einfacher. Insbesondere bei Bibliotheken mit kleinem Interface aber Unmenge an Implementierung (z.B. Interpreter).

    Trotzdem kann es bei grossem Interface und wenig Implementierungslogik von Vorteil sein, C zu verwenden. Ist eine Nische, aber kann vorkommen.

    In der Hinsicht muss ich dir rechtgeben. Allerdings muss man für C-Header für C++-Kompatibilität sowieso extern "C" drumherum packen, also ist das nicht viel anders als in C++.

    Nathan schrieb:

    Ich glaube die meisten guten C++ Programmierer können verkettete Listen im Schlaf schreiben. Der Punkt ist aber, dass diese Dinge nicht in der Standardbibliothek sind. Die C-Standardbibliothek ist extrem klein.

    Man schreibt doch nicht alles selbst. Wer in C nur die Standardbibliothek verwendet, hat dazu vielleicht Gründe (µC), aber es ist durchaus möglich eine fertige generische verlinkte Liste aus einer Bibliothek zu holen.

    Trotzdem ist das dann mehr Aufwand. Ich denke da jetzt an Beispielprogramme oder so ein Programm, was mal schnell eben geschrieben werden muss. Es direkt dabei zu haben, ohne Bibliotheken, ist da von Vorteil. Aber generell hast du recht.
    Und mit generisch meinst du void*? Ist imo nicht ganz so toll wie Templates o.ä.

    (Und ich schrieb oben nicht, dass C++-Programmierer keine verlinkte Liste schreiben können, sondern gar nicht wissen, was eine intrusive Liste ist)

    Ich hoffe doch sehr, dass das nicht stimmt. Ansonsten muss ich Torvalds Statement darüber, dass C++ immerhin die Nichtskönner aus C raushält, leider zustimmen.



  • bindingwriter schrieb:

    Es ist sehr einfach, generische verlinkte Listen zu schreiben. Nur können C++-Programmierer das nicht in C, weil sie intrusive Listen verlernt haben. Schau im Linux-Kernel nach, wie man verlinkte Listen generisch macht.

    Ich kann verkettete listen machen. Nur in den meisten Faellen lohnen sie sich nicht, weil z.B. std::deque in der Komplexitaet gleich, aber sehr viel cache-effizienter ist. Die C programmierer machen aber munter weiter ihre Listen, weil sie so schoen einfach zu implementieren sind. Ich habe sogar mal gesehen, dass listen fuer stacks eingesetzt werden, die Anwendungsgebiete fuer vector und deque schlechthin.

    Ich habe mir in den letzten Tagen den Sourcecode von zsh und manchen lxde-programmen mal angeschaut und den Eidnruck, dass man teilweise bis zur Haelfte des Codes sparen koennte, wenn man nur die C++-standard library haette.

    bindingwriter schrieb:

    Man schreibt doch nicht alles selbst. Wer in C nur die Standardbibliothek verwendet, hat dazu vielleicht Gründe (µC), aber es ist durchaus möglich eine fertige generische verlinkte Liste aus einer Bibliothek zu holen.

    Dabei ist man aber nicht immer so schnell. Das klassische Beispiel ist wohl qsort vs. std::sort. qsort arbeitet mit funktions-pointern und void*. Das bedeutet erstens unuebersichtliches casten zum anderen koennen die Funktionspointer nur sehr schwer geinlined werden. Bei std::sort hingegen uebergibt man ein functor-object oder nutzt den Vergleichsoperator und das kann problemlos zur compilezeit eindeutig zugeordnet und geinlined werden.



  • Ohne jetzt auf eure pseudoakademischen Beiträge einzugehen:

    Jeder der programmieren will sollte auch etwas Ahnung davon haben was hinter dem Vorhang passiert. Da ist C wesentlich geeigneter als C++.



  • Hi,
    also ich habe jetzt hier mal mit gelesen. Seit mir nicht böse aber schweifen wir nicht zu sehr vom Thema ab?? Klar gibt es gründe Programmiersprache x Programmiersprache Y vor zu ziehen und umgekehrt auch. ich möchte trotzdem ganz gerne erst einmal C lernen und wenn ich diese halbwegs vernünftig vertshe/behersche meine ersten Programme geschrieben habe, dann kann ich immer noch C++ lernen.
    Also zurück zum eigentlichem Thema wer kann mir welches Buch empfehlen und warum?



  • n122vu schrieb:

    Seit mir nicht böse aber schweifen wir nicht zu sehr vom Thema ab??

    Ist leider irgendwie Standard hier. Viele wollen mit ihrem fantastischen Wissen prahlen. Hab das auch schon mehrfach bemängelt, ist aber so.

    Einen guten Tip für ein gutes Buch kann ich dir leider auch nicht geben. Sorry.



  • Wenn du C brauchst, dann lerne es. Wenn du C++ brauchst, dann lerne es. Wenn du Java brauchst, dann lerne es. Wenn du Python brauchst, dann lerne es.

    Wo ist das Problem?



  • Ihr versteht glaub ich die Frage nicht so ganz oder?? naja auch egal der Theread kann geschlossen werden, werde diese Frage in nem anderen Forum stellen!


Log in to reply