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
 
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: 507
Wohnort: Jüterbog

BeitragVerfasst am: 05.11.2015, 22: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: 860
Wohnort: Ruhrpott

BeitragVerfasst am: 10.04.2016, 10: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
nemored



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

BeitragVerfasst am: 10.04.2016, 12: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: 860
Wohnort: Ruhrpott

BeitragVerfasst am: 10.04.2016, 12: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
nemored



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

BeitragVerfasst am: 10.04.2016, 12: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: 860
Wohnort: Ruhrpott

BeitragVerfasst am: 10.04.2016, 12: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
Keltin



Anmeldungsdatum: 23.08.2012
Beiträge: 10

BeitragVerfasst am: 02.03.2017, 15: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: 5900
Wohnort: Deutschland

BeitragVerfasst am: 02.03.2017, 18: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
_________________
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, 15: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: 4214
Wohnort: ~/

BeitragVerfasst am: 01.01.2018, 22: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: 860
Wohnort: Ruhrpott

BeitragVerfasst am: 01.01.2018, 23: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
nemored



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

BeitragVerfasst am: 01.01.2018, 23: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: 860
Wohnort: Ruhrpott

BeitragVerfasst am: 02.01.2018, 00: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
nemored



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

BeitragVerfasst am: 02.01.2018, 00: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: 860
Wohnort: Ruhrpott

BeitragVerfasst am: 02.01.2018, 01: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
Jojo
alter Rang


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

BeitragVerfasst am: 02.01.2018, 16: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: 4214
Wohnort: ~/

BeitragVerfasst am: 02.01.2018, 18: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
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
Seite 5 von 5

 
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