 |
Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 564
Wohnort: Jüterbog
|
 Verfasst am: 05.11.2015, 21:07 Titel: |
 |
|
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 |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1231
Wohnort: Ruhrpott
|
| Verfasst am: 10.04.2016, 09:36 Titel: |
|
|
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 |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4644
Wohnort: ~/
|
| Verfasst am: 10.04.2016, 11:05 Titel: |
|
|
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 |
|
|
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1231
Wohnort: Ruhrpott
|
| Verfasst am: 10.04.2016, 11:24 Titel: |
|
|
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 |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4644
Wohnort: ~/
|
| Verfasst am: 10.04.2016, 11:30 Titel: |
|
|
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. 
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1231
Wohnort: Ruhrpott
|
| Verfasst am: 10.04.2016, 11:45 Titel: |
|
|
Sicher, ich weiß auch, was gemeint ist. Ich dachte nur, so wird es für Anfänger vielleicht etwas klarer. 
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
| Nach oben |
|
|
Keltin
Anmeldungsdatum: 23.08.2012
Beiträge: 10
|
| Verfasst am: 02.03.2017, 14:42 Titel: |
|
|
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 |
|
|
Sebastian
Administrator
Anmeldungsdatum: 10.09.2004
Beiträge: 5969
Wohnort: Deutschland
|
|
| Nach oben |
|
|
Keltin
Anmeldungsdatum: 23.08.2012
Beiträge: 10
|
| Verfasst am: 06.03.2017, 14:19 Titel: |
|
|
OK dann werd ich das da mal versuchen.
MfG
Keltin |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4644
Wohnort: ~/
|
| Verfasst am: 01.01.2018, 21:37 Titel: |
|
|
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 |
|
|
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1231
Wohnort: Ruhrpott
|
| Verfasst am: 01.01.2018, 22:19 Titel: |
|
|
| 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 |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4644
Wohnort: ~/
|
| Verfasst am: 01.01.2018, 22:30 Titel: |
|
|
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. 
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 |
|
|
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1231
Wohnort: Ruhrpott
|
| Verfasst am: 01.01.2018, 23:34 Titel: |
|
|
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 |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4644
Wohnort: ~/
|
| Verfasst am: 01.01.2018, 23:56 Titel: |
|
|
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 |
|
|
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1231
Wohnort: Ruhrpott
|
| Verfasst am: 02.01.2018, 00:49 Titel: |
|
|
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 |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 02.01.2018, 15:38 Titel: |
|
|
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 |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4644
Wohnort: ~/
|
| Verfasst am: 02.01.2018, 17:09 Titel: |
|
|
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. 
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.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020
Beiträge: 85
|
| Verfasst am: 20.10.2021, 11:25 Titel: BUG oder NICHT ? |
|
|
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 |
|
|
hhr
Anmeldungsdatum: 15.07.2020
Beiträge: 104
|
| Verfasst am: 20.10.2021, 19:17 Titel: |
|
|
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 |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020
Beiträge: 85
|
| Verfasst am: 20.10.2021, 22:08 Titel: |
|
|
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 |
|
|
|
|
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.
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
