Diskussion:C (Programmiersprache)/Archiv/2006

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:C (Programmiersprache)/Archiv/2006#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:C_(Programmiersprache)/Archiv/2006#Thema_1

C++ in der Einleitung

Was hat denn C++ in der Einleitung eines Artikels über C zu suchen? Wenn überhaupt, gehört sowas ans Ende in ein »siehe auch ...«. -- Pingi 21:34, 28. Feb 2006 (CET)

Naja - anscheinend macht hier jemand werbung für C++ - sonst müsste ja auch Objective-C erwähnt werden. Hab den absatz sogar schon mal rausgelöscht, aber ein paar tage später war er wieder da. --Liebeskind 20:35, 25. Sep 2006 (CEST)

Sehe auch keinen Grund dies so explizit bereits in der Einleitung hervorzuheben. Der Satz "Zahlreiche weitere Sprachen, wie..." bringt den notwendigen Querverweis zu den anderen Sprachen und dort werden dann auch die Details besprochen. Wenn es keine begründeten Einwände gibt, werfe ich den Abschnitt wieder raus. --Revvar (D RT) 08:35, 26. Sep 2006 (CEST)

Man könnte ja stattdessen weiter unten einen absatz machen, in dem eben solche versuche C um objektorientiertheit zu erweitern (wie etwa C++ und Objective-C und gegebenenfalls andre die ich noch nicht kenne) aufgelistet werden. --Liebeskind 16:17, 26. Sep 2006 (CEST)

Impliziter Kode

Danke fuer die Eroeffnung des Edit-Wars... Kannst Du mir mal erklaeren, wie Du Dir das vorstellst? Soll ich jedesmal, bevor ich mein Wissen beitrage, es erst ausdiskutieren? Soll ich Dir jetzt eine Abhandlung ueber Kompilerbau geben? Oder besser dem Anonymous? --Montauk 23:03, 19. Jun 2006 (CEST)

Du gehoerst zu den Leuten, die mir die Wikipedia verleiden. Meine Zeit ist mir zu schade, um mein Fachwissen, das ich tagtaeglich an einer Hochschule vermittle, in dieser Weise in Frage stellen zu lassen. Ich habe nichts gegen unmittelbare Sachdiskussion einzuwenden (die der Anonymous haette eroeffnen muessen), aber ich werde mich nicht gegenueber dem selbsternannten Wikipolizisten Kadeck rechtfertigen. Basta. --Montauk 17:21, 25. Jun 2006 (CEST)

Was ist denn kurz gesagt ein „impliziter Programmcode“? Mir fällt da ad hoc so was wie „isxxx“ ein. Den Begriff habe ich aber als jahrelanger Praktiker bislang noch nirgends gelesen. Ich bin weit weg von der Uni... --Harald Wehner 22:51, 26. Jun 2006 (CEST)

Harald, gerne waere ich auf einen Diskussionsbeitrag wie den Deinigen eingegangen. Aber meine Zeit mit Wikipedia ist vorbei. Sie ist zu kostbar, um Leuten wie Kadeck Einhalt zu gebieten. --Montauk 14:39, 8. Jul 2006 (CEST)

@Montauk, du kannst diese Art der Diskussionen umgehen, indem du in der Zusammenfassung gleich eine Quelle angibst (wissenschaftliches Arbeiten geht dir ja sicher leicht von der Hand, bei deinem Hintergrund). Das du es selbst hier weniger bei Anderern sehen wirst, das gute Quellenangaben auch ohne Aufforderung dazugepackt werden, ist imho ein großes Problem der WP. Also schlaf bitte einfach noch ein paar Nächter über deinen Ausstieg hier - bei zukünftigen Problemen helfe/vermittle ich gerne. Schönen Gruß --Revvar (D RT) 15:13, 8. Jul 2006 (CEST)

Einfügen von & nbsp

Einfügen von & nbsp ist wie von Lehmzwerg gemacht typografisch nicht üblich. --Eozae 23:12, 18. Jul 2006 (CEST)

Wie bitte? Wie kommst Du darauf? Natürlich ist das sinnvoll! Als alter TeX-Benutzer bin ich jetzt auf Deine Gegenbeispiele und Referenzen gespannt. Lemzwerg 23:24, 22. Jul 2006 (CEST)

Schwächen - Überarbeiten

Der Abschnitt ist viel zu aufgeblasen. Viele Details beruhen auf ein und der selben Ursache (zum Beispiel der hardwareabhängigen Darstellung und Ausrichtung von Variablen und Strukturen). Die Schlussfolgerungen - fehlende Portabilität sind "so absolut" - falsch. Wenn sich nichts ändert werde ich mich nach Weihnachten mal ransetzen, hoffe aber ein Nutzer vom Fach finde dazu eher Zeit und Lust. --Revvar (D RT) 19:52, 29. Nov. 2006 (CET)

Dann aber bitte auch die Stärken kräftig entschlacken; die meisten Punkte sind Feststellungen und haben nichts mit Stärken zu tun ! Ich möchte ausdrücklich betonen, dass meine Ausführungen nicht polemisch gemeint sind. Ich habe immer wieder den Eindruck, dass sich viele Programmierer einfach nicht von ihren alten Zöpfen trennen können und krampfhaft an technisch völlig überholten Werkzeugen festhalten.

• Zeigerarithmetik ermöglicht die effiziente Behandlung von Feldzugriffen, Parametern usw.

Das war wichtig, als es 8 MHz-CPUs gab und ist heute wegen der möglichen Buffer-Overflows eher eine Schwäche.

-> In der Embedded Welt hat man nur zu Hauf Prozessoren in der einstelligen Mhz-Liga

Jede Digitalkamera hat heute einen Prozessor mit dreistelligen Megahertz-Taktfrequenzen. Bei langsamerer Hardware kommt es also heute gewiss nicht mehr auf Performanz an.Membeth 22:44, 5. Okt. 2008 (CEST)

• Präprozessor zur Spracherweiterung und bedingten Übersetzung

Rhetorische Frage: Ist das ein Bug oder ein Feature ?

• Linker (Binder) (C war eine der ersten Sprachen, die das Einbinden von externen vorübersetzten Routinen in der Sprachdefinition berücksichtigt)

Heute brauchen wir Loader, die zur Laufzeit linken, damit die Programme effizient und sicher arbeiten. Wie lange braucht denn zum Beispiel Windows XP zum Booten ?

• Viele Optimierungen sind bei der Übersetzung möglich.

Ist es wirklich entscheidend und wünschenswert, wenn ein Programm ein Promille schneller läuft, weil keine Index-Checks gemacht werden ? Das ist doch Schnee von gestern.

-> Oha, also wenn man hier Zeitmessungen ansetzt dann sind das Welten, die zwischen Size- und Speed-Optimierung liegen. Alleine eine Software ohne Optimierungen hat nach eigener Erfahrung oft einen Laufzeitoverhead im zweistelligen Prozentbereich!

Laufzeitvorteil im Vergleich wozu ? Jedenfalls nicht zu Pascal oder Modula-2 mit Index-Check (nach eigener Erfahrung aus den 80er Jahren). 10 oder 20% sind auch keine Welten. Membeth 22:44, 5. Okt. 2008 (CEST)

• Fast alle Kernel der bekannten Betriebssysteme sind in C implementiert.

Ist das eine Stärke oder ein Hinweis auf die Innovationsscheu der Entwickler ?

-> Das liegt an der einfachen Tatsache, dass hardwarenahe C-Compiler einfach weniger Fehler und Overhead generieren als C++ Compiler. Unterschiedliche C++ Compiler erzeugen funktional unterschiedlichen Code! Das ist für so etwas wichtiges wie einen Kernel nicht verantwortbar.

Wer redet denn von C++ ? Das ist C mit Präprozessor. Da ist C# schon eher auf dem Stand der Technik. Membeth 22:44, 5. Okt. 2008 (CEST)

• Sehr portabel und sowohl assemblernahe als auch abstrakte Programmierung möglich.

Wie ist denn portable, assemblernahe Programmierung möglich ? Unter abstrakt verstehe ich echte objektorientierte Programmierung (Module, Typensicherheit, Garbage Collection) und nicht das, was uns C++ oder gar C bietet.

• Nach wie vor ist C eine häufig benutzte Programmiersprache, nicht nur für Referenzimplementierungen.

Das ist bestenfalls eine Feststellung und im übrigen gereicht es sicherlich nicht zur Ehre einer innovativen Industrie. Was sind denn bitteschön Referenzimplementierungen ? Heute sollten wie andere Maßstäbe für Referenzen anlegen.

Bautsch 16:52, 6. Dez. 2006 (CET)

die Begriffe Stärken und Schwächen sind in diesem Artikel völlig unangebracht. Wie wärs mit Spracheigenschaften? Das ist neutral. Dass C nicht heute entworfen wurde, steht ja hoffentlich irgendwo. Die Sprache hatte und hat seinen festen Platz, wo der Einsatz Sinn macht. --Kurt Seebauer 21:25, 6. Dez. 2006 (CET)

Der Meinung binich auch. Ich habe mal exemplarisch einen Punkt nach oben gezogen (ich denke, man kann das Schritt für Schritt machen), was denkt Ihr? --62.225.37.69

einige Punkte sind schon Schwächen (z.B. das ein Int nicht zwangsläufig 32 bit hat, ist nicht gerade praktisch), ein Großteil sollte aber wirklich zu Merkmalen gehören, anstatt zu Stärken/ Schwächen. Vieleicht eine Tabelle: Merkmal | Vorteil | Nachteil, lässt sich wohl zu fast allem was finden. Ist eben Segen und Fluch zugleich^^ MfG --Zemy 23:11, 15. Jan. 2007 (CET)

Da sind zwei Punkte die ich nicht ganz nachvollziehen kann; „Mehrdimensionale Felder werden in der numerischen Mathematik für Matrizen benötigt. Dafür ist die Struktur der C-Felder jedoch ungeeignet.“

Jede andere (gebräuchliche) Programmiersprache arbeitet auch auf einen eindimensionalen Speichern und linearisiert mehrdimensionale Felder demnach. Warum sollte das eine Schwäche von C sein?

Ganz einfach: Schreibe mal in C mit zweidimensionalen Feldern (double m [][]) eine Funktion die Eigenwerte eine nxn-Matrix berechnet. n soll nicht a priori festgelegt sein. Es geht sinnvoll nur mit der Konstruktion double * []. Und es ist in der angegebenen Quelle zur numerischen Mathematik ausführlich beschrieben. Wie wärs mal mit einem Klick und Lesen??? --Brf 16:54, 18. Jan. 2007 (CET)

Natürlich hat irgendwer den wichtigen Link gelöscht. Ich tu ihn wieder rein. --Brf 16:57, 18. Jan. 2007 (CET)

Ah, aus dem Satz ging nicht eindeutig hervor das hier von Feldern mit zur Laufzeit veränderlicher Größe die rede ist. Das es unter C mehr Programmierarbeit erfordert so etwas zu Programmieren, als in Sprachen die über einen vollwertigen Feldtyp verfügen ist klar. Aber vielleicht sollte man diesen Kritikpunkt allgemeiner und klarer formulieren, diese Probleme sind ja beweiten nicht nur auf die numerische Mathematik beschränkt. Mein Vorschlag dafür; C unterstütz Felder nur in der Form von Zeigern, was zu einen höheren Aufwand bei der Programmierung mit mehrdimensionalen und laufzeitveränderlichen Feldern führt.

Oder so ähnlich ... --Vren 22:39, 18. Jan. 2007 (CET)

Außerdem; „In der Sprachversion C99 sind Datentypen mit expliziten Bit-Längen definiert (int8_t, int16_t etc.).“

Ja, das ist eine Voraussetzung um z.B. über ein Netzwerk kommunizieren zu können. Warum taucht das unter Nachteile auf?

---

• Ich habe den Abschnitt nun komplett gelöscht. Der Überblicks-Abschnitt enthält bereits eine gute, und im Gegensatz zu diesem, objektivere Beschreibung der Sprachmerkmale. Ggf. kann man noch Einzelheiten dort ergänzen, dann aber bitte in zusammenhängenden Sätzen und bei Wertung nur mit seriösen Quellen. Details zu den Einzelheiten gehören wenn überhaupt in ein Wikibook. Kritikpunkte, zum Beispiel die plattforspezifische Bit-Größe der Ganzzahhlendatentypen betreffend, zeugen eher vom Unverständnis von den Designzielen und Einsatzgebieten dieser Sprache. Dieser Artikel soll kein C-Kurs werden, sondern ein Enzyklopädieartikel sein. --Revvar (D RT) 17:48, 19. Jan. 2007 (CET)

"Gleiches Verhalten"

Folgenden Abschnitt berichtigt: "Verwendet ein Programm lediglich den Sprachkern gemäß der Sprachdefinition und die Standardbibliothek, so ist es auf jedem System, das einen ANSI-kompatiblen Compiler zur Verfügung stellt, übersetzbar und zeigt auch auf allen Systemen das gleiche Verhalten."

Beispiel für einen Progammausschnitt, der die Aussage widerlegt:

 long l;
 char* str = "----++++" ;
 strncpy(str, &l, 4);

--84.163.185.101

Das ist zwar syntaktisch in Ordnung, aber semantisch gesehen, ist das Verhalten ab der 3. Zeile undefiniert. "Gleich" ist natuerlich wie bei jeder Sprache etwas relativ zu sehen, z.B. kann die Ausgabe auf einem Farbbildschirm, einem Drucker, einem Dummy-Terminal oder was auch immer geschehen. --82.141.61.74 15:36, 20. Jan 2006 (CET)

"aufwärtskompatibel" - schreibfehler?

Im ersten Absatz heißt es Die wesentlich neuere Sprache C++ stellt eine annähernd aufwärtskompatibele Weiterentwicklung von C dar und wurde gegenüber C unter anderem um Möglichkeiten zur objektorientierten und generischen Programmierung erweitert.. Müßte es nicht (abgesehen davon dass es falsch geschrieben ist) abwärtskompatibel heißen? Oder will der Autor spitzfindig ausdrücken, dass c++ aufwärtskompatibel sein wird? Grüße Hoderlump 13:41, 24. Apr 2006 (CEST)

IRC

Hab den Dummfug gelöscht der seit ein paar Tagen unter dem Titel "IRC" zu finden war, hoffe das geht in Ordnung. -- 138.190.15.46 10:50, 24. Mai 2006 (CEST)

Bewertung von Sprachmerkmalen

Ich hätte einen Vorschlag zur Neugliederung des Abschnitts Bewertung von Sprachmerkmalen: Statt Sprachmerkmale als Stärken und Schwächen zu klassifizieren sollte nach Sprachmerkmalen gegliedert werden. Bei jedem Merkmal könnten dann direkt die individuellen Stärken und Schwächen angegeben werden. In der bisherigen Version tauchen manche Merkmale sowohl bei den Stärken als auch bei den Schwächen auf. Das finde ich eher ungünstig. Was meint ihr? --Joblech 09:13, 4. Okt 2006 (CEST)

Ich stimme dir zu, du hast vollkommen Recht. Nach Sprachmerkmalen zu gliedern halte ich für eine gute Idee. ~~Digedag1234

C-Hasser in 10 Tagen - den Link stelle ich jetzt mal in Frage.

Seid ihr wirklich der Meinung, dass dieser Link in den Artikel gehört? Um nur mal grob zu beschreiben was mir an dem Text nicht gefällt: Er ist alles andere als sachlich, die Begründungen sind absolut schwach. Vor allem die Tabelle ist schwach. Ich bin Programmieranfänger und komme mit der C - Syntax sehr gut zurecht.

Bsp.: while(i<10) i--; - so eine Zeile kann man nur programmieren wenn man während des Tippens sein Gehirn abgestellt hat. Das ist für mich kein Argument. Außerdem gibt es für derartige Fehler IDEs. Also: Habe ich irgendetwas nicht mitbekommen und ihr seid wirklich der Meinung, dass dieser Link in den Artikel gehört? ~~Digedag1234 (nicht mit einer Zeitangabe versehener Beitrag von Digedag1234 (Diskussion | Beiträge) 19:08, 10. Nov. 2006 (CET))