Warum programmiert ihr in C und was?
-
SeppJ schrieb:
Ich halte es jedenfalls so, dass ich keinen Grund für C sehe, wenn ich doch C++ kann, außer äußere Umstände (a.k.a. bestehendes Projekt in C) zwingen mich zu C. Da dies primär ein C++-Forum ist, wird es wohl vielen ähnlich gehen.
Der einzige rationale Grund, C zu verwenden, ist ja auch, dass es für eine Zielplatform keinen brauchbaren C++ Compiler gibt. Und das ist halt im 21. Jhd. relativ selten der Fall...
-
dot schrieb:
....
Der einzige rationale Grund, C zu verwenden, ist ja auch, dass es für eine Zielplatform keinen brauchbaren C++ Compiler gibt....Oder weil es für eine (alte) Zielplattform keinen zugelassen C++ Compiler gibt, da es sich um sicherheitsrelevante Software handelt, die darauf laufen muss. Hatten wir in meiner ehemaligen Firma auch schon, da musste tatsächlich die objektorientierte C++ Software nach C portiert werden.
-
dot schrieb:
Belli schrieb:
dot schrieb:
CFrager schrieb:
Aber das Java auch sehr ressourcensparend sein kann, hat Android gezeigt.
Das Android und ressourcensparend war jetzt als Witz gemeint, oder?
Bei Android kann man sich meiner Erfahrung nach alle zwei Jahre ein neues Gerät holen, weil sich auf dem Alten nichtmal mehr in endlicher Zeit der Browser öffnen lässt.
Du meinst also, Android ist dynamisch? So, dass es im Lauf der Zeit langsamer wird?
Interessant ...Systemupdate und so...
Okay ... mach ich nicht. Zumindest auf Win Desktops war es bisher aber auch immer so, dass eine neue OS-Version hardwarehungriger als der Vorgänger war.
Wenn man jedes Mal das neueste OS iVm sonstiger neuer SW haben will, ist jede Hardware nach 2 bis 3 Jahren ausgereizt, schätze ich.
-
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.
-
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.
-
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.
-
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
-
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
-
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...
-
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.
-
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...
-
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.
-
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...
-
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.
-
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...
