amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > FGetC [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

30.08.2006, 23:07 Uhr

Ralf27
Posts: 2779
Nutzer 		Ich bin da in der dos.lib über FGetC, FWrite, FRead, ... gestolpert und wollte einfach mal testen wie FGetC() so läuft. Eigentlich ganz einfache paramterübergabe ( FGetC(handler&) ), aber wohl doch nicht, denn es geht nicht so wie es sollte. Da ich bei einem Programm viele Bytes wirklich teilweise Byteweise lese und dann auch wieder eine längere Strecke ganze Strecken wollte ich halt diese Befehle benutzen, aber es geht leider nicht.

Muß man dann die Datei anderst öffnen, oder wieso kann ich z.b. denn Befehl AnzahlBytes=Read(handler,buffer,1) nicht einfach durch Byte=FGetC(handler) ersetzen?

Sorry, bitte nicht mit Steinen werfen, wenn ich hier die Doku nicht verstehn I-) :lach: :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 00:30 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von Ralf27:

Muß man dann die Datei anderst öffnen, oder wieso kann ich z.b. denn Befehl AnzahlBytes=Read(handler,buffer,1) nicht einfach durch Byte=FGetC(handler) ersetzen?

Sorry, bitte nicht mit Steinen werfen, wenn ich hier die Doku nicht verstehn I-) :lach: :D

hmm, ich habe den Befehl zwar noch nicht benutzt, aber soweit Ich das sehe, ist das erstens ein gepufferter Befehl, d.h. bei einem Read(fh,buffer,1) wird immer nur ein Byte vom Filesystem gelesen, d.h. bei jedem byte wird dauf die Hardware zugegriffen, bei FGetC() wird aus einem Puffer gelesen, d.h. es wird zuerst der Puffer gefüllt. Damit ist FGetC() bei Bytezugriffen schneller.

Das andere Problem was du haben dürftest ist das FGetC() kein Byte zurückgibt sondern ein Long. d.h. -1L steht für Fehler oder FileEnde, damit darfst du nicht Einfach den Wert von FGetC() in ein Byte Wert konvertieren oder schreiben, du mußt dafür sorgen dass wenn FGetC() nicht -1 zurückgibt du nur die untersten 8 Bits berücksichtigst. Auso in der Art

code:
LONG v = FGetC(fh);
if (v !=-1) {
 char c = v & 0xff;
} else {
 file zu ende.
}

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 07:25 Uhr

Ralf27
Posts: 2779
Nutzer 		Das mit -1 ist mir klar, dennoch kommt quasi nur Müll raus. Werd wohl wieder dieses gebufferte rauswerfen. Das mit dem ein Byte lesen via Read() ist zwar auch nicht das richtige, aber nunja...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 08:39 Uhr

thomas
Posts: 7717
Nutzer
Schonmal mit byte$ = chr$(FGetC(handler&)) probiert ?

Oder mit

wert& = FGetC(handler&)
byte$ = chr$(wert&)

?

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 09:09 Uhr

Ralf27
Posts: 2779
Nutzer 		@thomas:

ja, hab ich. Deswegen versteh ich nicht, wieso das nicht so läuft wie es laufen sollte.

Im konkretenn Fall läuft dann die Dekodierung von z.b. BMP-Bildern direkt von der Festplatte (wenn diese zu groß sind für den Arbeitsspeicher und komprimiert sind) fehlerhaft ab, bzw. kommt müll raus.
Aber auch die Farbgebung ist dann fehlerhaft. Hab eben den Befehl Flush() gesehn, aber ich vermute doch einfach mal das ich diesen Befehl nur benötige, wenn ich auf die Festplatte schreiben will und dann auch sicher gehn will das alle gebufferten Daten geschrieben werden. Also dürfte das dann doch mit dem lesen nichts zu tun haben.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 09:14 Uhr

whose
Posts: 2156
Nutzer 		@Ralf27:

Endianess hast Du berücksichtigt?

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 09:34 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von whose:
Endianess hast Du berücksichtigt?

Ja, hab ich. Mit Read() hab ich z.b. bei einem Long 4 Bytes gelesen und dann im Speicher gedreht.

Mit Read() läuft es ja, nur FGetC() will da net so wie es sollte.

Und der Befehl FRead() wäre eigentlich auch ganz interesant.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 10:34 Uhr

thomas
Posts: 7717
Nutzer 		@Ralf27:

Du darfst Read und FGetC (unbuffered und buffered) nicht mischen. Wenn du FGetC benuzt hast, mußt du vor einem Read erst Flush aufrufen. Um das zu vermeiden, kannst du statt Read FRead benutzen.

Wenn du immer nur einzelne Bytes liest, sollten die gepufferten Routinen deutlich schneller sein als die ungepufferten.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 17:46 Uhr

Ralf27
Posts: 2779
Nutzer 		@thomas:

Ah, danke, das erklärt einiges!

Also, dann am besten alles von Read auf FRead umrüsten.

Bevor ich das teste:
Die einzelnen Bytes hab ich direkt gelesen, wenn der Arbeitsspeicher zu klein war für die ganze Datei. Bzw. z.b. bei komprimierten BMP oder IFF-ILBM. Also kommt da laufen Byteweise oder gleich mal lange Strecken direkt (mit Read).

Was ist aber wenn z.b. beim unkomprimierten, direkt von der Platte angezeigten Daten große Abstände zwischen den gelesenen Bytes sind? Ist da FRead oder Read besser? Bzw. hab ich vorhin gesehn das man auch noch einen Buffer einstellen kann. Bei den Parameter von FRead steig ich noch nicht so ganz durch, hab es aber auch noch nicht richtig versucht.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
31.08.2006, 19:39 Uhr

thomas
Posts: 7717
Nutzer
FRead funktioniert genauso wie Read, nur daß sich die Anzahl Bytes, die gelesen werden soll, aus zwei Werten zusammensetzt: Satzlänge und Anzahl Sätze. Wenn du die Satzlänge auf 1 setzt, funktioniert es wie Read.

Zum Thema große Abstände: ich weiß jetzt nicht, ob es ein FSeek gibt. Wenn nicht, bleibt dir ohnehin nichts anderes übrig als Flush() und Seek(). Und wenn du schonmal bei ungepuffert bist, kannst du auch Read benutzen.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]
01.09.2006, 00:09 Uhr

Ralf27
Posts: 2779
Nutzer 		Wow, dieses gebufferte lesen ist um Faktoren schneller als ohne!

Nochmal wegen FRead:
Was genau kann man da einstellen und wieso zwei Parameter? Ok, eins ist die Blockgröße und das zweite die Anzahl der Blöcke. Wie benutzt man das denn richtig? Bzw. hab ich noch gesehn das man auch mit SetVBuf denn Buffer einstellen kann.

Im konkreten Fall:
Ich möchte die BMP oder IFF-Datei direkt von Festplatte lesen und dekomprimieren. Das heißt, die Daten kommen fortlaufend von der Platte. Wie sollte man da am besten den Buffer einstellen, wenn ca. das maximale, am Stück gelesene Datenblock 127Bytes groß ist?

Bei FRead muß ich wohl immer die blockgröße auf 1 setzen, da ich ja flexsibel sein muß bei der länge. Aber was kann ich noch mit SetVBuf hinbekommen? Bzw. bringt mir dieser Befehl hier irgendwas?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
01.09.2006, 11:51 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Ich möchte die BMP oder IFF-Datei direkt von Festplatte lesen und dekomprimieren. Das heißt, die Daten kommen fortlaufend von der Platte. Wie sollte man da am besten den Buffer einstellen, wenn ca. das maximale, am Stück gelesene Datenblock 127Bytes groß ist?
Wenn Du weißt, dass Du kontinuierlich lesen willst, ist asynchrone I/O ohne Pufferung am schnellsten. Wenn Du dagegen zwischen den Lesevorgängen Seek()s durchführst, musst Du zwischen zwischen Anzahl der Festplattenzugriffe und möglicherweise überflüssig gelesenen Daten abwägen.

Da die Dateisysteme immer blockorientiert arbeiten und ganze Blöcke von der Platte lesen, sollte der Puffer möglich immer die ganzen gelesenen Blöcke aufnehmen. Also, wenn Du am Stück 127 bytes liest, sollte der Puffer mind. 512 bytes betragen (gut, das sollte er immer...). Höhere Puffergrößen (in Vielfachen der Blockgröße) verringern die Anzahl der Festplattenzugriffe, wenn Du die Daten wirklich brauchst, erhöhen aber auch die Menge gelesener Daten, die Du möglicherweise nicht brauchst.

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

[ - Antworten - Zitieren - Direktlink - ]

-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > FGetC [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.