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
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".
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
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 ...
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? ;)
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
==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.
