Warum ist C so toll?

[Bronzegraf]

Davon mal abgesehen machen deine Codebeispiele eh nicht dasselbe.

 

[Atheist2]

Original geschrieben von Morag


Was willst du denn für einen Kommentar an einem allgemeinen Beispiel?

Solchen Code sollte man tunlichst (zumindest in C, Pascal ist recht selbsterklärend) kommentieren. Sonst weiß ja niemand mehr, was du dabei wieder geraucht hast.

 

[Whcttyh]

c ist genauso selbsterklaerend, man muss es nur koennen.

 

[Bronzegraf]

Gut, daß das eben ein Widerspruch war -.-

 

[Atheist2]

Original geschrieben von [UEP]Xyz
c ist genauso selbsterklaerend, man muss es nur koennen.

Assembler ist selbsterklärender. Auch wenn man es nicht kann.

 

[Morag]

Original geschrieben von Atheist
Solchen Code sollte man tunlichst (zumindest in C, Pascal ist recht selbsterklärend) kommentieren. Sonst weiß ja niemand mehr, was du dabei wieder geraucht hast.

was bitteschön soll ich an 1+1 kommentieren? Denk dir für alle Bezeichner die du nicht kennst was hübsches aus.
Sieht man mal davon ab, dass geschachtelte Funktionsaufrufe in C Standard sind. Das ist einer der Gründe warum man Pascal für die Schule nimmt und C zum arbeiten.

@Bronzegraf: hmm ok, denk dir nen <> (hoff ich zumindest, mein letztes Pascal Proggie ist Jahre her)

 

[Whcttyh]

oh stimmt ja
neuer versuch:
c ist sehr leicht zu lesen, wenn man es kann, genauso wie pascal. dies ist entscheidend, denn jemand der keine ahnung davon hat muss/soll es auch nicht verstehen (der wird pascal imho auch nur schwer verstehen).

 

[Morag]

Original geschrieben von [UEP]Xyz
denn jemand der keine ahnung davon hat muss/soll es auch nicht verstehen (der wird pascal imho auch nur schwer verstehen).

C ist IMHO schon schwerer zu lesen als Pascal. Pascal ist schließich auf didaktisch wertvoll optimiert. Der Code eines durschnittlichen Pascal coders sieht fast genauso aus wie der eines Experten.
C-Code ist da schon extrem vom Können des Coders abhängig, da einige Sachen schon deutlich mächtiger/flexibler sind (z.B. Vergleich der for-Schleife).


Aber was ich eigenlich los werden wollte, für alle die es noch nicht kennen und glauben C wär einfach zu lesen:

www.ioccc.org

 

[Whcttyh]

aber eben diese flexibilitaet, also z.B. knappe anweisungen, macht teilweise den code lesbarer finde ich. aber ist wohl letztendlich auch nicht so wichtig, jeder mensch hat halt andere vorlieben und jemand der was kann versteht es auch und die die es nicht koennen sollen anderen arbeiten nachgehen

 

[The_Company]

Original geschrieben von Morag
@company: Du hast Idee OO nicht verstanden. Dann hilft dir auch nicht wenn du weißt wie es implementiert ist.

Doch, ich habe sie sehr wohl verstanden.
Ich sagte nur (extra nochmal für Dich):
OOP ist ein Programmierparadigma, dass in eigentlich jeder gängigen Sprache funktioniert. In C auf jeden Fall.

Und dann noch mal einen grossen Dank an die Person, die Zuweisungen in einen If Befehl packt, damit jeder beim überfliegen des Codes denkt, das sei ein "==", denn welcher Depp macht sowas schon in nem if. Zum in den Fuss schiessen ist C halt unschlagbar, selbst für Leute, die damit angeben wollen...

 

[Morag]

Original geschrieben von The_Company
Und dann noch mal einen grossen Dank an die Person, die Zuweisungen in einen If Befehl packt, damit jeder beim überfliegen des Codes denkt, das sei ein "==", denn welcher Depp macht sowas schon in nem if. Zum in den Fuss schiessen ist C halt unschlagbar, selbst für Leute, die damit angeben wollen...

Auch auf die Gefahr hin mich zu wiederholen. Eine Zuweisung ist ein Statement ist ein legales Argument in einer if Anweisung.

Und konkrete Beispiele wie if( !(file=fopen(<path>)) ) ...
sind nun wirklich standard. Und ja C ist schwerer zu lesen. Aber ich traue es einfach mal jedem zu ein = von einem == zu unterscheiden. Vor allem weil beides des öfteren an solchen Stellen zu finden ist.

Original geschrieben von The_Company
Doch, ich habe sie sehr wohl verstanden.
Ich sagte nur (extra nochmal für Dich):
OOP ist ein Programmierparadigma, dass in eigentlich jeder gängigen Sprache funktioniert. In C auf jeden Fall.

Ich versuchs mal anders. Du hast technisch verstanden was OOP ist. Aber du hast nicht die Philosophie dahinter verstanden oder ignorierst sie geflissentlich:

Original geschrieben von The_Company
- alles ist möglich, kein "Sorry, die Variable ist private" oder son Mist

Wie man hier leicht sieht. Das zeigt daß du Code Kapselung entweder nicht verstanden hast oder verstehen willst. Jeder C++ Kompiler schluckt C-Code, aber dein C-Code wird dadurch nicht C++.

 

[Observator]

Original geschrieben von Bronzegraf
Davon mal abgesehen machen deine Codebeispiele eh nicht dasselbe.

Doch, seine Beispiele machen dasgleiche, zumindest wenn foo ein unsigned Integer-Typ ist.

 

[The_Company]

if (x = y) gibt heutzutage auf jedem vernünftigen Compiler ne Warnung aus und wird eigentlich überall if ((x=y)) geschrieben.
Und dann fragt man sich als Nubie wieder wieso da 2 Klammern sind, also isses nicht wirklich besser

Code Kapselung ist der grösste Mist aller Zeiten, aber das ist meine persönliche Meinung. Ich bevorzuge es den kompletten Code public zu machen und "/* private */" daneben zu schreiben. Hat den gleichen Effekt, nur man kommt ran, wenn mans haben muss.
Der Unterschied ist, dass Kapselung den Programmierer zum Idioten erklärt, weil es ihm etwas verbietet während meine Methode dem Programmierer Verantwortung überträgt.
Aber es gibt halt Leute, für die braucht man das.

Und ich habe sehr wohl OOP begriffen, ich bin nur kein blinder Bewunderer von dem ganzen Mist (s.o.).

 

[Atheist2]

Original geschrieben von The_Company
Der Unterschied ist, dass Kapselung den Programmierer zum Idioten erklärt, weil es ihm etwas verbietet während meine Methode dem Programmierer Verantwortung überträgt.
Aber es gibt halt Leute, für die braucht man das.

Ich wei nicht, was du da treibst, aber ich hatte noch nie Probleme mit lokalen Variablen.

 

[Bronzegraf]

Original geschrieben von The_Company
Code Kapselung ist der grösste Mist aller Zeiten, aber das ist meine persönliche Meinung. Ich bevorzuge es den kompletten Code public zu machen und "/* private */" daneben zu schreiben. Hat den gleichen Effekt, nur man kommt ran, wenn mans haben muss.

Es ist manchmal aber viel besser, dem Programmierer nicht unbedingt Zugang zu _allen_ Daten zu geben. Denn wenn er, ermutigt durch seine "Rechte", irgendwelche Werte auf unerwünschte Art und Weise ändert, können ziemlich lästige Seiteneffekte auftreten. Deshalb bevorzuge ich getter/setter - Methoden, die halt nur nach Prüfung Änderungen zulassen.

 

[The_Company]

Es ist besser, wenn der Programmierer Zugriff zu allen Daten hat, er aber weiss, dass das verändern bestimmter Werte ohne die Getter und Setter nicht gemacht werden soll.
Dann kann man ihm nämlich sagen "selber Schuld", wenn ers versemmelt, aber er kann es wenigstens versemmeln.


Das wäre ungefähr so, als würden alle Autos automatisch nur die Höchstgeschwindigkeit fahren, die auf der Strasse erlaubt ist.
Das ist absolut in Ordnung. Zumindest solange bis Dein kleiner Bruder blutüberströmt die Treppe runtergefallen ist und Dein PKW nur mit 30 in Richtung Krankenhaus fährt.

 

[Atheist2]

Original geschrieben von The_Company
Das wäre ungefähr so, als würden alle Autos automatisch nur die Höchstgeschwindigkeit fahren, die auf der Strasse erlaubt ist.
Das ist absolut in Ordnung. Zumindest solange bis Dein kleiner Bruder blutüberströmt die Treppe runtergefallen ist und Dein PKW nur mit 30 in Richtung Krankenhaus fährt.

Du kannst auch lokale Variablen durch wildes Pointerschießen überall verwenden. Nur solltest du das nur tun, wenn nötig.

 

[Observator]

Es geht aber nicht um lokale Variablen (sondern um Klassen; private, protected Variablen und Funktionen darin). Lern was über C++ , bevor du weiter deine "Weisheiten" verbreitest, oder geh zurück zu deinem Pascal und sei damit glücklich .

 

[The_Company]

Original geschrieben von Atheist
Du kannst auch lokale Variablen durch wildes Pointerschießen überall verwenden. Nur solltest du das nur tun, wenn nötig.

Genau das sag ich ja. Aber es sollte möglich sein, damit ichs tun kann, wenns nötig ist

 

[Atheist2]

Original geschrieben von Imperator
Es geht aber nicht um lokale Variablen (sondern um Klassen; private, protected Variablen und Funktionen darin). Lern was über C++ , bevor du weiter deine "Weisheiten" verbreitest, oder geh zurück zu deinem Pascal und sei damit glücklich .

Mir ist das Konzept von Klassen durchaus bekannt, die gibt es schließlich auch in FPC. Nur ist der Unterschied zu lokalen Variablen marginal und der Grund das sie Privat sind meist ein guter.

 

[Koestritzer]

Original geschrieben von The_Company

Code Kapselung ist der grösste Mist aller Zeiten, aber das ist meine persönliche Meinung. Ich bevorzuge es den kompletten Code public zu machen und "/* private */" daneben zu schreiben. Hat den gleichen Effekt, nur man kommt ran, wenn mans haben muss.
Der Unterschied ist, dass Kapselung den Programmierer zum Idioten erklärt, weil es ihm etwas verbietet während meine Methode dem Programmierer Verantwortung überträgt.
Aber es gibt halt Leute, für die braucht man das.

Und ich habe sehr wohl OOP begriffen, ich bin nur kein blinder Bewunderer von dem ganzen Mist (s.o.).

damit hast du wiedermal zugegeben das du von oop überhaupt nichts verstehst.
das mag vielleicht alles gut und schön sein wenn du alleine an
nem kleinen proggi arbeitest, spätestens wenn du professionell
in ner grösseren firma im team an nem riesen projekt arbeitest
wirst du dir aber auf diese art und weise selber mehr arbeit machen als eigentlich nötig.

ein beispiel:
du schreibst ne klasse die diverse interne variablen hat die aber
eigentlich nicht von aussen verändert werden sollten weil sie sonst das ergebnis unbeabsichtigt verändert werden können.
wenn die klasse jetzt einen gewissen umfang erreicht hat und
derjenige sich nicht unbedingt erst die doku davon reinzieht (oder den source löl) damit er weiss welche variable für was is oder welche funktion was macht, dann wird er vielleicht die falschen benutzen und dadurch wird das bugfixing unnötig erschwert.

die lösung wäre in dem fall diese sachen private zu machen und
wirklich nur die schnittstellen der klasse public zu lassen, dadurch
kann sowas nicht passieren.

 

[The_Company]

Was zieht er sich denn rein, wenn nicht entweder Doku oder Source?

Abgesehen davon steht über diese "private" Variablen ausser im Source nirgendwo was geschrieben (schliesslich sind sie nicht öffentlich), also muss er schon im Source wühlen um überhaupt zu wissen, dass es sie gibt.

 

[Koestritzer]

da gibts sone lustigen ide's wie zum bleistift bei visual studio, die bieten dir ne liste mit klassenmembers an sobald du draufzugreifen willst.

 

[Morag]

Original geschrieben von The_Company
Was zieht er sich denn rein, wenn nicht entweder Doku oder Source?

Abgesehen davon steht über diese "private" Variablen ausser im Source nirgendwo was geschrieben (schliesslich sind sie nicht öffentlich), also muss er schon im Source wühlen um überhaupt zu wissen, dass es sie gibt.

Das liegt daran, daß du die privates nicht brauchst und du da auch nichts dran zu suchen hast.

Und bei großen Projekten wirst du froh sein, wenns ne Doku gibt. Koestritzer hat recht, das gilt nicht fuer deine eigenen Miniprojekte an denen du aleine schreibst und wo die sourcen noch bequem auf eine Diskette passen.

Und wenn du was schreibst wo es auf Effizienz ankommt, dann machst du das eh nicht in einer OO Umgebung.
Das machst du dann uU nicht mal mehr in plain C weils nicht effizient genug ist.

 

[Koestritzer]

die performanceeinbußen durch oop sind fast lächerlich, die liegen im bereich von 4-5%, also eigentlich uninteressant.
ich sag nich das du alles mit oop machen musst, aber es hat duchaus seinen sinn und gerade bei grösseren sachen hab ichs zu schätzen gelernt.

performance kriegste zum bleistift indem du die kritischen stellen per inlineassembler progst, viel schneller wirds dann auch nicht mehr.

 

[The_Company]

Original geschrieben von Morag
Und bei großen Projekten wirst du froh sein, wenns ne Doku gibt. Koestritzer hat recht, das gilt nicht fuer deine eigenen Miniprojekte an denen du aleine schreibst und wo die sourcen noch bequem auf eine Diskette passen.

Und wenn du was schreibst wo es auf Effizienz ankommt, dann machst du das eh nicht in einer OO Umgebung.
Das machst du dann uU nicht mal mehr in plain C weils nicht effizient genug ist.

Reicht das Multimediaframework für GNOME (aka "DirectShow in besser") als ausreichend grosses Projekt?

Falls ja: Keine Kapselung drin, Effizienz relevant, alles OOP, geschrieben in C und Du solltest Deine Argumente überdenken.

 

[Morag]

Original geschrieben von Koestritzer
die performanceeinbußen durch oop sind fast lächerlich, die liegen im bereich von 4-5%, also eigentlich uninteressant.
ich sag nich das du alles mit oop machen musst, aber es hat duchaus seinen sinn und gerade bei grösseren sachen hab ichs zu schätzen gelernt.

performance kriegste zum bleistift indem du die kritischen stellen per inlineassembler progst, viel schneller wirds dann auch nicht mehr.

4-5% können durchaus viel sein, z.b. wenn du Simulationen (Wetter, Strömungen) rechnen willst oder quantenmechanische Rechnungen.
Zum rest sag ich doch.

@company: keine Kapselung und komplett OOP ist ein Wiederspruch in sich.

 

[Koestritzer]

4-5% im extremfall, meistens wirste den unterschied kaum merken.

aber wenn man performance braucht optimiert man doch ganz gezielt an bestimmten stellen, die halt extrem viel verschlingen - und spart nicht an sowas wie oop wodurch man sich selbst das leben erleichtert.

oop sollte man imo nur dort einsetzen wo es wirklich sinnvoll ist, es gibt genug junkees die alles auf biegen und brechen oo proggen wollen.

 

[ViperDK]

oh gott, ein spaghetti-coder der die *komplete kontrolle* braucht und *weis was er tut*, prost - n/c!

 

[The_Company]

Meintest Du mich?

 

[Koestritzer]

wayne sonst