| |
| |
|
 | Hallo Frank,
weil ich die dll nur für Bereiche benutzte hätte ich da noch ein paar Ideen für die neue Version.
1. DeleteTags erweitern:
Original:
Q : Long - Zeiger auf einen Speicherbereich (oder String) mit den Quelldaten
A : Long - Anzahl Bytes, die in Q bearbeitet werden sollen
Z : Long - Zeiger auf einen Speicherbereich (oder String), in den die Zieldaten geschrieben werden
C1: Long - ANSI-Code des Startbytes
C2: Long - ANSI-Code des Endbytes
F : Long - Flags
Erweitert:
Q : Long - Zeiger auf einen Speicher-Bereich/String ODER einer Datei
A : Long - Wie oben, aber bei 0 denn gesamten Bereich
Z : Long - Zeiger auf einen Speicher-Bereich/String ODER einer Datei, in den die Zieldaten geschrieben werden
C1: Long - StartString >>> ist bestimmt Flexibeler als nur ein Byte
C2: Long - EndString
C3: Long - Gültiger String d.h. MUSS enthalten sein.
C4: Long - Ungültiger String d.h. darf NICHT enthalten sein.
F : Long - Flags
Beispiel (hab addr() mal weggelassen) :
DeleteTags(a#, 0, C:ext.txt, <, >, .de, ftp:, 1)
würde zum Beispiel alle [...]  Tags in die Test.txt Schreiben aber keine Tags mit ftp:
2. Findbytes weitersuchen lassen (wie CountStrings) und die Fundstellen in einem Bereich übergeben, das erspart einem die Schleifen und man umgeht das Manko die dll mehrmals aufzurufen >>> Verzögerungszeit.
3. Da eigentlich jede dll das Manko hat eine gewisse Latenzzeit zu haben und man ab einer bestimmten Anzahl von Aufrufen nicht mehr in denn genuss von Assembler-Speed kommt. Dachte ich mir, du könntest Parallel zur dll auch eine Compilerte lib für Profan2CPP anbieten. Eine lib wird doch komplett in denn C++-Code mit eingebettet.
Voteil: keine Latenzzeit mehr wie bei einer dll- also volle Assemblerpower 
Beispiel: Wenn ich einen kompletten Bereich durchsuchen möchte und nach jedem Treffer weiter Suchen lasse dann Wird Profan2CPPs - Mempos bei 500 Aufrufen schneller als Findbytes, anders CountStrings, da kommt kein C++ Code mit und CountStrings hat bestimmt denn selben Code wie Findbytes nur in einer Schleife wäre doch vergleichbar oder...... ? 
Also, ich habe mir das so vorgestellt:
Jeder C++ Compiler hat doch auch einen Inline-Assembler, da packts du denn ProSpeed-Code hinein und compilierts daraus eine Profan2CPP lib.
Wie das genau abläuft weiß ich nicht (kann kein C++), aber der Sebastian könnte dir da bestimmt weiterhelfen und dir auch mitteilen wieviel Arbeit ungefähr da hinter steckt.
Jetzt bitte nicht Hauen, wenn ich zuviel von der neuen ProSpeed verlangt habe und Sachen dabei sind (wie Punkt 3) die vielleicht nicht realisierbar sind.
Waren nur ein Paar Ideen, die mir so durch denn Kopf gingen.
Freu mich schon auf die Antworten 
Also, in diesem Sinne...
Gruß Ingo |
|
| |
| |
| |
|
|
Frank
Abbing | Hi Ingo,
dann will ich deine Ideen mal miesmachen 
> 1. DeleteTags erweitern:
>
> Original:
> Q : Long - Zeiger auf einen Speicherbereich (oder String) mit den Quelldaten
> A : Long - Anzahl Bytes, die in Q bearbeitet werden sollen
> Z : Long - Zeiger auf einen Speicherbereich (oder String), in den die Zieldaten geschrieben werden
> C1: Long - ANSI-Code des Startbytes
> C2: Long - ANSI-Code des Endbytes
> F : Long - Flags
>
> Erweitert:
> Q : Long - Zeiger auf einen Speicher-Bereich/String ODER einer Datei
Hier rate ich dir, ReadFileFast() zu benutzen. Ist doch nur eine Zeile mehr Aufwand und hat einige Vorteile.
> A : Long - Wie oben, aber bei 0 denn gesamten Bereich
Problem: Die Dll kann nicht sicher das Ende eines Bereichs bestimmen. Bereiche müssen nicht zwingend mit einem Nullbyte enden. Und die Funktion ist so flexibel, dass auch die Null als Zeichen vorkommen darf.
> Z : Long - Zeiger auf einen Speicher-Bereich/String ODER einer Datei, in den die Zieldaten geschrieben werden
... eine Zeile, WriteFileFast()...
> C1: Long - StartString >>> ist bestimmt Flexibeler als nur ein Byte
> C2: Long - EndString
> C3: Long - Gültiger String d.h. MUSS enthalten sein.
> C4: Long - Ungültiger String d.h. darf NICHT enthalten sein.
Die vier nehme ich mal als Anregung.
> F : Long - Flags
>
> Beispiel (hab addr() mal weggelassen) :
>
> DeleteTags(a#, 0, C:ext.txt, <, >, .de, ftp:, 1)
> würde zum Beispiel alle [...] Tags in die Test.txt Schreiben aber keine Tags mit ftp:
Nö, würde nicht... nicht vergessen Strings in Addr() zu packen
>
> 2. Findbytes weitersuchen lassen (wie CountStrings) und die Fundstellen in einem Bereich übergeben, das erspart einem die
> Schleifen und man umgeht das Manko die dll mehrmals aufzurufen >>> Verzögerungszeit.
Gute Idee.
> 3. Da eigentlich jede dll das Manko hat eine gewisse Latenzzeit zu haben und man ab einer bestimmten Anzahl von Aufrufen
> nicht mehr in denn genuss von Assembler-Speed kommt. Dachte ich mir, du könntest Parallel zur dll auch eine Compilerte lib
> für Profan2CPP anbieten. Eine lib wird doch komplett in denn C++-Code mit eingebettet.
> Voteil: keine Latenzzeit mehr wie bei einer dll- also volle Assemblerpower
Meine Libraries gebe ich nur ungern weiter. Und darum sage ich dir auch nicht, dass es Tools gibt, um aus Dlls Libs zu generieren. Sogar statische Libs... Ne, sage ich dir nicht!
> Beispiel: Wenn ich einen kompletten Bereich durchsuchen möchte und nach jedem Treffer weiter Suchen lasse dann Wird Profan2CPPs
> - Mempos bei 500 Aufrufen schneller als Findbytes, anders CountStrings, da kommt kein C++ Code mit und CountStrings hat
> bestimmt denn selben Code wie Findbytes nur in einer Schleife wäre doch vergleichbar oder...... ?
Ja.
> Also, ich habe mir das so vorgestellt:
> Jeder C++ Compiler hat doch auch einen Inline-Assembler, da packts du denn ProSpeed-Code hinein und compilierts daraus eine
> Profan2CPP lib.
> Wie das genau abläuft weiß ich nicht (kann kein C++), aber der Sebastian könnte dir da bestimmt weiterhelfen und dir auch
> mitteilen wieviel Arbeit ungefähr da hinter steckt.
Beim Linken fällt sowieso eine Lib ab. Nur gebe ich die nicht weiter. Und ich sage dir auch nicht, dass... - hatten wir ja schon.
> Jetzt bitte nicht Hauen, wenn ich zuviel von der neuen ProSpeed verlangt habe und Sachen dabei sind (wie Punkt 3) die vielleicht
> nicht realisierbar sind.
> Waren nur ein Paar Ideen, die mir so durch denn Kopf gingen.
Danke. Anregungen sind immer gerne willkommen!
Hauen tue ich nicht  ... |
|
| |
| |
| |
|
|
 | Vonwegen hauen tust Du nich 
aber komm nur du schufft - komm nur 
 |
|
| |
| |
| |
|
|
| Hi,
>>> dann will ich deine Ideen mal miesmachen
Hab ich mir schon gedacht... 
>>> Nö, würde nicht... nicht vergessen Strings in Addr() zu packen
Würde doch, schau mal was ich obendrüber geschrieben habe 
>>>Beispiel (hab addr() mal weggelassen) <<< nur wegen der übersicht
>>>Meine Libraries gebe ich nur ungern weiter.
Sorry, ist wohl Falsch angekommen...
Ich habe nicht erwartet das du deinen Code hergibst,ich dachte nur die libs wären schon Compiliert, so wie die Units aus Profan dann wäre es ja auch kein Problem mit dem Urheberrecht ...hab halt nicht so die Ahnung von ASM & C++.
>>>Und darum sage >>>ich dir auch nicht, dass es Tools gibt, >>>um aus Dlls Libs zu >>>generieren. Sogar statische Libs... >>>Ne, sage ich dir nicht!
SuperTools, echt........ und das sagst du einem nicht C++ Coder? ... Super Tip  |
|
| |
| |
| |
|
|
Frank
Abbing | Hi,
> Würde doch, schau mal was ich obendrüber geschrieben habe
> >>>Beispiel (hab addr() mal weggelassen) <<< nur wegen der
> Übersicht
Argh! Kann ich nicht mehr lesen hast hast dus nachträglich editiert... 
Im Ernst, habs wohl überlesen.
> SuperTools, echt........ und das sagst du einem nicht C++
> Coder? ... Super Tip
Bin ja selber keiner  . Und nur ausnahmsweise... |
|
| |
| |
| |
|
(909)
Deutsch
English
Français
Español
Italia