Warum programmiert ihr in C und was?

Hmm ok, dann sind hier wohl doch die meisten auf der C++Schiene, ist ja auch ein C++ Forum.

Ich nutze C derzeit zum Lernen der Sprache an sich und befasse mich mit Grafikprogrammierung, aber ohne GPUs, sondern rein CPU basiert. Später will ich auch unter Linux und für Mikrocontroller programmieren.

Java und Android mache ich auch noch. Ja, man kann Java und gleichzeitig C mögen :p

Falls es dennoch den ein oder anderen C-Fan gibt, wäre es schön wenn er hier noch was schreiben könnte.

Assembler steht als nächstes auf dem Plan, das interessiert mich auch.

EOP

Ich mag C weil es oldschool ist.
Assembler ist ne andere Baustelle. Mochte ich auch, hab es aber schon 25 Jahre nicht mehr praktiziert. Ich hab damals 12 und mehr Stunden ohne Essen, nur mit Kaffee vor dem TurboDebugger oder anderen Werkzeugen gesessen. Da bin ich wohl etwas eingerostet.

dachschaden

SeppJ schrieb:

Anscheinend verstecken sich die C-Programmierer, oder es gibt hier einfach keine.

*hust*hust*.

Aber ich habe eigentlich keine Lust, darüber zu schreiben, WAS ich mit C schreibe, weil in diesem doch eher C++-lastigem Forum viele Leute sagen werden: "Aber das kannst du auch mit C++ machen".

Ja, kann ich. Und wenn ich's mache, werde ich von allen schief angekuckt, weil man Sachen "so nicht in C++ macht". Die Debatte kennen wir alle schon.

Wer's wirklich wissen will, kann sich ja mal die Fragen anschauen, die ich in diesem Forum bereits gestellt habe, und sich einen Reim daraus machen.

CFrager schrieb:

Später will ich auch unter Linux und für Mikrocontroller programmieren.

Dafür ist C natürlich optimal.

CFrager schrieb:

Ja, man kann Java und gleichzeitig C mögen

Ich mag auch beides.

dachschaden schrieb:

Ja, kann ich. Und wenn ich's mache, werde ich von allen schief angekuckt, weil man Sachen "so nicht in C++ macht". Die Debatte kennen wir alle schon.

c++ -user haben eine klatsche.
lass sie einfach links liegen.

also um dir mal ne antwort zu geben:
ich programmiere momentan in c um an der fh laborübungen im fach microcomputertechnik zu erfüllen, um das dann später mal für irgendwelche erfindungen o.ä. anzuwenden.

wir haben da sone schicke kleine kiste mit nem 386ex "embedded", nem intel 8255 ppi, nem intel 8259A pic und nem intel 8254 pit und sollen damit dann so lustige sachen wie multiplexer, da-wandler, ad-wandler, leuchtdioden usw ansprechen, also zeitmessungen durchführen, sinussignale erzeugen, interrupts durch knopfdruck auslösen, frequenzen und spannungswerte von signalen messen, mehrfarbige led durch pwm ansteuern usw.

also so richtig schöne direkte programmierung der hardware.

rustyoldguy

Hallo!

Früher interessierte ich mich für HF-Technik. Um die Schaltungen besser berechnen zu können, wie Schwingkreise PI-Tiefpassfilter,
Antennenberechnungen, schrieb ich zuerst in QBasic, dann in C (Symantec 6.11 Shareware-Compiler), da QBasic zu viele Beschränkungen hatte. Später in QC25, Turbo-C von Borland, dann MSVC 1.52 später 2.0. Jetzt seit dem Umstieg auf Linux mit codeblocks 16.01.

Heute schreib ich eben Programme um den beruflichen Stess besser zu meistern, wie Berechnung von Passungen, von Gewindegrößen metrischer Gewinde und Berechnung von Grenzmaßen für die Abnutzung von Grenzlehrdornen oder
Berechnung von Rohren, wie als einseitig eingespannte Träger(Antennenstandrohre) verwendet werden, Biegewiderstandmoment, Sicherheitszahl Sigma_bzul und so weiter. Oder zur Berechnung der
Sehnenlänge, des Bohrungsabstandes bei Verwendung von unterschiedlichen Teilkreisen. Selten für das Qualitätsmanagement wie Binomialkoeffizient, Poissonverteilung, Normalverteilung, Mittelwerte, Berechnung des Annahme-
bzw. Rückweiserisikos von Lieferungen, Berechnung der
Eingriffs-und Warngrenzen von Shewartkarten mit Standardabweichung und arithmetischen Mittelwerten zur Erfassung von Messwerten von Stichproben
wie
Durchmesserwerten.
Das aber nun seltener, (seit September 15 entlassen (jetzt mit 51 Alteisen!),
nur zum fitbleiben des Oberstübchens.

Die einen machen eben Kreuzworträtzel, andere eben C.

Danke für die interessanten Beiträge. Da könnt ich gern mehr von lesen.

Mensch, endlich mal wieder ein Thread in dem Wutz glänzen könnte und plötzlich ist Stille. Was ist Wutz? Fehlt dir die Grundlage jemanden zu beleidigen? Dann hast du sie jetzt

tenim

ich programmiere auch gern in c. hauptsächlich aus 2 gründen:

* wenn es um maximale performance geht, die implementierung in assembler aber zu aufwändig ist.

* wenn es sehr hardwarenah wird / bitschubsen bis zum exzess angesagt ist

zu punkt 1: ich hab früher programme geschrieben, die bestimmte puzzles gelösst haben, die suchbäume extrem groß waren und wo es nur mit brute force ging da kein algo bekannt. bei einigen bin ich dann aber auf fortran ungestiegen, da das dann noch ein kleinwenig performanter als c war, da der fortran compiler durch die größeren restriktionen dieser sprache mehr optimieren kann.

zu punkt2: ich habe eine dll geschrieben, welche bilddateien (bmp) einliest, dann daraus bildsignaturen für eine ähnlichkeitssuche generiert und diese bitoptimiert in einer binärdatei ablegt. glaube, so eine signatur hatte nur knapp über 300 byte. das vergleichen der signaturdateien auf prozentuale übereinstimmung hat die dll auch gemacht. da ging es dann wieder um speed.

c ist halt toll, wenn du komplexe algorithmen möglichst performant implementieren willst. z.b. das x264 projekt (video encoding) ist auch in c+assembler geschieben, und das 2016! warum? weil c halt zeitlos und ungeschlagen ist wenn es um die genannten punkte geht.

c++ erzeugt halt durch die höhere abstraktion overhead der dich dann taktzyklen kostet. zwar nur wenige, aber wenn du z.b. milliarden operationen immer wieder machst (videobearbeitung) fällt das extrem ins gewicht.

tenim

dot

tenim schrieb:

ich programmiere auch gern in c. hauptsächlich aus 2 gründen:

* wenn es um maximale performance geht, die implementierung in assembler aber zu aufwändig ist.

* wenn es sehr hardwarenah wird / bitschubsen bis zum exzess angesagt ist

In beiden Fällen wärst du mit C++ besser beraten, weil sich damit effizienterer Code besser schreiben lässt...

tenim schrieb:

c++ erzeugt halt durch die höhere abstraktion overhead der dich dann taktzyklen kostet. zwar nur wenige, aber wenn du z.b. milliarden operationen immer wieder machst (videobearbeitung) fällt das extrem ins gewicht.

Nö. C++ gibt dem Compiler bei korrekter Anwendung durch seine gegenüber C um Lichtjahre fortgeschrittene Ausdrucksstärke mehr Information um optimaleren Maschinencode zu erzeugen. Performance ist so ziemlich das schlechteste Argument für C, das ich je gehört hab. Ich arbeite selbst im Bereich High-Performance Graphics und C kommt bei uns nicht in Frage (wobei es, z.B. wegen OpenCL, wiederholt zur Diskussion stand), weil der Sprache zu viele Werkzeuge fehlen (allem voran Templates), die sich in täglicher Praxis als für guten, performanten Code absolut kritisch erwiesen haben...

tenim

lichtjahr ist keine zeiteinheit. :p

wenn c++ soviel besser/schneller ist, warum arbeiten dann soviele aktuelle projekte wie z.b. diese leute des x264 video encoders mit c? sind das deiner meinung nach alles nur idioten?

p.s. wenn ich von performance spreche, meine ich maximale performance.

dot

tenim schrieb:

lichtjahr ist keine zeiteinheit. :p

"fortgeschritten" ist auch nicht unbedingt eine Dauer... :p

tenim schrieb:

wenn c++ soviel besser/scheller ist, warum arbeiten dann soviele aktuelle projekte wie z.b. diese leute des x264 video encoders mit c? sind das deiner meinung nach alles nur idioten?

Gibt effektiv drei Möglichkeiten

Das Ding muss auf Plattformen laufen, für die es keinen C++ Compiler gibt
Ignoranz (ein sehr prominenter Grund)
sie wissen es nicht besser

tenim schrieb:

p.s. wenn ich von performance spreche, meine ich maximale performance.

ich ebenso...

dachschaden

dot schrieb:

C++ gibt dem Compiler bei korrekter Anwendung durch seine gegenüber C um Lichtjahre fortgeschrittene Ausdrucksstärke mehr Information um optimaleren Maschinencode zu erzeugen. Performance ist so ziemlich das schlechteste Argument für C, das ich je gehört hab.

Harharhar.

Ich habe hier gerade ein C++-Binary rumfliegen, welches so an das halbe Mebibyte groß ist. Verwendet Boost. Da sind so vielleicht 2 Funktionen von 100, die tatsächlich vom Programmierer kommen, der Rest kommt von Boost oder iostream oder macht string-Konvertierungen oder weiß der Geier. Würde mal so schätzen, mindestens 80% sind nur ctor/dtor-Aufrufe und ein bisschen Stack Unwinding. Der eigentliche Code ist minimal, vielleicht 200 LOC. Und libstdc++ ist nicht statisch drinne.

Meine mutige Einschätzung: das hätte ich auch in einem 10-KiB-Binary unterbringen können.

Performance ist nicht das schlechteste Argument, dass ich für C++ gehört habe, aber das beste ist es ganz sicher nicht.

dot schrieb:

Ich arbeite selbst im Bereich High-Performance Graphics und C kommt bei uns nicht in Frage[ (wobei es, z.B. wegen OpenCL, wiederholt zur Diskussion stand), weil der Sprache zu viele Werkzeuge fehlen (allem voran Templates), die sich in täglicher Praxis als für guten, performanten Code absolut kritisch erwiesen haben...

High-Performance Graphics, aber C kommt nicht in Frage ... >> OK << .. -_-.

Ich verkneif's mir, versprochen.

dot

dachschaden schrieb:

dot schrieb:

C++ gibt dem Compiler bei korrekter Anwendung durch seine gegenüber C um Lichtjahre fortgeschrittene Ausdrucksstärke mehr Information um optimaleren Maschinencode zu erzeugen. Performance ist so ziemlich das schlechteste Argument für C, das ich je gehört hab.

Harharhar.

Ich habe hier gerade ein C++-Binary rumfliegen, welches so an das halbe Mebibyte groß ist. Verwendet Boost. Da sind so vielleicht 2 Funktionen von 100, die tatsächlich vom Programmierer kommen, der Rest kommt von Boost oder iostream oder macht string-Konvertierungen oder weiß der Geier. Würde mal so schätzen, mindestens 80% sind nur ctor/dtor-Aufrufe und ein bisschen Stack Unwinding. Der eigentliche Code ist minimal, vielleicht 200 LOC. Und libstdc++ ist nicht statisch drinne.

Meine mutige Einschätzung: das hätte ich auch in einem 10-KiB-Binary unterbringen können.

Während die Codesize durchaus ein potentieller Performancefaktor ist, so ist dies ohne Profiling für eine konkrete Anwendung nicht einfach so festzustellen...

Abgesehen davon, zitier ich mich einfach nochmal selbst

dot schrieb:

C++ gibt dem Compiler bei korrekter Anwendung durch seine gegenüber C um Lichtjahre fortgeschrittene Ausdrucksstärke mehr Information um optimaleren Maschinencode zu erzeugen. Performance ist so ziemlich das schlechteste Argument für C, das ich je gehört hab.

dachschaden schrieb:

High-Performance Graphics, aber C kommt nicht in Frage ... >> OK << .. -_-.

Jo, keine Chance, Templates allein sind dermaßen essentiell für GPU Programming. Würden wir C verwenden wollen, müssten wir entweder einen eigenen Präprozessor bauen, der uns sowas wie Templates gibt oder zweistellige Performance Hits in Kauf nehmen...

dachschaden

dot schrieb:

Während die Codesize durchaus ein potentieller Performancefaktor ist, so ist dies ohne Profiling für eine konkrete Anwendung nicht festzustellen...

Das mit den 80% ctor-/dtor-Aufrufen hast du aber schon gelesen, ja?

dot schrieb:

C++ gibt dem Compiler bei korrekter Anwendung durch seine gegenüber C um Lichtjahre fortgeschrittene Ausdrucksstärke mehr Information um optimaleren Maschinencode zu erzeugen.

OK.

dot schrieb:

templates allein sind dermaßen essentiell für GPU Programming...

OK.

dot

dachschaden schrieb:

dot schrieb:

Während die Codesize durchaus ein potentieller Performancefaktor ist, so ist dies ohne Profiling für eine konkrete Anwendung nicht festzustellen...

Das mit den 80% ctor-/dtor-Aufrufen hast du aber schon gelesen, ja?

Ja, hab's nur wegen seiner Irrelevanz gleich unterbewusst ignoriert. Aber von mir aus: Zuallererst sei betont, dass das ja – deinen eigenen Worten nach – nur deine persönliche Schätzung und kein durch Messungen erlangtes Ergebnis war und du hast ja, nach allem, was ich bisher hier so gesehen hab, selber offenbar nicht gerade so viel Ahnung von C++. Aber wenn das wirklich so ist, dann deutet das natürlich drauf hin, dass der C++ Code Bullshit ist. Dass die meisten Leute, die C++ verwenden, nicht richtig damit umgehen können, ist halt mal so. Wenn es um die mit einer Sprache erreichbare Performance geht, dann ist das Argument, dass man auch ineffizienten Code schreiben kann, aber kein brauchbares Argument. Das geht nämlich mit jeder Sprache...

dachschaden

dot schrieb:

Ja. Das deutet natürlich drauf hin dass der C++ Code Bullshit ist. Dass die meisten Leute, die C++ verwenden, nicht richtig damit umgehen können, ist nur halt mal kein Problem der Sprache an sich. Insbesondere ist das Argument, dass man auch ineffizienten Code schreiben kann, kein brauchbares Argument, wenn es um die mit einer Sprache erreichbare Performance geht. Das geht nämlich mit jeder Sprache...

Nein, du hast meine Kritik nicht verstanden.

Es geht nicht darum, dass C++ per se schlechteren Code generiert. Es geht darum, dass Leute durch kaputte Interfaces dazu angestachelt werden, schlechten Code zu schreiben.

Das gleiche Problem haben wir bei C auch. Dieses ganze Konstrukt um malloc mag für Embedded-Systeme (wo z.B. alle Programme in Ring 0 laufen und überall lesen und schreiben können und sich alle Programme einen zentralen Heap teilen) vielleicht noch Sinn ergeben. Aber für einen großen Teil der Programme gilt das nicht.

Und C++ abstrahiert da noch mehr von. Ich kenne Leute, die lieber hexadezimale Zahlen in ihren Quellcode schreiben, anstatt einfach nur die Buchstaben, die sie meinen, weil sie meinen, das Programm liefe dann schneller, aber dann ohne Schamesröte malloc und new verwenden (ja, manchmal sogar im gleichen Programm - ich meine mich erinnern zu können, dass PCSX2 da ein böses Beispiel ist, aber deren Code stinkt eh zum Himmel ...).

Und da war ich zu Anfang meiner C-Laufbahn ja auch dabei. Machen wir alles komplett dynamisch, mit malloc und free ... bis man dann irgendwann lernt, wie so ein Allokator funktioniert, und man sich dumm vorkommt, weil man die ganze Zeit nur Schund programmiert hat.

Das Problem sind selten die Sprachen (bis auf Java, glaube ich, aber auch deswegen, weil hier Framework und Sprache verdammt eng verzahnt sind). Das Problem sind die Frameworks, die die Arbeit wegabstrahieren. Ja, können sie machen, aber bitte nicht so, dass wir uns am Ende nicht mal mehr bewusst darüber sind, was so ein einfaches new bedeutet.

Und wenn ich all diesen Scheiß wegnehme und mir mein eigenes Interface zusammenbastel, in dem ich auf Feature-Creep-Scheiß verzichte und mir lieber die Möglichkeit gebe, Page-Walks zu vermeiden, und dabei noch auf 32 KiB-Binaries komme, mit einem Verhältnis von 35/1 LOC (eine LOC in der Anwendung kommt auf 35 LOC in der Bibliothek), dann weiß ich, dass ich was richtig gemacht habe. Du kannst abstrahieren und dennoch gute Performance erreichen, aber dazu braucht es Zeit und Erfahrung. Dann hast du aber auch was, das gut funktioniert.

Von Templates habe ich da noch nicht mal angefangen.

EDIT: Ach, hast den Post geändert. Na dann ...

dot schrieb:

Ja, hab's nur wegen seiner Irrelevanz gleich unterbewusst ignoriert. Aber von mir aus: Zuallererst sei betont, dass das ja – deinen eigenen Worten nach – nur deine persönliche Schätzung und kein durch Messungen erlangtes Ergebnis war

Der Profiler zeigt die halt zualleroberst an, deutlich vor allen anderen. So im Zehntausenderbereich an Aufrufen, und alle so 3%- bis 5%.

Wenn ich die alle zusammennehme, komme ich auf 87%. Da war ich mit meiner Schätzung gar nicht so daneben.

dot schrieb:

und du hast ja, nach allem, was ich bisher hier so gesehen hab, selber offenbar nicht gerade so viel Ahnung von C++.

Einen Profiler bedienen kann ich noch gerade so.

Andromeda

dachschaden schrieb:

Das gleiche Problem haben wir bei C auch. Dieses ganze Konstrukt um malloc mag für Embedded-Systeme (wo z.B. alle Programme in Ring 0 laufen und überall lesen und schreiben können und sich alle Programme einen zentralen Heap teilen) vielleicht noch Sinn ergeben. Aber für einen großen Teil der Programme gilt das nicht.

Eine C-konformer Heap ist prinzipiell nix anderes als eine Zwischenschicht, die unten über einen großen Speicherblock verfügt, aber die nach oben hin diesen nur portionsweise zur Verfügung stellt. Das ist für einige Anwendungen nahezu ideal, birgt aber ein paar Problemchen:

1. Fragmentierung. Kann aber durch intelligente Algorithmen minimiert werden.

2. malloc kann fehlschlagen. Das ist oft ein KO-Kriterium in embedded Systemen, wenn eine Speicherallokation IMMER klappen muss.

dachschaden

Andromeda schrieb:

Eine C-konformer Heap

Nee, schlussaus, pfui. Nix C-konform.

Ich will ein Objekt haben, dem ich angeben kann:

- ob das jetzt eine Stack- oder eine Mapping-Allokation ist - und ich will die Möglichkeit haben, dass ab einer bestimmten Größe (z.B. eine Stanardpage) automatisch nur noch Mappings erlaubt sind.
- wie groß die Pages sein sollen, um weniger Einträge im TLB zu haben.
- dass ich jetzt neuen Speicher brauche und dass es mir komplett egal ist dabei, wo der neue Speicherbereich liegt, weil ich mit relativen Indizes arbeite.

Was ich NICHT will, ist mit Zeigern rumhantieren, wofür jedes Mal erst mal eine Liste gelockt werden muss, um dann nach dem Eintrag für den Zeiger zu suchen. Ich habe hier mein Mapping-Objekt auf dem Stack, das Mapping selbst gibt mir der Kernel, und große, zusammenhängende Daten kann ich einfach direkt reinpacken.

Dieser ganze C-konforme Anspruch mag für ein paar Systeme Sinn ergeben, aber lange nicht für alle. Selbst wenn alles gut läuft bei einem malloc - sprich, Daten müssen nicht kopiert werden, neuer Speicher muss nicht angefordert werden, also Zero-Copy und ohne Kontextwechsel - so muss doch noch immer in der globalen Liste eingetragen werden, dass Adresse X bis Y jetzt belegt sind.

Für kleine Allokationen kann man direkt den Stack benutzen, und derzeit teste ich Code, mit dem man den auch wieder zurücksetzen kann. Für größere Allokationen ruft man das Betriebssystem an oder verwendet optionale Mapping-Objekte bei Funktionsaufrufen. Wenn man keine hat, kümmert sich die Funktion selbst um ihren Speicher. Alles eine Frage des Frameworks, nicht der Sprache. Der zusätzliche Code, damit eine Funktion so ein Objekt nutzen kann, ist ein zusätzlicher Parameter, ein Variablenblockmakro, ein Funktionsaufruf, dem die Standardargumente über ein Makro mitgegeben werden (sprich, im normalen Code werden dann keine Argumente übergeben), und entweder das Zurücksetzen oder das Freigeben des Mapping-Objekts. Insgesamt vielleicht 5 Zeilen mehr Code pro Funktion, im Gegenzug kann dann reservierter Speicher mehrmals verwendet und auch erweitert werden.

Und interessant wird es, wenn man in dem gleichen Mapping, in dem man seine Input-Daten hat, auch seine Output-Daten speichern will, nur halt am Ende. Bonuspunkte, wenn man 64-Bit-Längen verarbeitet haben will, die ranzige Bibliothek aber nur direkt mit 32 Bit arbeiten kann (du brauchst gar nicht so unschuldig zu gucken, zlib). Dann muss man konsequent relative Indizes verwenden. Die Belohnung? Man hat nicht mehr diesen Verwaltungskram im Hintergrund, alles läuft direkt für deinen Thread und muss nicht gelockt werden, für kleinere Allokationen wird erst Speicher auf dem Stack verwendet, bevor das Betriebssystem angefragt wird, und man kann direkt bestimmen, wie der Speicher reserviert werden soll.

(EDIT): Und ich will dabei noch den Code, den ich dann hinterher schreiben muss, reduziert haben. Wenn ich am Ende mehr Code schreiben muss, um Kinkerlitzchen zu verwalten, dann habe ich das Ziel verfehlt. Das soll gleichzeitig intelligent UND einfach UND zentral sein, damit man es im Zweifelsfall auch an seine Situation anpassen kann. Ich gebe einen Pagesize von 1 GiB an, das kann der Prozessor aber nicht, dann soll das Ding automatisch runtergehen. bis es klappt.

SOWAS will ich. Gab es nicht. Also musste ich es selbst machen. Und plötzlich dauert ein Funktionsaufruf nur noch 500 Cycles statt 200.000, sowohl in C als auch in C++.

Es wird nicht besser, indem man versucht, "C-konform" Algorithmen zu tweaken. Aber schlecht programmieren kann man in jeder Programmiersprache, wa?