Code: Alles auswählen
class Item {
public:
QString name;
QString rule;
QString result;
};
class Items : public QList<Item> {
public:
Item& operator[](const QString& name) {
for (int i=0; i<count(); ++i)
if (name == (*this)[i].name)
return (*this)[i];
throw "Not found" ;
};
};
Das ist nur ein verkürztes Snippet. Die Ableitung ist eine Liste, hat aber einige Funktionen mehr als gezeigt. Da ich aus der Pascal-Ecke komme lege ich immer Wert auf klare Schreibweisen und da ist der subscribe-operator nett. Leider artet C++ immer eine Orgie aus Sternchen, spitze Klammern und ähnliche hässlichkeiten aus -> und . -Bezügen. Iteratoren machen die Sache noch hässlicher. Wozu soll die Liste sich wie ein Array verhalten, wenn man sie nicht so benutzen soll?franzf hat geschrieben:QList kennt auch ein at(int).
Und nur für einen neuen operator[] ist das Ableiten unnötig.
Du suchst qFind, oder wenn es etwas spezieller sein soll std::find_if mit nem speziellen Predicate.
Das kapier ich nicht. Wieso erbt meine Klasse nicht einfach? Meinst du ich sollte meine Klasse in einen anderen namespace verlagern?franzf hat geschrieben:Desweiteren gibt es in deinem QList-Derivat keinen operator[](int) mehr! Den bekommst du erst wieder mit ner passenden "using"-Direktive.
Der neueste Schrei?!? Das liegt einfach in der Materie der Sache. i++ erzeugt eine Kopie, erhöht den Wert und gibt den alten Wert zurück. ++i erhöht direkt und returned. Eine Kopie weniger, das ist einfach effizienter. Und wenn du die Kopie eh nur verwirfst ist das total unnötig und hat nichts mit Mode oder so zu tun.Der neueste Schrei scheint ++i statt i++ zu sein. Soll manchmal noch effektiver sein.
Weil die neue Methode gleichen Namens in deiner abgeleiteten Klasse die genauso benannten Methoden der Basisklasse überdeckt. Mit using kannst du die Namen aber in den Namensraum deiner Klasse holen.Das kapier ich nicht. Wieso erbt meine Klasse nicht einfach? Meinst du ich sollte meine Klasse in einen anderen namespace verlagern?
Code: Alles auswählen
#include <string>
#include <iostream>
using namespace std;
struct Test {
void run( int val ) const { cout << "Test " << val << endl; }
};
struct Der : public Test {
using Test::run; // kommentier das mal aus und freu dich über die bekannte Fehlermeldung
void run( string val ) const { cout << "Der " << val << endl; }
};
int main() {
Der d;
d.run( 10 );
}Sehr schön. Mit using klappts nun auch bei mir:Weil die neue Methode gleichen Namens in deiner abgeleiteten Klasse die genauso benannten Methoden der Basisklasse überdeckt. Mit using kannst du die Namen aber in den Namensraum deiner Klasse holen.
Und die Klasse in einen anderen namespace zu packen macht gar keinen Sinn - Problem bleibt.
Wie das jetzt aber mit der template-Basisklasse genau geht kann ich dir nicht sagen, in templates bin ich nie so richtig tief eingestiegen.
So würde das mit normalen Klassen gehen:Code: Alles auswählen
#include <string> #include <iostream> using namespace std; struct Test { void run( int val ) const { cout << "Test " << val << endl; } }; struct Der : public Test { using Test::run; // kommentier das mal aus und freu dich über die bekannte Fehlermeldung void run( string val ) const { cout << "Der " << val << endl; } }; int main() { Der d; d.run( 10 ); }
Code: Alles auswählen
...
class VarItems : public QList<VarItem> {
public:
VarItem& operator[](const QString& name);
using QList<VarItem>::operator[];
...
};
Es soll eine Liste von Name/Rule/Value-Tripels verwaltet werden, deren Bildungsregeln sich gegenseitig referenzieren können. Ein Solver löst diese Abhängigkeiten auf. Die Liste soll als eine Art Model im Sinne von Model/View vorliegen. Der wiederverwendbar benachrichtigende Mittler soll Änderungen in der Liste mitteilen (heißt das Delegate in Qt?). Der Anwender kann eigene Tripels definieren. Es handelt sich um einen Webgallery-Generator dessen Prozessor von der GUI unabhängig sein soll, damit er z.B. auch als nicht-graphische Anwendung laufen kann.Christian81 hat geschrieben:Ich sehe trotzdem noch keinen Sinn von QList<> abzuleiten - was willst Du damit erreichen?
Da ist dein Ansatz aber völlig Pustekuchenmotomoto hat geschrieben:Die Liste soll als eine Art Model im Sinne von Model/View vorliegen. Der wiederverwendbar benachrichtigende Mittler soll Änderungen in der Liste mitteilen (heißt das Delegate in Qt?).
Und ein Klingonenprogrammierer verwendet auch nur das was er sich selber ausgedacht hat und hört nicht auf Ratschläge Anderer?Klar, ich könnte die Liste auch als Member verwalten. Die GUI kennt die Klasse eh und benötigt keine Polymorphie. Aber damit wäre ich meiner eigenen Frage aus dem Weg gegangen und das ist Feigheit, die ein echter Klingonenprogrammierer nicht kennt.
Für was genau verwendest du ImageMagick?So lerne ich Qt und vielleicht kann ich ImageMagick noch besser einbinden als mit Delphi.
Ok. Was die Liste angeht hast du mich überzeugt. Da ich schon öfter Listen in einem Model verwaltet habe (auch Listen von Listen) und die benachrichtigende Anbindung des Models an die GUI immer sehr mühselig ist, grübel ich über eine elegantere Möglichkeit nach.franzf hat geschrieben:Da ist dein Ansatz aber völlig Pustekuchenmotomoto hat geschrieben:Die Liste soll als eine Art Model im Sinne von Model/View vorliegen. Der wiederverwendbar benachrichtigende Mittler soll Änderungen in der Liste mitteilen (heißt das Delegate in Qt?).
Du suchst http://doc.trolltech.com/4.6/model-view ... mming.html
Speziell was die einzelnen Begriffe angeht solltest du dir das nochmal durchlesen. Ein "Delegate" bei Qt4 ist für das Rendern von Items + User-Input zuständig.
Wenn du eh vorhast, das in einer View zu präsentieren solltest du auch daran denken, gleich ein vernünftiges Model zu schreiben.
Haaalo, das mit dem Klingonenprogrammierer war ein Spaß mit dem ich auszudrücken versuchte, dass man auch mal Mut zum probieren haben sollte. Klar dass sich alles verbessern lässt. Darum poste ich hier ja auch und freue mich über deine Antworten. Über die QList habe ja eben auch einiges gelernt.Und ein Klingonenprogrammierer verwendet auch nur das was er sich selber ausgedacht hat und hört nicht auf Ratschläge Anderer?
Im Ernst: Nur weil du jetzt weißt, wie du den Compileerror aus dem Weg räumst, heißt das noch nicht dass der Ansatz gut ist. Ich hoffe inständig, dass du nicht wirklich vor hast deine Klasse polymorph zu verwenden. HINT: QList hat keinen virtuellen Destruktor!
Stimmt, die Keys sind hier allerdings unique.Ein weiterer Nachteil deiner Herangehensweise ist, dass du mit deinem neuen operator[](QString) nur immer EINEN passenden Wert rausholst, und dabei nichtmal den zuletzt eingefügten (wie das z.B. bei QMap der Fall wäre). Deshalb sind Iteratoren eine feine Sache.
Alternativ könntest du eine Funktion "findAll" schreiben, die gleich eine QList<Item> zurück gibt. Der User kann sich dann aussuchen welche Items er verwenden will.
Es handelt sich bei meinem Programm um einen Generator für Webgallerien. Dateien unterschiedlicher Formate sollen geladen und verändert und wieder gespeichert werden. Das kann ImageMagick ganz gut (viele Formate, gute Qualität). Derzeit muss das Programm resizen, drehen, ausschneiden und etwas Dekoration zufügen (3D-Bilderrahmen für die Thumbnails). Das kann ImageMagick in hervorragender Qualität. Die Ergebnisse sehen besser aus als die Anzeige vieler Viewer (insbesondere selbstgeschriebener). Dazu gehört die automatisierte Manipulation von HTML, CSS und anderer Textdateien.Für was genau verwendest du ImageMagick?
Ich wuerd es sogar noch deutlicher artikulieren:Ich sehe trotzdem noch keinen Sinn von QList<> abzuleiten - was willst Du damit erreichen?
Das war mir nicht so klar. Ich will natürlich nichts Gefährliches tun. Womöglich zerhackt es mir den Rechner. Aber im Ernst, eigentlich bin ich noch in der Design-Findungsphase und ich habs mit Ableitung versucht (und wieder verworfen) aber die ursprüngliche Frage, warum der operator[](int) nicht vererbt wird, wenn ich einen anderen definiere wollte ich trotzdem geklärt haben.RHBaum hat geschrieben:Ich wuerd es sogar noch deutlicher artikulieren:Ich sehe trotzdem noch keinen Sinn von QList<> abzuleiten - was willst Du damit erreichen?
Ich find es gefeaehrlich von QList<> abzuleiten. gefaehrlich == ganz mies im C++ jargon, steht fast auf selber stufe wie "undefiniertes verhalten" ^^
Oh Mann, das Wort wollte ich jetzt gar nicht hören. Ich glaube ich poste lieber keine Fragen mehr.@motomoto
Du machst nen ziemlichen Anfaengerfehler. (weil grad Anfaenger machen genau das besonders gern)
Is klar. Ich würde sogar noch weiter gehen und Vererbung als einen Trick definieren, Code zu sparen. Für die Polymorphie sind z.B. abstrakte Basisklassen besser. Aus Java habe ich die Interfaces schätzen gelernt, aber da ist bei C++ (wie fast immer) nur mit Trickserei was zu machen. So würde ich meinem Solver einfach ein Interface verpassen "verhält sich wie eine Liste" und die QList intern verwenden. Klar, das kann mit abstrakten Basisklassen und Mehrfachvererbung machen (oder auch Aggregation eines entsprechenden Objektes, das das Interface implementiert). Aber wie gesagt, ich bin da noch in der Findungsphase. Nachsicht ist hier gefragt.Das was dein Ansatz kaputthaut, iss Vererbung. Es gibt mehrere möglichkeiten vorhandenen Code (wieder)zuverwenden.
Vererbung iss designtechnisch der schlechteste Ausdruck für die Technik. Besser sollt es Polymorphie heissen, weil es dem wesen einfach naeher kommt.
Das ist aber eigentlich nicht böse gemeint, jenes Wortmotomoto hat geschrieben:Oh Mann, das Wort wollte ich jetzt gar nicht hören. Ich glaube ich poste lieber keine Fragen mehr.@motomoto
Du machst nen ziemlichen Anfaengerfehler. (weil grad Anfaenger machen genau das besonders gern)
Hey, so war das ned gemeint, sorry ... eher positivOh Mann, das Wort wollte ich jetzt gar nicht hören. Ich glaube ich poste lieber keine Fragen mehr.
Und um obiges Problem mal richtig am eigenen Leib gespuert zu haben, muss man sich halt doch mal voll in einer aufgeblassenen Objecthirarchie voll verzettelt haben. Genau das mein ich. In der Praxis sieht es halt gegenteilig aus. Verwendest du Polymorphie, hasst meisst scho mit Dir gerungen und Aufwand in kauf genommen um eine "Saubere" Schnittstelle zu definieren.Ich würde sogar noch weiter gehen und Vererbung als einen Trick definieren, Code zu sparen.
ja und auch nur dann sollte man Ploymorphie verwenden. Schnittstellen und Polymorphie sollte man wirklich nur im Zusammenhang haben.Für die Polymorphie sind z.B. abstrakte Basisklassen besser
Haben wir doch eigentlich .... Wenn alle perfekt c++ koennten, gaeb es dieses Forum sicher nichtNachsicht ist hier gefragt.
Ich denk mal, grad umsattler aus anderen Sprachen haben es Designtechnisch besonders schwer.Aus Java habe ich die Interfaces schätzen gelernt,
m Sinne von: Es geht schon, aber "schoen" iss es nicht)Ich denke ein gewaltiger Unterschied hier zwischen java und C++ ist multiple inheritance. Das gibt es in Java nicht. Deshalb braucht man da Interfaces - und da ist nicht mal ne default implementation möglich. Ein interface in C++ ist eine Klasse mit nur "pure virtual"-Methoden - wobei auch pure-virtual-Methoden eine Implementierung haben können!RHBaum hat geschrieben:ja und auch nur dann sollte man Ploymorphie verwenden. Schnittstellen und Polymorphie sollte man wirklich nur im Zusammenhang haben.
Und abstrakt ist sollt man nicht ganz so zwingend sehen. Abstrakt ist eigentlich die natürlichere Form. Es gibt aber noch so themen wie Dafeaultimplementationen .... die eine Abweichung von der 100%igen Abstrakten Basisklasse sinnvoll werden lassen.
)