Crush

Ich würde, wenn ich Möllemann wäre, mich nicht entschuldigen. Erstens sollte man zu seinem Wort stehen (als Politiker ohnehin, weil man denen bald nix mehr glaubt) und außerdem sind die Leute in Jerusalem doch wirklich in einem Kriegszustand und deren Gehabe (ich denke an die mehrwöchigen "Säuberungsaktionen") läßt einen doch Parallelen erkennen, die man nicht abstreiten möchte. Auf jeden Fall als "heiliges" Volk haben die verdammt viel Dreck am Stecken find ich. Die sind eine Schande für das Christentum. Warum die auch noch Atomwaffen bunkern dürfen und keiner verschwendet einen Gedanken darum ist mir ein Rätsel. In Afghanistan konnte man auch einmarschieren und für Ordnung sorgen ohne mit der Wimper zu zucken. Bei Jerusalem hat meiner Meinung nach die Nato bisher kläglich versagt. Im Fernsehen bestehen zu 99% Nachrichten aus Jerusalem und keiner reagiert - find ich komisch.

Andererseits hast Du recht Klotzkopp, wenn Objekt1 ein globales Objekt verändert und Objekt2 dieses dann verwendet... Aber tut denn sowas fieses (bringt doch nur alle durcheinander)? Ist aber ein guter Trick um Code für andere unzugänglich zu machen. Man darf aber nicht vergessen, daß der normale Konstruktor ja auch nur als Ergänzung offen gelassen wurde, um dem Programmierer zu ermöglichen dynamisch Variablen für das jeweilige Objekt anzulegen und nicht nur irgendwelche eigenen Elemente zu initialisieren. Das man das auch noch meist tun kann ist ja nur ein beiläufiger Nebeneffekt aber nicht unbedingt in jeden Fall erwünscht wie die konstanten Elemente beweisen. Auch bei statischen Klassenelementen sollte die Initialisierung auch immer außerhalb durch den Programm-Lader erfolgen und nicht durch den Konstruktor der Klasse! Folgendes hat mich schwer beschäftigt (schwieriger als manche sonstige Programmierfrage im Forum): From Daragon: Das ganze wird wie es aussieht (stimmt - sieht so aus als ob C++ objektorientiert sein könnte - aber da Spalten sich die OO-Robin Hoods, ich würde sagen C mit objektorientierten Erweiterungen jedenfalls hätte man das auch so verstehen können) mit einem objektorientien Compiler geschrieben (ob der Compiler objektorientiert ist - da bin ich mir nicht so sicher, weil der aus einer Zeit stammt, als es noch gar keine Objektorientierung gab =8-) und trotz alledem werden die Source-Codes in den einzelnen Dateien *.cpp etc sequentiell abgearbeitet (das hoff´ ich doch schwer, dann bräuchte man sonst keine Includes mehr und könnte gleich alles in eine einzige .CPP reinknallen, was ja geht). Das ganze kannst du aber auch mit dem Debugger durchgehen und läßt dir die lokalen Variablen anzeigen (das mit den Namespaces bringt aber nicht viel bei der Elementinitialisierung - nur mit Blick auf den Assembler-Code kann man wirklich "sehen" was passiert - ansonsten steht man immer vor vollendeten Resultaten). Dann kannst du dich selber überzeugen lassen (ist irgendwo der Wurm drin - entweder: Dann kannst du dich selber überzeugen oder Dann kannst du dich überzeugen lassen von wem denn? oder... wovon denn eigentlich? Das die Elemente überhaupt initialisiert werden? Der Beitrag war bestimmt gut gemeint, allerdings wirft der für mich mehr Fragen auf als gestellt wurden und trägt so eher zur Verwirrung als zur Problemlösung bei. Trotzdem danke für den Versuch... (falsch war ja schließlich nichts - also: don´t worry - be happy!)

Der Speicher ist doch wohl wirklich nicht das Problem. Selbst bei 500 Anschlägen pro Minute schafft man am Tag kein Megabyte voll.

Das könnte allerdings irgendwann so kompliziert werden, daß man kaum noch blickt, was ein Programm tatsächlich anstellt - und da hilft es mehr lieber kurz durchzutracen ob´s überhaupt läuft anstatt den Kopf vorher schon zum Platzen zu bringen.

Also Dein Beispiel könnte eigentlich (theoretisch) nicht wichtig sein, weil der Konstruktor von bar1 und bar2 auch ohne den Element-Konstruktoraufruf normal durchwandert wird. Ich glaube, das ist eher eine Konsequenzfrage und eine Frage des Programmierstils, falls man bei den Elementobjekten konstante Inhalte hat und diese nach außen hin versteckt initialisieren möchte. Damit hat foo() die Aufgabe eines Dekorierers oder einer Fassade um in den verwendeten Elementklassen Information-Hiding zu betreiben. Sowas kann bei bestimmten Konstruktionen Sinn haben, z.B. wenn man im Atomkraftwerk die Pumpe hat, welche von Pumpeninspektor an den Pumpenregler weitergereicht wird, so ist die Pumpe selbst versteckt, geschützt und so kann man schaffen, ohne daß man friends unbedingt einsetzen muß (obwohl die für solche Zwecke und Operatoren implementiert wurden). Außerdem kann man so private Vererbung vermeiden, wovon ja jeder abrät. Es ist also wahr, daß man Deine Konstruktion schon noch in Sonderfällen verwenden muß, nämlich wenn konstante Elementobjekte von konstanten Elementen bei der Konstruktion initialisiert werden sollen!!! (hört sich das wieder kompliziert an... =8-) class bar1 { public: bar1(int Priv=0):priv(Priv){ TRACE("Erster\n"); } ~bar1() {;} private: int priv; // hätte man auch const priv schreiben können weil´s durch // foo eh konstant ist // andererseits ist es so als einzelnes bar-Objekt noch für friends verwendbar }; class bar2 { public: bar2(int Priv=0):priv(Priv){ TRACE("Zweiter\n"); } ~bar2(){;} private: int priv; }; class foo { public: // foo(int zahl=0) : b1(zahl), b2(zahl) {} // nur notwendig wenn den Initialisierer von bar1 und bar2 was anderes // übergeben werden soll foo() {} // geht genauso und springt die Konstruktoren richtig durch // foo() {b2(5);} klappt ja leider nicht weil´s konstante // Objekte sind, also EI notwendig ist ~foo(){;} private: const bar2 b2; // bar2 b2(5); // geht nicht, gilt als schon konstant (wunderlich, gell?)!!! const bar1 b1; }; foo boo; // foo boo2(2); // hier muß man Dein Beispiel tatsächlich zwangsläufig einsetzen, also hast Du Recht // es gibt also Ausnahmen Was Daragon damit sagen wollte ... darüber rätsel ich noch etwas.

Computer arbeiten halt Konstruktionsbedingt mit dem Index 0, deshalb ist das eigentlich der Standard. Das Zählen mit 1 ist nur ein Sprachgebrauch aufgrund der Tatsache, daß 1 Apfel 1 mal da ist und er deshalb der 1. sein muß! Dann zählt man in der Reihe: Der erste Apfel ist an Position 1. Wie gesagt arbeiten Rechner mit der Position 0 weil die Datenleitungen alle auf 0 liegen können. Früher hat man sich dann immer so beholfen, indem man den Index 0 entweder freigelassen hat oder Zugriffe mit Index-1 berechnete um sich dem Sprachgebrauch anzupassen. Es liegt im Ermessen des Programmierers und Compilerbauers einer Variante den Vorzug zu geben und stellt lediglich ein Schritt auf den Benutzer dar. Da es sich bei C++ um einen Super-Assembler handelt, arbeitet man hier halt mit Index0. Sollten Klassen oder Programme andere Möglichkeiten bieten darf man sich beim Programmierer bedanken und nirgendswo sonst. Wo kümmert sich da also der Compiler drum??? Ist mir unverständlich. Wenn es sowas wie einen Standard gibt basiert der hier mit Sicherheit auf der Maschinensprache. Bis heute gilt jedoch: ES GIBT KEINEN SPRACHÜBERGREIFENDEN EINHEITLICHEN STANDARD FÜR ARRAYS!!!

Die Reihenfolge der Initialisierungsiste wird nicht direkt abgearbeitet! Die Compiler orientieren sich nach der Reihenfolge der Variablendeklarationen in der Klasse (sicherlich wegen der Stack- & Heap-behandlung beim Konstruktoraufruf) - das spielt aber für den C++-Programmierer eh keine Rolle (höchstens wenn man sich direkt an den Assembler-Code wagt). Sollte mal irgendwo ein unerklärliches Initialisierungs-Problem auftauchen, könnte also u.U der Compiler dran schuld sein, weshalb es ratsam ist die Liste in Reihenfolge der Deklarationen vorzunehmen. Beim *** Visual C++ gibt´s da jedoch keine Probleme. Mir persönlich ist auch kein Compiler bekannt, bei dem das nicht korrekt bearbeitet wurde. Ich verlasse mich also normal darauf, daß der Compiler keinen Mist baut, aber ich behalte das für eventuellen Ärger mal im Hinterkopf. Gegenfrage außerhalb des Themas: Warum darf ich nicht mehr "Microsoft-Dollar" schreiben?

Es gibt schon Unterschiede: - Der Konstruktor legt erst alle verwendeten Variablen auf dem Stack an bevor in die Funktion gesprungen wird und danach die Variablen ein zweites mal mit dem Initialwert beschriftet werden, wodurch ein schlechteres Laufzeitverhalten folgt. Das macht die Initialisierungsliste in einem Rutsch. - die Initialisierung der Member-Variablen ist übersichtlicher wenn sie gleich direkt beim Konstruktor erfolgt - im Konstruktor selbst ist es nicht mehr auf einen Blick erkennbar, ob es sich wirklich um Member- oder Lokale-Variablen handelt: Dient der Leserlichkeit! Das Wichtigste wie Du schon gesagt hast: Konstante, bzw. nicht-statische Member-Variablen können NUR über die Initialisierungsliste direkt beschrieben werden. Versucht man das im Konstruktor gibt´s eine Fehlermeldung: "Variable XYZ" : muss in der Basisklassen/Element-Initialisierungsliste des Konstruktors initialisiert werden

Könntest Du mal Codeauszüge posten, da das Fenster jedesmal kleiner wird vermute ich da irgendeinen Fehler im Programm und nicht in SetWindowPos().

Ich kenne das auch nur als CSharp (C#). Und habe irgendwo gelesen, daß das vom "Schärfen", bzw. hochstellen (von der Musik her) kommt, womit man ausdrücken wollte, daß die Sprachregeln von C (und C++) verschärft und erweitert wurden.

Also für mich sahen die Mädel vom Video und dem Bericht keineswegs jünger als 20 aus ... eher älter (und wenn die das nicht hätten tun wollen hätten sie es wohl auch nicht getan). Wer frägt denn ein nettes Mädel, welches mit einem ins Bett steigen will zuerst nach dem Alter???

Algorithmen & Datenstrukturen... Dafür eine eigene Kategorie einzurichten halte ich für gar nicht so falsch, weil´s nicht in IDE, C/C++ oder Java paßt und im Sonstigen untergeht. UML oder sonstwelche Notationen sind allerdings wohl ein paar der besten Hilfsmittel zur Abstraktion und sollte auch mit reingenommen werden - die meisten wissen nur nicht, wie man das direkt in die entsprechenden Sprachen umsetzen kann, bzw. wie man tatsächlich ein komplexes Projekt so erstellen könnte und nur der Profi schafft es beim wilden Drauflosprogrammieren dann noch den Überblick zu behalten und vielleicht Designfehler zu vertuschen. Manche Dinge sind auch abstrakt betrachtet ohne Codierungsbeispiele fast nicht zu kapieren, wie möchte man jemand "einfach" beim Heap-Sort den Siftup() & Siftdown() verdeutlichen ohne jegliche Codebeispiele? Vielleicht rafft´s zwar einer auf anhieb, wenn es aber dann darum geht das ganze in Code zu realisieren stehen bestimmt viele da wie der Ochs vorm Berg (nur allein deshalb, weil es zig Möglichkeiten zur Umsetzung gibt - und hier trennt sich dann die Spreu vom Weizen). Vollkommen wird man nie das Abstrakte von der Umsetzung trennen können, weil einfach das eine zu eng mit dem anderen verwoben ist und gerade UML als (Design&Entwurfs)Mittel zum (Programmier)Zweck entworfen wurde. Ernsthaft gefragt: Wer von den Fachinformatikern ist überhaupt in der Lage nach der Ausbildung ein UML-Diagramm in C++ oder Java auszuprogrammieren??? Also bei uns hätte der Schulstoff alleine für gar nix gereicht - wer aber später im Beruf beim Programmieren seine Erfüllung sieht sollte sich dazu in die Lage versetzen wenn er ernst genommen werden möchte. Also ich bin dafür Algorithmen & Datenstrukturen + UML als eigenständigen Bereich aufzunehmen und Stimme deshalb DoubleZero voll zu (auch bei OOA, OOD, OOP). Zu gaiusjUlius: Die Implementierungsfrage wird zwar fast immer zu einer Algo-Frage gestellt, aber in einem entsprechend Bereich hätte man so wenigstens die Chance sich um das Wesentliche selbst zu beschäftigen und kann bei der Lösung in bestimmten Programmiersprachen dann per Link in der entsprechenden Sektion auf einen neuen Thread verweisen - das muß man halt vorher schon als Regel aufstellen, dann sollte das auch kein Problem sein. Vielleicht wäre es gar nicht so falsch von einem Algo-Bereich auf einen Implementations-Bereich und von dort zurück eine Doppel-Verzweigung einzurichten, dann hat man immer alles ordentlich getrennt und doch nicht auseinandergerissen. -> Widerspricht sich diese Aussage nicht ein wenig?

Genau!

Eigentlich hast Du Deine Frage selbst beantwortet, wenn Du nämlich genau hinschaust hast Du geschrieben: void swap(int *x, int *y); Das bedeutet es werden zwei Pointer auf int erzeugt (x und y). dann war Dein Beispiel: 1) int x = 5; 2) int * p_ptr; 3) *p_ptr = &x; was natürlich nicht klappt, weil p_ptr ein Zeiger ist und bei 3 der Zeiger dereferenziert wird, also der Inhalt der Speicherstelle auf die der Zeiger zeigt verändert werden soll. Richtig wäre p_ptr=&x; oder *p_ptr=x; Wird ein Zeiger erzeugt, sieht es nur aus wie eine Dereferenzierung, aber in Wirklichkeit ist es eine Deklaration welche klar macht, daß p_ptr ein Zeiger sein soll!!! int * p_ptr=&x; -> das ist es, was beim Funktionsaufruf passiert. Es wird ein Zeiger erzeugt und die Adresse von x übertragen. Es wird NICHT dereferenziert. Jeder spätere *p_ptr-Zugriff ist eine tatsächliche Dereferenzierung, weil die Variable schon existiert. Beim 1. mal wird also das * nur für die Unterscheidung (Deklaration) der Variable p_ptr als Zeigervariable verwendet! Deshalb funktioniert auch diese Version korrekt: int x = 5; int * p_ptr; // Deklaration von p_ptr als Zeiger p_ptr = &x; // Initialisieren des Zeigers mit einer Adresse *p_ptr = x; // Beschreiben der Zeigervariable mit einem Wert vom Typ int (von x) Reicht das als Erklärung aus?

Für alle, die die Prüfung wohl nicht so geschafft haben gibt es die Möglichkeit sich durch den Gehirn-Liefer-Service mehr Hirn zuzulegen. Vielleicht kann man auch bei aussichtslosen Fällen sein eigenes dort zum Verkauf anbieten. Nach der Prüfung torkelt eh jeder verzweifelt suchend rum wie ein Zombie auf der Suche nach: Brains4Zombies =8-)

Jabberwocky ist bestimmt einer der unbekanntesten Monty Phyton-Filme. Ich finde die Leichensammler dort ganz witzig.

Bestimmt meint er den Shellexecute und Windows: ShellExecute( NULL, "open", "http://www.google.de", NULL, NULL, SW_SHOWMAXIMIZED);

Viele lernen das Schwimmen am besten nicht mit Trockenübungen am Land, sondern indem man sie ins Wasser schmeißt. Entweder gehen sie dann unter, wobei die Trockenübungen wohl auch nicht allzu viel nützen oder sie SCHWIMMEN. Außerdem muß man sich früher oder später eh mit diesen fremden "Umgebungen" vertraut machen, da ist es einfacher schon von Anfang an seine Scheu zu verlieren und etwas damit herumzuexperimentieren.

Ich werde mir Simon3D auch holen, weil ich einfach den Adventure-Mix und den Humor mag. Allerdings wäre mir ein Simon2D auch lieber gewesen. Bestimmte Genre´s sollte man nicht versuchen zu verquirlen nur weil die Technik dazu da ist. Schönere Animationen oder Auflösungen wären genug. Lediglich Grim Fandango fand ich noch als Optimum wenn 3D eingebaut wird - komplett 3D find ich in Adventures nicht so überragend.

Ich meine, daß mit 8-10 Folien die Schmerzgrenze erreicht ist. So kannst Du jede Folie nicht mal ganz eine Minute präsentieren. Du bist da mehr beim Wechseln als am Erklären - was ja das wichtigere bei der Präsentation ist - und die vielen Bilder prägen sich bei den Zuhörern nicht mehr so gut ein, was eher zu Verwirrung führt.

Ich vermute, daß hier nicht allzu viele mit Borland arbeiten, deshalb empfehle ich Dir in wirklich dringenden Fällen mal die Borland-Community aufzusuchen, wo man auf eine riesen Wissensdatenbank zurückgreifen kann. Einfach mal dort nach ADO oder dem DeleteRecords() suchen oder gar gleich eine direkte Frage stellen.

Ich habe zwar mit Borland noch nie direkt gearbeitet, aber ich habe gelesen, daß die Entwicklungsumgebung vom Builder schon mehrfach einen Award als fortgeschrittendstes Entwicklungstool bekommen hat (noch vor Microsoft und IBM Produkten!). Meine persönlichen Erfahrungen von Borland-Produkt-Dokumentationen (IDE-Anleitungen, Lernkurse für C/C++/Assembler) ist, daß mir noch nie bessere, aufwendigere und so in die tiefe gehende Dokus in die Finger gekommen sind, womit die mich auch ziemlich beeindruckt haben. Die waren immer bemüht den Produkten irgendwo einen Vorsprung zu verschaffen und Fähigkeiten einzuweben, die man bei Konkurrenzprodukten verzweifelt sucht. Grundsätzlich ist das Arbeiten mit BC++Builder und VC++ eigentlich dasselbe. Es werden alle grundlegenden Funktionen fürs Programm-Rohgerüst praktisch 1:1 in beiden Entwicklungsumgebungen angeboten und sicherlich sind nur im Detail echte Unterschiede erkennbar. Vom Point&Click-Feeling müßten beide dasselbe leisten. Alles "neue" wie RTTI usw. was die Sprache betrifft ist in beiden Compilern zu 100% drin. Es gibt allerdings auch ein paar Unterschiede beim C++ die mir gleich aufgefallen sind: - Im Bereich Datenbankprogrammierung wird gerne die "Borland Database Engine" rangezogen, welche aber im Endeffekt auch wieder über ODBC abstrahieren kann. Andere direkte Datenbankschnittstellen kann man aber auch über Includes und Librraries einbinden. Jeder versucht halt seine Produkte irgendwie in den Vordergrund zu schieben ... ist normal. - Die Namensbereiche von Klassen sind teilweise etwas variabel zu orginal ***-Klassen, was zu Verwechslungen und zusätzlichem Aufwand führt, falls man mal etwas ins Studio exportieren und da übersetzen will wird zusätzlicher Arbeitsaufwand notwendig (aber vielleicht haben die das Problem ja irgendwie mit Tools o.ä. gelöst?). Sehr gerne wird Anstadt eine C(Klassenname) ein T... verwendet (hab ich nie geblickt, wieso ausgerechnet T... vielleicht weiß daß ja jemand) - Es gibt teilweise kleine Unterschiede, die auf den ersten Blick keine Übersetzungsfehler produzieren, aber sich zur Laufzeit fatal auswirken können. Ein Beispiel wäre da der String-Vergleich (müßte ich nochmal raussuchen welcher Befehl genau), bei dem zwar als Bool der korrekte Wert zurückgeliefert wird, allerdings als Int werden komplett unterschiedliche Werte geliefert. Irgendwie variieren diese Befehle schon vom Ablauf her und Borland berechnet seinen Rückgabewert komplett anders als Microsoft. Bestimmt gibt es irgendwo nähere Informationen zu solchen Abweichungen, aber grundsätzlich besteht da eine Fehlerquelle bei Unwissenheit. Diese kurze Borland-Darstellung ist zwar schon ziemlich alt, aber hier wird schon gut sichtbar, daß die Unterschiede sooooo dramatisch nicht von a nach b sind. Die zusätzlichen Entwicklungs- & Debug-Tools sind alle in nahezu gleichem Maß vorhanden und werden wohl v.a. in der Optik und den Shortcuts aber weniger von der Funktionalität voneinander abweichen. Was bei Borland die Komponents sind wird wohl in etwa den OCX-Komponenten vom Studio her entsprechen. Es ist also alles "irgendwie" bei anderen auch mit dabei. Jedenfalls als Compilerbauer habe ich vor Borland großen Respekt und bisher habe ich weniger von Bugfixes und Fehlermeldungen gehört als von Microsoft ... das muß allerdings auch nichts unbedingt bedeuten (wird ja auch von weniger Leuten benutzt und ich habe mit Borland sonst nix am Hut). Oft hört man, wie jeder "seine" Entwicklungsumgebung verteidigen will ohne die Andere auch je gesehen zu haben, was ich für Schwachsinn halte - da sollte man ohne echte Argumente ruhig drüber wegschauen. Borland wird oft etwas abwertend als das billigere Studio bezeichnet - so spricht man bestimmt gerne aus einer inneren Einstellung heraus. Allerdings glaube ich nicht, daß die High-End-Versionen preislich sooo extrem weit auseinander gehen. Man darf auch nicht vergessen, daß gerne Dinge von Microsoft mit eingepackt werden, auf die man u.U. lieber verzichten und sich als Einzelprodukt wohl kaum zulegen würde. Das Ganze entspricht nur meiner "oberflächlichen" Betrachtung mit Blick auf das C++-Builder-Buch von Tewi, welches allerdings auch schon ein paar Jahre auf dem Buckel hat. Sicherlich sieht das heute auch wieder ganz anders aus und vielleicht stimmt die ein oder andere Information, die ich so gelesen habe nicht unbedingt. Würde mich selber mal interessieren, worin die großen Unterschiede heute liegen. Borland wirbt mit RAD (Rapid Application Development) durch den Komponenteneinsatz aber ich glaube, daß da das Studio sehr gut dagegen halten kann - der große Zeitunterschied wird sich bestimmt nicht im Programmhauptgerüst bemerkbar machen, sondern im Detail der einzelnen Funktionen und Programmelemente. Ich denke: Man kann sich an alles gewöhnen und Unterschiede in IDEs sind heute nicht mehr so dramatisch wie es vielleicht früher mal war.

Die haben irgendwie Mist gebaut. Der Key ist für die neueste absolut uneingeschränkte Vollversion und keine verkrüppelte PC-Welt-Version. Lade die einfach runter, dann paßt auch der Key. Keine Angst, ist alles rechlich in Ordnung: Die haben es sich überlegt und entschieden, den PC-Lesern die Lizenz zur totalen High-End-Version uneingeschränkt zugänglich zu machen (andere müssen dafür später mal richtig ablöhnen): Software hier und die Anleitungen hier Ist noch besser, als das was auf dem Heft drauf ist! =;-) (außerdem hat mir Tiny´s Firewall immer besser gefallen als der ganze Rest). Die PC-Welt-CD kannst Du danach getrost in den Müll werfen, dafür wird´s auch keinen Key mehr geben - ist eh eine "alte" und abgespeckte Vorversion.

Damit meinte ich die Variablenübergabe auf den Stack bei Funktionsaufrufen allgemein. Bei unterschiedlichem Prozessor-Code ist das nicht möglich - ist ja auch klar.

"Calling Conventions" gibt´s schon ... nur halt keinen Systemübergreifenden oder auch einfach einen einzelnen System-Standard! Aber es ging ja mehr darum, warum und wie Variablen initialisiert sind oder werden müssen. Und deren Inhalte sind nicht nur von den Conventions schwer abhängig.