ich möchte ein paar Verschlüsselungsalgorithmen implementieren. Dazu brauche ich zu allererst einen Datentyp, der sehr große Zahlen verwaltet. Zur Übung möchte ich ihn gerne selbst implementieren, damit ich mein C++ mal wieder etwas verbessere.

Ich möchte, dass die Zahlen beliebig groß werden können und eigentlich nur durch den Speicher limitiert werden. Dazu hatte ich die Idee, jede Ziffer als Element in ein vector<char> zu speichern.

1.) Ist das eine gute Idee oder sollte ich das anders realisieren?

2.) Wie könnte man z.B. eine Addition oder Multiplikation implemeniteren? Müsste man das dann auf Basis der schriftlichen Addition/Multiplikation machen?

Vielen Dank
lg, freakC++

Dazu hatte ich die Idee, jede Ziffer als Element in ein vector<char> zu speichern.

Willst du BCDs? Dann speichere Ziffern am Besten in Nibbles, nicht in vollen Bytes - also pro Byte zwei Ziffern unterbringen.
Sonst ist das noch Speicher-verschwenderischer als es ohnehin ist.

2.) Wie könnte man z.B. eine Addition oder Multiplikation implemeniteren? Müsste man das dann auf Basis der schriftlichen Addition/Multiplikation machen?

Kommt eben völlig drauf an, wie du es implementierst. Sagen wir, du speicherst Ganzzahlen im Zweierkomplement, einfach direkt Bit für Bit in einem Bitset*, dann ist das z. T. anders als mit BCDs.

*Ob dynamisch oder nicht, musst du dir überlegen. Für beides gibt es Implementierungen (Boost.DynamicBitset und std::bitset ).

Willst du BCDs? Dann speichere Ziffern am Besten in Nibbles, nicht in vollen Bytes - also pro Byte zwei Ziffern unterbringen.

Darüber habe ich mir ehrlich gesagt keine Gedanken gemacht. Doch warum wäre es verschwenderisch, jede Ziffer als char in einem vector abzuspeichern? Da geht es doch gar nicht um Bytes?!

Du denkst also daran, alles binär abzuspeichern? Was hätte das für einen Vorteil?

Doch warum wäre es verschwenderisch, jede Ziffer als char in einem vector abzuspeichern?

Sagen wir, du speicherst mehrere 512-Bit Zahlen, also im Größenbereich von $2^{512} \approx 10^{154}$. Dann braucht deine Lösung 154 Byte pro Zahl, mit Nibbles 77, während die Lösung mit Bits 64 braucht.

Danke!

char.
Weil char ist IMMER ein Byte groß.

Naja, ich würde da zu uint8_t tendieren. Ist praktisch immer unsigned char, nur ist halt ein Byte nicht zwangsläufig 8 Bit groß. Und es wäre schön, da eine Sicherheit zu haben.

nur ist halt ein Byte nicht zwangsläufig 8 Bit groß. Und es wäre schön, da eine Sicherheit zu haben.

Ja, die Sicherheit kann Leben retten

Sone schrieb:

nur ist halt ein Byte nicht zwangsläufig 8 Bit groß. Und es wäre schön, da eine Sicherheit zu haben.

Ja, die Sicherheit kann Leben retten

Naja, aber wenn das Ding eben auch 10 Bit groß sein kann, können einige Definitionen für Dinge wie bspw. zyklische Shifts nicht mehr richtig sein.

unsigned char cyclicLeftShift(unsigned char val, std::size_t bits)
{
    return (val << bits) | (val >> (8-bits));
}

Und man baut seinen Code zu mit Dingen wie CHAR_BIT . Finde ich persönlich nicht schön. Wenn man verlangt, dass es einen Typ mit Bitlänge 8 auf der Maschine gibt, muss man sich nie wieder über sowas Gedanken machen und legt es beiseite.

Festgelegt.

Wenn Performance eine Rolle spielt, muss die Anzahl der Teil-Operationen pro Rechenvorgang minimiert werden.

Es gibt noch einen anderen Faktor: Ein- und Ausgabe (bzw. Umrechnung Bigint-Daten - Dezimalstring). Für Spielzeugprogramme ist es oft keine schlechte Idee, auf Zehnerpotenzen aufzubauen.

@freakC++: Welche der zu implementierenden Algos brauchen denn mehr als 32 Bit?

Von welchen Algorithmen sprichst Du?

spielzeug schrieb:

Es gibt noch einen anderen Faktor: Ein- und Ausgabe (bzw. Umrechnung Bigint-Daten - Dezimalstring).

Da dachte ich einfach an eine toString - Funktion, die meinen vector durchgeht und einen schönen String draus baut.

Ok, der Konsens rät mir wohl zu einer binären Darstellung. Dies sagt mir nach ein bisschen Überlegen doch auch mehr zu, da ich so später einfach Operationen wie das Addieren etc. implementieren kann. Ich könnte mir einfach einen RippleCarry Addierer bauen.

Leider hakt es noch bei einem Punkt ein bissl :

1.) Ich kriege den String: "13423...349". Ich dachte ja daran, die Ziffern einzeln abzuspeichern. Verstehe ich euch richtig, dass ihr jetzt jede Ziffer binär umwandeln würdet und dann in einem vector<uint8_t> speichert?

3.) Ich habe bisher noch nicht mit uint8_t gearbeitet. Verstehe ich es richtig, dass es wie ein char ist. nur hier garantiert ist, dass tatsächlich immer acht Bits, also ein Byte allokiert wurde?

Vielen Dank
lg, freakC++

ich bin gerade recht viel beschäfitgt, sodass ich einige Tage beim Projekt ruhen musste. Trotzdem bin ich weiterhin interessiert, meine BigInteger Klasse zu realisieren. Ich muss ehrlichg gestehen, dass ich noch nicht ganz schlau aus euren Antworten geworden bin.

Swordfish schrieb:

Von welchen Algorithmen sprichst Du?

Entschuldigt, mein Fehler. Ich rede von RSA zum Beispiel. Also es geht um Algorithmen, die weit mehr als nur mit 32 Bit arbeiten. Ich befinde ich mich in einer Größenordnung von 2048 Bit.

Ich suche also einen Datentyp, der genau acht Bit groß ist. Anscheinend darf ich mich da bei char nicht drauf verlassen.

1.) Wo hat char bitte keine 8 Bit?

Von std::uint_least32_t habe ich noch nie was gehört und finde dazu auch keine guten Referenzen.

2.) Was ist der Vorteil dieses Datentyps? Ich sehe nur die Beschreibung "width of at least 8, 16, 32 and 64 bits respectively. Das will ich doch gerade nicht!

Ich habe mir noch ein paar weitere Gedanken gemacht. Mir bleibt ja nichts anderes über, als die Zahl als BCD abzuspeichern. Andernfalls müsste ich die Zahl irgendwie binär zerlegen, wozu ich sie aber zunächst in eine Variabel packen müsste. Das geht ja gerade (noch) nicht.

3.) Ich hatte die primitive Idee, einfach mit bool zu arbeiten. Ist es nicht am effizientesten, wenn ich jedes Bit als true/false hinterlege. Damit habe ich auch die Speicherfrage gelöst, denn eine n Bit Zahl wird genau n Bit im Speicher beanspruchen.

Vielen Dank für eure Hilfe
freakC++

Hallo zusammen,

ich bin gerade recht viel beschäfitgt, sodass ich einige Tage beim Projekt ruhen musste. Trotzdem bin ich weiterhin interessiert, meine BigInteger Klasse zu realisieren. Ich muss ehrlichg gestehen, dass ich noch nicht ganz schlau aus euren Antworten geworden bin.

Swordfish schrieb:

Von welchen Algorithmen sprichst Du?

Entschuldigt, mein Fehler. Ich rede von RSA zum Beispiel. Also es geht um Algorithmen, die weit mehr als nur mit 32 Bit arbeiten. Ich befinde ich mich in einer Größenordnung von 2048 Bit.

Ich suche also einen Datentyp, der genau acht Bit groß ist. Anscheinend darf ich mich da bei char nicht drauf verlassen.

1.) Wo hat char bitte keine 8 Bit?

Von std::uint_least32_t habe ich noch nie was gehört und finde dazu auch keine guten Referenzen.

2.) Was ist der Vorteil dieses Datentyps? Ich sehe nur die Beschreibung "width of at least 8, 16, 32 and 64 bits respectively. Das will ich doch gerade nicht!

Ich habe mir noch ein paar weitere Gedanken gemacht. Mir bleibt ja nichts anderes über, als die Zahl als BCD abzuspeichern. Andernfalls müsste ich die Zahl irgendwie binär zerlegen, wozu ich sie aber zunächst in eine Variabel packen müsste. Das geht ja gerade (noch) nicht.

3.) Ich hatte die primitive Idee, einfach mit bool zu arbeiten. Ist es nicht am effizientesten, wenn ich jedes Bit als true/false hinterlege. Damit habe ich auch die Speicherfrage gelöst, denn eine n Bit Zahl wird genau n Bit im Speicher beanspruchen.

Vielen Dank für eure Hilfe
freakC++

lol

3.) Ich hatte die primitive Idee, einfach mit bool zu arbeiten. Ist es nicht am effizientesten, wenn ich jedes Bit als true/false hinterlege. Damit habe ich auch die Speicherfrage gelöst, denn eine n Bit Zahl wird genau n Bit im Speicher beanspruchen.

Nein. Bool ist exakt 1 Byte groß. also auf allen handelsülichen maschinen 8Bit. Warum? Weil C++ nur Bytes addressieren kann.

Nein. Bool ist exakt 1 Byte groß. also auf allen handelsülichen maschinen 8Bit. Warum? Weil C++ nur Bytes addressieren kann.

§ 5.3.3 / 1 schrieb:

sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1. The result of sizeof applied to any other fundamental type (3.9.1) is implementation-defined. [ Note: in particular, sizeof(bool), sizeof(char16_t), sizeof(char32_t), and
sizeof(wchar_t) are implementation-defined.74 — end note ]
[...]
74) sizeof(bool) is not required to be 1.

Wüsste nicht, wie man das noch expliziter schreiben könnte.

Zur Überlaufproblematik gerade bei der Multiplikation wird dort folgendes vorgeschlagen: Angenommen, man arbeitet mit uintN_t als Typ für die "Ziffern". Dann castet man vor der Multiplikation jeweils nach uint2N_t, und kann damit den Überlauf darstellen. Das Ergebnis kann man dann mit Bitoperation wieder in uintN_t zerlegen.

Man nimmt also nicht den größten auf der Plattform nutzbaren Typ, sondern einen, der nur halb so groß ist.

Wüsste nicht, wie man das noch expliziter schreiben könnte.

Kleiner kanns aber auch nicht werden.

Mir bleibt ja nichts anderes über, als die Zahl als BCD abzuspeichern. Andernfalls müsste ich die Zahl irgendwie binär zerlegen, wozu ich sie aber zunächst in eine Variabel packen müsste.

Ach was, das ist doch gar nicht nötig. Du kannst die Zahl in einem simplen char-Array speichern, oder eben etwas umständlicher in einem Vektor.
Damit kannst du Zahlen bauen, die viele Megabytes lang sind, ohne Probleme.

Ich habe mir noch ein paar weitere Gedanken gemacht. Mir bleibt ja nichts anderes über, als die Zahl als BCD abzuspeichern. Andernfalls müsste ich die Zahl irgendwie binär zerlegen, wozu ich sie aber zunächst in eine Variabel packen müsste. Das geht ja gerade (noch) nicht.

Sagt Dir das Horner-Schema was? Damit kannst Du die Zahl ziffernweise einlesen und sofort in eine Zahl zur Basis 2^N konvertieren.