OOP: soll man jetzt alles in ne Klasse packen oder watt?

OOP hat ja auch gar kein A.

Zeus

Ich weiss versteh eure Gedankengänge, allerdings akzeptiere ich diese nicht.
Naja was auch immer, viel spass

Shade Of Mine

Zeus schrieb:

Ich weiss versteh eure Gedankengänge, allerdings akzeptiere ich diese nicht.
Naja was auch immer, viel spass

reden wir in 5 jahren nochmal drueber - nachdem du dir lisp, js, etc. angesehen hast.

nimm bis dahin einfach mal hin, dass leute wie volkard oder ruediger etwas mehr erfahrung haben als du.

in ein paar jahren wirst auch du es verstanden haben dass es sich bei OOP nur um objekte dreht und objekte ein abstraktes konzept sind. und dass es eben mehrere auspraegungen gibt wie sich objekte manifestieren koennen.

Zeus

Du, das hab ich schon XD und ich steite mich ja auch nicht um deine Erfahrung :)~

Jester

net schrieb:

ob's standardkonform ist??? aber es sieht so aus...

Ich finde nicht, daß es so aussieht. Du wandelst einen Pointer von einem Typ in einen anderen um. Das ist nie im Leben definiert, was da passiert, portabel ist es damit natürlich auch nicht. Es gibt schlicht keinen Standardkonformen Weg das zu tun.

net 0

Jester schrieb:

net schrieb:

ob's standardkonform ist??? aber es sieht so aus...

Ich finde nicht, daß es so aussieht. Du wandelst einen Pointer von einem Typ in einen anderen um. Das ist nie im Leben definiert, was da passiert, portabel ist es damit natürlich auch nicht. Es gibt schlicht keinen Standardkonformen Weg das zu tun.

okay, das 'aus class mach struct' war dumm gewählt. hätt' ich mal besser zwei classes genommen, wobei bei der einen alles public ist. klar ist das ein fauler trick aber in der praxis wird bestimmt kein c++ compiler aus zwei fast gleichen klassen (mit dem einzigen unterschied dass bei der einen alles public ist) unterschiedliche objekte im speicher erzeugen, so dass der cast immer funzen sollte. das 'private/public' hat ja nur während des compiliervorgangs eine bedeutung. später dann, im executable, ist 'private/public' nicht mehr vorhanden...

Bashar

net schrieb:

klar ist das ein fauler trick aber in der praxis wird bestimmt kein c++ compiler aus zwei fast gleichen klassen (mit dem einzigen unterschied dass bei der einen alles public ist) unterschiedliche objekte im speicher erzeugen, so dass der cast immer funzen sollte.

Verletzt aber die One-Definition-Rule.

net 0

Bashar schrieb:

Verletzt aber die One-Definition-Rule.

ihr findet doch immer was...

Zeus

C++ ist nicht umsonst eine Multi-Paradigmasprache, der Entwickler steht in Verantwort das richtige zu machen

man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert

Jester

net schrieb:

Bashar schrieb:

Verletzt aber die One-Definition-Rule.

ihr findet doch immer was...

Sag ich doch. :p

rüdiger

Jester schrieb:

net schrieb:

Jester schrieb:

#define private public ist afaik laut Standard verboten. Man darf keine keywords definen. Also fällt der Weg schonmal weg. Das andere was Du geschrieben hast ist natürlich genauso unportabel und undefiniert.

mit type-casts bekommt man aber jedes 'private' weg

Zeig mal bitte eine portable, standardkonforme Lösung um das private wegzukriegen. Ich bin gespannt. (Bitte keine Sonderfälle wie ne template-Funktion in der Klasse oder sowas).

Natürlich ist es nicht portabel binär auf eine Klasse zuzugreifen. Aber ich kann mir auch eine binäre Struktur in C ausdenken, die ich als Klasse benutze. Ändert für mich nichts an dem Punkt.

Aber dann meinetwegen folgender Code. Verstößt ja auch gegen den Zugriffschutz

class foo {
  int i;
public:
  int &bar() { return i; }
};

int main() {
  foo f;
  int &j=f.bar();
  j = 100; //perfekt legales C++ und umgeht die Zugriffskontrolle
}

daHa

dieser sred kann wirklich einiges

letztes schmankerl:

class foo {
private:
int i;
public:
int &bar() { return i; }
};

schuld is natuerlich die sprache, was sonst

Jester

Genau

rüdiger:

Sogar wenn Du die Referenz wegläßt kann man mit diesem "fiesen Trick" ja schon den Wert der Variablen auslesen.

Wo umgehst Du da jetzt *von außen* das private? Daß man von der Klasse aus kann ist klar, sonst wäre die Variable ja nicht benutzbar.

Ich bin gespannt, was noch an Vorschlägen kommt

Objektorientierung hat man nur bei der Verwendung von Vererbung, ansonsten wär es nur objektbasiert (so wie ältere Visual Basic Versionen z.B.)

rüdiger

Okay, war ein schlechtes Beispiel. War gestern wohl zu müde.

Aber btw finde ich nichts im Standard, was Shades #define verbietet. Ein Macro kann so wie ich das sehe jeder identifier sein.

meine Lösung ist so weit ich weiß Implementation-Defined-Behaviour und kein Undefined-Behaviour. Es ist also in Ordnung, ich muss eben nur auf einer anderen Implementierung nicht erwarten, dass das richtige rauskommt. Aber im Grunde ist es kein Thema so etwas für andere Implementierungen anzupassen oder zeig mir eine Implementierung, auf der etwas ähnliches nicht funktioniert.

Aber das führt zu weit von der Diskussion ab, was OOP jetzt ausmacht. Wie Javascript oder CLOS zeigen, ist es egal ob man Zugriffskontrollen hat oder nicht.

@daHa
ich sag nicht, dass die Sprache schuld ist, sondern nur das Zugriffskontrolle sich effektiv nicht durchsetzen lässt.

Shade Of Mine

rüdiger schrieb:

Aber btw finde ich nichts im Standard, was Shades #define verbietet. Ein Macro kann so wie ich das sehe jeder identifier sein.

du darfst keine keywords redefinen. steht irgendwo im standard.

finde das aber relativ uninteressant weil es praktisch immer geht. genau wie man vector vor dem TR1 schon als c-like-array benutzen konnte.

und kapselung != zugriffskontrolle

daHa

rüdiger schrieb:

@daHa
ich sag nicht, dass die Sprache schuld ist, sondern nur das Zugriffskontrolle sich effektiv nicht durchsetzen lässt.

soll ichs auch skandaloes finden das jemand der den src code hat alles moegliche damit auffuehren kann?

was machst wennst nur a lib mit headern hast wo nur die public drinnen stehn und du zugriffkontrolle umgehen wills/musst?
(ausser sinnvolles wie am besten den ersteller der lib zu kontaktieren und um entsprechende aenderungen zu ersuchen bzw sich um den src code zu bemuehen wenn moeglich)

wenn schon theoretische konstrukte diskutieren deren praxsisrelevater sinn fraglich bis diskussionswuerdig is dann bitte doch eher themen wos so leiwande akademische kunstbegriffe wie deadly diamond of death gibt, das liest sich wesentlich blumiger und macht sich auch bei praesentationen ungemein gut.

volkard

daHa schrieb:

akademische kunstbegriffe wie deadly diamond of death gibt, das liest sich wesentlich blumiger und macht sich auch bei praesentationen ungemein gut.

und vor allem in übersetzungen, wo auf einmal diamanten statt rauten auftauchen. (nur eine weitere steigerung der silikonchips)

Shade Of Mine

daHa schrieb:

soll ichs auch skandaloes finden das jemand der den src code hat alles moegliche damit auffuehren kann?

in C++ brauchst du nur die header, nicht den source code...

es geht darum dass einige leute OO Code damit definieren dass die sprache access control bietet. und wir zeigen hier lediglich dass access control in C++ nur syntaktischer zucker ist.

stichwort:
protecting against Murphy (zufall, pech, dumm gelaufen) vs. protecting against Machiavelli (absicht und vorsatz)

access control ist nett fuer die "murphy" situationen aber gegen eine "Machiavelli" situation - da bringt es nichts.

folglich kann OO nicht davon abhaengen ob es access control gibt, denn access control kann umgangen werden - und ist somit nicht verlaesslich.

man muss sich also immer auf den anwender des codes verlassen dass er da nicht rumpfuscht. on man jetzt access control in der sprache hat oder nicht...