Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[CStoll]

@Mr.N: Weiß ich selber nicht so recht.

@Xin: Wenn ich auf eine Frage keine verwertbare Antwort erhalte, frage ich nach - besonders wenn die vorhandenen Antworten dem Thema nur ausweichen. Du hast zwar auf meine Fragen (anfangs) reagiert, aber dabei auch an der Frage vorbeigeredet.

Und spätestens an dem Punkt, wo du angefangen hast, alles und jeden als "Kindergarten" zu bezeichnen, ist das Niveau des Threads endgültig in den Keller gegangen. (das begann etwa auf Seite 20 - und auch ein "das soll keine Beleidigung sein" als Einleitung mindert den Effekt nur unwesentlich)
(vorher hattest du die Bezeichung "Kindergarten" schon zweimal erwähnt - gegenüber ulfbulf und als Reaktion auf "Post 101")

---

OK, mein Vorschlag: Wir vergessen den kompletten Thread und fangen noch einmal bei 0 an (am besten in einem neuen Thread). Einverstanden?

[rqwe6g7]

CStoll schrieb:

@Xin: Wenn ich auf eine Frage keine verwertbare Antwort erhalte, frage ich nach - besonders wenn die vorhandenen Antworten dem Thema nur ausweichen. Du hast zwar auf meine Fragen (anfangs) reagiert, aber dabei auch an der Frage vorbeigeredet.

Ja, das kann er gut.

OK, mein Vorschlag: Wir vergessen den kompletten Thread und fangen noch einmal bei 0 an (am besten in einem neuen Thread). Einverstanden?

In nem anderen Forum bitte.

[Xin]

Shade Of Mine schrieb:

Was natürlich möglich wäre - wäre eine "static" Vererbung wie sie manchmal gefordert wird. Also eine Vererbung die keine ist-ein Beziehung repräsentiert, sondern lediglich Code-Reuse Zwecken dient. Hier gäbe es dann keine Konvertierung von Derived zu Base. Ich kenne aber keine Sprache die dieses Konzept nutzt - ich habe in C++ ein paar mal Forderungen diesbezüglich gesehen, aber ich glaube das Standardisierungs Komitee ist Meilenweit davon entfernt sowas zu integrieren.

Mit einer static-Vererbung wäre der ganze Ansatz von Xin natürlich weit besser - da man eine Menge Nachteile ausgleichen würde da es keine impliziten Konvertierungen mehr gibt. Dann wäre es sogar möglich, dass Xins Ansatz eine ziemlich ideale Lösung ist - je nachdem wie static-Vererbung implementiert ist.

Mir fällt dazu grade nur private Vererbung ein, aber ich vermute, ich missverstehe, was Du meinst.
Ich wäre aber interessiert, das genau zu verstehen.

Shade Of Mine schrieb:

Was deine Literatur Hinweise betrifft: wir haben dir versucht zu erklären was du falsch verstanden/interpretiert hast. Aber auch dort wolltest du nicht hören.

Erklärt wurde viel, leider meist haarscharf an der Logik vorbei und häufig auch komplett in die andere Richtung.
Darauf wollte ich wirklich nicht hören.

[Jester]

Wo Du grad so eifrig postest und ja auch auf alles eingehst, könntest Du da noch schnell was zu CStolls Ausgabe-Beispiel mit dem Volumen sagen?

[Xin]

Shade Of Mine schrieb:

Worum es dabei geht ist, eine Vererbung einzuführen die keine ist-ein Beziehung bedeutet. Wenn also Meter von Integer erbt, dann hat Meter alle Methoden von Integer aber ist eben kein Integer. Das würde sich darin Niederschlagen dass es keine Konvertierung von Meter zu Integer gibt (es sei denn man definiert sie sich explizit selber). Diese Vererbung wird also eher als ein "has-a" oder "is-implemented-in-terms-of" verstanden - auch wenn sie aussieht wie eine public Vererbung.

Willkommen in Genesys.

Das ist etwa das, wovon ich die WindowFlags abgeleitet habe.

Shade Of Mine schrieb:

Da C++ dies aber nicht bietet - würde ich eben eine C++ Lösung nehmen die ebenfalls keine dieser genannten Nachteile hat. Zumal der Ansatz mit Meter/Meter einfach nur genial ist.

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand. Dazu vielleicht nochmal mein Beispiel: Zwei Kräfte zeigen in orthogonale Richtungen. Hier kürzt sich kg*m/s² mit kg*m/s². Ist das jetzt die gleiche Einheit wie Meter/Meter? Und wenn ja wieso kürzt sich kg/s² raus, aber Meter/Meter bliebt?

CStoll schrieb:

Und spätestens an dem Punkt, wo du angefangen hast, alles und jeden als "Kindergarten" zu bezeichnen, ist das Niveau des Threads endgültig in den Keller gegangen. (das begann etwa auf Seite 20 - und auch ein "das soll keine Beleidigung sein" als Einleitung mindert den Effekt nur unwesentlich)

Der Thread war etwa ab Seite 15 kaputt. Und wenn ich nach 15 Seiten Beleidigungen das ganze als Kindergarten einstufe, dann ist das nicht der Punkt, wo ich derjenige bin, der mit Beleidigungen anfängt.

CStoll schrieb:

(vorher hattest du die Bezeichung "Kindergarten" schon zweimal erwähnt - gegenüber ulfbulf und als Reaktion auf "Post 101")

Das würde ich jetzt auch nicht anders einstufen.

CStoll schrieb:

OK, mein Vorschlag: Wir vergessen den kompletten Thread und fangen noch einmal bei 0 an (am besten in einem neuen Thread). Einverstanden?

Zwischen uns? Sicher, warum nicht.

Das Herr der Unregistrierten hat sich ja bereits dazu geäußert.

Jester schrieb:

Wo Du grad so eifrig postest und ja auch auf alles eingehst, könntest Du da noch schnell was zu CStolls Ausgabe-Beispiel mit dem Volumen sagen?

Nein, den das habe ich im Verlauf des Threads schon zwei- oder dreimal gesagt. Ich übertitelte das Protokoll nicht um sonst als Post-Mortem. Ich werde das Thema auf keinen Fall weiterführen.

[Shade Of Mine]

Xin schrieb:

Mir fällt dazu grade nur private Vererbung ein, aber ich vermute, ich missverstehe, was Du meinst.
Ich wäre aber interessiert, das genau zu verstehen.

Kleines Code Beispiel:

class Vector {
public:
  int get(int pos) {}
  int size() {}
};

class RangeCheckedVector : static Vector {
public:
  int get(int pos) {
    if(0 <= pos && pos < size())
      return Vector::get(pos);
    else
      throw range_exception();
  }
};

Wenn wir hier nun static durch public ersetzen, ist folgender Code fehlerhaft:

int foo(Vector const& vec) {
  return vec.get(10);
}

RangeCheckedVector v;
foo(v);

Mit static würde dieser Code einen Fehler liefern. Ohne static Vererbung müsste man den Code also so schreiben:

class RangeCheckedVector {
private:
  Vector impl;
public:
  int get(int pos) {
    if(0 <= pos && pos < size())
      return impl.get(pos);
    else
      throw range_exception();
  }

  int size() {
    return impl.size();
  }
};

Der Vorteil von static ist nun, dass wir size nicht forwarden müssen - was interessant wird, wenn wir ein Policy haben:

template<typename Policy>
class Vector : static Policy {
public:
  int get(int pos) {}
  int size() {}
};

template<typename Policy>
class RangeCheckedVector : static Vector<Policy> {
public:
  int get(int pos) {
    if(0 <= pos && pos < size())
      return Vector::get(pos);
    else
      throw range_exception();
  }
};

class Policy {
public:
  int sum_all_elements() {}
};

RangeCheckedVector<Policy> v;

v.sum_all_elements();

Dies wäre mit Komposition oder private Vererbung nicht möglich.

In wie weit dies sinnvoll ist, sei mal dahin gestellt. Denn wie gesagt es gibt AFAIK keien Sprache die das bietet - denn so nett es auch aussieht, man kommt sehr gut ohne aus. Es ist aber vorallem dann interessant, wenn man von value typen erben will - denn public von value typen erben ist böse.

Nachtrag:

Xin schrieb:

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

C++ bietet aber keine static Vererbung und somit ist es nicht möglich. Du hast in allen deinen Posts nicht ein Wort davon verloren dass du ein Konzept wie diese static Vererbung haben willst.

Du hast argumentiert dass man um die Konvertierung die eine ist-ein Beziehung bedeutet herum kommen kann und hast abstrusive Bedingungen aufgestellt wie eben nur explicit CTors und dergleichen und hast somit versucht die Symptome zu bekämpfen nicht aber die Ursache der Probleme.

[Fragender2]

Xin schrieb:

Zwei Kräfte zeigen in orthogonale Richtungen. Hier kürzt sich kg*m/s² mit kg*m/s².

Wieso das?

Xin schrieb:

Ist das jetzt die gleiche Einheit wie Meter/Meter? Und wenn ja wieso kürzt sich kg/s² raus, aber Meter/Meter bliebt?

meter/Meter wird natürlich zu "einheitenlos", allerdings nur solche konstruktionen, in deinem Ansatz ist alles implizit einheitenlos.

[Mr. N]

Xin schrieb:

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand.

http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Units

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

Mir fällt dazu grade nur private Vererbung ein, aber ich vermute, ich missverstehe, was Du meinst.
Ich wäre aber interessiert, das genau zu verstehen.

Kleines Code Beispiel:

Dies wäre mit Komposition oder private Vererbung nicht möglich.

Ich verstehe Deine Idee, ich finde sie gut, weil ich komme ja gewissermaßen von dieser Idee mit den WindowFlags in diesen Thread.
Aber Dein Codebeispiel hakt an einer Stelle: Der RangedCheckedVector ist kein Vector, ergo musst Du eine Basisklasse haben oder zwei foo()-Funktionen.

Die optimale Lösung hier wäre OOP zu verwenden, also die get Funktion virtuell zu machen und öffentlich abzuleiten.
Wenn das nicht möglich ist, weil das Interface von Vector Dir das nicht erlaubt, könnte die "static-Vererbung" Dir eine Basisklasse geben, die sich wie ein Vector verhält, aber nachträglich die Funktion get() virtuell macht.
Womit wir uns von OOP in Richtung AOP bewegen. (Aspektorientierte Programmierung)

Shade Of Mine schrieb:

In wie weit dies sinnvoll ist, sei mal dahin gestellt. Denn wie gesagt es gibt AFAIK keien Sprache die das bietet - denn so nett es auch aussieht, man kommt sehr gut ohne aus. Es ist aber vorallem dann interessant, wenn man von value typen erben will - denn public von value typen erben ist böse.

AOP ist ein Ansatz, der noch recht jung ist. OOP ist seit sagen wir 10 Jahren Massentauglich, C++ gibt's seit 20 Jahren und Simula noch viel länger. Bis AOP in C++ existiert und massentauglich wird, vergeht noch das eine oder andere Jahrzehnt.

Shade Of Mine schrieb:

Nachtrag:

Xin schrieb:

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

C++ bietet aber keine static Vererbung und somit ist es nicht möglich. Du hast in allen deinen Posts nicht ein Wort davon verloren dass du ein Konzept wie diese static Vererbung haben willst.

Doch, ziemlich weit vorne, als ich sagte, dass ich die WindowFlags aus einem Genesys-Konzept übernommen habe und natürlich nicht perfekt auf C++ umsetzen konnte. Dort beschrieb ich es nicht als "static Vererbung", sondern aus Mischung von privater Vererbung (keine ist-ein-Beziehung) und öffentlicher (die Elemente werden in den Namensraum der abgeleiteten Klasse übernommen).

Shade Of Mine schrieb:

Du hast argumentiert dass man um die Konvertierung die eine ist-ein Beziehung bedeutet herum kommen kann und hast abstrusive Bedingungen aufgestellt wie eben nur explicit CTors und dergleichen und hast somit versucht die Symptome zu bekämpfen nicht aber die Ursache der Probleme.

An den expliziten CTors kommt man leider immernoch nicht vorbei. ^^

[Tellerrand]

@Shade

Du willst durch static Vererbung die Methoden und Attribute erben, aber die implizite Typumwandlung verbieten? Also eine zweite Vererbungsmöglichkeit ganz ohne Typen?

Da würde ich mich eher Code erzeugender Programmiermodelle bedienen, da sind wir imho im Bereich der Metaprogrammierung.
Sowas würde ich nicht gerne in einem Klassenmodell sehen, sondern davon abgekapselt.
Es geht ja nicht darum einen Typ zu definieren, eine Vererbungshirachie, sondern nur darum Code/Schreibarbeit zu sparen.
Meiner Meinung nach trennt man die beiden Bereiche "Code Redundanzen" und "OOP - Typ- / Klassensystem" leider viel zu selten.

So sehe ich das.

[CStoll]

Xin schrieb:

Shade Of Mine schrieb:

Worum es dabei geht ist, eine Vererbung einzuführen die keine ist-ein Beziehung bedeutet. Wenn also Meter von Integer erbt, dann hat Meter alle Methoden von Integer aber ist eben kein Integer. Das würde sich darin Niederschlagen dass es keine Konvertierung von Meter zu Integer gibt (es sei denn man definiert sie sich explizit selber). Diese Vererbung wird also eher als ein "has-a" oder "is-implemented-in-terms-of" verstanden - auch wenn sie aussieht wie eine public Vererbung.

Willkommen in Genesys.

Das ist etwa das, wovon ich die WindowFlags abgeleitet habe.

OK, das Problem hatten wir schon weiter vorne in diesem Thread - C++ ist nicht Genesys, und manche Sprachkonstrukte, die du in Genesys integriert hast, lassen sich nur ungenügend in C++ nachbilden. Du hast deine (afair) Typerweiterungen - und eine Länge als "Erweiterung" von int wäre durchaus sinnvoll - und du nimmst dir die C++ Vererbung und versuchst, das Konzept damit umzusetzen. Letzteres scheitert an der unterschiedlichen Semantik.

Xin schrieb:

Shade Of Mine schrieb:

Da C++ dies aber nicht bietet - würde ich eben eine C++ Lösung nehmen die ebenfalls keine dieser genannten Nachteile hat. Zumal der Ansatz mit Meter/Meter einfach nur genial ist.

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

Nein, du hast hier die (theoretische) Möglichkeit thematisiert, mit C++ Mitteln von build-in's abzuleiten. Daß du dir ein neues Ableitungs-Konzept mit eigener Semantik wünschst, hast du nie erwähnt.

Xin schrieb:

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand. Dazu vielleicht nochmal mein Beispiel: Zwei Kräfte zeigen in orthogonale Richtungen. Hier kürzt sich kg*m/s² mit kg*m/s². Ist das jetzt die gleiche Einheit wie Meter/Meter? Und wenn ja wieso kürzt sich kg/s² raus, aber Meter/Meter bliebt?

Meter/Meter kürzt sich genauso heraus wie alle übrigen Einheiten - wenn zwei gleichartige Größen dividiert werden, bleibt in jedem Fall ein einheitenloser Wert übrig.
(btw, was die Orthogonalität damit zu tun hat, müsstest du mir nochmal erklären)

Xin schrieb:

CStoll schrieb:

Und spätestens an dem Punkt, wo du angefangen hast, alles und jeden als "Kindergarten" zu bezeichnen, ist das Niveau des Threads endgültig in den Keller gegangen. (das begann etwa auf Seite 20 - und auch ein "das soll keine Beleidigung sein" als Einleitung mindert den Effekt nur unwesentlich)

Der Thread war etwa ab Seite 15 kaputt. Und wenn ich nach 15 Seiten Beleidigungen das ganze als Kindergarten einstufe, dann ist das nicht der Punkt, wo ich derjenige bin, der mit Beleidigungen anfängt.

Wenn du der Meinung bist, von irgendwem beleidigt worden zu sein, kannst du das dem betroffenen auch direkt sagen - zu dem Zeitpunkt wäre es vermutlich noch möglich gewesen, die Missverständnisse aufzuklären. Aber blind auf alles zu schießen, was sich bewegt, hilft niemandem.

Xin schrieb:

CStoll schrieb:

OK, mein Vorschlag: Wir vergessen den kompletten Thread und fangen noch einmal bei 0 an (am besten in einem neuen Thread). Einverstanden?

Zwischen uns? Sicher, warum nicht.

OK, das ist ein Wort.

Xin schrieb:

Jester schrieb:

Wo Du grad so eifrig postest und ja auch auf alles eingehst, könntest Du da noch schnell was zu CStolls Ausgabe-Beispiel mit dem Volumen sagen?

Nein, den das habe ich im Verlauf des Threads schon zwei- oder dreimal gesagt. Ich übertitelte das Protokoll nicht um sonst als Post-Mortem. Ich werde das Thema auf keinen Fall weiterführen.

Ja, du stufst solche Fehler als "Angelegenheit des Programmierers" ein - und erwartest demzufolge, daß er keine Tipfehler in seine Programme einbaut.

[Jester]

Xin schrieb:

Nein, den das habe ich im Verlauf des Threads schon zwei- oder dreimal gesagt. Ich übertitelte das Protokoll nicht um sonst als Post-Mortem. Ich werde das Thema auf keinen Fall weiterführen.

In diesem Fall geht ganz offensichtlich Typinformation verloren bzw. wird nicht verwendet, so dass ein Fehler der im einen Fall zur Compilezeit bemerkt wird, hier erst zur Laufzeit eintritt. Das ist ein handfester Vorteil des Systems ohne implizite int-Umwandlung und eben keine Geschmacksache mehr. Inwiefern Du darauf dann eingegangen bist sehe ich ehrlich gesagt nicht. Und nein: Jegliche berechtigte Kritik als Geschmacksache abzutun ist nicht darauf eingegangen.

[Xin]

CStoll schrieb:

Xin schrieb:

Shade Of Mine schrieb:

Worum es dabei geht ist, eine Vererbung einzuführen die keine ist-ein Beziehung bedeutet. Wenn also Meter von Integer erbt, dann hat Meter alle Methoden von Integer aber ist eben kein Integer. Das würde sich darin Niederschlagen dass es keine Konvertierung von Meter zu Integer gibt (es sei denn man definiert sie sich explizit selber). Diese Vererbung wird also eher als ein "has-a" oder "is-implemented-in-terms-of" verstanden - auch wenn sie aussieht wie eine public Vererbung.

Willkommen in Genesys.

Das ist etwa das, wovon ich die WindowFlags abgeleitet habe.

OK, das Problem hatten wir schon weiter vorne in diesem Thread - C++ ist nicht Genesys, und manche Sprachkonstrukte, die du in Genesys integriert hast, lassen sich nur ungenügend in C++ nachbilden. Du hast deine (afair) Typerweiterungen - und eine Länge als "Erweiterung" von int wäre durchaus sinnvoll - und du nimmst dir die C++ Vererbung und versuchst, das Konzept damit umzusetzen. Letzteres scheitert an der unterschiedlichen Semantik.

Xin schrieb:

Shade Of Mine schrieb:

Da C++ dies aber nicht bietet - würde ich eben eine C++ Lösung nehmen die ebenfalls keine dieser genannten Nachteile hat. Zumal der Ansatz mit Meter/Meter einfach nur genial ist.

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

Nein, du hast hier die (theoretische) Möglichkeit thematisiert, mit C++ Mitteln von build-in's abzuleiten. Daß du dir ein neues Ableitungs-Konzept mit eigener Semantik wünschst, hast du nie erwähnt.

!?!?
Mir fehlen die Worte. Das sind die Punkte, wo ich etwas schreibe, wie "Liebelein" oder "<stirnklatsch>".
Schau Dir an, was Du unterhalb von "Willkommen in Genesys" schreibst und dann direkt darunter dies.

CStoll schrieb:

Xin schrieb:

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand. Dazu vielleicht nochmal mein Beispiel: Zwei Kräfte zeigen in orthogonale Richtungen. Hier kürzt sich kg*m/s² mit kg*m/s². Ist das jetzt die gleiche Einheit wie Meter/Meter? Und wenn ja wieso kürzt sich kg/s² raus, aber Meter/Meter bliebt?

Meter/Meter kürzt sich genauso heraus wie alle übrigen Einheiten - wenn zwei gleichartige Größen dividiert werden, bleibt in jedem Fall ein einheitenloser Wert übrig.
(btw, was die Orthogonalität damit zu tun hat, müsstest du mir nochmal erklären)

Meter/Meter ergibt einen Winkel, wenn die Teilkräfte/Teilstrecken rechtwinklig sind. Satz des Pythagoras, Gegenkathete ist rechtwinklig zur Ankathete. Sind die Größen abhängig hast Du eine Hypothenuse von 0, also kein Dreieck, keine Winkel.

CStoll schrieb:

Xin schrieb:

Der Thread war etwa ab Seite 15 kaputt. Und wenn ich nach 15 Seiten Beleidigungen das ganze als Kindergarten einstufe, dann ist das nicht der Punkt, wo ich derjenige bin, der mit Beleidigungen anfängt.

Wenn du der Meinung bist, von irgendwem beleidigt worden zu sein, kannst du das dem betroffenen auch direkt sagen - zu dem Zeitpunkt wäre es vermutlich noch möglich gewesen, die Missverständnisse aufzuklären. Aber blind auf alles zu schießen, was sich bewegt, hilft niemandem.

Ich schieße nicht auf jeden. Ich beschränke mich auf diejenigen, die es in meinen Augen verdient haben.

[Mr. N]

Mr. N schrieb:

Xin schrieb:

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand.

http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Units

Nachdem ich das mal genauer angesehen habe, stelle ich fest, dass die fast genau den von mir skizzierten Weg gehen. :p

[Jester]

Xin schrieb:

Ich schieße nicht auf jeden. Ich beschränke mich auf diejenigen, die es in meinen Augen verdient haben.

Oder anders gesagt: Du widerlegst nur die Aussagen bei denen Dir auf die schnelle was einfällt. Alles andere wird einfach ignoriert, pardon, haben's nicht verdient.

[Shade Of Mine]

Tellerrand schrieb:

Du willst durch static Vererbung die Methoden und Attribute erben, aber die implizite Typumwandlung verbieten? Also eine zweite Vererbungsmöglichkeit ganz ohne Typen?

Da würde ich mich eher Code erzeugender Programmiermodelle bedienen, da sind wir imho im Bereich der Metaprogrammierung.
Sowas würde ich nicht gerne in einem Klassenmodell sehen, sondern davon abgekapselt.

Es hat schon seinen Grund warum es nicht unterstützt wird.
Der einzige Grund warum ich darauf gekommen bin ist, dass es irgendwie genau das ist was Xins Ansatz sinnvoll erscheinen lassen würde. Es war irgendwann mal ein proposal für den C++ Standard - wurde aber abgelehnt.

Es hat von der fragwürdigen Sinnhaftigkeit auch diverse technische Probleme die es zu bedenken gibt. Ich wollte es lediglich aufzeigen und nicht darüber werten ob es sinnvoll ist oder nicht.

Fakt ist: C++ bietet dieses Konzept nicht an, deshalb ist Xins Versuch es zu emulieren nicht zielführend.

Xin schrieb:

Aber Dein Codebeispiel hakt an einer Stelle: Der RangedCheckedVector ist kein Vector, ergo musst Du eine Basisklasse haben oder zwei foo()-Funktionen.

Das ist der Sinn der Sache. foo muss ein Template sein. Statische Polymorphie - aber das lassen wir jetzt lieber.

Die optimale Lösung hier wäre OOP zu verwenden, also die get Funktion virtuell zu machen und öffentlich abzuleiten.

Das ist aus einer C++ Sicht eine schlechte Idee - zumindest meistens. Die ganze Idee hinter der statischen Vererbung ist ja, genau das zu umgehen.

AOP ist ein Ansatz, der noch recht jung ist. OOP ist seit sagen wir 10 Jahren Massentauglich, C++ gibt's seit 20 Jahren und Simula noch viel länger. Bis AOP in C++ existiert und massentauglich wird, vergeht noch das eine oder andere Jahrzehnt.

statische Vererbung hat mit AOP erstmal recht wenig zu tun.

Doch, ziemlich weit vorne, als ich sagte, dass ich die WindowFlags aus einem Genesys-Konzept übernommen habe und natürlich nicht perfekt auf C++ umsetzen konnte. Dort beschrieb ich es nicht als "static Vererbung", sondern aus Mischung von privater Vererbung (keine ist-ein-Beziehung) und öffentlicher (die Elemente werden in den Namensraum der abgeleiteten Klasse übernommen).

Du hast aber die ganze Zeit versucht es in C++ zu rechtfertigen und das ist das Problem. Wie die Lösung in einer von dir erfundenen Sprache aussieht, kann keiner bewerten. Was wir können ist den C++ Ansatz zu berwerten und der ist total falsch.

An den expliziten CTors kommt man leider immernoch nicht vorbei. ^^

Nimm den Meter/Meter Ansatz von Mr.N oder meinen asInt Ansatz (der dem von Mr.N unterlegen ist) und du brauchst diese expliziten CTors nicht mehr. Sie mögen öfters Sinn machen - da widerspricht sicher Niemand - aber worum es geht ist, dass das vorhandensein eines non-explizit CTors den Code nicht kaputt macht wie es bei dir der Fall ist. Viele Leute verwenden zuviele non-explicit CTors, das stimmt, aber in einer Menge Situationen sind non-explicit CTors einfach sinnvoll.

[Theston]

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand. Dazu vielleicht nochmal mein Beispiel: Zwei Kräfte zeigen in orthogonale Richtungen. Hier kürzt sich kg*m/s² mit kg*m/s². Ist das jetzt die gleiche Einheit wie Meter/Meter? Und wenn ja wieso kürzt sich kg/s² raus, aber Meter/Meter bliebt?

Meter/Meter kürzt sich genauso heraus wie alle übrigen Einheiten - wenn zwei gleichartige Größen dividiert werden, bleibt in jedem Fall ein einheitenloser Wert übrig.
(btw, was die Orthogonalität damit zu tun hat, müsstest du mir nochmal erklären)

Meter/Meter ergibt einen Winkel, wenn die Teilkräfte/Teilstrecken rechtwinklig sind. Satz des Pythagoras, Gegenkathete ist rechtwinklig zur Ankathete. Sind die Größen abhängig hast Du eine Hypothenuse von 0, also kein Dreieck, keine Winkel.

Dein Verständnis des Satz von Pythagoras scheint nicht über Klasse 6 hinauszugehen. Wenn man irgendwelche Strecken dividiert, kürzen sich die Einheiten IMMER, egal ob rechtwinklig stehend oder nicht. Es kommt dabei NIE ein Winkel heraus, höchstens ein (Co-)Tangens.
Strecken wild miteinander zu dividieren, über deren Beziehung du nichts weißt, ist aber mathematisch völliger Blödsinn.
Entweder du weißt, dass die Strecken orthogonal sind, dann weißt du, dass ein Tangens herauskommt (KEIN Winkel).
Oder du weißt es nicht, dann musst du Vektoren und Vektoroperationen verweden, wenn du eine mathematische Beziehung ausdrücken willst.
Das simple Dividieren von einheitengleichen Größen ist immer einheitenlos, es drückt immer ein Verhältnis aus. In einem bestimmten Fall ist dieses Verhältnis halt der Tangens.

[Tellerrand]

Xin schrieb:

Meter/Meter ergibt einen Winkel, wenn die Teilkräfte/Teilstrecken rechtwinklig sind. Satz des Pythagoras, Gegenkathete ist rechtwinklig zur Ankathete. Sind die Größen abhängig hast Du eine Hypothenuse von 0, also kein Dreieck, keine Winkel.

Meter ist kein Vektor!
Meter ist eine reine Längenangabe, keine Richtung, kein Winkel.

Wenn du mit Richtungen, Winkeln oder ähnlichem hantieren willst, so nutze doch bitte auch deren Einheiten, deren Typen.

[Mr. N]

Shade Of Mine schrieb:

Nimm den Meter/Meter Ansatz von Mr.N oder meinen asInt Ansatz (der dem von Mr.N unterlegen ist) und du brauchst diese expliziten CTors nicht mehr. Sie mögen öfters Sinn machen - da widerspricht sicher Niemand - aber worum es geht ist, dass das vorhandensein eines non-explizit CTors den Code nicht kaputt macht wie es bei dir der Fall ist. Viele Leute verwenden zuviele non-explicit CTors, das stimmt, aber in einer Menge Situationen sind non-explicit CTors einfach sinnvoll.

Also einen int-Konstruktor sollte man IMHO nicht anbieten. Im Grunde sollte außer dem Copy-Constructor (und evtl. Konversionskonstruktoren aus kompatiblen Einheiten) gar kein öffentlicher Konstruktor nötig sein.

[scrub]

Xin schrieb:

Und wo mir grade (~40%) durch den Kopf geht, dass der Thread beleidigungstechnisch doch ziemlich langweilig ist, kommen wir endlich zum ersten vollkommen sinnlosen Posting, das eine Wertung enthält:

scrub_ schrieb:

Xin schrieb:

Ich finde den Kommentar "Kann Nüsse enthalten, bei Nussallergie nicht konsumieren" auf einer Packung Erdnüsse für lächerlich.

Wieder mal glaubst Du Dich im Besitz der absoluten Wahrheit. Anstatt einfach mal die Möglichkeit zu überdenken, daß Nüsse im Sinne dieses Hinweises etwas anderes sind als das, was Du Dir unter Nüssen vorstellst.

Zu Deinem restlichen Unfug braucht man schon nix mehr zu sagen. Fenster sind keine Flags, sondern haben (vielleicht) welche.
Ansonsten erklär einfach mal, was Deiner Meinung nach ein Flag ist. Ich bin an Deiner Meinung interessiert, jedoch nicht an Ablenkungsmanövern.

Das ist das erste Posting, dass mir auffällt, dass wertend und im Ton vollkommen daneben schlägt ohne dass der Absender wie ulfbuff offensichtlich die "Ich bin ein Troll"-Auszeichnung trägt.
Dass Erdnüsse eigentlich Bohnen und keine Nüsse sind, wußte er zu dem Zeitpunkt noch nicht. Es spielt auch keine Rolle, denn die Intention des Satzes ist wohl eindeutig und wäre genauso wenn ich auf Paprikas einen Hinweis drucke "Kann Paprika enthalten", damit Paprika-Allergiker nicht versehentlich Paprika kaufen.

Ähm LOL? Ich wußte es die ganze Zeit, nur Du hattest offensichtlich keine Ahnung, sonst hättest Du Dir als Beispiel für eine unsinnige Warnung nicht gerade ein Beispiel rausgesucht, das eben _nicht_ sinnlos ist.
Schon interessant, wie Du hier die Wahrheit verdrehst.

Xin schrieb:

Die optimale Lösung hier wäre OOP zu verwenden, also die get Funktion virtuell zu machen und öffentlich abzuleiten.

Hat Dein Physik-LK mit gepulster digitaler Strahlung experimentiert? Oder woher kommt Deine revolutionäre Ansicht über Winkel und Satz des Pytagoras?