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:

FB-Referenz - Bug-Report
Gehe zu Seite Zurück  1, 2, 3, 4, 5, 6  Weiter
 
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
Muttonhead



Anmeldungsdatum: 26.08.2008
Beiträge: 561
Wohnort: Jüterbog

BeitragVerfasst am: 05.11.2015, 21:07    Titel: Antworten mit Zitat

Japp, in die Richtung wirds wohl gehen. DKL hat im englischen forum auch die kodierung erwähnt. Ich habe die Woche bei einer meiner benutzten IDEs einmal an diesen Einstellungen herumgespielt und haben den möglichen zusammenhang nicht erkannt.

Interessant war eigentlich dabei das anscheinend fbc v1.03 da etwas flexibler reagiert.

Via wp mutton
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1208
Wohnort: Ruhrpott

BeitragVerfasst am: 10.04.2016, 09:36    Titel: Antworten mit Zitat

Hallo,

ich habe da eine Unstimmigkeit in der Befehlsreferenz entdeckt:
Zitat:
Referenz - Parameterübergabe
...
Anmerkung:
Bis einschließlich FreeBASIC v0.16 wurden Parameter an Prozeduren standardmäßig BYREF übergeben; seit FreeBASIC v0.17 ist dies nur noch der Fall, wenn mit der Kommandozeilenoption Befehlsreferenzeintrag-lang deprecated oder -lang qb compiliert wird. Andernfalls geht FreeBASIC ab Version v0.17 vom Standard BYVAL aus.


Dialect Differences:

In -lang fb dialect, Byval is the default parameter passing convention for all built-in types except String and user-defined Type which are passed Byref by default.
In -lang qb and -lang fblite dialects, Byref is the default parameter passing convention.

Zumindest was Strings betrifft, hat die englische Referenz recht. Diese werden standardmäßig ByRef übergeben.

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
nemored



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

BeitragVerfasst am: 10.04.2016, 11:05    Titel: Antworten mit Zitat

Vielen Dank, das muss bei der Revision durchgerutscht sein - unter BYVAL steht es korrekt. Ich habe es ausgebessert und bei der Gelegenheit auch die historischen Elemente "Verhalten bis v0.16" etwas weniger in den Fokus gerückt.

Wer korrekturlesen will:
https://www.freebasic-portal.de/befehlsreferenz/parameteruebergabe-453.html hat Folgendes geschrieben:
Anmerkung:
Standardmäßig werden Zahlendatentypen (INTEGER, DOUBLE usw.) BYVAL übergeben, STRINGs und UDTs dagegen BYREF. Arrays werden immer BYREF übergeben; eine Änderung der Übergabemethode ist hier nicht möglich. Wenn das Programm mit der Kommandozeilenoption -lang deprecated oder -lang qb compiliert wird, verwendet der Compiler die Übergabemethode, die bis einschließlich FreeBASIC v0.16 verwendet wurde: alle Parameter werden dann standardmäßig BYREF übergeben.

_________________
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: 10.04.2016, 11:24    Titel: Antworten mit Zitat

Vielleicht sollte es besser heissen:

"Arrays werden immer BYREF übergeben; der Versuch, ein Array BYVAL zu übergeben, erzeugt eine Fehlermeldung."

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
nemored



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

BeitragVerfasst am: 10.04.2016, 11:30    Titel: Antworten mit Zitat

Allerdings verursacht bei Arrays auch der Versuch, das Schlüsselwort BYREF zu verwenden, eine Fehlermeldung. Mal schauen, was andere so sagen; ich kann mit beiden Formulierungen leben. happy
_________________
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: 10.04.2016, 11:45    Titel: Antworten mit Zitat

Sicher, ich weiß auch, was gemeint ist. Ich dachte nur, so wird es für Anfänger vielleicht etwas klarer. lächeln
_________________
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
Keltin



Anmeldungsdatum: 23.08.2012
Beiträge: 10

BeitragVerfasst am: 02.03.2017, 14:42    Titel: Antworten mit Zitat

Hallo,

ich hab da scheinbar ein Problem mit einen Bug in fbc 1.05.0 (x86) bei Condbroadcast.
Mein Programm läuft meist ein paar Tage bis dieser Fehler auftritt und bleibt dann einfach irgendwann stehen, da der Haupt Thread der Condbroadcast ausführt danach nicht mehr weiterläuft.

Im groben hat mein Programm diesen aufbau:
Code:

Dim Shared WaitMutex         As Any Ptr
Dim Shared WaitCond            As Any Ptr
WaitMutex = MutexCreate()
WaitCond = Condcreate()
...
Starten der Threads
...
Do
   ...
   Print "Vor Condbroadcast"
   Condbroadcast(WaitCond)
   Print "Nach Condbroadcast"
   Sleep 60000,1
   ...
Loop

Sub Thread (...)
   ...
Do
   Print "Vor Condwait"
   MutexLock WaitMutex
   Condwait(WaitCond, WaitMutex)
   MutexUnlock WaitMutex
   Print "Nach Condwait"
   ...
   Print "Thread Loop Ende"
Loop
End Sub


Die Zeit von 1 Minute reicht für die Subs mehr als aus um durchzulaufen und wieder bei Condwait zu warten.
als Ausgabe hat man dann etwa das bei 3 Threads:

    Vor Condbroadcast
    Nach Condwait
    Nach Condwait
    Nach Condwait
    Thread Loop Ende
    Thread Loop Ende
    Thread Loop Ende
    Vor Condwait
    Vor Condwait
    Vor Condwait


Das "Nach Condbroadcast" fehlt wenn der Fehler auftritt und da bleibt dann alles stehen. Solange alles normal läuft ist das "Nach Condbroadcast" natürlich mit drin. Daher meine vermutung mit den Bug in Condbroadcast.

Bisher ist der Fehler nur unter Windows aufgetreten. Unter Linux hatte ich entweder glück oder dort gibt es den Bug nicht.

MfG
Keltin
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Sebastian
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 5969
Wohnort: Deutschland

BeitragVerfasst am: 02.03.2017, 17:02    Titel: Antworten mit Zitat

Hallo,

das Thema müsstest du am besten bei den FreeBASIC-Compiler-Entwicklern melden.
Siehe dazu: http://www.freebasic.net/wiki/wikka.php?wakka=CompilerReportingBugs

Der Thread hier im Forum bezieht sich nur auf Fehler in unserer deutschsprachigen FB-Befehlsreferenz.

Das fbc-Entwickler-Team wird hier vermutlich nicht mitlesen, schon gar nicht auf Deutsch. lächeln

Viele Grüße!
Sebastian
_________________

Der Markt regelt das! | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Keltin



Anmeldungsdatum: 23.08.2012
Beiträge: 10

BeitragVerfasst am: 06.03.2017, 14:19    Titel: Antworten mit Zitat

OK dann werd ich das da mal versuchen.

MfG
Keltin
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



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

BeitragVerfasst am: 01.01.2018, 21:37    Titel: Antworten mit Zitat

Bei den Funktionen der CRT steht unter tolower:
"Konvertiert ein Zeichen in Kleinbuchstaben (verwendet dazu ASCII-Kodierung)."
Wenn ich das richtig sehe, wird Unicode verwendet, oder irre ich mich? Bei toupper natürlich analog.
_________________
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: 01.01.2018, 22:19    Titel: Antworten mit Zitat

https://www.proggen.org/doku.php?id=c:lib:ctype:tolower hat Folgendes geschrieben:
Notice that what is considered a letter may depend on the locale being used; In the default "C" locale, an uppercase letter is any of: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z, which translate respectively to: a b c d e f g h i j k l m n o p q r s t u v w x y z.

In other locales, if an uppercase character has more than one correspondent lowercase character, this function always returns the same character for the same value of c.


https://www.proggen.org/doku.php?id=c:lib:ctype:tolower hat Folgendes geschrieben:
tolower() gibt den kleinen Buchstaben des übergebenen Zeichens zurück. Wird der ASCII-Code eines großen A ('A') übergeben erhält man den ASCII-Code des kleinen Buchstabens ('a'). Übergibt man ein ansonsten beliebiges Zeichen oder einen kleinen Buchstaben, wird der übergebene ASCII-Code unverändert zurückgegeben.


Das sieht mir nicht nach Unicode aus.

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
nemored



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

BeitragVerfasst am: 01.01.2018, 22:30    Titel: Antworten mit Zitat

Ich bekomme halt z. B. folgendes:
Code:
#include once "crt.bi"
print tolower(209)

Rückgabe: 241 (also Unicode für ñ statt Ñ). Getestet unter Windows 10, fbc 1.5
"ein ansonsten beliebiges Zeichen" kann sich durchaus auf Nicht-Buchstaben beziehen, wenn der Verfasser des Artikels nur ASCII im Blick hatte.

edit: Ich merke gerade, dass die zweite Formulierung sowieso sehr unglücklich gewählt ist; das würde ja heißen, dass nur asc("A") in asc("a") gewandelt wird und jedes beliebige andere Zeichen nicht. grinsen

noch ein edit: Die Funktion arbeitet korrekt für den Unicodeblock "Lateinisch-1, Ergänzung" (bis Unicode-Nummer 255); z. B. wird das sich inmitten von Großbuchstaben befindliche Zeichen 215 (ein Kreuz wie beim Vektorprodukt) korrekterweise nicht umgewandelt. Ab 256 klappt es nicht mehr. Scheinbar wird die Funktion mit (eingabe AND 255) gefüttert.
_________________
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: 01.01.2018, 23:34    Titel: Antworten mit Zitat

Ich verstehe die Formulierung im ersten Link ("may depend on the locale being used") so, daß jeweils gemäß der aktuellen Codepage gewandelt wird.

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
nemored



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

BeitragVerfasst am: 01.01.2018, 23:56    Titel: Antworten mit Zitat

Liegt da dann ein Bug im fbc vor? tolower(257) sollte ja dann zumindest 257 zurückgeben, und nicht 1.
_________________
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: 02.01.2018, 00:49    Titel: Antworten mit Zitat

Halte ich für eher unwahrscheinlich. In den Beschreibungen ist ja auch immer nur von ASCII die Rede, also Wertebereich 0...255.

Code:
#Include "crt.bi"
For x As Integer = 0 To 10000
   Print x;" ";tolower(x);" ";Chr(tolower(x))
   Sleep 100
Next
Sleep

tolower scheint wirklich <Eingangswert AND 255> zu verarbeiten. Nur bei <Eingangswert AND 255> = 0 wird der Originalwert zurückgegeben. Man müsste mal sehen, was ein entsprechendes C - Programm zurückliefert.

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
Jojo
alter Rang


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

BeitragVerfasst am: 02.01.2018, 15:38    Titel: Antworten mit Zitat

tolower und toupper nehmen ja in C ein int und geben auch ein int zurück, also sind durchaus Werte > 255 möglich. Man sollte sich aber absolut nicht darauf verlassen und diese Funktionen besser nicht zu benutzen, eben weil sie Locale-Abhängig sind. Besser ist es, eine eigene Transformationsfunktion zu schreiben die nur auf ASCII arbeitet (falls nötig) oder eben explizit auf UTF-8 arbeitet, oder in einen WString/WChar konvertiert und darauf arbeitet, etc...
_________________
» 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
nemored



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

BeitragVerfasst am: 02.01.2018, 17:09    Titel: Antworten mit Zitat

Auch in der entsprechenden FreeBASIC-Include-Datei nimmt die Funktion ein LONG entgegen und gibt ein LONG zurück, verarbeitet aber offenbar nur ein UBYTE. Wenigstens schön konsequent:
Code:
#include once "crt.bi"
print chr(tolower(256+asc("A")))

Wenn eine Funktion Werte zulässt, die es dann falsch verarbeitet, halte ich das durchaus für einen Bug. lachen
Tut jetzt aber in diesem Thread nichts zur Sache - faktisch funktioniert die Funktion nur im ASCII-Bereich zuverlässig, und damit passt das, was in der Referenz steht. happy
_________________
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
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 81

BeitragVerfasst am: 20.10.2021, 11:25    Titel: BUG oder NICHT ? Antworten mit Zitat

Hallo, bei meinem speziellen Primzahlsieben, kam ich auf einen Fehler in FB.

Windows 10 64bit

Also, man hat vom Typ UBYTE: ,C01...unwichtig,da string
a01=0:C01=RIGHT("0"+STR(a01),2)
a02=2:C02=RIGHT("0"+STR(a02),2)
a03=6:C03=RIGHT("0"+STR(a03),2)
a04=12:C04=RIGHT("0"+STR(a04),2)
a05=14:C05=RIGHT("0"+STR(a05),2)
a06=20:C06=RIGHT("0"+STR(a06),2)
a07=24:C07=RIGHT("0"+STR(a07),2)
a08=26:C08=RIGHT("0"+STR(a08),2)
a09=30:C09=RIGHT("0"+STR(a09),2)
a10=36:C10=RIGHT("0"+STR(a10),2)
a11=42:C11=RIGHT("0"+STR(a11),2)
a12=44:C12=RIGHT("0"+STR(a12),2)
a13=50:C13=RIGHT("0"+STR(a13),2)
a14=54:C14=RIGHT("0"+STR(a14),2)
a15=56:C15=RIGHT("0"+STR(a15),2)

CODE vom Typ UINTEGER

CODE=0:PRINT CODE
CODE=CODE+2^(a15-a01):PRINT CODE
CODE=CODE+2^(a15-a02):PRINT CODE
CODE=CODE+2^(a15-a03):PRINT CODE
CODE=CODE+2^(a15-a04):PRINT CODE
CODE=CODE+2^(a15-a05):PRINT CODE
CODE=CODE+2^(a15-a06):PRINT CODE
CODE=CODE+2^(a15-a07):PRINT CODE
CODE=CODE+2^(a15-a08):PRINT CODE
CODE=CODE+2^(a15-a09):PRINT CODE
CODE=CODE+2^(a15-a10):PRINT CODE
CODE=CODE+2^(a15-a11):PRINT CODE
CODE=CODE+2^(a15-a12):PRINT CODE
CODE=CODE+2^(a15-a13):PRINT CODE
CODE=CODE+2^(a15-a14):PRINT CODE
CODE=CODE+2^(a15-a15):PRINT CODE

Problem, die Summe CODE ist falsch, es fehlt die Addition mit und 2^2, 2^0



Ausgabe:
0
72057594037927936
90071992547409920
91197892454252544
91215484640296960
91219882686808064
91219951406284800
91219955701252096
91219956774993920
91219956842102784
91219956843151360
91219956843167744
91219956843171840
91219956843171904
91219956843171904
91219956843171904
91219956843171904

Ergebnis am Ende: 91219956843171904
Richtig wäre : 91219956843171909

Duale Darstellung ist maßgebend.

1010001 0000010100 0001000101 0001000001 0000010100 0001000000 Freebasic
1010001 0000010100 0001000101 0001000001 0000010100 0001000101 eigentlich

Wieso ?

Gruß


Nachtrag:

Weise ich a01 - a15 UINTEGER zu kommt auch Blödsinn, inbesondere die Addition der kleinen Zahlen am Ende erhöht nicht mehr "CODE"

0 72057594037927936 7.205759403792794e+016
90071992547409920 1.801439850948198e+016 <- ??? wieso, ist uinteger
91197892454252544 1125899906842624
91215484640296960 17592186044416
91219882686808064 4398046511104
91219951406284800 68719476736
91219955701252096 4294967296
91219956774993920 1073741824
91219956842102784 67108864
91219956843151360 1048576
91219956843167744 16384
91219956843171840 4096
91219956843171904 64
91219956843171904 4
91219956843171904 1
91219956843171904
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
hhr



Anmeldungsdatum: 15.07.2020
Beiträge: 84

BeitragVerfasst am: 20.10.2021, 19:17    Titel: Antworten mit Zitat

Vielleicht liegt es an der Potenzierung (^)?
Diese arbeitet mit Double, wie man in der englischsprachigen FB-Referenz nachlesen kann.
Integer-Typen werden in Double umgewandelt, dann wird potenziert und ggf. zurückverwandelt.
Die Genauigkeit reicht für große Longint, Ulongint und Integer64-Zahlen nicht aus.
Eigentlich sollte man Integer-Typen nur mit elementarer Arithmetik bearbeiten: +,-,*,\,mod.
Zum Arbeiten mit Zweierpotenzen kann man noch Shl und Shr verwenden.
Das ist kein Fehler von FB, gcc oder gas, das ist in der CPU so eingebaut.

Übrigens, mit der FB-Bigint-Bibliothek (big_int-lib.zip), die auf
https://www.freebasic.net/forum/viewtopic.php?f=14&t=25082&p=224933&hilit=Big+Int+overload.bi#p224933
zu finden war, kann man auch Primzahltests machen.
Damit konnte ich die Beispiele
10^99+84878086452295590307+d , d=0,2,6,12,14,20,24,26,30,32
10^99+707220670972957883551+d , d=0,2,6,8,12,18,20,26,30,32
aus https://forum.qbasic.at/viewtopic.php?p=110405#110405 nachvollziehen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 81

BeitragVerfasst am: 20.10.2021, 22:08    Titel: Antworten mit Zitat

Hallo hhr !
Das mit dem Primtest interessiert mich brennend.

Kannst Du mir mal Schritt für Schritt folgendes erklären ?

big_int-lib.zip, wo ist genau der Download.

Was muss ich in FB genau anwerfen als Programm , um zum Bsp. 10^101+3 als prim zu bekommen.

Das wäre unendlich großartig !

Gruß
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php
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
Gehe zu Seite Zurück  1, 2, 3, 4, 5, 6  Weiter
Seite 5 von 6

 
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