Einen schönen guten Abend,
ich bin absoluter C Neuling und versuche mich gerade mit dem Buch
"C programmieren lernen für dummies" von Dan Gookin einzuarbeiten. Daher
bitte ich um Nachsicht für meine sicherlich triviale Frage.
Ich habe folgendes kleines Programm, unter Nutzung von CodeBlocks,
erstellt:
--------------------
#include <stdio.h>
main()
{
char txtstr[5];
strcpy(txtstr, "100°C");
printf (txtstr);
return(0);
}
--------------------
Das funktioniert soweit auch bis auf die Tatsache, das das ° Zeichen
nicht als solches ausgegeben wird sondern ersatzweise zwei Sonderzeichen
auf der Konsole abgebildet werden (siehe Screenshoot). Nun habe ich
gelesen, das es zum einen daran liegen kann, dass die Codepages nicht
übereinstimmen, aber daß man eine Ausgabe unter Zuhilfenahme des
Hexcodes der Codepage erreichen kann. Beispiel unter der Codepage 437
wäre das "°" Zeichen als 0xF8 zu erreichen.
Nehmen wir mal an, das Programm sollte unter verschiedenen Codepages
laufen. Wie bekommt man es hin, dass der notwendige Hexcode in den
auszugebenden Textstring "integriert" wird.
Wäre schön wenn mir da jemand die Augen öffnen könnte.
Danke
Torsten
Angehängte Dateien:
-
Fehlerhafte_Ausgabe.JPG
14 KB
Torsten K. schrieb: > Daher > bitte ich um Nachsicht für meine sicherlich triviale Frage. Leider ist diese Frage alles andere als trivial und hat schon Generationen von Softwareentwicklern zur Verzweiflung getrieben. Wahrscheinlich geht ein Anfängerbuch gar nicht so weit, daß das Thema irgendwann geklärt wird. Tipp für den Anfang: Das Problem zurückstellen. Tipp für später (unter Windows: Stichwort "wchar". Viele Grüße W.T.
Und weil offene Klammern Programmierer immer nervös machen: )
Beitrag #5704358 wurde von einem Moderator gelöscht.
Beitrag #5704364 wurde von einem Moderator gelöscht.
Zusätzlich ist "char txtstr[5]" zu klein für den String.
. . schrieb im Beitrag
#5704378:
> Zusätzlich ist "char txtstr[5]" zu klein für den String.
Warum ist "char txtstr[5]" zu klein ? 100°C sind 5 Zeichen oder irre
ich?
Torsten K. schrieb: > Nun habe ich gelesen, das es zum einen daran liegen kann, dass die > Codepages nicht übereinstimmen, aber daß man eine Ausgabe unter > Zuhilfenahme des Hexcodes der Codepage erreichen kann. Hast du auch diesen Thread hier Beitrag "Char als Klartext im Quellcode ©" gefunden? Da steht ziemlich viel Information zu dem Thema, ich bin jetzt nur zu faul, die für dich relevanten Beiträge herauszupicken. > Nehmen wir mal an, das Programm sollte unter verschiedenen Codepages > laufen. Man kann unter bestimmten Voraussetzungen die im Ausgabemedium verwendete Zeichenkodierung abfragen, um dann im eigenen Programm eine passende Konvertierung durchzuführen. Das ist aber nicht ganz einfach, und ich weiß auch nicht auswendig, wie das geht, schon gar nicht unter Windows. Da du aber ein "absoluter C Neuling" bist, würde ich mich vorerst mit wichtigeren und grundlegenderen Dingen beschäftigen, bspw. damit: Strings in C haben immer ein NUL-Zeichen als Endekennung, was bei der Dimensionierung von char[]-Variablen berücksichtigt werden muss. Tut man dies nicht, droht Böses, weil über das Ende der Variable hinaus geschrieben wird. "100°C" hat 5 Zeichen, weswegen textstr mindestens mit [6] dimensioniert werden muss. Tatsächlich müssen es sogar [7] sein, weil '°' in der von Code::Blocks verwendeten UTF-8-Kodierung 2 Bytes belegt. Übrigens kann man mit strncpy statt strcpy die Anzahl der kopierten Bytes begrenzen, womit der Überlauf vermieden und ein möglicher Fehler leichter erkannt wird.
Von den Zeichenkodierungen abgesehen:
1 | char txtstr[5]; |
2 | strcpy(txtstr, "100°C"); |
txtstr hat Platz für 5 Bytes, deine Stringkonstante ist aber länger, je nach nach Codepage 5 oder mehr Bytes für die Zeichen an sich plus 1 Byte für den 0-Terminator. Der strcpy schreibt also über das Ende des txtstr-Arrays hinaus. Dass es keinen Programmabsturz gibt, ist mehr oder weniger Zufall ...
Danke Yalu... das mit dem String und Deiner Erklärung ist schon mal Klasse... dann macht auch der Satz des vorherigen Posts Sinn. Denn Link schaue ich mir mal an...
Also die Stichworte wären u.a. Escape-Sequenzen Hexcode Tabellen ( wie https://de.wikipedia.org/wiki/Codepage_850 ) Steuerzeichen und Schriftzeichen Alte Assemblerbücher (mit guten Nachschlagetabellen) (und weiter oben "Stack Overflow" (oder so..) (https://stackoverflow.com)
> Übrigens kann man mit strncpy statt strcpy die Anzahl der kopierten > Bytes begrenzen, womit der Überlauf vermieden und ein möglicher Fehler > leichter erkannt wird. Kein guter Rat. Der Nutzen von strncpy ist ziemlich zweifelhaft[1], da er den Zielbuffer nicht immer mit einer 0 terminiert - das Ergebnis ist kein gülter C-String und andere Routinen, die einen solchen erwarten (wie z.B. der printf), lesen über den Buffer hinaus, was ebenfalls falsch ist. Außerdem füllt strncpy den nichtgenutzen Bereich des Buffers unnötigerweise mit Nullen. [1] war ursprünglich designed, um Festbreitenfelder in Datei-Records zu füllen.
foobar schrieb: > [1] war ursprünglich designed, um Festbreitenfelder in Datei-Records zu > füllen. Ahh, danke.
Vor main gehört meiner Meinung nach noch ein int, immerhin lieferst du mit return 0 einen Rückgabetyp zurück. Die klammern um die 0 kannst du hier weglassen.
Yalu X. schrieb: > Strings in C haben immer ein NUL-Zeichen als Endekennung, was bei der > Dimensionierung von char[]-Variablen berücksichtigt werden muss. @Torsten, wenn dies nicht in dem Buch behandelt wird, ist es Mist.
Außerdem würde ich in der printf Anweisung noch ein "\n" einbauen. Die IDE mag zwar ihren eigenen Text in eine neue Zeile setzen, aber in der Kommandozeile ist das nicht mehr der Fall.
foobar schrieb: >> Übrigens kann man mit strncpy statt strcpy die Anzahl der kopierten >> Bytes begrenzen, womit der Überlauf vermieden und ein möglicher Fehler >> leichter erkannt wird. > > Kein guter Rat. Der Nutzen von strncpy ist ziemlich zweifelhaft[1], da > er den Zielbuffer nicht immer mit einer 0 terminiert Du hast recht, und ich ziehe hiermit meinen Tipp zurück. strncpy verhindert zwar einen Überlauf beim Schreiben, aber danach entstehen neue Probleme. Das war mir nicht (mehr) bewusst als ich den obigen Beitrag schrieb. PS: Wenn ich ahne, dass ich in einem Programm eine der Funktionen strcpy, strncpy, strcat oder strncat benötigen werde, wechsle ich meist schon vorher die Programmiersprache ;-)
Der Eindruck verfestigt sich: Es ist für eine einzelne Person unmöglich, ein funktionierendes C-Programm zu schreiben. Zu viele Fallstricke und Unwägbarkeiten, als daß sie noch von einer einzogen Person überblickt werden könnten.
Stringhandling war noch nie die Stärke von C.
Fazit schrieb: > Der Eindruck verfestigt sich: Es ist für eine einzelne Person unmöglich, > ein funktionierendes C-Programm zu schreiben. Zu viele Fallstricke und > Unwägbarkeiten, als daß sie noch von einer einzogen Person überblickt > werden könnten. Es gibt auch Personen, die deutlich weniger als C brauchen, um den Überblick zu verlieren.
Fazit schrieb: > Zu viele Fallstricke und > Unwägbarkeiten, als daß sie noch von einer einzogen Person überblickt > werden könnten. So viele sind das nicht. Das ist das schöne an C. Und man kann sich auch eigene Stringfunktionen schreiben, die mehr Sicherheit bieten. Dann tauscht man Schnelligkeit gegen Sicherheit. In C hat man die Wahl.
ImZweifel ist aber C++ dann doch die bessere Wahl. Sicherheit, und Geschwindigkeit.
vn nn schrieb: > ImZweifel ist aber C++ dann doch die bessere Wahl. Sicherheit, und > Geschwindigkeit. Im Zweifel nimmt man Rust. Wer sich mit C ins Knie schießt, der wird das auch mit C++ tun.
Nano schrieb: > Im Zweifel nimmt man Rust. > > Wer sich mit C ins Knie schießt, der wird das auch mit C++ tun. Darum kam doch Java raus oder? Damit man sich das Bein mit C++ nicht wegschießt. Jetzt wird Rust alle Probleme lösen? Irgendwie schießen jetzt neue Programmiersprachen wie die Pilze aus dem Boden.
zitter_ned_aso schrieb: > Darum kam doch Java raus oder? Damit man sich das Bein mit C++ nicht > wegschießt. Java war nie für die Systemprogrammierung gedacht und kann das auf normaler Hardware auch gar nicht. Daher konnte es C und C++ auch nie ersetzen und das war auch nie geplant. Bei Rust sieht das komplett anders aus, damit könntest du auch einen Betriebssystemkernel programmieren. Damit ist Rust eine theoretisch ernstzunehmende Alternative zu C und C++. Theoretisch deswegen, weil noch einiges vom Drumherum fehlt und es auch von der Marktakzeptanz abhängig ist, und wie sich das entwickelt kann nur die Zeit zeigen. Von der Sprache selbst aber steht dem nichts im Weg.
Yalu X. schrieb: [...] > PS: Wenn ich ahne, dass ich in einem Programm eine der Funktionen > strcpy, strncpy, strcat oder strncat benötigen werde, wechsle ich meist > schon vorher die Programmiersprache ;-) Das wüsste ich ja zu gerne, welche das ist. :-)
zitter_ned_aso schrieb: > Jetzt wird Rust alle Probleme lösen? Irgendwie schießen jetzt neue > Programmiersprachen wie die Pilze aus dem Boden. Das gab's doch eigentlich immer schon. Es gibt Modesprachen, die plötzlich "aus dem Boden" schießen und alle Probleme lösen wollen, und es gibt die bewährten Sprachen, die sich über Jahrzehnte halten und auch noch da sind, wenn die neueste Modesprache schon wieder verwelkt ist.
Es gibt seit C11 (also seit ca, 8 Jahren) die Funktion strcpy_s im Standard. Oder noch besser strncpy_s Achtung: strcpy_s ergibt einen Leerstring, wenn die Quelle nicht ins Ziel passt strncpy_s kopiert noch eine '\0' ans Ende vom Ziel, wenn Platz ist. Da gibt es noch mehr Funktionen, die einen Pufferüberlauf verhindern können. Wenn man weiß was man tut, ist C in Ordnung. Aber wer weiß das schon.
Yalu X. schrieb: > Hast du auch diesen Thread hier > > Beitrag "Char als Klartext im Quellcode ©" Leider ist da nicht wirklich das Problem gelöst worden. Danke erstmal für die ansonsten fachlichen Beiträge. Ich würde gerne drum bitten, beim Thema zu bleiben. Die letzten Post streifen doch sehr weit ab. Ich denke wenn ich das hier so lese, das meine Anfrage auch für andere Benutzer durchaus interessant ist, sofern sich eine sagen wir mal vorsichtig, allgemein gültige Lösung finden lassen würde. Denn so wie ich es bis jetzt verstanden habe gibt es die wohl nicht oder ich interpretiere da etwas falsch. Es sollte doch grundsätzlich möglich sein, Sonderzeichen in einem Strin ausgeben zu können ohne sich all zu sehr zu verbiegen. Aber vielleicht ist C dafür die falsche Programmiersprache was ich aber eigentlich nicht glauben will. Auch wenn ich erst Anfänger bin, wäre es für mich wichtig zu wissen, wie ich einen ich sage jetzt mal aus meiner Sicht einfachen String fehlerfrei zur Ausgabe bringe. Danke für sach- und fachdienliche Hinweise. Gruß Torsten Nachtrag: auch wenn ich CodeBlocks verwende, so wird dort von mir der GNU GCC Compiler genutzt.
Nano schrieb: > Wer sich mit C ins Knie schießt, der wird das auch mit C++ tun. Kannst du dies näher erläutern? Um beim Beispiel des Threads zu bleiben, klassische Probleme mit zu kurzen Strings oder Array-off-by-one sind in modernem C++ so ziemlich komplett eliminiert, weshalb die Sprache gerade für Anfänger ja auch viel einfacher ist. Man muss nicht erst kapieren, wie ein String intern aufgebaut ist, um ihn zu verwenden, hat aber im Hintergrund trotzdem auch sämtliche Möglichkeiten offen. Wer natürlich bloß einen C++-Compiler verwendet, aber trotzdem weiterhin C programmiert, wird sich auch weiterhin ins Knie schießen. Aber ja, Rust könnte sich durchaus zu einer ernstzunehmenden Alternative entwickeln.
Zumindest für den eingangs beschriebenen Fall kann die Länge des Strings auch vom Compiler bestimmt werden:
1 | char txtstr[] = "100°C\n\0"; |
Meine ich zumindest, hab es grad nicht getestet. Dies unterliegt aber natürlich weiterhin den Einschränkungen, die in diesem Thread schon angemerkt wurden.
Torsten K. schrieb: > Leider ist da nicht wirklich das Problem gelöst worden. Welches Problem genau? Von einem mit Code::Blocks geschriebenen C-Programm auf einer Konsole mit Codepage 437 ein "°" auszugeben? Eine – wenn auch nicht besonders schöne – Möglichkeit besteht darin, direkt den Zeichencode (hier F8) zu verwenden. Statt "100°C" schreibst du dann entweder "100\370C" (oktal) oder "100\xF8""C" (hexadezimal) Die beiden "" im zweiten Beispiel verhindern, dass das "C" als dritte Hexadezimalziffer interpretiert wird. Um den Quellcode leserlicher zu halten, kannst du den Compiler mit der Option -fexec-charset=cp437 anweisen, im Quellcode enthaltene String- und Char-Literale automatisch nach Codepage 437 zu konvertieren. Dann darfst du den String wie gewohnt als "100°C" schreiben.
Hallo Yalu, lieben Dank... das probiere ich gleich mal aus. Etwas ähnliches hatte ich heute Nacht in einem alten C Buch von Kernighan/Ritchie gelesen. Mir war nicht klar das Strings in der von Dir beschriebenen zweiten Weise zusammen gesetzt werden können. Danke
Christoph O. schrieb: > Zumindest für den eingangs beschriebenen Fall > kann die Länge des Strings auch vom Compiler bestimmt werden: > char txtstr[] = "100°C\n\0"; > Meine ich zumindest, hab es grad nicht getestet. Die \0 am Ende kannst du dir in dem Fall sparen, die hängt der Compiler automatisch an. Großer Vorteil dieser Deklaration :) MfG, Arno
Super... der Hinweis von Yalu funktioniert... mehr wollte ich ja erstmal nicht. Lieben Dank für alle gegebenen Hinweise. Gruß Torsten
Arno schrieb: > Die \0 am Ende kannst du dir in dem Fall sparen, die hängt der Compiler > automatisch an. Großer Vorteil dieser Deklaration :) Danke für den Hinweis, wieder was gelernt :-)
Meiner Meinung nach wäre es aber dennoch besser, gleich den Umgang mit UTF-8 zu lernen. Die alten Codepages sind eigentlich nicht mehr zeitgemäß und werden nie besonders schön aussehen, wenn eine andere Codepage verwendet wird, als die, für die das Programm compiliert wurde.
rbx schrieb: > Alte Assemblerbücher (mit guten Nachschlagetabellen) Muss gar kein Assemblerbuch sein, das bekommt man u.U. auch gar nicht so schnell. (gemeint war auch konkret "Programmiersprache Assembler. Eine strukturierte Einführung" von Reiner Backer mit seinen nützlichen Tabellen.) In dem C-Buch vom Erlenkötter sind die entsprechenden Tabellen für die Frage oben auch im Anhang.
> Java war nie für die Systemprogrammierung gedacht und kann das auf > normaler Hardware auch gar nicht. > Daher konnte es C und C++ auch nie ersetzen und das war auch nie > geplant. Java war als systemübergreifende bzw. plattformübergreifende Programmiersprache konzipiert, um C oder C++ Programme eben nicht auf einem anderen System neu schreiben zu müssen. > ImZweifel ist aber C++ dann doch die bessere Wahl. Sicherheit, und > Geschwindigkeit. totaler Blödsinn; C++ ist eine Obermenge von C und deshalb gleich schnell oder eben langsamer - das merkt man aber erst auf alten Rechnern und bei größeren Programmen. Auch in Puncto Sicherheit gibt es bessere Alternativen, nämlich ADA, das im u.a. im Militärbereich verwandt wird. C++ hat sich wegen u.a. wegen bunter Windows-Fenster, der besseren IDE, etc. durchgesetzt; insbesondere Fenstertechnik und graphische Oberflächen funktionierte mit C zur damaligen Zeit praktisch nicht.
statt 100°C schreibst Du notfalls 100 Grad Celsius und schon ist das Problem gelöst - primitiv, aber auch primitive Lösungen sind am Ende Lösungen; es geht um Improvisation und das können/wollen die meisten heute leider nicht mehr, weil jeder unbedingt mit dem Kopf durch die Wand will.
> der Hinweis von Yalu funktioniert... mehr wollte ich ja erstmal > nicht. Nicht wirklich. Dein Wunsch war: "das Programm sollte unter verschiedenen Codepages laufen." Schalt doch mal auf z.B. russisch um (CP878), da bekommst du dann statt des ° nun ein Ь - das ° liegt dort auf 0x9c. Wie die erste Antwort schon sagte: "Leider ist diese Frage alles andere als trivial und hat schon Generationen von Softwareentwicklern zur Verzweiflung getrieben." Mit UTF-8 wurde es dann einfacher und die meisten Betriebssysteme haben darauf umgestellt - Microsoft ist immer noch am flicken und hat dabei ziemliches Chaos angerichtet (richtig lustig wird's, wenn du es mit Dateinamen zu tun bekommst) ...
> Nicht wirklich. Dein Wunsch war: "das Programm sollte unter > verschiedenen Codepages laufen." Schalt doch mal auf z.B. russisch um > (CP878), da bekommst du dann statt des ° nun ein Ь - das ° liegt dort > auf 0x9c. > > Wie die erste Antwort schon sagte: "Leider ist diese Frage alles andere > als trivial und hat schon Generationen von Softwareentwicklern zur > Verzweiflung getrieben." das Problem ist, daß CodeBlocks unter Windows nicht ganz ANSI-conform zu sein scheint - ich bekomme sofort eine Fehlermeldung, weil die Headerdatei string.h fehlt, usw. Hier meine Lösung: #include <stdio.h> #include <string.h> int main(void) { char txtstr[10]; strcpy(txtstr, "100°C"); printf("\n%s\n",txtstr); }
S. B. schrieb: >> Java war nie für die Systemprogrammierung gedacht und kann das auf >> normaler Hardware auch gar nicht. >> Daher konnte es C und C++ auch nie ersetzen und das war auch nie >> geplant. > Java war als systemübergreifende bzw. plattformübergreifende > Programmiersprache konzipiert, um C oder C++ Programme eben nicht auf > einem anderen System neu schreiben zu müssen. Java ist keine Sprache für die Systemprogrammierung. Punkt. Guck nach was Systemprogrammierung bedeutet. Anwendungsprogrammierung ist keine Systemprogrammierung. Es hat einen Garbage Collector, eine Runtimeumgebung und Bytecode und ist auch nicht Echtzeitfähig, das sind alles Dinge, die es nicht für einen Kernel geeignet machen. Mit C, C++ und Rust kannt du einen Kernel aber sehr wohl programmieren.
> Java ist keine Sprache für die Systemprogrammierung. Punkt. > Guck nach was Systemprogrammierung bedeutet. Anwendungsprogrammierung > ist keine Systemprogrammierung. Hast Du meinen obigen Post nicht gelesen oder nicht verstanden ?! Nochmal als Wiederholung: Java ist eingeführt worden, um unabhängig von der Plattform bzw. dem jeweiligen Betriebssystem des Rechners programmieren zu können. Punkt!
foobar schrieb: > Mit UTF-8 wurde es dann einfacher und die > meisten Betriebssysteme haben darauf umgestellt - Microsoft ist immer > noch am flicken und hat dabei ziemliches Chaos angerichtet (richtig > lustig wird's, wenn du es mit Dateinamen zu tun bekommst) ... Man kann das jetzt allerdings nicht Microsoft vorwerfen. Viele wollen in der Eingabeaufforderung "cmd.exe" noch ihre alten Textgui Anwendungen laufen lassen, wie man sie von edit.exe oder Turbo Pascal 6 her kannte. Die ganzen Rahmen und Rahmenzeichen liegen in den länderspezifischen Codepages alle in der höheren 128 Bit Ebene so eines 1 Byte großen Zeichens und bei UTF-8 sind die ganz woanders. Man denke da bspw. an das UTF-8 Zeichen U+2566, welches in Codepage 850 unter 0xCB zu finden ist. https://de.wikipedia.org/wiki/Codepage_850 https://de.wikipedia.org/wiki/Rahmenzeichen Würde man die Eingabeaufforderung auf UTF-8 umstellen, dann würde dieses Rahmenzeichen als solches nicht mehr dargestellt werden und die Abwärtskompatibilität flöten gehen. Das gleiche gilt für länderspezifische Buchstaben. Da Microsoft aber schlecht die Software von Drittsoftwareherstellern ändern kann, bleibt es bei den üblichen Codepages zwecks Abwärtskompatibilität. Ein Vorwurf an Microsoft ist daher nicht gerechtfertigt. Fairer wäre, wenn man in der Powershell nachschauen würde, wie es da gelöst ist.
S. B. schrieb: >> Java ist keine Sprache für die Systemprogrammierung. Punkt. >> Guck nach was Systemprogrammierung bedeutet. Anwendungsprogrammierung >> ist keine Systemprogrammierung. > Hast Du meinen obigen Post nicht gelesen oder nicht verstanden ?! > Nochmal als Wiederholung: > Java ist eingeführt worden, um unabhängig von der Plattform bzw. dem > jeweiligen Betriebssystem des Rechners programmieren zu können. Punkt! Entscheidend ist doch folgendes, widersprichst du mir jetzt oder widerspricht du mir nicht? Wenn du mir nicht widersprichst, was willst du mir dann sagen? Wofür Java gemacht wurde, weiß ich nämlich selber, aber der Kontext ist das was zitter_ned_so oben gesagt hat. Siehe nochmal mein Kommentar auf seine Aussage: Beitrag "Re: C Neuling benötigt Schubs in die richtige Richtung" Sowie hier seine Aussage: Beitrag "Re: C Neuling benötigt Schubs in die richtige Richtung"
S. B. schrieb: > das Problem ist, daß CodeBlocks unter Windows nicht ganz ANSI-conform zu > sein scheint - ich bekomme sofort eine Fehlermeldung, weil die > Headerdatei string.h fehlt, usw. Das hängt auch von den Compileroptionen ab. Oder waren es "nur" Warnungen?
S. B. schrieb: > das Problem ist, daß CodeBlocks unter Windows nicht ganz ANSI-conform zu > sein scheint - ich bekomme sofort eine Fehlermeldung, weil die > Headerdatei string.h fehlt, usw. > Hier meine Lösung: > > #include <stdio.h> > #include <string.h> > > int main(void) > { > char txtstr[10]; > strcpy(txtstr, "100°C"); > printf("\n%s\n",txtstr); > } Also folgender Code läuft bei mir unter Nutzung des GNU GCC Compilers in CodeBlocks jetzt ohne Probleme #include <stdio.h> int main() { char txtstr[7]; strcpy(txtstr, "100\xF8""C"); printf (txtstr); return(0); }
Nano schrieb: > zitter_ned_aso schrieb: >> Darum kam doch Java raus oder? Damit man sich das Bein mit C++ nicht >> wegschießt. > > Java war nie für die Systemprogrammierung gedacht und kann das auf > normaler Hardware auch gar nicht. Falsch. Java hieß ursprünglich Oak und war genau dafür gedacht, als Alternative zu C++ [1] [2] Sowohl der Fokuswechsel - zunächst auf Applets im Web, später für diverse andere Verwendungen - kam erst später, weil sich der ursprüngliche Projektplan zerschlagen hatte. Der Namenswechsel von Oak zu Java war i.W. durch markenrechtliche Problem begründet. [3] > Daher konnte es C und C++ auch nie ersetzen und das war auch nie > geplant. Doch, genau dafür war die Sprache und anfängliche Implementierung explizit vorgesehen und wurde auch genau dafür benutzt. > Bei Rust sieht das komplett anders aus, damit könntest du auch einen > Betriebssystemkernel programmieren. Das geht mit Sprachen, die wie Oak oder Java zunächst eine Übersetzung in Bytecode vorsehen, ebenfalls, das Verfahren ist lediglich anders als man es üblicherweise mit C/C++ tut. Ein einschlägiges Verfahren besteht darin, den Bytecodeiinterpreter bzw Compiler in der jeweiligen Sprache selber zu implementieren. Ich habe so etwas auch schon mal gemacht, laange bevor Java - oder Oak - überhaupt existierte. Im übrigen ist es ein gängiger Irrtum, Systemprogrammierung auf die Programmierung von Betriebssystemkernen zu reduzieren. > Damit ist Rust eine theoretisch ernstzunehmende Alternative zu C und > C++. Klar. Aber nicht die einzige auch praktisch ernstzunehmende Alternative und auch nicht aus diesem Grund. > Theoretisch deswegen, weil noch einiges vom Drumherum fehlt und es > auch von der Marktakzeptanz abhängig ist, und wie sich das entwickelt > kann nur die Zeit zeigen. Von der Sprache selbst aber steht dem nichts > im Weg. Und exakt das gilt auch für Oak, Java, C#, Lisp und viele andere mehr. [1] "he Java platform and language began as an internal project at Sun Microsystems in December 1990, providing an alternative to the C++/C programming languages." [2] "Because they were developing an embedded system with limited resources, they decided that C++ needed too much memory and that its complexity led to developer errors" [3] "In 1994, Sun renamed the Oak language to Java after a trademark search revealed that Oak Technology used the name Oak"
Ich schrieb "und kann das auf normaler Hardware auch gar nicht". Sun wollte für Java Chips bauen, die Java Bytecode verstehen, das ist mir sehr wohl bekannt, deswegen sagte ich "normale Hardware", solche Chips sind aber etwas ganz anderes, als das, was wir unter ARM und x86 verstehen. Und zum Thema: "[1] "he Java platform and language began as an internal project at Sun Microsystems in December 1990, providing an alternative to the C++/C programming languages." Das sagt gar nichts aus, denn C++ und C wurde selbstverständlich damals auch für die Anwendungsentwicklung eingesetzt. Entscheident ist also der Kontext. Es bleibt aber das Problem mit den genannten Schwächen, siehe oben, warum Java für die Systemprogramierung nicht geeignet ist. Und selbst wenn etwas irgendwie geht, z.b. weil du ne Laufzeitumgebung in den Kernel einbaust und dann prebootest, dann bedeutet das nicht, dass sich etwas dafür auch eignet. > Im übrigen ist es ein gängiger Irrtum, Systemprogrammierung auf die > Programmierung von Betriebssystemkernen zu reduzieren. Das habe ich nicht getan, der Kernel ist ein Beispiel der dafür zu Veranschaulichung steht.
> Wenn du mir nicht widersprichst, was willst du mir dann sagen? Vielleicht verstehe ich ja was falsch - für mich ist das Problem des TO ein Problem der Anwendungsprogrammierung. Systemprogrammierung sind für mich eher Treiber für Schnittstellen, etc. - was hat das jetzt mit der Frage des TO zu tun? > Das hängt auch von den Compileroptionen ab. > Oder waren es "nur" Warnungen? GNU C Compiler unter Linux, jede Menge Warnungen; bei Ausführung der Objektdatei gibt's dann einen 'core dumped'. Es wird u.a. eine Deklaration von strcpy verlangt oder Einbindung der Headerdatei string.h Letztendlich ist das Problem des TO gelöst.
> Ich schrieb "und kann das auf normaler Hardware auch gar nicht". > Sun wollte für Java Chips bauen, die Java Bytecode verstehen, das ist > mir sehr wohl bekannt, deswegen sagte ich "normale Hardware", solche > Chips sind aber etwas ganz anderes, als das, was wir unter ARM und x86 > verstehen. Bei C, C++, usw. ist alles mehr oder weniger abhängig vom Betriebsystem. Bei Macintosh, Linux, usw. würde das C oder C++ Windows-Programm unter Umständen nicht mehr laufen (mein Compiler unter Linux quittiert ja schon das obige simple Windows-Programm mit Warnungen - wenn es komplexer wäre, dann sähe es düster aus). Das Theater gibt es bei Java nicht, da reicht eine Laufzeitumgebung und es läuft dann auf jedem Betriebsystem ohne Änderung.
S. B. schrieb: >> Wenn du mir nicht widersprichst, was willst du mir dann sagen? > Vielleicht verstehe ich ja was falsch - für mich ist das Problem des TO > ein Problem der Anwendungsprogrammierung. > Systemprogrammierung sind für mich eher Treiber für Schnittstellen, etc. > - was hat das jetzt mit der Frage des TO zu tun? Ja, das wird wohl der Grund sein. Wir führen hier ein Nebenthema um die Programmiersprachen allgemein, das sich daraus entwickelt hat. Zitter_ned_aso Posting, welches lautete: > Darum kam doch Java raus oder? Damit man sich das Bein mit C++ nicht > wegschießt. als Antwort auf meine Erwähnung von Rust, mag zwar für die Anwendungsprogrammierung stimmen, suggeriert aber auch bzw. kann man es so interpretieren, dass Java rauskam um C++ vollständig zu ersetzen oder dies tun könnte. Und das geht halt bei der Systemprogrammierung nicht mehr, mit Rust allerdings schon. Deswegen habe ich erwähnt, das Java C++ nicht ersetzen kann mit Hinweis auf die Systemprogrammierung. S. B. schrieb: >> Ich schrieb "und kann das auf normaler Hardware auch gar nicht". >> Sun wollte für Java Chips bauen, die Java Bytecode verstehen, das ist >> mir sehr wohl bekannt, deswegen sagte ich "normale Hardware", solche >> Chips sind aber etwas ganz anderes, als das, was wir unter ARM und x86 >> verstehen. > Bei C, C++, usw. ist alles mehr oder weniger abhängig vom Betriebsystem. > Bei Macintosh, Linux, usw. würde das C oder C++ Windows-Programm unter > Umständen nicht mehr laufen (mein Compiler unter Linux quittiert ja > schon das obige simple Windows-Programm mit Warnungen - wenn es > komplexer wäre, dann sähe es düster aus). > Das Theater gibt es bei Java nicht, da reicht eine Laufzeitumgebung und > es läuft dann auf jedem Betriebsystem ohne Änderung. Ja, wenn du für ein spezifisches Betriebssystem in C oder C++ Programme schreiben willst und du die Systemlibs nicht selbst implementieren willst, dann ist das für gewöhnlich so, aber mit C oder C++ kannst du auch ein Betriebssystem, Teile davon oder die Treiber dafür oder eine Firmware für die Hardware schreiben. Java kann ohne Laufzeitumgebung oder spezieller Java CPU die Java Bytecode direkt versteht nichts mehr. Die Sprachen sind somit einfach grundverschieden um sagen zu können, dass Java entwickelt wurde um C++ vollständig zu verdrängen oder es wenigstens zu können. Rust könnte C++ dagegen sehr wohl vollständig verdrängen wenn man wollte, die Sprache gibt das von den Features her her.
> Die Sprachen sind somit einfach grundverschieden um sagen zu können, > dass Java entwickelt wurde um C++ vollständig zu verdrängen oder es > wenigstens zu können. Mit dem Aufkommen der Android Smartphones hat sich die Frage des Fortbestandes von Java bzw. dem Nutzen gegenüber C++ geklärt :-) > Rust könnte C++ dagegen sehr wohl vollständig verdrängen wenn man > wollte, die Sprache gibt das von den Features her her. Rust kenne ich noch nicht - ich Laufe der IT Geschichte ist so manche hochgepriesene Sprache schnell wieder in der Versenkung verschwunden (z.B. Ruby on rails wollte ich mal starten, habe es dann aber sein gelassen); alles sehr unbeständig bzw. Nischenmarkt.
S. B. schrieb: > Auch in Puncto Sicherheit gibt es bessere Alternativen, nämlich ADA, das > im u.a. im Militärbereich verwandt wird. Die Sicherheitsdenke ist vermutlich die gleiche wie beim Autofahren. Allradantrieb, Antiblockersysteme, Sicherheitsgurt uvm. Technisch sicherer, aber das wird oft so genutzt (rücksichtsloser fahren), dass am Ende fast das selbe herauskommt. Bei Haskell heißt es öfter: keine Tests. Wenn sich das einbürgert, würden die guten Eigenschaften dieser Programmiersprache missbraucht werden, vor allem, um Kosten zu sparen o.a. Gründen. Haskell zeigt noch etwas anderes: alles was irgendwie nicht C-verwandt ist, erscheint unkoscher. Der Hintergrund ist aber eher, weil C so einfach bzw. besser: pragmatisch gestrickt ist. Oder Wörter-Psycho: Java: Kaffee, Kuchen, Insel.. Haskell: Lambda Kalkül, List Komprehensions, Monaden.. (Hilfe..) C: In den Fuß schießen -> hat mit dem Zeigen zu tun bzw. auf den Fuß zeigen - und für den ein oder anderen (vermutl.) mit schneller ziehen? Früher in Zeitschriften: Vitamin C Basic: passt ganz gut, aber der Begriff verschleiert etwas zu unrecht den großen Bruder.. C++ ..ganz offenbar eine Weiterentwicklung, die sich (versehentlich) ständig wiederholt
S. B. schrieb: >> Die Sprachen sind somit einfach grundverschieden um sagen zu können, >> dass Java entwickelt wurde um C++ vollständig zu verdrängen oder es >> wenigstens zu können. > Mit dem Aufkommen der Android Smartphones hat sich die Frage des > Fortbestandes von Java bzw. dem Nutzen gegenüber C++ geklärt :-) Android hat einen Kernel der in C geschrieben wurde. Die meisten dürften den kennen. ;) >> Rust könnte C++ dagegen sehr wohl vollständig verdrängen wenn man >> wollte, die Sprache gibt das von den Features her her. > Rust kenne ich noch nicht - ich Laufe der IT Geschichte ist so manche > hochgepriesene Sprache schnell wieder in der Versenkung verschwunden > (z.B. Ruby on rails wollte ich mal starten, habe es dann aber sein > gelassen); > alles sehr unbeständig bzw. Nischenmarkt. Ja, diese Risiken gibt es bei neuen Sprachen leider immer.
S. B. schrieb: >> ImZweifel ist aber C++ dann doch die bessere Wahl. Sicherheit, und >> Geschwindigkeit. > totaler Blödsinn; C++ ist eine Obermenge von C und deshalb gleich > schnell oder eben langsamer - das merkt man aber erst auf alten Rechnern > und bei größeren Programmen. Bullshit, in jedem größeren Programm kann der Compiler mit modernem C++ wesentlich besser optimieren, und das bei mehr Comfort und weniger Fehleranfälligkeit, stichwort zero cost abstraction. Und ja, ich schreibe beruflich Hauptsächlich in C. S. B. schrieb: > C++ hat sich wegen u.a. wegen bunter Windows-Fenster, der besseren IDE, > etc. durchgesetzt; insbesondere Fenstertechnik und graphische > Oberflächen funktionierte mit C zur damaligen Zeit praktisch nicht. Natürlich. Deswegen verwendet man es ja auch im Serverbereich. Nicht etwa, weil es Dinge wie Objektorientierung, verünftige Typisierung, generische Programmierung und Co. bietet. Und welche "bessere IDE" soll das sein? Bist du ein Satireprojekt? Wolfgang S. schrieb: > "Because they were developing an embedded system with limited > resources, they decided that C++ needed too much memory and that its > complexity led to developer errors" C++ braucht zuviele Resourcen und deswegen brauchen wir Java? Selten so gelacht. S. B. schrieb: > Es wird u.a. eine Deklaration von strcpy verlangt oder Einbindung der > Headerdatei string.h Tja, hättest wohl string.h einbinden sollen. Nano schrieb: > Deswegen habe ich erwähnt, das Java C++ nicht ersetzen kann mit Hinweis > auf die Systemprogrammierung. Und weil die Performance einfach grottig ist. S. B. schrieb: > Mit dem Aufkommen der Android Smartphones hat sich die Frage des > Fortbestandes von Java bzw. dem Nutzen gegenüber C++ geklärt :-) Fortbestand? Ja. Nutzen? Nö. rbx schrieb: > Die Sicherheitsdenke ist vermutlich die gleiche wie beim Autofahren. > Allradantrieb, Antiblockersysteme, Sicherheitsgurt uvm. Technisch > sicherer, aber das wird oft so genutzt (rücksichtsloser fahren), dass am > Ende fast das selbe herauskommt. > > Bei Haskell heißt es öfter: keine Tests. Wer ADA einsetzen (muss) weil Military, Aerospace oder sonstwas, wird sich Tests nicht sparen können...
vn n. schrieb: > Wer ADA einsetzen (muss) weil Military, Aerospace oder sonstwas, wird > sich Tests nicht sparen können... Man beachte die rein begriffliche Verwandtschaft zwischen ADA und Haskell. Von Charles Babbage habe ich mal gelesen, dass er deswegen auf Computer kam, weil er viele Rechenfehler in einer Nachschlagetabelle erkannt hatte und so auf die Idee einer Automation kam. Man sieht aber heute, bei guter Automation am Beispiel der Rechtschreibkontrolle, dass sie ihre Grenzen hat (z.B. Erkennungsschwächen) wie auch dass sie missbraucht wird (Qualitätsnachlass bei Tageszeitungen, Mitarbeitereinsparungen z.B.)
Christoph O. schrieb: > Zumindest für den eingangs beschriebenen Fall > kann die Länge des Strings auch vom Compiler bestimmt werden: > char txtstr[] = "100°C\n\0"; > Meine ich zumindest, hab es grad nicht getestet. Ich habe nochmal die Variante von Christoph ausprobiert... und die ist sehr schön da kurz: --------------------- #include <stdio.h> // #include <string.h> char txtstr[] = "100\xF8""C\n"; int main() { printf (txtstr); return(0); } --------------------- strcpy habe ich rausgeschmissen da unnütz an der Stelle Danke nochmal für die Tipps... hab heute viel dazugelernt.
Nano schrieb: > Ich schrieb "und kann das auf normaler Hardware auch gar nicht". > Sun wollte für Java Chips bauen, die Java Bytecode verstehen, das ist > mir sehr wohl bekannt, deswegen sagte ich "normale Hardware", solche > Chips sind aber etwas ganz anderes, als das, was wir unter ARM und x86 > verstehen. In Irrtum wird nicht besser, wenn man ihn mehrfach wiederholt. Man benötigt weder C noch eine andere Sprache, um Sprachen des Typs von Oak, Java usw. auf "normaler Hardware", also den derzeit gebräuchlichen CISC/RISC-Prozessoren verwenden zu können, lediglich für den initialen Bootstrap wird es bequemer, wenn man für die Unterstützung einer neuen ISA einen Compiler in einer beliebigen genügend brauchbaren Programmiersprache zur Verfügung hat. Sobald der damit implementierte Codegenerator/Interpreter seinen Zweck erfüllt hat, kann man ihn wegwerfen. https://en.wikipedia.org/wiki/Tombstone_diagram Vorsorglich, dies ist nicht die Behauptung, diese seit der frühen Steinzeit bekannte einschlägige Methode sei der einzige oder der beste Weg. Wichtig ist mir aber der Hinweis, daß dies kein bloß theoretisches Verfahren ist und daß es jedenfalls für eine Widerlegung der obigen pauschalen Behauptung reicht. Ich nehme an, daß dies dem OP genau so wenig hilft wie die Hinweise auf Rust. Jedoch habe ich etwas dagegen, wenn man Anfängern in dieser Weise einen Bären aufbindet. Daß viele der besagten Sprachen samt ihrer Laufzeitumgebung einen Anfänger, der bereits an dem eingangs skizzierten Problem scheitert, vor den vielen Ideosynkrasien der Architektur der darunterliegenden "normalen Hardware" abschirmt, wird genau so wenig bestritten wie der Sachverhalt, daß beim praktischen Einsatz von C hilfreich ist, ein gewisses Verständnis derselben zu haben. Bevor man hier aber mit Ratschlägen um sich wirft, sollte man erst mal herauszubringen versuchen, welchen Zweck der OP mit dem Einsatz bzw. Erlernen von C verfolgt. Vielleicht wäre ein schlichtes "Ja" auf "Aber vielleicht ist C dafür die falsche Programmiersprache" die richtige Antwort gewesen. Eine Sammlung von Rezepten resp. die Suche nach "allgemeingültigen Lösungen" als Ersatz eines ausreichenden Sprachverständnisses - mit dem man sich solche Fragen dann weitgehend selber beantworten kann oder wenigstens weiss, wo man die Antworten findet -, das ist der falsche Weg. > > Und zum Thema: > "[1] "he Java platform and language began as an internal project at Sun > Microsystems in December 1990, providing an alternative to the C++/C > programming languages." > > Das sagt gar nichts aus, denn C++ und C wurde selbstverständlich damals > auch für die Anwendungsentwicklung eingesetzt. Das für sich genommen besagt, daß Oak/Java ursprünglich als Alternative zu C++ gedacht war. Im Zusammenhang mit dem Projekt, für das die Sprache spezifiziert wurde, läßt sich auch erkennen, daß der intendierte Zweck die Systemprogrammierung von embedded systems, im Speziellen einer konkreten Set-top-Box war. Oak mag nach der Eiche vor Goslings Zimmer benannt sein, expandiert wurde dies als Object Application Kernel. Ein Folgeprojekt war "LiveOak" mit der expliziten Intention, mit Oak ein unspezialisiertes kleines OS zu realisieren. > Entscheident ist also der Kontext. Eben. Wenn man den nicht kennt, neigt man zu Fehlschlüssen. > > Es bleibt aber das Problem mit den genannten Schwächen, siehe oben, > warum Java für die Systemprogramierung nicht geeignet ist. Auch diese Behauptung könnte man hinterfragen, ich bezweifle aber, daß das dem OP sonderlich weiterhilft. > > Und selbst wenn etwas irgendwie geht, z.b. weil du ne Laufzeitumgebung > in den Kernel einbaust und dann prebootest, dann bedeutet das nicht, > dass sich etwas dafür auch eignet. Ex falso quodlibet. > >> Im übrigen ist es ein gängiger Irrtum, Systemprogrammierung auf die >> Programmierung von Betriebssystemkernen zu reduzieren. > > Das habe ich nicht getan, der Kernel ist ein Beispiel der dafür zu > Veranschaulichung steht. Auch in Oak ließe sich ein Kernel programmieren. Dies wurde seinerzeit ja sogar begonnen. Als Veranschaulichung der Eigenschaften und Vorzüge von Rust taugt das auch deswegen nicht.
So wie du printf gerade verwendest, geht das irgenwann schief. Nämlich dann, wenn in dem String ein % enthalten ist.
1 | printf("%s", txtstr); |
oder
1 | fputs(txtstr, stdout); |
oder wenn am Ende kein \n ist (das hängt puts automatisch an)
1 | puts(txtstr); |
vn n. schrieb: > Wolfgang S. schrieb: >> "Because they were developing an embedded system with limited >> resources, they decided that C++ needed too much memory and that its >> complexity led to developer errors" > > C++ braucht zuviele Resourcen und deswegen brauchen wir Java? Selten so > gelacht. Quark. Dies ist ein paraphrasiertes Zitat vom Anfang der 90er, betreffend den direkten Vorläufer von Java, Oak. Oak und damit Java hatte seine ersten Ursprünge übrigens bereits in den 70ern und war von Bill Joy damals spezifisch für die Programmierung eines kleinen OS entworfen worden, basierend auf den Erfahrungen mit Mesa und C. C++, das damals ein ziemlich grobschlächtig implementierter Versuch war, das Konzept von Simula 67 (eine Erweiterung von Algol 60, gedacht für discrete event simulation, die erste objektorientierte Sprache überhaupt) auf C zu übertragen, erwies sich dafür zu der Zeit als zu plump und unbrauchbar. Daß der Ansatz, sich auf Basis einer wackeligeren Unterlage (C statt Algol) viel mehr vorzunehmen ("zero abstraction"), nicht so einfach werden würde, wie Stroustrup sich das vorstellte, hat damals kaum jemanden überrascht, der sich mit dem Entwurf und der Implementierung von Programmiersprachen beschäftigte. Daß man durch jahrzehntelanges Nachbessern von Sprache, Library und Compiler und Benutzungseinschränkungen jede Sprache für die meisten Anwendungsfälle brauchbar machen kann, irgendwie, ist unbestritten. Eleganter wird eine Sprache dadurch nur selten. Und wie schlank oder bloated C++ oder Java heute sind, spielt weder für die Betrachtung, wo Java herkommt, eine Rolle noch für die Frage, welche Spracheigenschaften für die OS-Entwicklung erforderlich und förderlich sind. Im übrigen diente das obige Zitat lediglich dazu, eine Behauptung zu widerlegen
Angehängte Dateien:
-
Run__1.JPG
13 KB -
Run__2.JPG
13 KB
Dirk B. schrieb: > So wie du printf gerade verwendest, geht das irgenwann schief. Nämlich > dann, wenn in dem String ein % enthalten ist. > printf("%s", txtstr);oderfputs(txtstr, stdout);oder wenn am Ende kein \n > ist (das hängt puts automatisch an)puts(txtstr); Hallo Dirk, das habe ich natürlich gleich ausprobiert und dabei bis auf die Tatsache das bei der ersten Version noch eine Leerzeile folgt keinen Unterschied oder Problem feststellen können. Kannst Du Deinen Hinweis bitte präzisieren? Anbei der Quellcode von obigem Bild mit dem Titel Run #1 ---- #include <stdio.h> // #include <string.h> char txtstr[] = "100%\n"; int main() { printf ("%s", txtstr); return(0); } ---- und hier der Quellcode von obigem Bild mit dem Titel Run #2 ---- #include <stdio.h> // #include <string.h> char txtstr[] = "100%"; int main() { printf ("%s", txtstr); return(0); } ----
Torsten K. schrieb: > char txtstr[] = "100%\n"; char str[]="ddd%ddd"; printf(str); das hat er damit gemeint.
"ddd%ddd" ist wahrscheinlich kein gutes Beispiel ;-) So ist es besser:
1 | char str[]="Preisnachlas von 5% auf alle IT-Buecher"; |
2 | printf(str); |
%f wird als Platzhalter für eine Fließkommazahl betrachtet. Und die Ausgabe ist falsch.
1 | char str[]="Preisnachlas von 5%% fuer alle IT-Buecher"; |
wäre richtig. https://de.wikibooks.org/wiki/C-Programmierung:_Einfache_Ein-_und_Ausgabe
Angehängte Dateien:
-
Run__3.JPG
14 KB -
Run__4.JPG
14 KB
zitter_ned_aso schrieb: > char str[]="ddd%ddd"; > > printf(str); > > das hat er damit gemeint. Ja habe ich eben ausprobiert und Du hast Recht... siehe zweites Bild
KORREKTUR: "ddd%ddd" ist wahrscheinlich kein gutes Beispiel ;-) So ist es besser: char str[]="Preisnachlas von 5% fuer "; printf(str); %f wird als Platzhalter für eine Fließkommazahl betrachtet. Und die Ausgabe ist falsch. char str[]="Preisnachlass von 5%% fuer alle IT-Buecher"; wäre richtig. https://de.wikibooks.org/wiki/C-Programmierung:_Einfache_Ein-_und_Ausgabe
Angehängte Dateien:
-
Run__5.JPG
13 KB
Ja... auch hier richtig. Aber ich denke, das kommt auch immer darauf an
WAS man gerade ausgeben will.
----
#include <stdio.h>
// #include <string.h>
char txtstr[] = "Preisnachlaß von 5% fuer ";
int main()
{
printf (txtstr);
return(0);
}
----
Für mein obiges Beispiel passt es zumindest und das war was ich wollte.
Deinen Hinweis greife ich trotzdem auf und werde ihn verfolgen. Danke
Torsten K. schrieb: > und Du hast Recht Dirk war das. Ich kam nur mit einem Beispiel. Fuer bestimmte Sonderzeichen gibt es unter C spezielle "Kodierungen", wenn man sie in einem String darstellen will. %% fuer % \" fuer " usw..
Das mit dem %% gilt aber nur für den Formatstring von printf. Denn das % leitet einen Formatspecifier ein. Einfache Strings können einfacher mit puts ausgegeben werden.
> Bullshit, in jedem größeren Programm kann der Compiler mit modernem C++ > wesentlich besser optimieren, und das bei mehr Comfort und weniger > Fehleranfälligkeit, stichwort zero cost abstraction. Mag schon sein, daß der C++ Compiler besser ist, weil der C Compiler nicht mehr weiterentwickelt wird gibt's natürlich zeitliche Einbußen. Deswegen ist das Endergebnis aber nicht unbedingt besser - das ist der Irrtum, insbesondere der BWL-Personaler. > Und ja, ich schreibe beruflich Hauptsächlich in C. LOL, und dann kritisierst Du an C rum ??? Wir haben doch einen 'blühenden?' Arbeitsmarkt, such Dir doch einen neuen Job, wo es nur um dieses f**k C++ geht - gibt doch genug Arbeitgeber, die genau das und nichts anderes mehr suchen! Bei soviel Mangel überall sollte das doch wirklich kein Problem sein? Du bist also beruflich inkonsequent, zumal Du ja genug BE hast :-) > Natürlich. Deswegen verwendet man es ja auch im Serverbereich. Nicht > etwa, weil es Dinge wie Objektorientierung, verünftige Typisierung, > generische Programmierung und Co. bietet. Und welche "bessere IDE" soll > das sein? > Bist du ein Satireprojekt? bei C++ ist das logischerweise die Visual C++ Schiene und die dürfte besser sein als irgendeine GNU C Variante oder was immer Du unter C nutzt. C++ ist nach C gekommen und damit ist die Weiterentwicklung von C zugunsten von C++ mehr oder weniger zum Erliegen gekommen. Was erwartest Du? Wenn es nicht den Mikrocontroller-Bereich gäbe, wäre es vorbei mit C! Ich bezweifle ja nicht, daß C++ seine Vorteile hat - aber die Systemschiene ist mehr oder weniger gelaufen, wenn Du nicht gerade in der Wartung als Sysadmin tätig bist. Ansonsten ist Anwendungsprogrammierung gefragt und da schlägt sich Java besser. > C++ braucht zuviele Resourcen und deswegen brauchen wir Java? Selten so > gelacht. im Vergleich zu C aber schon und das verschweigt der C++ Fan. > Tja, hättest wohl string.h einbinden sollen. siehe Programm, habe ich ja gemacht. Aber es ist ein Beispiel, welche kleinen Programmiertücken ein anderes Betriebsystem, etc. mit sich bringt. Das wäre in Java nicht notwendig gewesen wegen JRE - und zum 100. Mal, es geht hier nicht um Systemprogrammierung! Das ist nur eine schöne Nische für wenige. > Fortbestand? Ja. Nutzen? Nö. Du kannst Anwendungsapps für Android programmieren - und damit wird u.a. wenigstens noch Kleingeld gemacht. Von Deiner Systemprogrammierung, wo nur einige wenige Experten vom Kuchen profitieren, kann die Masse jedenfalls nicht leben, oder? > Wer ADA einsetzen (muss) weil Military, Aerospace oder sonstwas, wird > sich Tests nicht sparen können... braucht das jeweilige Unternehmen ja auch nicht, weil die Endverkaufspreise entsprechend sind und diese Preise auch ohne zu zucken gezahlt werden. Der jeweilige Staat schwimmt ja im Geld, wenn es um Militär geht. Sparen in diesem Bereich ist eine absolute Fehlanzeige, es lebe der Snob-Effekt.
S. B. schrieb: > Mag schon sein, daß der C++ Compiler besser ist, weil der C Compiler > nicht mehr weiterentwickelt wird gibt's natürlich zeitliche Einbußen. > Deswegen ist das Endergebnis aber nicht unbedingt besser - das ist der > Irrtum, insbesondere der BWL-Personaler. Du hast eine blühende Fantasie. Wäre neu, dass der GCC nicht mehr weiterentwickelt wird... S. B. schrieb: > LOL, und dann kritisierst Du an C rum ??? > Wir haben doch einen 'blühenden?' Arbeitsmarkt, such Dir doch einen > neuen Job, wo es nur um dieses f**k C++ geht - gibt doch genug > Arbeitgeber, die genau das und nichts anderes mehr suchen! > Bei soviel Mangel überall sollte das doch wirklich kein Problem sein? > Du bist also beruflich inkonsequent, zumal Du ja genug BE hast :-) Ja, wie kann man nur so realistisch sein, und sein tagtäglich verwendetes Werkzeug kritisieren! Keine Angst, die Sprache kann ich in meinem Job schon selbst aussuchen, ich bin ja kein armer Programmiersklave der sich sowas vorschreiben lassen muss. Aber nicht für jeden Prozessor gibt es einen (guten) C++-Compiler, und dann ist da noch die Sache mit Legacycode... S. B. schrieb: > bei C++ ist das logischerweise die Visual C++ Schiene und die dürfte > besser sein als irgendeine GNU C Variante oder was immer Du unter C > nutzt. Ohoho, C++ ist also Visual C++. Verwendet das überhaupt noch irgendwer, wo doch GCC oder CLANG viel besser sind? S. B. schrieb: > C++ ist nach C gekommen und damit ist die Weiterentwicklung von C > zugunsten von C++ mehr oder weniger zum Erliegen gekommen. > Was erwartest Du? Achso, C wird also nicht mehr weiterentwickelt. C11 sagt dir was? Aus welchem Jahr stammt C11 nochmal? Tipp: es steckt im Namen. S. B. schrieb: > Ich bezweifle ja nicht, daß C++ seine Vorteile hat - aber die > Systemschiene ist mehr oder weniger gelaufen, wenn Du nicht gerade in > der Wartung als Sysadmin tätig bist. > Ansonsten ist Anwendungsprogrammierung gefragt und da schlägt sich Java > besser. Dieser Absatz ließt sich leicht wirr, kannst du ihn näher erläutern? Was ist die "Systemschiene", warum ist die gelaufen, und welche konkreten Vorzüge soll Java haben? S. B. schrieb: > im Vergleich zu C aber schon und das verschweigt der C++ Fan. Du kannst sicher erläutern, wo dieses mehr an Ressourcen deiner Meinung nach herkommen soll. Oder sind es doch nur leere Worte? S. B. schrieb: > siehe Programm, habe ich ja gemacht. Aber es ist ein Beispiel, welche > kleinen Programmiertücken ein anderes Betriebsystem, etc. mit sich > bringt. Was genau soll das mit dem Betriebssystem zu tun haben? Die Standardbibliotheken sind Teil des Standards, aber das hilft natürlich nicht, wenn man den Compiler nicht bedienen kann... leider schaffst du es ja auch nicht zu beschreiben, was genau du gemacht hast, um dieses Sonderbare Ergebnis zu bekommen... Welcher Code genau (Zeichen für Zeichen), welcher Compiler, welche Einstellungen? Es ist in den seltensten Fällen der Compiler Schuld, das Problem sitzt meist vor dem Bildschirm. S. B. schrieb: > Das wäre in Java nicht notwendig gewesen wegen JRE - und zum 100. Mal, > es geht hier nicht um Systemprogrammierung! Das ist nur eine schöne > Nische für wenige. In welcher Realität braucht man eine fette JRE für ein bisschen Stringspielerei, und was hast du immer mit deiner Systemprogrammiererei? Allein welche Sicherheitsprobleme die JRE ständig hat, sagt schon alles... S. B. schrieb: > Du kannst Anwendungsapps für Android programmieren - und damit wird u.a. > wenigstens noch Kleingeld gemacht. Oho, Appprogrammierung, ist das das was man macht, wenn man sonst nirgends unterkommt? Aber ich kann dich trösten, man kann auch Android-Apps ohne Java schreiben! S. B. schrieb: > Von Deiner Systemprogrammierung, wo nur einige wenige Experten vom > Kuchen profitieren, kann die Masse jedenfalls nicht leben, oder? Deine Fantasie wird immer blühender. Mit "Systemprogrammierung" meinst du den ganzen Betriebssystemsektor? Einen Großteil der Desktopanwendungen (nein, MS Office oder ein 3D-CAD-System wie CATIA ist nicht in Java geschrieben)? Nicht mal ein bedeutender Webbrowser ist in Java geschrieben, im Gegenteil, man hat nach massiver Sicherheitsprobleme Java aus den Browsern verbannt... S. B. schrieb: > braucht das jeweilige Unternehmen ja auch nicht, weil die > Endverkaufspreise entsprechend sind und diese Preise auch ohne zu zucken > gezahlt werden. > Der jeweilige Staat schwimmt ja im Geld, wenn es um Militär geht. > Sparen in diesem Bereich ist eine absolute Fehlanzeige, es lebe der > Snob-Effekt. Tja, wenn man sich nicht als Java-App-Frickler prostituieren muss, liegt das Geld halt auf der Straße, man muss es nur aufheben. Wenn man aber ständig mit Billiglohn-Codemonkeys konkurrieren muss... Mich würde ja echt interessieren, woher du deine ganzen Fantastereien hernimmst... C wird nicht weiterentwickelt, C++ ist Visual C++, Anwendungen werden nur in Java geschrieben...
> Ja, wie kann man nur so realistisch sein, und sein tagtäglich > verwendetes Werkzeug kritisieren! Allerdings - wenn Dir C++ so gut gefällt und Du Dich im Job aber mit C abgeben mußt, dann verstehe ich das nicht ganz? > Keine Angst, die Sprache kann ich in meinem Job schon selbst aussuchen, > ich bin ja kein armer Programmiersklave der sich sowas vorschreiben > lassen muss. Aber nicht für jeden Prozessor gibt es einen (guten) > C++-Compiler, und dann ist da noch die Sache mit Legacycode... Aha, jetzt auf einmal doch C++: Deine Aussage oben lautete aber: "Und ja, ich schreibe beruflich Hauptsächlich in C." DAS war Deine Aussage. Ja was denn jetzt? Kann man Dich noch Ernst nehmen? > Ohoho, C++ ist also Visual C++. Verwendet das überhaupt noch irgendwer, > wo doch GCC oder CLANG viel besser sind? wenn es keine Frickelbude ist, wo Du arbeitest gibt es eben auch Vorgaben von der Chefetage - vielleicht bist Du ja auch Freiberufler? > Achso, C wird also nicht mehr weiterentwickelt. C11 sagt dir was? Aus > welchem Jahr stammt C11 nochmal? Tipp: es steckt im Namen. Kennst Du Basic? Da wird ebenfalls ein Revival mit allerlei Neuauflagen probiert, die so schlecht nicht sind - Fakt ist, daß das ein absoluter Nischenmarkt ist und deswegen ist ja heute C++ oder C# angesagt - C11, usw. interessiert dank C++, C# kein Schwein mehr. > Was genau soll das mit dem Betriebssystem zu tun haben? Die > Standardbibliotheken sind Teil des Standards, aber das hilft natürlich > nicht, wenn man den Compiler nicht bedienen kann... Was müßte ich denn bei meinen GNU C Compiler unter Linux einstellen, damit das auch ohne die Headerdatei string.h wie beim TO funktioniert? > Du kannst sicher erläutern, wo dieses mehr an Ressourcen deiner Meinung > nach herkommen soll. > Oder sind es doch nur leere Worte? mehr Quellcode und Du siehst es auch bei der Laufzeit auf älteren Rechnern und insbesondere bei größeren Programmen - KDE als Desktop verwende ich deshalb nicht. Deshalb werden Mikrocontroller ja auch primär in C statt in C++ programmiert, weil sich dort der mangelnde Speicherplatz noch bemerkbar macht und last but not least c++ ist eine 'Obermenge' von c .... Du kannst maximal die gleiche Laufzeit erreichen, aber nicht besser. > Es ist in den seltensten Fällen der Compiler Schuld, das Problem sitzt > meist vor dem Bildschirm. Bei dem TO funktioniert obiges Programm unter CodeBlocks Windows ohne string.h und bei mir nicht. Zeig mir doch bitte mal konkret was Du kannst! Was müßte ich denn da an meinen GNU C Compiler unter Linux noch einstellen, damit es so wie bei CodeBlocks ohne string.h funzt? Na? Ist doch alles so easy? Wie geht das in den Compiler-Einstellungen; ich weiß es nämlich nicht, aber Du sicherlich?! Ich wette, dieser Part wird umgangen und es gibt keine Antwort auf meine Frage? Wie immer. > Oho, Appprogrammierung, ist das das was man macht, wenn man sonst > nirgends unterkommt? Genau, so einen großkotzigen Top-Job bekommt nämlich nicht jeder, weil die Nachfrage gering ist. Sei froh, wenn Du das Glückslos gezogen hast - offenbar bist Du Dir dessen gar nicht bewußt! > Aber ich kann dich trösten, man kann auch Android-Apps ohne Java > schreiben! kann man, aber warum sollte man vom Mainstream abweichen, wenn sich Java diesbezüglich durchgesetzt hat? Du kannst von mir aus auch in "Halligalli" programmieren und das Ergebnis kann sehr gut oder sogar besser sein - nur ob das Dein Chefe so will ist eine andere Frage - der macht nämlich Vorgaben. Wie gesagt, vielleicht bist Du ja Freiberufler, da kannst Du Dein eigenes Ding fahren, aber sonst eben nicht. > Einen Großteil der Desktopanwendungen (nein, MS Office oder ein 3D-CAD- > System wie CATIA ist nicht in Java geschrieben)? Nicht mal ein > bedeutender Webbrowser ist in Java geschrieben, im Gegenteil, man hat > nach massiver > Sicherheitsprobleme Java aus den Browsern verbannt... Du sagst es, Desktop - also Windows Rechner, denn die sind Marktführer .... mit Aufkommen der Smartphones / Tablets hat sich das eben etwas geändert. Natürlich gibt's auch weiterhin C++ und wenn Dir so danach ist, dann bewirb Dich doch bei diesen Firmen (möglichst dann noch ohne Visual C++ als Wunschkonzept); wirst ja dann merken, was 'die' so an Anforderungen haben und ob Dir das dann schmeckt ?! Dann hast Du wenigstens nichts mehr mit C zu tun, was Du ja angeblich hauptberuflich machst ??! Mach doch mal, mußt ja am Ende nicht zusagen. > Allein welche Sicherheitsprobleme die JRE ständig hat, sagt schon > alles... Dafür ist Java eben nicht ausgelegt, da gibt es dann bessere Alternativen. > Tja, wenn man sich nicht als Java-App-Frickler prostituieren muss, liegt > das Geld halt auf der Straße, man muss es nur aufheben. Wenn man aber > ständig mit Billiglohn-Codemonkeys konkurrieren muss... Warum gibst Du Dich dann noch mit C ab, wenn das alles so easy ist ?! Dann hätte ich den Laden doch schon längst verlassen? Du weißt offenbar nicht wie gut es Dir geht und kotzt über vor Arroganz. > Mich würde ja echt interessieren, woher du deine ganzen Fantastereien > hernimmst... C wird nicht weiterentwickelt, C++ ist Visual C++, > Anwendungen werden nur in Java geschrieben... ich hab das so konkret erlebt: "Bei uns nur Visual C++", "nur Ruby on Rails", usw., nur dies&das sonst nichts, interessiert uns nicht was Sie in anderen Sprachen können und außerdem sind Sie zu alt (das wurde natürlich wegen AntiDis nicht gesagt). Also Meister-Prog, bewirb Dich mal und mach Dich mal schlau bezüglich Deines eigenen Marktwertes - vielleicht hast Du dann auch Deine aha Erlebnisse!
S. B. schrieb: > Allerdings - wenn Dir C++ so gut gefällt und Du Dich im Job aber mit C > abgeben mußt, dann verstehe ich das nicht ganz? Du kannst halt nicht lesen. Macht nix. Aber dann schreib doch einfach auch nix. S. B. schrieb: > Aha, jetzt auf einmal doch C++: > Deine Aussage oben lautete aber: > "Und ja, ich schreibe beruflich Hauptsächlich in C." > DAS war Deine Aussage. > Ja was denn jetzt? > Kann man Dich noch Ernst nehmen? Ich hab dir in dem von dir zitierten Absatz erklärt, warum man beruflich manchmal C nutzen muss, auch wenn man C++ bevorzugen würde. Offensichtlich hast du Probleme, diesen einfachen Absatz zu verstehen. Macht nix. Aber dann schreib doch einfach auch nix. S. B. schrieb: > wenn es keine Frickelbude ist, wo Du arbeitest gibt es eben auch > Vorgaben von der Chefetage - vielleicht bist Du ja auch Freiberufler? Chefetage? Nö, die interessiert nur dass Termine eingehalten werden. Wär ja noch schöner, wenn da irgendein fachfremder den Softwareentwicklern reinquatscht. Wobei, das erklärt natürlich, warum so viele Java oder .NET nutzen. Du hast halt keine Ahnung von Softwareentwicklung. Macht nix. Aber dann schreib doch einfach auch nix. S. B. schrieb: > Kennst Du Basic? Da wird ebenfalls ein Revival mit allerlei Neuauflagen > probiert, die so schlecht nicht sind - Fakt ist, daß das ein absoluter > Nischenmarkt ist und deswegen ist ja heute C++ oder C# angesagt - C11, > usw. interessiert dank C++, C# kein Schwein mehr. Du schreibst, C wird nicht mehr verwendet weil es nicht mehr weiterentwickelt wird. Ich antworte, doch, sieh dir C11 an, es wird noch weiterentwickelt. Du faselst daher, dass die Weiterentwicklungen eh keinen interessieren, weil eh keiner mehr C verwendet. Du widersprichst dir. Macht nix. Aber dann schreib doch einfach auch nix. S. B. schrieb: > Was müßte ich denn bei meinen GNU C Compiler unter Linux einstellen, > damit das auch ohne die Headerdatei string.h wie beim TO funktioniert? Das Headerfile bringt der Compiler mit. Du musst gar nix einstellen. Du kannst halt den Compiler nicht bedienen, schaffst es aber auf Nachfrage auch nicht zu posten, was du falsch gemacht hast, damit man dir helfen kann. Macht nix. Aber dann schreib doch einfach auch nix. S. B. schrieb: > mehr Quellcode und Du siehst es auch bei der Laufzeit auf älteren > Rechnern und insbesondere bei größeren Programmen - KDE als Desktop > verwende ich deshalb nicht. > Deshalb werden Mikrocontroller ja auch primär in C statt in C++ > programmiert, weil sich dort der mangelnde Speicherplatz noch bemerkbar > macht und last but not least c++ ist eine 'Obermenge' von c .... Du > kannst maximal die gleiche Laufzeit erreichen, aber nicht besser. Du hast offensichtlich keine Ahnung von Zero Cost Abstraction. Du hast offensichtlich keine Ahnung davon, was wirklich dafür verantwortlich ist, warum eine Desktopumgebung mehr Resourcen braucht als die andere. Du hast offensichtlich keine Ahnung davon, warum in der Praxis µC in C und nicht in C++ programmiert werden, weil du offensichtlich fachfremd bist. Macht nix. Aber dann schreib doch einfach auch nix. Und nein, C++ ist keine Obermenge von C. Du behauptest erst wiederholt, C++ würde aus ominösen Gründen mehr Ressourcen brauchen, schaffst es aber nicht, konkret zu erläutern, warum das so sein soll. Du hast halt keine Ahnung von C, C++ oder Softwareentwicklung. Macht nix. Aber dann schreib doch einfach auch nix. S. B. schrieb: > Bei dem TO funktioniert obiges Programm unter CodeBlocks Windows ohne > string.h und bei mir nicht. > Zeig mir doch bitte mal konkret was Du kannst! > Was müßte ich denn da an meinen GNU C Compiler unter Linux noch > einstellen, damit es so wie bei CodeBlocks ohne string.h funzt? > Na? Ist doch alles so easy? Jeder standardkonforme C-Compiler (und das ist der GCC natürlich) bringt die string.h mit. Das Problem muss also offensichtlich vom Bediener ausgehen. Leider schaffst du es ja auch nicht, genau zu posten was du gemacht hast. Du hast keine Ahnung von C. Macht nix. Aber dann schreib doch einfach auch nix. S. B. schrieb: > Ich wette, dieser Part wird umgangen und es gibt keine Antwort auf meine > Frage? Wie immer. Wie immer? Bitte, wo soll das denn bisher so der Fall sein? Du schaffst es ja auch nach wie vor nicht, dein konkretes Problem verständlich zu posten, schwafelst nur irgendwas von einer angeblich fehlenden string.h... S. B. schrieb: > Genau, so einen großkotzigen Top-Job bekommt nämlich nicht jeder, weil > die Nachfrage gering ist. Sei froh, wenn Du das Glückslos gezogen hast - > offenbar bist Du Dir dessen gar nicht bewußt! Wenn man nicht über den Java-Tellerrand hinausblicken kann, bekommt man halt keinen Topjob. Erklärt jetzt nur nicht, warum das für Java sprechen soll... S. B. schrieb: > Du kannst von mir aus auch in "Halligalli" programmieren und das > Ergebnis kann sehr gut oder sogar besser sein - nur ob das Dein Chefe so > will ist eine andere Frage - der macht nämlich Vorgaben. > Wie gesagt, vielleicht bist Du ja Freiberufler, da kannst Du Dein > eigenes Ding fahren, aber sonst eben nicht. Wenn es deinem Chef egal ist, dass du mit einem anderen Werkzeug bessere Ergebnisse produzieren kannst, würde ich mir schleunigst einen neuen Job suchen! Aber nachdem du ja Java für die Erleuchtung schlechthin hälst... S. B. schrieb: > Du sagst es, Desktop - also Windows Rechner, denn die sind Marktführer > .... mit Aufkommen der Smartphones / Tablets hat sich das eben etwas > geändert. Was hat das mit Windows zu tun? Java ist ja so toll, warum sind leistungsfähige Programme wie CAD-Suiten nicht in Java geschrieben? S. B. schrieb: > Natürlich gibt's auch weiterhin C++ und wenn Dir so danach ist, dann > bewirb Dich doch bei diesen Firmen (möglichst dann noch ohne Visual C++ > als Wunschkonzept); wirst ja dann merken, was 'die' so an Anforderungen > haben und ob Dir das dann schmeckt ?! "weiterhin C++", na da ist ja einer Experte... rat mal, in was CAD-Systeme, dein Webbrowser, dein Betriebssystem, dein Office, dein Mailclient, ein Webserver, etc. pp. geschrieben sind... S. B. schrieb: > Dann hast Du wenigstens nichts mehr mit C zu tun, was Du ja angeblich > hauptberuflich machst ??! Ich mach embedded. Das wüsstest du auch, könntest du sinnerfassend lesen. Ich will da auch nicht weg, keine Ahnung wie du darauf kommst. S. B. schrieb: > Dafür ist Java eben nicht ausgelegt, da gibt es dann bessere > Alternativen. Achso, Java ist nicht dafür ausgelegt, sicher zu sein. Tja, blöd, wofür darf ich es dann verwenden, wenn es nicht mit externen Daten in berührung kommen darf? Für ein Hello World? S. B. schrieb: > Warum gibst Du Dich dann noch mit C ab, wenn das alles so easy ist ?! > Dann hätte ich den Laden doch schon längst verlassen? > Du weißt offenbar nicht wie gut es Dir geht und kotzt über vor Arroganz. Dass du es öfter wiederholst, macht es nicht sinnvoller. Warum sollte ich von meinem Job weg wollen? Dass es für manche Plattformen nur C-Compiler gibt, und dass man sich auch mal mit Legacycode herumschlagen muss, ist halt ein notwendiges übel. Wenn man nur Java programmieren will und nicht mal ein simples C-Programm kompiliert kriegt, konkurriert man halt mit Millionen Indern, das ist Fakt, keine Arroganz. S. B. schrieb: > ich hab das so konkret erlebt: "Bei uns nur Visual C++", "nur Ruby on > Rails", usw., nur dies&das sonst nichts, interessiert uns nicht was Sie > in anderen Sprachen können und außerdem sind Sie zu alt (das wurde > natürlich wegen AntiDis nicht gesagt). Tja, du schreibst trotzdem nur Schwachsinn. Aber wer nur Java kann, hat halt wenig Chancen. Wer dann auch noch keine Ahnung hat, und so Dinge behauptet wie z.B. C++ wäre gleichzusetzen mit Visual C++, oder Software würde eh nur in Java geschrieben, ist halt aus. S. B. schrieb: > Also Meister-Prog, bewirb Dich mal und mach Dich mal schlau bezüglich > Deines eigenen Marktwertes - vielleicht hast Du dann auch Deine aha > Erlebnisse! Keine Angst, ich kenne meinen Marktwert. Gute Embeddedprogrammierer findet man halt nicht an jeder Ecke, während Java-App-Coder frisch von der Uni (wenn überhaupt) angeworben werden können.
Beitrag #5712317 wurde von einem Moderator gelöscht.
> Ich hab dir in dem von dir zitierten Absatz erklärt, warum man beruflich > manchmal C nutzen muss, auch wenn man C++ bevorzugen würde. ach jetzt auf einmal nur 'manchmal'? Vorher hieß es noch 'hauptsächlich'! Macht nix, Dich kann man nicht Ernst nehmen, aber dann schreib doch besser nix :-) > Das Headerfile bringt der Compiler mit. Du musst gar nix einstellen. Aber ich muß es im Programm für den Precompiler explizit angeben mit #include <string.h> und der TO nicht! Erklärung von Dir? Macht nix, geht alles ohne Einstellung; aber dann schreib besser nix, wenn Du es nicht weißt :-) > Du kannst halt den Compiler nicht bedienen, schaffst es aber auf Nachfrage > auch nicht zu posten, was du falsch gemacht hast, damit man dir helfen > kann. Macht nix. Aber dann schreib doch einfach auch nix. Hab ich doch geschrieben: GNU C Compiler unter Linux. Wenn ich ohne #include <string.h> arbeite, gibt es eine fette Warnung vom Compiler und ich weiß nicht was ich beim Compiler 'einstellen' soll. Ausführung mündet dann in einem Core dumped. Bei CodeBlocks unter Windows brauche ich diese Programmzeile nicht; was ist bei diesem Compiler denn anders? Was mußt Du denn noch wissen, damit Du überhaupt eine Lösung bringen kannst? Macht nix, Du weißt es nicht, bringst keine konkrete Lösung, aber dann schreib doch einfach auch nix. > Was hat das mit Windows zu tun? Java ist ja so toll, warum sind > leistungsfähige Programme wie CAD-Suiten nicht in Java geschrieben? weil Windows den Hauptmarktanteil hat und es auf Smartphones, Tablets, etc. CAD-Suiten, etc. totaler Unsinn wären. Ein stationärer Rechner ist nun einmal leistungsfähiger als jedes Smartphone, etc. - schlimm, daß man Dir sowas erklären muß. Java hat auch nicht den Anspruch auf irgendwelche Hyperdüper-Programme. > "weiterhin C++", na da ist ja einer Experte... rat mal, in was > CAD-Systeme, dein Webbrowser, dein Betriebssystem, dein Office, dein > Mailclient, ein Webserver, etc. pp. geschrieben sind... Tja, Linux basiert auf C und versuche C++ zu vermeiden, da ich keinen Vorteil für mich darin erkennen kann - wenn es geht, möglichst C. > Achso, Java ist nicht dafür ausgelegt, sicher zu sein. Tja, blöd, wofür > darf ich es dann verwenden, wenn es nicht mit externen Daten in > berührung kommen darf? Für ein Hello World? Plattformunabhängige Programme - Du siehst es ja am obigen Compiler-Debakel mit string.h ; und das ist ja nur eine Kleinigkeit, wehe, wenn das Programm größer wäre. > Warum sollte ich von meinem Job weg wollen? weil Du lieber in C++ statt in C programmieren möchtest und C schlechter als C++ einstuft, was definitiv nicht der Fall ist vor allen in Bezug auf die Laufzeiten. > Dass es für manche Plattformen nur > C-Compiler gibt, und dass man sich auch mal mit Legacycode herumschlagen > muss, ist halt ein notwendiges übel. mit der Einstellung hast Du Glück, daß Du dort wo Du arbeitest überhaupt noch arbeiten darfst. > Wenn man nur Java programmieren will und nicht mal ein simples > C-Programm kompiliert kriegt, konkurriert man halt mit Millionen Indern, > das ist Fakt, keine Arroganz. Will ich doch gar nicht (primär mache ich C) - aber Java hat klare Vorteile außerhalb der Windows-Welt, die Du ignorierst. Die Inder haben sich angepaßt und programmieren mit C++ .... das werde ich mir ganz sicher nicht mehr antun, zumal ich Windows sowieso hasse. C ist nur noch im embedded Bereich und ein paar anderen Nischen; deswegen klappt's bei Dir auch nicht mehr dem C++ Job, vielleicht bist Du auch schon zu alt - das weißt Du ganz genau - und Du kannst froh sein, daß Du Deine sichere Stellung im Embedded Segment gefunden hast, weil Du sonst nämlich nichts mehr bekommst, schon gar nicht C++, wenn Du bisher haupt- oder nebensächlich C programmierst. Macht nix, Du bist so von Dir überzeugt, daß Du nix mehr merkst - deswegen auch gar kein Versuch mehr im geliebten C++ Segment zu landen! > Wer dann auch noch keine Ahnung hat, und so Dinge behauptet wie z.B. C++ > wäre gleichzusetzen mit Visual C++ wie gesagt, ich habe das bei mehreren Firmen so erlebt - da war Visual C++ klare Vorgabe! Macht nix, Du bewirbst Dich ja nicht. Aber wenn man das nicht macht, sollte man besser nix sagen. > Keine Angst, ich kenne meinen Marktwert. Gute Embeddedprogrammierer > findet man halt nicht an jeder Ecke Warum nur ist im Embedded Bereich immer noch C angesagt, wenn C++ doch so toll ist?! Warum nur? Macht nix, C++ ist supi, C ist übel und Java ist s***e, so simpel ist Deine Logik ... aber dann würde ich doch besser nichts schreiben :-)
Cola Borateur schrieb im Beitrag #5712317:
> Du bist keinen Pfifferling wert, Du häßliche Großschnauze.
Süß. Der andere bemüht sich zumindest Argumente zu bringen (auch wenn
seine Thesen reichlich an der Realität vorbeigehen), du schaffst
scheinbar nicht mal das.
> Der andere bemüht sich zumindest Argumente zu bringen
hoffentlich sind Deine Lösungen im embedded Bereich besser als Deine
pauschalen Hinweise wie Compiler 'richtig' einstellen, etc.
Blabla kann jeder.
S. B. schrieb: > ach jetzt auf einmal nur 'manchmal'? Vorher hieß es noch > 'hauptsächlich'! Och nö, musst du dich jetzt schon auf Formulierungen stürzen, weil du keine Argumente hast? S. B. schrieb: > Aber ich muß es im Programm für den Precompiler explizit angeben mit > #include <string.h> Tja, so wies halt gehört. Und trotzdem schwafelst du von "es funktioniert nicht". S. B. schrieb: > und der TO nicht! > Erklärung von Dir? Macht nix, geht alles ohne Einstellung; aber dann > schreib besser nix, wenn Du es nicht weißt :-) Was schwafelst du von Einstellungen? Include string.h wies gehört und es funktioniert, wo liegt das Problem? Das Setup vom TS kennt keiner, wie soll man das kommentieren? S. B. schrieb: > Hab ich doch geschrieben: GNU C Compiler unter Linux. > Wenn ich ohne #include <string.h> arbeite, gibt es eine fette Warnung > vom Compiler und ich weiß nicht was ich beim Compiler 'einstellen' soll. > Ausführung mündet dann in einem Core dumped. Wenn ich mit mit dem Hammer auf den Daumen hau statt auf den Nagel wird der Daumen blau und der Nagel geht nicht rein, blöder Hammer. Genau so agierst du. Schriebt keinen korrekten Code und wundert sich, dass es nicht geht. S. B. schrieb: > Bei CodeBlocks unter Windows brauche ich diese Programmzeile nicht; was > ist bei diesem Compiler denn anders? Braucht es die sicher nicht? Und wenn schon, dass etwas zufällig funktioniert heißt nicht dass es immer so funktionieren muss. S. B. schrieb: > Was mußt Du denn noch wissen, damit Du überhaupt eine Lösung bringen > kannst? > Macht nix, Du weißt es nicht, bringst keine konkrete Lösung, aber dann > schreib doch einfach auch nix. Welche Lösung denn? Die hast du doch eh schon gefunden, "#include <string.h>", so wies der Standard sagt. Übrigens reichlich billig, meine Postings zu kopieren. S. B. schrieb: > weil Windows den Hauptmarktanteil hat und es auf Smartphones, Tablets, > etc. CAD-Suiten, etc. totaler Unsinn wären. > Ein stationärer Rechner ist nun einmal leistungsfähiger als jedes > Smartphone, etc. - schlimm, daß man Dir sowas erklären muß. Dein Geschwafel erklärt jetzt immer noch nicht, warum diese Programme nicht in deinem tollen Java geschrieben sind. Was hat Windows damit zu tun? Was hat die Leistungsfähigkeit von Desktoprechner damit zu tun? Du redest dich um Kopf und Kragen, und kannst keine deiner abstrusen Theorien untermauern. S. B. schrieb: > Java hat auch nicht den Anspruch auf irgendwelche Hyperdüper-Programme. Achso, Java ist nicht dafür gedacht, damit sinnvolle Programme zu schreiben, sondern nur Smartphonespielereien und "Hello World"? Sag das doch gleich. S. B. schrieb: > Tja, Linux basiert auf C und versuche C++ zu vermeiden, da ich keinen > Vorteil für mich darin erkennen kann - wenn es geht, möglichst C. Leider kann man auf diesen Satz nicht mal antworten, da er kein sinnvoller Deutscher Satz ist, und ich absolut nicht verstehe, was du damit ausdrücken willst. Aber ganz großes Kino, ich frage dich warum du von "weiterhin C++" schwafelst, wo doch ein Großteil der PC-Software geschrieben wird (und nicht etwa Java, was du immer wieder zu erklären versuchst), und fabulierst von C und Linux. Weißt du eigentlich, was du schreibst? S. B. schrieb: > Plattformunabhängige Programme Achso, deswegen wird ja auch so viel in Java geschrieben. Browser, Mailclients, Webserver oder Officesuiten z.B. Ironie Ende. S. B. schrieb: > Du siehst es ja am obigen > Compiler-Debakel mit string.h ; und das ist ja nur eine Kleinigkeit, > wehe, wenn das Programm größer wäre. Welches Compilerdebakel denn? Du versuchst fehlerhaften Code zu kompilieren, es funktioniert nicht (der Compiler weißt dich sogar auf deinen Fehler hin) und du nennst das Debakel? S. B. schrieb: > weil Du lieber in C++ statt in C programmieren möchtest und C schlechter > als C++ einstuft Tja, deswegen wird bei uns für neue Projekte ja auch nur noch C++ verwendet, wenn ein Compiler für die Plattform existiert. S. B. schrieb: > was definitiv nicht der Fall ist vor allen in Bezug > auf die Laufzeiten. Kannst du das jetzt endlich mit Argumenten belegen, anstatt es immer und immer wieder zu wiederholen? S. B. schrieb: >> Dass es für manche Plattformen nur >> C-Compiler gibt, und dass man sich auch mal mit Legacycode herumschlagen >> muss, ist halt ein notwendiges übel. > mit der Einstellung hast Du Glück, daß Du dort wo Du arbeitest überhaupt > noch arbeiten darfst. Diese Behauptung kannst du sicher auch näher untermauern. Ich kann froh sein dass ich noch wo arbeiten darf, weil es für manche Plattformen keinen C++-Compiler gibt? Aber immerhin, im Gegensatz zu dir nimmt mich ja noch jemand. S. B. schrieb: > Will ich doch gar nicht (primär mache ich C) - aber Java hat klare > Vorteile außerhalb der Windows-Welt, die Du ignorierst. Ich hab dich jetzt schon so oft gefragt, welche diese sein sollen, und warum dann so viel Software (auch Plattformunabhängig) in C++ geschrieben ist, z.B. mit sehr hoher Wahrscheinlichkeit der Webbrowser von dem aus du postest, oder auch der Webserver auf dem dieses Forum läuft. Bis jetzt konntest du das nicht beantworten. S. B. schrieb: > Die Inder haben sich angepaßt und programmieren mit C++ .... das werde > ich mir ganz sicher nicht mehr antun, zumal ich Windows sowieso hasse. Was hat C++ nun mit Windows zu tun? Windows-only wäre eher C#/.NET... S. B. schrieb: > C ist nur noch im embedded Bereich und ein paar anderen Nischen; > deswegen klappt's bei Dir auch nicht mehr dem C++ Job Was genau klappt nicht? S. B. schrieb: > vielleicht bist > Du auch schon zu alt - das weißt Du ganz genau - und Du kannst froh > sein, daß Du Deine sichere Stellung im Embedded Segment gefunden hast, > weil Du sonst nämlich nichts mehr bekommst, schon gar nicht C++, wenn Du > bisher haupt- oder nebensächlich C programmierst. > Macht nix, Du bist so von Dir überzeugt, daß Du nix mehr merkst - > deswegen auch gar kein Versuch mehr im geliebten C++ Segment zu landen! Du wirst immer lächerlicher. Keine Angst, mit C++ kommst du überall unter, ist doch ein großer Teil der verbreiteten Software im Desktop- und Serverbereich in dieser Sprache geschrieben. S. B. schrieb: > wie gesagt, ich habe das bei mehreren Firmen so erlebt - da war Visual > C++ klare Vorgabe! C++ ist trotzdem nicht mit Visual C++ gleichzusetzen, dass du es noch so oft wiederholst, macht es auch nicht wahrer, und zeugt nur von absoluter Ahnungslosigkeit. Aber gut, die konnte man ja schon erkennen als du dich gewundert hast, dass dein C-Programm nicht kompiliert, obwohl du doch angeblich primät mit C arbeitest. Und nur weil manche Firmen halt mit Visual C++ (möglicherweise auch noch C++/CLI) arbeiten, heißt das immer noch nicht, dass C++ auch nur ansatzweise irgenwas mit MS zu tun hat... S. B. schrieb: > Warum nur ist im Embedded Bereich immer noch C angesagt, wenn C++ doch > so toll ist?! Warum nur? Weil es nicht für alle Plattformen Compiler gibt und weil es oft Legacycode gibt, aber das hab ich dir ja oben schon erklärt. Und natürlich auch weil es ahnungslose Leute wie dich gibt die unbelegten Bullshit von angeblich laufzeitintensivem C++ glauben. Gibt ja auch noch genug Firmen die kein Test Driven Development machen, weil man das vor 30 Jahren auch nicht gemacht hat. Aber keine Angst, im professionellen Embeddedbereich nutzen mehr C++ als du vermutlich denkst. S. B. schrieb: > Macht nix, C++ ist supi, C ist übel und Java ist s***e, so simpel ist > Deine Logik ... Komisch, dabei hab ich doch genau das mit C und C++ so nie geschrieben, lediglich, dass C++ besser als C ist, weder, dass das eine supi wäre, noch, dass das andere übel wäre. Aber mit einem hast du immerhin recht, Java ist tatsächlich Kacke. S. B. schrieb: > aber dann würde ich doch besser nichts schreiben :-) Wenn du schon meine Postings kopieren musst, solltest du zumindest keine Lügen verbreiten. Oder halt einfach mal nix schreiben, lieber bewerben, damit du wieder einen Job bekommst.
S. B. schrieb: >> Der andere bemüht sich zumindest Argumente zu bringen > hoffentlich sind Deine Lösungen im embedded Bereich besser als Deine > pauschalen Hinweise wie Compiler 'richtig' einstellen, etc. > Blabla kann jeder. Nochmal: du wunderst dich ernsthaft dass dein Programm nicht funktioniert, wenn du die nötigen Header nicht includest, und machst dem Compiler und mir einen Vorwurf? Dir ist halt einfach nicht zu helfen.
> Nochmal: du wunderst dich ernsthaft dass dein Programm nicht > funktioniert, wenn du die nötigen Header nicht includest, und machst dem > Compiler und mir einen Vorwurf? schau Dir den Thread nochmal genau an! Das ist nicht mein Programm, sondern das Programm des TO, das beim TO unter Windows CodeBlocks ohne die Programmzeile #include <string.h> auskommt. Meine Programmverbesserung steht im Post Datum: 22.01.2019 13:05 Dort habe ich auch nix falsch gemacht, sondern was konkret richtiges in Bezug auf das Problem des TO geschrieben, was Du ja nicht kannst - der Thread ist ja schon sehr lang und das Problem des TO ist ja mittlerweile gelöst. Ich vermute, daß hat mit der ANSI-Konformität des CodeBlock-Compiler zu tun, von dem der CodeBlock-Compiler abweicht. Genau so etwas gibt es bei Java wegen der JRE nicht; also ein klarer Vorteil insbesondere auf verschiedenen Plattformen. Also leichte Compileräbänderungen und schon kann das ganze Programm anders aussehen bzw. nicht mehr funktionieren. Bei C++ Compilern wird es wohl nicht anders sein. Und Du sagst es ja selbst, string.h gehört mit rein - die Einstellung bei der es wie bei CodeBlocks ohne string.h. funktioniert möge man mir doch bitte mal für GNU C zeigen! Die Frage, warum das bei CodeBlocks anders ist, hast Du bis jetzt noch nicht beantwortet und kannst es auch nicht; weil Dich die ganze Thematik nicht wirklich interessiert, so habe ich jedenfalls den Eindruck. Du postest sehr viel, aber eben nur viel blabla - da kann ich auch den Fernseher einschalten und hab mehr davon :-)
> Aber keine Angst, im professionellen Embeddedbereich nutzen mehr C++ als > du vermutlich denkst. richig, weil auch der Speicher im Embeddedbereich stetig zunimmt und damit Leute wie Du, die von C bedingt Ahnung haben auch mit an Board bleiben und sich nicht den C++ Job besorgen; selbst das machst Du ja nicht. Ist nicht schlimm, aber man sollte es wenigstens zugeben .... deswegen überlasse ich ja auch den anderen C++. Alles geht eben nicht. Jedem seine Lieblingssprache.
Ich habe irgendwie den Teil verpasst, wo ihr das mit den Zeichensätzen erschöpfend geklärt habt, dass dieser Thread jetzt für andere Fragestellungen offen ist.
S. B. schrieb: > schau Dir den Thread nochmal genau an! > Das ist nicht mein Programm, sondern das Programm des TO, das beim TO > unter Windows CodeBlocks ohne die Programmzeile #include <string.h> > auskommt. Und trotzdem wunderst DU dich, dass es bei DIR nicht funktioniert. S. B. schrieb: > sondern was konkret richtiges in > Bezug auf das Problem des TO geschrieben, was Du ja nicht kannst - der > Thread ist ja schon sehr lang und das Problem des TO ist ja mittlerweile > gelöst. Achso, was ich also nicht kann. Liegt nicht etwa daran, dass sein Problem schon gelöst ist. S. B. schrieb: > Ich vermute, daß hat mit der ANSI-Konformität des CodeBlock-Compiler zu > tun, von dem der CodeBlock-Compiler abweicht. Ach ne, sag bloß? C wird übrigens primär von der ISO standardisiert, "ANSI-C" bezeichnet gang, ganz was altes... aber gut, du denkst ja auch "C++" und "Visual C++" wäre das gleiche und C++ hätte was mit Windows zu tun, also who cares. S. B. schrieb: > Genau so etwas gibt es bei Java wegen der JRE nicht; also ein klarer > Vorteil insbesondere auf verschiedenen Plattformen. Nochmal, was genau soll das nicht standardkonforme Verhalten eines C-Compilers mit der JRE zu tun haben? Wer hätte das gedacht, nicht standardkonformer Code produziert fehlerhafte Ergebnisse, da ist die Sprache schuld!!11!1elf Preisfrage, was passiert, wenn die JRE auf der Zielplattform nicht dem Sprachstandard entspricht? S. B. schrieb: > Also leichte Compileräbänderungen und schon kann das ganze Programm > anders aussehen bzw. nicht mehr funktionieren. Falsch, so lange man nur im Sprachstandard definierte Dinge tut, passiert nichts. Wenn du Dinge machst, die in der Sprache nicht definiert sind, geht das auch in Java nach hinten los. S. B. schrieb: > Bei C++ Compilern wird es wohl nicht anders sein. Da C++ wesentlich strenger ist als C, ist das Problem eher kleiner denn größer. Aber das wüsstest du, würdest du über Themen reden, bei denen du dich auskennst. S. B. schrieb: > Und Du sagst es ja selbst, string.h gehört mit rein - die Einstellung > bei der es wie bei CodeBlocks ohne string.h. funktioniert möge man mir > doch bitte mal für GNU C zeigen! Welche Einstellung? Warum soll es eine Einstellung geben, mit der fehlerhafter Code plötzlich kompiliert, nur weil es bei einem anderen Compiler zufälligerweise funktioniert? S. B. schrieb: > Die Frage, warum das bei CodeBlocks anders ist, hast Du bis jetzt noch > nicht beantwortet und kannst es auch nicht; Doch: weil es halt zufällig so ist, denn "undefined behaviour" darf auch zufällig funktionieren. Hab ich dir auch schon lang und breit erklärt, dass du den Compiler halt falsch bedienst. S. B. schrieb: > weil Dich die ganze Thematik > nicht wirklich interessiert, so habe ich jedenfalls den Eindruck. > Du postest sehr viel, aber eben nur viel blabla - da kann ich auch den > Fernseher einschalten und hab mehr davon Ich frag dich schon zum hundertsten mal, ob du denn endlich deine absurden Behauptungen (Performance und Verbreitung von Programmiersprachen, etc. pp.) sachlich belegen kannst, was du nach wie vor verweigerst, und unterstellst mir, mich nicht dafür zu interessieren? Ganz großes Kino. Ja, setz dich vor den Fernseher und schau das Dschungelcamp, ist besser. S. B. schrieb: > richig, weil auch der Speicher im Embeddedbereich stetig zunimmt und > damit Leute wie Du, die von C bedingt Ahnung haben Süß. Woher nimmst du die Behauptung, ich würde kein C können? Und kannst du jetzt endlich, endlich die strunzdämliche Behauptung belegen, C++ würde so ganz doll viel Speicher benötigen? S. B. schrieb: > und sich nicht den C++ Job besorgen; selbst das machst Du ja > nicht. Was genau mach ich nicht? Kannst du eigentlich lesen, was ich schreibe? Ist Deutsch eine Fremdsprache für dich, sollen wir lieber auf Englisch wechseln? S. B. schrieb: > Ist nicht schlimm, aber man sollte es wenigstens zugeben ... Was genau soll man zugeben? S. B. schrieb: > deswegen > überlasse ich ja auch den anderen C++. Alles geht eben nicht. > Jedem seine Lieblingssprache. Wohl eher, weil deine abstrusen Behauptungen daran zweifeln lassen, dass du IRGENDEINE Sprache vernünftig kannst. C kann jedenfalls nicht dein Talent sein, wunderst du dich doch, dass fehlerhafter Code komische Dinge macht. C++ kann es auch sein, denkst du doch, es würde auf wundersame Weise ganz dolle viel Speicher brauchen, wofür auch immer. Java? Vielleicht, aber daran wachsen die Zweifel auch, behauptest du doch, unspezifizierte Dinge zu tun würde dort funktionieren.
Walter T. schrieb: > Ich habe irgendwie den Teil verpasst, wo ihr das mit den Zeichensätzen > erschöpfend geklärt habt, dass dieser Thread jetzt für andere > Fragestellungen offen ist. Die Zeichensätze wurden im Nachbarthread, auf den verwiesen wurde, schon ziemlich breit erklärt. Kompilierst du dein Programm für einen Zeichensatz, verwendest aber dann einen anderen, kommt halt Unsinn raus. Unschön, ist aber leider derzeit so.
> Wohl eher, weil deine abstrusen Behauptungen daran zweifeln lassen, dass > du IRGENDEINE Sprache vernünftig kannst. vermutlich mehr wie Du :-) > Woher nimmst du die Behauptung, ich würde kein C können? An der nachfolgenden Bemerkung: > Und kannst du jetzt endlich, endlich die strunzdämliche Behauptung > belegen, C++ würde so ganz doll viel Speicher benötigen? Du siehst es am Quellcode von C++ und an Laufzeitmessungen (wohlgemerkt nicht des Compilers, sondern des Objektcodes). Speziell bei älteren Mikrocontroller funzt C++ wegen des Speicherbedarfs nicht. Bei modernen Controller spielt es keine Rolle mehr und weil C++ in ist haben Dienstleister so wie Du einen ganz besonderen Augenmerk drauf :-> > Doch: weil es halt zufällig so ist, denn "undefined behaviour" darf auch > zufällig funktionieren. Hab ich dir auch schon lang und breit erklärt, > dass du den Compiler halt falsch bedienst. undedined behaviour, LOL, na klar. Ich verwende nicht CodeBlocks unter Windows wie der TO, sondern GNU C unter Linux und mein Programm läuft - wenn man nur lesen könnte :( > Die Zeichensätze wurden im Nachbarthread, auf den verwiesen wurde, schon > ziemlich breit erklärt. welcher denn? > Kompilierst du dein Programm für einen > Zeichensatz, verwendest aber dann einen anderen, kommt halt Unsinn raus. > Unschön, ist aber leider derzeit so. na ja, das hängt vom Quellcode ab und von der Zielsetzung des Programms. > Ich habe irgendwie den Teil verpasst, wo ihr das mit den Zeichensätzen > erschöpfend geklärt habt, dass dieser Thread jetzt für andere > Fragestellungen offen ist. In puncto C kann ich Dir einiges beantworten - am besten konkretes Beispiel. Bei C++ (und vielleicht auch C) kann Dir sicherlich vn nn(Gast) weiterhelfen oder auch nicht :-) Da wird sich dann zeigen, was er kann :-)
S. B. schrieb: > Du siehst es am Quellcode von C++ Ach, du kannst also am Quellcode ablesen, dass C++ doll viel Speicher braucht, denn optimierende Compiler und zero cost abstraction wurden ja noch nicht erfunden. Du bist ja ein richtiger Experte, schreibst wahrscheinlich in C auch alles in eine riesige Funktion anstatt sauber zu gliedern, weil du von inlining und Optimizer noch nie gehört hast... S. B. schrieb: > an Laufzeitmessungen Die du zwar ständig versprichst, aber nicht liefern kannst. S. B. schrieb: > undedined behaviour, LOL, na klar. Was ist es denn deiner Meinung nach, wenn du den passenden Header nicht includest und dich dann Wunderer dass es nicht geht? S. B. schrieb: > erwende nicht CodeBlocks unter Windows wie der TO, sondern GNU C unter > Linux und mein Programm läuft - wenn man nur lesen könnte Na wenns doch eh geht, was beschwerst du dich dauernd dass C ganz böse ist und bei dir nicht geht? S. B. schrieb: > welcher denn? Wurde oben verlinkt. Schau halt nach. S. B. schrieb: > das hängt vom Quellcode ab und von der Zielsetzung des Programms. > >> Ach ne, das Resultat hängt vom Quellcode ab. Sag bloß. S. B. schrieb: > In puncto C kann ich Dir einiges beantworten - am besten konkretes > Beispiel. Könntest du schon beantworten, warum der Aufruf einer nicht deklarierten Funktion undefiniert ist, oder bereitet dir das immer noch Kopfzerbrechen? S. B. schrieb: > Bei C++ (und vielleicht auch C) kann Dir sicherlich vn nn(Gast) > weiterhelfen Ich dachte, du bist C++-Experte und kannst am Quellcode schon den Resourcenverbrauch ablesen?
> Ach, du kannst also am Quellcode ablesen, dass C++ doll viel Speicher > braucht, denn optimierende Compiler und zero cost abstraction wurden ja > noch nicht erfunden. schau mal hier: https://stackoverflow.com/questions/418914/why-is-c-so-fast-and-why-arent-other-languages-as-fast-or-faster auch anderen fällt auf, daß C schneller ist - nur Assembler ist schneller als C, da maschinennäher .... nur Dir fällt vor lauter C++ Hype nichts mehr auf. C++ hat andere Vorteile gegenüber C, die Du gar nicht ansprichst! Mach das doch, wenn C++ Deine Herzensangelegenheit ist! > Die du zwar ständig versprichst, aber nicht liefern kannst. Du kennst den Unterschied zwischen runtime und compile-time nicht und deswegen eierst Du rum, weil bei C++ ja alles gut sein muß! Schau mal hier, da wird der Unterschied erklärt: https://www.quora.com/What-is-the-difference-between-runtime-and-compile-time > Was ist es denn deiner Meinung nach, wenn du den passenden Header nicht > includest und dich dann Wunderer dass es nicht geht? OMG, ich hab den Header includiert! Mir ist aber aufgefallen, daß das bei CodeBlocks gar nicht notwendig ist und das hat mich etwas gewundert .... wie oft muß ich das hier noch posten bis Du es endlich kapierst?! > Na wenns doch eh geht, was beschwerst du dich dauernd dass C ganz böse > ist und bei dir nicht geht? Sag mal, kannst Du nicht lesen? Bei mir funktioniert es nur mit der zusätzlichen include-Anweisung und beim TO geht es ohne diese! Interessiert Dich vor lauter f**k C++ Geilheit natürlich nicht, warum das so ist ?! Und das sagt dann sehr vieles aus ): > Ich dachte, du bist C++-Experte und kannst am Quellcode schon den > Resourcenverbrauch ablesen? wenn Du mir nicht glaubst lies doch im Netz wie andere das sehen - wie gesagt C++ hat Vorteile, aber sicher nicht runtime der fertigen Programme; da bist Du auf dem Holzweg.
S. B. schrieb: > schau mal hier: > https://stackoverflow.com/questions/418914/why-is-c-so-fast-and-why-arent-other-languages-as-fast-or-faster > auch anderen fällt auf, daß C schneller ist Uiuiuiui, na wenns auf Stackoverflow steht, muss es ja stimmen! Selbst kannst du also nicht mehr argumentieren? Aber bitte, dann zerlegen wir deine reichlich dünne Suppe halt mal (ich beschränk mich mal aus Zeitgründen auf das "Top"-Posting): > Newer languages which have support for garbage collection, dynamic typing > and other facilities which make it easier for the programmer to write > > programs. Gegessen. C++ hat keinen Garbagcollector, auf Laufzeitdynamik kann man komplett verzichten und alles zur Compilezeit machen. Ein Expere halt, wie du. > The catch is, there is additional processing overhead which will degrade > the performance of the application. C doesn't have any of that Oh, eine leere Behauptung ohne Beleg, woher kennen wir das nur? Welcher "additional processing overhead"? Oh großer "S. B. (piezokristall)", kannst du diese Behauptung endlich, endlich Argumentieren, nachdem du sie immer und immer wieder aufstellst? > That said, many languages and platforms, such as Java (with its Java > Virtual Machine) and .NET (with its Common Language Runtime) have > improved performance over the years with advents such as just-in-time > compilation which produces native machine code from bytecode to achieve > higher performance. Oh, achso, der redet nur von Java und .NET, na sag das doch gleich, warum verlinkst du dann drauf? Ach, dann nehmen wir halt das zweite Posting auch noch dran: > C won't > Check array index bounds > Check for uninitialized variable values > Check for memory leaks > Check for null pointer dereference Tja, und da ich das in C alles manuell machen muss, während es in C++ der Compiler für mich tut (und wunderbar optimieren kann, macht es den Code blöderweise schneller und nicht langsamer. Defensive Programming würde in C von mir verlangen, dass ich in der aufgerufenen Funktion die Länge meines Arrays checke, auch wenn die aufrufende Funktion das schon getan hat (sie könnte ja auch von einer anderen aufgerufen werden) - in C++ erkennt der Compiler das und wirft einen raus wenn möglich. Der Rest: Geschwafel über Java, und Designentscheidungen von C, die selbst die Macher von C heute ganz anders sehen. Schade, ich dachte jetzt kommt endlich die Umwerfende Argumentation deiner Behauptung auf die ich schon so lange warte, stattdessen gehts dort nur um Java und .NET. S. B. schrieb: > nur Assembler ist > schneller als C, da maschinennäher Ich muss dich enttäuschen, aber um an die Geschwindigkeit eines guten C-Compilers heranzukommen müsstest du schon einer der absoluten Top-Assembler-Programmierer sein, und selbst dann wäre es fraglich. Wie so viele deiner Behauptungen. S. B. schrieb: > nur Dir fällt vor lauter C++ > Hype nichts mehr auf. Äh, Hype, bitte wo? S. B. schrieb: > C++ hat andere Vorteile gegenüber C, die Du gar nicht ansprichst! Doch, genau das habe ich getan, seitdem drehst du am Rad und wirfst hier mit Kot um dich. Falls du dich erinnerst: in meinem Ursprungsposting hab ich kurz mal auf die Vorteile von C++ verwiesen. S. B. schrieb: > Mach das doch, wenn C++ Deine Herzensangelegenheit ist! Herzensangelegenheit? Nö. Ein Werkzeug halt. Keine Ahnung warum du so durchdrehst, und ständig irgendwelche Behauptungen aufstellst, die dann ja doch leer bleiben. Deine Behauptungen über mich sind ja ähnlich fundiert wie die über diverse Programmiersprachen. S. B. schrieb: > Du kennst den Unterschied zwischen runtime und compile-time nicht und > deswegen eierst Du rum, weil bei C++ ja alles gut sein muß! > Schau mal hier, da wird der Unterschied erklärt: > https://www.quora.com/What-is-the-difference-between-runtime-and-compile-time Du wirst immer lustiger, warum genau soll ich den Unterschied nicht kennen, wie kommst du zu der Behauptung? Und was hat das nun mit dem Thema zu tun? Ich frage dich nun schon unzählige Male nach einem Beleg für deine Behauptung eines schlechteren Laufzeitverhaltens, und du rotzt diesen unpassenden Link hier rein, anstatt deine Behauptung endlich zu argumentieren? S. B. schrieb: > OMG, ich hab den Header includiert! Mir ist aber aufgefallen, daß das > bei CodeBlocks gar nicht notwendig ist und das hat mich etwas gewundert > .... wie oft muß ich das hier noch posten bis Du es endlich kapierst?! Und doch hast du unzählige Male herumgejammert dass C ganz pöse unportabel ist, weil oh Gott, undefiniertes Verhalten nun mal undefiniert ist. S. B. schrieb: > Sag mal, kannst Du nicht lesen? Bei mir funktioniert es nur mit der > zusätzlichen include-Anweisung und beim TO geht es ohne diese! Ja, und ich erklär dir schon zum hundertsten Mal, dass es völlig egal ist, wenn bei jemandem fehlerhafter Code zufälligerweise das erwartete verhalten zeigt, wichtig ist lediglich, dass richtiger Code funktioniert. S. B. schrieb: > Interessiert Dich vor lauter f**k C++ Geilheit natürlich nicht, warum > das so ist ?! Ich hab dir schon oft genug warum es so ist, du ignorierst es nur ständig. Würde mich interessieren, wo du diese "f**k C++ Geilheit" verortest. Nur weil du es nicht schaffst, Vor- und Nachteile von Programmiersprachen sachlich und korrekt zu diskutieren? Nur weil du ständig Behauptungen (über alle möglichen Programmiersprachen, nicht nur C++) in den Raum wirfst, immer und immer wieder, die du bis jetzt nie, aber auch wirklich nie belegen konntest? Das höchste der Gefühle waren bisher hingerotzte, Themenverfehlende Links... S. B. schrieb: > wenn Du mir nicht glaubst lies doch im Netz wie andere das sehen Kannst du es nicht endlich, endlich selbst begründen? Ist es wirklich so schwer, bist du wirklich so ahnungslos? Warum stellst du dann laufend diese Behauptungen auf? Oder wenn du das schon nicht schaffst, stell doch zumindest mal einen Link rein wo jemand das mit Argumenten erklärt (wo du es schon nicht schaffst). Aber bitte nicht wieder irgendeinen Stackoverflow-Link, der sich eigentlich auf Java und .NET bezieht. S. B. schrieb: > wie > gesagt C++ hat Vorteile, aber sicher nicht runtime der fertigen > Programme; da bist Du auf dem Holzweg. Ständiges wiederholen unbelegter Behauptungen macht diese auch nicht besser. Beweis es endlich. Ach ja, hast du vorher nicht noch vom immensen Speicherverbrauch geschrieben? Das bitte auch gleich. Und dann bitte die restlichen Behauptungen: C++ wäre ein Superset von C, C++ hat irgendwas mit Microsoft zu tun, C++ nimmt keiner weil Java ja der Trend ist (doof nur, dass dein Webbrowser vermutlich in C++ geschrieben ist), C wird nicht weiterentwickelt (ach ne, haben wir ja eh schon entkräftet), C++ hat sich wegen bunter Fenster durchgesetzt (genau, deswegen nimmt man es ja auch im Serverbereich, du meinst wohl eher Java und .NET?), C++ hat sich wegen der tollen IDE durchgesetzt (welche soll das nochmal sein, gcc + vim?), etc. pp.
> Ständiges wiederholen unbelegter Behauptungen macht diese auch nicht > besser. das machst Du leider: "Und trotzdem wunderst DU dich, dass es bei DIR nicht funktioniert." Immerhin scheinst Du es jetzt teilweise kapiert zu haben, weil ich das 100mal wiederholt habe - es funktioniert bei mir, weil ich string.h inkludiert habe und nochmal: Beim TO funktioniert es unter CodeBlocks eben auch ohne string.h - darum geht es HIER! Deine Antwort darauf: Ja das ist dann Zufall, undefined behaviour, fehlerhafter Code bei CodeBlocks eben. Na, das ist ja mal eine tolle Antwort! Mit anderen Worten: Du weißt es nicht (und ich leider auch nicht - deswegen frage ich danach). Das ist der Unterschied. > Ja, und ich erklär dir schon zum hundertsten Mal, dass es völlig egal > ist, wenn bei jemandem fehlerhafter Code zufälligerweise das erwartete > verhalten zeigt, wichtig ist lediglich, dass richtiger Code > funktioniert. aha, es ist also fehlerhafter Code, wenn es bei CodeBlocks ohne string.h funktioniert? Ist das jetzt Deine Aussage? Ja oder nein - oder was jetzt? > Selbst kannst du also nicht mehr argumentieren? Du kapierst den Unterschied zwischen runtime und compile-time nicht und machst deshalb immer wieder den gleichen Fehler, mindestens 100mal, dazu kommen wir gleich noch. > Tja, und da ich das in C alles manuell machen muss, während es in C++ > der Compiler für mich tut (und wunderbar optimieren kann, macht es den > Code blöderweise schneller und nicht langsamer. das kann schon, daß die compile-time aufgrund der Weiterentwicklung der C++ Compiler besser ist als mit einem C Compiler mit C11 Standard - das bezweifle ich nicht - es geht aber auch um die Runtime der Programme und das ist was anderes. Richtig und in C gibt es keine Weiterentwicklung seit 2011, C11 - und heute schreiben wir 2019! Oha! So sieht also Weiterentwicklung bei Dir aus?! Fast 8 Jahre nix Neues! Für mich ist das keine Weiterentwicklung und das geht auch nicht, weil irgendwann die Optimierung eines Compilers abgeschlossen ist. Weiterhin kann ich natürlich C++ verwenden, weil C++ bequemer und in der Compilezeit heute besser ist als damals - aber nicht generell besser, genau das ist Dein Irrglaube! > Und doch hast du unzählige Male herumgejammert dass C ganz pöse > unportabel ist, weil oh Gott, undefiniertes Verhalten nun mal > undefiniert ist. jo, alles Zufall, alles undefinierbar, weil das in C nun mal so ist - sag doch besser 'ich weiß es leider nicht' anstelle dieses hochtrabenden Geschwafels von Undefinierbarkeit, usw. - Tip: meld Dich mal in der Politik an. > Falls du dich erinnerst: in meinem Ursprungsposting hab > ich kurz mal auf die Vorteile von C++ verwiesen. Ich weiß es jetzt nicht genau, ist irgendwo am Anfang des Threads - da empfiehlst Du in Deinem ersten Post zu diesem Thread den TO: Nimm C++, in C geht das nicht richtig, viel zu kompliziert. Na, offenbar geht es schon! Du warst nicht in der Lage ihm zu helfen vor lauter C++ Hype! > Würde mich interessieren, wo du diese "f**k C++ Geilheit" verortest. Nur > weil du es nicht schaffst, Vor- und Nachteile von Programmiersprachen > sachlich und korrekt zu diskutieren? das fängt schon mit Deiner Empfehlung an bei einem simplen Programmierproblem die Sprache zu wechseln! > Oh großer "S. B. (piezokristall)", ... Ja, Deine Sachlichkeit läßt mindestens genauso zu wünschen übrig! Richtig, an Sachlichkeit mußt Du auch noch arbeiten. > Ein Expere halt, wie du. siehst Du, ebenfalls jemand, der so seine Zweifel hat. Ich bezweifle, daß die Runtime der vom C++ Compiler optimierten C++ Programme wirklich besser als identische C Programme ist - bitte, wenn Du es besser weißt, beweise es doch auch einmal mit Quellen! > Beweis es endlich. Ach ja, hast du vorher nicht noch vom > immensen Speicherverbrauch geschrieben? Hast Du Dir mal die CAD-Suiten, usw. angeschaut? Da spielt Speicher keine Rolle - das war früher ganz anders, da gab es eben nur ein paar Kilobyte an Speicher genauso wie bei Embedded teilweise noch heute! Und die C++ Compiler waren in der Anfangszeit ebenfalls grottig. Inbesondere bei größeren Programmen ist der Unterschied nun wirklich spürbar zu merken, u.a. KDE - aufgrund von anderen Nachteilen hat sich C nun mal nicht durchgesetzt bzw. versuchte durch C99, C11 Weiterentwicklung ein paar C++ Konzepte zu übernehmen. > Und dann bitte die restlichen Behauptungen: C++ wäre ein Superset von C, was soll es denn sonst sein? Eine Untermenge? LOL > C++ hat irgendwas mit Microsoft zu tun, Indirekt - C++ wurde vom Marktführer Microsoft dankbar aufgenommen. Deine Software-Suiten, usw. die werden nun mal mit Visual C++ compiliert und nicht mit GNU C++, Borland C++ oder weiß der Geier was - obwohl das auch funktionieren würde .... vielleicht, wenn da nicht dieses zufällige böse "undefined behaviour" der anderen Compiler wäre - warum soll man das Risiko eingehen, wenn es Visual C++ kostenlos zum Download gibt, alles reibungslos funktioniert und das zusammen mit Windows aus einem Guß ist? C++ nimmt keiner weil Java ja der Trend ist (doof nur, dass dein Webbrowser vermutlich in C++ geschrieben ist), C wird nicht weiterentwickelt (ach ne, haben wir ja eh schon entkräftet), ja, ja, wir schreiben das Jahr 2019, letzte Weiterentwicklung 2011, hust, röchel. Dillo (https://www.dillo.org/) ist ein Browser, der teilweise in C geschrieben ist. Das ist dann mal 'Geschwindigkeit'! Oder Best of the best in Assembler: https://kolibrios.org/en/ Das ist dann die hohe Kunst! Nur leider kommen die an die Funktionalität der Standardprogramme gar nicht heran, vieles geht noch nicht und wird nie funktionieren - wie denn auch als One-Man-Show! > C++ hat sich wegen bunter Fenster durchgesetzt > (genau, deswegen nimmt man es ja auch im Serverbereich, du meinst wohl > eher Java und .NET?), Serverbereich weiß ich nicht, da hat Linux wohl etwas Boden gut gemacht? - aber ansonsten gilt das Marktführerprinzip, also Android vor IOS, Microsoft vor Apple, usw. > C++ hat sich wegen der tollen IDE durchgesetzt > (welche soll das nochmal sein, gcc + vim?), etc. pp. hab ich doch schon x-mal geschrieben: Visual C++ Microsoft ist Marktführer, warum soll man sich dann auf Experimente mit anderen Compilern einlassen - nur, weil die 5% besser sind? Okay, in Deinem Embedded Bereich kannst Du das natürlich gerne machen und Du scheinst ja auch quasi Dein eigener Chefe zu sein. Der Marktführer wird genommen, also Windows, IE oder Firefox, MS Office, usw. - Punkt; so will es nun mal die Mehrheit! Du kannst natürlich gern was anderes wählen, aber im Prinzip dann berufliches Abseits, falls Du aus unerfindlichen Gründen doch nochmal wechseln mußt. Achso, Sicherheit ist ja in C++ ganz groß geschrieben (eines Deiner TOP-Argumente zu Anfang des Threads); gab's da nicht mal einen Ariane 5 Absturz? Dein Englisch ist ja besser, welche Programmiersprache haben die da verwendet? Hört sich stark nach C++ an, aber mein Englisch ist nicht so gut, vielleicht täusche ich mich ja: http://computer-programming-forum.com/44-ada/626c282aa05b4b23-15.htm
S. B. schrieb: > Immerhin scheinst Du es jetzt teilweise kapiert zu haben, weil ich das > 100mal wiederholt habe - es funktioniert bei mir, weil ich string.h > inkludiert habe und nochmal: Beim TO funktioniert es unter CodeBlocks > eben auch ohne string.h - darum geht es HIER! Tja, und ich hab dich nun schon 100 Mal gefragt, wo dein Problem damit ist, dass es bei ihm zufällig funktioniert? CodeBlocks ist ja nicht mal ein Compiler sondern eine IDE, wir wissen also genau gar nix über sein Setup, für dich ist aber C Schrott deswegen. S. B. schrieb: > Deine Antwort darauf: Ja das ist dann Zufall, undefined behaviour, > fehlerhafter Code bei CodeBlocks eben. > Na, das ist ja mal eine tolle Antwort! > Mit anderen Worten: Du weißt es nicht (und ich leider auch nicht - > deswegen frage ich danach). Das ist der Unterschied. "undefined behaviour" ist ein Begriff aus dem C-Standard. Aber das weißt du halt nicht, weil du kein C kannst. Und nein, nicht CodeBlocks (oder der Compiler, den der TS unbekannterweise verwendet) ist fehlerhaft, sondern sein Code, wie wir ja schon festgestellt haben. S. B. schrieb: > aha, es ist also fehlerhafter Code, wenn es bei CodeBlocks ohne string.h > funktioniert? Ist das jetzt Deine Aussage? Ja oder nein - oder was > jetzt? Natürlich ist sein Code fehlerhaft, dass es bei einzelnen Compilern zufällig funktioniert, ist lt. Standard nun mal zulässig. S. B. schrieb: > Du kapierst den Unterschied zwischen runtime und compile-time nicht und > machst deshalb immer wieder den gleichen Fehler, mindestens 100mal, dazu > kommen wir gleich noch. Äh bitte was? Du kennst offensichtlich nicht mal den Unterschied zwischen Compiletime, Compiletime-Optimization und Runtime Behaviour... S. B. schrieb: > das kann schon, daß die compile-time aufgrund der Weiterentwicklung der > C++ Compiler besser ist als mit einem C Compiler mit C11 Standard - das > bezweifle ich nicht - es geht aber auch um die Runtime der Programme und > das ist was anderes. Oh mein Gott, und wieder outest du dich als völlig ahnungslos. Nein, die Zeit die der Compiler für C++ braucht ist sicher nicht geringer, eher höher, eben weil er zur Compilezeit bereits stärker optimieren kann, was wiederum die Laufzeit verringert. Du kannst aber nichtmal diese simplen Begriffe auseinander halten. S. B. schrieb: > Richtig und in C gibt es keine Weiterentwicklung seit 2011, C11 - und > heute schreiben wir 2019! Oha! So sieht also Weiterentwicklung bei Dir > aus?! Nun, du hast ja so getan als hätte sich seit 1989 nichts mehr getan... S. B. schrieb: > Weiterhin kann ich natürlich C++ verwenden, weil C++ bequemer und in der > Compilezeit heute besser ist als damals - aber nicht generell besser, > genau das ist Dein Irrglaube! Komisch, nicht nur dass ich nie geschrieben habe, dass C++ in jeder hinsicht besser wäre als C (wobei, ja, mir fällt da eigentlich kein Fall ein wo dem nicht so wäre), compiliert C++ ganz sicher nicht schneller. Aber du weißt halt nicht was Compiletimeoptimization ist (gibt es übrigens auch bei C), und lässt dich deswegen durch solche Begriffe verwirren. S. B. schrieb: > jo, alles Zufall, alles undefinierbar, weil das in C nun mal so ist - > sag doch besser 'ich weiß es leider nicht' anstelle dieses hochtrabenden > Geschwafels von Undefinierbarkeit, usw. - Tip: meld Dich mal in der > Politik an. Tipp: lern endlich C bevor du hier über diese Sprache fachsimpelst, dann lernst du, dass "undefined" Teil des Standards ist! S. B. schrieb: > Nimm C++, in C geht das nicht richtig, viel zu kompliziert. Wo genau soll ich das geschrieben haben? S. B. schrieb: > Na, offenbar geht es schon! Du warst nicht in der Lage ihm zu helfen vor > lauter C++ Hype! Ach ja klar. Unternimm was gegen deinen Wahn. S. B. schrieb: > das fängt schon mit Deiner Empfehlung an bei einem simplen > Programmierproblem die Sprache zu wechseln! Wo soll ich das getan haben? S. B. schrieb: > Ja, Deine Sachlichkeit läßt mindestens genauso zu wünschen übrig! > Richtig, an Sachlichkeit mußt Du auch noch arbeiten. Wenn jemand tagelang unbelegten Müll behauptet und auch mehrfache Nachfrage nix belegen kann, hört die Sachlichkeit halt irgendwann auf. S. B. schrieb: > siehst Du, ebenfalls jemand, der so seine Zweifel hat. Nochmal. Er redet von einem Garbage Collector. Einen solchen gibt es in C++ nicht. Er redet offensichtlich von Java und .NET. S. B. schrieb: > Ich bezweifle, > daß die Runtime der vom C++ Compiler optimierten C++ Programme wirklich > besser als identische C Programme ist Und immer noch kannst du nicht mal im entferntesten Begründen, warum dies so sein soll. Weil du halt weder die eine noch die andere Sprache wirklich kennst. S. B. schrieb: > bitte, wenn Du es besser weißt, > beweise es doch auch einmal mit Quellen! Ach, jetzt soll ich noch Quellen für deinen Bullshit bringen? Aber bitte, gerne, informier dich einfach mal über Zero Cost Abstraction wie ich es dir schon lange nahelege, wenn du willst, kann ich dir auch ein Beispielprogramm zusammenhacken. Liefer doch endlich nur ein einziges Argument für deine abstrusen Behauptungen. S. B. schrieb: > Hast Du Dir mal die CAD-Suiten, usw. angeschaut? Da spielt Speicher > keine Rolle - das war früher ganz anders, da gab es eben nur ein paar > Kilobyte an Speicher genauso wie bei Embedded teilweise noch heute! Ja ne ist, klar, gerade bei solchen High-Performancetools soll Perfomance egal sein. Aber sonst gehts noch? Wäre dem so, wäre das Zeug ja in Java oder .NET geschrieben... S. B. schrieb: > Und die C++ Compiler waren in der Anfangszeit ebenfalls grottig Bestreitet keiner. S. B. schrieb: > Inbesondere bei größeren Programmen ist der Unterschied nun wirklich > spürbar zu merken, u.a. KDE Achso, du spürst also, ob ein Programm in C oder C++ geschrieben ist? Esoteriker, oder was? Und KDE ist nicht etwa aufgrund von mehr Eyecandy langsamer? S. B. schrieb: > Deine Software-Suiten, usw. die werden nun mal mit Visual C++ compiliert > und nicht mit GNU C++, Borland C++ oder weiß der Geier was - obwohl das > auch funktionieren würde Ja ne klar, keiner verwendet GCC. Ist klar. S. B. schrieb: > was soll es denn sonst sein? Eine Untermenge? LOL Eine andere Sprache, die in Teilen kompatibel ist. Ein Superset wäre zu 100% kompatibel, aber dann müsste man auch diverse Altlasten von C mitschleppen (die man dort eigentlich auch gern raus hätte, aber Kompatibilität und so). Aber du kennst die Sprachen, über die du dich lang und breit auslässt halt nicht, weder die eine, noch die andere. S. B. schrieb: > vielleicht, wenn da nicht dieses zufällige > böse "undefined behaviour" der anderen Compiler wäre Nochmal, zum mitschreiben: Es gibt im Standard (insbesondere C, C++ ist da wesentlich strenger) Dinge, die sind "undefined", andere "implementation defined". Dort darf (!) der Compiler machen was er will, deshalb vermeidet man diese Dinge halt. Das hat nix mit Zufall zu tun. Wer fehlerhaften Input liefert, kriegt halt undefinierten Output, ganz einfach. S. B. schrieb: > warum soll man > das Risiko eingehen, wenn es Visual C++ kostenlos zum Download gibt, > alles reibungslos funktioniert und das zusammen mit Windows aus einem > Guß ist? Reibungslos? MSVC unterstützt nicht mal C99 und C++98 richtig, 20 Jahre nach deren Erscheinen, da hast du deinen Grund. S. B. schrieb: > Serverbereich weiß ich nicht, da hat Linux wohl etwas Boden gut gemacht? > - aber ansonsten gilt das Marktführerprinzip, also Android vor IOS, > Microsoft vor Apple, usw. Nochmal, was hat das mit Windows oder Linux zu tun? S. B. schrieb: > hab ich doch schon x-mal geschrieben: Visual C++ > Microsoft ist Marktführer, warum soll man sich dann auf Experimente mit > anderen Compilern einlassen - nur, weil die 5% besser sind? MSVC ist kein toller Compiler, sondern der letzte Schrott, und wird außerhalb vom Klickbuntbereich auch nicht verwendet. S. B. schrieb: > Okay, in Deinem Embedded Bereich kannst Du das natürlich gerne machen So ziemlich jeder, der vernünftig ist, verwendet GCC oder Clang, auch Projekte die aus historischen Gründen bei MSVC hängen, wechslen immer öfter, nicht nur bei C++, auch bei C. Das wüsstest du, wärst du vom Fach. S. B. schrieb: > und Du scheinst ja auch quasi Dein eigener Chefe zu sein. Nö, lediglich kompetent genug die Werkzeuge vorzugeben. S. B. schrieb: > Firefox Firefox ist schon lang kein Marktführer mehr. S. B. schrieb: > Du kannst natürlich gern was anderes wählen, aber im Prinzip dann > berufliches Abseits, falls Du aus unerfindlichen Gründen doch nochmal > wechseln mußt. Du meinst so wie du? Nein, die Angst hab ich nicht. Man stellt sich ja breit auf und entwickelt sich weiter, deswegen bleibt man ja nicht aus purer Angst vor neuem bei C. S. B. schrieb: > Achso, Sicherheit ist ja in C++ ganz groß geschrieben (eines Deiner > TOP-Argumente zu Anfang des Threads); > gab's da nicht mal einen Ariane 5 Absturz? > Dein Englisch ist ja besser, welche Programmiersprache haben die da > verwendet? Hört sich stark nach C++ an, aber mein Englisch ist nicht so > gut, vielleicht täusche ich mich ja: > http://computer-programming-forum.com/44-ada/626c282aa05b4b23-15.htm Interessant, was genau willst du der Welt damit mitteilen? Dass du ernsthaft denkst, irgendeine Sprache könnte Fehler zu 100% verhindern? Und wieder beweist du durch deine Polemik völlige Ahnungslosigkeit. Und wieder konntest du deine Behauptungen nicht untermauern. Nicht mal konntest du erklären, warum C++ so doll viel Speicher brauchen soll.
> Tja, und ich hab dich nun schon 100 Mal gefragt, wo dein Problem damit > ist, dass es bei ihm zufällig funktioniert? das klang vorher ganz anders; aber gut, falscher Code beim TO und der Rest dann alles reiner Zufall - genau das bezweifle ich. > CodeBlocks ist ja nicht mal ein Compiler sondern eine IDE, wir wissen > also genau gar nix über sein Setup, für dich ist aber C Schrott > deswegen. Na, irgendeinen Compiler scheint bei CodeBlocks eingestellt gewesen zu sein und das wäre ja mal interessant zu erfahren welcher? GCC ist angeblich bei CodeBlocks sogar voreingestellt. > für dich ist aber C Schrott deswegen. wieder eine miese Unterstellung! Es geht mir hier lediglich um die Frage, warum das beim TO ohne string.h läuft. Für Dich ist im Zweifel 'alles' illegal code, undefined behaviour, etc. - bißchen sehr einfach! > Nochmal, zum mitschreiben: Es gibt im Standard (insbesondere C, C++ ist > da wesentlich strenger) Dinge, die sind "undefined", andere > "implementation defined". Dort darf (!) der Compiler machen was er will, > deshalb vermeidet man diese Dinge halt. Genau deswegen wäre es ja mal sehr interessant zu wissen, welchen Compiler der TO unter CodeBlocks überhaupt verwendet ?! Oder? Vielleicht meldet er sich ja nochmal. Bei mir: gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0 > Wo genau soll ich das geschrieben haben? Dein Zitat: "Im Zweifel ist aber C++ dann doch die bessere Wahl. Sicherheit, und Geschwindigkeit." Also indirekt eine Aufforderung besser gleich in C++ zu programmieren, obwohl das Miniprogramm in C nun wirklich nicht das Programmierproblem war und ist. Und an diesen Blödsinn hat sich der ganze Streit entbrannt - für nix! Teilweise muß ich mich korrigieren - auch die Runtime der C++ Programme scheint bei "guter" C++ Programmierung zu stimmen bzw. sogar noch besser zu sein - das geht aber nur bei wirklich guter Optimierung, was der C++ Compiler wohl mittlerweile auch schafft! https://www.quora.com/Is-C++-slower-than-C-If-yes-is-the-difference-significant Den Link hättest Du ja bringen können, hast Du aber nicht! Komischerweise kommt in diesem Endlos-Link dann auch noch jemand zu dem Ergebnis, daß der Java-Compiler am Ende sogar noch besser ist was Optimierung anbelangt im Vergleich zu C++ .... und dafür gibt's dann :-):-):-) von mir. Du siehst, so ganz eindeutig scheint das alles nicht zu sein! > Dass du ernsthaft denkst, irgendeine Sprache könnte Fehler zu 100% > verhindern? Für Dich scheint C++ das A&O für alles und nichts zu sein und das ist es eben nicht - Sicherheit wohl eher mäßig, sonst hätte es den Absturz nicht gegeben. Was nicht sein kann, passiert auch schon mal - Zufall eben, der falsche C++ Compiler bzw. Compilereinstellung war aber sicher nicht Schuld :-) Du hast mit C++ weitaus mehr Möglichkeiten und kannst damit auch mehr ruinieren, ohne daß es einer sofort merkt. Wie gesagt, die Compilervariante des TO würde mich mal interessieren (so er sich denn nochmal meldet) .... sonst führt das hier zu nix außer blabla.
Troll around the clock schrieb: > Dein Zitat: > "Im Zweifel ist aber C++ dann doch die bessere Wahl. Sicherheit, und > Geschwindigkeit." > > Also indirekt eine Aufforderung besser gleich in C++ zu programmieren, > obwohl das Miniprogramm in C nun wirklich nicht das Programmierproblem > war und ist. Dein Textverständnis ist ähnlich gut wie deine Programmierkünste. Troll around the clock schrieb: > Und an diesen Blödsinn hat sich der ganze Streit entbrannt - für nix! Nö, weil du ständig mit Kacke und unbelegten Behauptungen um dich wirfst. Troll around the clock schrieb: > Teilweise muß ich mich korrigieren - auch die Runtime der C++ Programme > scheint bei "guter" C++ Programmierung zu stimmen bzw. sogar noch besser > zu sein Ach ne, jetzt auf einmal? Troll around the clock schrieb: > https://www.quora.com/Is-C++-slower-than-C-If-yes-is-the-difference-significant > Den Link hättest Du ja bringen können, hast Du aber nicht! Oh, ich bin aber ganz böse, ich hab den Link nicht gebracht! Troll around the clock schrieb: > Komischerweise kommt in diesem Endlos-Link dann auch noch jemand zu dem > Ergebnis, daß der Java-Compiler am Ende sogar noch besser ist was > Optimierung anbelangt im Vergleich zu C++ .... und dafür gibt's dann > :-):-):-) von mir. > Du siehst, so ganz eindeutig scheint das alles nicht zu sein! Man kann natürlich für jeden Compiler ein Programm schreiben, das schlechter performt als auf einem anderen. Troll around the clock schrieb: > Für Dich scheint C++ das A&O für alles und nichts zu sein Dass du es noch 10 mal wiederholst, macht es auch nicht wahrer. Warum verdammt nochmal versuchst du eigentlich, mir zu erklären was deiner Ansicht nach meine Meinung sein soll? Troll around the clock schrieb: > Sicherheit wohl eher mäßig, sonst hätte es den Absturz > nicht gegeben. Blödheit und mangelnde Tests kann keine Programmiersprache verhindern. Aber dass das für dich ein Zeichen mäßiger Sicherheit ist, sagt ja eh schon wieder alles über deine Kompetenz. Troll around the clock schrieb: > Was nicht sein kann, passiert auch schon mal - Zufall eben, Richtig, deshalb gibts auch Tests, die kann keine Programmiersprache der Welt ersetzen, auch wenn du das zu glauben scheinst. Troll around the clock schrieb: > der falsche > C++ Compiler bzw. Compilereinstellung war aber sicher nicht Schuld :-) Wäre auch absurd, das anzunehmen. Troll around the clock schrieb: > Du hast mit C++ weitaus mehr Möglichkeiten und kannst damit auch mehr > ruinieren, ohne daß es einer sofort merkt. Juhu, schon wieder eine unbelegte Behauptung mehr. Poste doch mal ein Beispiel, vielleicht klappt es ja diesmal, ohne dass du wieder tagelang mit Kacke um dich werfen musst, bevor du feststellst dass du doch unrecht hattest. Ich bin hier raus, deine Selbstüberschätzung gepaart mit absoluter Fachunkenntnis wird mir zu blöd.
> Blödheit und mangelnde Tests kann keine Programmiersprache verhindern. > Aber dass das für dich ein Zeichen mäßiger Sicherheit ist, sagt ja eh > schon wieder alles über deine Kompetenz. So gesehen ist natürlich alles sicher, wenn das übliche Prozedere irgendwie absolviert wurde und Fragen unerwünscht sind :-> Aber so weit kannst Du vor lauter Kompetenz gar nicht mehr denken! Dafür reicht es eben nicht, für Anglizismen, Nachhaltigkeit und Schlagwörter dafür reicht es. Glaubst Du wirklich ein Milliardenprogramm läuft ohne Software-Tests ab? "Die Sicherheit" von C++ wird in dem Link angezweifelt! Da wird tatsächlich behauptet, daß es mit einer anderen Programmiersprache gar nicht erst passiert wäre - soviel zur C++ Sicherheit! Aber das sind natürlich so wie meine Wenigkeit alles nur inkompetente Idioten und wie IMMER hast nur DU recht, bist eben der Superguru! > Wäre auch absurd, das anzunehmen. LOL, aber bei CodeBlocks und dem dort eingebundenen C Compiler spielt das auf einmal doch wieder eine entscheidende Rolle? Der produziert auf einmal per Zufall fehlerhaften Code? Fehlerhafter Code, Compilereinstellungen sind Schuld, welche genau spielt keine Rolle, macht nix, alles nur reiner Zufall, 'undefined' eben. Das ist eine schöne Erklärung, wenn man nicht mehr weiter weiß. > Richtig, deshalb gibts auch Tests, die kann keine Programmiersprache der > Welt ersetzen, auch wenn du das zu glauben scheinst. eigentlich noch schlimmmer !!! - dann hätten die Software-Tests beim Arianeprogramm genau diese Fehler zu Tage fördern müssen! Natürlich alles Idioten die Programmierer und die Software-Tester ebenfalls ?! So muß es wohl gewesen sein? Nur Gurus wie Dir kann sowas natürlich nie passieren. Nur gut, daß Sie beim Militär ADA verwenden, ansonsten gute Nacht! > Juhu, schon wieder eine unbelegte Behauptung mehr. Poste doch mal ein > Beispiel,... mach das zur Abwechslung doch mal selber, Du bist doch der C++ Experte, ich nicht. Außerdem liest Du meine Links nur oberflächlich; Egal was ich bringen würde, es wäre IMMER inkompetent, usw., Futter für den Oberguru, damit es dann Anglizismen hagelt? Nein, Danke! Weiterhin komme ich gar nicht mehr nach auf Deine ganzen zum Teil falschen Darstellungen zu antworten! Es geht schon rein zeitlich nicht! Auf den eigentlichen Sachverhalt gehst Du sowieso nicht ein bzw. mit "undefined" hat sich die Frage für Dich erledigt. > Ich bin hier raus ich auch - jemand, der mit Anglizismen nur so um sich wirft, alles auf 'undefined behaviour',fehlerhaften Code und Zufälle aller Art zurückführt, den das Compilerverhalten einen Dreck interessiert, der den Ariane Absturz nur auf mangelnde Tests oder auch totale Doofheit der dortigen Programmierer und Software-Tester zurückführt, der den Visual C++ Compiler wesentlich schlechter als einen Freeware Compiler einstuft - was soll man da noch sagen ??? Du hast IMMER recht, könnten wir doch alle Deinen göttlichen Status erreichen! - jetzt zufrieden ?! Aber es gibt auch Teilnehmer (nicht nur ich), die das anders sehen und der Sache gern auf den Grund gehen möchten; ob Dir das nun paßt oder nicht! Dann mußt Du eben mal Beispiele und Argumente liefern, die das eindeutig belegen - was Du ja nicht machst. Zum Abschluß noch ein kleines Schmankele zur Deiner Lieblingssprache JAVA, die ja so mies ist im Vergleich zu C++ https://www.heise.de/newsticker/meldung/SAP-setzt-auf-Java-51972.html Na ja, SAP ist für Dich wahrscheinlich eine genauso inkompetente Firma wie die Programmiersprache Java selbst ?! Echt traurig solche Leute wie Du. Überall nur Inkompetenz & Idioten, mal Dir weiter Deine Welt!
Beitrag #5714679 wurde von einem Moderator gelöscht.
Beitrag #5714718 wurde von einem Moderator gelöscht.
Wieder so viele Personalpronomen... Darüber hinaus gilt im gesamten Forum, also auch hier die simple Regel: Nur 1 Nutzername pro Thread! Siehe die Nutzungsbedingungen
Thread beobachten
Seitenaufteilung abschalten