amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > C-Anfängerkurs [ - Search - New posts - Register - Login - ]

1 2 3 -4- 5 [ - Post reply - ]

2004-02-24, 13:57 h

Tessien
Posts: 55
User 		Falls das Community-Projekt "IDE" noch nicht gestorben ist... ich würde mitmachen. Allerdings nur begrenzt, da meine Erfahrung in Oberflächenprogrammierung nahe Null liegen und ich bereits ein eigenes Nebenbei-Projekt pflege. Ich würde den Teil übernehmen, den ich an Visual C am meisten schätze: Intellisense. Für die, die kein VisualC kennen: Auto-Vervollständigen, Typinfo während des Tippens usw. Arbeitet nicht immer perfekt, hat einige Probleme, aber im Großen und Ganzen erleichtert es das Programmieren doch ungemein. Eine ähnlich arbeitende Einrichtung wäre für mich jedenfalls Bedingung, um überhaupt eine IDE zu benutzen.

Meine Sorge ist eher, daß der Vorschlag von Holger kommt. Ich habe ihn wegen seiner Postings bisher nur als Sprücheklopfer mit zuviel Selbstvertrauen kennengelernt. Um ein solches Projekt auf die Beine zu stellen, braucht es doch eher andere Fähigkeiten. Gibt es denn sonst noch jemand, der da mitmachen würde?

Vor kurzem war doch mal eine AmigaNews-Meldung, daß jemand an einer neuen IDE bastelt. Vielleicht könnte man sich mit ihm zusammentun.

Bye, Thomas


--
Thomas Schulze - programmer at Dreamworlds Development - http://www.dreamworlds.de

[ - Answer - Quote - Direct link - ]
2004-02-24, 14:38 h

Holger
Posts: 8116
User
Zitat:
Original von Dietmar:
Zitat:
Ich kann absolut nicht nachvollziehen, was Du hiermit sagen willst.

Er will damit sagen, dass jeder angehende Programmierer die Developer-CD braucht und dass auf dieser CD ein bestimmter Compiler halt nur einen Mausklick entfernt ist. Da er den C-Kurs schreibt, ist das letzlich seine Entscheidung, unbegründet ist sie jedenfalls nicht. Wenn wir noch lange herumnörgeln, verliert er noch die Lust, also Vorsicht :)
Ich bitte Dich hiermit darum, Zitate nicht aus dem Zusammenhang zu reißen und einen falschen Eindruck von Bezug und Adressat zu erwecken.
Wenn Du zum eigentlichen Inhalt meines Postings nicht's zu sagen hast, dann mache auch Deine Aussage in Zukunft, ohne mich zu zitieren.
Danke.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-02-24, 14:50 h

Holger
Posts: 8116
User
Zitat:
Original von Mad_Dog:
Und die Pragmas muß halt jeder selbst in der Anleitung zu seinem Compiler nachschauen, falls er sie wirklich braucht.
Na großartig. Bist Du Dir sicher, dass das Ergebnis ein Anfängerkurs wird?
Zitat:
Schau Dir zum Vergleich mal die Beispiele der NDKs an. Die sind teilweise so uralt, daß sie nichteinmal mehr mit einem halbwegs aktuellen Compiler richtig funktionieren, weil sich seit 1.3 halt schon einiges in den Includes verändert hat. Viele sind der NDK-Beispiele sind nichteinmal ANSI-komform (void main(void) usw.)
Und Du willst unter diesen Umständen einen Kurs auf einem Compiler aufbauen, der heute ebenfalls schon veraltet ist?
Zitat:
Trotzdem kann man aus den (teilweise veralteten) Beispielsources der NDKs noch was lernen. Aber der eigentliche Hauptgrund, der für den Kauf dieser CD spricht sind die RKRM's und Autodocs.
Und die Texte, die den in den Beispielsourcen enthaltenen Code auch gleich als veraltet beschreiben.
Nein, der Hauptgrund dürfte wohl sein, dass es derzeit nichts anderes gibt.
Zitat:
@Holger:
Dann kannst Du in der Zwischenzeit ja schonmal anfangen eine neue, vorbildliche IDE zu programmieren. :)
Mit bislang einem weiteren Interessenten wird das wohl nix.
Abgesehen davon ist das Wort vorbildlich in diesem Zusammenhang unsinnig, so etwas gibt es nicht. Es gibt eher einen noch zusammenzutragenden Katalog von Forderungen, den wir an eine solche IDE stellen. Das wird aber auch nichts, wenn wir schon über die grundsätzliche Notwendigkeit streiten müssen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-02-24, 14:57 h

Holger
Posts: 8116
User
Zitat:
Original von Tessien:
Falls das Community-Projekt "IDE" noch nicht gestorben ist... ich würde mitmachen.
Bislang hat es noch nichtmal angefangen.
Zitat:
Allerdings nur begrenzt, da meine Erfahrung in Oberflächenprogrammierung nahe Null liegen und ich bereits ein eigenes Nebenbei-Projekt pflege.
Das sind sehr gute Voraussetzungen. UI-Programmierung sollte nicht der Schwerpunkt sein und zu wissen, was man braucht, ist besser, als viel Zeit zu haben.
Zitat:
Meine Sorge ist eher, daß der Vorschlag von Holger kommt. Ich habe ihn wegen seiner Postings bisher nur als Sprücheklopfer mit zuviel Selbstvertrauen kennengelernt. Um ein solches Projekt auf die Beine zu stellen, braucht es doch eher andere Fähigkeiten. Gibt es denn sonst noch jemand, der da mitmachen würde?
Siehs mal so: am Sinn des Vorschlags als solchen gibt es nichts zu rütteln, und wenn Du in Zukunft auch nach dem Inhalt und nicht der Quelle gehst, wird das auch funktionieren.
Aber an weiteren Interessenten bin ich natürlich auch interessiert, zwei sind nicht genug.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-02-24, 15:08 h

Tessien
Posts: 55
User
Zitat:
Original von Holger:
Zitat:
Original von Tessien:
Falls das Community-Projekt "IDE" noch nicht gestorben ist... ich würde mitmachen.
Bislang hat es noch nichtmal angefangen.
Das war mir schon klar, nur hatte ich auf Grund der ausbleibenden Reaktionen bisher die Vermutung, daß Du die Idee ad acta gelegt hättest.

Zitat:
Siehs mal so: am Sinn des Vorschlags als solchen gibt es nichts zu rütteln, und wenn Du in Zukunft auch nach dem Inhalt und nicht der Quelle gehst, wird das auch funktionieren.
Aber an weiteren Interessenten bin ich natürlich auch interessiert, zwei sind nicht genug.
Der Inhalt stimmt, da hast Du Recht. Meine Bemerkung war auch nicht wirklich konstruktiv, bitte entschuldige das. Du hast nur eine Angewohnheit, in praktisch all Deinen Bemerkungen einen Unterton mitschwingen zu lassen, der das Gegenüber und große Teile der Welt als unfähig darzustellen sucht. Das warf bei mir Zweifel an Deiner Ernsthaftigkeit auf.

Nunja, auch zu zweit werden wir wohl kaum eine IDE aus dem Boden stampfen. Falls ich den entsprechenden AmigaNews-Beitrag finde, werde ich den IDE-Schreiberling mal fragen, wie weit sein Projekt gediehen ist.

Bye, Thomas

(Edit: quote-Tags repariert.)
--
Thomas Schulze - programmer at Dreamworlds Development - http://www.dreamworlds.de

[ Dieser Beitrag wurde von Tessien am 24.02.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-02-24, 15:57 h

Dietmar
Posts: 166
User
Zitat:
Falls das Community-Projekt "IDE" noch nicht gestorben ist... ich würde mitmachen. Allerdings nur begrenzt, da meine Erfahrung in Oberflächenprogrammierung nahe Null liegen und ich bereits ein eigenes Nebenbei-Projekt pflege. Ich würde den Teil übernehmen, den ich an Visual C am meisten schätze: Intellisense

Falls das Community-Projekt doch gestorben ist: Intellisense könnte man auch in GoldED nachrüsten und den Editor als Ausgangspunkt für eine IDE nehmen. Eine Schnittstelle für Plug-Ins gibt es schon und die Erweiterungen, die man in VisualC unter, über und neben dem Text sieht, kann man mit dieser Schnittstelle realisieren: Container mit Sourcecode-Liste, definierte Funktionen usw. Plug-Ins, die die Eingaben überwachen und Vorschläge anzeigen, wären kein grosses Problem (das Problem ist, die richtigen Vorschläge zu finden). Andere typische IDE-Komponenten auch nicht: CVS in einem Container, Projektverwaltung usw. Beispielsourcecodes liegen bei. Hier ist ein Bild, das ein Plug-In neben dem Text zeigt (Dateiliste):

http://www.angelfire.com/droid/dtmr/images/screen_c.png



Etwas von Deinen Ideen ist sowieso schon drin, z.B. Typ-Info für die Parameter einer OS-Funktion, die man gerade eingetippt hat. Allerdings habe ich noch nie Zeit und Motivation gehabt, richtiges Intellisense zu machen, das z.B. Struktur-Mitglieder vorschlägt. Dazu müsste man eine Datenbank im Hintergrund haben, die ständig alle geänderten Dateien eines Projektes durchsucht und einen Baum mit globalen und lokalen Objekten und ihrer Struktur aufbaut. Schwierig ist vor allem der C++-Parser: wenn der User /* oder { eintippt, dann verändert sich schlagartig die Struktur grosser Sourcecode-Abschitte. Man müsste einen Parser schreiben, der C++ versteht und zerlegt UND mit Sourceode in einem Zwischenzustand zurechtkommt (nicht syntaktisch/semantisch korrekt) UND rasend schnell ist UND auf Nachrichten der Art "Zeile 100 wurde geändert" zurechtkommt, um auf dieser Basis seine Datenbank zu aktualisieren.

[ Dieser Beitrag wurde von Dietmar am 24.02.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-02-24, 17:22 h

Holger
Posts: 8116
User
Zitat:
Original von Dietmar:
Falls das Community-Projekt doch gestorben ist: Intellisense könnte man auch in GoldED nachrüsten und den Editor als Ausgangspunkt für eine IDE nehmen. Eine Schnittstelle für Plug-Ins gibt es schon ...
Da es ja nicht das Ziel sein soll, das RadNG zu erfinden, kann das auch die Ausgangsbasis sein, wenn das Community-IDE Projekt nicht stirbt.
Von GoldEd gibt's doch auch eine freie Grundversion, oder?
Ist eine Dokumentation der Plugin-Schnittstelle in dem Archiv enthalten, oder gibt's das gesondert?
Zitat:
Allerdings habe ich noch nie Zeit und Motivation gehabt, richtiges Intellisense zu machen, das z.B. Struktur-Mitglieder vorschlägt. Dazu müsste man eine Datenbank im Hintergrund haben, die ständig alle geänderten Dateien eines Projektes durchsucht und einen Baum mit globalen und lokalen Objekten und ihrer Struktur aufbaut. Schwierig ist vor allem der C++-Parser: wenn der User /* oder { eintippt, dann verändert sich schlagartig die Struktur grosser Sourcecode-Abschitte. Man müsste einen Parser schreiben, der C++ versteht und zerlegt UND mit Sourceode in einem Zwischenzustand zurechtkommt (nicht syntaktisch/semantisch korrekt) UND rasend schnell ist UND auf Nachrichten der Art "Zeile 100 wurde geändert" zurechtkommt, um auf dieser Basis seine Datenbank zu aktualisieren.
In der Verwaltung der in einem Projekt enthaltenen Resourcen liegt ja auch ein Schwerpunkt der IDE. Da kommt dann noch die Verwaltung der Aufgaben und die Delegation an das jeweils zuständige Modul dazu, und schon kann man anfangen, existierende Software möglichst harmonierend einzubinden.
Was den Parser angeht: übliche Lösungen besitzen nach Geschwindigkeit und Vollständigkeit gewichtete Modi, zwischen denen nach Eingabeverhalten gewechselt wird. Tippt der Nutzer schnell, wird nur die Grundstruktur geparsed, hört er auf zu tippen, wird genauer analysiert. Der Nutzer muß ja mit Tippen aufhören, bevor er browsen kann.
Aber selbst Software wie Eclipse hat da manchmal noch seine Schwierigkeiten, trotzdem ist es schon sehr nützlich und man will kaum mehr darauf verzichten.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 24.02.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-02-24, 18:11 h

Tessien
Posts: 55
User
Zitat:
Original von Dietmar:
Etwas von Deinen Ideen ist sowieso schon drin, z.B. Typ-Info für die Parameter einer OS-Funktion, die man gerade eingetippt hat. Allerdings habe ich noch nie Zeit und Motivation gehabt, richtiges Intellisense zu machen, das z.B. Struktur-Mitglieder vorschlägt. Dazu müsste man eine Datenbank im Hintergrund haben, die ständig alle geänderten Dateien eines Projektes durchsucht und einen Baum mit globalen und lokalen Objekten und ihrer Struktur aufbaut. Schwierig ist vor allem der C++-Parser: wenn der User /* oder { eintippt, dann verändert sich schlagartig die Struktur grosser Sourcecode-Abschitte. Man müsste einen Parser schreiben, der C++ versteht und zerlegt UND mit Sourceode in einem Zwischenzustand zurechtkommt (nicht syntaktisch/semantisch korrekt) UND rasend schnell ist UND auf Nachrichten der Art "Zeile 100 wurde geändert" zurechtkommt, um auf dieser Basis seine Datenbank zu aktualisieren.

Ich sollte dazu vielleicht erwähnen, daß ich die Intellisense-Funktionalität hauptsächlich deswegen machen will, weil ich sie am meisten brauche und niemanden anderen deswegen fragen kann. Das heißt nicht, daß ich speziell dafür qualifiziert wäre. Im Gegenteil, ich bin eigentlich mehr auf Spiele geeicht.

All die "UND"s im obigen Text sind zwar logisch, aber ich wäre für den Anfang zufrieden mit einem Parser, der C++ versteht und sonst nix. Dazu auf irgendeine Art den Kontext ermitteln, in dem der Cursor gerade blinkt und für kleinere Projekte müsste es reichen. Danach sehen wir weiter.

Was brauche ich denn, wenn ich PlugIns für GoldEd entwickeln will? Und falls irgendjemand von Euch Ideen hat, wie das Problem anzugehen ist, bitte ich um Vorschläge. Ich habe mir Intellisense nicht vorgenommen, weil ich weiß, wie man das macht, sondern weil es das ist, was ich am meisten brauche. Wenn irgendwer von Euch das besser kann, gebe ich die Aufgabe gerne ab.

Bye, Thomas


--
Thomas Schulze - programmer at Dreamworlds Development - http://www.dreamworlds.de

[ - Answer - Quote - Direct link - ]
2004-02-24, 18:17 h

Mad_Dog
Posts: 1944
User 		Eine bescheidene Forderung von mir an eine neue IDE wäre z.B. ein Online-Hilfesysten, wie bei StormC. D.h. der User klickt im Editor ein Schlüsselwort an und drückt die HELP-Taste. Darauf hin öffnet sich ein Amiga-Guide (oder HTML) - Hypertext, der das Schlüsselwort kurz erklärt. sowas gab's übrigens schon bei der uralten Enticklerumgebung von AMOS Pro Basic.

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]
2004-02-24, 18:44 h

Mad_Dog
Posts: 1944
User
Zitat:
Original von Holger:
Zitat:
Original von Mad_Dog:
Und die Pragmas muß halt jeder selbst in der Anleitung zu seinem Compiler nachschauen, falls er sie wirklich braucht.
Na großartig. Bist Du Dir sicher, dass das Ergebnis ein Anfängerkurs wird?

Voraussichtlich werden wir sowieso keine Pragmas brauchen.

Zitat:
Zitat:
Schau Dir zum Vergleich mal die Beispiele der NDKs an. Die sind teilweise so uralt, daß sie nichteinmal mehr mit einem halbwegs aktuellen Compiler richtig funktionieren, weil sich seit 1.3 halt schon einiges in den Includes verändert hat. Viele sind der NDK-Beispiele sind nichteinmal ANSI-komform (void main(void) usw.)
Und Du willst unter diesen Umständen einen Kurs auf einem Compiler aufbauen, der heute ebenfalls schon veraltet ist?

Ich glaube dieses Thema ist mittlerweile ausgelutscht.
Wer will, darf auch einen anderen Compiler verwenden.
Für alle Nörgler kann ich ja noch einen Link zu Dietmar's Website einfügen...

Zitat:
Zitat:
Trotzdem kann man aus den (teilweise veralteten) Beispielsources der NDKs noch was lernen. Aber der eigentliche Hauptgrund, der für den Kauf dieser CD spricht sind die RKRM's und Autodocs.
Und die Texte, die den in den Beispielsourcen enthaltenen Code auch gleich als veraltet beschreiben.
Nein, der Hauptgrund dürfte wohl sein, dass es derzeit nichts anderes gibt.

Hast Du einen besseren Vorschlag? Es ist nicht mein Fehler, daß Amiga Inc. bzw. Haage&Partner es versäumt haben, eine halbwegs aktuelle Dokumentation der AmigaOS API herauszubringen.

Zitat:
Zitat:
@Holger:
Dann kannst Du in der Zwischenzeit ja schonmal anfangen eine neue, vorbildliche IDE zu programmieren. :)
Mit bislang einem weiteren Interessenten wird das wohl nix.
Abgesehen davon ist das Wort vorbildlich in diesem Zusammenhang unsinnig, so etwas gibt es nicht. Es gibt eher einen noch zusammenzutragenden Katalog von Forderungen, den wir an eine solche IDE stellen. Das wird aber auch nichts, wenn wir schon über die grundsätzliche Notwendigkeit streiten müssen.

Wenn Du mal anfangen würdest, eine Spezifikation Deiner "IDE NG" zu machen, würden sich bestimmt einige Leute dafür interessieren.
Mein Tip: Notorische Nörgler und Ignoranten einfach ignorieren. :)
Leg einfach mal los, mach ein Konzept usw. . Sicherlich werden dann wieder einige sagen "das funktioniert doch nie", aber mich persönlich motivieren solche Aussagen dann noch mehr. 8) Am Ende staunen :shock2: die Pessimisten dann oft am meisten, wenn sie sehen, was alles geht. :lickout:
--

http://www.norman-interactive.com


[ Dieser Beitrag wurde von Mad_Dog am 24.02.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-02-24, 20:01 h

Dietmar
Posts: 166
User
Zitat:
All die "UND"s im obigen Text sind zwar logisch, aber ich wäre für den Anfang zufrieden mit einem Parser, der C++ versteht und sonst nix

Leider hat man da nicht die grosse Wahlmöglichkeit. Da der Sourcecode vom Benutzer im Editor bearbeitet wird, kommt man mit einem Parser, der "nur" C/C++ versteht (und das ist schon schwierig genug), nicht weiter: es steht zu 99% der Zeit kein korrektes C++ im Editor. Man wird auf einen automatisch generierten syntaktisch vollständigen Parser verzichten müssen und sich was empirisches ausdenken müssen.

Zitat:
Was brauche ich denn, wenn ich PlugIns für GoldEd entwickeln will? Und falls irgend jemand von Euch Ideen hat, wie das Problem anzugehen ist, bitte ich um Vorschläge.

GoldED und die Unterlagen dazu. Aber an Deiner Stelle würde ich mir jetzt dazu keine Gedanken machen und Intellisense unabhängig schreiben. Mit GoldED wirst Du dich nur in den letzten Minuten des Projekts beschäftigen müssen.

Vorschläge:

(a) eine projektbezogene Datenbank, die eine Lookup-Funktion für Symbole hat. Man füttert die Datenbank mit zwei Eingabewerten (Inhalt der aktuellen Zeile und Position in der aktuellen Zeile) und die Datenbank liefert eine Tabelle mit Vorschlägen. Die Datenbank sollte ein Baum sein, in dem es Äste für Scopes (Module, Namespaces, ..., Blöcke), Strukturen und Klassen gibt. An Ende der Äste stehen die elementare C-Objekte (Funktionsnamen, Variablen, #defines usw).

(b) Ein Parser, der Texte durchsucht und die Datenbank aktualisiert. Der Parser sollte die Dateien zeilenweise und nur vorwärts untersuchen, dann kann man das Lesen aus der Datei später durch Lesen der Zeilen aus dem Editor ersetzen. Der Parser muss einen Notification-Hook für dynamische Änderungen haben, einfach Sourcecodes von Anfang bis Ende parsen geht nicht: man kann nicht nach jedem eingegebenen Buchstaben ganze Sourcecodes parsen. Also braucht man eine Funktion im Parser, die übergeben kriegt: x Zeilen ab Zeile y eingefügt/geändert/gelöscht. Dann parst er nur genau so viele Zeilen, wie unbedingt notwendig (den jeweiligen Scope). Anfang und Ende der Scopes kann man möglicherweise nur empirisch pi-mal-Daumen ermitteln. Bei manchen Benutzereingaben wie #ifdef kann die ganze Scope-Struktur zusammenbrechen. Ausserdem muss der Parser diesen Hook dazu benutzen, die Information über den Ort der gefundenen Symbole nachzuführen, Zeilennummern ändern sich.

[ - Answer - Quote - Direct link - ]
2004-02-26, 17:33 h

Mad_Dog
Posts: 1944
User 		Zurück zum C-Kurs:

Habe jetzt im 1. Kapitel noch eine Lektion über Aussagelogische Operatoren eingefügt (hatte ich doch glatt vergessen :glow: ).

Als nächstes sind dann wohl structs (ja Solar mit C ;) ) dran.

Ich überlege mir noch, ob es für Anfänger sinnvoll ist, auch Listen und Bäume zu besprechen. Ich würde mal sagen: Ja. Denn in der AmigaOS API (und nicht nur in der) werden solche Datenstrukturen ständig verwendet. Und wer sowas nicht kennt, fängt dann an zu pfuschen, sobald es um Fenster usw. geht.

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]
2004-03-04, 18:22 h

Holger
Posts: 8116
User
Zitat:
Original von Mad_Dog:
Ich überlege mir noch, ob es für Anfänger sinnvoll ist, auch Listen und Bäume zu besprechen. Ich würde mal sagen: Ja. Denn in der AmigaOS API (und nicht nur in der) werden solche Datenstrukturen ständig verwendet. Und wer sowas nicht kennt, fängt dann an zu pfuschen, sobald es um Fenster usw. geht.

Selbst wenn es nicht im Zusammenhang mit dem AmigaOS auftreten würde, ist es sinnvoll, diese Konzepte zu besprechen. Es schadet nichts, wenn der C-Kurs auch ein Programmier-Kurs wird.
Schliesslich mangelt es dem Amiga an Software, nicht an C-Programmierern :)

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-03-04, 19:47 h

Mad_Dog
Posts: 1944
User 		Ich hab jetzt mal zwei Lektionen über Zeiger und Adressen und Zeiger auf Strukturen reingesetzt. Ist garnicht so leicht, diese Konzepte anfängergerecht herüberzubringen... Wie gefällt Euch meine Roboter-Analogie? :D

Listen und Bäume werde ich auf jeden Fall noch bringen.

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]
2004-03-04, 23:56 h

swat
Posts: 83
User 		Tolle Sache,
interessant wäre es einen kursus in Sachen - wie kompiliere ich
vorhandenden quellcode in ein ausführbares Programm
ohne das ich erstmal c lernen muss.
gruss Matthias

[ - Answer - Quote - Direct link - ]
2004-03-05, 00:15 h

Mad_Dog
Posts: 1944
User 		Siehe hier:

http://w3studi.informatik.uni-stuttgart.de/~walternn/C-Kurs_1_1.html


Übrigens wird das nur mit reinem ANSI-C Quellcode funktionieren. Sobald irgendwelche (nicht portable) API-Aufrufe dabei sind, kannst Du das "einfach mal schnell durch den Compiler jagen" vergessen.

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]
2004-03-05, 16:48 h

obw
Posts: 94
User 		Ich habe hier gerade gesehen, daß einige Leute darüber nachgrübeln, eine IDE zu schreiben (Oder daß mal jemand eine schreiben müßte.). Und daß von Grund auf anfangen aufwendig ist.

Guckstu hier:
AmIDE

Der gute DaMato freut sich sicher, wenn da noch ein paar Leute einsteigen und sich endlich mal wieder was um sein Baby tut. Lizenz ist GPL, haut rein. :D

(Ich habe schon selber überlegt, bin aber im Augenblick ein wenig bei Eclipse hängengeblieben und wollte da evtl. was mit Crosscompiling zusammenpfriemeln :smokin: )

OBW

[ - Answer - Quote - Direct link - ]
2004-03-30, 16:49 h

Ralf27
Posts: 2779
User 		Ich verfolge denn C-Kurs und bei denn Strukts kam es bei mir zu einem "Aha"-Erlebniss. :)

Jetzt möchte ich aber meine alten Basic-Projekte nicht sterben lassen bzw. ist es fast unmöglich sie in C zu neu zu schreiben.

Deswegen folgende Frage:
Wenn ein Programm ein Strukt zurückliefert das z.b. wie folgt aufgebaut ist, wie kann ich dann mit Basic drauf zugreifen?

struct test
{
struct bla
struct bla2
...
}

struct bla
{
ULONG info
...
}

...

Wie kann ich dann am besten auf die Daten zurückgreifen? Ich nehme mal folgendes an:

Anfangbla=peekl(test)
Anfangbla2=peekl(test+4)
Info=peekl(Anfangbla)

Kommt das so in etwa hin?
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2004-03-30, 17:08 h

Mad_Dog
Posts: 1944
User 		@Ralf27:

Freut mich, daß Du zu einem Aha-Erlebnis gekommen bist.
Wenn Du Dich ein wenig weiter in C reinarbeitest, wirst Du mit Sicherheit auch Deine alten Basic-Programme nach C umschreiben können. Merke: Die Idee, die hinter einem Programm steht, steht im Vordergrund, nicht die Implementierung in einer bestimmten Programmiersprache oder API. Als z.B. mal ein Student des Bauwesens zu mir kam, damit ich ihm beim Lernen auf seine Informatik-Prüfung helfe, haben wir zusammen die "Kochsche Schneeflocke", die ich zuvor in C mit OpenGL bzw. Intuition gemacht habe, nach Visual Basic portiert um das Thema "Rekursion" zu vertiefen.

Wie man auf Strukturen in MaxonBasic zugreift, kann ich Dir nicht sagen, da ich es nicht kenne. Aber Du hast das bestimmt schonmal gemacht, wenn Du die AmigaOS API programmiert hast (z.B. Intuition).

Wie Du anhand des Kurses siehst, geht das in C recht einfach. In BASIC mußt Du eventuell die Adresse der einzelnen Komponenten der Structs berechnen oder so... kein Plan.

Zum Thema "Zeiger" baue ich vielleicht noch ein paar Bilder zum besseren Verständnis ein... in der Zwischenzeit hilft Dir vielleicht meine "Roboter-Analogie" ;)
--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]
2004-03-30, 17:23 h

Ralf27
Posts: 2779
User 		Also, zum einen ist Basic nicht komplizierter als C. :D

Die Frage ist nur wie ein Struct im Speicher abgelegt ist. Das ist eigentlich alles.

Aber eins muß ich C zugute halten was MBasic nicht hat:
Typen von einem Byte Größe. Das ist gerade bei einer Graphics-Funktion sehr wichtig und das fehlt mir bei MBasic(könnte ich zwar auch in Basic umschreiben, aber das wird dann langsamer als schneller).
Insofern würde ich gerne ein Beispielprogramm von Basic in C konvertieren das nicht gerade lang ist, aber zum testen...

Hey, ihr macht mir aber C recht schmackhaft! :D

[ Dieser Beitrag wurde von Ralf27 am 30.03.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-03-30, 17:35 h

Mad_Dog
Posts: 1944
User
Zitat:
Original von Ralf27:
Also, zum einen ist Basic nicht komplizierter als C. :D

Aber BASIC ist nicht auf Strukturen (oder Records, wie man das in anderen Programmiersprachen nennt) vorbereitet.

Zitat:
Die Frage ist nur wie ein Struct im Speicher abgelegt ist. Das ist eigentlich alles.

Das braucht einen C-Programmierer nicht zu interessieren. :D
Das einzige, was ab und zu mal interessant ist, ist die Größe in Byte eines sochen Structs. Die bekommt man aber ganz einfach mit dem sizieof-Operator. :D

Zitat:
Insofern würde ich gerne ein Beispielprogramm von Basic in C konvertieren das nicht gerade lang ist, aber zum testen...

Hey, ihr macht mir aber C recht schmackhaft! :D

Yo! Dann hau mal rein. :D


--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]
2004-03-30, 18:06 h

Holger
Posts: 8116
User
Zitat:
Original von Ralf27:
Die Frage ist nur wie ein Struct im Speicher abgelegt ist. Das ist eigentlich alles.
Das ist der Knackpunkt. Im Normalfall interessiert man sich als C-Programmierer nicht um die Speicherform einer Struktur.
Man kann allerdings von gewissen Grundregeln ausgehen. Deine Vermutung, dass die Daten hintereinander im Speicher liegen, ist erstmal richtig. Allerdings sind verschachtelte Strukturen ohne pointer auch direkt eingebettet, also für Dein Beispiel:

struct bla { int x, y; };
struct bla2 { int z; };
struct test { struct bla one; struct bla2 two; };

Dann liegen test.one.x, test.one.y und test.two.z direkt hintereinander im Speicher, Du kann sie also peekl(addresse), peekl(addresse+4) und peekl(addresse+8) auslesen.

Sind die Daten nicht eingebettet, sondern über pointer referenziert, dann brauchst Du mehrfache peek's wie in Deinem posting, also für

struct test { struct bla * one; struct bla2 * two; };

addrOne=peekl(addresse), addrTwo=peekl(addresse+4) und
x=peekl(addrOne), y=peekl(addrOne+4), sowie z=peekl(addrTwo).

Beachten mußt Du natürlich, dass unterschiedliche Datentypen auch unterschiedliche Längen im Speicher haben und dass Compiler je nach Architektur unbenutzte bytes einfügen, um alignment-restruktionen einzuhalten, bei herkömmlichen Amiga-Compilern werden alle Datentypen >2bytes auf gerade Adressen geschoben, ppc-Compiler bevorzugen meist durch vier teilbare Adressen, etc.

Wie gesagt, den normalen C-Programmierer interessiert das eher selten.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 30.03.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-03-31, 18:08 h

Mad_Dog
Posts: 1944
User 		Hallo Leute,

Ein Leser hat mich darauf hingewiesen, daß in meinem C-Kurs der Beispielcode in der Lektion "Das erste Fenster" nicht mit gcc zusammenarbeiten würde, da ein Zeiger auf die IntuitionBase auch immer vom Typ struct IntuitionBase sein müsse und nicht vom Typ struct Library.

Nun habe ich aber in den NDKs auch diverse Beispiele gesehen, wo der Zeiger auf als struct Library *IntBase; deklariert war.

Zugegeben: Mit gcc hat mein Code nicht funktioniert, wohl aber mit StormC.

Deshalb habe ich etwas rumgebastelt, bis es sowohl mit gcc, als auch mit StormC ohne Warnings durchlief:

code:
/*  Listing 7.2
 *  Das erste Fenster
 */

#include <exec/types.h>
#include <exec/exec.h>
#include <intuition/intuition.h>

#include <clib/exec_protos.h>
#include <clib/intuition_protos.h>

// Symbolische Konstanten
#define WIDTH 300   // Breite des Fensters
#define HEIGHT 300  // Höhe des Fensters

struct Window *Fenster;                // Zeiger auf Window-Struktur
struct IntuitionBase *IntuitionBase;   // Zeiger auf IntuitionBase-Struktur

int main(void)
{

  // Intuition Library öffnen
  IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",0L);

  if (IntuitionBase != NULL)
  {

    // Fenster mittels Tags öffnen
    Fenster = OpenWindowTags(NULL,
                             WA_Left, 100,       // Abstand vom linken Rand
                             WA_Top, 100,        // Abstand vom oberen Rand
                             WA_Width, WIDTH,    // Breite
                             WA_Height, HEIGHT,  // Höhe
                             WA_Title, "Mein erstes Fenster", // Fenstertitel
                             WA_CloseGadget, TRUE,            // Close-Gadget
                             WA_DragBar, TRUE,                // Ziehleiste
                             WA_DepthGadget, TRUE,            // Depth-Gadget
                             WA_IDCMP, IDCMP_CLOSEWINDOW,
                             WA_Activate, TRUE,               // Fenster aktivieren
                             TAG_DONE);

    if (Fenster != NULL)
    {
      // Auf Close-Gadget warten
      Wait(1L << Fenster->UserPort->mp_SigBit);

      CloseWindow(Fenster);   // Fenster schließen
    } // end if

  } // end if

  // Librarie schließen
  if (IntuitionBase != NULL) CloseLibrary((struct Library *)IntuitionBase);

  return 0;

}

Bin etwas ratlos... was ist jetzt "richtig(er)"? :dance3:
Jedenfalls kann man sich die Typecasts sparen, wenn man den Zeiger als struct Library statt struct IntuitionBase deklariert.

Seltsamerweise motzt der gcc auch herum, falls man <clib/dos_protos.h> includiert. Mir scheint, daß einige der Includes der NDKs noch von/für ältere Compiler sind??? :dance3:

Jedenfalls habe ich das (scheinbare) Schlamassel mit StormC nie bemerkt.

--

http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 31.03.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-04-01, 00:11 h

obw
Posts: 94
User
Zitat:
Original von Mad_Dog:

Bin etwas ratlos... was ist jetzt "richtig(er)"? :dance3:
Jedenfalls kann man sich die Typecasts sparen, wenn man den Zeiger als struct Library statt struct IntuitionBase deklariert.

Seltsamerweise motzt der gcc auch herum, falls man <clib/dos_protos.h> includiert. Mir scheint, daß einige der Includes der NDKs noch von/für ältere Compiler sind??? :dance3:

Jedenfalls habe ich das (scheinbare) Schlamassel mit StormC nie bemerkt.

Also, wenn Du die intuition.library als Library benutzen willst, dann reicht struct Library. Aber wahrscheinlich wollen alle möglichen Klamotten auf mehr oder weniger interne Strukturen der Intuitionbase zugreifen (s.a. intuition/intuitionbase.h) und abgesehen von der struct Library (die ja direkt am Anfang steht, deswegen ist direktes casten einfach möglich) auf den Rest zugreifen.

IntuitionBase ist halt nicht nur struct Library. Genau wie DosBase auch struct DosLibrary ist.

BTW hat dein Code (noch? ;) ) einen Fehler, OpenLibrary() solltest Du nicht mit 0L, sondern mit 36L machen, sonst bekommst Du auf Kickstart < 2.0 einen üblen Absturz, da Du OpenWindowTags() benutzt, was es damals noch nicht gegeben hat. :D

<clib/dos_protos.h> sollte man nie includen. Eigentlich sollte man <proto/dos.h> nehmen, welches abhängig vom Compiler dann die richtigen Includes reinsaugt. Leider sind die <proto/*.h>-Dateien vom NDK IIRC nur für SAS/C ausgelegt, man muß also mit fd2pragma selber den Rest nachbauen. Dafür hat man dann aber Includes, die mit allen Compilern gehen, also egal welcher Compiler, <proto/xxx.h> für die xxx.library. Und ja, das ist nervig, ich habe das letztens für den gcc gemacht, um AWeb endlich wieder ans Übersetzen zu bekommen.

StormC hat sich vielleicht Mühe gegeben, SAS-kompatibel zu sein. :dance3:

HTH, OBW

[ - Answer - Quote - Direct link - ]
2004-04-01, 01:30 h

Palgucker
Posts: 1342
User 		@ Mad_Dog

quote:

Jedenfalls habe ich das (scheinbare) Schlamassel mit StormC nie bemerkt

Dieses Schlamassel finde ich garnicht mal so scheinbar. Mir sind schon einige Quelltexte untergekommen, die mit StormC3.0 sauber kompiliert wurden, während andere Kompiler "die Hände über'm Kopf zusammenschlugen", und abbrachen.
Als Anfänger bekommt man solche Sachen auch nicht einfach mal schnell geradegebogen.
Dein Beispiel mit dem "ersten Fenster" lässt sich ja - trotz rummosern - wenigstens noch kompilieren. Anderst Dein Beispiel zum zeichnen des Sierpinski-Dreiecks in Kapitel 8.
Mit StormC3.0 - no problem. Aber weder vbbc noch gcc3.3 konnte ich übereden, daraus ein Programm zu stricken. Mein letzter Versuch sah wie folgt aus:

gcc Ram:Sierpinski-Dreieck.c -o Ram:Sierpinski-Dreieck -s -lc
Ram:Sierpinski-Dreieck.c: In function 'DrawSierpinski':
Ram:Sierpinski-Dreieck.c:102: error: parse error before "int"
Ram:Sierpinski-Dreieck.c:102: error: parse error before ')' token
Ram:Sierpinski-Dreieck.c: At top level:
Ram:Sierpinski-Dreieck.c:128: error: parse error before '}' token

Und immer ist es hier die Zeile 102 >>switch (random(0,2)) <<.
Na, jedenfalls stehe ich in diesen Punkt mal wieder auf dem Schlauch.

mfg Palgucker

P.s. Könnte man gcc nicht wenigstens in der Amigaversion die Option -brutal oder -nofear verpassen? ;)


[ - Answer - Quote - Direct link - ]
2004-04-01, 02:28 h

whose
Posts: 2156
User
Zitat:
Original von Palgucker:
@ Mad_Dog

quote:

Jedenfalls habe ich das (scheinbare) Schlamassel mit StormC nie bemerkt

Dieses Schlamassel finde ich garnicht mal so scheinbar. Mir sind schon einige Quelltexte untergekommen, die mit StormC3.0 sauber kompiliert wurden, während andere Kompiler "die Hände über'm Kopf zusammenschlugen", und abbrachen.
Als Anfänger bekommt man solche Sachen auch nicht einfach mal schnell geradegebogen.

Naja, StormC3 ist etwas "neben" dem ANSI-Standard, daher kommt der auch mit Formulierungen zurecht, die dem GCC überhaupt nicht schmecken. Normalerweise sollte man aber so schreiben, daß es auch der GCC peilt. Der StormC3 frißt das meist ebenfalls, ohne zu mucken.

Zitat:
gcc Ram:Sierpinski-Dreieck.c -o Ram:Sierpinski-Dreieck -s -lc
Ram:Sierpinski-Dreieck.c: In function 'DrawSierpinski':
Ram:Sierpinski-Dreieck.c:102: error: parse error before "int"
Ram:Sierpinski-Dreieck.c:102: error: parse error before ')' token
Ram:Sierpinski-Dreieck.c: At top level:
Ram:Sierpinski-Dreieck.c:128: error: parse error before '}' token

Und immer ist es hier die Zeile 102 >>switch (random(0,2)) <<.
Na, jedenfalls stehe ich in diesen Punkt mal wieder auf dem Schlauch.

mfg Palgucker

P.s. Könnte man gcc nicht wenigstens in der Amigaversion die Option -brutal oder -nofear verpassen? ;)

>>switch (random(0,2)) <<

Das das _ohne_ Semikolon da steht, ist doch hoffentlich nur ein Copy&Paste-Versehen? Hoffentlich, weil "parse error" meist ein Hinweis auf ein vergessenes Semikolon oder eine fehlende Klammer ist. Dank der "genaueren" Fehlermeldungen des GCC ("parse error" finde ich enorm spezifisch ;) kommts sehr häufig vor, daß man in ner völlig korrekten Zeile nach dem Fehler sucht und den logischerweise nicht findet, weil da nun mal gar kein Fehler ist. Ich habe mir den Source jetzt nicht ansehen können, daher kann ich nicht sagen, was der Fehler ist. Aber schau doch mal in der näheren Umgebung der Zeile 102, womöglich stößt Du da auf den Fehler.

Grüße


[ - Answer - Quote - Direct link - ]
2004-04-01, 02:47 h

whose
Posts: 2156
User
Zitat:
Original von Mad_Dog:

Bin etwas ratlos... was ist jetzt "richtig(er)"? :dance3:
Jedenfalls kann man sich die Typecasts sparen, wenn man den Zeiger als struct Library statt struct IntuitionBase deklariert.

Seltsamerweise motzt der gcc auch herum, falls man <clib/dos_protos.h> includiert. Mir scheint, daß einige der Includes der NDKs noch von/für ältere Compiler sind??? :dance3:

Also, _korrekter_ ist die aktuelle Fassung. IntuitionBase ist in den Includes vom Typ "struct IntuitionBase *", also sollte man das auch so deklarieren. Das bei OpenLibrary() und CloseLibrary() ein Cast nötig wird, ist zwar lästig, aber auch nicht so dramatisch.

Zum Thema <clib/...>: So ganz Recht hat der Vorredner zu dem Thema nicht. <clib/dos_protos.h> sollte man immer dann einbinden, wenn man _nicht_ mittels #pragma oder (beim GCC) Macros für die OS-Funktionseinsprünge arbeitet, sondern die Stub-Funktionen der amiga.lib oder storm.lib (oder wie die Compiler-Lib auch immer heißt) verwendet.

Das der GCC bei Dir meckert, mag damit zusammenhängen, daß Du (unwissentlich) die inline/-Macros für die OS-Einsprünge benutzt. Solange Du das machst, nimmst besser <proto/...> statt <clib/...>. Meistens meckert der GCC nicht, aber manchmal dann doch ;)

Grüße

[ - Answer - Quote - Direct link - ]
2004-04-01, 11:14 h

gni
Posts: 1106
User
Zitat:
obw:
IntuitionBase ist halt nicht nur struct Library. Genau wie DosBase auch struct DosLibrary ist.
Das eigentliche Problem ist doch die Mehrfach Deklaration bzw. Definition mit unterschiedlichem Typ. Proto/ Header machen die dazugehörige Librarybasis sichtbar und meist mit dem "richtigen" Typ. Wenn man eine Library nicht selber öffnen will, dann braucht man keine eigene Deklaration. Wenn man es aber will, _muß_ die Librarybasis aber mit dem im proto/ Header verwendeten Typ übereinstimmenn. Dieses Problem kann man umgehen, indem man die Library nur lokal verwendet (in einer Funktion definiert und rumreicht) oder man lagert die Basis in ein File aus, die keine proto/ Header inkludiert ;-)
Zitat:
<clib/dos_protos.h> sollte man nie includen.
Unterschreib ich nicht :-P

[ - Answer - Quote - Direct link - ]
2004-04-01, 11:20 h

gni
Posts: 1106
User
Zitat:
Mad_Dog:
Seltsamerweise motzt der gcc auch herum, falls man <clib/dos_protos.h> includiert. Mir scheint, daß einige der Includes der NDKs noch von/für ältere Compiler sind??? :dance3:
GCC meckert andere Sachen an als andere Compiler. Wenn man Strukurzeiger als Funktionsargument verwenden möchte, dann muß der Compiler die Struktur bereits gesehen haben. Ansonsten gibts Mecker, da das vom ANSI/ISO Standard so gefordert wird. (Das Programm läuft dennoch und macht auch was man erwartet, aber es gibt wohl Fälle wo das nicht so ist.) SAS/C war/ist da etwas relaxter.

[ - Answer - Quote - Direct link - ]
2004-04-01, 11:26 h

gni
Posts: 1106
User
Zitat:
Palgucker:
Anderst Dein Beispiel zum zeichnen des Sierpinski-Dreiecks in Kapitel 8. Mit StormC3.0 - no problem. Aber weder vbbc noch gcc3.3 konnte ich übereden, daraus ein Programm zu stricken. Mein letzter Versuch sah wie folgt aus:

gcc Ram:Sierpinski-Dreieck.c -o Ram:Sierpinski-Dreieck -s -lc
Ram:Sierpinski-Dreieck.c: In function 'DrawSierpinski':
Ram:Sierpinski-Dreieck.c:102: error: parse error before "int"
Ram:Sierpinski-Dreieck.c:102: error: parse error before ')' token
Ram:Sierpinski-Dreieck.c: At top level:
Ram:Sierpinski-Dreieck.c:128: error: parse error before '}' token

Und immer ist es hier die Zeile 102 >>switch (random(0,2)) <<.
Na, jedenfalls stehe ich in diesen Punkt mal wieder auf dem Schlauch.
Was random() für eine Funktion? Woher kommt die? Das ganze sieht aus, als ob random() ein Makro ist und das Schwierigkeiten bereitet.
Zitat:
P.s. Könnte man gcc nicht wenigstens in der Amigaversion die Option -brutal oder -nofear verpassen? ;)
-H und -E -p sollten Dir schon weiterhelfen. Alles in der Manpage bzw im Manual dokumentiert. Oder gcc -v --help.

[ - Answer - Quote - Direct link - ]

1 2 3 -4- 5 [ - Post reply - ]


amiga-news.de Forum > Programmierung > C-Anfängerkurs [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.