Halialo. Ich habe ein kleines/großes Problem und zwar bin ich im Moment in der 12 Klasse und fange demnächst mein 3 Semester (Schülerstudium) in Mathematik an der TUM an und in diesem Semester steht programmieren mittels C und Python auf dem Plan. Mit Python bin ich sehr vertraut und mit C möchte ich mich nun einmal etwas ausprobieren, nur leider bekomme ich es nicht zum laufen und die bisherigen Erklärungen haben mir wenig geholfen. Da mein System mit dem neusten Windows läuft und C nur unter Linux ohne Extrawurst läuft, bräuchte ich mal ein paar Tipps, mit welchen Programmen ich dies am besten zum Laufen bringe. Es sollte schon eine schöne Umgebung sein. Ich hoffe ihr könnt mir da ein paar Ratschläge geben. Liebe Grüße Lucas
Welche(n) Compiler hast du denn zu installieren versucht? Und wo hat's gehakt? Visual Studio Express und Cygwin (~Linux für Windows, inklusive gcc und allem Pipapo) sind doch eigentlich recht geschmeidig in der Installation. Aber nun, wenn das gar nicht klappt dann kannst du ja mal die Liste hier durchprobieren: https://www.thefreecountry.com/compilers/cpp.shtml
Vielleicht gefaellt Dir das zum Einstieg: http://www.tutorialspoint.com/compile_c_online.php Hier ist die Homepage mit mehr als 75 Programmiersprachen https://www.tutorialspoint.com/codingground.htm
Lucas schrieb: > und C nur unter Linux ohne Extrawurst läuft Wer sagt denn sowas? Versuchs mal mit Code::blocks oder DEV C++ oder Pelles C oder eine andere IDE, sie du mit der Suchmaschine deiner Wahl findest.
Du brauchst einen C-Compiler und einen Editor. THEORETISCH ginge das mit Notepad und minGW oder so, aber das ist nicht benutzerfreundlich. Sehr einfach ist der hier: https://www.bloodshed.net/devcpp.html Ich sollte erwähnen, dass ich damit Probleme hatte. Daher verwende ich Code::Blocks Das findet man hier: http://www.codeblocks.org/ Das ist nur eine IDE, also so was ähnliches wie ein besserer Texteditor (bitte nicht hauen!). Man benötigt zusätzlich den Compiler, den muss man gesondert installieren. Ich verwende minGW: http://wiki.codeblocks.org/index.php/MinGW_installation Dann kannst du natürlich noch Microsoft visual studio benutzen. Das findet man hier: https://visualstudio.microsoft.com/ Man braucht die "Community edition", die ist kostenlos. Einfach zu installieren und benutzen ist nichts davon. Die Installation von Code::Blocks und minGW hat meine Geduld arg beansprucht. Alle 3 Programme sind übrigens kostenlos.
Danke an alle, ich habe es mit Code Blocks zum laufen gebracht, jedenfalls denke ich das:) C-Anfänger von der Übelsten Sorte schrieb: > Daher verwende ich Code::Blocks > Das findet man hier: > http://www.codeblocks.org/ > Das ist nur eine IDE, also so was ähnliches wie ein besserer Texteditor > (bitte nicht hauen!). Man benötigt zusätzlich den Compiler, den muss man > gesondert installieren. Ich verwende minGW: > http://wiki.codeblocks.org/index.php/MinGW_installation Bei mir war dies irgendwie alles in einer Datei, jedenfalls funktioniert "hello world".
C-Anfänger von der Übelsten Sorte schrieb: > Man benötigt zusätzlich den Compiler, den muss man > gesondert installieren muss man mit http://sourceforge.net/projects/codeblocks/files/Binaries/17.12/Windows/codeblocks-17.12mingw-setup.exe nicht machen, da ist alles drin
für schnelle Tests gibt es auch Online Compiler, da braucht man nix installieren. Frag Google, ein Treffer ist zB https://www.jdoodle.com/c-online-compiler https://www.jdoodle.com/ wenn man noch andere Sprachen sprechen möchte.
fast schrieb: > muss man mit > http://sourceforge.net/projects/codeblocks/files/Binaries/17.12/Windows/codeblocks-17.12mingw-setup.exe > nicht machen, da ist alles drin Danke, das kann mir in Zukunft eine Menge Arbeit sparen! Kannte ich nicht.
Achte darauf, dass du .c Dateien anlegst, damit der Compiler auch im C-Modus arbeitet.
Es gab früher von Borland "Turbo C". Das war IDE, Debugger und Compiler/Linker in einem und sehr bequem. Lief quasi auf Anhieb und war rattenschnell. Auch das Hilfesystem war gleich mit integriert und super. Wenn es nur ums C Programmieren geht, wäre das immer noch eine Alternative, wenn auch schon über 20 Jahre alt. "https://de.wikipedia.org/wiki/Turbo_C"; Falls Du etwas mehr Zeit im Vorwege investieren möchtest/kannst, so empfehle ich den Aufwand des Microsoft Visual Studios. Damit bist Du zukünftig gut aufgestellt und die Umgebung kann nicht nur C sondern viele andere Sprachen auch. ... und ich liebe die IDE/Debugger, ist wirklich gut. Das Visual Studio 2017 ist schon recht umfangreich, das kann quasi alles. Ähnlich gut - jedenfalls fürs C Progammieren - sind die alten IDEs, z.B. das Visual Studio 2008, auch da war die IDE und der Debugger schon sehr gut. Also: * Wenn es total einfach gehen soll und Aktualiät nicht so wichtig ist: Turbo-C. * Vielleicht hast Du einen Lehrer oder Freund, der sich mit Visual Studio auskennt. Mit einer Stunde Einführung, klappt es bestimmt.
Ich habe damals Quincy 2005 benutzt. http://www.codecutter.net/tools/quincy/ Mit Win7 hat es noch funktioniert. Win10 weiß ich nicht. Download hat nur 18MB. Es ist alles vorhanden, von C/C++ bis zum GUI Builder. Die gleichen Projekte können dann sogar in Fluid/Fltk für Linux übernommen werden. Es sind auch sehr viele Beispiele vorhanden. Wenn du dir das erst einmal ansehen möchtest: https://www.youtube.com/results?search_query=quincy2005
Georg W. schrieb: > Wenn es nur ums C Programmieren geht, wäre das immer noch eine > Alternative Es sei denn, man möchte Programme auch laufen lassen. Unter 64-Bit-Windows laufen keine DOS-Programme mehr, da braucht es dann einen Emulator wie DOSBox. Und DOS-Programme kannten keine Dateinamen, sondern nur 8.3-Kürzel, was die Nutzung doch etwas ... unkomfortabel macht, wenn man mit Dateien hantieren will. Mit Pelles C ist man recht sicher besser bedient, wenn man sich nicht das Visual-Studio-Monster antun will. Nicht, daß ich Turbo-C generell mies finden würde, vor bald 30 Jahren war das mein erster Kontakt zu einem vernünftigen Compiler mit vor allem erstklassiger deutschsprachiger(!) Dokumentation (die nicht einfach aus dem englischen übersetzt, sondern von Arne Schäpers komplett neu geschrieben wurde). Das war schon schick, unter den Einschränkungen, die man damals halt so hatte (keine Dateinamen, 80x25-Textbildschirme, Disketten und winzige Festplättchen ...)
Einen gcc bekommt man unter Windows am einfachsten über msys2. Einfach installieren. Dazu dann einen Editor der Wahl. Alternativ nativ und mit IDE per Visual Studio, das aber bei bei C doch etwas schwächelt. Oliver
:
Bearbeitet durch User
Oder QtCreator (IDE) über den Installer auf https://qt.io installieren, bringt einen GCC (Mingw) mit. Das ganze QtFramework kann man ja abwählen.
Sofern eine Kommandozeile reicht lässt sich unter Windows 10 auch einfach ein Linux Userspace installieren (Windows Subsystem for Linux, dann hat man z.B: ein effektives Ubuntu 18.04 direkt in Windows). Dort dann einfach den Compiler z.B. via apt installieren. Das ganze läuft meiner Erfahrung nach mitlerweile sehr gut mit dem gcc und clang. Serielle Geräte sind dort auch verfügbar, sodass z.B. avrdude direkt läuft.
Rufus Τ. F. schrieb: > Und DOS-Programme kannten keine Dateinamen Womit wurden denn damals die Files bezeichnet? Was du meinst: "...keine langen Dateinamen". Das Schema 8.3 waren die Dateinamen.
npn schrieb: > Womit wurden denn damals die Files bezeichnet? Wenn Du nur ein paar Wörter länger meinen Text gelesen hättest, statt Deinen Beitrag zu schreiben, hättest Du Deine Frage gar nicht erst stellen müssen.
Rufus Τ. F. schrieb: > npn schrieb: >> Womit wurden denn damals die Files bezeichnet? > > Wenn Du nur ein paar Wörter länger meinen Text gelesen hättest, statt > Deinen Beitrag zu schreiben, hättest Du Deine Frage gar nicht erst > stellen müssen. Auch wenn der Ton die Musik macht, und hier vermutlich einen Missklang erzeugt hat, liegt er nicht völlig daneben. Es war im Desktop-Bereich eine Zeitlang verbreitet, mit einem BBASIC zu arbeiten, das nzr Variablennamen zuließ, die aus genau einem Buchstaben A..Z sowie höchstens einer Ziffer 0..9 bestand. Damit vernünftig zu programmieren dürfte wesentlich anstrengender gewesen sein, als sich brauchbare Dateinamen im CP/M-Muster auszudenken. Trotzdem wäre es verfehlt, zu behaupten, dieses BASIC hätte keine Variablennamen zugelassen, sondern nur Kürzel. Es mag heute seltsam klingen, aber ich habe in den Jahren mit CP/M und MS-DOS kaum etwas so wenig vermisst, wie LFN.
Percy N. schrieb: > Trotzdem wäre es verfehlt, zu behaupten, dieses BASIC hätte keine > Variablennamen zugelassen, sondern nur Kürzel. Nein, das ist nicht verfehlt, sondern eine offenkundige Tatsache. A0 ist kein Variablenname. Dann kann man auch einfach eine Speicheradresse direkt verwenden und auf das Konzept von Namen verzichten.
Rufus Τ. F. schrieb: > Percy N. schrieb: >> Trotzdem wäre es verfehlt, zu behaupten, dieses BASIC hätte keine >> Variablennamen zugelassen, sondern nur Kürzel. > > Nein, das ist nicht verfehlt, sondern eine offenkundige Tatsache. A0 ist > kein Variablenname. Dann kann man auch einfach eine Speicheradresse > direkt verwenden und auf das Konzept von Namen verzichten. Das hätte wiederum den Quelltext aufgebläht, was zu vermeiden war. Und E4 konnte E4 bleiben, auch wenn E2 wegfiel.
Rufus Τ. F. schrieb: > Percy N. schrieb: >> Trotzdem wäre es verfehlt, zu behaupten, dieses BASIC hätte keine >> Variablennamen zugelassen, sondern nur Kürzel. > > Nein, das ist nicht verfehlt, sondern eine offenkundige Tatsache. Es ist jedenfalls ziemlich albern zu behaupten, es habe unter DOS keine Dateinamen gegeben. Die meisten Filesysteme haben Begrenzungen bei der Länge von Dateinamen. Ab wie vielen Zeichen wird es denn für dich ein Name? 10? 50? 100? NTFS unterstützt auch nur "Kürzel" von bis zu 255 Zeichen.
Rolf M. schrieb: > Rufus Τ. F. schrieb: > Percy N. schrieb: > Trotzdem wäre es verfehlt, zu behaupten, dieses BASIC hätte keine > Variablennamen zugelassen, sondern nur Kürzel. > > Nein, das ist nicht verfehlt, sondern eine offenkundige Tatsache. > > Es ist jedenfalls ziemlich albern zu behaupten, es habe unter DOS keine > Dateinamen gegeben. Die meisten Filesysteme haben Begrenzungen bei der > Länge von Dateinamen. Ab wie vielen Zeichen wird es denn für dich ein > Name? 10? 50? 100? NTFS unterstützt auch nur "Kürzel" von bis zu 255 > Zeichen. Wie viele Wörter mit über 255 Zeichen kennst du?
Rolf M. schrieb: > Es ist jedenfalls ziemlich albern zu behaupten, es habe unter DOS keine > Dateinamen gegeben. BRFTNTBR.TXT statt "Brief Tante Berta" HVOKT18B.TXT statt "Hausverwaltung Oktober 18 Beschwerde" KNDIGPSS.TXT statt "Kündigung Mietvertrag Passauer Straße" ALTMDSGN.EXE statt "Altium Designer" Nein, DOS kannte keine Dateinamen, sondern nur 8.3-Kürzel. Die Einführug von Dateinamen, die mit Windows NT 1993 und für den "Mainstream" mit Windows 95 stattfand, war ein wichtiger und bedeutsamer Schritt. Andere Betriebssysteme kannten auch schon lange davor Dateinamen, Mac OS beispielsweise erlaubte 32 Zeichen (und interessierte sich nicht für Dateinamenserweiterungen), OS-9/68k erlaubte auch schon 28 Zeichen.
Rufus Τ. F. schrieb: > Nein, DOS kannte keine Dateinamen, sondern nur 8.3-Kürzel. Nur weil eine Beschränkung auf 8.3 existierte, waren das trotzdem Dateinamen. Oder willst du sagen, daß "liste.doc" oder "tage.txt" keine Dateinamen sind? Auch die von dir zitierten Beispiele sind durchaus Dateinamen. Lediglich mit einer Längenbeschränkung.
Rufus Τ. F. schrieb: > Rolf M. schrieb: >> Es ist jedenfalls ziemlich albern zu behaupten, es habe unter DOS keine >> Dateinamen gegeben. > > BRFTNTBR.TXT statt "Brief Tante Berta" > HVOKT18B.TXT statt "Hausverwaltung Oktober 18 Beschwerde" > KNDIGPSS.TXT statt "Kündigung Mietvertrag Passauer Straße" > ALTMDSGN.EXE statt "Altium Designer" > > Ich hatte mal einen Bekannten (Hochschullehrer), der hatte seine Korrespondenz schön strukturiert und unter Windows abgelegt, Dutzende Verzeichnisse, und in jedem davon BRIEF1.DOC, BRIEF2.DOC ... Wer vor Windows 95 nicht auf sprechende Dateinamen verzichten mochte, der griff zu 4DOS. DESCRIT.ION gehört allerdings zu den Features, die ich infinitesimal selten aktiv verwendet habe. > Nein, DOS kannte keine Dateinamen, sondern nur 8.3-Kürzel. > Wenn's Dich selig macht ...
P.S.: Was unterscheidet eigentlich das "Kürzel" 'BRIEF.TXT' vom Dateinamen 'BRIEF.TXT'?
npn schrieb: > P.S.: Was unterscheidet eigentlich das "Kürzel" > 'BRIEF.TXT' vom Dateinamen 'BRIEF.TXT'? Wenig. Vermutlich kannst Du bei einem richtigen Betriebssystem aber den kompletten Text des Briefes als Dateinamen verwenden und brauchst dann als Inhalt nur noch "BRIEF.TXT" abzuspeichern. So ähnlich wie Cookies halt ...
An den OP: Die Idee, die allseits bekannte und beliebte GCC zu benutzen, kann ich zum Lernen von C nur empfehlen. Dann aber würde ich dir raten, dir gleich ein echtes Linux, ob nun Debian, Arch, Slackware, zu installieren in einer VirtualBox. Wenn du unter Windows programmieren willst, also mehr als nur "Hello, World!\n", dann sind die Visual Studio Build Tools deine Freunde. Falls du keine sehr merkwürdig geschneiderte Custom Version von einem aktuellen Windows auf deinem PC/Laptop hast, brauchst du sonst eigentlich nur noch das passende Windows SDK. Wie schon jemand sagte, ist die Visual Studio IDE nicht gerade überfrachtet mit Features für natives C. Es ist ausgelegt für die Programmierung innerhalb der .NET-Welt. Und da gilt sowas wie "malloc()" als "deprecated" oder einfach pfui -- aus guten Gründen. .NET ist eher wie Python, C ist eher wie Assembler. Hat beides seine Berechtigung, aber wenn du es dir aussuchen kannst, ziehst du doch sicher auch lieber in ein Haus mit Strom, Gas und Abwasserrohr, als erst eine Grube graben zu müssen, oder? ;)
:
Bearbeitet durch User
Visual Studio Code oder Atom mit LLVM als Compiler tut's auch.
ntldr schrieb: > Sofern eine Kommandozeile reicht lässt sich unter Windows 10 auch > einfach ein Linux Userspace installieren (Windows Subsystem for Linux, > dann hat man z.B: ein effektives Ubuntu 18.04 direkt in Windows). Dort > dann einfach den Compiler z.B. via apt installieren. > > Das ganze läuft meiner Erfahrung nach mitlerweile sehr gut mit dem gcc > und clang. Serielle Geräte sind dort auch verfügbar, sodass z.B. avrdude > direkt läuft. das klingt gut? wie macht man das?
Pandora schrieb: > das klingt gut? wie macht man das? Microsoft hat eine Anleitung dafür veröffentlicht: https://docs.microsoft.com/en-us/windows/wsl/install-win10 Die Linux-Distribution (z.B. Debian) installierst du über den Microsoft Store. Das geht relativ schnell. Compiler und so weiter musst du dadrin manuell installieren (sudo apt-get install build-essential).
ntldr schrieb: > Sofern eine Kommandozeile reicht lässt sich unter Windows 10 auch > einfach ein Linux Userspace installieren Um den "Linux *Userspace*" Part nochmal hervorzuheben: Man muss sich bewusst sein, dass es sich dabei nicht um Linux, sondern immernoch um Windows handelt. Es findet keine Emulation des kernels oder dergleichen statt. Die WSL ist immernoch unvollständig, die Implementation sowie die erforderliche init Anwendung Proprietär, und man stolpert immer mal wieder über nen Bug oder etwas, das noch nicht implementiert ist. Zudem funktionieren nur Konsolenanwendungen einigermassen vernünftig. Ein besonders Schwerwiegendes Beispiel, Programme, die mit asan (AddressSanitizer) kompiliert wurden, laufen nicht:
1 | abre2@PSTNABRE201:/mnt/c/Users/abre2$ echo 'int main(){*(int)0=1;}' | gcc -x c -g -Og -fsanitize=address test.c -o test
|
2 | abre2@PSTNABRE201:/mnt/c/Users/abre2$ ./test |
3 | ==49==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) |
4 | ==49==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v |
5 | Aborted (core dumped) |
Unter einem echten Linux würde man von asan angezeigt bekommen, wo was im Program schief lief, aber hier startet es nicht einmal. Noch besser wird es mit Valgrind:
1 | abre2@PSTNABRE201:/mnt/c/Users/abre2$ echo 'int main(){*(int)0=1;}' | gcc -x c -g -Og test.c -o test
|
2 | abre2@PSTNABRE201:/mnt/c/Users/abre2$ ./test |
3 | Segmentation fault (core dumped) |
4 | abre2@PSTNABRE201:/mnt/c/Users/abre2$ valgrind test |
5 | ==65== Memcheck, a memory error detector |
6 | ==65== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. |
7 | ==65== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info |
8 | ==65== Command: test |
9 | ==65== |
10 | ==65== |
11 | ==65== HEAP SUMMARY: |
12 | ==65== in use at exit: 0 bytes in 0 blocks |
13 | ==65== total heap usage: 30 allocs, 30 frees, 3,681 bytes allocated |
14 | ==65== |
15 | ==65== All heap blocks were freed -- no leaks are possible |
16 | ==65== |
17 | ==65== For counts of detected and suppressed errors, rerun with: -v |
18 | ==65== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) |
Bei normaler Ausführung stürzt das Programm ab. Die Nullpointerdereferenz müsste auch Valgrind um die Ohren fliegen und anzeigen, aber nein "0 errors", na wunderbar. Zum Entwickeln ist dass völlig unbrauchbar. Meine Empfehlung ist deshalb, solange man nicht keine andere Wahl hat, nutze ein echtes Linux. Es ist auch noch zu erwähnen, das obwohl die Binaries in Linux Distributionen mit Binärenpacketen statt Quellpacketen linux spezifisch sind (, wobei viele auch auf Freebsd laufen würden), basieren diese auf Quellcode, der meistens auch auf BSD, Hurd, und vielen anderen Unixoiden laufen würde. Es ist also nur diese spezifische Binärform der Programme Linuxspezifisch.
DPA schrieb: > Die WSL ist immernoch unvollständig, die Implementation sowie die > erforderliche init Anwendung Proprietär, und man stolpert immer mal > wieder über nen Bug oder etwas, das noch nicht implementiert ist. Das stimmt. Wobei Microsoft immerhin auf die Nutzer hört und die wichtigsten Features bevorzugt implementiert. Die MSDN-Seiten und -Blogs sind technisch äußerst interessant. Ein guter Einstieg findet sich hier: https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/ Was mich besonders beeindruckt, ist die Ehrlichkeit, mit der auf fehlende oder unvollständige Funktionalität hingewiesen wird (und die Gründe dafür). Das ist man von Microsoft historisch nicht gewohnt. DPA schrieb: > Zudem funktionieren nur Konsolenanwendungen einigermassen vernünftig. Für grafische Anwendungen muss man einen X-Server installieren, aber dann sollte das meiste funktionieren. Grafikbeschleunigung ist noch ein anderes Thema. DPA schrieb: > Zum Entwickeln ist dass völlig unbrauchbar. Um C zu lernen, ist das völlig brauchbar. Um nicht zu sagen, sogar verdammt gut bis exzellent. Und die Grundlagen von Linux lernt man auch. DPA schrieb: > Es ist auch noch zu erwähnen, das obwohl die Binaries in Linux > Distributionen mit Binärenpacketen statt Quellpacketen linux > spezifisch sind (, wobei viele auch auf Freebsd laufen würden), Der Linux-Support in FreeBSD basiert auf der gleichen Idee, nämlich die Syscalls nachzubauen. Trotzdem lässt niemand ein Ubuntu-Userland auf dem FreeBSD-Kernel laufen (Debian/kFreeBSD ist tot). > basieren diese auf Quellcode, der meistens auch auf BSD, Hurd, > und vielen anderen Unixoiden laufen würde. Haha. Guck mal in pkgsrc rein, was da für Patches rumliegen, um Software für Nicht-Linux-Unixoide zu bauen. Oder wieviel Software für Cygwin gepatcht werden muss (und musste). WSL ist bei weitem nicht der goldene Löffel, die I/O-Performance ist mäßig, aber technisch ist das Projekt hochinteressant und zum Lernen von C (und den typischen Unix-Tools) vollkommen angemessen und deutlich einfacher, als parallel noch ein Ubuntu zu installieren. Und das sag ich, der seit Windows Vista privat auf Linux umgestiegen ist.
C "läuft" auch unter Linux nicht ohne Extrawurst, auch hier braucht man erst mal die Binutils und GCC. Auch wenn diese bei einigen Distributionen schon mit dabei sind. Es ist auch ein wenig irreführend, davon zu sprechen, C würde "laufen". Es ist nur eine Programmiersprache, die (stark vereinfacht) von einem Compiler in Maschinenbefehle übersetzt wird. Dazu braucht es im Falle von C noch nicht mal zwingend eine Laufzeitbibliothek. Was am Ende läuft, ist ein Programm, bestehend aus nativen Instruktionen und dabei ist es fast egal, in welcher Sprache es geschrieben wurde. Das "läuft" bei Python etwas anders, daher wohl auch diese Ausdrucksweise. Unter Windows ist zum Programmieren in C eigentlich nur das Windows SDK erforderlich, da es die entsprechenden Header mitbringt. Mit welchem Compiler und Editor man das dann verwendet (und wie gut das funktioniert), bleibt einem am Ende selbst überlassen. Interessant unter Windows 10 ist natürlich die Möglichkeit, Linux-Userspace-Programme nativ (also die "echte" ELF-Binary) ausführen zu können. Man muss sich allerdings im Klaren sein, dass wenn man ein in C geschriebenes Programm (sei es nur das berühmte "Hello, World") mit dem "originalen" GCC dann kompiliert, dies für Linux geschieht und das Programm nicht ohne das entsprechende Subsystem von Windows 10 (WSL) unter Windows läuft. Es ist ja eine ELF-Binary. Wenn man aber die Absicht hat, Windows-Programme zu schreiben, sehe ich keinen Grund, warum man nicht auch die entsprechenden Windows-Tools (MSVCC, Visual Studio Community...) verwenden sollte. Gerade als Anfänger gibt es nichts Einfacheres, als Visual Studio zu installieren, ein neues Visual C++-Konsolenprojekt zu starten, Hello World zu implementieren, mit einem Knopfdruck zu übersetzen und sich das Ergebnis anzuschauen. Wie das ganze dann unter der Haube funktioniert, und welche portableren Alternativen es dazu gibt, kann man sich Stück für Stück im weiteren Verlauf ansehen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.