Gemeinschaftsprojekt?

[ragnar76]

Mal ne dusselige frage. Wieso nicht printf(); anstelle von Cconws();?

[m0n0]

Weil printf in dem Fall nicht benötigt wird und ich denke Cconws ist ein bisschen performanter.

[ragnar76]

im  grunde genomme hab ich schon kapiert was als nächstes zu tun ist. das währe dann ja wohl den autoordner auszulesen. Von php kenn ich den befehl readdir() und hab mal etwas vergleichbares gesucht.

gefunden hab ich den befehl dreaddir() der in der tos.h definiert wird aber ich bin mir nicht ganz schlüssig. im tos.hyp steht der ohne weitere einschränkungen beschrieben, im compendium wiederum steht dass das ein mint befehl währe. im profibuch hab ich nichts dergleichen gefunden.

Was ist denn nun richtig und währe das was für uns?

[simonsunnyboy]

Der Call ist Mint-only.

TOS kompatibel geht das mit Fsfirst() und Fsnext() . Das sind offizielle GEMDOS-Aufrufe seit 1984/85.

[m0n0]

Also ich benutze in meinem Code findfirst(), findnext() das sind PureC funktionen und die sind meiner Meinung nach einfach zu benutzen als die von Atari bereitgestellten.

AHCC stellt diese Funktionen auch bereit.

[afalc060]

wie war das mit der beschworenen portierbarkeit von c ??

[m0n0]

ok, was cconws anbelangt gebe ich dir recht - das ein kleines eigentor bezüglich portierbarkeit... aber die nutzung von findfirst() / findnext() ähnelt viel mehr der Dateiauflistung unter linux / unix als die TOS variante.

Ich glaube um es auf einem Linux system zu kompilieren müsste man dann nur eine andere deklaration beachten, das war's dann schon.

[afalc060]

ich wollte nur sticheln.. das es irgendwie geht war mir schon bewusst. 

[m0n0]

Naja, wenn ich mich recht erinnere habe ich von anfang an gesagt das es in ANSI C keinen standard für das Verzeichnis auslesen gibt.... aber die PureC funktion kommt der Funktion aus dem POSIX standard schon sehr nahe.

Aber darum geht es ja noch garnicht. 

[ragnar76]

Ob Posix kompatibel oder nicht, hier gehts doch um Atari. Was wil man mit den Bootselector auf Linux oder Windows?  Also von daher sind doch spezielle Atari only funktionen doch gestattet.

[m0n0]

Natürlich, aber ich finde die nutzung von den Atari Funktionen bezüglich des Auslesens von Verzeichnissen nicht besser um die Aufgabe zu erfüllen....

Hier noch ein Beispiel für die nutzung:

Code: [Auswählen]

void file_list( char * path)
{
        /* variable vom typ int anlegen:  */
int err;

        /* variable vom typ ffblk anlegen: */
struct ffblk blk;

        /* erstes element auslesen: */
err = findfirst( path, &blk, 0xff);
while( err == 0 ){

                /* datei name ausgeben: */
Cconws( blk.ff_name );

                /* evt. weitere elemente auslesen ... : */
err = findnext( &blk );
}
}


[simonsunnyboy]

TOS calls sind deutlich vorzuziehen, denn diese Pure C Calls rufen nichts anderes auf, und dazu noch mit einem unnötigen Overhead (mehr Datenstrukturen, mehr Unteraufrufe, mehr Sprünge -> langsamer als nötig)

Ausserdem sind die TOS Aufrufe auf jeden anderen Atari Compiler portierbar, z.B. auch den gcc.

[ragnar76]

Roger that. Von mir aus kanns weiter gehen

[Arthur]

TOS calls sind deutlich vorzuziehen, denn diese Pure C Calls rufen nichts anderes auf, und dazu noch mit einem unnötigen Overhead (mehr Datenstrukturen, mehr Unteraufrufe, mehr Sprünge -> langsamer als nötig)

Ausserdem sind die TOS Aufrufe auf jeden anderen Atari Compiler portierbar, z.B. auch den gcc.

Du möchtest also lieber den kleinsten gemeinsamen Nenner nehmen damit die Portierbarkeit erhalten bleibt und es auch auf Uraltcompilern noch läuft? Ich finde M0n0 wählt einen guten Mittelweg da wir ja Pure C oder AHCC nehmen. Als Hausaufgabe kann man das Programm ja noch mit den alten TOS Calls parallel schreiben...

[simonsunnyboy]

Wenn TOS so uralt ist, wieso benutzt ihr dann alle so selbstverliebt seinen Nachfahren Mint, der auch noch erstaunlicherweise komplett kompatibel ist? 

Treibt was ihr wollt, aber sich auf einen Compiler und eine Library festzulegen ist unabhängig vom System immer schlecht. Das macht später nur Arbeit...wenn mal irgendetwas nicht mehr geht.

Ausserdem ist es eine gute Übung, sich mit den TOS Aufrufen vertraut zu machen. Für ein anständiges Atariprogramm (bei euch allen sehe ich ja das Wort GEM und GUI immer groß leuchten) kommt ihr nicht darum herum, systemkonform zu bleiben.

[m0n0]

Was mich an den TOS funktionen stört:

Nach Abschluß der Funktion steht der Verzeichniseintrag unter der Diskettenübertragungsadresse DTA, die mit Fgetdta und Fsetdta ermittelt bzw. festgelegt werden kann. Die Informationen können dann der Struktur DTA entnommen werden.

Es macht also Probleme wenn es Rekursiv aufgerufen wird. Das ein Verzeichnisbuam Rekursiv abgerufen werden soll, ist ja nicht nicht-selte.

Also ich persönlich muss mir das nicht geben, zumal das portieren der purec funktion einfach ist...(Falls es denn jemals gemacht werden sollte.)  Wenn jemand diesbezüglich einen Beispielcode posten kann, dann würde ich die evt. auch verwenden. Das würde den Code aber aufblaehen und nicht unbedingt leichter verständlich halten.

Und davon abgesehen halte ich die PureC Funktion für einfache - insbesondere wenn es darum geht novizen etwas zu zeigen. Bei der PureC version muss ich mich nicht um den DTA kram kümmern. bei der TOS Funktion schon.

[afalc060]

irgendwie fehlt hier so ein klein wenig die planung 

was soll das programm können?
zusammenstellen mögliche funktionen/prozeduren (pseudo-code)
erklärung der nötigen datenstrukturen (systemintern)
mögliche erweiterbarkeit?
usw

zudem sollte doch lieber basic gewählt werden

also das ist zumindest meine meinung 

[m0n0]

Was das programm können soll ist doch eigentlich schon besprochen:

- Bestimmte Programme / ACC / CPX beim booten de/aktivieren und im besten fall auch die Bootreihen folge verändern. Ausserdem muss es Coldfire kompatibel sein.

zudem sollte doch lieber basic gewählt werden

Welches ist denn Coldfire kompatibel?

Ich meine, wenn die leute lieber was anderes Programmieren wollen, dann gerne - aber ich bin dann raus.

mögliche erweiterbarkeit?

Sowieso - immer - ist ja open-source

[simonsunnyboy]

Die Rekursion ist C ist kein Problem. Mach die DTA in die du die Daten reinholst, immer lokal, auf dem Stack.

D.h. du deklarierst den Speicherplatz innerhalb deiner Funktion. Diese C-Funktion ist i.d.R. dann wieder reeentrant und kann regulär sich selbst aufrufen.

[Arthur]

Hast Du mal ein Beispiel-Code dazu?