Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Entwickler>C am Mac lernen

C am Mac lernen

Matic11.08.1612:41
Hi,

ich wollte in meinem Urlaub gerne etwas C lernen, habe aber hiervon gar keine Ahnung bisher. Soweit ich weiß geht es per xCode am Mac. Habe das nun auch installiert und versucht erste Befehle einzugeben, doch wie sich herausstellt ist C am Mac (vielleicht nur unter xCode) anders als unter DOS. system("PAUSE"); muss zB. durch system("SLEEP"); ersetzt werden und system("Cls") geht wiederum auch nicht.

Daher meine Fragen:
Wie muss xCode eingestellt werden, damit ich C lernen kann, ohne immer die OS X Eigenarten berücksichtigen zu müssen?
Kann man C auch in einem anderen Programm schreiben und lernen, das diese Probleme gar nicht erst auftreten?

Vorab: Ich weiß ich habe keine Ahnung und bitte daher nicht auf den am Boden liegenden zu treten.

Merci und Grüße,
matic
0

Kommentare

Danger11.08.1613:16
Du brauchst die Apple Developer Tools. Die hast du wahrscheinlich bereits installiert, denn Xcode läuft bei dir ja.

Du kannst im Text-Editor deiner Wahl dein Programm eingeben:
#include <stdio.h>

int main(void)
{
    printf("Hallo Welt !\n");
    
    return 0;
}

Sicherst das auf dem Schreibtisch als "hallo.c", startest das Terminal, navigierst zum Schreibtisch und kompilierst das Ganze mit:
gcc -o hallo hallo.c

Anschließend kannst du das Programm mit der Eingabe von
./hallo
ausführen.

Vielleicht hilft das als Einstieg.
0
Embrace11.08.1613:23
http://www.tutorialspoint.com/c_standard_library/c_function_system.htm ()

Die system Funktion gibt den Befehl an das Betriebssystem weiter. Unterschiedliche Systeme benötigen also unterschiedliche Befehle. Ansonsten ist C plattformunabhängig (weitestgehend).
0
Arne 211.08.1613:27
An den Universitäten wird gerne Eclipse genutzt, weil das für Linux, Mac und Windows verfügbar ist. Programme kannst du direkt in Eclipse schreiben, compilieren und ausführen. Als Einstieg meiner Meinung nach gut geeignet.
0
Igor Detlev11.08.1614:16
Matic

Ganz im Ernst: warum C?

Ich habe selbst mal ein bisschen C gelernt, es hat mir geholfen, besser zu verstehen, was wirklich passiert, wenn ein Programm ausgeführt wird, aber heute würde ich dieZeit eher in was anderes investieren.
0
gfhfkgfhfk11.08.1614:35
Matic
Soweit ich weiß geht es per xCode am Mac. Habe das nun auch installiert und versucht erste Befehle einzugeben, doch wie sich herausstellt ist C am Mac (vielleicht nur unter xCode) anders als unter DOS. system("PAUSE"); muss zB. durch system("SLEEP"); ersetzt werden und system("Cls") geht wiederum auch nicht.
Mit den DeveloperTools hast Du die Compiler (gcc) und vieles mehr u.a. Xcode installiert. Du kannst zum Entwickeln einen beliebigen Texteditor nehmen und die Programme auf der Shell übersetzen. Das ist für Anfänger meiner Meinung nach sinnvoller, weil Du Dich dann nicht auch noch mit der IDE (Xcode) auseinandersetzen mußt. Wenn Du die Programme in der Shell ausführst, brauchst Du auch kein PAUSE (ein MS DOS Befehl), die Shell verschwindet nicht, wenn das Programm beendet wurde.
0
Matic11.08.1619:20
Vielen Dank euch allen für die Antworten.

Ich werde es ausprobieren und wünsche euch einen schönen Abend!
0
Weia
Weia12.08.1600:23
Auch noch mein Senf dazu:

1. C ist aus heutiger Sicht die „Mutter aller Sprachen“, und ich kann Dich zu Deiner Entscheidung nur ermutigen! Es gibt nichts Sinnvolleres, wenn man wirklich Programmieren an einem Computer verstehen will. Also lass Dich nicht durch Fragen verunsichern von jemandem, der „selbst mal ein bisschen C gelernt“ gelernt hat. Alleine schon, dass Linux und damit das Open-Source-Betriebssystem schlechthin in C geschrieben ist (und alle Unix-Betriebssysteme ganz generell, OS X inklusive), ist Grund genug für die herausgehobene Stellung von C.

2. Andere haben es schon gesagt, aber der Deutlichkeit halber nochmal: C ist an und für sich so plattformübergreifend, wie eine Sprache nur sein kann, aber mit system() hat Du nun ausgerechnet den einen Befehl erwischt, der C sozusagen „verlässt“ und Befehle des Betriebssystems ausführt. Dass die nicht plattformübergreifend sein können, versteht sich von selbst.

3. „Nerds“ strafen Xcode oft mit Verachtung und empfehlen stattdessen puristisch Texteditoren. Das ist zwar Geschmacksache, aber ich würde Dir Xcode sehr ans Herz legen. Es nimmt Dir erstmal alles, was außerhalb eines fehlerhaften Quellcodes beim Programmieren schiefgehen könnte, mit dem vom Mac gewohnten Komfort ab und lässt Dich außerdem superleicht nach Fehlern suchen („debuggen“).

Öffne einfach ein neues Projekt in Xcode (File → New → Project…) und wähle OS X → Application → Command Line Tool:



Nenne das Programm z.B. ctest und sichere es an einem passenden Platz:



Dann öffnet sich ein Xcode-Fenster, und wie Du sehen wirst, ist das oben vorgeschlagene Hello, World!-Programm bereits als Beispiel eingetragen!

Sobald Du auf die „Play“-Taste links oben in der Werkzeugleiste des Fensters (also das aus iTunes bekannte Dreieck) klickst, wird das Programm automatisch kompiliert und danach auch gleich ausgeführt. Dazu öffnet sich unten in der Mitte des Fensters ein neuer Ausgabebereich, wo Du die Ausgabe Deines Programms (also eben Hello, World!) sehen kannst. Einfacher geht es wirklich nicht:



Und von da an kannst Du nun Schritt für Schritt den Programmcode des Programms erweitern, wieder auf die „Play“-Taste klicken und sehen, was das Programm nun tut.

Willst Du nun das Programm während seiner Ausführung an einer bestimmten Stelle anhalten, um z.B. zu sehen, welche Werte bestimmte Variablen gerade haben, dann klickst Du einfach in die Zeilennummer links neben dem Textbereich, in genau der Zeile, in der das Programm die Ausführung unterbrechen soll:



(Im Falle dieses extrem simplen Programms gibt es allerdings noch gar keine Variablen, deren Werte man inspizieren könnte …)

Direkt über dem Ausgabebereich (also direkt über dem ausgegebenen Hello, World! im Screenshot) findest Du eine zweite Werkzeugleiste; wenn Du auf dessen ähnliche „Play“-Taste klickst, wird die Programmausführung fortgesetzt.

Wenn Du auf den blau ausgefüllten Pfeil links neben der „Play“-Taste klickst, verliert der seine Farbe, und die Funktion zum Debuggen (als zum Unterbrechen des Programms während der Ausführung) ist deaktiviert.

Viel Spaß beim Ausprobieren!
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
Weia
Weia12.08.1600:32
Ach so, und eins noch: Wenn Du anhand irgendwelcher Lehrmaterialien lernst, nimm welche, die sich auf den Mac beziehen oder auf Linux oder auf ein anderes Unix. Mac, Linux und Unix sind im Systemunterbau alle sehr ähnlich, und sind historisch die „Heimat“ von C. DOS ist hingegen ein schlechtes Beispiel …
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
gfhfkgfhfk12.08.1609:44
Weia
3. „Nerds“ strafen Xcode oft mit Verachtung und empfehlen stattdessen puristisch Texteditoren.
Es gibt einen sehr guten Grund weshalb man sich bei C nicht in die Gefangenschaft von Xcode begeben sollte. Xcode ist eine OSX only Entwicklungsumgebung, und da verliert man einen wesentlichen Vorteil von C - die Portabilität. Wenn man eine IDE nutzen will, wäre Eclipse oder Netbeans sinnvoller, das läuft faktisch auf jedem *I*X und Windows.
0
nane
nane12.08.1611:00
Weia
+1*

Sensationell! Das nenne ich mal Information und Hilfe!
„Das Leben ist ein langer Traum, an dessen Ende kein Wecker klingelt.“
0
Weia
Weia12.08.1611:05
gfhfkgfhfk
Es gibt einen sehr guten Grund weshalb man sich bei C nicht in die Gefangenschaft von Xcode begeben sollte. Xcode ist eine OSX only Entwicklungsumgebung, und da verliert man einen wesentlichen Vorteil von C - die Portabilität.
Was hat denn das eine mit dem anderen zu tun?

Dein Satz ist in etwa so sinnvoll wie „Es gibt einen sehr guten Grund weshalb man sich bei Pixelbildern nicht in die Gefangenschaft von Pixelmator begeben sollte. Pixelmator ist ein OSX only Bildeditor, und da verliert man einen wesentlichen Vorteil von Pixelbildern im png-Format - die Portabilität.“

Gefangenschaft – was für ein polemischer und falscher Begriff!

Ich schreibe eine Menge Cross-Platform-C-Code, der auf OS X und auf Linux laufen muss – und zwar immer in Xcode. Wenn’s da läuft, kompiliere ich es auf Linux mit den passenden Makefiles und nehme ggf. erforderliche kleine Anpassungen in einem Linux-Texteditor vor. Geht wunderbar.

Zudem geht es hier ums Lernen – da ist die tatsächliche Cross-Plattform-Kompilation weniger wichtig als eine hilfreiche Entwicklungsumgebung, nehme ich mal an.

(Grundsätzlich ist es für mich ein Ausschlusskriterium, wenn ich erfahre, dass ein Programm cross-platform ist. Ich verwende solche Programme nur im äußersten Notfall, wenn es absolut keine OS-X-only-Alternative gibt. Denn nicht nur sind solche Programme mit Notwendigkeit immer kompromissbehaftet und nicht optimal an OS X angepasst, vor allem verrät der Ansatz auch etwas über die Geisteshaltung seiner Autoren – die Kompromisse und „Pragmatismus“ der optimalen Lösung offenkundig vorziehen. Mit dieser Geisteshaltung will ich so wenig Berührungspunkte wie möglich haben.)
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
Walter Plinge12.08.1611:16
gfhfkgfhfk
Es gibt einen sehr guten Grund weshalb man sich bei C nicht in die Gefangenschaft von Xcode begeben sollte. Xcode ist eine OSX only Entwicklungsumgebung, und da verliert man einen wesentlichen Vorteil von C - die Portabilität. Wenn man eine IDE nutzen will, wäre Eclipse oder Netbeans sinnvoller, das läuft faktisch auf jedem *I*X und Windows.

Sorry, aber das ist doch Unsinn. Man braucht doch keine Cross-Plattform IDE um Cross-Plattform C zu schreiben. Abgesehen davon, dass Cross-Plattform C ohnehin im Quellcode angelegt sein muss (z.B. Threads, Netzwerk, IPC, etc.; - oder man verwendet eine lib wie libuv) kann man aus jeder mir bekannten IDE einfach den C-Quellcode nehmen, und in jede andere IDE stecken. Und in meinen Augen ist tatsächlich die jeweilige Hersteller-IDE auch die auf der jeweiligen Plattform geeignetste, also XCode auf OSX und Visual Studio auf Windows. Eine wirklich gelungene IDE gibt es für Linux meines Erachtens nicht, aber viele zweitbeste Lösungen (vom absturzfreudigen KDevelop bis hin zum Eclipse-Dschungel).
0
Walter Plinge12.08.1611:21
Weia
(Grundsätzlich ist es für mich ein Ausschlusskriterium, wenn ich erfahre, dass ein Programm cross-platform ist. Ich verwende solche Programme nur im äußersten Notfall, wenn es absolut keine OS-X-only-Alternative gibt. Denn nicht nur sind solche Programme mit Notwendigkeit immer kompromissbehaftet und nicht optimal an OS X angepasst, vor allem verrät der Ansatz auch etwas über die Geisteshaltung seiner Autoren – die Kompromisse und „Pragmatismus“ der optimalen Lösung offenkundig vorziehen. Mit dieser Geisteshaltung will ich so wenig Berührungspunkte wie möglich haben.)

Nun ja, das ist schon etwas extrem. Es gibt ja Bibliotheken, die genau das ermöglichen, indem sie für die jeweilige Funktionalität die plattformspezifischen APIs verwenden. Das kann das Entwicklerleben schon erheblich vereinfachen, ohne dass man als Nutzer (oder Entwickler) irgendwelche Kompromisse eingehen muss. Denn ob z.B. uv_thread_create() aus der libuv jetzt pthread_create() unter Linux/OSX oder CreateThread() unter Windows aufruft macht ja wohl keinen Unterschied.
0
Matic12.08.1612:49
Vielen Dank Weia die tollen Beiträge und allen anderen für die kleine Diskussion.

Mir geht es nur darum etwas C zu lernen. Ich werde wohl in den nächsten paar Wochen keine großen Meisterwerke schreiben, aber es macht bisher unglaublich viel Spaß und ein paar kleine Programme sind es schon geworden!

Ich nutze bisher auch xCode, das ist kostenlos und da es gut funktioniert, bin ich zufrieden.
Den system()-Befehl habe ich aus dem Internet. Aber sonst arbeite ich mit dem Buch "C Programmieren von Anfang an" von H. Erlenkötter. Finde das sehr gut bisher.
0
Danger12.08.1613:44
Weia
3. „Nerds“ strafen Xcode oft mit Verachtung und empfehlen stattdessen puristisch Texteditoren. Das ist zwar Geschmacksache, aber ich würde Dir Xcode sehr ans Herz legen. Es nimmt Dir erstmal alles, was außerhalb eines fehlerhaften Quellcodes beim Programmieren schiefgehen könnte, mit dem vom Mac gewohnten Komfort ab und lässt Dich außerdem superleicht nach Fehlern suchen („debuggen“).

Da muss ich meinen extra-scharfen Senf auch zugeben:
Ich mag Xcode, schließlich sitze ich häufig 8 h oder mehr täglich davor. Insofern empfehle ich die Verwendung von Xcode uneingeschränkt.

Allerdings kann ich mich noch gut erinnern, als ich vor Jahren gerade anfing, hat mich Xcode mit seiner Oberfläche brutal überfordert: Zu viele Teilbereiche im Fenster, eine Vielzahl von Knöpfen, etc. Damals war der Interface Builder noch ein eigenständiges Programm, was für mich zusätzliche Komplexität bedeutete.

Daher kann ich es gut nachvollziehen, dass man den Wunsch hat, "nur den reinen Code" zu sehen, um zunächst einmal begreifen zu können, was im Kern von einem selbst geschriebenem Quelltext zu einem ausführbaren Programm führt. Hat man ein basales Verständnis darüber erreicht, kann man den Schritt zu einer IDE tun.

Für mich war dieser Weg damals der richtige.
0
gfhfkgfhfk12.08.1613:45
Weia
Was hat denn das eine mit dem anderen zu tun?
Sehr viel, Xcode (wie jede IDE) erzeugt erhebliche zusätzliche Komplexität. Es geht am Anfang darum die Sprache zu lernen und nicht wie bediene ich diese spezielle IDE. Die Probleme bei IDEs fangen an, wenn man Libraries, spezielle Compilerflags etc. nutzen will. Ferner ist das Wissen über Xcode für andere IDEs wertlos.
Weia
Ich schreibe eine Menge Cross-Platform-C-Code, der auf OS X und auf Linux laufen muss – und zwar immer in Xcode.
Das ist Deine persönliche Präferenz und es spricht auch nichts dagegen, daß Du es so machst.
Weia
Zudem geht es hier ums Lernen – da ist die tatsächliche Cross-Plattform-Kompilation weniger wichtig als eine hilfreiche Entwicklungsumgebung, nehme ich mal an.
Es geht darum die Sprache zu lernen.
Weia
(Grundsätzlich ist es für mich ein Ausschlusskriterium, wenn ich erfahre, dass ein Programm cross-platform ist.
Was hat das mit dem Erlernen von C zu tun? Gar nichts!
0
Weia
Weia12.08.1614:44
Walter Plinge
Nun ja, das ist schon etwas extrem. Es gibt ja Bibliotheken, die genau das ermöglichen, indem sie für die jeweilige Funktionalität die plattformspezifischen APIs verwenden. Das kann das Entwicklerleben schon erheblich vereinfachen, ohne dass man als Nutzer (oder Entwickler) irgendwelche Kompromisse eingehen muss. Denn ob z.B. uv_thread_create() aus der libuv jetzt pthread_create() unter Linux/OSX oder CreateThread() unter Windows aufruft macht ja wohl keinen Unterschied.
Da hast Du bis zu einem gewissen Grad recht, das habe ich nicht spezifisch genug formuliert.

Was aus meiner Perspektive gar nicht geht, und worauf ich mich in erster Linie bezog, sind GUI-Bibliotheken, die Cocoas AppKit emulieren sollen; das funktioniert nie wirklich. Xojo (früher RealBasic) und vor allem Qt sind rote Tücher für mich, von Java-Applikationen ganz zu schweigen.

Was den Code „im Inneren“ betrifft, kann plattformübergreifendes C (oder meinetwegen notfalls auch C++) natürlich wunderbar funktionieren, solange es nicht zu performancekritischen Sachen kommt, wo dann wieder die plattformspezifischen Bibliotheken wie Grand Central Dispatch überlegen sind.

Ich selbst habe viel mit mathematischen Algorithmen zu tun, und natürlich verwende ich da gerne und ausgiebig die vielen guten C-Algorithmen, die es gibt (und die natürlich allesamt plattformübergreifend sind).
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
Weia
Weia12.08.1614:55
gfhfkgfhfk
Weia
Was hat denn das eine mit dem anderen zu tun?
Sehr viel, Xcode (wie jede IDE) erzeugt erhebliche zusätzliche Komplexität. Es geht am Anfang darum die Sprache zu lernen und nicht wie bediene ich diese spezielle IDE.
Aber wer iTunes bedienen kann, kann auch Xcode bedienen … Das ist doch gerade der Punkt: Für Mac-Nutzer entfällt mit Xcode eine besondere Lernkurve …
Die Probleme bei IDEs fangen an, wenn man Libraries, spezielle Compilerflags etc. nutzen will.
Ja, aber das tut man am Anfang eh nicht …
Ferner ist das Wissen über Xcode für andere IDEs wertlos.
Was kümmert mich das, wenn ich als Mac-Nutzer andere IDEs gar nicht verwende?

Das Wissen über andere IDEs ist im übrigen für Xcode wertlos. Als Mac-Nutzer wirst Du aber irgendwann mal ein kleines Cocoa-Programm schreiben wollen. Und dann musst Du Xcode verwenden …
Weia
Zudem geht es hier ums Lernen – da ist die tatsächliche Cross-Plattform-Kompilation weniger wichtig als eine hilfreiche Entwicklungsumgebung, nehme ich mal an.
Es geht darum die Sprache zu lernen.
Eben! Und genau deswegen ist es völlig schnurz, ob die Entwicklungsumgebung auch auf einer anderen Plattform laufen würde – Hauptsache, sie ist intuitiv für Dich als Mac-Nutzer, und das ist Xcode.
Weia
(Grundsätzlich ist es für mich ein Ausschlusskriterium, wenn ich erfahre, dass ein Programm cross-platform ist.
Was hat das mit dem Erlernen von C zu tun? Gar nichts!
Nö, aber damit, ob man Eclipse oder Xcode den Vorzug gibt. Du schriebst:
Wenn man eine IDE nutzen will, wäre Eclipse oder Netbeans sinnvoller, das läuft faktisch auf jedem *I*X und Windows.
Für Dich spricht dieses Faktum für Eclipse oder Netbeans, für mich spricht es gegen Eclipse oder Netbeans.
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
Weia
Weia12.08.1615:00
Danger
Allerdings kann ich mich noch gut erinnern, als ich vor Jahren gerade anfing, hat mich Xcode mit seiner Oberfläche brutal überfordert: Zu viele Teilbereiche im Fenster, eine Vielzahl von Knöpfen, etc. Damals war der Interface Builder noch ein eigenständiges Programm, was für mich zusätzliche Komplexität bedeutete.
Ja, da hast Du natürlich einen Punkt. Seitdem ist Xcode aber deutlich einfacher geworden, finde ich.

Makefiles jedenfalls haben mich als Einsteiger seinerzeit mindestens ebenso „brutal überfordert“.
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
gfhfkgfhfk12.08.1620:51
Was kümmert mich das, wenn ich als Mac-Nutzer andere IDEs gar nicht verwende?
Matic verwendet ja Xcode insofern ist das Thema ohne geklärt.

Wir beide wissen um Deine Vorliebe für OSX als Plattform. Trotzdem ist es so, daß Xcode für viele Dinge auch auf dem Mac nicht die beste IDE ist. Verläßt man einmal die Pfade von C, C++, Objective-C oder Swift wird es mit Xcode schwierig. Du magst die notwendig nicht dazu sehen - ok, ist dann so.
0
DefiLover12.08.1621:40
Ich programmiere jetzt seit 1977 und bin immer wieder verwundert welchen Fetisch Menschen um eine bestimmte Sprache oder um eine IDE machen. Mal ganz einfach, brutal und aus vollem Herzen es ist total scheissegal welche Programmiersprache man lernt, Hauptsache man hat einmal begriffen wie ein Computer auf Bit-Basis funktioniert!

Auch liess sich fast jede IDE die ich erlebt habe einfach benutzen, man muss nur den komplizierten Schrott ignorieren. Also, auch da - scheissegal!

Alle Sprachbesonderheiten sind nur Ideologien und Glaubensbekenntnisse. Lern irgendeine Sprache die dir gerade über den Weg kommt, begreife sie und der Rest ist dann nur noch das Namensschild an der Wand. Ich habe irgendwann aufgehört mir überhaupt die Namen zu merken, weil es am Ende völlig wurscht ist, ob das Mnemnomics, Comal, Pascal, C, C++, Swift oder was auch immer heisst, das Grundprinzip ist immer das gleiche.

Einzig bei dem Sprung von reinem Sequentiellem Spaghetticode zu Objekten muss man einmal kurz das Hirn durchblasen, aber am Ende ist auch der letzte Objektgott nur aus Bit&Bytes gehäkelt. Ich kann auch schon nicht mehr zählen wie viele Goldene Kälber der Entwicklungsumgebungen an mir vorbei gezogen sind, ob nun PG23, AAR51, NC, RTX, das wie ich heute noch finde exzellente CodeWarrior oder heute eben Xcode, das übrigens zusammen mit der sehr guten Apple Dokumentation mehr als ausreichend und gut ist um Programmieren zu praktizieren.

Noch nie war es so trivial und billig Programmieren zu lernen und Xcode und C sind sicher nicht die schlechtesten (wobei ich betonen möchte kein C Freund zu sein), also warum nicht die völlig kostenfreie C + Xcode Variante? Ich sehe nichts was dagegen spricht. Aber = konzentriere dich auf die logischen Komponenten, denn 99,9% heutiger Programmierung sind nur Schaumschlägerei, bunte Bildchen und Verkaufsgedöns, aber keine intellektuelle Betätigung ... So, nun auf den Ring ...
0
torfdin13.08.1600:03
DefiLover
... exzellente CodeWarrior ...
+1
Deine Sichtweise ist die eines Fortgeschrittenen, aber 100% Zustimmung
einfach Xcode
„immer locker bleiben - sag' ich, immer locker bleiben [Fanta 4]“
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.