es wäre nett wenn ihr mir eben das hier erklären könntet:

void IClientPacketHandler::Decrypt(char *&szData)
{
	for(unsigned int i = 0; i < strlen(szData); i++)
	{
		szData[i] = (char)((char)szData[i] ^ (char)0xC3);
	}
}

Das da was Decrypted also leserlich gemacht wird weiss ich nur bitte die einzelnen abschnitte genau erklären, es wäre sehr nett.

Lg

Jedes Zeichen des Strings wird mit 0xC3 xor-verknüpft.

hmmm ich werde mir das mal anschauen.
Könntest du eventuell den rest auch noch erklären?

Lg

Könntest du eventuell den rest auch noch erklären?

Da ist kein Rest, das ist alles was passiert.

Gast123456789 schrieb:

Könntest du eventuell den rest auch noch erklären?

Da ist kein Rest, das ist alles was passiert.

Gut, dachte da wäre mehr

Danke euch beiden.

void IClientPacketHandler::Decrypt(char *&szData)

Warum hier eine Referenz genommen wird, weiss niemand. Der Zeiger selbst wird jedenfalls nicht geändert. Und was soll dieses sz -Präfix?

szData[i] = (char)((char)szData[i] ^ (char)0xC3);

Etwas viele Casts, oder? Zumal sie alle unnötig sind. Man könnte ausserdem gleich operator^= verwenden.

for(unsigned int i = 0; i < strlen(szData); i++)

So zu iterieren führt zu quadratischer Laufzeit. Iteriere lieber gleich mit Zeigern und prüfe auf die Nullterminierung.

Das könnte dann so aussehen:

void IClientPacketHandler::Decrypt(char* dataPtr)
{
    for (; *dataPtr != '\0'; ++dataPtr)
        *dataPtr ^= 0xC3;
}

for (; *dataPtr != '\0'; ++dataPtr)

schneller als

for(unsigned int i = 0; i < strlen(szData); i++)

?
Weil jedesmal die Stringlänge berechnet wird? Wäre dann nicht

int len = strlen(szData);
for(unsigned int i = 0; i < len; ++i)

die schnellste Variante?

for(unsigned int i = 0; i < strlen(szData); i++)

So zu iterieren führt zu quadratischer Laufzeit. Iteriere lieber gleich mit Zeigern und prüfe auf die Nullterminierung.

Wie bitte?

Nexus schrieb:

for(unsigned int i = 0; i < strlen(szData); i++)

So zu iterieren führt zu quadratischer Laufzeit. Iteriere lieber gleich mit Zeigern und prüfe auf die Nullterminierung.

Wie bitte?

Was macht StrLen ?

Weil jedesmal die Stringlänge berechnet wird? Wäre dann nicht

int len = strlen(szData);
for(unsigned int i = 0; i < len; ++i)

die schnellste Variante?

Wozu erst einmal über den ganzen String iterieren um die Zeichen zu zählen und dann nochmal ums sie zu ver-xor-en, wenn man auch gleich nur einmal über alle Zeichen iterieren kann, sie dabei ver-xor-dern kann und beim letzten Zeichen aufhören kann?

Das würde ungefähr doppelt so lange dauern.

this->that schrieb:

Nexus schrieb:

for(unsigned int i = 0; i < strlen(szData); i++)

So zu iterieren führt zu quadratischer Laufzeit. Iteriere lieber gleich mit Zeigern und prüfe auf die Nullterminierung.

Wie bitte?

Was macht StrLen ?

Gute Compiler werden doch den Funktionsaufruf aus der Schleife rausziehen?

Gute Compiler werden doch den Funktionsaufruf aus der Schleife rausziehen?

Zumindest könnten sie es, bei Funktionen aus der Std-Lib ist ja klar, welche pure sind und welche nicht.

Gute Compiler werden doch den Funktionsaufruf aus der Schleife rausziehen?

Warum die Nicht-Optimierung riskieren statt gleich richtig zu programmieren? Ist ja nicht so, dass letzteres hier besonders anspruchsvoll wäre.

this->that schrieb:

Gute Compiler werden doch den Funktionsaufruf aus der Schleife rausziehen?

Warum die Nicht-Optimierung riskieren statt gleich richtig zu programmieren? Ist ja nicht so, dass letzteres hier besonders anspruchsvoll wäre.

Weil man dann Gefaehr laeuft unnoetigerweise unleserlichen/frickeligen Code zu schreiben.
Ist genauso wie mit den Leuten die Rueckgabeparameter per non-const Referenz uebergeben, weil sie meinen das sei viel Effizienter als mit by value return. Ergibt haesslicheren Code, obwohl jeder Compiler dank (N)RVO den schoeneren Code optimiert haette.

for(unsigned int i = 0, imax = strlen(szData); i < imax; ++i)

Funktioniert hier genauso wie bei den leidigen end()-Abfragen, wenn man durch Container iteriert und den end()-Iterator nicht invalidiert

this->that schrieb:

Gute Compiler werden doch den Funktionsaufruf aus der Schleife rausziehen?

Zumindest könnten sie es, bei Funktionen aus der Std-Lib ist ja klar, welche pure sind und welche nicht.

Selbst der beste Compiler kann nicht wissen (ohne dass man es ihm auf irgendweine andere Weise mitteilt), dass die Sequenz kein 0xC3 enthält und folglich das Ergebnis von strlen nicht beeinflusst wird.

Weil man dann Gefaehr laeuft unnoetigerweise unleserlichen/frickeligen Code zu schreiben.

Ich halte

for (; *dataPtr != '\0'; ++dataPtr)
    *dataPtr ^= 0xC3;

nicht für unleserlich. Mit etwas C- oder C++-Erfahrung versteht man sofort, was gemeint ist, und zwar um einiges besser als bei der Originalversion. Ich habe extra nicht

while (*dataPtr)
    *dataPtr++ ^= 0xC3;

geschrieben.

Du kannst auch gerne

for (unsigned int i = 0; data[i] != '\0'; ++i)

verwenden, falls der Code so klarer ist. Finde ich besser als sich blind auf Optimierungen zu verlassen, zumal man dann tendiert, das auch bei komplexeren Situationen so handzuhaben, wo eine Optimierung nicht mehr möglich ist. Und selbst wenn der Compiler dein strlen() aus der Schleife ziehen könnte, würdest du die Anzahl Zeichen unnötigerweise doppelt zählen. Sehe ich in diesem Fall nicht als Premature Optimization an, weil die effiziente Lösung nicht wirklich schwieriger zu programmieren ist.

Aber in solchen Situationen habe ich meist std::string , first/last -Iteratoren oder besonders bei binären Daten ein first/size -Paar, in allen Fällen stellt sich die Problematik nicht.

this->that schrieb:

Ist genauso wie mit den Leuten die Rueckgabeparameter per non-const Referenz uebergeben, weil sie meinen das sei viel Effizienter als mit by value return. Ergibt haesslicheren Code, obwohl jeder Compiler dank (N)RVO den schoeneren Code optimiert haette.

In den Fällen, wo (N)RVO anwendbar ist, handelt es sich um lokale Objekte, wodurch eine Referenz als Rückgabetyp sowieso nie in Frage kommt.

Aber ich weiss schon, worauf du hinauswillst

Daher habe ich das.

Lg

http://warrock.googlecode.com/svn/trunk/LoginServer/LoginServer/ClientPacketHandler.cpp

Daher habe ich das.

Lg

Das ist ein lupenreines Negativbeispiel für die Vermischung von C++ und C.
C-Gefrickel in Situationen, in denen C++ Code höchstwarscheinlich performanter und in jedem Fall sicherer und einfacher ist.

fdfdg schrieb:

this->that schrieb:

Gute Compiler werden doch den Funktionsaufruf aus der Schleife rausziehen?

Zumindest könnten sie es, bei Funktionen aus der Std-Lib ist ja klar, welche pure sind und welche nicht.

Selbst der beste Compiler kann nicht wissen (ohne dass man es ihm auf irgendweine andere Weise mitteilt), dass die Sequenz kein 0xC3 enthält und folglich das Ergebnis von strlen nicht beeinflusst wird.