Zugriffsverletzung beim Schreiben von Integern

SeppJ

Frager schrieb:

InputClass();
	~InputClass();

	void Initialize();

Wo kann ich Geld darauf setzen, dass du weder Konstruktoren noch Destruktoren verstanden hast? Und wettet überhaupt jemand dagegen?

Caligulaminus

Wo kann ich Geld darauf setzen, dass du weder [...]

Das riecht nach Whisky und Zigarren.
Poker?

Ich hatte heute (gestern?) auch schon solche Anwandlungen.

Was treibt sich jemand wie ich um diese unchristliche Zeit eigentlich noch in irgendwelchen Foren herum?

Vollmond!

Und morgen wieder rote Augen.

Gott zum Gruße

C.

Frager

SeppJ schrieb:

Frager schrieb:

InputClass();
	~InputClass();

	void Initialize();

Kann mir mal Jemand bitte sagen was an meinen Kon- und Destruktern so falsch sein soll ?
Oder soll das darauf abzielen, dass ich keine Funktion Initialize() brauche, da doch der Konstruktor aufgerufen wird ?

@CStoll Danke für deinen Tipp werde es gleich mal versuchen

Eisflamme

Frager schrieb:

SeppJ schrieb:
Frager schrieb:
InputClass();
	~InputClass();

	void Initialize();
Kann mir mal Jemand bitte sagen was an meinen Kon- und Destruktern so falsch sein soll ?
Oder soll das darauf abzielen, dass ich keine Funktion Initialize() brauche, da doch der Konstruktor aufgerufen wird ?

Ja.

CStoll

Vor allem fällt auf, daß die Klasse nichts enthält, was einen expliziten Konstruktor oder Destruktor benötigt.

Frager schrieb:

in der ich die InputNachrichten von meine Callback-Funktion aus der WinAPI weiterleite und verarbeiten lasse.

Mir ist beim noch im Nachhinein aufgefallen: Wozu machst du dir überhaupt die Mühe, wo du den Status der Tastatur auch über GetKeyState() bzw. GetAsyncKeyState() abfragen kannst?

Skym0sh0

bei directx geht zum beispiel ein klein wenig anders
da wird ein ganzes array mit bool bzw floats gefüllt je nachdem ob (und bei floats wie weit) eine taste gedrückt wurde, so kriegt man ganz gut mit, ob mehrere tasten gedrückt wurden usw.

GetAsyncKeyState() ist im gegensatz dazu viel schlechter geeignet.

DocShoe

GetKeyboardState füllt ein Array mit den Stati aller Tasten, könnte dir etwas Arbeit abnehmen.

ipsec

CStoll schrieb:

Vor allem fällt auf, daß die Klasse nichts enthält, was einen expliziten Konstruktor oder Destruktor benötigt.

Ich bilde mir ein, dass bei einem weggelassenen Konstruktor das Array nicht initialisiert wird, bei einem leeren Konstruktor aber schon. Kann sein, dass ich das jetzt verwechsle und es vom POD-Status abhängt, welcher in dem Fall schon durch den privaten Member nicht mehr gegeben wäre.
In jedem Fall brauch man aber keinen Destruktor, da hast du Recht.

Btw, @DocShoe: der Plural von Status ist Status mit langem u (gehört zur gleichen Wortgruppe wie z.B. Sinus oder Kasus, da ist das auch so). Schön umgangssprachlich kann man auch Statuse sagen, aber bitte kein falscher lateinischer Plural.

pumuckl

ipsec schrieb:

Ich bilde mir ein, dass bei einem weggelassenen Konstruktor das Array nicht initialisiert wird, bei einem leeren Konstruktor aber schon.

Dann bilde dich weiter Der compilergenerierte Ctor macht exakt das Selbe wie ein leerer Default-Ctor

ipsec

Ja, jetzt weiß ichs wieder: deine Aussage stimmt nicht ganz. Bei einer POD-Klasse werden die Member (wie das Array) nicht initialisiert (außer bei solchen Geschichten wie MyClass x = MyClass() ). Ein expliziter userdefined Konstruktor (auch ein leerer) hebt aber den POD-Status auf, womit das Array mit false initialisiert werden würde.
Im konkreten Fall ist die Klasse aber sowieso kein POD, weil das Array privat ist, somit kann man den Konstruktor auch weg lassen.

Frager

Danke für eure Hilfe und Ratschläge

Ich habe den Fehler gefunden ... reine Blödheit von mir !!!
ich habe bei den WM_KEYUP Message den LPARAM-WERT GENOMMEN !!!!
Und dann immer einen Schwachsinns-wert erhalten ... kein Wunder !

Trotzdem Danke für eure Hilfe

hustbaer

@ipsec:
Nö, der leere explizit definierte Ctor macht schon immer genau das selbe wie ein implizit definierter Default-Ctor.

Bloss führt z.B. new T() nicht unbedingt den Default-Ctor aus, und da liegt der Hund begraben:

new POD; // uninitialized
new POD(); // default initialized == zero initialized
new NON_POD; // default initialized == default ctor
new NON_POD(); // default initialized == default ctor

Daraus können sich dann einige Überraschungen ergeben. Nach new POD() sind nämlich hübsch alle Member Null, nach new NON_POD() allerdings sind alle POD-Member uninitialisiert, sofern man sie nicht explizit im Ctor initialisiert hat (was ein impliziter Default-Ctor oder leerer expliziter Ctor ja nicht macht).

Siehe auch hier: http://www.c-plusplus.net/forum/p2021136#2021136

----

Wobei sich für mich gerade die Frage stellt: haben PODs überhaupt einen Default-Ctor? Ich wüsste zumindest gerade keine Syntax mit der dieser aufgerufen werden könnte. (Und wenn sie einen haben, dann tut er garantiert genau nichts -- von daher ist die Frage ziemlich akademisch.)

----

Auch stimmt das was du über Arrays geschrieben hast nicht. Auch ein explizit definierter leerer Konstruktor initialisiert diese nicht, sofern sie PODs sind. Muss man selbst machen.

camper

hustbaer schrieb:

Wobei sich für mich gerade die Frage stellt: haben PODs überhaupt einen Default-Ctor? Ich wüsste zumindest gerade keine Syntax mit der dieser aufgerufen werden könnte. (Und wenn sie einen haben, dann tut er garantiert genau nichts -- von daher ist die Frage ziemlich akademisch.)

Rein akademisch, ja.
12.1./5 S. 2: Alle Klassen ohne explizit deklarierten Konstruktor, also erst recht alle POD-Klassen, haben einen Defaultkonstruktor.

Der wird im Falle von POD-Klassen weder für default- noch für value-Initialisierung benutzt (8.5). Da ein Konstruktoraufruf immer zur Initialisierung eines Objektes führt, folgt im Umkehrschluss, dass der Defaultkonstruktor einer POD-Klasse niemals aufgerufen wird.