Diskussion:C (Programmiersprache)/Archiv/2008

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/2008#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

return 0; beim Hallo-Welt-Programm

Hallo, hab mal das return 0; beim Hallo-Welt-Programm zu return EXIT_SUCCESS; geändert. Ist laut Ansi-C-Standart besser, da nicht jedes Ausführungssystem 0 als Rückgabewert für Erfolgreiche Ausführung ansehen müssen.Daher ist RETURN_SUCCESS; hier eine bessere Alternative.

1. es heißt Standard. 2. EXIT_SUCCESS wird in <stdlib.h> definiert, daher müsste dieser Header dann in das - nun nicht mehr wirklich minimalistische - Hello-World-Programm ebenfalls inkludiert werden. --RokerHRO 11:22, 23. Mär. 2008 (CET)

3 jo ok, alter Schreibfehler von mir :D aber ohne EXIT_SUCCESS könnte das Programm auf manchen Compilern / OS nicht laufen, die eben als Rückgabewert für korrekte Ausführung nicht 0 bieten.

Welcher Compiler verhält sich so? Der Compiler sollte damit keine Schwierigkeiten haben, höchsten dass er eine Warning rausmeckert. Das manche OS für EXIT_SUCCESS nicht 0 verwenden, verhindert nicht die Ausführung des Programms, es führt höchsten dazu, dass eine fehlerfreie Ausführung nicht als solche interpretiert wird. --Burkhard 20:59, 13. Apr. 2008 (CEST)

Erstens EXI_SUCCESS ist gut aber nicht zwingend notwendig, das Programm endet und fertig... Dazu bleibt bei Verwendung dieser Definition nichts anderes uebrig als die entsprechende Headerdatei zu includieren, ausser man definiert sie sich selbst! Zweitens werden im Artikel Funktionen manchmal mit und ohne dem Parametereraum () dargestellt, was nun? Dies traegt nicht zur einheitlichen Schreibweise bei. Gentfloo (--88.70.5.112 20:12, 13. Apr. 2008 (CEST))

Dann sollte in den Erläuterungen zumindest stehen, dass es sich bei EXIT_SUCCESS um ein Makro handelt, dass den Wert OS spezifisch definiert. BTW: Bei der Gelegenheit sollte auch noch in === Die Standardbibliothek === erwähnt werden, dass die IF-Definition per <stdlib.h> eingebunden werden. --Burkhard 20:59, 13. Apr. 2008 (CEST)

Mhh Makro muss man nicht erwaehnen, das geht dann schon in die Richtung Praeprozessor, auf dem man im Artikel ja stoeßt. Ist die Anwendung denn jetzt so richtig erlaeutert und formuliert? EXIT_SUCCESS als einzigstes Makro zu verwenden das includiert werden muss / sollte ist nicht verkehrt, denn schliesslich soll Wikipedia soweit systemunabhaengig sein... und mehr bruach man nun wirklich nicht. Gentfloo

Wenn man schon meint, solche Verrenkungen (EXIT_SUCCESS) machen zu müssen, sollte dem Leser auch erklärt werden, was da passiert. dies ist ein von der Headerdatei an das System angepasster Rückgabewert. ist für den Leser nicht nachvollziehbar. Eine klare Formulierung wäre z.B. „Das Symbol EXIT_SUCCESS ist in der Headerdatei stdlib.h definiert und wird statt eines festen numerischen Rückgabewerts verwendet, um die erfolgreiche Programmausführung dem Aufrufer plattformunabhängig zu signalisieren.“ Ob man das Wort Makro verwendet oder nicht, ist da nur eine Feinheit, im Zusammenhang mit dem Hallo-Welt Programm hätte es immerhin einen didaktischen Mehrwert.--Burkhard 20:47, 26. Apr. 2008 (CEST)

Großartig. Sei mutig und schreib deine Verbesserung doch gleich rein in den Artikel. :-) --RokerHRO 20:54, 26. Apr. 2008 (CEST)

Mach's wie Du willst, hauptsach' die Sache stimmt ;). Aber wenn, solltest Du's auch hineineditieren, sonst hilft's niemandem und jeder muss fuer seinen eigenen Kram schliesslich verantwortung uebernehmen, ich editiers nicht hinein ;) Gentfloo --88.70.17.225 14:01, 2. Mai 2008 (CEST)

Man koennte laut C99 auch gleich int main(void){ /*Code*/ } schreiben etc. belassen wir's leiber dabei wie's ist x). Gentfloo --88.70.17.225 14:01, 2. Mai 2008 (CEST)

Also ich lese im ISO-Standard: "[...] reaching the } that terminates the main function returns a value of 0. [...]" Und 0 muss nicht EXIT_SUCCESS bedeuten. --RokerHRO 15:22, 2. Mai 2008 (CEST)

Ja und? 'Wollte nur mal anderes Licht in's Dunkle werfen, bezueglich dass eigentlich gar kein return noetig waere. ;). Gentfloo --88.70.112.169 20:12, 2. Mai 2008 (CEST)

O.K. - ihr habt es so gewollt. Nach einiger Überlegung habe ich auf die Erwähnung des Begriffs Makro verzichtet, da auch eine Definition als Konstante möglich ist.

Vielleicht an dieser Stelle noch ein Wort zur Funktion des Hallo-Welt Beispiels im Artikel: Da es einen eigenen Artikel Hallo-Welt-Programm gibt und dort auch Hinweise auf die ursprüngliche Version in K&R zu finden sind, kann die Aufgabe des Beispielprogramm hier im Artikel nur die sein, eine komprimierte Übersicht über die grundlegen Spracheigenschaften zu geben. Ich habe daher die Gelegenheit ergriffen und gleich noch einen abschliessenden Kommentar eingefügt und kurz erläutert. --Burkhard 10:21, 4. Mai 2008 (CEST)

Meinung

in dem Artikel lauert ja die eine oder andere Meinung, beispielsweise:

• 'Für die Anwendungsentwicklung ist C nur eingeschränkt geeignet, weshalb [andere Sprachen dort verwendet werden].'

Keine Quelle, keine Begründung. Wenn ich mich beispielsweise auf einer Linux-Distribution umschaue, sehe ich die Aussage nicht bestätigt.

• 'C wird auch oft dazu benutzt Endbenutzer-Programme zu erstellen, obwohl man bei größeren Programmen eher auf höhere Programmiersprachen (z. B. C++) zurückgreift. '

Was man so alles eher macht ... Was sind größere Programme? Ist beispielsweise gcc, Xorg oder xine jeweils noch nicht groß genug?

• [C Programme sind im allgemeinen schlechter wartbar, als Programme in anderen Programmiersprachen]

Unwartbaren Code kann man ja wohl in jeder Programmiersprache schreiben.

Ich werde mal versuchen solche Meinungen aus dem Artikel rauszunehmen. --Gms 20:54, 3. Mai 2008 (CEST)

Gut so. Auch wenn ich C nicht sonderlich mag, und jene Meinungen durchaus teile, so sind es doch stark wertende und nur schwer zu belegende Aussagen. Wir sollten uns hier auf relativ leicht nachprüfbare Fakten beschränken. Wer sich eine Meinung über C bilden will, sollte sie nicht durch das Lesen dieses Artikels vorgefertigt bekommen, er sollte C einfach mal in größeren Projekten ernsthaft einsetzen, das langt... ;-) --RokerHRO 22:47, 3. Mai 2008 (CEST)

Wirklich starker POV ist auch die Behauptung, C kennte kein Modulkonzept. Selbstverständlich ist die Modularisierung nur schwach, aber es gibt Information hiding und eine Bekanntgabe der Schnittstellen durch Headerdateien. Ich werden diesen Unfug auch gleich rausschmeissen (mit Verweis auf Quellen). --Burkhard 10:26, 4. Mai 2008 (CEST)

Nunja, ist halt Definitionssache, was man als "Modulkonzept" gelten lässt. Für Datentypen gibt es z.B. überhaupt keine sinnvolle Kapselungsmöglichkeit, außer man gibt nur void* heraus. --RokerHRO 21:52, 4. Mai 2008 (CEST)

Das "Modulkonzept" wird ausser in der klassischen Literatur (siehe Artikel) online z.B. hier definiert: Ein Modul ist eine abgeschlossene Komponente einer Software, bestehend aus einer Folge von Verarbeitungsschritten und Datenstrukturen. Inhalt eines Moduls ist häufig eine wiederkehrende Berechnung oder Bearbeitung von Daten, die mehrfach durchgeführt werden muss. Module bieten eine Kapselung (encapsulation) durch die Trennung von Schnittstelle und Implementierung. Das alles ist in C vorhanden und umsetzbar. Wie man mit C sogar objektorientiert programmieren kann, zeigt Bertrand Meyer in Objektorientierte Softwareentwicklung, Hanser 1990, ISBN 3-446-15773-5.

BTW: Würde die Modem-Software für Mobiltelefon-Systeme mit - je nach Protokollumfang ca. 3000 bis 4000 C-Quelldateien - als Beispiel für ein umfangreiches Projekt durchgehen können? Und solche Projekte sind durch die straffe Modularisierung der zahlreichen Komponenten und Subkomponenten sehr gut beherrschbar. Ähnliches gilt für Betriebssystemkernel wie Linux. Durch die Formulierung schwach ausgeprägtes Modulkonzept im Artikel wird aber auch deutlich zum Ausdruck gebracht, dass das Modulkonzept von C nicht umfassend ist. --Burkhard 20:29, 5. Mai 2008 (CEST)

Da C annähernd Turing-vollständig ist, lässt sich sicher jedes Konzept (mehr oder minder gut) umsetzen, das steht außer Frage. Aber was z.B. die Datenkapselung angeht, ist dies recht mühsam, da man dem Benutzer damit unter anderem das Lifecycle-Management der Objekte aufbürdet, da er sämtliche Datentypen, die einen internen Aufbau haben, der "ihn nichts angeht", nur über Zeiger und modulspezifische (Hilfs-)Funktionen und Makros "anfassen" kann. Dass sowas geht, zeigen viele C-Bibliotheken. Dass dies umständlich ist, zeigen andere C-Bibliotheken, die die Benutzung zwar einfacher machen, dafür aber die Datenkapselung und "information hiding" verletzen müssen, in dem sie ihre struct-Definitionen in die Schnittstelle packen. --RokerHRO 23:07, 5. Mai 2008 (CEST)

Einleitung

Es wurde ja in letzter Zeit mehrmals die Information aus der Einleitung entfernt, dass C eine imperative Programmiersprache ist. Z.B. [[1]] mit der Begründung '(Revert. Die Information ist bei weitem nicht so wichtig, als dass sie in den Einleitungssatz gehören würde. Außerdem steht die Information weiter unten noch mal. Das sollte reichen.)'.

Welches Programmiersprachenparadigma eine Programmiersprache implementiert ist eine der wichtigsten Informationen über eine Programmiersprache. Und gehört somit auch in die Einleitung. Das die Information auch weiter unten im Text steht ist kein Argument (vergleiche auch Wikipedia:Wie_schreibe_ich_gute_Artikel#Begriffsdefinition_und_Einleitung). In der jetzigen Fassung erfährt der Leser nur, das C eine Programmiersprache ist, wer sie erfunden hat, wo, wann, und welche Sprachen sie beeinflusst hat. Aber eben nicht was für eine (Art von) Programmiersprache C überhaupt ist.

Vergleiche auch die Einleitungen der Artikel C++ und Haskell (Programmiersprache).

Also, bitte das 'imperativ' nicht schon wieder raus-revertieren. --Gms 20:17, 11. Aug. 2008 (CEST)

Da teile ich ganz die Meinung von Gms, aus genau den Gründen, die er genannt hat. Ausserdem müsste man mit der Begründung "steht schon im Artikel" auch die Informationen "Bell", "1970er" und "Ritchie" löschen. --Chiccodoro 20:42, 11. Aug. 2008 (CEST)

Gms, da bist du wohl einem Irrtum aufgesessen, denn in der Einleitung von C++ steht nichts von imperativ. --Naftalin-O 20:35, 12. Aug. 2008 (CEST)

In der Einleitung von dem Haskell Artikel steht auch nichts von imperativ ... - Spaß beiseite: In der Einleitung des C++ Artikels steht eben, welches Programmiersprachenparadigma bzw. welche Paradigmen C++ implementiert: also laut Einleitung ist C++ prozedural, objektorientiert und generisch (wobei prozedural imperativ impliziert - aber das nur nebenbei). --Gms 23:23, 12. Aug. 2008 (CEST)

Und was ist mit strukturiert? --Naftalin-O 16:55, 13. Aug. 2008 (CEST)

Programmierparadigmen

Sollte man in der Infobox nicht ebenfalls weitere Programmierparadigmen aufnehmen, die man in C ohne größere Schwierigkeiten benutzen kann? Unter anderem zum Beispiel Objektorientierte Programmierung (siehe zB GTK+) oder funktionale Programmierung (wenn man ein Subset von C verwendet). --Kingruedi 14:07, 19. Sep. 2008 (CEST)

Finde ich nicht. C an sich ist nicht objektorientiert noch funktional. Logisch kann man mit C auch funktionale und objektorientierte Paradigmen einführen, schliesslich ist C touringvollständig und "kann" sozusagen einfach alles, was der Computer kann. Genauso wie Assembler. Der wäre also somit auch objektorientiert und funktional, und ausserdem noch alles andere, was es an Paradigmen gibt. --Chiccodoro 14:24, 19. Sep. 2008 (CEST)

Turingvollständigkeit sagt nichts über die möglichen Programmierparadigmen aus. Wie ist überhaupt definiert, wann eine Programmiersprache objektorientiert ist? --Kingruedi 14:34, 19. Sep. 2008 (CEST)

Natürlich sagt Turingvollständigkeit etwas über die möglichen Programmierparadigmen aus. Welche Argumente hast du für deine gegenteilige Behauptung?

Das Feld 'Paradigmen' meint ja eben, für welche Paradigmen besondere Sprachunterstützung in der Sprache vorhanden ist. Die Paradigmen lassen sich objektiv begründen, wenn z.B. der Sprachentwickler selbst in einem History-Paper/Blog-Eintrag beispielsweise schreibt 'Sprache xy soll die strukturierte und modulare Programmierung vereinfachen/ermöglichen'. Oder wenn Konstrukte in der Sprache auftauchen, die auch in einer anderen Sprache auftauchen, die von deren Entwicklern objektiv belegbar eingeführt wurden, um ein bestimmtes Paradigma zu implementieren. Zu der Definition von einzelnen Paradigmen, gibt es natürlich auch Quellen, die sich damit auseinander setzen. --Gms 13:33, 21. Sep. 2008 (CEST)

Turingvollständigkeit sagt doch nur etwas über die Berechenbarkeit aus. Was hat das also mit den Programmierparadigmen zutun? Wenn es so wäre, dass Turingvollständigkeit bedeutet, dass man jedes mögliche Programmierparadigma nutzen kann, dann wäre das Feld ja nutzlos

Warum ist C dann nicht Objektorientiert, wenn man sich Beispielsweise GTK+ anschaut?

--Kingruedi 16:18, 21. Sep. 2008 (CEST)

Lies dir doch bitte nochmal Chiccodoro's Antwort durch. Er hat es doch schön präzise zusammengefasst: '[..] und "kann" sozusagen einfach alles, was der Computer kann. Genauso wie Assembler.'

Der Punkt ist, dass man in einer turingmächtigen Programmiersprache p in jedem Paradigma programmieren _kann_, wie man ja auch einen Compiler schreiben könnte, der ein Programm in einer Sprache mit besondere Sprachunterstützung für ein Paradigma x nach p übersetzt. Man kann in Assembler funktional programmieren. Nur ist dies eine Binse bzw. eine triviale Aussage. Die Aussage 'Sprache l implementiert Paradigma p' wird in der Informatik so verstanden, dass die Sprache so design't ist, dass sie das Programmieren in diesem Paradigma besonders einfach macht, bzw. eine besondere Unterstützung für das Paradigma durch spezielle Sprachelemente vorhanden ist. Und hier spielt natürlich das Ziel des Sprachentwicklers eine Rolle. Ritchie hat z.B. in seinem History-Paper nicht geschrieben, dass er mit C eine lazy-functional-Programmiersprache entwickeln wollte bzw. entwickelt hat. --Gms 00:09, 23. Sep. 2008 (CEST)

Turingvollständigkeit sagt nur etwas über Berechenbarkeit aus. Wenn eine Sprache turingvollständig ist, besagt das nur, dass die Sprache jede Funktion berechnen kann, die eine universelle Turingmaschine berechnen kann. Das hat einfach nichts mit Programmierparadigmen zu tun. Ein Programmierparadigma beschreibt ja nur einen Stil, eine Methode wie man Programme verfasst. Oder anders gesagt, wie programmiert man objektorientiert oder funktional in Brainfuck? Wenn man ein objektorientiertes (oder welches Paradigma auch immer) Programm in eine andere Zielsprache übersetzt ist es danach nicht zwangsläufig objektorientiert!

Und auch wenn Ritchie nicht vorhatte eine OO-Sprache zu entwerfen (zur Zeit in der C entworfen wurde, war OO ja auch noch sehr klein. Vielleicht wussten die noch nicht mal was davon). Aber das Ergebnis ist ja offensichtlich auch OO programmierbar. Wie u.a. GTK+ zeigt.

--Kingruedi 14:15, 23. Sep. 2008 (CEST)

Ich versuche es nochmals anders zu formulieren und hoffe, dass dir der springende Punkt klar wird: Das man in C irgendwie OO/funktional/whatever-Programmieren kann sagt nur etwas darüber aus, dass man in C irgendwie OO/funktional/whatever-Programmieren kann. Das hat einfach nichts mit Programmierparadigmen zu tun. Wenn man irgendwie ein OO-Modell in C übersetzt, ist es danach nicht zwangsläufig OO! --Gms 21:17, 23. Sep. 2008 (CEST)

Wenn man sich an der OOP-Programmieraradigma hält, hat es natürlich etwas mit dem Programmierparadigma zu tun. Ich finde es verwunderlich, wie man das anders sehen kann. Wenn man in C OO programmiert, dann ist es zwangsläufig OO. Siehe zB GTK+.

--Kingruedi 02:06, 24. Sep. 2008 (CEST)

Bevor ihr eure Infobox weiter verwässert, solltet ihr die Infos dort lieber mit Quellen belegen, sonst wird sie euch auch noch gelöscht, so wie es im Artikel C++ passiert ist (siehe dortige Diskussion darüber. :-(( --RokerHRO 14:30, 19. Sep. 2008 (CEST)

C stellt wenig syntactic sugar bereit, aber ich kann mit C von vielen verschiedenen Paradigmen Gebrauch machen. Ob ich Spagetticode oder wartbaren und sinnvoll gegliederten, strukturierten Code produziere, hängt vom Engagement des Programmierers ab. Ich sehe das ähnlich wie bei Perl, das mir auch alles erlaubt. Nicht umsonst gibt die Infobox im Perl-Artikel schon von Anfang an keine Paradigmen an. Deshalb mein Vorschlag: Löschen der Zeile „Paradigmen“ aus der Infobox. --Dagobert Drache 14:53, 19. Sep. 2008 (CEST)

Da gebe ich Dir recht. Wenn Du willst, kannst Du Deinen Vorschlag ja in der Diskussion über die Infobox einbringen.

--Kingruedi 22:18, 20. Sep. 2008 (CEST)

Wie wärs, sie durch "meistverwendetes Paradigma" oder so zu ersetzen? Durchs löschen geht m.E. mehr richtige Information verloren als falsche. --Chiccodoro 23:39, 20. Sep. 2008 (CEST)

Das wäre aber wieder POV. --Kingruedi 23:59, 20. Sep. 2008 (CEST)

C ist nicht Perl. Wenn ein Feld nicht sinnvoll für eine Sprache ist, dann muss es nicht direkt in der Vorlage gelöscht werden. Es ist beispielsweise sinnvoll für C. Siehe meine obige Antwort auf Kingruide und z.B. das History-Paper von Ritchie. --Gms 13:38, 21. Sep. 2008 (CEST)

Ich habe nicht gemeint, die Zeile aus der Vorlage zu löschen, sondern aus der hier verwendeten Box. Die Infobox sollte kein POV haben, sondern belegt sein – die jetzigen Einträge können etwa auf Richies The Development of the C Language verweisen. Ich kann aber auch belegen, dass C „objektorientiert“ ist, allein mit dem Satz „I had fun discovering that ANSI-C is a full-scale object-oriented language.“ (Axel-Tobias Schreiner in Object-Oriented Programming with ANSI C) Allerdings will ich das gar nicht wirklich, denn OOP für mich immer zuerst eine Denkweise, kein Sprachfeature. Unabhängig davon sollte die Hauptfrage aber sein: Verbessert die Zeile „Paradigmen“ den Artikel? Ich glaube: Nein. --Dagobert Drache 14:53, 23. Sep. 2008 (CEST)

Das sehe ich fast genauso.

–Kingruedi 15:20, 23. Sep. 2008 (CEST)

Bei deiner Argumentation unterläuft dir (genauso wie Kingruedi) ein logischer Fehler. Du implizierst: 'man kann irgendwie in einer Sprache x OO programmieren' => 'Sprache x implementiert das OO-Paradigma' bzw. 'Sprache bietet besondere Unterstützung für Programmieren im OO-Paradigma'

Und diese Implikation ist falsch. Ich muss es nochmal wiederholen: 'Die Aussage 'Sprache l implementiert Paradigma p' wird in der Informatik so verstanden, dass die Sprache so design't ist, dass sie das Programmieren in diesem Paradigma besonders einfach macht, bzw. eine besondere Unterstützung für das Paradigma durch spezielle Sprachelemente vorhanden ist.'

Ich hoffe, das alle Unklarheiten damit beseitigt sind. --Gms 21:11, 23. Sep. 2008 (CEST)

Wie kann eine Sprache ein OO-Paradigma implementieren. Ein Programmierparadigma ist ja vor allem ein Programmierstil. Wie soll der also in einer Sprache implementiert sein? Und wo kann ich bitte deine wird in der Informatik so verstanden Aussage nachlesen? Das klingt für mich eher nach wird von Gms so verstanden.

--Kingruedi 02:06, 24. Sep. 2008 (CEST)

Ganz einfach - sie stellt OO-Konstrukte zur Verfügung. Wo bitte findest Du Klassen und Operatorüberladen in C? Gar nicht! Du kannst höchsten versuchen, bestimmte Dinge in Bibliotheken nachzubilden, das macht wahrscheinlich GTK+. Simula, C++ und Java haben solche OO-Sprachkonstrukte schon eingebaut, d.h. der Compiler versteht sie ohne externe Bibliothek. Bitte informiere Dich erstmal, mir fällt da Bertrand Meyer: Objektorientierte Softwareentwicklung, Hanser 1990, ISBN 3-446-15773-5, ein. --Burkhard 02:16, 24. Sep. 2008 (CEST)

Seit wann ist Operatorüberladung ein Bestandteil der OOP? Auch Klassen stellen ja nur eine Ausprägung des OOP dar. Und man kann in C ja auch wunderbar Strukturen für Klassen benutzen. Ein Programmierparadigma beschreibt ja ein Programmierstil. Das also vor allem erst einmal etwas mit dem Programmierer und dem Code zu tun und erst dann etwas mit der Sprache. Gibt es überhaupt eine klare Definition wann sich eine Sprache als OO bezeichnen darf?

--Kingruedi 13:15, 24. Sep. 2008 (CEST)

Schaust Du hier - und dort. --Burkhard 19:43, 24. Sep. 2008 (CEST)

Ich sehe dort nichts, was deine Behauptungen untermauert und auch keine feste Definition ab wann man eine Programmiersprache als objektorientiert bezeichnen darf. --Kingruedi 19:02, 27. Sep. 2008 (CEST)

Ich seh das wie Kingruedi verstehe aber auch, dass es Leute gibt, die bei objektorientiert gleich nach dem Schlüsselwort class rufen. Ist C objektorientiert? Nein. Erlaubt es mir C, objektorientiert zu programmieren? Ja. All die netten Dinge über C (sie ist ja eine großartige Sprache, und deswegen sind wir alle hier), all die Dinge also, die in dieser Diskussion angeschnitten wurden, gehören eigentlich auch in den Artikel. Ich werde jetzt nachdenken, in welcher Art und auf welche Weise das geschehen kann und es dann einfügen. Geht aber erst am oder nach dem Wochenende und eigentlich will ich vorher noch was über die Geschichte von C schreiben. Wer also vorher schon Zeit und Ideen hat, soll ruhig erweitern. --Dagobert Drache 17:20, 24. Sep. 2008 (CEST)

@Kingruedi: Belege doch einfach die Behauptung "Programmierparadigma beschreibt Programmierstil" mit Quellen aus der wissenschaftlichen Literatur und schon ist die ganze Diskussion hier beendet. Bis dahin --Burkhard 19:43, 24. Sep. 2008 (CEST)

Das habe ich aus der englischen Wikipedia. Aber Dir steht es natürlich frei das Gegenteil meiner Behauptungen mittels Fachliteratur aufzuzeigen oder deine eigenen Behauptungen mit solcher zu untermauern. --Kingruedi 19:02, 27. Sep. 2008 (CEST)

Der Begriff Paradigma im Zusammenhang mit Programmiersprachen wird in der Wikipedia sehr unscharf benutzt. In der Wissenschaft wird die OOP oft lieber als Programmierstil bezeichnet, da sie Programmierparadigmen nicht entgegensteht, sondern auf ihnen aufbaut; sie ergänzt (die "großen" objektorientierten Sprachen sind immer imperativ, oft strukuriert und prozedural). Programmiersprachen unterstützen Programmierparadigmen durch Sprachkonstrukte. Entsprechend spricht man, will man nach Grundlegenden Paradigmen unterscheiden, von imperativen, funktionalen, logikbasierten und regelbasierten Programmiersprachen. C unterstützt durch Sprachkonstrukte die imperative, prozedurale, eingeschränkt modulare und strukturierte Programmierung - (sicher habe ich hier was vergessen) NICHT aber die Objektorientierte Programmierweise. Sicher ist es damit möglich (je mächtiger eine Sprache, desto mehr kann man aus ihr basteln), jedoch wird das weder ernsthaft praktiziert (in der Softwareentwicklung) noch durch die Sprache erleichtert. Dass sich durch C objektorientierte Konzepte realisieren lassen, hat der Meilensteinwerfer der OOP, Bertrand Meyer, ja selbst gezeigt (Eiffel wird vor der Kompilierung in C übersetzt). C selbst kann jedoch nicht als Objektorientiert bezeichnet werden, wird es in seriöser Literatur auch nicht und wir dürfen das hier auch nicht tun. Sonst müsste man jede Sprache mit der man Programmierstile (und auch Paradigmen) ertricksen kann, in all diese Stile kategorisieren. Das würde das Einteilen in Paradigmen und Stile ad absurdum führen. --Lupenrein 20:26, 27. Sep. 2008 (CEST)

Der Punkt ist einfach, dass es offenbar keine feste Definition für OOP, Programmierparadigmen und die Unterstützung von Programmierparadigmen in Programmiersprachen gibt. Jeder definiert die Punkte anders. Ich weiß nur nicht, wie wir hier zu einer vernünftigen und möglichst objektiven Meinung kommen.

Was braucht es also nach deiner Meinung, dass eine Programmiersprache als objektorientiert qualifiziert? Die Fähigkeit, damit objektorientiert programmieren zu können, ist es ja offenbar nicht.

--Kingruedi 23:43, 28. Sep. 2008 (CEST)

Ja, die Fähigkeit hängt von der Mächtigkeit ab - da wäre C ja quasi alles. Ob eine Sprache "objektorientiert ist" oder nicht, hängt vom Sprachdesign ab. Also ob sie dazu gestaltet wurde, objektorientiert zu Programmieren. Wie wär's mit: eine Sprache ist dann objektorientiert, wenn sie Konstrukte enthält, die objektorientierte Programmierung unterstützen. C enthält diese Konstrukte nicht. Dass dies auch von C-Freunden so gesehen wird, zeigt am besten die Geschichte von C++ (vgl. C with Objects) die u.a. dazu entworfen wurde, Objektorierung zu C hinzuzufügen. -- Lupenrein 17:06, 29. Sep. 2008 (CEST)

Sieh dir mal diese Liste an Liste objektorientierter Programmiersprachen, dort ist recht treffend formuliert: Eine objektorientierte Programmiersprache ist eine Programmiersprache, deren allgemeine Organisationsstruktur das Objekt ist und die damit die objektorientierte Programmierung besonders unterstützt. -- Lupenrein 17:48, 29. Sep. 2008 (CEST)

Nicht mehr erreichbare Weblinks

Gerade die interessantesten Weblinks, die bei Bell Labs gehostet wurden, sind nicht verfügbar. (Murphy lässt grüßen) cm.bell-labs.com existiert nicht mehr, bell-labs.com leitet zu alcatel-lucent.com weiter.

• Ritchie über die Geschichte von C (engl.)
• Abhandlung über die Urzeiten von C und Compilerversionen von 1972/73 (engl.)

--Carminox 00:30, 19. Okt. 2008 (CEST)

Kann ich nicht nachvollziehen - es dauert zwar ein bißchen, bis die Seiten aufgebaut werden, aber die Links funktionieren definitiv. Hab Deine Änderung revertiert. --Burkhard 11:08, 19. Okt. 2008 (CEST)

Ja, das war wirklich zu voreilig von mir. Zu dem Zeitpunkt, als ich die Links getestet habe, war selbst die DNS-Abfrage negativ. Entweder wurde die IP des Server in dem Zeitraum gewechselt oder die Putzfrau ist über das Netzwerkkabel vom Server gestolpert... :X --Carminox 01:32, 22. Okt. 2008 (CEST)

Hallo Welt - kein beliebiges Beispielprogramm

Das Hallo-Welt-Programm ist nicht einfach ein beliebiges Beispielprogramm - ich habe daher die Änderung der Überschrift durch eine IP am 31. Mai 2008 revertiert. --Burkhard 22:58, 2. Jun. 2008 (CEST)

Sinn und Zweck der Infobox

Vielleicht mögen sich von euch auch einige an der Diskussion hier beteiligen, wo es darum geht, was eigentlich in diese Infobox soll/gehört und was nicht. --RokerHRO 16:03, 19. Sep. 2008 (CEST)

Hello World mit EXIT_SUCCESS

Wieso muss unbedingt das Makro EXIT_SUCCESS, statt 0 im Beispiel verwendet werden? Das bläht den Code nur unnötig auf und verschleiert für Anfänger den Sinn von Rückgabewerten. EXIT_SUCCESS ist in stdlib.h definiert. Ich bin dafür das #inlude "stdlib.h" samt EXIT_SUCCESS rauszuwerfen, so wie das auch im englischen Wiki der Fall ist. --Stefan Schultz 11:15, 23. Dez. 2008 (CET)

Es gibt halt Plattformen, wo als erfolgreiches Programmende ein Wert != 0 erwartet wird. EXIT_SUCCESS ist auf jenen Plattformen dann 1, EXIT_FAILURE ist 0. Andere (plattformabhängige) Werte wären auch möglich. Siehe § 7.20 Abs. 3 im C99-Standard. --RokerHRO 12:22, 23. Dez. 2008 (CET)

Ich dachte stdlib.h definiert EXIT_SUCCESS immer mit 0. Ich kann im besagten § 7.20 Abs. 3 nichts konkretes dazu finden. Im Standard heißt es: "Finally, control is returned to the host environment. If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned." Die Betonung liegt bei dem ODER! Für mich klingt das so, als ob auch bei 0 an exit() ein implementierungsabhängiger Wert übergeben wird. Insofern scheint es sich bei der Rückgabe um ein Synonym zu handeln. Daher kann man auch return 0 schreiben. --Stefan Schultz 13:48, 23. Dez. 2008 (CET)

Das Thema wurde schon vor einiger Zeit diskutiert, EXIT_SUCESS war damals Konsens. EXIT_SUCESS und die Einbindung durch #include <stdlib.h> wird im Text erläutert und hat somit sogar einen gewissen Mehrwert gegenüber einem kommentarlosen return 0. Gruß, --Burkhard 22:38, 3. Jan. 2009 (CET)

Auch der verlinkten Diskussion kann ich den Grund für die Verwendung von EXIT_SUCCESS nicht entnehmen. Nach ANSI C99 Standard ist return 0 gleichbedeutend mit EXIT_SUCCESS, auf allen Plattformen. Das ein kommentiertes EXIT_SUCESS gegenüber einem unkommentierten 0 einen gewissen Mehrwert aufweist, liegt in der Natur der Sache. Der Artikel soll aber nicht den Sinn und Zweck von Rückgabewerten erläutern, genausowenig wie das im C++ Artikel gemacht wird. --Stefan Schultz 21:13, 7. Jan. 2009 (CET)

In C++ ist ein return 0; bei main() gänzlich entbehrlich. :-) --RokerHRO 13:25, 8. Jan. 2009 (CET)

Um was genau geht es Dir dabei? Das Beispiel ist korrekt und Standard-konform, zeigt die Verwendung von Defines und #include-Anweisungen, verwirrt den Leser nicht dadurch dass return 0; draufsteht, wo evtl. ein anderer Wert zuürckgegeben werden kann - als kompaktes Beispielprogramm also gar nicht mal so schlecht, wenn auch für alte Hasen vielleicht etwas ungewohnt. Klassische Hello-World-Programme stehen woanders und die en:WP diskutiert selten über Inhalte mit uns hier bei de:WP. Verklicker uns doch einfach den Mehrwert return 0; gegenüber EXIT_SUCCESS, dann sind wir bestimmt dabei. Gruß, --Burkhard 22:39, 8. Jan. 2009 (CET)

Mir geht es um eine gewisse Konsistenz in Bezug auf die englische Wikipedia. Es leuchtet mir gegenwärtig nicht ein, warum in der deutschen Wikipedia unbedingt EXIT_SUCCESS in Kombination mit der stdlib.h verwendet werden muss, nach dem Motto „Be different, be cool“. Persönlich habe ich keine Probleme mit dem aktuellen Programmbeispiel. Und es geht nicht um den Mehrwert, sondern darum das Hello World Beispiel möglichst kompakt zu halten. Bei einem return 0; entfällt nunmal eine Header. --Stefan Schultz 15:09, 9. Jan. 2009 (CET)

Beachtet bitte die Definition in Hallo-Welt-Programm: Ein Hallo-Welt-Programm ist ein kleines Computerprogramm und soll auf möglichst einfache Weise zeigen, welche Anweisungen oder Bestandteile für ein vollständiges Programm in einer Programmiersprache benötigt werden und somit einen ersten Einblick in die Syntax geben. Die Verwendung von aus anderen Dateien importierten Konstanten mach die Einfachheit und Klarheit dermaßen zunichte, dass ich mich an den Kopf fassen muss. --Thüringer ☼ 15:52, 9. Jan. 2009 (CET)

Nur zur Klarstellung vorweg: - ich habe EXIT_SUCCESS damals nicht eingeführt, sondern im wesentlichen nur die Erläuterungen im Text angepasst und ein Kommentar eingefügt. Dass ich diese Fassung jetzt verteidige, hat folgende Gründe

• Das klassische Hello-World-Programm findet sich bereits hier, eine wortwörtlich Wiederholung im Artikel über C ist redundant und bringt keinen Mehrwert.
• Wie bereits in der ursprünglichen Disku zu EXIT_SUCCESS gesagt, sollte das Beispielprogramm die wichtigsten Sprachmerkmale möglichst kompakt darstellen - sollte der Name Hello World dabei stören, wäre eine andere Benennung zu überlegen.
• Konsistenz mit der englischsprachigen Wikipedia ist schlicht ein Null-Argument, dort ist in manchen Artikeln der größte Blödsinn zu finden (wie bei uns auch ;-) --Burkhard 07:58, 10. Jan. 2009 (CET)