template <class DERIVED, class BASE>
class MyBaseTemplate : public BASE
{
protected:
    explicit MyBaseTemplate(Blah* b)
        : BASE(b)
    {
    }

    typedef MyBaseTemplate MyBaseTypedef;

    // ein paar Hilfsfunktionen die von DERIVED abhängen
};

// Verwendung:

class FooControl : public MyBaseTemplate<FooControl, Control>
{
public:
    using MyBaseTypedef::SomeFunction();

    virtual void SomeOverride()
    {
        MyBaseTypedef::SomeOverride();
        Whatever();
    }
};

Der Typedef ist eigentlich nur da, damit man Namen der Basisklasse einfacher ansprechen kann.

Und nun suche ich gute Namen für "MyBaseTemplate" und "MyBaseTypedef".
Ich würde sie gern beide "ControlBase" nennen, aber das geht ja leider nicht (Member-typedef darf nicht gleich wie die Klasse heissen).

Vorschläge?

314159265358979 schrieb:

Dein typedef ist sinnlos.

Nein, ist es nicht.
Nur weil du den Sinn nicht verstanden hast, muss es nicht sinnlos sein.

Außerdem solltest du DERIVED und BASE nicht in Großbuchstaben schreiben - Solche Namen werden gerne für defines und Konstanten genommen, DERIVED und BASE heißt schnell mal ein Define.

Aha. Was hältst du, mit deinen zig Jahren Erfahrung in der Praxis, für eine sinnvolle Namenskonvention für Template-Parameter?

@314159265358979:
Du gehst mir manchmal tierisch auf den Sack.

Danke gleichfalls!

hustbaer schrieb:

Nein, ist es nicht.
Nur weil du den Sinn nicht verstanden hast, muss es nicht sinnlos sein.

Wenn ich in Dervied auf die Basisklasse zugreifen will, dann nehm ich dafür ein:

typedef BaseClass<T1, T2, T3, ...> base;

Sowas gehört dort hin, wo ich die Klasse verwenden will, und nicht in die Klasse.

hustbaer schrieb:

Aha. Was hältst du, mit deinen zig Jahren Erfahrung in der Praxis, für eine sinnvolle Namenskonvention für Template-Parameter?

CamelCase ist eine Möglichkeit. Du willst mir doch nicht ernstaft erzählen, dass du deine Template-Prameter in GROSSBUCHSTABEN schreibst.

Sowas gehört dort hin, wo ich die Klasse verwenden will, und nicht in die Klasse.

Du verkündest auch mir ein wenig zu oft, was in C++ alles verboten sei, was kein C++ sei und so, hast dabei aber auch oft unrecht, kennst noch zu wenige Standardtechniken, überschätzt die Gefahren.

hustbaer schrieb:

Nein, ist es nicht.
Nur weil du den Sinn nicht verstanden hast, muss es nicht sinnlos sein.

Wenn ich in Dervied auf die Basisklasse zugreifen will, dann nehm ich dafür ein:

typedef BaseClass<T1, T2, T3, ...> base;

Sowas gehört dort hin, wo ich die Klasse verwenden will, und nicht in die Klasse.

Ich brauche das in 2/3 aller abgeleiteten Klassen. Das BaseClass<> Template ist *immer* die 1. Basisklasse, und ich will auch immer auf die Namen dieser 1. Basisklasse zugreifen.

Das Typedef in zig abgeleiteten Klasse zu wiederholen, macht wohl kaum Sinn. Das ganze Ding ist sowieso eine reine Commodity-Klasse, wieso sollte ich dann das Typedef nicht mit dort hinein packen?
Kannst du mir einen einzigen guten Grund nennen? Ausser "es gehört dort nicht hin" (was nämlich sofort die Frage aufwirft: wieso gehört es denn dort nicht hin).

314314langstrumpf schrieb:

hustbaer schrieb:

Aha. Was hältst du, mit deinen zig Jahren Erfahrung in der Praxis, für eine sinnvolle Namenskonvention für Template-Parameter?

CamelCase ist eine Möglichkeit. Du willst mir doch nicht ernstaft erzählen, dass du deine Template-Prameter in GROSSBUCHSTABEN schreibst.

Ich will dir gar nix erzählen. DU meinst hier Dinge kommentieren zu müssen die überhaupt nicht zum Thema gehören.

Ich verwende CamelCase für Typennamen. Die gleiche Namenskonvention für Typennamen und Template-Parameter zu verwenden, hat sich in der Praxis als unvorteilhaft erwiesen.
Also. Nächster Vorschlag.

MyBaseTemplate = BehaviorInjectionConcept?
MyBaseTypedef = InjectedBehavior?

Hm, ich sehe schon, da ist wohl ein wenig mehr Kontext gefragt.

Es geht um GUI Controls (Widgets), und die Template-Klasse tut nicht wirklich Verhalten "injizieren". Der Hauptgrund, warum es die Klasse überhaupt gibt, ist, weil ich zwei Dinge haben wollte:

1. Erwähntes Typedef, damit ich in allen Controls über einen einheitlichen Namen auf ihre jeweilige Basisklasse zugreifen kann
2. Sie überschreibt die "shared_from_this" Funktionen mit welchen, die den Typ der abgeleiteten Klasse zurückgeben.

Ich hätte eher an sowas gedacht:
MyBaseTemplate = ControlBaseImpl
MyBaseTypedef = ControlBase

Bloss das ControlBaseImpl finde ich irgendwie ... doof

Ich brauche das in 2/3 aller abgeleiteten Klassen. Das BaseClass<> Template ist *immer* die 1. Basisklasse, und ich will auch immer auf die Namen dieser 1. Basisklasse zugreifen.

Das Typedef in zig abgeleiteten Klasse zu wiederholen, macht wohl kaum Sinn. Das ganze Ding ist sowieso eine reine Commodity-Klasse, wieso sollte ich dann das Typedef nicht mit dort hinein packen?
Kannst du mir einen einzigen guten Grund nennen? Ausser "es gehört dort nicht hin" (was nämlich sofort die Frage aufwirft: wieso gehört es denn dort nicht hin).

Dann sag mir doch mal, was am besten ist:

using base<int, double, std::string>::base_class; // (1)
typedef base<int, double, std::string>::base_class base_class; // (2)
typedef base<int, double, std::string> base_class; // (3)

Begründe, warum. (Begründung, (1) ist 1 Zeichen kürzer, zieht nicht.)

hustbaer schrieb:

314314langstrumpf

Süß

hustbaer schrieb:

Ich will dir gar nix erzählen. DU meinst hier Dinge kommentieren zu müssen die überhaupt nicht zum Thema gehören.

Ich habe den Vorschlag gebracht, eine andere Konvention zu verwenden. Eine bestimmte hab ich nicht genannt.

hustbaer schrieb:

Ich verwende CamelCase für Typennamen. Die gleiche Namenskonvention für Typennamen und Template-Parameter zu verwenden, hat sich in der Praxis als unvorteilhaft erwiesen.

Und ich schreibe klassen_namen und TemplateParameter. Cool, was? :p

hustbaer schrieb:

Also. Nächster Vorschlag.

Dann halt KlassenName und template_parameter. Immer noch besser, als TEMPLATE_PARAMETER.
(Mal abgesehen davon, dass Grossbuchstaben Augenkrebs verursachen.)

MyBaseTemplate = UtilityImpl
MyBaseTypedef = BaseUtility

Boah der Mann fragte nach Hilfestellung um Benennungen zu finden, nicht von ein Mädchen angezickt zu werden.

@314159265358979

Boah der Mann fragte nach Hilfestellung um Benennungen zu finden, nicht von ein Mädchen angezickt zu werden.

Das Anzicken hat erst mit hustbaers Post begonnen. Im Gegensatz zu seinem, war meiner nämlich konstruktiv gemeint und vor allem höflich

Das Anzicken hat erst mit hustbaers Post begonnen. Im Gegensatz zu seinem, war meiner nämlich konstruktiv gemeint und vor allem höflich

Es war auf jeden Fall nicht höflich.
Etwas als "sinnlos" zu bezeichnen, was man (offensichtlich) nicht verstanden hat, ist nicht höflich. Höflich wäre gewesen nachzufragen.
Da du das, in deiner immerwährenden Selbstüberschätzung (aus der die Sicherheit erwächst etwas verstanden zu haben, wenn du es eben nicht verstanden hast), sehr häufig machst, reagiere ich darauf etwas genervt.

Punkt 2 stimmt weiterhin.

Punkt 2 ist weiterhin eine Frage der Konvention, ein absolutes Statemend dazu ist dementsprechend weiterhin Blödsinn.

Einheitlicher Name, einheitliche Basis für shared_from_this?
Etwas einfallslos: uniform_shared_base und uniform_name?

Naja...
Der Name des Typedefs sollte schon "die Basisklasse dieses Controls" zum Ausdruck bringen.
Ich glaube ich werde bei "ControlBase" bleiben (evtl. wäre auch "BaseControl" OK).
Fehlt nur noch der Name für die Klasse selbst.
"StandardControlBase" wäre vielleicht was. Hm.

Es war auf jeden Fall nicht höflich.Etwas als "sinnlos" zu bezeichnen, was man (offensichtlich) nicht verstanden hat, ist nicht höflich. Höflich wäre gewesen nachzufragen.

Nicht nicht verstanden - vergessen. Das ist ein wesentlicher Unterschied.

hustbaer schrieb:

Da du das, in deiner immerwährenden Selbstüberschätzung (aus der die Sicherheit erwächst etwas verstanden zu haben, wenn du es eben nicht verstanden hast), sehr häufig machst, reagiere ich darauf etwas genervt.

Im Nachhinein betrachtet hätte ich wohl auch nicht anders reagiert - ich vergebe dir.

hustbaer schrieb:

Punkt 2 ist weiterhin eine Frage der Konvention, ein absolutes Statemend dazu ist dementsprechend weiterhin Blödsinn.

Und diese Konvention hat sich weitestgehend durchgesetzt.

Man könnte das natürlich auch alles anders lösen, ganz ohne die "Zwischen-Basisklasse", nur gefallen mir alle anderen Lösungen (die mir eingefallen sind) noch weniger.

Speziell was das Thema shared_from_this() angeht.

Immer Casten wo der abgeleitete Type gebraucht wird finde ich nicht gut.
Es in jeder abgeleiteten Klasse zu wiederholen finde ich auch nicht gut.
Bliebe noch die Möglichkeit ein Makro zu verwenden, aber ... naja. Den "Aufruf" des Makros müsste man auch in jeder Klasse wiederholen, und ... hmpf. Gefällt mir also auch nicht so richtig.

Das einzige was mich bei der "Zwischen-Basisklasse" stört, ist, dass diverse Tools wie Doxygen sich damit nicht so richtig anfreunden können. Eigentlich sollte die "Zwischen-Basisklasse" in Doxygen Charts gar nicht auftauchen, sondern direkt der "BASE" Typ als Basisklasse. Dazu konnte ich Doxygen aber blöderweise nicht überreden.

Default, Default, Default, ...

Default klingt für mich, im Zusammenhang mit C++, immer nach etwas, was man bekommt wenn man irgendwas nicht angibt.
Default-Ctor (keine Parameter angegeben), Default-Argument (kein Argument angegeben), Default-Implementierung (keine Implementierung angegeben, mit SpecialFunction() = default).
Das passt in dem Fall IMO nicht gut.

Standard passt IMO besser. Standard heisst für mich ... naja, dass es eben "Standard" ist, aber man es auch anders machen kann (wenn es gute Gründe dafür gibt).

Zeus schrieb:

Default, Default, Default, ...

...

Das war ein Joke von einen Java-Programmierer

hustbaer schrieb:

Zeus schrieb:

Default, Default, Default, ...

...

Das war ein Joke von einen Java-Programmierer

Den verstehe ich nicht

BTW: da das Thema nun schon aufgegriffen wurde: findet ihr die Verwendung einer solchen Basisklasse + typedef darin auch schlecht/fragwürdig?

Es ist immerhin eine weitere Abtraktion, die ich erst lernen muß. Ich hasse Abstraktionen, die sich nicht aus den Begriffen der Programmlogik ergeben.
Wenn ich recht sehe, willst Du nur...

class HappyFooControl : public FooControl
{
public:
    typedef FooControl Base;//...nur diese kleine Zeile automagisieren

    using Base::SomeFunction();

    virtual void SomeOverride()
    {
        Base::SomeOverride();
        Whatever();
    }
};

public interface AbilityOne { void one(); }
public interface AbilityTwo { void two(); }

public class DefaultOne implements AbilityOne {
    @Override
    public void one() {
        System.out.println("rly i am meaningful");
    }
}

public class DefaultTwo implements AbilityTwo {
    @Override
    public void two() {
        System.out.println("sure i am meaningful");        
    }
}

public abstract class AbstractMeaningful implements AbilityOne, AbilityTwo {

}

public class DefaultMeaningful extends AbstractMeaningful {

    private AbilityOne one = new DefaultOne();
    private AbilityTwo two = new DefaultTwo();

    @Override
    public void one() {
        one.one();
    }

    @Override
    public void two() {
        two.two();
    }

}

Bfindet ihr die Verwendung einer solchen Basisklasse + typedef darin auch schlecht/fragwürdig?

Man könnte das natürlich auch alles anders lösen, ganz ohne die "Zwischen-Basisklasse", nur gefallen mir alle anderen Lösungen (die mir eingefallen sind) noch weniger.

Ich find's ok. Nicht optimal, aber man schreibt idR selten eigene Controls, da ist kurze Einarbeitungszeit in Ordnung. Anwesenheit des typedefs ist ok wenn man ohne Nachschlagen/Intellisense sieht, dass eben jenes Parent damit gemeint ist.

Rein aus Interesse: Woran liegt es denn, dass man nicht einfach nur von direkt Control ableiten kann? Oder spezifische Hilfsfunktionen?

hustbaer schrieb:

Speziell was das Thema shared_from_this() angeht.

Das "spezialisieren" von shared_from_this finde ich eine coole Idee, hab ich so noch nicht gesehen.