Auch wenn ein Boolean nur 2 Werte annehmen kann, so ist er mindestens ein Byte groß. Meist ist er sogar 4 Byte groß, wird von 32-Bit CPU's schneller verarbeitet. Die VARIANT-Boolean ist glaub ich 16-Byte großzigapeda hat geschrieben:aber eine Boolean Variable wäre doch gut. So eine hätte ich schon oft gebraucht aber ich musste dann immer die 1 Bytevar nehmen.
Vieleicht eine funktion zum Downloaden von Dateien aus dem Inet (URLDownloadToFile ist ja eine WinAPI)
Wünsche für PureBasic 4.0
- ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.

Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.

-
- Beiträge: 6291
- Registriert: 29.08.2004 08:37
- Computerausstattung: Hoffentlich bald keine mehr
- Kontaktdaten:
Gibts doch in ner UserLib, aber ich weiß nicht ob ich es euch verraten darf, das frag ich nachher mal im IRC, ob die Lib schon veröffentlicht wurde(Ich glaub schon).SlapY hat geschrieben:Ho,
Bin auch für komplette Ogreimplementierung sowie die abschaffung von Sprite3D !!!
Bye
Slap
Ps: Wie wärs wenn man Dlls über n Befehl in die Exe reinpacken könnte?...IncludeLibrary "" ^^
Richtig! Sprite3D sollte man nur für alle Systeme kompatibel machen.MVXA hat geschrieben:Und dann die CPU die ganzen 2D Sprite operationen durchführen lassen? Sprite3D baut auf DirectDraw auf, das wiederum auf die GPU aufbaut. D.h. mit Sprite3D befehlen spricht man die GPU quasi direkt an. Das abzuschaffen wäre ein teil tot der spiele entwicklung.AndyX hat geschrieben:Dann wäre noch gut, die Sprite3Ds abzuschaffen um den ganzen Dreh-und Zoom Kram auch mit normalen Sprites durchführen zu können.
Ich wünsche mir Doubles und 64-bit Floats(jaja, gibts zwar schon, aber nicht fürn Funktionsaufruf, da muss man immer die doppelte anzahl Parameter schreiben). Und CrossPlatformCompiling wäre auch nicht schlecht.
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
LastDatabaseRow()
Was ich mir wünchen würde für PB4.0:
LastDatabaseRow --> Zugriff auf die letzte Zeile/Datensatz einer Tabelle.
SeekDatabaseRow --> Zugriff auf eine bestimmte Zeile/Datensatz einer Tabelle.
Siehe auch:
http://forums.purebasic.com/english/vie ... php?t=2779
http://forums.purebasic.com/english/vie ... hp?t=12294
Die Database lib von PB hat FirstDatabaseRow(), NextDatabaseRow() und PreviousDatabaseRow() aber wieso keinen Befehl für die letzte Zeile?
LastDatabaseRow --> Zugriff auf die letzte Zeile/Datensatz einer Tabelle.
SeekDatabaseRow --> Zugriff auf eine bestimmte Zeile/Datensatz einer Tabelle.
Siehe auch:
http://forums.purebasic.com/english/vie ... php?t=2779
http://forums.purebasic.com/english/vie ... hp?t=12294
Die Database lib von PB hat FirstDatabaseRow(), NextDatabaseRow() und PreviousDatabaseRow() aber wieso keinen Befehl für die letzte Zeile?
Es gäbe da viele Gründe gegen Verwendung von Win-API!AndyX hat geschrieben:@zigapeda:Vieleicht eine funktion zum Downloaden von Dateien aus dem Inet (URLDownloadToFile ist ja eine WinAPI)
Wieso willst du es nicht mit der API-Lösung machen? Wegen Linux?![]()
![]()
1. API ist zwangsabhängig vom Online/Offline-Status des IE (das ist der gravierendste Grund!) und daher eigentlich nur in echten Online-Anwendungen verwendbar. Aber selbst hier ist diese Einschränkung eigentlich inakzeptabel! Ausserdem muss das immer gecheckt werden und der User auf den Umstand hingewiesen werden, warum die (Download-)Komponente gerade nicht funktioniert.
2. Die Caching-Kontrolle der APIs ist schwer kontrollierbar, da einige Parameter betriebssystemabhängig sind und andere seit Ewigkeiten nicht implementiert sind (obwohl dokumentiert!)
3. API läuft nur unter Windows
4. API ist teilweise Bestandteil des IE und auch von einigen seiner Einstellungen abhängig.
5. API ist in einigen Bereichen eingeschränkt und nur schwer erweiterbar.
Vorteil ist aber:
1. API ist relativ gut dokumentiert
2. Einbau ist einfach
3. Für die Bugfeiheit und Sicherheit ist MS verantwortlich (ist das ein Vorteil oder Nachteil?!)

Also ich würde eine direkte Unterstützung in PB auch begrüßen oder bzw. als eine komplette LIB für html und ftp (mit auth in allen Varianten, get, post, toFile, toMEM, Proxy, Errorhandling, ...). Das Beste in diesem Bereich, was frei verfügbar ist, sind derzeit wohl die Routinen von GPI, die aber leider noch nicht "vollständig" sind.
Dann fehlt mir da noch SNMP, was aber ja gerade in einem anderen Thread in Arbeit ist.
Ok, man kann alles sicherlich mit Bordmitteln von PB erledigen (wenn man pb mit den Network-Befehlen wirklich gut drauf hat und die RFCs umsetzen kann), aber das Thema ist so komplex und eigentlich so wichtig, da sehr vieles auf html bzw. Webdiensten (auch lokal im LAN) aufbaut, dass eine "native Unterstützung" sicherlich für viele Projekte eine wirkliche Erleichterung wäre.
Bei anderen Programmiersprachen gibt's genug frei verfügbaren, guten Code in diesem Bereich. Bei PB ist das, was User bisher veröffentlicht haben, eher dünn bzw. eben unvollständig.
Und wohl die wenigsten sind dazu in der Lage, sowas selber mit PB auf Basis der network-Befehle "zu erfinden" bzw. daraus guten und sicheren Code zu entwickeln.
@125:
Es gibt keine vollständige Implementierung für Webdownloads in PB. Für "normale" Downloads von freien Webserver schon, aber bei Proxy, auth und post/get hört's meist auf.
Gruß,
Martin
Und was ist das?: http://forums.purebasic.com/german/view ... y+downloaddeMattin hat geschrieben: aber bei Proxy, auth und post/get hört's meist auf.

Ich sagte ja schon, dass das von GPI bisher mit Abstand das Beste in diesem Bereich ist.125 hat geschrieben:Und was ist das?: http://forums.purebasic.com/german/view ... y+downloaddeMattin hat geschrieben: aber bei Proxy, auth und post/get hört's meist auf.

Nachteil bisher ist hier noch das fehlende "get" und das Problem, dass der Einbau in Threads etwas problematisch ist durch die teilweise verwendeten Stringbefehle. Bei Verwendung der API-Befehle gibt es diese Thread-Probleme nicht, so dass hiermit relativ problemlos und übersichtlich "threadsicher" gebaut werden können. Von der Funktionalität her bieten die GPI-Routinen ansonsten schon deutlich mehr als die sonstigen hier immer wieder geposteten API-Routinen und ich finde es absout super, was GPI hier gemacht hat!
Für eine Downloadroutine (Update des Programms über Internet o.ä.) in einer separaten exe sind die Routinen sicherlich klasse, aber wenn man ständig im Hintergrund des Hauptprogramms (eben in einem Thread) Webaktionen machen muss, dann muss man derzeit auf Tricks ausweichen wie z.B. den Download-Code in einer separaten exe auszulagern und dieses Programm dann vom Hauptprogramm aus fernsteuern und dann über shared memory o.ä. den Datenaustausch zwischen den Modulen realisieren.
Die ebenfalls möglichen Alternativen mit critical sections o.ä. machen das dann sehr unübersichtlich, da die an mehreren Stellen in den Routinen eingebaut werden müssen, so dass man die GPI-Routinen zwar verwenden kann, aber das hier eben nicht als einfache, universell verwendbare Befehlsbibliothek verwenden kann.
Threads mit lokalen Stringpointern würden das Problem ebenfalls lösen. Das wäre mein Wunsch für PB - gerne auch früher als für PB 4.0

Auch wenn jetzt hier wieder kommen sollte, dass man Threads nicht verwenden muss oder vermeidbar sind... Man sollte es verwenden dürfen oder können. Wenn das mit Threads so unsinnig wäre, dann wären die ja schliesslich auch gar nicht "erfunden" worden.

Gruß,
Martin
- ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
>> Für eine Downloadroutine (Update des Programms über Internet o.ä.)
Fällt mir zu ein, wer es nicht kann, sollte es auch lassen, es nervt wenn diese Routinen z.B. über meine Fernsehkarte ein Download versuchen, bloß weil das der erste Netzwerkadapter im System ist
.
GPI's Routinen funktionieren sehr gut, native Verfügbarkeit solcher oder ähnlicher Routinen wäre schon schön.
Fällt mir zu ein, wer es nicht kann, sollte es auch lassen, es nervt wenn diese Routinen z.B. über meine Fernsehkarte ein Download versuchen, bloß weil das der erste Netzwerkadapter im System ist

GPI's Routinen funktionieren sehr gut, native Verfügbarkeit solcher oder ähnlicher Routinen wäre schon schön.
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.

Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.

Also ich hätte da auch paar dinge für mich ganz wichtig wären.
- Debuger der mir mal ein paar mehr infos gibt und man z.b. breakpoints benutzen kann
- bessere Netzwerkfunktionen
- 64bit long
- nen ordentlichen VD (der jetzige is mir leider viel zu verbugt und versaut mir fast immer ein aufgebautes project)
- verbesserte OnError-Funktionen (die jetzigen sind leider nich so zuverlässige)
- abwärtskompatibilität für userlibs (man hat ja jetzt schon bei umstellen auf v3.93 gesehen was dann aus projecten wird die kann man dann nich weiter entwickeln bis die user mal nen update ihrer lib gemacht haben)
- na ja und paar bugs weniger wäre sicher auch nich schlecht.
- Debuger der mir mal ein paar mehr infos gibt und man z.b. breakpoints benutzen kann
- bessere Netzwerkfunktionen
- 64bit long
- nen ordentlichen VD (der jetzige is mir leider viel zu verbugt und versaut mir fast immer ein aufgebautes project)
- verbesserte OnError-Funktionen (die jetzigen sind leider nich so zuverlässige)
- abwärtskompatibilität für userlibs (man hat ja jetzt schon bei umstellen auf v3.93 gesehen was dann aus projecten wird die kann man dann nich weiter entwickeln bis die user mal nen update ihrer lib gemacht haben)
- na ja und paar bugs weniger wäre sicher auch nich schlecht.