muss ein Konstructor immer denselben Namen wie die Klasse haben oder laesst scih das durch irgend einen boesen Trick umgehen?

Gruesse

muss ein Konstructor immer denselben Namen wie die Klasse haben

Ja.

oder laesst scih das durch irgend einen boesen Trick umgehen?

Nein, aber du kannst dir ja ne Factory-Methode schreiben... nur ruft die auch bloß den Ctor auf. Also Augenwischerei.

habs mir fast gedacht... nicht weiter tragisch. Waere halt nur schoen gewesen, den Leere-Liste-Konstruktor fuer eine Liste Nil() zu nennen ...

Hi,

habs mir fast gedacht... nicht weiter tragisch. Waere halt nur schoen gewesen, den Leere-Liste-Konstruktor fuer eine Liste Nil() zu nennen ...

Dann schreib Dir doch eine freie Funktion mit dem Namen (wenn es unbedingt sein muß - ich halte es für eher unnötig):

MyListe Nil() { return MyListe() }

... 
{
    MyListe a = Nil();
    ...

oder als staticMethode in MyListe:

class MyListe {
...
public:
    static MyListe Nil() { return MyListe() }
...
};

... 
{
    MyListe a = MyListe::Nil();
    ...

Ist aber IMO total überflüssig: Dass der StandardCtor aufgerufen wird, kann man durch nichts eindeutiger dokumentieren als durch:

MyListe a;

Gruß,

Simon2.

const struct NilType
{
} Nil;

class Liste
{
public:
    Liste(const NilType&)
    {
    }
};

Liste blubb = Nil;

Aber wie Simon schon schrieb

Ist aber IMO total überflüssig

Singleton s = Singleton.createInstanz();

Für Enums oder Wrapper-Klassen:

Double d = Double.valueOf("1.34987");
Farbe e = Farbe.valueOf("ROT");

usw.

Es macht aber in manchen Fällen schon Sinn einen Namen für ein Konstruktor zu vergeben. Das meist gebrauchteste:

Singleton s = Singleton.createInstanz();

Für Enums oder Wrapper-Klassen:

Double d = Double.valueOf("1.34987");
Farbe e = Farbe.valueOf("ROT");

usw.

Also Ersteres ist bewußt kein Konstruktor (ihm fehlt z.B. die Eigenschaft, daß er automatisch aufgerufen wird bei Stackobjekten), sondern eine Factorymethode und für Letzteres sehe ich gar keinen Bedarf.
Was ist an

Double d1("1.34987");
Double d2 = Double("1.34987");
Farbe e("ROT");
Farbe e = Farbe("ROT");

(mit geeigneten explicit Konstruktoren)
falsch oder unverständlich oder unsicher ?

Alternativ kann man natürlich mit templates

Double d = valueOf<Double>("1.34987");
Farbe e = valueOf<Farbe>("ROT");

oder wie in Deeinem Beispiel statics FactoryMethoden bauen - aber wie gesagt: Sind eigentlich keine Konstruktoren.

Gruß,

Simon2.

Double d = Double.valueOf("0.23");

macht tatsächlich keinen sinn. methoden dieser art sind für sowas gedacht (und zudem eigentlich static, da keine eigenschaft eines objekts):

double d = Double::valueOf("0.23"); // bedeutungs-"korrekter" wäre parseDouble()

(man beachte das kleine double).

hier wird einem datentyp double ein wert zugewiesen, den eine statische methode, zugehörig zum objekt Double, liefert.

wichtig ist dabei die unterscheidung zwischen einem primitiven datentyp und einem objekt. gibt programmiersprachen, die gar keine primitive zur verfügung stellen.

hier wird einem datentyp double ein wert zugewiesen, den eine statische methode, zugehörig zum objekt Double, liefert.

wichtig ist dabei die unterscheidung zwischen einem primitiven datentyp und einem objekt. gibt programmiersprachen, die gar keine primitive zur verfügung stellen.

Eine statische Methode funktioniert ohne Objekt. Eine statische Methode gehört zu einer Klasse, ohne dass es möglich sein müsste, Objekte dieser Klasse erstellen zu können.

klasse beschreibt die formale spezifikation eines typs. als objekt bezeichne ich die verwendung des typs und methoden des typs zur laufzeit. das dabei keine instanz der klasse existieren muss, ist für statische methoden unter c++ selbstverständlich. in sprachen ohne statische konstrukte macht die unterscheidung objekt, instanz, klasse mehr sinn.

Generell gilt: Ein Objekt definiert sich durch einen Zustand (Membervariablen) und seine Methoden.

Klassenfunktionen sind keine Objekte, da sie keinen Zustand besitzen.

Jetzt kann man argumentieren, das kann man in C/C++ aber in Kombination mit statische Variablen dies realisieren kann...

Das fällt meiner Meinung allerdings eher darunter wie kann man ein Objekt funktional abbilden.

Generell gilt: Ein Objekt definiert sich durch einen Zustand (Membervariablen) und seine Methoden.

Nein, generell gilt folgendes:

<a href= schrieb:

wikipedia">Als Objekt bezeichnet man in der Informatik ein Exemplar eines beliebigen Datentyps.

ISO/IEC ISO/IEC 14882:2003(E), 1.8 The C++ object model schrieb:

An object is a region of storage.

Also Ersteres ist bewußt kein Konstruktor

Ich meine natürlich eine Factory-Methode, das war ja sowas von deutlich aus dem Code herauszulesen. Aber solche Factory-Methode sind eben ein Ersatz für eine Namenvergebung bei Konstruktoren. Ich wollte nur anmerken das es eben manchmal Sinn macht einem Konstruktor einen Namen zu geben um eine zusätzliche Information zu verbreiten.

Ausserdem ist es klar das man sowas explizit aufrufen muss, etwas implizites verbirgt ja zusätzliche Information. Wir wollen aber eine zusätzliche Information.

Man glaubt es kaum, aber Objekte gab es in der Informatik schon bevor es Objektorientierung gab.

natürlich gabs objekte schon, bevor es objektorientierung gab. was meinst du ulknudel, woher der begriff stammt? :p

dein zitat stammt übrigens aus der oo zeit und hält sich dabei strikt an die c/c++ auffassung von objekten: das sind nämlich structs, also datenstrukturen. c++ ist zwar oo, aber das grundkonzept ist immer noch rein c. deshalb ist c++ denkbar schlecht geeignet, um objektorientierung zu diskutieren. dafür ist smalltalk oder von mir aus auch java besser geeignet.

...Ich meine natürlich eine Factory-Methode, das war ja sowas von deutlich aus dem Code herauszulesen. Aber solche Factory-Methode sind eben ein Ersatz für eine Namenvergebung bei Konstruktoren. Ich wollte nur anmerken das es eben manchmal Sinn macht einem Konstruktor einen Namen zu geben um eine zusätzliche Information zu verbreiten....

DEvent schrieb:

Es macht aber in manchen Fällen schon Sinn einen Namen für ein Konstruktor zu vergeben....

Was jetzt: Konstruktor oder Factorymethode ?

Ja: Factorymethoden können sinnvoll sein.(Wobei das Wesentliche an ihnen nicht ihr Name ist, sondern ihre Aufgabe im Design)
Nein: Ich habe noch keinen Fall gesehen, wo ein Konstruktor einen anderen Namen haben sollte als den der Klasse.

Gruß,

Simon2.

Konstruktör schrieb:

Man glaubt es kaum, aber Objekte gab es in der Informatik schon bevor es Objektorientierung gab.

natürlich gabs objekte schon, bevor es objektorientierung gab. was meinst du ulknudel, woher der begriff stammt? :p

Sorry, ich habe die Ironie-Tags nicht gefunden

hoschi23 schrieb:

...strikt an die c/c++ auffassung von objekten: das sind nämlich structs, also datenstrukturen.

NEIN. Es ist ein Exemplar eines beliebigen Datentyps.

hoschi23 schrieb:

c++ ist zwar oo, aber das grundkonzept ist immer noch rein c. deshalb ist c++ denkbar schlecht geeignet, um objektorientierung zu diskutieren.

C++ ist eine Hybridsprache und da wir uns in einem C++ Forum befinden, scheint es mir nicht verkehrt zu sein, sich an diese, allgemeinere, vom Standard festgelegte, Definition von Objekt zu halten.

Was jetzt: Konstruktor oder Factorymethode ?

Ich bezeichne eigentlich beides als Konstruktor, weil beide das selbe machen. Beide Konstruieren ein Objekt und liefern es zurück. Ich kenne zwar den Unterschied aber hier abstrahiere ich einfach.

Was jetzt: Konstruktor oder Factorymethode ?

Ich bezeichne eigentlich beides als Konstruktor, weil beide das selbe machen. Beide Konstruieren ein Objekt und liefern es zurück. Ich kenne zwar den Unterschied aber hier abstrahiere ich einfach.

Ach so !
Na gut; ich halte zwar "Privatdefinitionen" für suboptimal, aber das erklärt unser Mißverständnis. Wir können uns ja auf "Konstruktionsfunktion" einigen ...

Ich denke aber, inhaltlich sind wir uns sowieso einig:
- in C++ müssen (echte) Konstruktoren so heißen wie die Klassen und
- es gibt Situationen, in denen zusätzliche/alternative Konstruktionstechniken sinnvoll (bisweilen auch die beste Lösung) sind.

Gruß,

Simon2.