Beiträge von Wasserleiche

Nein, Fehler müsste es nicht geben wenn es gut implementiert ist. Aber ich würde dir auch empfehlen es wenn schon richtig zu verschlüsseln.

Und dafür nutzt man meistens freie Bibliotheken. Denn selber einen guten (vorhandenen) Verschlüsselungsalgorithmus zu imlementieren (wie z.B. AES) ist doch sehr aufwändig. Ich kann dir jetzt zwar keine Lib empfehlen, aber google doch mal nach "c++ cryptographic library" oder ähnliches...

Ok, das kannst du dir doch ganz flott selber schreiben:

* zeile für Zeile einlesen und in einen String schreiben
* jedes einzelne Zeichen durch den Code ersetzen (std::string::replace())

Fertig.

Was meinst du mit verstehen: willst du die Algorithmen verstehen, oder einfach nur wie man eine bestimmte Bibliothek nutzt?

Google doch mal ein bisschen, ich bin mir sicher du findest ein paar easy-to-use Libs. Und falls es nicht sicher sein muss, kannst du beispielsweise einen einfachen DES nehmen. Sollte einfach zu finden sein...

So eine Verschlüsselung die dem Cäsar Chiffre doch sehr ähnlich ist, bringt so gut wie gar keinen Schutz.

Nutze lieber eine Bibliothek wie crypto++ oder ähnliche.

Das geht mit den File-Funktionen der C-Bibliothek: schau dir mal fscanf() an (und die andere nötigen Funktionen).

The User:
Es ist nicht ungewöhnlich erstmal nur C zu lernen, und dann auf C++ umzusteigen. Da in der embedded Programmierung noch größtenteils reines C genutzt wird, lernen viele Elektrotechniker erstmal nur C.

Zitat von The User

Mir fällt jetzt nicht mehr ein, Wasserleiche darf aber gerne noch Sachen ergänzen - wenn es nicht der garbage-Collector ist, der lässt sich finde ich in C++ gut ersetzen.

Hehe, danke.
Aber den GC kann man in C++ nicht vollständig ersetzen. Wenn du den auto_ptr meinst, der hat einige Einschränkungen. Zum Beispiel darfst du Objekte die mittels auto_ptr verwaltet werden, in keine STL Container stecken. Und das ist schon eine schwerwiegende Einschränkung!

The User:
Eigentlich nicht der richtige Thread für sowas, aber:

Ich hab prinzipell nichts gegen Operatorüberladung. Es macht mir viele Dinge einfacher zu schreiben. Super Sache!
Doch Operatorüberladung ist nur syntaktischer Zucker. Soll heißen, alles was man damit machen kann, geht auch ohne Operatorüberladung (ist ja nur ein Funktionsaufruf). Es gibt Leute die meinen, C++ hätte die Operatorüberladung zu weit getrieben, da man fast alles überschreiben kann. Nutzt man fremde Bibliotheken, bekommt man unter umständen garnicht mit, dass eine aufwändige Operation aufgerufen wird, die man dort nicht vermutet. Was wirklich passiert wird vor dem Programmierer versteckt, was zu Problemen/Missverständnissen führen kann.

Versteh mich nicht falsch, ich persönlich finde die Operatorüberladung super, aber ich kann Kritiker auch verstehen.

Ericfischer:
Die for() Schleife ist eine Endlosschleife, dass ist dir hoffentlich klar. Außerdem solltest du while() nutzen, wenn du nur den mittleren Teil der for() Schleife nutzt.

Zitat von The User

Aber die Treiber, das ansprechen der Hardware und die Versorgung der JRE müssen außerhalb von Java laufen.

Dir ist aber klar das es auch Prozessoren gibt, die Java Bytecode ausführen können?!

Zitat von The User

C++ bietet einem außerdem auch einfach mal eine ganz normale Funktion. Falls, die man dann vielleicht einfach in einen Nammmensbereich packt, und gut ist, da muss maan als Anfänger nicht an jeder Stelle die Objektorientierung lostreten.

Wo liegt bitte der Unterschied zwischen einer Funktion in einem Namensbereich, und einer statischen Methode in einer Klasse?

Versteh mich nicht falsch, ich ziehe C++ auch eher Java vor, aber trotzdem gibt es viele Aspekte die in anderen Sprachen (wie z.B. Java) schöner gemacht sind.

Tja, das sollte geschehen, aber genauso können Bugs entstehen.

Programme stürzen nicht aus Böswilligkeit der Entwickler ab, sondern entstehen durch solche Situationen. Eine Sprache die sowas verhindert, in dem Typkonversion fast nur explizit ausgeführt werden kann, ist einfach sicherer.

Operatorüberladung ist auch so ein Kritikpunkt an C/C++. Dieser syntaktischen Zucker beherbergt einige Tücken.

Aber ich sollte jetzt aufhören, bin schon lange vom Thema abgewichen...

Dodo:

Setz doch mal deine Fantasie ein, natürlich schreibt keiner explizit "double = true". Aber stell dir folgendes vor:

Du arbeitest mit Kollegen an einer großen Software. Du hast dir eine Funktion geschrieben, die abhängig von einem oder zwei Parameter etwas ausrechnet:

double computeSomething(double param1)
{
   // ...
}


double computeSomething(double param1, param2)
{
   // ...
}

Nach einer Weile fällt dir auf, dass in der Funktion auch etwas schief gehen kann. Aber wie teilst du das dem Aufrufer mit? Du machst es also anders:

bool computeSomething(double &retValue, double param1)
{
   // ...
}


bool computeSomething(double &retValue, double param1, param2)
{
   // ...
}

Bei einem Fehler gibst du false zurück, den eigentlich Wert gibst du by-reference zurück.

Du compilierst, alles Ok. Du testest deinen Code, alles wunderbar. Du kannst auf den Fehler reagieren. Das Programm wird an einen Kunden ausgeliefert der sich nach ein paar Tagen meldet. Er schreit, tobt, ist sauer... Die Produktion steht, tausende Euro schaden. Was ist passiert?

Du hast vergessen, dass ein Kollege deine Hilfsfunktion auch nutzt:

double x, y, z;
y = 0.001;
z = 12.7;
x = computeSomething(y, z);

Aber leider macht die Funktion jetzt nicht mehr das was dein Kollege vermutet und die Software hat einen Bug. Und der Compiler hat nicht gemeckert, nichtmal eine Warning ausgegeben. Finde mal so einen Fehler in einem großen Projekt - viel Spaß!

Rate mal warum die casting Operatoren in C++ so "komisch" aussehen (z.B. dynamic_cast<int>(value)) im Gegensatz zum c-style cast . Damit erkennt man sofort an welcher Stelle im Code gecastet wird. Und das ist gut, weil man casten so weit es geht vermeiden sollte.

Das ist nicht richtig. C/C++ haben umfangreiche implizite Typkonversionen. Das ist unter anderen ein großer Kritikpunkt an diesen Sprachen.

Aber um das mal hier auf das Beispiel zu beschränken: mehr oder weniger alles was ungleich 0 ist, bedeutet "true".

Folgender Code:

for(double x = 0.001; d; d=0)
   cout << "klappt" << endl;

"klappt" wirklich. Und warum ist das jetzt schlecht? Ein Beispiel:

double x;
x = true;

Das funktioniert wirklich! Und zwar weil der Boolean Datentyp ein integraler Typ ist und damit auch einem double zugewiesen werden kann. Bei sowas wird mir wirklich schlecht, üble Sache. Sowas sollte nur explizit erlaubt sein...

Ich denke der wichtigste Grund, warum Java kaum noch langsamer als C/C++ ist, liegt im JIT Compiling. Die Sprache wird nicht, wie in ihren frühen Tagen interpretiert, sondern Just-In-Time Compiliert.

Dadurch kann sich der Start zwar etwas verzögern, aber da der Compiler die Maschine kennt auf der das Programm läuft, hat man super Optimierungsmöglichkeiten (z.B. können die Befehlserweiterungen der neuen Prozessoren genutzt werden).

Welche Sprache man am Anfang lernt ist doch eine sehr subjektive Entscheidung. Aber eines kann man doch sagen: der Umstieg von C++ auf Java fällt sicherlich einfacher als andersrum, aber dafür ist für den Einstieg Java sicherlich leichter zu lernen.

Würde mich auch interessieren, aber diese Zeilen hier...

datei = fgets(argv[1] != EOF);
{
   zaehler++;
}

...machen überhaupt keinen Sinn. Schau dir mal fgets() genauer an. Du brauchst ne while Schleife und musst den Rückgabewert prüfen.

Aber ich frag mich warum du mit der C-Library arbeitest, wenn du C++ lernen willst. Mit ifstream geht das wesentlich besser!

Also wenn du schon Erfahrung mit C/C++ hast, wirst du folgendes Tutorial super finden: Java for C++ Programmers.

Prinzipiell kann man sagen: am Ende des umfassenden Skopes. Dodo hat im Normalfall schon recht, allerdings muss man es eventuell genauer betrachten:

int foo(float bar)
{
   int temp = 0;


   for(int i=0; i<10; i++)
   {
      temp += i; // erlaubt 
   }


   cout << i << endl; // NICHT erlaubt, i gehört zum Skope der for-Schleife


   return temp + bar;
}

Natürlich wird beim Aufruf der Funktion Platz für 2 (abgesehen vom Parameter bar) Integer auf dem Stack reserviert (temp und i), aber i darf nur innerhalb der for-Schleife genutzt werden. Ein Compiler würde den Speicher von i auf dem Stack wiederverwenden, wenn nach der for-Schleife eine neue Variable angelegt wird.

Der Skope ( also { und } ) definiert also den Gültigkeitsbereich der Variablen auf dem Stack. Mit new angeforderter Speicher auf dem Heap (dynamischer Speicher), muss explizit mit delete wieder freigegeben werden. Machst du das nicht, hast du ein Speicherleck.

Schreib doch mal was du bisher hast...

Das bekommst du sicherlich mit den Codeschnippseln hier selber hin. Und wenn du Fragen hast, kannst du mich gerne fragen.

Mittels Reverse Engineering kann man die Funktionsweise eines Programms schon wieder zurück verfolgen. Aber es ist nicht möglich (praktisch nicht möglich), aus einem ausführbaren Programm C Code zu erzeugen. Außer du hast Bytecode vorliegen : )

Zitat von Dodo

es werden einfach externe programme oder libraries heruntergeladen und mit den jetziger ersetzt

So pauschal ist diese Aussage falsch. Natürlich kann man mit einem Patch/Update ein vorhandenes Binary (z.B. ein ausführbares Programm) ändern. Aber natürlich ist das nicht bei jedem Patch/Update der Fall.

Hier eine gute Einführung zum Patchen.

Naja, dafür ist das switch Statement doch super geeignet. Enums sind nichts anderes als ints.
Und switch ist auf jeden Fall schneller als x if Abfragen, da sie über Sprungtabellen realisiert werden.