Allegro OO ?
-
ps. wenn's dir wichtig ist suche ich nach dem zitat in den büchern hier
gerne. mach das bitte
-
effective c++ second edition
seite 55 ziemlich mittig.rapso->greets();
-
unter welcher lektion steht das? ich hab nur die deutsche version und da ist die seitenverteilung glaub ich ein bisschen anders.
-
12 oder 13 ist das soweit ich weiß, da ist eine recht lange construktorlist in der nähe als quelltext beispiel.
auf deutsch müßte da in etwa stehen, dass initialisierungs funktionen genauso gut wie constructor sind und in einigen fällen besser... wenn ich's richtig im kopf habe.
vielleicht ist auch mein english zu schlecht
rapso->greets();
-
es geht darum eine große anzahl von buildins zu initialiesieren und damit man nicht bei jeden ctor das wiederhollen muss, kann mann eine private funktion machen
da es bei buildins kein unterschied macht ob man sie in der initialiesierungsliste oder im ctor body durch zuweisung initialiesiert
-
hmm... steht da wirklich nirgendwo dass man init gegenüber constructor bevorzugen sollte? ich hätte schwör'n können *amkopfreib*
hmm.. ich kann mich aber auch immer net entscheiden ob ich konstruktorlisten oder init benutzen will...
rapso->greets();
-
Noch nichtmal lesen kann der rapso.
-
ja das mit den Init funktionen mach ich jetzt so:
Screen screen1(640,480); //Hier wird noch gar nichts initialisiert Screen screen2(800,600); //auch da nicht screen1.set_colordepth(32); //blub nix passiert allegro().install(screen1); //Erst hier, Allegro ruft screen1.install auf, eine //private methode von Device, von der Screen abgeleitet ist, die die virutelle //protected Methode do_install aufruft :) - hört sich komplizierter an, als es //ist
Ich finde das ist ein guter Kompromiss
-
ich würde das set_ weglassen
FlaMor ist da nicht ein F zuviel *reflame*
rapso->greets();
-
eigentlich ne gute idee
ok
-
aber ich hab auch noch mal dieselben get methoden, was soll ich tun?
-
ups, hab vergessen, dass es ja sowas wie "function overloading" auch noch gibt
-
ich finde das ziemlich angenehm sowas zu machen wie (nicht das schreiben davon sondern das anwenden, c++ ist geil
)
protected: CShip* m_pShip; public void Ship(CShip* pShip); CShip* Ship();
schade dass das nicht automatisiert ist, oder kennt jemand ein tool? (am besten als integration ins visual studio
(das für eine membervariable automatisch ne accessor function macht
rapso->greets();
-
Du vergisst auch nicht, dass sich Allegro in ständiger Entwicklung befindet?
Etliche Dinge werden von Zeit zu Zeit grundlegend geändert, hoffentlich kommst Du dann hinterher. Ich meine, ein Allegro-OO-Wrapper für Version 4.0.2 sieht ziemlich müde aus, wenn Allegro 4.7.53 aktuell ist.
Will sagen: an dem Punkt wo Du jetzt bist, war ich schon vor vier Jahren. Da ich aber keine Zeit hatte ständig nachzuziehen, habe ich es irgendwann mal in die Ecke gelegt. Das Design ist seinerzeit grundlegend geändert worden, als Allegro auf Multiplatform ging, und es wird sicherlich noch einmal geändert, wenn die Hardwarebeschleunigerdinge hineinkommen.
Es gibt beispielsweise auch ein AllegroGL, aber George kommt da auch nicht hinterher...
Und, hmmm, einen Tester für die BEOS-Version der OO-Version hast Du dann auch?
Auf der Sun läuft Allegro mittlerweile ebenfalls... kennst Du die Eigenheiten der entsprechenden Compiler? So wie C != C ist, ist auch C++ != C++.
Und nur mit Standarddingen kommst Du wahrscheinlich nicht hin.Nichts gegen die gute Absicht, aber wenn Du beim function overloading schon nachdenken musst, dann lasse besser die Finger davon.
Mir reicht's schon, dass derjenige, der derzeit die RHIDE 'fortsetzt' auch mehr guten Willen als Fähigkeiten besitzt. Die neueren Versionen schmieren nur noch ab.[ Dieser Beitrag wurde am 03.04.2003 um 15:26 Uhr von Bitsy editiert. ]
-
ich glaube er hat das eher für sich gecodet und bietet es freundlicherweise anderen an damit sie sich nicht die selbe arbeit machen müssen... und wer vergisst mal etwas net? immerhin ist es ihm von selbst eingefallen.. ich vergess auch manchma dinge die ich jahre lang nicht gemacht habe (letztens dass es anstatt constructor listen auch inplacement news gibt...)
vom konzept her finde ich den wrapper ziemlich ok!
rapso->greets();
-
Ich will ihn auch nicht stoppen. Aber bevor man sich nach Webspace erkundigt, sollte die Arbeit fertig sein, und ich behaupte mal - das ist sie nicht.
Wäre sie ausserdem wirklich ordentlich gemacht, würde sie bereits in allegro.cc im Angebot stehen. Das habe ich gestern noch gecheckt, ist sie nicht.
Ich habe die Allegro-mailing-Liste immer noch abonniert, und ich weiß nicht, wer als Allegro-Mitglied irgendwelche Gründe haben sollte hier anonym unregistriert zu posten. Allzu seriös kann es also nicht sein.
-
seriös? nö!
ich wollte nur schnell mal die Allegro Lib ausprobieren und mir ist aufgefallen, dass es das noch nicht als OO Style gibt (bzw. nichts richtiges)
sieh das einfach als ein projekt für mich alleine an, das ich gerne mit anderen leuten teilen würde. ich erwarte mir auch nichts davon, nicht den riesensupermegaknaller, jjjust for fun!
-
Original erstellt von <Alleger>:
**ja das mit den Init funktionen mach ich jetzt so:Screen screen1(640,480); //Hier wird noch gar nichts initialisiert Screen screen2(800,600); //auch da nicht screen1.set_colordepth(32); //blub nix passiert allegro().install(screen1); //Erst hier, Allegro ruft screen1.install auf, eine //private methode von Device, von der Screen abgeleitet ist, die die virutelle //protected Methode do_install aufruft :) - hört sich komplizierter an, als es //ist
Ich finde das ist ein guter Kompromiss :)**
Wenn bei blub nix passiert dann mach doch einfach den Konstruktor gleich so "Screen screen1(640,480,32);" und lass set_colordepth() ganz weg.
-
@Alleger:
Ich will nur nicht, dass Du zu keck und zu voreilig bist, wenn es um Allegro geht. Das Ding hat schon eine lange Geschichte und mir persönlich ist es sehr wichtig. Daher knurre ich da lieber einmal mehr als einmal zu wenig. Ansonsten sind junge Allegratoren natürlich immer willkommen, es muss ja weitergehen.
-
lass den alleger machen was er will!!!