
Crush
Mitglieder-
Gesamte Inhalte
2048 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Alle Inhalte von Crush
-
in der umschulung prakitukmsstelle wechseln??
Crush antwortete auf Marco1174's Thema in Ausbildung im IT-Bereich
Frag doch mal beim Bildungsträger nach - die haben manchmal ein paar Reserven in der Tasche, auf die man auch kurzfristig mal wechseln kann. Allerdings werden die so knapp vor der Prüfung auch die Stirn runzeln. Wenn eine echt gute Begründung vorliegt, kannst Du auch bei der IHK nachhaken. Die können sogar Dich von dort befreien und Dich trotzdem zur Prüfung zulassen hat mir mal einer gesagt, selbst wenn Du keinen weiteren Praktikumsplatz finden solltest - doch suchen mußt Du im Zweifelsfall immer, weil die sonst ihre Meinung ändern könnten. -
Wie macht der sich denn genau bemerkbar und gibt es schon eine Impfung dagegen?
-
Früher hat man ja gerne von den Word-Viren berichtet, die ja im Zusammenhang mit Spam-Mail in Massen verschickt worden sein sollen und sich selber ans Telefonbuch vom Explorer weitergeschickt hat. Hat überhaupt mal jemand einen Mail-Virus bekommen? Das einzigste was mir mal unter die Finger kam war der CIH und noch irgendein andere Bösewicht - aber das war´s auch schon.
-
Heute haben die auf RTL gezeigt, wie ein Hund in Holland erst sein Herrchen getötet und danach einem Kumpel den Arm aufgerissen hat, daß sogar das Innerste nach außen gekrempelt war und in Fetzen runterhing. Ein Polizist hat sich nicht getraut den Hund abzuschießen, weil eine Kugel abprallen und den Mann verletzten könnte - obwohl dieser ihn darum bat den Hund zu erschießen!!! Irgendwann hat er dann doch erbarmen gezeigt und nach 2 Kugeln hat der Hund immer noch ohne ein Zeichen weitergefetzt. Erst nach der 3. war Feierabend. Ich fand es ja unglaublich toll, wie man diese ziemlich extrem blutigen Aufnahmen in Szene gesetzt hat ohne auch nur mit einem sterbens Wörtchen zu erwähnen, was für einer der Besitzer war oder was den Hund so in Rage gebracht haben könnte. Damit wird mal wieder wunderbar das Bild in den Augen der Öffentlichkeit absichtlich in die gewünschte Richtung gedreht und nach eigenem Wunsch geprägt. Warum zeigen die nicht mal halb so oft, wie Hundebesitzer ihre Tiere unmenschlich behandeln und diese bis zum krepieren verhungern lassen, nachdem man sie irgendwo festkettet? Solche Bilder sind halt leider nicht reißerisch genug. Und die Hundekämpfe werden nur gezeigt um das Aggressionspotential dieser Tiere hervorzuheben. Auch wird viel zu wenig von Lebensrettern unter den Hunden berichtet um auch mal die andere Seite der Medaillie zu zeigen. Schade, daß die Leute immer nur an das denken, was ihnen direkt vor Augen geführt wird und ausgerechnet immer die letzten Bilder im Gedächtnis festsetzen. Dadurch beweist die Öffentlichkeit immer mehr, wie sehr sie durch die Medien manipuliert werden kann.
-
Wo ist denn der große Unterschied zwischen Ziv1 & Ziv2? Ich habe beide hier (bin ein alter Spielesammler). Wenn ich mal von der wenigen Zeit die ich habe was von den alten Sachen anschauen möchte, würde mich schon interessieren, ob und warum sich Zivnet nicht lohnt.
-
Nochmal für alle! Die IHK hat das Tabellenbuch für die ZWP freigegeben!!!
Crush antwortete auf svb79's Thema in IHK-Prüfung allgemein
Hier in BW durften wir das IT-Büchlein zur Prüfung verwenden. Doch es war fast nirgendwo wirklich gut einsetzbar und die Zeit war auch zu knapp um sich da irgendwo durchzuwühlen und rumzulesen. Wer das nicht schon vorher durchgelesen hatte, der hatte auch bei der Prüfung nicht besondere Vorteile davon. Nur bei einem bestimmten Stichwort hat es was gebracht, weil sich nicht alle ganz sicher waren, was für eine Darstellungsweise damit gemeint war. Wunder darf man sich also deshalb wirklich nicht erhoffen. -
Wenn ich hier in Deutschland etwas nicht bekomme, lasse ich mir was vom Ausland zuschicken oder kaufe selber dort ein. Polen gefällt mir zur Zeit am meisten, weil da absolut gar nix zensiert wird - egal wie knallhart es auch sein mag - und auch fast immer in englischer Version serviert wird.
-
Wenn bei Euch eine Diskussion über dieses Thema entbrannt ist, würde mich interessieren, was da für Argumente vorgebracht wurden, woraus das denn sonst noch berechnet werden könnte.
-
PlayStation2, XboX und GameCube
Crush antwortete auf capitanx's Thema in Gaming Club's Allgemeine Themen
Ich werde mir in absehbarer Zeit keine Konsole kaufen, sondern lieber mal wieder einen neuen Computer. Es würde mir momentan noch sehr schwer fallen, mich für ein System zu entscheiden. Zelda64 ist mein absolutes Lieblingsspiel gewesen (mal unabhängig von Systemen betrachtet - und ich fand, daß die Story und der Schwierigkeitsgrad wohl wirklich nix für Kinder war - nur die Musik und Grafik hat die vielleicht angesprochen ... es gab aber auch ein paar durchaus blutige Szenen und Clips) und so wäre GC fast schon eine Nasenlänge weiter, doch nach der Änderung in der Grafik bin ich mir da auch nicht mehr so sicher. Auf der anderen Seite bin ich fast genauso in Outcast (einfach eine wunderschöne Welt, die da erschaffen wurde) verschossen ... und das wird man halt auf der PS2 wohl zuerst erleben können (ich halte die Grafik bis jetzt für die Beste von allen Titeln, sogar besser als Unreal2). Andere Titel reizen mich momentan noch nicht so recht bis auf das Resident Evil-Remake (habe ich aber schon im Orginal durchgezockt) würde ich mich gerade für nix Weiteres besonders interessieren. Jedes System hat ein paar Kracher und wenn man die richtigen Perlen sammeln möchte, muß man sich wohl alles anschaffen. Andererseits habe ich noch so viel wirklich schöne Dinge im Schrank rumliegen, die sollte ich nicht vergammeln lassen. (Monkey Island3, MDK2, Grim Fandango, Dungeon Keeper2, Messiah, the longest journey, Rayman2 und Ultima Ascension (und noch viele weitere) zählen da zu ein paar von meinen Anwärtern als nächste Freizeitbeschäftiger - also auf eine Konsole kann ich derzeit gerne noch verzichten) -
Selber habe ich Eiffel noch nicht kennengelernt, aber ich weiß, daß Eiffel wohl einer der Vorreitersprachen in der Objektorientierung war, genauso wie Smalltalk. Bis jetzt haben Autoren von Smalltalk und Eiffel eher positiv gesprochen - was Negatives gab´s noch nirgends. Die Eiffel-HP scheint mir etwas überzogen diese Programmiersprache zu präsentieren. Allerdings macht die Syntax einen ordentlichen Eindruck auf mich. Es gibt auch einen GNU-Eiffel-Compiler (Smalleiffel), wenn Du´s vielleicht nur mal ausprobieren möchtest: http://smalleiffel.loria.fr/ weiteres: http://www.elj.com/eiffel/ Wie man sehen kann haben wohl die Franzosen sich das ganze einfallen lassen ... offensichtlich haben die außer Croissants, Rotwein und Amour Versessene noch ein paar Abtrünnige unter sich, die auch noch was anderes im Kopf haben! =8-D
-
Es gibt nur ein paar Bücher, aber Online habe ich bisher auch nichts gesehen. Bei den Programmen ist aber wohl mit die genialste Anleitung nicht nur für die Programme dabei, sondern vor allem zum Lernen von C++ & Assembler auf höchstem Niveau mit Details, die ich so noch nirgends gesehen habe. Doch weil die Dokus nur bei der Orginal-CD dabei sind (hab ich noch von früher), bin ich mir ziemlich sicher, daß es nicht legal wäre, die einfach so durch die Gegend zu posten. Die Docs sind übrigens so extrem Umfangreich (RIESIG), daß Du Wochen bräuchtest um da was brauchbares darüber zusammenzufassen - damit könnte man selber schon einen paar Bücher füllen. Ich habe nach dem Lesen das Gefühl gehabt, daß das Studio dagegen wohl nur was für Einsteiger ist =8-) Für ein Referat ist das einfach zu viel. Das ist auch ein Grund, wieso ich vor Borland wirklich höchsten Respekt habe - viele wollen ja diese Firma und ihre Produkte in Grund und Boden zerreißen, aber erst gestern habe ich hier gelesen, daß der neue Builder sogar als bester Compiler überhaupt ausgezeichnet wurde. Auch den Assembler TASM halte ich für ein übermächtiges Werkzeug im Vergleich zum (dagegen mickrigen) MASM.
-
Politiker wollen immer mit erhobenen Zeigefinger auf Großereignisse der Industrien hinweisen und das als Zeichen deuten, wie auf einmal alles florieren wird. Daß diese Messen, Präsentationen und Verkaufsmeetings auch ohne Rezession stattfinden ist doch klar. Erhoffen tun sich immer alle irgendwas, sonst würd´s ja keiner machen. Allerdings haben sich die Riesen-Hintergrundprojektionsfernseher mit Internetzugang bisher ja auch als Flop erwiesen. Ankommen kann nur, was die Leute bereit sind auszugeben, weil sie sich selber einen echten Vorteil davon verschaffen wollen. Ich glaube, daß DSL der Renner werden wird - vor allem die noch schnelleren DSL-Typen die jetzt auf uns zukommen. Die Telekom sagt sogar selber, daß sie nur hier wirklich was runterreißen kann.
-
Wer meint, wir würden hier keine Kritik vertragen...
Crush antwortete auf StefanE's Thema in News und Feedback zu Fachinformatiker.de
Es wird bestimmt auch nicht jeder von den Mods denken, daß sie sture Roboter und Sklaven der Boardregeln sind und deshalb unter Größenwahn wegen ihrer "Macht" leiden- da müßte man schon ziemlich naiv zu sein. -
Ich habe das ganze mal versucht irgendwie zum Laufen zu bekommen. Deine Frames wurden nicht richtig gezeichnet, weil Du mit der Invertierung gearbeitet hast. Man benötigt einen FrameIcon-kompatiblen Operator= und den Rahmen muß man beim Kopiervorgang für das FrameIcon-Objekt natürlich dann gleichzeitig dazufügen und nicht stur rüberkopieren. Sonst wird das FrameIcon ja ein normales Icon-Objekt!!! An den Protected-Part kommt man nur durch eine Friend deklaration ran oder eine Funktion, die diesen Member-Bereich indirekt weiterreicht. Hier kommt nämlich nur der Icon-Part ran! Beim Erstellen eines Frameicons muß man die Initialisierung des Icon-Teils durch die Initialisierungsliste realisieren. Alles klar? #include "stdafx.h" # define SCHWARZ 0 # define WEISS 1 int maske1[16][16] = { {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,0,0,0,0,0,0,1,1,1,1,1}, {1,1,1,1,0,1,1,1,1,1,1,0,1,1,1,1}, {1,1,1,0,1,1,1,1,1,1,1,1,0,1,1,1}, {1,1,0,1,1,1,1,1,1,1,1,1,1,0,1,1}, {1,0,1,1,1,1,1,1,1,1,1,1,1,1,0,1}, {1,0,1,1,1,1,1,1,1,1,1,1,1,1,0,1}, {1,0,1,1,1,1,1,1,1,1,1,1,1,1,0,1}, {1,0,1,1,1,1,1,1,1,1,1,1,1,1,0,1}, {1,0,1,1,1,1,1,1,1,1,1,1,1,1,0,1}, {1,0,1,1,1,1,1,1,1,1,1,1,1,1,0,1}, {1,1,0,1,1,1,1,1,1,1,1,1,1,0,1,1}, {1,1,1,0,1,1,1,1,1,1,1,1,0,1,1,1}, {1,1,1,1,0,1,1,1,1,1,1,0,1,1,1,1}, {1,1,1,1,1,0,0,0,0,0,0,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, }; int maske2[16][16] = { {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,0,0,1,1,0,0,1,1,1,1,1}, {1,1,1,1,1,0,0,1,1,0,0,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,0,0,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,0,0,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,0,0,1,1,1,1,1,1,1}, {1,1,1,1,0,1,1,1,1,1,1,0,1,1,1,1}, {1,1,1,1,1,0,0,0,0,0,0,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, }; int maske3[16][16] = { {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,1,1,1,1,0,0,0,0,0,0,1,1,1,1,1}, {1,1,1,1,0,1,1,1,1,1,1,0,1,1,1,1}, {1,1,1,0,1,1,1,1,1,1,1,1,0,1,1,1}, {1,1,0,1,1,0,0,1,1,0,0,1,1,0,1,1}, {1,0,1,1,1,0,0,1,1,0,0,1,1,1,0,1}, {1,0,1,1,1,1,1,1,1,1,1,1,1,1,0,1}, {1,0,1,1,1,1,1,0,0,1,1,1,1,1,0,1}, {1,0,1,1,1,1,1,0,0,1,1,1,1,1,0,1}, {1,0,1,1,1,1,1,0,0,1,1,1,1,1,0,1}, {1,0,1,1,0,1,1,1,1,1,1,0,1,1,0,1}, {1,1,0,1,1,0,0,0,0,0,0,1,1,0,1,1}, {1,1,1,0,1,1,1,1,1,1,1,1,0,1,1,1}, {1,1,1,1,0,1,1,1,1,1,1,0,1,1,1,1}, {1,1,1,1,1,0,0,0,0,0,0,1,1,1,1,1}, {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, }; class icon { friend class frameicon; // sonst kommt man an die protected-Elemente nicht ran friend icon operator+( icon i1, icon i2); friend icon operator!( icon i); protected: int bitmap[16][16]; public: icon( int f=WEISS); /* initialisiert ein icon */ icon( int x[][16]); /* kopiert "bitmuster" als icon */ int compare( icon i1, icon i2); void show(); }; icon operator+( icon i1, icon i2) { icon x; int i,j; for( i=0; i<16; i++) for( j=0; j<16; j++) x.bitmap[i][j] = i1.bitmap[i][j] & i2.bitmap[i][j]; return x; } icon operator!( icon x) { icon y; int i,j; for( i=0; i<16; i++) for( j=0; j<16; j++) y.bitmap[i][j] = x.bitmap[i][j]^1; return y; } icon::icon( int x[][16]) { int i,j; for( i=0; i<16; i++) for( j=0; j<16; j++) bitmap[i][j]=x[i][j]; } icon::icon( int f) { int i,j; for( i=0; i<16; i++) for( j=0; j<16; j++) bitmap[i][j]=f; } void icon::show() { int i,j; for( i=0; i<16; i++) { for( j=0; j<16; j++) { if( bitmap[i][j] == WEISS ) cout << '*'; else cout << ' '; } cout << endl; } cout << endl; } int icon::compare( icon i1, icon i2) { int i,j; for( i=0; i<16; i++) for( j=0; j<16; j++) { if( i1.bitmap[i][j] != i2.bitmap[i][j]) return 0; } return 1; } class frameicon: public icon { public: frameicon( int rf=SCHWARZ, int ff=WEISS); frameicon(int x[][16]):icon(x){} // Das Bitmap-Element muß initialisiert werden frameicon operator=(icon v); // frameicon& operator=(icon v){return static_cast<frameicon&>(v);} // klappt nur bei einzelner Zuweisung und wäre eine "harte" Methode }; frameicon frameicon::operator=(icon v) { int i,j,rf=SCHWARZ, ff=WEISS; for( i=0; i<16; i++) for( j=0; j<16; j++) { if( i==0 || j==0 || i==15 || j==15) bitmap[i][j]=ff; else bitmap[i][j] = v.bitmap[i][j]; // Beim Zuweisen eines Icon auf einen FrameIcon muß der Rand noch dazugefügt werden! // ansonsten würde ein bestehender Rand ja gelöscht werden (logisch, oder?) } return *this; } frameicon::frameicon( int rf, int ff) { int i,j; for( i=0; i<16; i++) { for( j=0; j<16; j++) { if( i==0 || j==0 || i==15 || j==15) bitmap[i][j]=ff; else bitmap[i][j]=rf; } } } int compare( icon i1, icon i2) { if( i1.compare(i1,i2)) return 1; else return 0; } void main() { icon m1( maske1); icon m2( maske2); icon m3( maske3); icon m; frameicon fi1(maske1); frameicon fi2(maske2); frameicon fi3(maske3); frameicon n; /* if( compare( m1,m2)) cout << "gleich" << endl; else cout << "ungleich" << endl; if( compare( fi1,fi2)) cout << "gleich" << endl; else cout << "ungleich" << endl; */ m= m1+m2; m=!m; // m.show(); // fi2.show(); // fi2.show(); // n=static_cast<frameicon&>(m); // wieder ein paar "brutale" Methoden, die auch nur // n=static_cast<frameicon&>(!m=fi1+fi2); // bedingt funktionieren // n=static_cast<frameicon&>(!m); // fi1.show(); n=fi1+m2; // jetzt darf man auch alles mischen n=!n; n.show(); }
-
Warum nicht - bei Programm-Problemen ist es immer besser mal in den Source reinschauen zu können. Hat das oben bis jetzt nix gebracht?
-
Da kam mal ein Bericht über die Franzosen und ihrem Gesetz zur Erhaltung der französischen Sprache. Es ist dort nach dem Berichterstatter sogar gesetzlich untersagt worden in Radio und Fernsehen französische Musik mit Fremdwörtern auszustrahlen! Weiß jemand ob das wirklich stimmt?
-
Poste doch mal den Link zu diesem Indy (vielleicht kann man´s ja selber irgendwann brauchen). Wegen dem Trayicon such mal in der MSDN nach TRAYTEST da ist alles was man so anstellen kann ziemlich gut in einem Komplettbeispiel dargestellt.
-
Die friends muß man halt immer explizit in der Basisklasse angeben, aber die Operatoren werden vererbt. class test { friend class frtest; // muß in der Basis stehen, weil nicht vererbbar friend class afrtest; int x; public: test(int v=0):x(v){} ~test(){} int getfriend() {return x;} operator<<(test& v) {this->x=v.getfriend();} }; class frtest : public test { public: frtest(int l=0){x=l;} ~frtest(){} }; class afrtest : public frtest { public: afrtest(int l=0){x=l;} ~afrtest(){} }; void meinefunc() { int v1,v2,v3; test a(5); frtest b(3); afrtest c(1); v1=a.getfriend(); v2=b.getfriend(); v3=c.getfriend(); c<<b; // funktioniert! v3=c.getfriend(); }
-
Grundsätzlich kann man das so nach den Konventionen machen. ABER: ... die Bitfelder verwende ich NIE!!! Und zwar aus dem Grund, wie die Compiler das handhaben. 1. sind mehr als 32 Bit nicht möglich (bei M$) ist aber meines Wissens maschinenabhängig. 2. werden die Bitfelder durch Zwischenspeichern, verheriges durch-die-Gegend-Rotieren und erst mal Ausmaskieren extrem langsam und sind auch nicht unbedingt geschickter zu verwenden. (dazu braucht man nur mal so einen Bitfield-Zugriff im Debugger anschauen - absoluter Wahnsinn was Studio da anstellt) 3. Der Einsatz von ganzen Bytes ist wohl kaum langsamer und sogar geschickter, selbst wenn ich dann nachher noch alle Bits zusammenmaskieren müßte um sie dann auf den Port zu legen. Ich bin ein bekennender Verfechter der Bitfield-Befehle - aber nur in C++. In ASM sieht das wieder ganz anders aus! Hier zeigt sich einfach mal wieder wie miserabel Compiler Code übersetzen. Derselbe Spaß findet auch beim Bits Rotieren statt - auch das ist nur umständlich mit unnötigen Zwischenspeicher und Ausmaskieren zu lösen und wird alles andere als maschinennah übersetzt (auch das gibt´s in nur einem ASM Befehl). Das soll jetzt kein Aufruf sein, daß sein zu lassen. Doch es ist einfach schade zu sehen, wie kostbare Rechenzeit von schlechten Compilern verplempert wird.
-
Da hast Du aber Glück gehabt, Poldi, daß Du keinen Spaziergang durch die Bronx gewagt hast! =8-D
-
Mehrfachvererbung ist ja auch eigentlich eine Generalisierung und steht im krassen Gegensatz zur Objektorientierung (welche eher eine Spezialisierung darstellt - ist natürlich auch die Frage aus welcher Richtung man das betrachtet), weil hier Objekte aus verschiedenen Klassen zusammengemischt werden, die man vielleicht besser als Member eines neues Objekts definieren sollte. Ein Auto hat einen Stoßdämpfer und 4 Räder und ist kein vierrädriges Stoßdämpfer-Auto. Die OO soll sich ja auch am Sprachgebrauch mitorientieren - und da heißt fast es immer: hat (Member-Objekte=Enthalten via Wert, Komposition->Objektreferenzen=Enthalten via Referenz, Aggregation=enthalten via Zeiger, ist ein ...(=Vererbung), benutzt (Parameterübergabe von Objekten) oder ist abstrakt (sobald virtuelle Methoden vorkommen - es darf davon keine Instanz existieren) und dient somit nur als Vorlage, bzw. Vereinheitlichung gemeinsamer Teil-Komponenten verschiedener Klassen. "Das ist m.E. nach ein Schlag ins Wasser gewesen. Wer mit Schnittstellen arbeitet der weiss was ich meine. All diese Namenskonventionen in Bezug auf Methoden etc...." Wenn´s nicht einleuchtend ist, wird man die Mehrfachvererbung bestimmt nicht einsetzen. Es gibt aber schon Fälle, wo eine Mehrfachvererbung unvermeidbar ist. Z.B. wenn man zwei komplett verschiedene Produkte hat (die nichts miteinander zu tun haben) und daraus ein 3. Neues zusammenstellt. Das hat dann schon Sinn. Genauso bei zusammengesetzten Fenster-Objekten, welche Eigenschaften in sich vereinheitlichen sollen. Bei Schnittstellenprogrammierung würde mir nicht mal im Traum einfallen hier irgendwas durch Mehrfachvererbung erreichen zu wollen. Da gibt es normal nur "ist" und "verwendet". Vielleicht solltest Du das mit den Namenskonventionen genauer erklären, anstatt es nur in den Raum zu stellen.
-
Würde mich wirklich mal interessieren, wie ein Programm für solche Kisten in etwa aussieht (wieviel Codezeilen, was für Programmiersprachen), wer da dran sitzt und wieviel dafür kassiert.
-
Was steht denn in der cray.h?
-
Ich bin ein echter Fan der Star Wars Serie. Die ersten 3 Teile waren super - eigentlich waren die Ewoks auch gar nicht so übel, aber Episode 1 war für mich etwas enttäuschend. Egal - die ersten Trailer von Episode2 lassen auf einen richtigen Megahammer hoffen. Jedenfalls habe ich schon lange nicht mehr so exzessive HQ-CG-Flut gesehen wie in diesem Trailer "Clone War". Sogar der witzige Yoda spielt wieder mit und Darth Vader die Hauptrolle! Und wenn ich schon mal wieder sage worauf ich mich noch freue, dann vielleicht noch der Scorpion King, Zu Warriors, Eight legged Freaks und Resident Evil.
-
Das Chaining wie Du es meinst habe ich eigentlich unter dem Deep Copy Constructor beschrieben. Es ist ja auch wahr, daß OO nichts wirklich Neues ist. Was man hier unter dem Thema Klassen laufen läßt ist nichts weiter als Datenbündelung und Abgrenzen von Funktionen auf diese Datenbündel. Das hat man halt früher nicht so schön darstellen können, war aber auch anders genauso lösbar. Protected oder Private Vererbung hat schon einen Sinn, kann aber tatsächlich anders dargestellt werden. Public entspricht der Schnittstellenvererbung und Private/Protected der Implementationsvererbung, was aber genauso auch durch ein privates Member-Objekt dargestellt werden kann. Ich sehe das weniger als Designfehler als lediglich eine logische Schlußfolgerung auf Öffentlich/Private Trennung innerhalb der Klassen nach außen auf die Vererbung übertragen - aber redundant, weil man es auch anders lösen kann, jedoch ist es dann nicht so schnell ersichtlich, was man beabsichtigt hat. Vieles in der Syntax ist nicht absolut notwendig (genauso wie die Rekursionen) und dient nur der Übersicht. Das mit der Template-Metaprogrammierung ist ja auch nur eine zufällig entdeckte Methode um Macros zu definieren, die man über Defines oder eigene Funktionen genauso realisieren kann. Das war ja auch nur zufällig entdeckt worden als Nebeneffekt der Template-Maschine. Was Du jetzt mit den kanonischen Formen meintest habe ich wohl falsch verstanden. Vielleicht könntest Du das mal etwas näher erläutern. "Was einfach fehlt, sind so Aha-Erlebnisse, wo Du ohne OOP voll vor die Wand knallst, und es mit OOP aber funktioniert." -> Das halte ich für etwas unmögliches, weil einfach alles auch ohne OOP realisierbar ist. Eigentlich ist das nichts weiter als eine Strukturierungsmethode für Soucecode - unter dem Deckmantel, daß man etwas weniger Tipparbeit hat und Fehlerquellen dadurch eingeschränkt werden sollen. Sicherlich ist das Debuggen ohne diese Strukturierung schon etwas schwieriger - andererseits komme ich im Debugger ohne den Assembler-Code und den Trace-Mode kaum aus, welche davon überhaupt keinen Gebrauch machen. Viele der OO-Themen bringen genau hier keine Vorteile. Versuch mal was von CObjects abgeleitetes oder verkette Listen aller Art im Debugger anzuschauen. Ich halte OO für nichts anderes als eine andere Darstellungsform. Doch viele Dinge, die durch diese Sprach-Konstruktion entstanden sind sind der Übersichtlichkeit im Wege oder machen die Programmierung in bestimmten Bereichen unheimlich kryptisch. Jedes Plus hat auch ein Minus. Das ist auch der Grund, wieso eine so riesige Anzahl an Programmiersprachen existiert. Jeder glaubt, daß seine genial ist - und das ist sie auch bestimmt für ihren Einsatzbereich. Ob ich jetzt mit VB Oberflächen, mit Delphi DB-Anwendungen, mit Java plattformunabhängige Abfragemasken oder C rasend schnelle Systemnahe Software erstelle spielt doch keine Rolle. Jede hat Ihre Berechtigung und je nach Einsatzgebiet seine Vor- und Nachteile. Schon vor 12 Jahren habe ich ein paar Entwicklern von Warenwirtschaftsssystemen direkt mal über die Schulter geschaut, weil ich bei denen in den Entwicklungssessions die Protokolle geführt habe und das ganze für die Programmierer gut verdaulich aufbereiten mußte. Die ganzen Datenflußpläne und Datenobjekte sind damals auch nicht anders festgehalten worden wie in der OO. Man hatte seine Objekte, mit Attributen und diese wurden so oder in andere Objekte eingebettet, verwendet oder anderweitig abgefragt. Für jede Form von Objekten gab es Zugriffs und Verwaltungsfunktionen und unter dem Deckmantel einer Oberfläche mit entsprechend vielen Bildschirmmasken hat man im VGA-Modus mit dem ANSI-Zeichensatz hat man diese dann erstellen, editieren und abfragen können. Für mich hat sich mit OO nichts geändert. Nur wird das heute halt so dargestellt, als ob man etwas völlig Neuartiges geschaffen habe, was die Welt nachhaltig verändern wird und ein extrem mächtiges Werkzeug ist. Für mich ist OO vor allem ein Modewort für eine andersartige Syntax - sonst nix. Ich kann mir wie gesagt nicht vorstellen, daß man mit OOP irgendwas machen kann, was ohne nicht genauso funktionell realisierbar ist - und deshalb wird es ein solches Beispiel nie geben. Deshalb sind solche Diskussionen wie gut oder schlecht die Vorzüge davon nun sind, ein wenig überflüssig. Als C sozusagen als Superassembler erfunden wurde dachte man ja auch, man hat die ultimative Waffe im Kampf gegen die Hardware erfunden. Das dachte man mit Modula1&2 auch und auch mit Fortran, Logo, Lisp und Cobol usw. usw. Wirklich innovativ fand ich das ehrgeizige Projekt von einem, der eine geniale Symbiose erfunden hat: Assembler mit C Syntax: EZASM. Das war für mich ein echter Lückenfüller. Schade, daß dies wohl kaum beachtet wurde. Das wäre vielleicht auch eine Sache, mal zu überlegen, was man gerne an der Syntax anders sehen möchte. Viele Dinge wie Index-indizierte Zugriffe sind meiner Meinung nach in Assembler wesentlich übersichtlicher gehalten als in C++. Auch viele der Bitoperationen sind nicht mehr einfach möglich. Man entfernt sich von den Vorteilen der Prozessoren und der Systeme aufgrund von Compilerbau und Portabilität - und die Optimierungsmethoden sind alles andere als gut. Einmal schreit jeder, wenn ein Computer sich durchsetzt, dann wenn ein Betriebssystem sich durchsetzt und dann als letzte Schlußfolgerung versucht man künstlich Sprachen zu erzeugen, die auf allen laufen sollen ... ich halte von diesen Bewegungen irgendwie nicht viel. Ich bin wenn es um sowas geht der, der für die Forcierung von internationalen Standards im Computerbereich steht - dann wäre die Welt doch viel einfacher. Programmiersprachen sind nur Mittel zum Zweck und sie entwickeln sich genauso wie die echte Sprache im wirklichen Leben. Nichts bleibt einfach stehen, irgendwas gefällt dem einen mehr oder weniger und so wird halt mal irgendwann aufgrund der Forderungen wieder was verändert. Aber man kann genauso wie in der Physik nicht ständig das Rad neu erfinden. Es gibt Prinzipien die immer als Basis zugrunde liegen. Es wird wohl nie wirklich AHA-Erlebnisse geben. Eine Programmiersprache ist mit den vielen Schnittstellen und Steuerungsmethoden die geschaffen worden sind auch immer mehr und mehr eine Übereinkunft von Programmierern geworden, damit man eine Basis hat mit der man Daten hin- und herschaufelt. Deshalb sind für mich Sprachdiskussionen nur in einem Zusammenhang sinnvoll: Nach dem Einsatzgebiet - und sonst nix.