• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Wir haben den Frühjahrsputz beendet, Ihr auch? Welches Foto zu dem Thema hat Euch dann am Besten gefallen? Hier geht es lang zur Abstimmung --> Klick

Probleme mit C++ Programmierung unter OSX

below

Purpurroter Cousinot
Registriert
08.10.06
Beiträge
2.858
Und Cobol ist immer die Brot&Butter Programmiersprache in einem großen Teil des Enterprisegeschäfts. Zusammen mit den vielen zSeries, die in den vielen Keller der Rechenzentren stehen, wird so ein Großteil des täglichen Geschäfts gestemmt, und das sehr zuverlässig. Cobol dürfte ähnlich bekannt und beliebt sein wie RPG, trotzdem ist es eine Stütze vieler Firmen.

Wundervolles Zitat, das meinte ich auch so ähnlich.

Trotzdem stehen sind weder make noch Cobol für das Kurrikulum des Diplomstudiengangs Informatik vorgesehen -- und das ist auch gut so.

Was uns hier unterscheidet, ist ein bischen die Sichtweise. Du denkst sofort an die Praxis, das ist veilleicht auch ganz gut so.

Ich denke an Konzepte, und um das Konzept eines Linkers oder Compilers zu verstehen muss ich nicht wissen, wie der in der Kommandozeile heisst, oder mit welchen Optionen man ihn aufruft.

Unser Studium war fast vollständig agnostisch, die Wahl der Werkzeuge wurde uns fast immer selbst überlassen. Das machte es mir möglich, auch mit meinem PowerBook 170 und System 7 da durch zu kommen.

Alex
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.059
Was uns hier unterscheidet, ist ein bißchen die Sichtweise. Du denkst sofort an die Praxis, das ist vielleicht auch ganz gut so.
Wenn man wissen will wie ein Compiler und der Linker interagieren sollte man sich wohl besser die Werkzeuge auf der Shell anschauen und von Hand aufrufen. Für theoretische Betrachtungen reicht meiner Meinung nach eine Beschreibung in einem Buch/Artikel aus, dazu braucht man keinen Computer.

Ansonsten fällt für mich IDE und Makefile unter das Thema: wie erzeuge ich ausführbare Programme aus einem abstraktem Konzept eines Computerprogramms.
 
Zuletzt bearbeitet:

FrankR

Gascoynes Scharlachroter
Registriert
15.11.07
Beiträge
1.537
Ich soll mich mit einem CLI-Tool herumquälen, weil es zum Beispiel Serveranwendung gibt, die portabel sein sollen?

Er sprach doch von etwas Einfachem und für die Programme die ein Anfänger schreibt, hat ein Makefile vielleicht 5 Zeilen und gut.

Wahrscheinlich ist meine Sichtweise etwas anders, weil ich von der Unix-Richtung zum Mac gekommen bin und einfach mit dem CLI vertraut bin. Ausserdem arbeite ich gemischt unter OS X, Linux und Solaris und ein CLI ist da nunmal der kleinste gemeinsame Nenner. Ich finde aber auch Xcode nett, aber ehrlich gesagt - ich mag meinem vim und die CLI lieber, aber wie ich schon mal schrieb - alles Geschmacksache.
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Er sprach doch von etwas Einfachem und für die Programme die ein Anfänger schreibt, hat ein Makefile vielleicht 5 Zeilen und gut.
Es war sein Beispiel, nicht meines …

Wahrscheinlich ist meine Sichtweise etwas anders, weil ich von der Unix-Richtung zum Mac gekommen bin und einfach mit dem CLI vertraut bin. Ausserdem arbeite ich gemischt unter OS X, Linux und Solaris und ein CLI ist da nunmal der kleinste gemeinsame Nenner. Ich finde aber auch Xcode nett, aber ehrlich gesagt - ich mag meinem vim und die CLI lieber, aber wie ich schon mal schrieb - alles Geschmacksache.
Ich bin von Assembler-Entwicklung auf selbst entwickelten 6502/6511Q-Ein-Platinen-Rechnern, bei denen man anstelle eines Fix-Buttons die Möglichkeit hatte, den Code zur Laufzeit selbst (aka im Kopp) zu assemblieren und als Hexcode in den EPROM-Simulator einzugeben zu OS X gekommen (Ja, dazwischen waren noch einige Schritte erforderlich).

Ich verstehe dennoch nicht, warum ich es mir deshalb heutzutage maximal unbequem machen soll.

Die einzigen Argumente, die mir einfallen sind:
1. Ich habe das schon immer so gemacht, wieso sollte ich es ändern.
2. Ich habe es so mühsam lernen müssen, alles wird es wohl richtig sein. Der Jugend wird heutzutage ohnehin viel zu viel in den Arsch geschoben.

Bei beiden Argumenten habe ich aber für mich persönlich die Entscheidung getroffen, noch nicht alt genug zu sein, um ihnen zu folgen.
 
Zuletzt bearbeitet:

_ebm_

Gala
Registriert
30.03.08
Beiträge
53
Dieses Thema scheint ja immer und immer wieder hoch zu kommen. Ich bin ansich auch eher der Fan von CLI+make.

Das Hauptproblem bei der Betrachtung ist aber doch: Was ist das Lernziel des "Probanden"? Was will er lernen? Für das Zusammenhacken von einfachen Tools wird eine IDE sicherlich dienlich sein, zumal diese oftmals für eine bestimmte Platform gedacht sind - Ich spreche hier von Xcode. Grosse Projekte mit tief verschachtelten Verzeichnishirarchien wie sie zB in Java vorkommen, würde ich auch nicht mehr ohne IDE programmieren.

Etwas ganz anderes ist aber systemnahe Programmierung. Treiber, plattformübergreifend compilierbare Programme und ähnliches erfordern es oftmals auf archaische Werkzeuge zurückzugreifen. Ein Einsteiger wird sich damit aber nicht so schnell auseinandersetzen müssen.

Im universitären Umfeld und bei der Ausbildung als Programmierer bin ich aber sehr wohl dafür, recht frühzeitig auch den Umgang mit der CLI zu lehren. So wird das Verständnis gestärkt, wie die einzelnen Dateien und Stufen in der Entwicklung zusammenhängen und der Umgang mit anderen Umgebungen lernt sich leicher, weil man weiss, wonach man suchen muss.

Ach ja, den Vergleich mit Cobol fand ich garnicht mal so falsch. Noch immer werden mehr Zeilen in Cobol90 geschrieben als in allen anderen Programmiersprachen zusammen. Cobol hat weiterhin eine grosse Bedeutung und daran wird sich nicht viel ändern. Ähnlich wird es auch mit make sein (ok, da werden keine millionen Zeilen Code für geschrieben). Der Umgang wird damit weiterhin wichtig sein, wenn man systemnah auf mehreren unterschiedlichen Systemen programmiert, wie es im UNIX-Umfeld doch recht häufig vorkommt.
 

below

Purpurroter Cousinot
Registriert
08.10.06
Beiträge
2.858
Etwas ganz anderes ist aber systemnahe Programmierung. Treiber, ...
Aha. Mach mal ein Makefile für eine OS X Kernelextension. Aber aus dem Xcode Template abkucken ist schummeln, das gilt nicht! EDIT "Well, kexts require special build-foo that takes some experimentation to get right"
OS X Kernelextensions NICHT mit Xcode zu bauen kann ich nur Leuten empfehlen, die das Geld für die Domina sparen wollen.

Im universitären Umfeld und bei der Ausbildung als Programmierer bin ich aber sehr wohl dafür, recht frühzeitig auch den Umgang mit der CLI zu lehren. So wird das Verständnis gestärkt, wie die einzelnen Dateien und Stufen in der Entwicklung zusammenhängen und der Umgang mit anderen Umgebungen lernt sich leicher, weil man weiss, wonach man suchen muss.
Verdammt, ich wusste doch, dass das mit der "Eliteuni" Beschiss ist! Das hat mir die RWTH Aachen nie beigebracht.

Deshalb fehlt mir wahrscheinlich das Verständnis, wie das alles zusammenhängt. Ich werde wohl doch auf Gärtner umschulen müssen

Alex
 

_ebm_

Gala
Registriert
30.03.08
Beiträge
53
Alex, ich meinte ja eigentlich weniger OS X als eher Solaris + Linux + AIX +...... ;) Mir ist klar, dass Apple einen anderen Weg geht und dafür mit Xcode Hilfsmittel in die Hand des Entwicklers legt, welches hier und da viel Foo und ein wenig Bar veranstaltet. Sonst würde ihnen vielleicht auch Eclipse oder ähnliches reichen...

So und dann lies bitte nochmal, was ich geschrieben hab. Da steht "Verständnis gestärkt". Das heisst nicht, dass der Entwickler sich das nicht selbst aneignen kann. Du gibst da ja ein vortreffliches Beispiel ab. Aber du wirst doch zugeben, die Abstraktion, in einer IDE einen Knopf zu drücken hilft einem nicht beim Verständnis. Ich stehe weiterhin zu der Aussage: Eine IDE ist ein Hilfsmittel, um komplexe Systeme leichter warten zu können und sollen verhindern, den Überblick zu verlieren. Ein Blick über den Tellerrand schadet aber in keinem Fall.

Gruss Carsten
 

below

Purpurroter Cousinot
Registriert
08.10.06
Beiträge
2.858
Eine IDE ist ein Hilfsmittel, um komplexe Systeme leichter warten zu können und sollen verhindern, den Überblick zu verlieren. Ein Blick über den Tellerrand schadet aber in keinem Fall.

Das können wir so stehen lassen, und auch ich würde ohne gdb im Terminal nicht weit kommen.

Du hast es selber gesagt: Was ist das Ziel? "Programmieren lernen" heisst für mich eben nicht, Werkzeuge lernen. Da darf es ruhig ein "Build & Go" Knopf sein.

Klassische Lehrsprachen wie Modula-2 machen Makefiles unnötig. Warum ist das wohl so?

Ah, ich weiss es: Weil der Herr Wirth uns alle verderben wollte ;)

Alex
 

_ebm_

Gala
Registriert
30.03.08
Beiträge
53
Modula-2 wird noch gelehrt? *gg*

Nee Herr Wirth wollte uns nicht verderben. Im Einstieg soll ja schon vom darunterliegenden System abstrahiert werden. Irgendwann wird der Lehrling sich aber mit Preprozessor, Compiler und Linker auseinandersetzen müssen und genau da ist die CLI doch hilfreich.
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.059
Klassische Lehrsprachen wie Modula-2 machen Makefiles unnötig. Warum ist das wohl so?
Dafür mußte man die ganze Zeit Definitions Module schreiben - absolut nervig. Ich wußte schon, warum ich den Modula-II Compiler gegen den Oberon-2 Compiler getauscht habe, und dieser hatte ein extra Make Tool, was man meistens out-of-the-box nutzen konnte aber genauso gut übers CLI.
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.059
Du hast es selber gesagt: Was ist das Ziel? "Programmieren lernen" heisst für mich eben nicht, Werkzeuge lernen.
Zum Programmieren lernen braucht man genau genommen noch nicht einmal einen Computer. Wenn ich allerdings anfange Programme auf einem real existierenden Computer ausführen zu wollen, dann muß ich mich mit so Sache wie Interpreter, Byte-Code Compiler (Virtual Machines) und Maschinencode Compiler auseinandersetzen. Dazu gehört es auch die Grundlagen der Toolchains zu kennen, und zu diesen gehören nun einmal Compiler, Linker und Debugger.

Dabei ist es ziemlich egal, was für eine Sprache und Plattform ich nutze. Am grundsätzlichen Ablauf compilieren von Übersetzungseinheiten, Binden derselben und Programm ggf. debuggen hat sich seit Jahrzehnten nichts geändert. Also muß man das auch wissen, es ist Basiswissen und meiner Meinung nach keineswegs entbehrlich.
 
Zuletzt bearbeitet:

below

Purpurroter Cousinot
Registriert
08.10.06
Beiträge
2.858
Ich wußte schon, warum ich den Modula-II Compiler gegen den Oberon-2 Compiler getauscht habe, und dieser hatte ein extra Make Tool, was man meistens out-of-the-box nutzen konnte aber genauso gut übers CLI.

Du hast natürlich recht ;)
Ich kann mich nicht erinnern, aber hatte Oberon nicht seine eigene, OS unabhängige grafische Oberfläche?

Alex
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.059
Ich kann mich nicht erinnern, aber hatte Oberon nicht seine eigene, OS unabhängige grafische Oberfläche?
Jein, das Oberon System der ETH Zürich hatte das, aber das habe ich nicht genutzt sondern einen reinen Oberon-2 Compiler für AmigaOS. Mittlerweile gibt es auch eine eigenständigen Oberon-2 Compiler für UNIX Systeme "oo2c".
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.059
Ja, das haben wir verwendet (Auf meinem Rechner unter System 7, in der Uni auf HP-UX)
Wenn ich mich recht entsinne, baute das original Oberon-System auf Oberon auf und nicht auf Oberon-2. Der Hauptunterschied war, aus dem Gedächtnis hevorgekramt, es gab on Oberon keine for Schleife und vor allem gab es keine typgebundenen Prozeduren und somit keine Polymorphie wie in Oberon-2.