c++ cheatengine etc.

[Padmak]

Hast du grade echt empfohlen, die Compiler-Error zu ignorieren und stattdessen von Hand auf die Suche nach dem Fehler zu gehen?
... ???!!
Im Ernst? Wofür gibt es denn die Meldungen? Und selbst wenn man sie nicht versteht, hilft es IMMER die Meldung (den Fehler an sich, nicht die betroffene Zeile) in Google zu pasten und danach zu suchen. Beim MSVC gibts sogar die praktischen Compiler-Fehler-Codes, zu denen es tonnenweise Dokus gibt.

Padmak

[alpines]

Du musst nicht gleich überreagieren, natürlich hab ich ihm das empfohlen.
Sofern man sich mit "Anfängerkrams" beschäftigt ist es einfach besser sowas zu ignorieren und sich selber auf die Suche zu machen.
Die Compiler-Error soll er sich später natürlich auf jeden Fall anschauen, weil er auf einem neuen Gebiet ist und das natürlich nicht kann. Sowas kann niemand, ist klar.

Aber wenn man sich damit beschäftigt und einige Programme schreibt sollte mal nicht gleich die Augen runter zum Error wandern lassen, wenn es einfache Fehler sind wie:

- Semikolon vergessen
- der Variable keinen Typ verpasst
- { } von Schleifen fehlen

[Tasiro]

Es sollte auch ganz einfach nicht notwendig sein, seine Augen irgendwohin wandern zu lassen, wenn es doch so etwas wie "Syntaxhervorhebung" gibt, welche Fehler auch noch rot unterstreicht und zusätzlich sagt, was man falsch gemacht hat. Dazu muss man nicht suchen, das springt einem ins Auge.
Wenn von diesem Rot nichts mehr übrig ist und es dennoch nicht kompiliert, muss man sich die Fehlerausgabe ansehen, sonst weiß man gar nicht, warum es nicht kompiliert, und wo der Fehler auftritt. Gerade Anfänger sollten versuchen, die Fehlermeldungen zu verstehen, sind sie doch der Schlüssel zum Verständnis des eigentlichen Fehlers, ob es nun ein fehlendes Semikolon oder ein fehlendes typename-Schlüsselwort ist. Wem sollen sie denn sonst glauben, wenn nicht dem Compiler? Irgendeinem halbfertigen und fehlerhaften Internet-Tutorial? Das empfiehlst du Neulingen?

[alpines]

'Das' empfehle ich nicht den Neulingen, aber ich sehe das so ähnlich wie du.
Meiner Meinung nach sollte man erst die unterstrichenen Fehler versuchen wegzumachen und bei nicht sichtbaren Fehlern nachdem(!) man seinen Code überflogen hat die Meldung erst durchlesen. Bevor man sofort in den Editor starrt kann man seine Fehler auch oft sofort ohne in die DebugBox zu gucken herausfinden.

[Padmak]

Ich seh immer noch nicht, was falsch daran ist sich an den vorhandenen Fehlermeldungen auch zu orientieren. Natürlich gibt es Fehler, wo man schon anhand der Datei weiß was man vergessen hat (Ach verdammt, das wollte ich ja noch machen)
Aber ich finde es mindestens genauso wichtig die Fehler lesen zu können, weil vor allem in C++ die Fehlermeldungen manchmal nicht auf den Fehler hinweisen sondern auf irgendwas ganz anderes. Wenn man da nicht genug Erfahrung mit dem Verstehen hat, wird's irgendwann echt kompliziert

Padmak

[Tasiro]

Z. B. gibt Microsoft Visual C++ Compiler Nov 2012 CTP drei Fehler für dieses Programm aus:

#include <list>
#include <algorithm>

int main () {
    std::list <int> l;
    sort (l.begin (), l.end ());
}

Ausgabe:

c:\program files (x86)\microsoft visual studio 11.0\vc\include\algorithm(3702): error C2676: binary '-' : 'std::_List_iterator<std::_List_val<std::_List_simple_types<int>>>' does not define this operator or a conversion to a type acceptable to the predefined operator
          c:\...\file.cpp(14) : see reference to function template instantiation 'void std::sort<std::_List_iterator<std::_List_val<std::_List_simple_types<int>>>>(_RanIt,_RanIt)' being compiled
          with
          [
              _RanIt=std::_List_iterator<std::_List_val<std::_List_simple_types<int>>>
          ]
c:\program files (x86)\microsoft visual studio 11.0\vc\include\algorithm(3702): error C2780: 'void std::_Sort(_RanIt,_RanIt,_Diff,_Pr)' : expects 4 arguments - 2 provided
          c:\program files (x86)\microsoft visual studio 11.0\vc\include\algorithm(3832) : see declaration of 'std::_Sort'
c:\program files (x86)\microsoft visual studio 11.0\vc\include\algorithm(3702): error C2780: 'void std::_Sort(_RanIt,_RanIt,_Diff)' : expects 3 arguments - 2 provided
          c:\program files (x86)\microsoft visual studio 11.0\vc\include\algorithm(3668) : see declaration of 'std::_Sort'

Da ist es alles andere als klar, dass eine std::list nicht mit std::sort sortiert werden kann, weil der Iteratortyp unzureichend ist.

[MrSm!th]

Ich kapiere auch nicht, wieso man die netten Fehlermeldungen vom Compiler ignorieren sollte (zumal man auch mit denen trotzdem noch lange auf der Suche sein kann, wenn der Fehler nur indirekt vom Compiler moniert wird). Welchen Vorteil hat man dadurch, den Fehler selbst zu suchen, anstatt einfach in den Zeilen zu schauen, auf die einen der Compiler hinweist?!

[alpines]

Ich rede nicht von Fehler die man macht wenn man weiter fortgeschritten ist, natürlich kann man sich um die Definition streiten, aber warum sollte ich in die DebugBox schauen, wenn ich den Fehler schon auf Anhieb sehe?
Warum sollte ich bei einfachen Anwendungen, die nur ein Ziel verfolgen, beispielsweise eine Umrechnung, die Compiler Errors anschauen, wenn man die Fehler doch sofort sieht?
Es geht nicht darum überhaupt nicht in die Box zu schauen, sondern sich erstmal den Code anzuschauen, und zu gucken ob man nicht gleich den Fehler sieht.
Wenn man langsam anfängt komplizierte und verzweigte Anwendungen zu programmieren, dann ist der Blick in die Errors natürlich erforderlich.

[Tasiro]

Wenn du es doch aber siehst, wie konntest du es dann überhaupt falsch schreiben?

[alpines]

Richtig, Flüchtigkeitsfehler halt beim Tippen.
Hast du je mal versuch eine lange Nachricht zu tippen ohne die Fehler zu korrigieren?
Egal wie gut du tippen kannst, du wirst immer Fehler machen also sollte man sich drum kümmern weniger zu machen um weniger Zeit mit dem Korrigieren zu verschwenden.
Allerdings finde ich das wir langsam vom Thema abschweifen, das was wir diskutieren sind nichts mehr als unsere persönliche Meinungen.

[MrSm!th]

Wenn wenn man sie sofort sieht, bleibt man doch intuitiv erstmal da und korrigiert sie und geht dann runter zu den Compiler Fehlern. Verstehe nicht, was dein Hinweis da bringen soll. Wo ist da irgendeine Art von Lerneffekt, wenn ich die Fehlermeldung (auch wenn es nur am Anfang ist) ignoriere?

Nebenbei: Was meinst du mit einfachen Programmen bzw am Anfang? Eine "Komplexität", bei der es keinen Sinn mehr macht, den Fehler selbst zu suchen, ist schnell erreicht.

[MaBarker]

Also,
Wenn du Hacks Programmieren willst z.b. mit C++ solltest du die Sprache ansich erstmal Lernen oder als Minimum die Basics von C++.
Also du musst es Lernen und du brauchst viel Zeit, sehr viel Zeit ^^

Wenn du es lernst wie gesagt du machst ja dein Studium in Informatik und ansonsten so noch Bücher etc. Kaufen.
Wenn du einen Hack Coden möchtest bzw. einen D3D Hack dann empfehle ich dir anstatt deine eigene base zu coden erstmal eine Base von wem anders zu nehmen.
Da empfehle ich dir die "ELExTrO D3D" Base.
Sie ist auch sehr einfach zu Verstehen.
Dann Codest du deine ersten Funktionen und wirst dich immer Verbessern ^^
Irgendwann solltest du dann soweit sein deine ersten Hacks und vllt. auch schon deine ersten Größeren Hacks zu schreiben.

Aber ganz wichtig ist. Um nicht ganz so Ahnungslos und Noobig zu sein sollte man schon so einige Begriffe können/lernen, denn ich hab auch schon welche gesehn die was "gecodet" haben und dachten sie wären cool, konnten mir anschließend aber nicht sagen was ne Detour ist
Also du solltest schon so begriffe wie "Detour, Hook ......" können, geh dich einfach mal Informieren damit du nich einer solcher noobs bist ^^

lg. MaBarker