[Programmiererstammtisch] "Zum ächzenden Compiler"

[Gullix]

Wenn dann allerdings ein B : A (und C : B, ...) dazukommt, das die Member von A benutzen koennen soll, wird das wieder unangenehm

protected?

[Mongke Khan]

Wenn es in A protected ist, damit B es nutzen kann, sieht doch AChil : A es genauso?

[Harleen]

Pack doch einfach Zeiger statt Objekte in den Vector von A. Dann kannst du da auch abgeleitete Klassen reinpacken.

class Obj {
  // ...
} 

class ObjChild : public Obj {
  // ...
}

class A {
  std::vector<std::unique_ptr<Obj>> m_objs;
}

class AChild : public A{
  // benutzt m_objs für ObjChild
}

[alpha civ]

(C++)

Wie wuerdet ihr folgendes Szenario umsetzen: [...]

Das ist kein Scenario, das ist schon eine mögliche Implementierung. Welches Verhalten soll den die Klasse haben bzw. deren Methoden? Das ist doch die spannende Frage. Daraus ergibt sich dann die Implementierung.

Grundsätzlich solltest du dir auch die folgende Frage stellen, ob du ein polymorphes Verhalten benötigst. Falls nein, dann solltest du eher keine Vererbung verwenden. Sorgt nur für unnötige Kopplung und erhöht die Komplexität. Dann lieber Templates verwenden, was auch kein Overkill ist, sondern auch genau dafür da ist.

[Mongke Khan]

Templates muss man ggf. aber immer durch den Code schleppen

Setting ist: Ich habe geometrische Objekte (Shapes), von denen manche konvex sind. Die können alles, was die normalen auch können (Flächeninhalt berechnen, Prüfen ob ein Punkt drin liegt) und noch mehr (z.B. den Mittelpunkt berechnen, der garantiert im Shape liegt).
Nun kommt ein Aggregator dazu, der neben Shapes noch mehr verwaltet (z.B. Punkte, die in diesen Shapes liegen können). Und es gibt auch einen, der nur konvexe Shapes zulassen soll (und dann dadurch auch ein paar Sachen anders/ effizienter machen kann, als der normale Aggregator). Kontextabhängig wird auf den aber auch als "normaler" Aggregator geschaut.

[Harleen]

Dann gib deinem normalen Aggregator und dem Konvex-Aggregator eine gemeinsame Interface-Klasse, wenn du Templates vermeiden willst (was ich durchaus verstehen kann). Also in etwa so:

class A_Interface {
}

class A : public A_Interface{
  std::vector<Obj> m_objs;
}

class AChild : public A_Interface {
  std::vector<ObjChild> m_objs;
}

[alpha civ]

Templates muss man ggf. aber immer durch den Code schleppen

Setting ist: Ich habe geometrische Objekte (Shapes), von denen manche konvex sind. Die können alles, was die normalen auch können (Flächeninhalt berechnen, Prüfen ob ein Punkt drin liegt) und noch mehr (z.B. den Mittelpunkt berechnen, der garantiert im Shape liegt).
Nun kommt ein Aggregator dazu, der neben Shapes noch mehr verwaltet (z.B. Punkte, die in diesen Shapes liegen können). Und es gibt auch einen, der nur konvexe Shapes zulassen soll (und dann dadurch auch ein paar Sachen anders/ effizienter machen kann, als der normale Aggregator). Kontextabhängig wird auf den aber auch als "normaler" Aggregator geschaut.

Und du brauchst polymorphes Verhalten?

[Mongke Khan]

Ich will es

[Flunky]

Bisher würde es auch ein Feld bIsConvex tun

[alpha civ]

Dann lieber Polymorphie.

[Frozen]

ArrayOfStructs memory layout
StructofArray ist meistens deutlich performanter

[Mongke Khan]

Auf Performanz kommt es mir in dem Code gar nicht wirklich an.

[alpha civ]

Auf Performanz kommt es mir in dem Code gar nicht wirklich an.

Das traurige ist, dass das auch für "professionelle" Programmierer gilt, die für ihren Schrott auch noch Geld bekommen. Der Import einer Exceldatei mit ca 3k Zeilen kann dann schon mal so 10 Minuten dauern. Nicht wegen dem Parsen der Exceldatei - sondern wegen den zahlreichen Datenbankoperationen. Einfach der größte Rotz.

Tests waren denen auch ein Fremdwort.

[[VK]]

https://jimbly.github.io/regex-cross..._name=original

[Snup]

Achtung Spoiler:

Okay, musste erstmal wieder Regex lernen und wach werden, also hab ichs erst im zweiten Anlauf hingekriegt. Danach hab ich mir die anderen drei angeguckt und festgestellt, dass das genug Regex für die nächsten paar Jahre war.