Die Klasse speichert ihre Daten so:

class BigInt
{
private:

	void* Content;
	unsigned int Length;	

};

Mein bisheriger operator + ist wie folgt definiert:

const BigInt operator+ (const BigInt& lhs,const BigInt rhs)
{
	BigInt erg;
	if(lhs.Length == rhs.Length)
		if (( ((*static_cast<char*>(lhs.Content)) & static_cast<char>(128))==static_cast<char>(128) ) || (((*static_cast<char*>(rhs.Content)) & static_cast<char>(128))== static_cast<char>(128)))
			erg.Length = lhs.Length+1;
		else
			erg.Length = lhs.Length;
	else
		if(lhs.Length > rhs.Length)
			erg.Length = lhs.Length;	
		else
			erg.Length = rhs.Length;

	erg.Content = malloc(sizeof(unsigned int)*erg.Length);

	unsigned int pos = 0;
	unsigned int ueb = 0;
	unsigned int aueb;
	while(pos < erg.Length)
	{
		aueb = ueb;

		ueb = 0;
		unsigned int a;
		if (pos < lhs.Length)
			a = *(static_cast<unsigned int*>(lhs.Content)+(lhs.Length-1-pos));		
		else
			a = 0;	

		unsigned int b;
		if (pos < rhs.Length)
			b = *(static_cast<unsigned int*>(rhs.Content)+(rhs.Length-1-pos));	
		else
			b = 0;	

		ueb += (a>>31);
		ueb += (b>>31);

		a &= 2147483647;
		a += (b & 2147483647);

		a += aueb;			
		ueb += (a>>31);

		a &= 2147483647; 
		unsigned int d = ueb % 2;

		a += (d<<31); 

		ueb >>= 1;

		(*(static_cast<unsigned int*>(erg.Content)+(erg.Length-1-pos))) = a;
		++pos;
	}

	return erg;
}

Habt ihr da noch Ideen, wie man das (vor allem von der Geschwindigkeit her) optimieren kann?

Vielen Dank für eure Mühe, Niko

const BigInt operator+ (const BigInt& lhs,const BigInt rhs)
{
	BigInt erg;

gut für RVO

if(lhs.Length == rhs.Length)
		if (( ((*static_cast<char*>(lhs.Content)) & static_cast<char>(128))==static_cast<char>(128) ) || (((*static_cast<char*>(rhs.Content)) & static_cast<char>(128))== static_cast<char>(128)))
			erg.Length = lhs.Length+1;
		else
			erg.Length = lhs.Length;
	else
		if(lhs.Length > rhs.Length)
			erg.Length = lhs.Length;	
		else
			erg.Length = rhs.Length;

WTF? das soll korrekt sein?

ueb += (a>>31);
		ueb += (b>>31);

nach
c=a+b;
weiß ich, daß ein überlauf passierte, wenn c<a (oder c<b), war das nicht so?mußt mal testen, ob das schneller wird.

Habt ihr da noch Ideen, wie man das (vor allem von der Geschwindigkeit her) optimieren kann?

jo. und die gehen mir auch nicht aus. zuerstmal ganz normal optimieren. dann vielleicht

void plus(BigInt* result,BigInt const& a,BigInt const& b)

und natürlich op+=.
schauen, was mal mit expression templates machen kann.
ein wenig inline-assembler, um ans carry-flag zu kommen.
sollten die zahlen mit der höchstwertigen ziffer links oder rechts darestellt werden? vielleicht nicht int als elemente nehmen, sondern 256 bit große superziffern, deren operationen fein geunrollt und handoptimiert werden können.

Zu dem Speichermanagement. Wie viel freizügiger sollte ich denn bei dem Speicher sein? Gibt es da sowas wie eine Faustformel?

Wenn ich Length und MaxLength trenne, wie finde ich dann am effizientesten die neue Length vom Ergebnis raus?

Warum sollte man size_t verwenden? Ist das portabler? Hat das sonstige Vorteile?

WTF? das soll korrekt sein?

Na ja, die Idee war einfach, nur wenn das erste (nicht von der Zahl, da ist es das logischerweise, sondern in m einem Speicherbereich) Bit von mindestens einer der Zahlen eins ist, dann kann das Ergebnis der Addition überhaupt so lang sein, dass es nicht mehr in den Speicherbereich passt, also nehme ich ein weiteres Stück hinzu. Sonst nehme ich die Länge der längeren Zahl.

nach
c=a+b;
weiß ich, daß ein überlauf passierte, wenn c<a (oder c<b), war das nicht so?mußt mal testen, ob das schneller wird.

Ist das so festgelegt? Kann ich mich darauf verlassen, dass das dann und nur dann der Fall ist? Und, steht dann in c trotzdem das "richtige" Ergebnis, nur halt ohne die führende 1?

void plus(BigInt* result,BigInt const& a,BigInt const& b)

Das ist leider nicht möglich. Die benutzung der Operaoren ist festgelegt. Operator += ist natürlich eine Idee, da hätte ich auch selber drauf kommen können.

schauen, was mal mit expression templates machen kann.
ein wenig inline-assembler, um ans carry-flag zu kommen.
sollten die zahlen mit der höchstwertigen ziffer links oder rechts darestellt werden? vielleicht nicht int als elemente nehmen, sondern 256 bit große superziffern, deren operationen fein geunrollt und handoptimiert werden können.

Ui, das überfordert mich erstmal ein bisschen. Leider habe ich keine Ahnung, was expression templates sind oder wie man diese benutzt. Auch Assembler kann ich leider nicht. Aber ich würde gerne dazulernen.
Wie würde man denn diese 256 bit großen Superziffern konstruieren? Wo bekäme ich die her?

So, das sind wohl ziemlich viele Fragen auf einmal, aber ich hoffe ihr könnt mir trotzdem weiterhelfen.

Nochmal vielen Dank für die Mühe, Niko

Ui, das überfordert mich erstmal ein bisschen. Leider habe ich keine Ahnung, was expression templates sind oder wie man diese benutzt

Hier der Artikel von Todd persönlich: http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html
Und hier noch was auf Deutsch: http://www.hlrs.de/people/mueller/tutorials/script/scriptse26.html

MfG

GPC

speziell zu + :
es könnte sinnvoll sein, dafür zu sorgen, dass operand a stets >= als operand b ist, dann kann man die addition nähmlich sehr schön in drei phasen aufteilen:
- zunächst werden ziffern aus a und b und evtl. überlauf verarbeitet und ins ergebnis geschrieben, solange bis alle ziffern von b verbraucht sind
- jetzt ist nur noch ein evtl. übertrag zu beachten, addiere diesen, bis er verschwindet
- die restlichen ziffern von a werden direkt kopiert
um diese vorbedingung zu erreichen, müssen wir delegieren, ein rekursiver aufruf von + mit vertauschten operanden, würde uns die NRVO ruinieren.

wie überträge erfasst werden, hängt ein bisschen von der plattform ab - formal gesehen sind überläufe UB, für 100% standard-konformen code müsste man diese vorher auffangen, wir gehen hier davon aus, dass überläufe ignoriert werden (mit inline assembler geht es nat. am besten, dank carry)

class BigInt
{
private:
    template unsigned base_int;
    std::vector<base_int> value;

    friend bool operator<(const BigInt& lhs, const BigInt& rhs);
    friend BigInt operator+(const BigInt& lhs, const BigInt& rhs)
    {
        struct
        {
            BigInt operator()(const BigInt& lhs, const BigInt& rhs) const
            {
                BigInt result;
                result.value.reserve( lhs.size() );
                typedef std::vector<base_int>::const_iterator const_iterator;
                const_iterator lhs_pos = lhs.value.begin();
                bool carry = false;
                for ( const_iterator rhs_pos = rhs.value.begin(); rhs_pos != rhs.value.end(); )
                {
                    base_int c = *lhs_pos++ + *rhs_pos;
                    if ( c < *rhs_pos++ )
                    {
                        result.value.push_back( c + carry );
                        carry = true;
                    }
                    else
                    {
                        result.value.push_back( c += carry );
                        carry = carry && c == 0;
                    }
                }
                while ( carry && lhs_pos != lhs.value.end() )
                {
                    base_int c = 1 + *lhs_pos++;
                    carry = c == 0;
                    result.value.push_back( c );
                }
                if ( carry )
                    result.value.push_back( 1 );
                else
                    while ( lhs_pos != lhs.value.end() )
                        result.value.push_back( *lhs_pos++ );
            }
        } add;
        return rhs < lhs ? add( rhs, lhs ) : add( lhs, rhs );
    }
};

template unsigned base_int;

Die Fehlermeldung ist:

43  expected `<' before "unsigned"

Sollte dort anstat dem template vieleicht ein typedef stehen?

MFg, Niko

Sollte dort anstat dem template vieleicht ein typedef stehen?

genau, kleiner tippfehler. das typedef wurde ja auch im text erwähnt.

Zu dem Speichermanagement. Wie viel freizügiger sollte ich denn bei dem Speicher sein? Gibt es da sowas wie eine Faustformel?

ja, vielleicht.
"eng" ist ein dehnungbegriff.
und
was nicht paßt, wird passend gemacht.

ich dachte an:
result.maxSize=max(a.size,b.size)+1;
und nach dem addieren wird noch geschaut, ob die größte stelle 0 ist, wenn ja, dann wird result.usedSize=result.maxSize-1;

@camper: du scheinst so ne klasse schon fertig zu haben. magste die zeigen? oder wenn nicht fertig, dann ein paar fragmente. deine überlegungen sind toll, da mag ich was lernen von.
und base_int sollte Digit heißen.

eigentlich hab ich da nichts, die überlegungen sind im grunde nur solche zu anderen problemen die ich hierauf übertragen habe. aber vielleicht skizziere ich noch ein paar sachen.
ein paar dinge, die noch zu überlegen sind:
- vorzeichenlose/-behaftete zahlen, dem grunde nach gibt es keinen grund, vorzeichenlose zahlen zu haben, denn speicherplatz ist ja formal kein problem. dann muss man sich aber überlegen, wie negative zahlen darzustellen sind - die wahl beeinflusst die komplexität (nicht im sinne von O() aber als text) der algorithmen; es bieten sich an 1er-/2er komplement (hier muss man die zahl ggf. künstlich verländern) oder signed magnitude (eine kurze übersetzung fällt mir dazu gerade nicht ein).
- hat man integer, möchte man vielleicht auch fixkomma zahlen haben (die durchaus in beide richtungen vom komma wachsen können). mit dem richtigen dreh, sollte man das unter einen hut bekommen können
- speicherverwaltungsmässig hat man verschiedene optionen, ich habe hier der bequemlichkeit halber vector gewählt, so kann ich mich erst mal auf die grundlegenden funktionen konzentrieren; aber es gibt hier die üblichen optionen: normales oder überladens new/delete und/oder per allokator evtl. mit referenzcounting
- lazy evaluation von ausdrücken mittels expression templates: das ist zum glück weitgehend orthogonal zum rest, man kann also erst einmal etwas fertiges bauen und diese funktionalität später integrieren; selbiges gilt für exotischere sachen wie assembler routinen

zu meinem code oben: es fehlt nat. noch ein return in add
und statt b < a (das ja eine komplexität von O(N) hat), genügt es, die anzahl der stellen jeder zahl zu vergleichen - sofern beide zahlen dieselbe anzahl von stellen haben, spielt die reihenfolge ja keine rolle