Hex-string memory compression functions in C (MS C-Cpp) ( 50 prozent Speicher reduktion bei 0 pr

high schrieb:

ja dan lol mal schön...du spass vogel

lol

Müssen wir uns wirklich auf dem Level unterhalten ..
lowbyte hat es ja ein gesehen und ist sicher nicht so ein Profi wie du.
Auserdem hat er die convchartohex() funktion angepasst. Und der rest ist geschmackssache.
Und wen man halt als Ausgangswert bei den Hashfunktionen einen char vector hat.
Dan kommt man wohl nicht drum rum,den speicher zu reduzieren.Oder man lässt es auch einfach sein.

high

pointercrash**

+fricky schrieb:

pointercrash() schrieb:

Meine absoluten Haß- Parameter bei RS232 sind übrigens Klartext per 8N1 zu senden .. wer errät, warum?

wenn man irgendwo im bitstrom einhakt, kann's passieren, dass man nur noch quatsch bekommt und es synchronisiert sich auch nicht mehr.

Das ist nur die halbe Antwort, aber soweit richtig. Das 8. Bit ist bei Klartextmeldungen (ASCII bis max 127d) auf die maximal sinnloseste Art eingesetzt worden. Keine Parity, die einen framedrop/resync auslösen würde, stattdessen abstruse wait/timeout- Regeln.
Ist mir aber nicht nur einmal untergekommen, sondern mir fallen spontan zwei Beispiele ein. Erstmal so ein Laborzeugs- Produzent, der seine Zentrifugen, Öfchen, Pipettierautomaten per RS232 zusammengenagelt hat, dieselbe Krankheit nochmal bei Autotestständen, sogar herstellerübergreifend.

Zum Thema:
Was soll so eine Compression im Source- Bereich? Man müßte sie entweder als Source- Nachbesserung unterbringen, aber da wäre es geeigneter, das GeBinHexe von vorneherein rauszuwerfen. Als externes Programm ist das Methoden- Sammelsurium von Zip&Co sicherlich effektiver. Als schnellen Packer dazwischen, an bestimmte Dateiendungen gebunden, könnte man das an die eine oder andere Geschichte rantricksen, aber mit Sicherheit auch das eine oder andere System stören.
Klartext- Hex- Dateien auf diese Art zusammenzuraffen, macht keinen Sinn, jedenfalls sehe ich gar kein Einsatzgebiet.

Scheppertreiber

32 Byte zippen *hmmpfff* Na ja, weißt Du wie der Algorythmus funktioniert ?

pointercrash**

Scheppertreiber schrieb:

32 Byte zippen *hmmpfff* Na ja, weißt Du wie der Algorythmus funktioniert ?

Grob, ja. Da wird so eine Library angelegt, die quasi die optimalen Grundvektoren auf das dekomprimierte Objekt enthält und die braucht mehr als 32 Byte.
Aber ein Intel- Hex- File ist meist etwas fetter als 32 Byte. So 600 kB Intel- Hex per Zip zusammengestaucht sind eher 30 kB als 300.

lowbyte

helo

Meine Idee war es eigentlich auf diese weise ein Hex-string wie eine MD5 Signatur,zu komprimieren um so hash tables anzulegen.
Aus 32byte(stringsize) also 50% zu sparen. und dan die 16 Byte Binary in das File zu schreiben.

Oder ist die Idee völiger schwachsinn..?

lowbyte

Scheppertreiber

Nein, die Idee ist kein Schwachsinn. Hätte ich 1 Mio solcher Werte zu speichern
würde ich mir darum auch Gedanken machen. Bei den heutigen Speichermengen ist das
aber nicht mehr so wild. Selbst eine Mio Werte wären 32 MB, nicht die Welt. Das
packt sogar Windows

lowbyte

helo

Das dachte ich auch ..
Wie würdest du jetz die bytes in einem file speicher?

etwa so?
write(string_komprimiert ,sizeof(string komprimiert) ,1 ,ptr);

Das file sollte nach meine vorstellungen so aussehen.

zeile: (komprimierte 16byte),password

Ich habe aber jetz milliarden von werten..

lowbyte

helo

Das ist noch meine Variante der memory_reduction()

char memory_reduction(a_ptr ,b_ptr)
{
   char a ,b;

   a = convchartohex(a_ptr);
   b = convchartohex(b_ptr);

   a = a<<4;
   return b|a;

}

lowbyte

pointercrash() schrieb:

+fricky schrieb:

pointercrash() schrieb:

Meine absoluten Haß- Parameter bei RS232 sind übrigens Klartext per 8N1 zu senden .. wer errät, warum?

wenn man irgendwo im bitstrom einhakt, kann's passieren, dass man nur noch quatsch bekommt und es synchronisiert sich auch nicht mehr.

Das ist nur die halbe Antwort, aber soweit richtig. Das 8. Bit ist bei Klartextmeldungen (ASCII bis max 127d) auf die maximal sinnloseste Art eingesetzt worden. Keine Parity, die einen framedrop/resync auslösen würde, stattdessen abstruse wait/timeout- Regeln.

rs232 ist ja nur ein ziemlich primitiver 'physical layer'. wer ascii,8N1 für'nen dauerhaften datenstrom verwendet, hat selber schuld. aber in den meisten fällen, wobei daten 'burst'-weise gesendet werden, geht's dann ja doch. ausserdem gibt's ja tolle protokolle in software, die das ganze stabiler machen (HDLC und ähnliches).