Diskussion:C (Programmiersprache)/Archiv/2005

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

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Schwächen

C schreibt die Speichergröße verschiedener Typen in der Sprachdefinition nicht vor. Dies ermöglicht die Portierung bestehender Programme auf andere, auch neue Prozessoren. Es ist nur zugesichert, dass ein short int nicht länger sein darf als ein long int. In den 1980er und 1990er Jahren wurden vorwiegend 32-Bit Systeme wie VAX, 68000, i386 eingesetzt. Bei diesen waren Zeiger, int und long alle 32 Bits lang, so dass sich dies als Quasistandard etabliert hat. Dies bereitet Probleme bei der Portierung auf modernere 64-Bit-Architekturen, falls der Programmierer von bestimmten Längen ausgegangen ist. würde ich gern entfernen. Das ist keine Schwäche von C (zumindest keine die über "wilde Zeiger" hinausgeht, sondern eine schwäche der Programmierer. In jedem vernünftigen C-Buch steht, man soll nicht davon ausgehen, das Zeiger die selbe Grösse hätten wie int-Varablen. Oder seh ich das falsch?--EoltheDarkelf 01:41, 21. Apr 2005 (CEST)

Ich stimme dem zu. Abgesehen davon ist der Satz C schreibt die Speichergröße verschiedener Typen in der Sprachdefinition nicht vor. IMHO so nicht korrekt / missverständlich. Beispielsweise schreibt der Standard vor, dass der Typ short int mindestens Werte zwischen -32.767 und +32.767 aufnehmen kann - und eben nicht nur, dass ein short int nicht länger sein darf als ein long int. -- Daniel 00:53, 26. Mai 2005 (CEST)

---

Hi ich finde den Letzten abschnitt Mangelnde Eignung für größere Projekte ist doch irgendwie durch den Abschnitt Stärken Fast alle Kernels der bekannten Betriebssysteme sind in C implementiert. widerlegt. bin also für das löschen, da es offensichtlich eine ganze Menge von großen Projekten gibt die sich unter C Programmieren lassen. Auch die Aussage: Die Speicherverwaltung ist fehleranfällig halte ich in dieser form für reihe Polemik. sie ist nicht schlimmer als anderen Sprachen, malloc & Co liefern im Fehler fall null zurück das kann man anfragen. Eine Exectipon muss nicht sein. Also sollte diese Aussage etwas Konkretisiert werden oder ersatzlos gestrichen. Imon 12:50, 05. Juni 2006 (CEST)

Der Widerspruch liegt leider in C selbst. C ist geeignet für große Projekte und wurde und wird immer wieder dafür eingesetzt. Und C ist gleichtzeitig völlig ungeeignet, weil es fast sämtliche Erkenntisse der modernen Softwaretechnik ignoriert. Der C-Standard verhindert ja sogar einen C-Compiler, der auch nur eine Option "Feldgrenzenprüfung" zuläßt. Das geht in C einfach nicht. Viele große Projekte könnten mit anderen Sprachen schneller und mit besserem Ergebnis programmiert werden. Die Existenz großer verwendbarere Libraries in C ist oft das einzige Argument für die Wahl dieser Programmiersprache. Und natürlich das klassische "das ham wir schon immer so gemacht". Viele Programmierer sind in C ausgebildet und programmieren in C; Viele Softwarefirmen haben große Teile ihres Codes in C; ein Umstieg zu anderen Sprachen bedeutet Aufwand (Lernaufwand) und Kosten.

C sollte ein Scherz sein

In einer Anküdigung, die die Computer-Industrie verblüffte, haben Ken Thompson, Dennis Ritchie und Brian Kerninghan zugegeben, dass das von ihnen geschaffene Betriebssystem Unix und die Programmiersprache C ein raffinierter Aprilscherz sind, der sich über 20 Jahre am Leben erhalten hat. Bei einem Vortrag vor dem letzten UnixWorld-Software-Entwicklungsforum enthüllte Thompson: "1969 hatte AT&T gerade die Arbeit am GE/Honeywell/AT&T-Multicasprojekt beendet. Brian und ich experimentierten zu diesem Zeitpunkt mit einer frühen Pascal-Version von Professor Niklaus Wirth vom ETH-Laboratorium in der Schweiz und waren beeindruckt von seiner eleganten Einfachheit und Mächtigkeit. Dennis hatte gerade 'Der Herr der Klinge' gelesen, eine spöttische Parodie auf Tolkiens große Trilogie 'Der Herr der Ringe'. Im Übermut beschlossen wir, Parodien zur Multics-Umgebung und zu Pascal zu verfassen.

Dennis und ich waren für die Betriebssystemumgebung verantwortlich. Wir sahen uns Multics an und entwarfen ein neues System, das so komplex und kryptisch wie möglich sein sollte, um die Frustration der gelegentlichen Nutzer zu maximieren. Wir nannten es Unix in Anspielung auf Multics und fanden es auch nicht gewagter als andere Verballhornungen.

Danach entwickelten Dennis und Brian eine wirklich perverse Pascal-Version names 'A'. Als wir bemerken, daß einige Leute tatsächlich versuchten, in A zu programmieren, fügten wir schnell einige zusätzliche Fallstricke hinzu und nannten es 'B', 'BCPL', und schließlich 'C'. Wir hörten damit auf, als wir eine saubere Übersetzung der folgenden Konstruktion erhielten:

for(;P("\n"),R--;P(";")) for(e=E;e--;P("_"+(*u++/8)%2)) P(" "-(*u/4)%2);

Der Gedanke, daß moderne Programmierer eine Sprache benutzen würden, die solch eine Anweisung zuließ, lag jenseits unseres Vorstellungsvermögens. Wir dachten allerdings daran, alles den Sowjets zu verkaufen, um ihren Computer- Fortschritt 20 Jahre und mehr zu verhindern.

Unsere Überraschung war groß, als dann AT&T und andere US-Unternehmen tatsächlich begannen, Unix und C zu verwenden! Sie haben 20 weitere Jahre gebraucht, genügend Erfahrung zu sammeln, um einige bedeutungslose Programme in C zu entwickeln, und das mit einer Parodie auf die Technik der 60er Jahre ! Dennoch sind wir beeindruckt von der Hartnäckigkeit (falls nicht doch Gemeinsinn) des gewöhnlichen Unix- bzw. C-Anwenders. Jedenfalls haben Brian, Dennis und ich in den letzten Jahren nur in Pascal auf einem Apple Macintosh programmiert, und wir fühlen uns echt schuldig an dem Chaos, der Verwirrung und dem wirklich schlechten Programmstill, der von unserem verrückten Einfall vor so langer Zeit ausging."

Namhafte Unix- und C-Anbieter und Benutzer, einschließlich AT&T, Microsoft, Hewlett-Parkard, GTE, NCR und DEC haben vorläufig jede Stellungnahme abgelehnt. Borland International, ein führunder Anbieter von Pascal- und C- Werkzeugen, einschließlich der populären Turbo Pascal, Turbo C und Turbo C++, meinte, sie hätten diesen Verdacht schon seit Jahren gehegt und würden nun dazu übergehen, ihre Pascal-Produkte zu verbessern, und weitere Bemühungen um die C-Entwicklung stoppen.

CS 28.04.2005

---

Das klingt nett, aber kann man die Quelle dazu angeben? Almdudi 13:59, 10. Dez 2005 (CET)

---

Der Text Stammt wohl von Netzmafia.de. Als Quelle ist dort angegeben "Quelle: Bernhard L. Hayes, NetNews-Gruppe"

War anscheinend ein Aprilscherz, das Original Zitat stamm aus der "Computerworld" vom 1. April 1994, siehe z.B.:

• http://casablanca.informatik.hu-berlin.de/database/pi3-ws2004/VL/01.C-Ueberblick.PI-3.pdf
• http://www.textfiles.com/humor/COMPUTER/creators.hoa

Keine Ahnung wie in weit man es trotzdem zur charakterisierung von C im Artikel benutzen kann... :) Gruß Azrael. 16:22, 24. Nov. 2007 (CET)

div. Haarspaltereien

stdio.h erklärt; "hosted" überall da eingefügt, wo es fehlte (hrmpf!), "Performanz" entschärft - das ist ein Märchen, guckt euch mal den Assembler-Output an, C hat Eigenschaften, die Optimierung geradezu verhindern, z.B. die ganze Pointer-Aliasing-Geschichte; dass C-Programme fix sind, liegt daran, daß die anderen Sprachen noch lahmer sind, OOP-Bloatgeil sind oder ihre Programmierer knechten. Daß C ein Highlevel-Assembler ist, wird dadurch "widerlegt", daß man Betriebssysteme in C schreibt?!!! Oh Mann. (und allein die *Idee* ein OS in C++ zu schreiben.. oh gott. operator knew oder was?!). "Algorithmen" entfernt (was soll das?) --Miez 08:23, 13. Jun 2005 (CEST)

Insgesamt finde ich Deine Änderungen nicht sehr gelungen. Zu einigen tiefergehenden fachlichen Aspekten kann ich nichts sagen, aber was haben Bemerkungen wie kleinen Text gibts leider nicht (Doch, gibts? Oder worauf bezieht sich das?) oder Hinweis: Solche Programme tun für gewöhnlich nichts Nützliches. in einem Enzyklopädie-Artikel zu suchen? Auch was ein ("hosted") C-Compiler ist erschliesst sich dem Laien kaum und trägt nicht gerade zur Klärung bei. Auch der Sinn Deiner Löschungen bei den Stärken und Einfügungen bei den Schwächen (was bitte ist ein Carry-Flag?) erschliesst sich mir nicht. Bitte bedenke das der Artikel sich nicht in erster Linie an C-Cracks, die sowieso schon alles wissen was darin steht, richten sollte, sondern dem (interesierten) Laien Informationen liefern soll. Und da sind Deine Änderungen leider wenig hilfreich. Trotzdem möchte ich nicht alles einfach reverten, sondern Dich bitten, Deine Änderungen unter den oben genannten Gesichtspunkten nocheinmal zu überarbeiten.--EoltheDarkelf 14:23, 13. Jun 2005 (CEST)

Stimmt, kenne nicht jeden Wikibefehl auswendig. Wird ausgebessert. Das nix Nützliches war ein SCNR. Ich formuliere das mal in Richtung erträglich um (oder versuche es zumindest). Bei hosted und Carry schau ich mal. --Miez 16:29, 13. Jun 2005 (CEST)

Der Quatsch mit "sooo viele Betriebssysteme in C geschrieben beweisen, daß C kein Highlevel-Assembler ist" wurde wieder eingefügt. "Ich glaube nicht, daß es draußen regnet, denn es sieht so feucht aus", oder was? Bei einem Betriebssystem will man einen portablen Highlevel-Assembler, das war ja das Tolle an C und UNIX (vor C wurden die nämlich mühselig in Assembler geschrieben). Und Betriebssysteme in C++ ... ach macht doch was ihr wollt ;( --Miez 06:54, 14. Jun 2005 (CEST)

Lass Dir doch von unkommunikativen IP's nicht die Lust verderben! Das kommt leider immer mal wieder vor, dass jemand ohne irgendeine Begruendung was aendert, und man sich wundert, was das soll. Vor allem IP's tendieren dazu. Das gibt sich - oder man gewoehnt sich dran - ja nachdem :-). Zum konrekten Fall: der Abschnitt "Ueberblick" sieht aus wie ein Sammelsurium von Fakten, die immer mal wieder jemand eingefuegt hat - ohne dass diejenigen den Abschnitt als Ganzes bearbeiten wollten - auch das passiert hier leider zimlich oft (macht aber wohl jeder - ist Wiki-bedingt). Wenn das als Ganzes umgearbeitet wuerde, wuerde wohl irgendow wieder was von Kernels stehen - aber halt im richtigen Zusammenhang. Dann waere wohl jeder gluecklich. Nut trau ich mich nicht an sowas ;-) --Sig11 ? 10:38, 14. Jun 2005 (CEST)

Newbiefrage

Ich habe WinXP, wie starte ich da das C-Programm? Oder muss ich es mir erst herunterladen und installieren? Ich meine, einfach so mit cmd die DOS-Box öffnen und programmieren ist ja nicht. Wo also gebe ich die C-Programmbefehle ein? 84.172.209.147 03:41, 12. Jul 2005 (CEST)

Wie bei allen Programmiersprachen wird ein Interpreter oder Compiler benötigt. Ersterer führt die Programmzeilen direkt aus, zweiterer macht ein klassischen Programm (beispielsweise .exe) aus dem Quelltext. Bei C wird üblicherweise ein Compiler verwendet, ich weiss jedenfalls von keinem C-Interpreter. Bei Windows ist meines Wissens kein C-Compiler dabei. Aber Du kannst ja mal eine Suchmaschine anwerfen, es gibt viele kostenlose C-Compiler, da wird doch der eine oder andere für Windows dabei sein. -- Dishayloo [ +] 10:49, 12. Jul 2005 (CEST)

Probier mal DevCpp - hat eine nette GUI, ist relativ einsteigerfreundlich (im Vergleich zu anderen IDEs) und kostenlos bzw. sogar Open Source! Xell 16:10, 12. Jul 2005 (CEST)

Am besten im Zusammenhang mit einen guten Anfängertutorial --Jonathan Hornung 08:23, 31. Jul 2005 (CEST)

Was ich nicht ganz glauben kann: Dass Windows keinen eingebauten Interpreter/Compiler haben soll. Aber zuzutrauen wärs denen ja. 84.172.215.166 13:13, 2. Aug 2005 (CEST)

Ein Interpreter für C - das wär wohl die Lahmheit in Person. (Ich meine, mich erinnern zu können, von sowas mal gehört zu haben - lang ists her!) Aber ein interessantes Projekt. Sollte man mal den GCClern andienen. Unter XP gibts mit Sicherheit keinen C-Compiler. Wofür auch? Der Kernel wird gekauft, mit einigem Geld bezahlt und mit mehreren hundert MB DLLs auf der Platte verfeinert. Es braucht keine Neucompilate wie bei Linux, wenn man mal was neues einbauen möchte. Einfache eine neue DLL - und scho isch de Kiddl gflickt. Und wenn man Office sein eigen nennt - VBA ist auch noch verfügbar. NIL Problem... Im Übrigen: My favorite free C: LCC (Little C Compiler)

Cinterpreter gibt es mehrere. Zum einen das undürchschaubare cint([1]), das nochnichteinmal bison oder lex benutzt, aber immerhin sich selber interpretien kann und cinter([2]), die Entwicklung scheint eingeschlafen zu sein, es läuft aber manches. Schlecht ist das aber nicht wenn man mal eben ein kleines Programm mit ca20 zeil zum Luafen bringen will.(beide könne auch c++)

Zur ursprünglichen Frage: C-Programmbefehle gibt man in ein Textfile mit der Endung „.c“ ein. Diese wiederum gibt man einem C-Compiler (hinter dem wiederum ein Linker hängen muß) als Futter, der wiederum daraus ein ausführbares Programm mit der Endung „.exe“ macht. Dieses File wiederum kann XP als Programm ausführen. Es macht dann das, was die Prammbefehle im auftragen.

Ein „C-Programm“ in dem Sinn wie z.B. EXCEL oder Paint gibts so nicht. Normalerweise redet man in dem Zusammenhang von einer „Integrierten Entwicklungsumgebung“, neudeutsch IDE (Integrated Development Environment, was auch mein geliebter LCC ist). Die liefert alles, was man zur Entwicklung von Programmen in der Programmiersprache C braucht: Texteditor (schreiben der Programmbefehle), Compiler (Übersetzen der Programmbefehle in Maschinencode), Bibliotheken (für Funktionen, die man nicht selbst schreiben muß), Linker (der den ganzen Gammel in ein ablauffähiges Programm zusammenbaut). --Harald Wehner 02:22, 6. Okt 2005 (CEST)

Fehlende Relevanz

Eine exotische Programmiersprache namens "GOC" hat nicht den gleichen Stellenwert wie z.B. C++. Dies sollte auch im Artikel nicht so dargestellt werden. Daher habe ich den Eintrag wieder entfernt. --Kadeck 11:15, 13. Aug 2005 (CEST)

-62.180.172.92 19:50, 25. Aug 2005 (CEST) GOC ist keine exotische Programmiersprache, sondern C mit erweiterten Befehlen zur objektorientierten Programmierung und dies sehr viel mächtiger als in C++. GOC IST C. Also hat es hier was zu suchen.

GOC ist nicht C. Warum schreibst du nicht über GOC einen eigenen Artikel? :-) --Kadeck 17:55, 27. Aug 2005 (CEST)

Literaturliste, Weblinks und Bewertung der Sprachmerkmale

Der Artikel ist momentan in wirklich keinem besonders guten Zustand. Besonders störend ist die ellenlange Liste der Vor- und Nachteile von C und die lange Literaturliste und schlecht ausgesuchten Weblinks. Bei der Literaturliste scheint mir inzwischen bald jedes Anfängerbuch über C aufgelistet zu sein. Weiter Meinungen? Ideen wie man weiter vorgehen kann? -- Daniel 19:14, 11. Jul 2005 (CEST)

Bezüglich der Literatur- und Linkliste kann ich dir nur zustimmen. Schmeiß raus was nicht reinpasst!
Die Liste der Vor- und Nachteile könnte man vielleicht in Fließtext umwandeln. --Kadeck 17:49, 27. Aug 2005 (CEST)

Ich finde die Literaturliste ist mittlerweile viel zu kurz geraten - einzig auf Kernighan&Ritchie zu verweisen finde ich beileibe nicht ausreichend; natürlich gehört es mit in die Liste, aber kein Mensch lernt wirklich nur anhand diesen Buches. Drum werde ich nun wieder mein favourisiertes (noch dazu nativ deutsches) Buch eintragen, welches sich sowohl für den Einsteiger als auch den ambitionierten Nutzer zu lesen lohnt. Des Weiteren hoffe ich, dass es nicht wieder binnen eines Monates aus der Liste verschwindet, denn ich gehe stark davon aus, dass Menschen sich positiv daran bereichern können. Darüber hinaus gibt's von mir noch einen Weblink, denn das Buch gibt es auch frei verfügbar im Netz - auch das passt meiner Ansicht nach viel besser als ein Link auf "Programming in C" aus dem Jahr 1974! --preek Thu Dec 29 20:46:21 CET 2005

Von wegen Qualitaetssicherung; ich habe mir mal 'Programmieren in C' (Sommergut) angeschaut - und nun eine Begruendung warum ich ich es als Weblink aus dem Artikel entfernen moechte: - teils fragwuerdige/zu pauschale/in der Allgemeinheit falsche 'Tips'. Z.B.: "Verwenden Sie für kleine Aufgaben Makros anstelle von Funktionen! Sie erhöhen damit die Geschwindigkeit des Programms. Gehen Sie aber bei komplexeren Problem en oder fehleranfälligen arithmetischen Berechnungen auf Nummer sicher und bleiben Sie bei der Definition von Funktionen!" oder "Ziehen Sie die bedingte Kompilierung dem "Auskommentieren" von Programmteilen vor. Diese ist übersichtlicher, flexibler und vermeidet verschachtelte Kommentare." Sowas steht dann unter der Ueberschrift 'guter Programmierstil'. - in einfachen Beispielen wird die Fehlerbehandlung vergessen (z.B. fclose) - unnoetiger nicht-ANSI/MS-DOS-Bezug an einigen Stellen (near/far pointer, conio.h) - C wird nicht als Hochsprache eingeordnet - in der Einfuehrung werden Interpreter vs. Compiler verglichen, aber als wesentlicher Unterschied nur der Schutz geistigen Eigentums durch das erzeugte Kompilat genannt - es wird fuer ueberluessige Schreibweisen 'Konvention' als Begruendung genannt - ist das schon Cargo Cult? - es wird nichts ueber die Modularisierung von C-Programmen im Allgemeinen oder die Verwendung von Watcher-Makros in C-Headern geschrieben

Im Vergleich dazu bietet das C-Wiki-Book deutlich mehr, bzw. hat eine hoehere Qualitaet und man kann dort auch noch Inhalte verbesseren. Und da wir schon auf das Wiki-Book schon verweisen, ist es IMHO gerechtfertigt diesen Weblink zu entfernen. --Gms 20:18, 28. Mai 2007 (CEST)

Immo Weblink:

• verletzt das dinkumware copyright
• ein Mirror, welcher nicht seine Quellen nennt
• teilweise redundant, da ein paar Inhalte schon ueber den 'Programming in C' Weblink erreichbar sind
• Inhalte wie die glibc- oder djgpp-Referenz haben eher was mit Posix/Unix/Linux/Dos-Programmierung zu tun

-> deswegen entfernt --Gms 20:36, 28. Mai 2007 (CEST)

C-HowTo:

• kein Mehrwert gegenüber schon verlinkter Literatur (wie z.B. das C-WikiBook), eher das Gegenteil
• z.B. öfter in Beispielen 'int main()'
• bei Behandlung von Zeigern, keine Behandlung von Funktionszeigern

-> deswegen entfernt --Gms 00:03, 4. Mai 2008 (CEST)

Zu Gms's Kommentaren:

• Das C-HowTo liefert sicherlich eine andere Erklärung als das Wikibook, für den User wäre es also besser ihm eine gewisse Auswahl an HowTos zu lassen, da jeder andere Erklärungen braucht um Dinge zu verstehen.
• 'int main()' wird nur in Beispielen mit mehreren Programmzeilen verwendet, die zummengefasst ein kleines Programm ergeben, somit kann der User es mit copy un paste auch einfacher selbst testen.
• Die Funktionszeigern befinden sich im Kapitel "Funktionen Teil 2": http://www.c-howto.de/tutorial-funktionen-teil2-zeiger-auf-funktionen.html

--> Deshalb nochmals reingesetzt

--Cient 21:25, 30. Juni 2008 (CEST)

Von wegen 'andere Erklärung': Mit dem Argument müssten wir alle zig-trillionen C-Bücher, C-Online-Kurse, C-Linksammlungen etc. in dem Artikel verlinken - egal wie inhaltlich gut oder schlecht sie sind bzw. ob sie zusätzlich relevant sind. Nur ist Wikipedia keine Link-Sammlung. Und das c-howto.de weist Schwächen auf bzw. bietet nicht mehr als schon verlinkte Literatur/Inhalte. Es hat einiges an Mühe gekostet die aktuelle Linkliste auszumisten und in einen relevanten Zustand zu überführen.

Die Kritik an 'int main()' ist nicht das in Beispielen eine main-Methode definiert wird, sondern dass in Beispielen eine main-Methode ohne Ansi-C-Prototyp definiert wird. Das ist schlechter Stil, den Anfänger (die Zielgruppe) als Beispiel nicht vorgesetzt bekommen sollten.

Mich würde bei der Frage ob c-howto.de verlinkt werden soll oder nicht die Meinung von anderen Wikipedianern interessieren, die nicht direkt hinter c-howto.de stehen. Das der Autor von c-howto.de seine Seite bei Wikipedia verlinkt haben möchte kann ich ja verstehen. --Gms 11:19, 3. Jul. 2008 (CEST)

Siehe unten neuer Unterabschnitt. --Chiccodoro 16:44, 3. Jul. 2008 (CEST)

dmoz-OpenDirectory-Link:

• nicht wirklich C-sprachspezifisch: in der Kategorie dort geht es um Algorithmen und Datenstrukturen, eine Bildbearbeitungslib (die wohl in C implementiert ist), Win-Api Programmierung, Kryptographie und sowas
• es ist schon eine umfangreiche Linksammlung verlinkt - und diese ist gut gepflegt und thematisch passend ( http://www.lysator.liu.se/c/ )

-> deswegen entfernt --Gms 00:11, 4. Mai 2008 (CEST)

-->OpenDirectory-Link: Mir hat diese Linksammlung sehr geholfen! Ich bin dafür, dass der Link wieder eingefügt wird.

Gut - aber das alleine ist ja kein Argument, IMHO. Mir haben auch so einige Links, die am Rande mit C zu tun hatten, sehr geholfen, und trotzdem möchte ich sie nicht in diesem Artikel haben. Es geht ja um die Relevanz in Bezug auf diesen Artikel. PS: Beiträge auf der Diskussionsseite bitte beim nächsten Mal signieren. --Gms 22:50, 5. Mai 2008 (CEST)

Siehe unten neuer Unterabschnitt. --Chiccodoro 16:44, 3. Jul. 2008 (CEST)

Diskussion über Links

Hallo. Ich bin ganz der Meinung von Gms. Es geht hier nicht um "nützliche" Links um programmieren zu lernen. Wikipedia ist kein Tutorial, sondern eine Enzyklopädie. Wenn schon müssten meiner Meinung nach solche Links im bereits existierenden und verlinkten Wikibook eingefügt werden. --Chiccodoro 16:44, 3. Jul. 2008 (CEST)

Hallo-Welt-Programm: printf oder puts?

Gibt es irgendeinen tieferen Grund für die komplizierte Variante

printf("%s", "Hallo Welt!\n");

wenn man auch einfach

puts("Hallo Welt!");

schreiben könnte?--Gunther 15:48, 21. Sep 2005 (CEST)

Gute Idee! Ich bin für puts. Auf keinen Fall printf ("Hallo Welt!\n"); wie es verbreitet ist. -- Hokanomono 16:00, 21. Sep 2005 (CEST)

printf wird auch in K&R benutzt und wurde in vielen anderen Büchern so übernommen. Ich sehe da auch keine großen Vorteile puts zu benutzen. Das "%s" ist sowieso überflüssig. -- 141.70.109.83 10:08, 22. Sep 2005 (CEST)

Ich hab die Bibel nie gelesen: Hat K&R eigentlich schon puts() - oder ist das später dazugekommen? --Harald Wehner 02:27, 6. Okt 2005 (CEST)

Also zumindest in der 2. Ausgabe finden sich hinweise zu Puts sowohl in dem I/O Abschnitt als auch im Appendix B

Der Hauptgrund für printf ist seine Vielseitigkeit. Gerade in einem Lehrbuch (und das war K&R) sollten am Anfang nicht zu viele Konzepte gleichzeitig vorgestellt werden. printf ist für sehr viele Arten von Ausgabe geeignet (Strings, Zahlen in verschiedensten Formaten, Zeichen). Die Alternative wäre gewesen, puts für das Hello-World-Beispiel zu verwenden und danach nie wieder. --RolandIllig 22:17, 8. Jan 2006 (CET)

Ich halte es nicht fuer sinnvoll printf einzufuehren, es schaft komplexitaet die man als anfaenger eher umgehen sollte und die in einem Beispiel nichts zu suchen hat. Wenn man schon printf benutzen moechte, dann bitte auch mit printf ("%s\n", "Hello, world"). -- FaUl

Wieso nicht printf("Hello%s%c\n", ", world", '!');? Die einfachste printf-Variante ist wohl printf("Hello, world!\n"); und so wuerde das wohl auch nahezu jeder schreiben. Daran ist nichts komplex oder undefiniert und es ist auch kein Sicherheitsproblem. Problematischer dagegen finde ich dagegen puts() und aehnliches zu verwenden ganz besonders da fputs() im Gegensatz zu puts() keinen Zeilenumbruch anhaengt. Diese Funktionen sind prinzipiell voellig ueberfluessig und verwirren bloss. Um *printf() kommt man als C-Programmierer sowieso kaum herum und die Komplexitaet haelt sich fuer das Gros der Anwendungsfaelle nun wirklich in Grenzen. --82.141.61.74 15:47, 20. Jan 2006 (CET)

Nur minimalistisch (wie ein Hello-World-Programm m.E. sein sollte) ist es mit printf nicht; das ist eine ziemlich mächtige Funktion, deren Verwendung das Programm (d.h. den übersetzten und gelinkten Code) viel größer macht als nötig...

Allerdings hat es wenig Zweck, C-Anfängern printf ersparen zu wollen. Man kommt ja eh nicht drumrum, und die Formatierungsstrings kann man auch in anderen Sprachen wiederfinden. --Tobias 16:07, 14. Apr. 2007 (CEST)

printf heisst doch soviel wie print formatet, also formatiert ausgeben. Wenn ich meinen String nicht formatieren muss, warum sollte ich dann diese Funktion benutzen? Das ist völlig sinnlos. Ein ordentlicher Programmierer wird immer versuchen seine Programme so klein wie möglich zu halten, desshalb rate ich puts oder besser gleich fputs zu benutzen.

ich programmiere seit jahren c und c++ und habe noch nie etwas von "puts" gehört. :) kenne neben printf sonst höchstens noch cout. --217.84.58.206 14:40, 6. Mär. 2008 (CET)

Ich benutze nur write(), oder manchmal eine Funktion mit dem noetigen inline-Assembler, oder gleich ganz auf assembler umsteigen... printf einfach aus bequemlichkeit benutzen wenn man effizienter sein kann, dann gleich noch 1GB Ram zu kaufen. Gentfloo

Man keonnte (so habe ich das fast vergessen) auch fputs("Hallo", stdout) verwenden, diese Funktion nutzt im gegensatzt zu puts() nur einen i/o-Vector ;))) Gentfloo

Natürlich sollte ein Hello-World-Programm so einfach wie möglich sein. Aber was macht printf("Hello, world!\n"); soviel komplizierter als puts("Hello world!")? Der Zeilenumbruch? Der ist hoffentlich dem Leser des Artikels noch knapp zuzumuten. Es kann nicht schaden, im Hello-World-Beispiel diejenige Variante kennenzulernen, der er in zahlreichen Tutorials und Alltagssituationen begegnen wird, und die ihm den Weg zu vielen Formatierungsfunktionen offen lässt. Ein Hello-World-Programm muss nicht einen kleinen Binärcode generieren, oder sonst: warum nicht gleich alle möglichen Optimierungen vornehmen? Ich finde, das Hello-World-Programm sollte die Welt dieser Sprache repräsentieren, und da gehören printf und '\n' mehr dazu als putf. --Chiccodoro 18:39, 10. Jul. 2008 (CEST)

Literaturhinweis

Joachim Goll, Ulrich Bröckl, Manfred Dausmann: C als erste Programmiersprache - Vom Einsteiger zum Profi, Teubner, ISBN 3-519-32999-9

Manfred Dausmann oder Michael Dausmann? Quellen gibt es für beide Varianten, Michael wird allerdings wesentlich häufiger genannt. -- RainerBi ✉ 12:04, 2. Mai 2005 (CEST)

Ich empfehle auch C für PCs von Peter und Ulla Kirch-Prinz. Beide haben auch das sehr beliebte Buch C++ lernen und professionell anwenden geschrieben. Das Buch ist sehr gut geschrieben und vor allem im deutschsprachigen Raum ein Standardwerk. Die ISBN-13 lautet 978-3826607844. --Stefan Schultz 11:06, 23. Dez. 2008 (CET)