Hallo,
ich suche einen freien C-Compiler mit einer super simplen IDE für
Windows 10. Mir ist egal ob 32 oder 64bit, ich brauche kein Debugging
oder sonst was. Ich möchte zum konfigurieren kein Tutorial Video
anschauen müssen, nicht stundenlang Eclipse konfigurieren,
Umgebungsvariablen setzen, keine eigenen Make-Files schreiben oder sonst
was. Out of the Box, benötigte Dateien im Projektbaum hinzufügen, Play
drücken und fertig. Wie es eben mit Python funktioniert ;)
Gibt es das? Wenn ja was?
Danke!
QtCreator oder VisualStudio können beides - für ne Commandline App gibts
auch wenig Aufwand bei beiden.
Allerdings ist C/C++-Programmierung bzw. Programmierung an sich mit der
Frage der SW-Inbetriebnahme verbunden - das gibts auch bei Python.
Musste richtige Python-Version haben, per Pip die Pakete installiert
haben usw. usf - ganz für lau ist das auch nicht, zumindest nicht, wenn
die software weitergegeben werden soll
Hallo,
Michael L schrieb:> ich suche einen freien C-Compiler mit einer super simplen IDE für> Windows 10.
- lcc
Ist uralt, 32-Bit, hat eine einfache IDE und ist für einfache Sachen ok.
- Code::Blocks
aktuelle IDE, gcc wird mitinstalliert, zwar komplex, wenn man sich auf
die Grundfunktionen beschränkt hat man nach einer Minuten ein
Grundgerüst stehen.
- Editor, gcc-Aufruf über ein "Universal-makefile"
rhf
nur gibt es bei Codeblocks immer wieder schöne Überraschungen bei der
Installation.
Anleitungen sind oft im Netz nicht mehr aktuell.
Kann ziemlich nerv zermürbend sein.
Aktuell scheint er aber recht einfach zu funktionieren, vor 8 Monaten
oder so, lief nichts vernünftig und keine Anleitung passte auf die
Version.
Daher eher Turbo C z.B.
oder aktueller MS Visual C bzw VisualStudio
Nicht konfigurieren etc. trifft auc Codeblocks auf keinen Fall zu, da
noch minigw bzw gcc etc installiert werden müssen und dort eingetragen
werden etc
Pelles C wurde ja auch schon genannt
starte WSL2, schreibe deinen Quelltext mit nano und kompiliere mit 'cc
main.c'.
C hat eben kein Programmiersystem im Standard, gerade das ist ja ein
Ansatz von Python und Co das einfacher zu machen. Spätestens wenn es um
das Einbinden anderer Bibliotheken geht.
Hatte mir gerade mal Pelles C angesehen.
Nein, das ist nicht was er sucht.
Auf Anhieb läuft es bei mir nicht, meldet immer nur einen Fehler beim
Kompilieren, aber nicht mal eine brauchbare Meldung, was sein Problem
ist
Also doch eher Visual Studio
UPDATE: DEV C++ sieht gut aus. Und es funktioniert auch auf anhieb, kann
ich also auch empfehlen
Kinderlandverschicker schrieb:> BorlandC in einer Dos-Box?
Brrrrrr.
Peter K. schrieb:> PDATE: DEV C++ sieht gut aus. Und es funktioniert auch auf anhieb, kann> ich also auch empfehlen
Das sah schon vor 20 Jahren gut aus.
Peter K. schrieb:> Nicht konfigurieren etc. trifft auc Codeblocks auf keinen Fall zu, da> noch minigw bzw gcc etc installiert werden müssen
... was aber soooo schlimm nicht ist.
Ich wäre auch für CodeBlocks. Das ist einfach "smart" :-)
Peter K. schrieb:> Und wieso gibt es hier keinen Fehler?!> printf("Bitte gebe Deinen Namen ein: ");
Weil ein Compiler nicht den korrekten Gebrauch des Imperativs prüft!
Bald heißt es tatsächlich noch: Fresse oder Sterbe, statt Friss oder
Stirb.
Peter K. schrieb:> Und wieso gibt es hier keinen Fehler?!> #include <stdio.h>> const char a['u'];
Weil das, so bizarr es klingen mag, kein Fehler ist. 'u' hat einen
numerischen Wert, und das Array wird mit entsprechend vielen Elementen
dimensioniert.
Der Compiler sieht an dieser Stelle kein 'u', sondern die numerische
Repräsentation dieses Zeichens in der von Dir beim Erstellen des
Quelltextes verwendeten Zeichencodierung - also mit sehr hoher
Wahrscheinlichkeit ASCII. Und da ist 'u' gleichbedeutend mit 117.
loeti2 schrieb:> Und das return 0; in main ist nicht erforderlich lt. Standard.
Und das gilt tatsächlich ausschließlich für main(). Alle anderen
Funktionen, deren Return-Typ nicht void ist, müssen explizit einen Wert
zurückgeben, sonst ist das Verhalten undefiniert.
DerEinzigeBernd schrieb:> Der Compiler sieht an dieser Stelle kein 'u', sondern die numerische> Repräsentation dieses Zeichens in der von Dir beim Erstellen des> Quelltextes verwendeten Zeichencodierung - also mit sehr hoher> Wahrscheinlichkeit ASCII. Und da ist 'u' gleichbedeutend mit 117.
Ja, denn anders als viele andere Sprachen unterscheidet C nicht zwischen
Zeichen und Zahlenwerten. 117 ist in C vom Typ int, genau wie 'u', und
so einen int kann man für die Größenangabe eines Arrays nehmen.
Rolf M. schrieb:> Und das gilt tatsächlich ausschließlich für main(). Alle anderen> Funktionen, deren Return-Typ nicht void ist, müssen explizit einen Wert> zurückgeben, sonst ist das Verhalten undefiniert.
Eben, main() unterliegt einer Ausnahme. Ein fehlendes Return ist hier
gleichbedeutend mit
1
return0;
Peter K. soll das mal mit einer anderen Funktion als main() testen. Ich
bin mir sicher, dass er dann auch eine entsprechende Meldung vom
Compiler bekommt.
DerEinzigeBernd schrieb:> Weil das, so bizarr es klingen mag, kein Fehler ist. 'u' hat einen> numerischen Wert, und das Array wird mit entsprechend vielen Elementen> dimensioniert.
Neinj, das mit dem u ist schon klar,
aber es ist als const definiert und dennoch lese ich mit scanf Werte
ein.
Auch wenn man sie vorher festlegt, sin die beliebig veränderbar!??!
Thomas G. schrieb:> Weil ein Compiler nicht den korrekten Gebrauch des Imperativs prüft!
schade, Du hast nicht mal verstanden um was es eigentlich ging, und
laberst wieder rum.
Ein Troll also
Peter K. schrieb:> aber es ist als const definiert und dennoch lese ich mit scanf Werte> ein.
Ein anständiger Compiler gibt da eine Warnung aus.
1
main.c: In function ‘main’:
2
main.c:18:5: warning: writing into constant object (argument 2) [-Wformat=]
3
18 | scanf("%10s",a);
4
| ^~~~~
Abgesehen davon sollte man NIE die Funktion scanf verwenden. Absolut
niemals. Auch nicht, um damit programmieren zu lernen. Diese Funktion
ist essentiell kaputt und gehört aus dem C-Standard verbannt.
Peter K. schrieb:> Auch wenn man sie vorher festlegt, sin die beliebig veränderbar!??!
Ja, auf gewissen Umwegen kann man auch Variablen, die eigentlich const
sind, beschreiben, darf man aber eigentlich nicht. Es muss auch nicht
zwingend das gewünschte Ergebnis rauskommen. Bei mir stürzt das Programm
in der Zeile, die den Schreibzugriff versucht, ab.
Léo schrieb:> Abgesehen davon sollte man NIE die Funktion scanf verwenden. Absolut> niemals.
Das wurde ihm schon in einem anderen Thread nahegelegt, will er aber
nicht hören, weil er unbedingt scanf will (warum auch immer…).
Peter K. schrieb:> Thomas G. schrieb:>> Weil ein Compiler nicht den korrekten Gebrauch des Imperativs prüft!>> schade, Du hast nicht mal verstanden um was es eigentlich ging, und> laberst wieder rum.> Ein Troll also
Wieder?
Ich wüsste nicht dass wir schon einmal das "Vergnügen" miteinander
hatten. An so jemanden würde ich mich erinnern. Dann geh halt zum Lachen
in den Keller und "nehme" deinen Humor mit!