[C++]Zugriffsfehler bei Klasse

Eine methode wird zumindest AFAIK NICHT mit einem strichpunkt abgeschlossen, sondern nur die klasse.
Zum Vergrößern anklicken....
Das Semikolon am Ende der Funktionsblöcke ignoriert der Compiler ohnehin als Leeranweisung. Insofern könnte man sagen, dass das Anhängen von Semikolons optional, allerdings auch sinnlos ist. Ein Fehler ist es jedenfalls nicht.

Außerdem kommt es nie gut wenn man eine variable gleich nennt wie die klasse, das führt sonst beim compiler zu verwirrungen.
Zum Vergrößern anklicken....
Und auch beim Programmierer... Also ich würde es nicht tun - warum sich selbst das Leben schwer machen?
 
Zugriffsfehler

Das Symbol InputQuery ist (jedenfalls in dem geposteten listing) kein member von class Diche. ERGO gibts von dort aus keinen Zugriff auf die private Member. Zugriffsversuche sollten eigentlich schon vom Compiler bemängelt werden.

Zur Namensgebung ein paar Tips:
Einige Leute (entweder Ungarn oder Polen) haben eine Notation entwickelt.
Hier ein kleiner Ausschnitt:

Klassennamen beginnen mit C (class CDichte)
Membervariablen beginnen mit m_TypkürzelName (float m_fDichte)
Damit löst man das Problem der mehrfach verwendeten Symbole.
Der Quellcode wird dadurch lesbarer.

Das mit den this-> Zeigern in den Methoden ist überflüssig.

Zwirni
 
Das waren Ungarn. Deshalbe nennen Feinde der Prefixes sie auch "ungarische Warzenschweine" oder auch "hungarian warthogs". Sie sind etwas umstritten, haben sich allerdings auch stark durchgesetzt. Ich bin mir selber immer noch nicht sicher, ob ich sie gut finden soll oder nicht. Meist verwende ich sie jedoch.

Der Quellcode wird dadurch lesbarer.
Zum Vergrößern anklicken....
Solange man nicht irgendwann den Typ oder Zugriff der Membervariablen geändert hat und vergessen hat, den Variablennamen überall anzupassen. Die Prefixes sind dann nämlich nur irreführend. Man sieht also, dass sie unter Umständen einen gewaltigen Wartungsaufwand mit sich bringen. Im Normalfall sollten Membervariablen aber ohnehin in der Klasse verborgen bleiben (zumindest für den Nutzer der Klasse), so dass die (Nicht-)Verwendung der Prefixes letzten Endes auf eine Stilfrage hinausläuft.
 
Re: Zugriffsfehler

Das mit den this-> Zeigern in den Methoden ist überflüssig.
Zum Vergrößern anklicken....

Für die funktion ja, aber nicht für die übersichtlichkeit in großen projekten!

Wenn du projekte hast die aus 50 und mehr dateien bestehen, dann gewöhnst du dir liebend gern an das objekt oder den namensraum extra anzugeben, einerseits weil es sonst womöglich eine funktion und ne methode gibt die gleich heißen, und wo der compiler dann nix mit anfangen kann, anderersets sieht man dann sofort wo im code man eine funktion suchen muss.

Wenn eines klasse 5 seiten lang ist und da eine methode daraus aufgerufen wird, und ich hab ein this-> da stehen, dann seh ich auf den ersten blick schon, ah das kann nur in der klasse sein.
wenn aber da kein this steht, kann es sich genau so gut um eine globale funktion handeln die ich womöglich ganz wo anders suchen muss.

Von daher hab ich mir angewöhnt, das ich sowohl den this zeiger als auch den global scope operator benutze um das optisch besser sichtbar zu machen.

Dadurch werden sachen wie ein m_ vor der variable nahezu überflüssig, denn ein member einer klasse wird ja über ein objekt angesprochen, eine globale variable über ein global scope und so weiter...
 
Also ein this-> ist nützlich, aber ein m_ ist überflüssig? Das leuchtet mir nicht ein. Man sollte davon ausgehen, das alle Aufrufe sich auf Methoden des Objektes beziehen, abgesehen von den sinnvollerweise durch "::" gekennzeichneten globalen Funktionen. Deshalb scheint mir die Verwendung von this eigentlich unnötig. Aber letzten Endes läuft all dies vermutlich wieder auf eine Stil- oder Geschmacksfrage hinaus. :)
 
Es geht immer noch nicht! Hier mal der komplette Quelltext mit samt Aufruf:
Code: 
#include <vcl.h>
#include <vcl/dstring.h>
#pragma hdrstop

#include "Unit.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
class Dichte
{
        private:
                float Gewicht;
                float Volumen;
                AnsiString Name;
        public:
                float vDichte;
                

                Dichte()
                {
                        vDichte = 0;
                        Gewicht = 0;
                        Volumen = 0;
                        Name = "";
                }
                void reset()
                {
                        vDichte = 0;
                        Gewicht = 0;
                        Volumen = 0;
                        Name = "Test";
                }
                void Dichte_errechnen()
                {
                        InputQuery("Volumen des Stoffs","Dichte",Volumen);
                        InputQuery("Masse des Stoffs","Dichte",Gewicht);
                        vDichte = Gewicht/Volumen;
                }
};
TForm1 *Form1;
Dichte Stoff;
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
        : TForm(Owner)
{
}
//---------------------------------------------------------------------------

void __fastcall TForm1::Beenden1Click(TObject *Sender)
{
        Close();        
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Dichteneu1Click(TObject *Sender)
{
        PDichte->Caption = "";
        EName->Text = "";
        Stoff.reset();
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Dichteerrechnen1Click(TObject *Sender)
{
        Stoff.Dichte_errechnen();        
}
//---------------------------------------------------------------------------
an den roten Zeilen tritt der Zugriffsfehler auf.
 
void Dichte_errechnen()
{
InputQuery("Volumen des Stoffs","Dichte",Volumen);
InputQuery("Masse des Stoffs","Dichte",Gewicht);
vDichte = Gewicht/Volumen;
}
};
an den roten Zeilen tritt der Zugriffsfehler auf.
Zum Vergrößern anklicken....

Wie ich sagte auch in deinem letzten Listing is InputQuery NICHT Member von Dichte. Du kriegst von Nicht-Member-funktionen normalerweise keinen Zugriff auf private member.

Mach dir n Kopf wie du die member anders setzt zumal du mit dieser Funktion eine ungeschickte Verknüpfung zwischen Applikation und Benutzungsoberfläche implementierst.

Zu dem Problem mit dem this-> statt m_:
Man sollte unnötige Dereferenzierungen vermeiden. Lesbarkeit in allen Ehren aber bitte nicht auf Kosten der Performance. Ich habs zwar noch nich im Schrittbetrieb verfolgt aber diese Dereferenzierung muss vom Compiler ja irgendwie aufgelöst werden. Also bleib ich lieber bei m_. Zudem hab ich m_ schneller getippt als this->.
 
Wie ich sagte auch in deinem letzten Listing is InputQuery NICHT Member von Dichte. Du kriegst von Nicht-Member-funktionen normalerweise keinen Zugriff auf private member.
Zum Vergrößern anklicken....

Wusste ich gar nicht dass man aus einer Member Funktion nicht eine z.B.: Api Funktion mit private Membervariablen aufrufen kann.
Wieso dass den ! Ist das wirklich so , bin mir nämlich ziemlich sicher dass das geht !
 
Schau mal, er übergibt eine PRIVATE Variable an eine normale Funktion, die die PRIVATE Variable verändert. Was haben wir alle gelernt? Private Variablen dürfen nur von der Klasse verwendet werden. Übergeben darf man sie anscheinend innerhalb der Klasse schon.

Wie wärs mit einem Buffer?

Bitte mach die Dichte nicht public, und dafür ein Funktion GetDensity().

@Zwirni Ungarische Notation heißt es ;)
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück