|
unsigned DWORD
Einige hier verwenden die Bass Library.
Habe mir die Mühe gemacht meinen Code nochmals zu analysieren inklusive eingeschalteter Bereichs Prüfung. Das Problem ist folgendes. BASS_ChannelGetData und andere Funktionen verursachen ERangeError's (manchmal) weil hier DWord unsigned (LongWord 0 bis 4294967295.) verwendet wird. Treten also minus werte auf dann kracht es. Die Library von Bass verschickt aber mit seinem Archiv die API Definiert wie folgt.
Delphi-Quellcode:
function BASS_ChannelGetData(handle: DWORD; buffer: Pointer; length: DWORD): DWORD;
Zitat:
Also muss ich die Bereichsprüfung ausgeschaltet lassen oder gibt es vergleichbare signierte Data Typen für DWord? Wenn nicht ist diese Library ohne ausgeschalteter Bereichsprüfung bzw. ohne jedes einzelne Sample vorher auf negative werte zu analysieren nicht verwendbar mit Delphi. gruss |
AW: unsigned DWORD
?unsigned? DWORD... es gibt bei xWORD da 100% gar kein "signed"/"unsigned"!
Ein WORD ist ein "unsigned 16BIT-Wert" und ein "DWORD" ist ein "unsigned 32BIT-Wert" und ein "QWORD" ist ein "unsigned 64BIT-Wert"... in allen Programiersprachen und in allen OS und auf allen Plattformen vom 8Bit Microcontroler bis zur 64Bit ARM/Intel CPU Ein DWORD (unter 32Bit Delphi "cardinal") kann per Definition keinen ungültigen "Bereich" haben, da alle Werte von $00000000..$FFFFFFFF gültig und zugelassen sind. Das "zufällig" $FFFFFFFF in 32BitDelphi auch für "-1" beim "Integer-Typ"steht und der Compiler dadurch eventuell meint ein $FFFFFFFF Cardinal/DWORD sei "out of Range", ist ein FEHLER der Bereichsprüfung durch dem Compiler! -> mache ein Minimalbeispiel und eröffne im QC bei Emab/Idera einen Fall |
AW: unsigned DWORD
unsigned bedeutet meines Erachtens das die werte im Bereich zwischen 0.. xxx + liegen.
signed werte können aber im Bereich zwischen -1.. xxx + liegen. Oder warum denkst du das es sonst einen ERangeError mit dem Data Typ DWORD in Delphi gibt? Dieser liegt nun mal bekanntlich im Bereich von 0 bis 4294967295. Also nochmal vom Bass Forum.. Zitat:
 http://docwiki.embarcadero.com/Libra...em.Types.DWORDZitat:
DWORD is a 4-byte unsigned integer. oder DWORD ist unsigned ist gehüpft wie gesprungen.. Das kannst du für dich definieren wie du willst ändert aber nichts an der Tatsache. Zitat:
Wie gesagt es ist ein unsauberer Code wenn ich bedingt durch die Data Typen die Bereichsprüfung ausschalten muss. Ein gefrickel ohne gleichen. :evil: gruss |
AW: unsigned DWORD
Sorry das ist kein Gefrickel, das ist pure binäre Logik.
"Oder warum denkst du das es sonst einen ERangeError mit dem Data Typ DWORD in Delphi gibt?"... für negative "Integer" Werte oder Konstanten die man ohne Cast auf DWORD zuweist(obwohl die Typgröße im Speicher passt) und in 64BitDelphi macht es Sinn (z.B. unter Delphi64Bit ist es klar, das eine = $FFFFFFFFFFFFFFFF für eine z.B. "Integer:-1" Zuweisung einen Fehler bei der Bereichsprüfung wirft, denn $FFFFFFFFFFFFFFFF ist dann nunmal größer wie der maximale $FFFFFFFF im DWORD Typ) Sorry für die Faulheit alles in Hex zu schreiben, da es eh um das Verständnis der entsprechenden 2er Potenzen geht, ist es so sogar "klarer" worum es geht. (in dezimal erkenne ich den Zusammenhang auch immer nicht sofort, aber das Spiel mit den Nullen&Einsen kann man sich durchaus mal BitByBit zu Gemüte führen;) ) BASS nutzt bei seinen DLL Deglerationen die WindowsAPI und C konforme Variante, möglichst alles vorzeichenlos Sprachen portabel mit 100% fix bestimmten Typen zu definieren. BYTE = unsigned 8Bit 0..$FF WORD = unsigned 16Bit 0..$FFFF DWORD = unsigned 32Bit 0..$FFFFFFFF QWORD = unsigned 64Bit 0..$FFFFFFFFFFFFFFFF Mit signed Variablen mit wo möglich noch ala "Integer" variablem Wertebereich kann ich in eigenen Programmteilen leben, aber wenn es um externe Kopplungen geht sollte man wie BASS es macht sich an die üblichen Standards halten. Wenn was in Delphi nicht passt, liegt es oft nur an "schlecht" definierten/portierten Konstanten welche z.B. als "-1" deglariert sind und bei aktivierter Bereichsprüfung eben nicht für einen DWORD Parameter verwendet werden können. |
AW: unsigned DWORD
Zitat:
Zitat:
Selbst wenn die BASS-Funktion ein -1 zurückgibt, sollte ein Vergleich auf eine DWORD-Konstante mit dem Wert $FFFFFFFF das gewünschte Ergebnis bringen (für das Gegenteil hätte ich dann gerne ein konkretes Beispiel). Solange die anderen Rückgabewerte nicht über MaxInt liegen, sollte auch ein Cast auf Integer funktionieren. Eine simple Zuweisung eines DWORD auf einen Integer wird aber gelegentlich zu einem RangeError führen, aber das ist ja auch so gewollt. Es ist natürlich schlechter Stil, wenn eine Typdeklaration ein DWORD angibt, die Dokumentation dann aber von -1 spricht. Das ist aber eindeutig die Schuld der BASS-Library. Wobei auch Microsoft in der Windows-API gerne mal einen solchen Fehlgriff verbaut hat. |
AW: unsigned DWORD
Hallo,
warum nimmst du dann nicht einfach Integer statt DWORD? |
AW: unsigned DWORD
Mit gefrickel meine ich das wenn ich die Bereichsprüfung für Bass extra ausschalten muss.
Es hatte nichts mit deiner Person zu tun. ;) oder den Byte Werten an sich. Zitat:
Einfaches Beispiel. Mit Bereichsprüfung wirft diese Funktion einen ERangeError. Nicht bei normaler Behandlung aber wenn ich die Samples pushe über einen Equalizer.
Delphi-Quellcode:
function BASS_ChannelGetData(handle: DWORD; buffer: Pointer; length: DWORD): DWORD;
Delphi-Quellcode:
Wie du siehst ist das ne simple Sache destotrotz werden Fehler geworfen..
function BassDataAvailable: BOOL;
var BytesValid: DWORD; begin result := TRUE; BytesValid := BASS_ChannelGetData(gnAudioChannel, nil, BASS_DATA_AVAILABLE); //<< ERangeError if BytesValid = DW_ERROR then result := FALSE; end; Ich kann die Samples natürlich einzeln analysieren und anschließend BytesValid den Wert übergeben. Nur wo steckt der Sinn dahinter. Und dieser hier!
Delphi-Quellcode:
Ich muss hier die Samples separat vorher Analysieren um den Fehler zu beheben.
for C := 1 to 2 do
Inc(pInteger[C]); // WaveData von TWaveData über BASS_ChannelGetData
Delphi-Quellcode:
for C := 1 to 2 do
begin IntI := pInteger[C]; if (IntI > 32767) then IntI := 32767 else if (IntI < -32768) then IntI := -32768; pInteger[C] := IntI; end; gruss |
AW: unsigned DWORD
Anderes Beispiel.
Delphi-Quellcode:
function BassChannelGetLevel: DWORD;
begin result := 0; if gnAudioPause = FALSE then begin if gnAudioChannel <> 0 then result := BASS_ChannelGetLevel(gnAudioChannel); end; end; Zitat:
Zitat:
Code:
exception class : ERangeError
exception message : Fehler bei Bereichsprüfung. usw.. gruss |
AW: unsigned DWORD
Und wie ist
Delphi-Quellcode:
deklariert?
gnAudioChannel
|
AW: unsigned DWORD
Zitat:
Delphi-Quellcode:
Ich habe nichts davon hier irgendwas zu erzählen ;)
HSTREAM = DWORD; // sample stream handle
gnAudioChannel: HSTREAM; (Cardinal) Möchte nur das es funktioniert auch mit eingeschalteter Bereichsprüfung. Das es nicht geht sieht man ja. Bei diesen einfachen Beispielen kann man nichts falsch machen. Kann aber auch nichts an den Ergebnis ändern das von Bass geliefert wird. D2010.. gruss |
AW: unsigned DWORD
|
AW: unsigned DWORD
Zitat:
Frage mich nur warum man dann noch weiter eine Unit Publiziert obwohl das Problem ja schon seit längeren bekannt ist. Muss dann wohl alle DWords mit LongInt ersetzen. bzw.. nur die Rückgabe. Hoffe mal das es hilft. Das verstehe ich nicht ganz Zitat:
Delphi-Quellcode:
DW_ERROR = LongWord(-1);
Delphi-Quellcode:
if BytesValid = DW_ERROR then
gruss und Danke. |
AW: unsigned DWORD
C ist bezüglich Typisierung nunmal recht "lasch" und Delphi reagiert auf falsche Typen eben bissl allergisch.
Code:
In C mag das gehen.
int r=BASS_ChannelGetData(decoder, buffer, length);
if (r==-1) return 0; // error = no data Delphi erkennt hier, dass R niemals -1 sein kann und wären beides Variablen, dann würde Delphi die beiden Typen so weit vergrößern, dass sie gemeinsam in den selben Wertebereich passen, also 64 Bit signed > Int64 bei LongInt und LongWord In Deplhi kann man Typgrenzen nur durch harte explizite Casts umgehen.
Delphi-Quellcode:
Man könnte es zwar auch als
const BassNoData = DWORD(-1);
if r = BassNoData then Result := 0; // error = no data
Delphi-Quellcode:
deklarieren, aber dann würde es nicht mehr der Vorgabe entsprechen. :stupid:
const BassNoData = $FFFFFF;
|
AW: unsigned DWORD
Dann also
Delphi-Quellcode:
zu
DW_ERROR = LongWord(-1);
Delphi-Quellcode:
oder verstehe ich da wieder was falsch.
DW_ERROR = DWord(-1);
Aber nebenbei es nimmt kein ende. Habe es nach LongInt geändert. Nun bekomme ich hier einen ERangeError.
Delphi-Quellcode:
function BASS_ChannelGetLevel(handle: DWORD): LongInt;
Delphi-Quellcode:
function TMainApp.SolvePeak(nValue, nTotal: LongInt): LongInt;
begin Result := 0; if nTotal <> 0 then Result := (nValue * 98) div nTotal; end;
Delphi-Quellcode:
EDIT:
nLevel := BassChannelGetLevel;
nLpeak := SolvePeak(loword(nLevel), 128); nRpeak := SolvePeak(Hiword(nLevel), 128); Nein kann kein LongInt verwenden da die Daten die von Bass_ChannelGetdata geliefert werden im Bereich höher sind als bei LongInt (-2147483648 to 2147483647) Was für ein Schmarrn.. Da bleibt nichts anderes übrig als die Bereichsprüfung auszuschalten. Oder eine neuere Version von Delphi zu verwenden (Nur dafür fehlt mir die Kohle zu teuer für Hobby Programmierer). ;) Danke an alle für die Diskussion. gruss |
AW: unsigned DWORD
LongWord und DWORD ist das "Selbe".
Das Eine ist blos der Pascal-Name und das andere der C-Name. Wie zu lesen ist, ist BASS absichtlich unsigned, also kann man da nicht es nicht einfach signed ändern. Aber man kann integer explizit auf DWORD/LongWord casten. Gut, man könnte zwar geziehtl versuchen einige Stellen auf Integer zu ändern, damit der Code delphi-typischer wird, aber dann muß man bei Upgrades aufpassen. Alternativ kann man auch nur für bestimmte Units die Bereichsprüfung deaktivieren, so wie man es z.B. auch bei Verschlüsselungen/Hashs macht, welche implizit mit Überläufen "funktionieren", damit der Code einfacher bleibt. Die Starter-Edition ist ja aktuell gratis. (wenn man auf ein bissl was bezüglich Features verzichten mag, siehe die vielen Threads dazu) |
AW: unsigned DWORD
Zitat:
Hatte anschließend unerklärliche Speicherlecks und muste zurück zum letzten Build. gruss |
AW: unsigned DWORD
Du kannst aber auch gezielt die Bereichsprüfung nur in deiner Schnittstelle zu BASS deaktivieren (also in der Unit, in der du die Funktionen der DLL aufrufst), im Rest des Projekts aber aktiv lassen.
Dafür gibt es die Direktive
Delphi-Quellcode:
.
{$RangeChecks Off} bzw. {$RangeChecks On}
|
AW: unsigned DWORD
Zitat:
Da aber die Funktionen von und zu der Bass Schnittstelle aus der Main und diverser anderer Units aufgerufen werden denke ich das es nicht viel Sinn macht diese nur in der Bass Unit zu deaktivieren. gruss |
AW: unsigned DWORD
Wenn die Software nicht genug modularisiert ist, geht das natürlich schlecht.
Bei unserem Quelltext würde es genügen das in einer oder mehrerer Schnittstellenunits bei uns zu deaktivieren, weil nicht potenziell viele Units (und schon gar nicht eine Formular-Unit aus der GUI) darauf zugreifen würden. Unsere Business Logik greift dann nur auf diese Schnittstellenunits zu, die von uns selbst geschrieben sind. |
AW: unsigned DWORD
Zitat:
Ich habe schon versucht diverse Funktionen in dafür vorgesehene Units zu lagern. Aber für jede inklusive das Abspielen von Musik externe Units anzulegen ist nicht umsetzbar und würde nichts bringen da ich am ende doch von der Main Form darauf zugreifen muss. bsp. Bass, uBass (alle Funktionen die mit Bass zu tun haben) Muss ich aber von der Main Unit drauf zugreifen. BassVis, uBassVis Hier das gleiche usw.. Modular ist da nichts zu machen. gruss |
AW: unsigned DWORD
Zitat:
Dass man das nicht mal eben so nachträglich macht, ist aber sicher richtig. Deshalb habe ich ja auch nur gesagt, dass das dann schlecht geht, und nicht, dass du das ändern sollst. |
AW: unsigned DWORD
Zitat:
Aber gut zu wissen das man mit der Compiler Direktive so was machen kann. gruss |
AW: unsigned DWORD
Zitat:
Zitat:
|
AW: unsigned DWORD
Zitat:
Man muss nur dafür sorge tragen das der Daten Typ vom Bereich her passt. Oder warum denkst du das mit ein und der gleichen Funktion die von der DLL veröffentlicht wird mehrere unterschiedliche Sprachen miteinander kommunizieren können. Letztendlich zählt nur die Auswertung der Rückgabe. bsp. Nur weil ich unter Delphi einen PAnsiChar als Rückgabe einer Funktion erwarte ist die andere Sprache nicht dazu gezwungen exakt diese Namensgebung auch zu verwenden. Ausgabe: Library Delphi Delphi
Code:
VB6
function BASSVIS_FindPlugins(Kind: TBASSVIS_KIND_T; PluginPath: PAnsiChar; Searchflags: DWORD; Delimiter:AnsiChar=','): PAnsiChar; stdcall;
Code:
C++
Public Declare Function BASSVIS_FindPlugins Lib "bass_vis.dll" (ByVal Kind As BASSVISKIND, ByVal PluginPath As Any, ByVal Searchflags As Long, Optional(ByVal delemiter As Byte = 44) As Long
Code:
CSharp
char* BASSVISDEF(BASSVIS_FindPlugins)(BASSVIS_KIND_T Kind, char *PluginPath, DWORD Searchflags, char *Delemiter); DWORD BASSVISDEF(BASSVIS_GetModuleHandle)(BASSVIS_KIND_T Kind, char *Pluginfile);
Code:
So jetzt definiere du mir mal wer nun für den Daten Typ der Rückgabe zuständig ist.
private static extern IntPtr BASSVIS_FindPlugins(BASSVISKind A_0, [In, MarshalAs(UnmanagedType.LPStr)] string A_1, BASSVISGetPlugin A_2, byte A_3);
Mein DLL und oder die jeweilige Programmiersprache. Der Bereich des Daten Typ muss stimmen und da hatte ich nach dem Vorschlag nicht nachgesehen in dem Fall hätte ich ihn auch nicht geändert. Und wenn er nicht passt muss man ihn passend machen! Das obliegt aber der Sprache die meine DLL nutzen möchte, Nicht umgekehrt so wie du das denkst. VB6
Code:
Dim flist As String
Dim LngP As Long LngP = BASSVIS_FindPlugins( _ BASSVISKIND_WINAMP, _ PluginDir, _ BASS_VIS_FIND_RECURSIVE) flist = VBStrFromAnsiPtr(LngP) alist = Split(flist, ",")
Code:
So..
Public Function VBStrFromAnsiPtr(ByVal lpStr As Long) As String
Dim bStr() As Byte Dim cChars As Long On Error Resume Next ' Get the number of characters in the buffer cChars = lstrlen(lpStr) If cChars Then ' Resize the byte array ReDim bStr(0 To cChars - 1) As Byte ' Grab the ANSI buffer Call CopyMemory(bStr(0), ByVal lpStr, cChars) End If ' Now convert to a VB Unicode string VBStrFromAnsiPtr = StrConv(bStr, vbUnicode) End Function Und das es nicht funktioniert mit unsigned DWord und signed C++ bei eigeschalteter Bereichsprüfung liegt am ende schlichtweg daran das der Compiler unter D2010 bei der Bereichsprüfung fehlerhaft ist. Anders kann ich mir das nicht erklären. Gäbe es jetzt einen Daten Typ in Delphi der im Bereich von -4294967295 bis 4294967295 läge würde ich ihn nehmen dabei würde es für mich keine rolle spielen wie der Daten Typ benannt ist. gruss |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 05:13 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz