this ist const?

class ClassA {
	void MyFunc() {
		ClassB *obj = new ClassB(this);
	}
}

class ClassB {
	ClassB(ClassA &obj) { \\ Konstruktor
	}
}

// Fehler:
// cannot convert parameter 1 from 'class ClassA *const ' to 'class ClassA &'

Ich möchte innerhalb von ClassA das aktive Objekt von ClassA (this) an ClassB übergeben. ClassB soll ein paar Änderungen vornehmen. Darf "this" bei der Übergabe nicht verändert werden?

Würdet Ihr sagen das sei kein guter Stil? Wenn ja vereinige ich die beiden Klassen... momentan ist es wegen der Übersichtlichkeit nur sehr angenehm 2 mittelgroße Klassen zu haben.

darthdespotism

Was mir als erstes auffällt:

Der Konstruktor von ClassB nimmt eine Refernez auf ClassA, this ist aber ein Pointer auf ClassA

CStoll

Dein Problem ist nicht das const, sondern der Versuch, einen ClassA-Zeiger an eine Funktion zu übergeben, die eine ClassA-Referenz erwartet (die sind zwar verwandt, aber grundverschieden). Entweder du dereferenzierst this bei der Übergabe oder du passt den Ctor so an, daß er einen Pointer entgegennimmt.

PS: Um dir Tips zum Design zu geben, habe ich zu wenig Informationen über die Aufgaben der beteiligten Klassen

Argh! Ihr habt Recht. Ist ja auch logisch das man den ThisPointer nicht verändern darf.

Zum Design: Die eine Klasse (ClassA) erstellt einen XML Baum und die andere Klassen (ClassB) verschlüsselt alle Knoten die auf bestimmte Weise makiert sind. So habe ich etwas Übersichtlichkeit gewonnen, auf der anderen Seite ist ClassB halt nur eine funktionale Erweiterung von ClassA.

MFK

martin_salo schrieb:

Zum Design: Die eine Klasse (ClassA) erstellt einen XML Baum und die andere Klassen (ClassB) verschlüsselt alle Knoten die auf bestimmte Weise makiert sind.

Klingt IMHO nach einem kaputten Design. Allein schon deswegen, weil alle Klassen etwas tun, anstatt etwas zu sein.

Dann muß ich wohl meinen Satz umformulieren. ClassA ist ein XML Baum mit Methoden die diesen Baum erweitern. ClassB ist die Erweiterung von ClassA um Verschlüsselung. Die EncEngine die wir benutzen ist recht unhandlich und erfordert Seitenlangen Source damit ich sie ansprechen kann. Deshalb ist es übersichtlicher diese Funktionalität getrennt unterzubringen. Auf der anderen Seite ist die EncryptKlasse aufs engste mit der XML Klasse verbunden, denn sie muß ja auch durch den Baum gehen um die markierten Knoten zu finden.

pumuckl

martin_salo schrieb:

ClassB ist die Erweiterung von ClassA um Verschlüsselung.

Dann sollte ClassB von ClassA ableiten, oder einen ClassA Member haben. Es macht aber keinen Sinn, dass eine Klasse etwas von ihrer Erweiterung weiss, geschweige denn dass ClassA eine Funktion enthaelt, die ein ClassB benutzt.

Ableiten ist ein gute Idee. ClassA würde ich dann irgendwie abstract machen so dass nur noch ClassB instanziiert werden kann und ich habe den Source trotzdem getrennt. Vielen Dank

shapeless

Warum denn abstrakt ?
Darf es das ganze nicht ohne Verschlüsselung geben ?
Sprich warum sollte es eine Instanz von Klasse A nicht geben können ?

Ist zwar evtl garnicht wichtig, aber ich bin halt beim lesen drüber gestolpert.

Naja es geht um ein Dateiformat wo unsere Firma wichtige Daten abspeichern will. Ich schreibe den File Reader/Writer. Die geheimen Dateidaten sollen auf keinem Fall bei den Kundenrechnern im Klartext auf die Platte geschrieben werden... wenn jemand die WriteXMLToHD() Methode ohne die Encryption Methode aufrufen könnte wäre das nicht so gut.

CStoll

Und du meinst, die Klasse abstrakt zu machen reicht aus, um sowas zu verhindern? Wenn jemand es drauf anlegt, schreibt er sich eine eigene Noop_Encrypter-Klasse, die die Daten (nicht) verschlüsselt

Das erfordert aber nicht nur Nachlässigkeit sondern auch Bösartigkeit von Seiten unserer Entwickler.