Droopy LIB Threadafe?

[onny]

Hi

Obwohl in SubSystems\UserLibThreadSafe\PureLibraries die Droopy Datei liegt, bekomme ich folgenden Error beim Compilieren mit Threadsafe:

PureBasic - Linker error
POLINK: error: Unresolved external symbol '_PB_StringBasePosition'.

Geht die Lib nun doch nicht Threadsafe? :,(

[dige]

.. die ist dann wohl veraltet und funktioniert nicht mehr mit PB4.20. Schau
mal ob Droopy schon was neues released hat...

[Rings]

nehmt doch einfach den source, dann klappts mit fast jedem subsystem.

[Hoto]

Die Lib ist eh Schrott, es gibt zwar eine Version für 4.20 aber selbst dort funktionieren einige Funktionen überhaupt nicht. Zumindest war das bei mir so als ich sie vor knapp 4 Wochen ausprobiert hatte. Da allerdings jaPBe einen Bug hat, der den Restart des Compilers nötig macht muss ich das noch mal testen um sicher zu gehen, dass es nicht daran lag...

http://sourceforge.net/project/showfile ... _id=211325

[Rings]

es ist doch der source dabei, einfach includieren und fertig.
Was die qualität der funktionen betrifft:
vieles wurde einfach aus den Foren übernommen,
auch mit Fehlern (zum Bsp unzureichende Dimensionierung bei StringBuffern) .
Die Kommentare in Französich lassen Urlaubsgefühle aufkommen.
Oft sinds tatsächlich nur einzeilige einfache Api-Wrapper.
Da aber der source ja dabei ist, selber grad schnell ändern.

[Hoto]

Ok, Kommando zurück, ich die Lib gerade noch mal installiert und merkwürdigerweise funktioniert nun das was ich gerade getestet hab und letztes mal absolut nicht wollte jetzt einwandfrei.

Wäre also möglich, dass doch alles geht. Hab natürlich auf die Schnelle nicht alles ausprobieren können, dafür sind es viel zu viele (für mein aktuelles Projekt sehr nützliche) Befehle. Gut dass ich es noch mal ausprobiert habe.

Dumm ist jedoch bei so einer Sammlung an Befehlen, dass die komplette Lib ins Programm eingebunden wird, auch wenn man nur einige wenige der Funktionen nutzt. Oder ist der Compiler so intelligent Prozeduren, die im eigentlich Programm nie aufgerufen werden, direkt weg zu lassen?

[Kaeru Gaman]

> Oder ist der Compiler so intelligent Prozeduren, die im eigentlich Programm nie aufgerufen werden, direkt weg zu lassen?

ist er.
nicht nur bei UserLibs, auch bei StandardLibs.
das ist einer der Gründe, warum PB so unglaublich schlanke Exen erzeugt.

[ts-soft]

Das macht eigentlich der Linker. Eine lib besteht aus einer oder mehrerer
obj, welche einzeln hinzugelinkt werden können, so das alle Abhängigkeiten
erfüllt sind. TailBite splittet automatisch in viele obj und die PB libs wurden
im lauf der Jahre auch nach und nach gesplittet.

Droopys Lib ist als solche in meinen Augen nicht verwendbar, da z.B. nicht
in allen Funktionen dynamische IDs (#PB_Any) verwendet werden, so das
man sich dann wundert, wenn eine geöffnete Datei nicht mehr offen ist oder
eine DLL nicht mehr geladen

[dige]

> Oder ist der Compiler so intelligent Prozeduren, die im eigentlich Programm nie aufgerufen werden, direkt weg zu lassen?

ist er.
nicht nur bei UserLibs, auch bei StandardLibs.
das ist einer der Gründe, warum PB so unglaublich schlanke Exen erzeugt.

stimmt leider nicht so ganz ... ich habe mir deshalb einen preprozessor gebaut, der wirklich alle ungenutzten Procs rausschmeisst..

[edel]

> Oder ist der Compiler so intelligent Prozeduren, die im eigentlich Programm nie aufgerufen werden, direkt weg zu lassen?

ist er.
nicht nur bei UserLibs, auch bei StandardLibs.
das ist einer der Gründe, warum PB so unglaublich schlanke Exen erzeugt.

Es kommt darauf an wie man die Lib schreibt. Schreibe ich alles in eine
Datei, landet auch alles in der Executable. Wie ts schon schrieb, hat das
aber gar nichts mit dem Kompiler zu tun.

Der Kompiler schreibt alle Proceduren in ASM Macros, werden diese
nicht aufgerufen, kompiliert sie FASM erst gar nicht mit. Leider ist PB
da etwas oberflaechlich.

Code: Alles auswählen

Procedure a()

EndProcedure

Procedure b()
  a()
EndProcedure

Hier wird keine Procedure aufgerufen, Procedure a landet aber trotzdem
in der Exe.