"gets" wurde in C11 entfernt!?

Die Frage ist doch eher warum sowas erst reinkommt.

Tim schrieb:

Die Frage ist doch eher warum sowas erst reinkommt.

Die Welt des Programmierens war jung und unschuldig.

Wutz

Die "Frage" ist sehr leicht zu beantworten:
Weil gets schon seit K&R Zeiten drin war und insbesondere K&R wussten, was sie tun wenn sie gets einsetzen, was man von der Mehrheit ihrer Möchtegernnachfolger nicht behaupten kann.

Wutz schrieb:

gets war schon in C99 als "deprecated" gekennzeichnet und ist folgerichtig in C11 nun endgültig raus.

C99? wer braucht schon C99? wo doch C90 schon so überflüssig war.

Das einzig wahre ist nach wie vor C89, aka "ANSI-C". alles andere kann man in die tonne treten.

Jetzt versuchst du es aber zu sehr!

EinGast schrieb:

Jetzt versuchst du es aber zu sehr!

ne, das ist mein bitterer ernst.

C90 ist (fast?) inhaltsgleich mit C89, nur dass C90 von der europäischen ISO standardisiert wurde, und nicht vom amerikanischen ANSI.

C99 bringt massenhaft unnötiges zeug, z.b. neue datentypen, die niemand braucht, und die ich auch noch nie in irgendwelchen c-quellcodes gesehen hab.

Wutz schrieb:

Die "Frage" ist sehr leicht zu beantworten:
Weil gets schon seit K&R Zeiten drin war und insbesondere K&R wussten, was sie tun wenn sie gets einsetzen, was man von der Mehrheit ihrer Möchtegernnachfolger nicht behaupten kann.

Ui, das würde mich jetzt aber schon interessieren: Inwiefern ist gets() von K&R eingesetzt anders als gets() von ~K&R eingesetzt?

C11 schrieb:

EinGast schrieb:

Jetzt versuchst du es aber zu sehr!

ne, das ist mein bitterer ernst.

C90 ist (fast?) inhaltsgleich mit C89, nur dass C90 von der europäischen ISO standardisiert wurde, und nicht vom amerikanischen ANSI.

C99 bringt massenhaft unnötiges zeug, z.b. neue datentypen, die niemand braucht, und die ich auch noch nie in irgendwelchen c-quellcodes gesehen hab.

Das ist nicht dein ernst oder? Was sollen das für Quellcodes gewesen sein? C99 ist heutzutage Pflicht, schon wegen den genannten Datentypen wie z.B. uint8_t, uint16_t etc.. Sobald du platformunabhängigen code oder daten festergröße brauchst sind sie unverzichtbar. In C weißt du eben nicht wie groß ein int ist. Klar kann man die auch nachbauen, aber hier sind sie standardisiert, du musst dir nicht bei jeder Platform darüber informieren wie groß int, long etc. groß sind und deine Defines anpassen.
Außerdem bieten die neuen Standards auch endlich einen richtigen bool Typen an (stdbool.h) und eingebaute Komplexezahlen. Und das sind nicht die einzigen Gründe.

uint8_t schrieb:

Das ist nicht dein ernst oder? Was sollen das für Quellcodes gewesen sein? C99 ist heutzutage Pflicht, schon wegen den genannten Datentypen wie z.B. uint8_t, uint16_t etc.. Sobald du platformunabhängigen code oder daten festergröße brauchst sind sie unverzichtbar. In C weißt du eben nicht wie groß ein int ist. Klar kann man die auch nachbauen, aber hier sind sie standardisiert, du musst dir nicht bei jeder Platform darüber informieren wie groß int, long etc. groß sind und deine Defines anpassen.
Außerdem bieten die neuen Standards auch endlich einen richtigen bool Typen an (stdbool.h) und eingebaute Komplexezahlen. Und das sind nicht die einzigen Gründe.

mein beitrag war wohl etwas missverständlich. natürlich weiß ich, dass die bytegröße eines datentypen in c nicht genormt ist.

mit den "neuen Datentypen" meinte ich: _Bool , _Complex , _Imaginary

C99 ist heutzutage Pflicht

Da kann ich nicht zustimmen. C99 sieht beispielsweise vor, dass man das " return x; " (ersetze "x" mit einer beliebigen zahl) weglassen darf, wenn man die main-Funktion verlässt.

Ein C99 Hello World sähe also so aus:

#include <stdio.h>

int main()
{
     printf("Hello World\n");
}

und jetzt erzähl mir nicht, dass das standard ist. wenn du so einen code schreibst, ist man schneller weg vom fenster, als dass man "Das ist C99" sagen kann.

Deine Aussage müsste heißen:
"C89/C90 ist heutzutage Pflicht"

ich denke, es hat schon seinen grund, dass viele compilerhersteller C99 nur rudimentär implementieren, oder ganz weglassen. das lässt tief blicken.

return x;

kannst du laut aktuellem C-Standard nur weglassen solange x gleich 0 ist!

Bei anderen Werten für x musst du es schreiben!

Und, wenn du bei "gets" schon Panik bekommst, dann schau mal in das MSDN was da noch eventuell alles bei denen auf der Entfernen-Liste oder Ersetzen-Liste steht.
Und Microsoft ist nicht verdächtig C99 gross zu unterstützen.

f.-th. schrieb:

return x;
kannst du laut aktuellem C-Standard nur weglassen solange x gleich 0 ist!

Bei anderen Werten für x musst du es schreiben!

wusste ich garnicht. aber das ist auch gut so. soetwas ist sehr schlechter programmierstil, den man sich garnicht angewöhnen sollte.

ja, ich hab, als ich gesagt hab, dass manche compiler C99 nicht unterstützen, an ms gedacht.

für mich ist C89 das einzig wahre. C90 von der ISO hat C keinen schritt weitergebracht. mag sein, dass C99 diese pseudo-genormten datentypen mitgebracht hat, aber deshalb werde ich trotzem nicht absichtlich einen schlechten code schreiben, auch wenn C99 das anscheinend erlaubt und unterstützt.

Zwingt dich jemand diesen Stil anzuwenden? Nein. C war schon immer eine Sprache, die von einem verlangte zu wissen was man da tut. Dafür bekommst du völlige Freiheit. Es ist paradox, zum einen stellst du das als schlechten Stil hin, andererseits wunderst du dich warum gets entfernt wurde. Wie passt das zusammen?
Außerdem bekommst du sowieso eine Warnung mit -Wall, wenn du eine non-void Funktion nur mit return; beendest (außer indem Fall von main(), was aber so gewollt ist). Ohne -Wall sollte niemand ein C Programm kompilieren, Warnungen sollte man ernst nehmen. Das sollte jeder C-Programmierer wissen.
Ganz ehrlich, das ist Meckern auf höchsten Niveau.

uint8_t schrieb:

Zwingt dich jemand diesen Stil anzuwenden? Nein. C war schon immer eine Sprache, die von einem verlangte zu wissen was man da tut. Dafür bekommst du völlige Freiheit. Es ist paradox, zum einen stellst du das als schlechten Stil hin, andererseits wunderst du dich warum gets entfernt wurde. Wie passt das zusammen?
Außerdem bekommst du sowieso eine Warnung mit -Wall, wenn du eine non-void Funktion nur mit return; beendest (außer indem Fall von main(), was aber so gewollt ist). Ohne -Wall sollte niemand ein C Programm kompilieren, Warnungen sollte man ernst nehmen. Das sollte jeder C-Programmierer wissen.
Ganz ehrlich, das ist Meckern auf höchsten Niveau.

1. es ist wahr, C bringt einem große Freiheit, mit der anscheinend nicht jeder umgehen kann. aber deshalb programmier ich ja in C.
2. nun ja, du musst wissen: mit der Funktion "gets" hab ich mich eigentlich noch nie so richtig beschäftigt. ich hab immer fgets benutzt (auch wenn ich von stdin lese).
3. Es weiß eben leider nicht jeder C-Programmierer, z.b. Anfäger könnten das nicht wissen. es ist nicht gut, wenn man erlaubt, code wegzulassen, den dann der compiler "automatisch" dazugibt.
manchmal liest man hier im forum auch noch so sachen wie "main()" (ohne int) (das ist ein überbleibsel aus dem K&R-"Standard"). das zeigt, dass sich anscheinend nicht jeder mit allen c-standards auskennt, und nicht jeder selbst entscheiden kann, was im standard "gut" oder "schlecht" ist. außerdem kompiliert nicht jeder mit der option "-Wall".
C99 ist ein standard für Programmierer, die schon programmieren können, und wissen, was sich "gehört" und was nicht, bzw. die wissen, wann man etwas weglassen darf und wann nicht.

darf ich fragen, warum du hier jetzt C99 so unterstützt?

es ist fast nicht möglich "vollständig" in C99 zu programmieren, einfach aus dem grund, weil die meisten compiler c99 nur teilweise unterstützten, manche auch garnicht: http://en.wikipedia.org/wiki/C99#Implementations
deshalb hat sich die sache mit c99 schon seit jahren erledigt.

C11 schrieb:

ich denke, es hat schon seinen grund, dass viele compilerhersteller C99 nur rudimentär implementieren, oder ganz weglassen. das lässt tief blicken.

Von welchen sprichst du? MSVC stammt von Microsoft, was erwartest du von denen? Die wollen C++ pushen nichts anderes und meinen sie wissen was die Entwickler brauchen . Deshalb haben sie dann ab C89 aufgehört, manche Dinge wie stdint.h siehst du nur weil das für C++ sowieso rein muss.
Dann wären da noch die anderen großen Kompiler für x86 GCC und Clang => C11, bei Intel bin ich mir gerade nicht sicher aber C99 unterstützt der auf jeden Fall. ARM Kompiler von Keil unterstützt auf jeden Fall C99 wahrscheinlich auch C11. GCC-AVR kann sowieso C99, ist glaube ich auch automatisch eingestellt. Beim PIC Kompiler genauso. Also welche wichtigen Kompiler meinst du, das wahren so ziemlich die wichtigsten auf der Welt. Wie du siehst ist dreht sich die Welt nicht um Microsoft.

Achso schau mal auf C11, also wenn Multithreading nichts wichtiges ist, was dann? Mal ausgenommen im Bezug auf Embeddedsystemen.

bevors untergeht:

C11 schrieb:

uint8_t schrieb:

Zwingt dich jemand diesen Stil anzuwenden? Nein. C war schon immer eine Sprache, die von einem verlangte zu wissen was man da tut. Dafür bekommst du völlige Freiheit. Es ist paradox, zum einen stellst du das als schlechten Stil hin, andererseits wunderst du dich warum gets entfernt wurde. Wie passt das zusammen?
Außerdem bekommst du sowieso eine Warnung mit -Wall, wenn du eine non-void Funktion nur mit return; beendest (außer indem Fall von main(), was aber so gewollt ist). Ohne -Wall sollte niemand ein C Programm kompilieren, Warnungen sollte man ernst nehmen. Das sollte jeder C-Programmierer wissen.
Ganz ehrlich, das ist Meckern auf höchsten Niveau.

1. es ist wahr, C bringt einem große Freiheit, mit der anscheinend nicht jeder umgehen kann. aber deshalb programmier ich ja in C.
2. nun ja, du musst wissen: mit der Funktion "gets" hab ich mich eigentlich noch nie so richtig beschäftigt. ich hab immer fgets benutzt (auch wenn ich von stdin lese).
3. Es weiß eben leider nicht jeder C-Programmierer, z.b. Anfäger könnten das nicht wissen. es ist nicht gut, wenn man erlaubt, code wegzulassen, den dann der compiler "automatisch" dazugibt.
manchmal liest man hier im forum auch noch so sachen wie "main()" (ohne int) (das ist ein überbleibsel aus dem K&R-"Standard"). das zeigt, dass sich anscheinend nicht jeder mit allen c-standards auskennt, und nicht jeder selbst entscheiden kann, was im standard "gut" oder "schlecht" ist. außerdem kompiliert nicht jeder mit der option "-Wall".
C99 ist ein standard für Programmierer, die schon programmieren können, und wissen, was sich "gehört" und was nicht, bzw. die wissen, wann man etwas weglassen darf und wann nicht.

darf ich fragen, warum du hier jetzt C99 so unterstützt?

es ist fast nicht möglich "vollständig" in C99 zu programmieren, einfach aus dem grund, weil die meisten compiler c99 nur teilweise unterstützten, manche auch garnicht: http://en.wikipedia.org/wiki/C99#Implementations
deshalb hat sich die sache mit c99 schon seit jahren erledigt.

Ok 100% scheint der Standard tatsächlich nicht implementiert zu sein und das da ein haufen Schrott dabei ist, will ich auch nicht bestreiten. Allerdings finde ich das man kein neues Projekt mehr mit älteren Standard als C99 anfangen sollte, einfach schon wegen stdint.h und Variablen Definition im Schleifenkopf. Und -Wall sollte nun wirklich jeder C-Programmierer kennen, der Kompiler meckert nicht umsonst.

uint8_t schrieb:

Ok 100% scheint der Standard tatsächlich nicht implementiert zu sein und das da ein haufen Schrott dabei ist, will ich auch nicht bestreiten. Allerdings finde ich das man kein neues Projekt mehr mit älteren Standard als C99 anfangen sollte, einfach schon wegen stdint.h und Variablen Definition im Schleifenkopf. Und -Wall sollte nun wirklich jeder C-Programmierer kennen, der Kompiler meckert nicht umsonst.

dem stimme ich prinzipiell zu, aber eigentlich ist es mir scheißegal, ob ein int 4 bytes oder mehr hat, es reicht mir, zu wissen, dass ein int mindestens 4 bytes hat.
es gibt vielleicht noch computer, bei denen der int 2 bytes ist, aber das sind so wenige, die kann man getrost vergessen.

unsigned int a = 1;

// oder
#include <stdint.h>
uint32_t a = 1;

da ist es eigentlich egal, das zweite beispiel ist lediglich mehr schreibarbeit. außerdem machen solche "pseudo-datentypen" die syntax-highlightning-funktionen von editoren kaputt.

außerdem steht in stdint.h auch nichts anderes als

typedef unsigned int uint32_t;

das weiß ich, obwohl ich den quellcode garnicht gesehen habe

C89 wird von 100% der c-compiler 100%ig unterstützt.

Als C-Entwickler kann man richtig neidisch auf seine C++ Kollegen sein. Bei C wird sich, so wie es aussieht, leider nicht mehr viel ändern. Ich hoffe das Gegenteil, aber das Standardkommite traut sich nichts.

uint8_t schrieb:

Als C-Entwickler kann man richtig neidisch auf seine C++ Kollegen sein. Bei C wird sich, so wie es aussieht, leider nicht mehr viel ändern. Ich hoffe das Gegenteil, aber das Standardkommite traut sich nichts.

naja, wenn am ende dann doch sowas wie c99 rauskommt, verzichte ich gerne auf weitere standards.

wenn man sich andere programmiersprachen so zum vergleich anschaut, dann kommt da ca. alle 10-15 jahre ein neuer standard.

c ist recht einsteigerunfreudnlich, weil man relativ viel falsch machen kann, deshalb wird es mit den jahren wohl immer weniger leute geben, die c lernen

C11 schrieb:

dem stimme ich prinzipiell zu, aber eigentlich ist es mir scheißegal, ob ein int 4 bytes oder mehr hat, es reicht mir, zu wissen, dass ein int mindestens 4 bytes hat.
es gibt vielleicht noch computer, bei denen der int 2 bytes ist, aber das sind so wenige, die kann man getrost vergessen.

Ja aber hier versichert dir der Kompiler, dass uint32_t auch wirklich 4Bytes groß sind. Es reicht nicht immer zu wissen dass der Typ min. so groß wie x. Z.B. im Code für 8Bit Mikrocontrollern (hier AVR) wirst du größtenteils uint8_t vorfinden, int wäre hier 2Byte groß, das wäre möglicherweise eine Verschwendung von einem Byte (der größte Controller hat 4kB RAM!), was aber noch wichtiger ist eine 16Bit Berechnung dauert hier sehr viel länger als eine 8Bit Berechnung. Was ich damit sagen will ist, dass es Platformen gibt wo man wirklich wissen muss wie groß die Datentypen sind und das sind vor allem Embeddedplatformen (jetzt der Hauptbereich für C) C wurde auf dem Desktop fast vollständig von C++ abgelöst, lediglich bei absoluten low-level Zeug kann C Parade bieten. Dort geht es oft einzelne Bytes.

Du musst dir unbedingt mal Code vom Embedded- und Betriebssystembereich ansehen. Dort wirst du viel von stdint.h sehen.
Beispiel: PrettyOS http://www.c-plusplus.net/forum/252232

&quot;gets&quot; wurde in C11 entfernt!?

"gets" wurde in C11 entfernt!?