Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Endlosschleife mit "for Ubyte..NEXT"

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
tom_dehn



Anmeldungsdatum: 05.10.2015
Beiträge: 30

BeitragVerfasst am: 07.12.2015, 22:05    Titel: Endlosschleife mit "for Ubyte..NEXT" Antworten mit Zitat

Hi,


ich konnte meinen Augen nicht trauen: DO FOREVER leicht gemacht.

Code:

for bCnt as uByte = 0 to 255
 ? bCnt;" ";
 if bCnt > 252 then
    Print "pause " & "bCnt=" & bCnt
    ?
    sleep
 EndIf
Next
END

'' [Compiler Ver 1.04/Win32 von der Stange]

Ärgerlich vor allem, weil diese Anomalität in einer sehr verschachtelten
"Pointer-auf-UByte als Index-in-UDT-überladenem-Operator-mit-einzeiliger-Mehrfachdereferenzierung"-Geschichte auftrat (das uByte muß mehrfach dereferenziert werde).
Hat mich wieder mal Stunden gekostet. Jammer Not Weh.

Tom
PS: Hab`s grad noch mal probiert. Faszinierend.
Im Original war das eigentlich das Konstrukt

" *(pDst+bCnt)=*(pTab + *(pSrc+bCnt)) "
Die Funktion dazu wird einer UDT als so eine Art CallBack mit überladenem LET eingetragen. Beim Rest des Codes fiel mir auf, wie nützlich und vor allem auch verständlich das "Überladen"-Tutorial on MOD ist. Daher, aus gegebenem Anlass:

Vielen vielen Dank an MOD!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4594
Wohnort: ~/

BeitragVerfasst am: 07.12.2015, 23:39    Titel: Antworten mit Zitat

Steht allerdings schon seit Ewigkeiten in der Referenz. lächeln
https://www.freebasic-portal.de/befehlsreferenz/for-next-zaehlschleife-281.html hat Folgendes geschrieben:
Achtung: Bei Ganzzahl-Datentypen ist es nicht möglich, bis zum höchstmöglichen Wert zu zählen (oder bis zum tiefstmöglichen bei negativer Schrittweite), da die Schleife nur verlassen wird, wenn die Zählvariable den Endwert überschreitet. Das tritt in diesem Fall jedoch nie ein. Wird beispielsweise versucht eine UBYTE-Variable von 0 bis 255 zählen zu lassen, wird die Schleife erst verlassen, wenn die Variable den Wert 256 oder höher erreicht. Den Wert 256 kann die UBYTE-Variable jedoch nicht speichern. Stattdessen wird sie nach 255 auf 0 zurückgesetzt und die Schleife läuft weiter.

_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 08.12.2015, 13:17    Titel: Antworten mit Zitat

Das wird übrigens leichter verständlich, wenn man sich das C-Äquivalent der Schleife anschaut:

Code:

for(uint8_t i = 0; i <= 255; i++)
...

Was passiert hier?
1. Iteration:
i = 0
Ist i <= 255? Ja...
i++
2. Iteration:
i = 1
Ist i <= 255? Ja...
i++
...
256. Iteration
i = 255
Ist i <= 255? Ja...
i++
257. Iteration
i = 0
Ist i <= 255? Ja...
i++

Ein Grund, warum ich Schleifen, die "<=" vergleichen nicht mag.

Eine Lösung wäre eine fußgesteuerte Schleife mit Post-Inkrement, aber das kann FB nicht:
Code:

do
...
while(i++ != 255);

Also muss man die dafür nötigen Kontrollstrukturen in FB selbst nachbauen:

Code:
Do
...
if(i = 255) then exit do
i+=1
Loop

_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
RockTheSchock



Anmeldungsdatum: 04.04.2007
Beiträge: 138

BeitragVerfasst am: 08.12.2015, 14:45    Titel: Antworten mit Zitat

Naja, man kann sich das IF mit dem exit do auch sparen.
Code:
Dim As Ubyte i=0
Do   
   Print i,
   '...   
   
   i+=1
Loop until i=0 'Überlauf 255+1 = 0
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 08.12.2015, 18:10    Titel: Antworten mit Zitat

Geht *prinzipiell* auch, aber ich würde mich nicht unbedingt darauf verlassen. Überläufe sind in C z.B. undefined behaviour bei vorzeichenbehafteten Datentypen. Bei vorzeichenlosen Datentypen wie hier im Beispiel ist das Verhalten definiert, aber wenn man nun z.B. ein Byte von 0 bist 127 zählen lassen will, könnte das problematisch werden - im Backend von FreeBASIC kann schließelich ein C- oder LLVM-Emitter sitzen, der dann sieht, dass diese Bedingung nie erfüllt werden kann und dann lustige Dinge mit dem Programm tut.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
tom_dehn



Anmeldungsdatum: 05.10.2015
Beiträge: 30

BeitragVerfasst am: 09.12.2015, 03:10    Titel: Antworten mit Zitat

Danke für den Hinweis auf die Referenz.

"Das wird übrigens leichter verständlich, wenn man sich das C-Äquivalent der Schleife anschaut:
for(uint8_t i = 0; i <= 255; i++)" etc....

Fein. aber ein uByte kann nun mal 255 werden, auch wenn C da wenig Verständnis zeigt.
Die Argumentation ist IMO ohnehin ein Molkereiprodukt.
Ich kann doch nicht allen Ernstes eine von vornherein als unzulänglich implementierte, weil jeglicher BASIC-Literatur widersprechende Funktion mit einem lapidaren Hinweis in der eigenen Referenz gesund beten (und welcher "alte" BASICler liest schon ausgerechnet die FOR..NEXT Referenz? Das hat zu funktionieren, wie seit ewigen Zeiten.
Und nicht seit ewigen Zeiten falsch zu funktionieren. Basta! Wo gibt`s denn sowas... maul mecker grummel)
Das folgende Beispiel zeigt deutlich, daß man es auch anders machen könnte. Vielleicht sogar als C-Compiler.
Code:

dim as uByte b
dim as integer ix=0 '' nur als, ahem, Referenz
b=0

b=0:do:b+=1:ix=b:if b=255 then goto l01:Loop
l01:
? b; " "; ix; " aha! geht doch!"
sleep
END

Und weil wir schon dabei sind:

Code:

/' unter DOS mit MASM ging 
   so was auch noch....
   Halt ohne C-Compiler, nur mit CPU ;-)
'/   
again:
   push cx
   push ax
   push si
sub ax,ax  ; stat xor oder mov...
   mov  cl,255
   inc  ax
   dec  cl
   jnz  again:
   mov  si,offset result
   mov [si],ax
   pop si
   pop ax
   pop cx
   ret
result:
   dw 0


Langsam habe ich es satt, mich dauernd mit dem fast schon als unantastbar ge/behandelten C-Backend zu beschäftigen. Wenn selbst BASICA, ach was, noch früher, MS-BASIC unter CP/M "meine" Bytes bis 255 - einschliesslich! - zählten, kommt jetzt so ein neumodisches Backend daher und wirft 3 Jahrzehnte BASIC-Erinnerungen auf den Müll.
Kommt vielleicht irgendwer mal auf die Idee, den C-Code einzufrieren und solche Ungereimtheiten manuell zu korrigieren?
Oder wenigstens den angeblich sich selbst kompilierenden Compiler so auszuliefern, daß dieses Selbst-Kompilieren ähnlich problemlos ist wie bei QB64?
Ich habe mal zwei Tage erfolglos getüftelt, um FB selbst zu übersetzen. Das klappte letztlich auch, aber das Resultat als solches wollte nicht mal simple Dreizeiler übersetzen.
Wieder mal schuld, na wer wohl? Der bitterböse C-Compiler. Und irgend welche MINGWesen, die sich ohne Rücksicht in die Root installieren, und dies und jenes, ach, es ist ein Kreuz...

Nix für ungut!

Tom
PS:
Das mit dem Selbstkompilieren war durchaus ernst gemeint. Der Nicht-C-ler hat keine Chance oder kaum eine, also ein kompletter Installer wäre ein Traum. Muss ja nicht alles auf dem Stand von heute morgen sein lächeln
[/quote]
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1208
Wohnort: Ruhrpott

BeitragVerfasst am: 09.12.2015, 10:33    Titel: Antworten mit Zitat

tom_dehn hat Folgendes geschrieben:
Wenn selbst BASICA, ach was, noch früher, MS-BASIC unter CP/M "meine" Bytes bis 255 - einschliesslich! - zählten, kommt jetzt so ein neumodisches Backend daher und wirft 3 Jahrzehnte BASIC-Erinnerungen auf den Müll.
Diese BASIC - Dialekte kannten als Ganzzahl ja auch nur den Datentyp Integer. Wenn du in deinem Beispiel den Typ wie in alten Zeiten auf Integer setzt, funktioniert die Zählschleife wie gewünscht.

Und wenn du bei den alten Dialekten bis zum Maximalwert von Integer gezählt hättest, hätte es schon damals nicht funktioniert
(32767 + 1 = -32768 bzw. 65535 + 1 = 0).

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
RWK



Anmeldungsdatum: 04.07.2011
Beiträge: 44

BeitragVerfasst am: 09.12.2015, 12:06    Titel: Antworten mit Zitat

Na, so ganz unrecht hat der Tom ja nicht. Ist schon ein nicht ganz nachvollziebares Verhalten. Es liegt wohl daran das For Next auf Überschreitung der oberen Grenze prüft, anstatt vor Erhöhung der Laufzeitvariablen auf Gleichheit.
Vielleicht kann man das im For-Loop ja auch auch irgendwelchen anderen Gründen nicht machen...Wer weiss....


Code:
dim as ubyte x, xUp
dim as ushort y
dim as uinteger z

for x = 250 to 255
   print x ; "-";
   if x = 0 then exit for
next x
 print
 print "fertig:";x
 sleep

for y = 65530 to 65535
   print y ; "-";
   if y = 0 then exit for
next y
 print
 print "fertig:";y
 sleep

for z = 4294967290 to 4294967295
   print z ; "-";
   if z = 0 then exit for
next z
 print
 print "fertig:";z
 sleep
'-------------------------------------------
x = 250: xUp = 255
do
   print x ; "-";
   if x = 0 then exit do

x += 1
IF x > xUp then exit do
loop
 print
 print "fertig:";x
 sleep
'-------------------------------------------
x = 250:
do
   print x ; "-";
   if x = 0 then exit do


IF x = xUp then exit do
x += 1
loop
 print
 print "fertig:";x
 sleep


Grüße
Rainer
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 09.12.2015, 14:34    Titel: Antworten mit Zitat

tom_dehn: Reg dich mal ab. Wie meine Vorredner schon erwähnten, kannten die "alten" BASIC-Dialekte gar keine UBytes. Insbesondere gab es keine Unsigned-Datentypen. Was wäre denn das Problem dabei einfach ein Integer statt UByte zu verwenden? Merke: Integers sind auf modernen Systemen sowieso minderstens genau so schnell oder schneller, auch wenn sie vier mal größer sind.
Außerdem hat es ja gar nichts mit dem C-Backend zu tun, ich hab dir ja nur erklärt wie man einfach verstehe kann, was hier passiert.

Der Vollständigkeit halber noch ein Vergleich was in QBasic passieren würde:


Korrekt, in QBasic kann man auch nicht bis zur oberen Grenze eines Datentyps zählen. Sobald man die 32767 erreicht, knallt's.

Also: Einmal tief durchatmen, abregen, akzeptieren dass das einfach ein Problem ist, das leider durch die BASIC-Syntax nicht so klar wird wie durch die C-Syntax, und dann ein (U)Integer statt einem UByte verwenden.
Natürlich kann man FOR auch anders implementieren, wie du schön demonstriert hast. Das hat dann aber nichts mehr damit zu tun, wie FOR eben in QBasic, FreeBASIC und auch vielen anderen Sprachen definiert ist.
Der einzige Unterschied zwischen QBasic und FreeBASIC ist dass FreeBASIC solche Integer-Überläufe nicht mit einem Fehler quittiert. Ansonsten ist das Verhalten aber dasselbe.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
tom_dehn



Anmeldungsdatum: 05.10.2015
Beiträge: 30

BeitragVerfasst am: 10.12.2015, 03:38    Titel: Abregen? Sich regen bringt Segen :) Antworten mit Zitat

@Jojo
meinte an mich gerichtet:
"Also: Einmal tief durchatmen, abregen, akzeptieren dass das einfach ein Problem ist, das leider durch die BASIC-Syntax nicht so klar wird wie durch die C-Syntax, und dann ein (U)Integer statt einem UByte verwenden.

Natürlich kann man FOR auch anders implementieren, wie du schön demonstriert hast. Das hat dann aber nichts mehr damit zu tun, wie FOR eben in QBasic, FreeBASIC und auch vielen anderen Sprachen definiert ist."

>>reicht erst mal. Jetzt rege ich mich erst recht, und: Zu Recht auf.

"Der einzige Unterschied zwischen QBasic und FreeBASIC ist dass FreeBASIC solche Integer-Überläufe nicht mit einem Fehler quittiert. Ansonsten ist das Verhalten aber dasselbe."

Ach- Qbasic hört auch bei 254 auf? Das ist das arithmetische Doppelte des Wertes, nach dem der vermeintliche Überlauf entsteht, also MSB gesetzt wird (Bit 7, normalerweise). Das ist aber kein CPU-Überlauf, sondern eine von Menschen getroffene Vereinbarung zur Definition von negativen Zahlen. Die Überläufe auf CPU-Ebene finden statt, wenn von 0 was subtahiert werden soll. Oder aber eine Addition bei "alle Bits schon gesetzt".
Ein Pseudo-Überlauf so mittendrin wie bei "meinem" Beispiel ist schlicht ein Programmierfehler. Eine Frage der Binärlogik.

OK. Wenn ich sage "bis einschliesslich 255", dann meine ich das auch so. Und wenn das Programm nicht bei der Hälfte des Wertes abbricht, weil das Resultat als "minus" vereinbart ist, sondern irgendwann kurz vor knapp, ist das für mich ein Fehler. Vermeidbar, erkannt und ignoriert.

Noch was. Ein Compiler, der die Konstante 255 nicht als unzulässig erkennt, na ja. Kann man noch durchgehen lassen. Darüber weiter unten mehr.

Aber die Zwangsläufigkeit, die v.A. Jojo C-ergeben hinnimmt, verstehe ich nicht. Gar nicht. Ds hat ja fast schon religiöse Anflüge. Jetzt rege ich mich schon wieder auf lächeln

Übrigens:

DIM b AS _UNSIGNED _BYTE
FOR b = 0 TO 255
PRINT b; " ";
NEXT b
SLEEP
END

funktioniert bestens. Wenn richtig implementiert. Näheres weiter unten, ich musste mich erst mal wieder spontan aufregen. Puh....

OK, die folgenden Zeilen hatte ich schon mal vorbereitet
Man will ja nicht verkommen lassen, und so.

na gut. Kein uByte in GW-BASIC un Co. Diese Runde geht an Euch.

Klar, damals, bei CP/M, da gab es keine UBytes oder so was. Daher freute ich mich schon auf die vollen 8 Bits der uBytes. Nicht auf ein Wischi-Waschi wegen Bugs.

Aber wenn ich schon weiss, daß uByte im C-Compiler FOR..NEXT fehlerhaft (im C-Sprachgebrauch vielleicht nicht 'fehlerhaft', sondern fatalistisch `so isses nu mal`zwinkern ) "umgebrochen" wird, dann muss ich als Compiler die Verwendung in derlei Schleifen entweder limitieren (keine uIntegers-als Zähler zulassen), oder aber im Assembler geschickter mit den (s.o.) Flags umgehen. Ach so, man hat ja ewig dieses Backend am Hals... der Assembler kommt erst hintendrein.

Also:

A:Entweder: LongtInts sind als Laufvariablen in FOR..NEXT nicht zugelassen. BASTA! Dann kann man unbesorgt die C-Merkwürdgkeiten vergessen. Workaround siehe Punkt B1.
Dann brauch ich vielleicht schon aus Mißtrauen überhaupt keine UInts, wenn ich deren Wertebereich nicht voll nutzen kann. Oder ist das nur abhängig von der Version des Backends?

B: Oder aber
1. "Kleinere" Argumente werden "aufgerundet" 8->16->32->64 Bit
Die kleineren Datentrpen werden entsprechen "aufgerundet".
Das ist Schmarren. Beim Bau nennt man so was Pfusch.
2. Beim NEXT nur den den CARDINAL-Wert arithmetisch UNDen (z.B: reg32 AND 0x0ffffL)
Aber auch das ist Lötzinn hoch 2. Braucht nicht der Mensch und auch nicht die Maschine.
oder aber:
3. Den Bug fixen. Die Lösung ist klar.

OK, back to the roots. Noch eine Anmerkung:

Das angebliche Äquivalent in c:

for (uint8_t i = 0; i <= 255; i++) {
code....
} //NEXT in "C": Brackets are not used for Code!

Angeblich. Warum "angeblich" ?

Das NEXT sollte und kann dafür verwendet werden, den Schlusscode der FOR-Schleife zu kodieren. Die geschweiften Klammern hingegen sind in C tatsächlich nur als LABELs zu verstehen.

Wem das noch nicht einleuchtet:
"Operator Next is called every time the iterator needs to be checked against the end value. This happens immediately after the call to its Operator For, and immediately after any calls to its Operator Step. Operator Next should return zero (0) if the loop should be terminated, or non-zero if the loop should continue iterating. The first time Operator Next is called, no statements in the For...Next body, if any, have been executed yet."

So steht es in der englischen CHM Datei, dort:KeyPgOpNext.html.
Zu FreeBASIC, versteht sich.

DO FOREVER , auch in C beliebt:
for (;zwinkern { ... }

So wie gaaaanz ganz früher manche C-Compiler sogar Formulierungen wie

for i!=123;i=y=funcXY(j);z-- { _code_ }

oder ähnlich wüstes Zeug akzeptierten. Vielleicht immer noch.

Wie geht das?
Weil jede Binnenfunktion (erkennbar am ";") für sich der Reihe nach auskodiert wird. SEEEEHR fehlerträchtig, über solche "gute alte Zeiten" jammere nicht mal ich.
Man kann und sollte das auch expliziter codieren.

Also ist das "gugg doch mal bei C rein" nicht nur in diesem Fall der falsche Rat. Noch dazu, wenn ein erkennbarer vermeidbarer Programmierfehler zwar seit "ewigen Zeiten" dokumentiert ist, aber nicht behoben wird.
Das Problem jedoch ist immer noch nicht gelöst.

Jojo meinte, wie scho erwähnt:
"...akzeptieren dass das einfach ein Problem ist, das leider durch die BASIC-Syntax nicht so klar wird wie durch die C-Syntax, und dann ein (U)Integer statt einem UByte verwenden. "

Sind wir hier in der Politik oder was? "Alternativlose" vermeidbare Programmierfehler hinnehmen? "Unklare" Syntax?
Schon vorher, Jojo,. hast Du geschrieben:
"Ein Grund, warum ich Schleifen, die "<=" vergleichen nicht mag. "
Du vielleicht nicht, die CPU schon:
JLE label: '' jump if Lower or Equal

Ist es so schwer, zuzugeben, daß die ganze Angelegenheit eine Schlamperei und ein Bug ist? Wahrscheinlich hätte man in der Zeit für diese Diskussion den Code schon ein Dutzend mal korrigieren können.

Ach ja, weil eingangs versprochen:Wenn man wo anders hinschaut als direkt nach C, geht folgender Code locker durch. Ich mein, auch so wie erwartet.-

DIM b AS _UNSIGNED _BYTE
FOR b = 0 TO 255
PRINT b; " ";
NEXT b
SLEEP
END

Man glaubt es kaum. Dieses verkappte UByte läuft bis 255 anstandslos durch. Und im QB64 - Verzeichnis findet sich auch so eine MINGWase oder wie das heisst, und der Compiler kompiliert sich auch selbst. Angeblich mit dem selben Backend lächeln wie FreeBASIC.
Also auch mit Hilfe von mingw und solchen Sachen, allerdings so, daß man ihn auch ohne Fernstudium tatsächlich selbst kompilieren, und dann das Ergenis auch läuft. So,. wie erwartet. Nicht nur syntaktisch unpräzise missverständlich zwinkern
QB64 kennt aber (noch?) nicht das geniale Stringhandling von VB. Dafür aber auch keinen Überlauf, wo er definitionsmäßig gar nicht auftreten kann: Bei 254.

Wie dem auch sei. Da selbst unter FreeBASIC _meine_ Schleife funktioniert, könnte man ja mal am C-Code fummeln. Das mit der Programm-Logik geht nämlich auch in C. Wie es geht, wurd beschrieben. Jetzt muss es wer machen. Wenn ich nen selbstkompilierenden Compiler hätte,dann hätte ich auch die Zeit...

So long

Tom
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 10.12.2015, 03:59    Titel: Antworten mit Zitat

Ok, ich werde auf deine Wall of Text nicht im Detail anworten, nur die Punkte rauspicken, die du immer noch nicht verstanden hast:

Zitat:
Ach- Qbasic hört auch bei 254 auf?

Nein, QBasic kennt wie alle älteren BASIC-Dialekte keine (U)Bytes, der kleineste Datentyp ist dort Integer mit Werten von -32768 bis 32767. Zählt man in QBasic mit einer FOR-Schleife bis 32767, kommt es nach der letzten gewünschten Ausführung zu einem Überlauf. Bei FreeBASIC würde das Programm nicht crashen wie in QBasic, sondern einfach endlos weiterlaufen.
Wie gesagt, wenn du von 0 bis 255 zählen willst, verwende halt ein UInteger statt einem UByte.

(Edit: Kompilierte QBasic-Programme haben sich übrigens wie FreeBASIC verhalten, d.h. der Überlauf resultierte dort auch in einer Endlosschleife.)


Zitat:
Ist es so schwer, zuzugeben, daß die ganze Angelegenheit eine Schlamperei und ein Bug ist? Wahrscheinlich hätte man in der Zeit für diese Diskussion den Code schon ein Dutzend mal korrigieren können.

Ich brauch damit ja nicht umgehen, ich bin hier nicht derjenige der in BASIC programmiert. zwinkern Aber, wie schon in den vorherigen Posts herausgehoben wurde, liegt hier prinzipiell einfach kein Bug vor, weil FreeBASIC dasselbe tut wie QBasic, und das Ziel von FreeBASIC ist / war es eben auch 99% kompatibel zu QBasic zu sein.

GW-BASIC tut übrigens dasselbe, und das ist noch älter als QBasic:



Selbst wenn GW-BASIC, CP/M, etc. einen Datentyp UByte gehabt hätten, hätten sie sich genau so verhalten wie FreeBASIC. Klar, man kann's auch anders implementieren, du brauchst mir nicht zu erklären wie man das in Assembler bauen würde, das weiß ich auch. Das hat dann aber halt nichts mehr damit zu tun, wie praktisch alle FreeBASIC-Vorgänger sich verhalten haben. Oder auch so ziemlich jede andere Programmiersprache auch.
Ich sehe also keine Grundlage für weitere Diskussionen hier.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.


Zuletzt bearbeitet von Jojo am 10.12.2015, 22:52, insgesamt 2-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1208
Wohnort: Ruhrpott

BeitragVerfasst am: 10.12.2015, 10:44    Titel: Antworten mit Zitat

@tom_dehn:
Ich verstehe gar nicht, worüber du dich aufregst. Daß die Laufvariable einer FOR..NEXT - Schleife hinterher den Wert Endwert + 1 hat, ist ein bekanntes Verhalten aller BASIC - Versionen (zumindest aller, die ich kenne).
Code:
Dim As Integer x
For x = 0 To 255
Next
? x
Sleep
Falls gewünscht, kannst du den Inhalt der Variable im weiteren Programmverlauf ganz normal weiterverwenden. Schon deshalb wäre eine Neuimplementierung nicht ganz unproblematisch.

Und zur Entspannung (du scheinst es nötig zu haben zwinkern) noch eine kleine Denksportaufgabe: Finde heraus, warum das hier nicht funktioniert.
Code:
Dim As Integer x
For x As Integer = 0 To 255
Next
? x
Sleep

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
tom_dehn



Anmeldungsdatum: 05.10.2015
Beiträge: 30

BeitragVerfasst am: 13.12.2015, 17:34    Titel: Antworten mit Zitat

grindstone hat Folgendes geschrieben:
@tom_dehn:
Ich verstehe gar nicht, worüber du dich aufregst.

Und zur Entspannung (du scheinst es nötig zu haben zwinkern) noch eine kleine Denksportaufgabe: Finde heraus, warum das hier nicht funktioniert.
Code:
Dim As Integer x
For x As Integer = 0 To 255
Next
? x
Sleep

Gruß
grindstone

...und das Ziel von FreeBASIC ist / war es eben auch 99% kompatibel zu QBasic zu sein.
Und das bringt den Übrlauf pünktlich bei 127+1=b AND 0x80== rat mal.
Das mit dem Denksport ist fies; so ein nerventötender Meckerer wie ich hat gar keine Zeit, sich mit so merkwürdigen Sachen wie Lebenszeiten von x´en zu befassen. Aber: Wenn ich beide Schleifen direkt hintereinander schalte, klappt es nach Theo Rettich wieder. Zauberei ?!?
Irgendwie haste ja recht: Du programmierst nicht in BASIC (habe ich so verstanden) und willst daher "Dein" C hochhalten. Erinnert mich an meine Schulzeit, wo man entweder Beatles mochte oder die Stones. Aber niemals nicht beide.
Ach ja, btw: Was bedeutet Deiner Ansicht nach das "U" in UByte? "U"eberlaufgefährdung?
Fuer heute und kuenftig Schluss mit dem Thema. Mit diesem. OK.

Tom
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4594
Wohnort: ~/

BeitragVerfasst am: 13.12.2015, 23:32    Titel: Antworten mit Zitat

Wieso soll Jojo C hochhalten wollen? Wenn dem so wäre, würde er dir raten, C zu verwenden anstatt FreeBASIC. Was er dir tatsächlich sagen will, nämlich dass ein Zählen bis zum letzten Zahlenelement auch in QBasic noch nie funktioniert hat, scheinst du offenbar nicht zu verstehen oder nicht realisieren zu wollen. Soll mir recht sein, schließen wir die Diskussion, da kommen wir sowieso nicht voran.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1208
Wohnort: Ruhrpott

BeitragVerfasst am: 14.12.2015, 09:38    Titel: Antworten mit Zitat

tom_dehn hat Folgendes geschrieben:
Wenn ich beide Schleifen direkt hintereinander schalte, klappt es nach Theo Rettich wieder. Zauberei ?!?
Nein, keine Zauberei, sondern ganz normales, logisches Verhalten (Stichwort: Scope Block).

Aber nemored hat recht: Sparen wir uns die weitere Diskussion. traurig

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
tom_dehn



Anmeldungsdatum: 05.10.2015
Beiträge: 30

BeitragVerfasst am: 15.12.2015, 21:36    Titel: Antworten mit Zitat

grindstone hat Folgendes geschrieben:
tom_dehn hat Folgendes geschrieben:
Wenn ich beide Schleifen direkt hintereinander schalte, klappt es nach Theo Rettich wieder. Zauberei ?!?
Nein, keine Zauberei, sondern ganz normales, logisches Verhalten (Stichwort: Scope Block).

Aber nemored hat recht: Sparen wir uns die weitere Diskussion. traurig

Gruß
grindstone


Da hat wohl wer die Ironie versäumt. Keine Angst: Ich war`s nicht.
Ich zitiere mich selbst, vor dem Zusammenhänger:
"Das mit dem Denksport ist fies; so ein nerventötender Meckerer wie ich hat gar keine Zeit, sich mit so merkwürdigen Sachen wie Lebenszeiten von x´en zu befassen."

Zur Bedeutung dieser Worte:
Falsch! Im Joghurt sind gar keine Knochen.

Tom
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
tom_dehn



Anmeldungsdatum: 05.10.2015
Beiträge: 30

BeitragVerfasst am: 15.12.2015, 21:42    Titel: Antworten mit Zitat

nemored hat Folgendes geschrieben:
schließen wir die Diskussion


Sagte,dachte und schrieb ich auch schon. Gestern.

Grüsse
Tom
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz