Nein, das nun nicht gerade. War ja auch nur so eine Idee. Ich weiß ja nicht, wie GC.Collect() arbeitet und wie viel Performance er benötigt. Und auch habe ich noch keine Erfahrung darin, wie viel Performance so ein 2D Sidescroll Shooter (ala Contra oder Metal Slug) schluckt. Ist ja immerhin erst unser erstes Projekt. Ich sagte ja auch nur, dass ich es mir vorstellen kann.Zitat:
Zitat von Corti
Der Absatz ließt sich etwas arrogant finde ich. Du denkst zu sehr aus deiner "Informatiker"-Sicht. Versuch mal das aus den Augen eines großen Bankunternehmns zu sehen. Die arbeiten mit Geld, sie arbeiten mit DEINEM Geld. Für die sind Computer nur mittel zum Zweck (ein Mittel das durchaus Fehler verursachen kann) und wenn dann ein System gut läuft und alles gut macht, dann würde ich mich auch über neuere Versionen fürchten. Gerade als Programmierer sollte man wissen wie schnell sich Fehler einschleichen die man nicht erkennt weil man Software nicht so benutzt wie das der Verbraucher benutzen würde.Zitat:
Zitat von niR-kun
Beschäftige dich mal mit den Computersystemen von Banken. Die haben fast alle Uralt-Software. Warum? Weil es funktioniert. Das ist für die wichtiger als fancy graphics oder feature-creep. Was meinst du wieviel Geld mit Softwareintegration gemacht wird (Also mit dem Entwicklen von Schnitstellen für Altsysteme).
Generell das Entwickeln von Schnittstellen. Bei Banken kommt ja nicht nur eine Software zum Tragen, sondern gleich mehrere, die untereinander funktionieren müssen. D.h. es müssen Schnittstellen gebaut werden.Zitat:
Zitat von R.D.
Unsere Software bekommt die Daten von anderer Software eines anderen Hersteller. Dafür haben wir dann Schnittstellen gebaut. Wenn sich dann was an einer Software ändert und unsere Schnittstelle kann damit nicht umgehen, dann ist es meist schon zu spät. Wenn Updates eingespielt werden müssen, dann wird das eh erst Monatelang in einem Testsystem beobachtet, ob sich alles verhält, wie es soll, ehe das Update wirklich live geht.
Generell würde ich da sagen, dass ihr euch da erstmal keine Gedanken machen braucht. Das anschmeißen des GCs sind eher minimale Optimierungen, die man erst mal vernachlässigen sollte.Zitat:
Zitat von RPG Hacker
Falls ihr irgendwo Performanceprobleme haben solltet, dann liegen sie meist an einer anderen stelle. Gerade was Grafiken angeht, tappt man gerne als Anfänger in diverse Fallen. Ich kann davon ein Liedchen singen, als ich in meiner Ausbildung ein MS Paint-Klon basteln sollte. So trivial ist die ganze Thematik nämlich nicht. Ich weiß zwar nicht, mit was ihr euer Spiel entwickelt, aber ich würde euch raten, mal XNA anzuschauen, falls ihr das nicht schon tut. Das Framework ist sehr mächtig und auch recht gut dokumentiert.
Und außerdem: Du arbeitet sehr wohl mit Pointern in C#. Nur nennen sich diese hier Referenzen. ;)
Wenn du ein Objekt instanzierst, bekommst du als Rückgabewert ein Pointer auf dein Objekt.
Jab, wir benutzen XNA. Aber ehrlich gesagt bin ich davon nicht nur begeistert. XNA bietet zwar ein nettes Framework, mit dem man schnell in eine Engine einsteigen kann und die wichtigsten Funktionen gleich schon geboten bekommt (was auch durch die Einfachheit von C# noch unterstützt wird), oftmals ist aber gerade dieses hohe Level genau das Problem. Bestimmte Tweaks am zu Grunde liegenden System sind erst gar nicht möglich ohne eine komplett eigene Engine zu schreiben. Die Erfahrung habe ich jedenfalls gemacht, wenn es beispielsweise um so Sachen geht wie Timing. Konkret habe ich mal versucht, Interpolation in ein Spiel einzubauen. Und obwohl auf MSDN steht, dass in XNA die Draw-Methode selbst dann noch möglichst oft aufgerufen wird, wenn man das Spiel auf Fixed Time Steps stellt, hat das bei mir nicht so wirklich funktioniert. Faktisch wurden Update und Draw bei mir immer noch gleich oft aufgerufen. Beispielsweise hatte ich mal testweise die Update-Frequenz auf 4 FPS gesetzt. Der Effekt war, dass auch Draw nur mit 4 FPS aufgerufen wurde. Solches Verhalten zu verändern wird in XNA beispielsweise nicht leicht.Zitat:
Zitat von Whiz-zarD
Eine andere Sache, die mir in XNA nicht gefällt, ist dass es viele Sachen komplizierter macht als nötig. Zur Erläuterung: In unserem Spiel gibt es einen Laser, der Ray-Tracing verwendet und genau bis zur nächsten Wand fliegt. Zur Darstellung verwenden wir Tiles, die wir x-mal wiederholen. Nun dachten wir uns, dass es vielleicht einen ganz guten Effekt gäbe, wenn wir den Laser per Add-Blending darstellen. War auch an und für sich keine schlechte Idee, nur haben die Tiles sich an den Übergängen überlappt (was in XNA sonst kaum anders lösbar wäre aufgrund gewisesr Eigenschaften), was bei Add-Blend natürlich bedeutet, dass an dieser Stelle doppelt addiert wird und man Übergangskanten hat. Schön und gut dachte ich mir. Zeichne ich den Laser einfach vorher per Alpha-Blend auf einen Buffer und dann von da per Add-Blend auf den Bildschirm. Aber nein, Pustekuchen. Das einzige, was ich dafür hätte verwenden können, sind RenderTargets. Und die sind einfach so ziemlich das schlimmste, was es in XNA gibt. Jeder, der damit schonmal gearbeitet hat, kennt sicher das Problem mit der lilanen Farbe im Hintergrund. Ich schwöre: Ich habe ein paar Stunden lang gegoogelt und diverse als funktionierend abgestempelte Methoden teilweise eins zu eins übernommen. Ich habe es einfach nicht geschafft, die Farbe rauszukriegen. In anderen Libraries, beispielsweise Allegro, hätte ich an diesem Problem vielleicht fünf Minuten gesessen.
Also wie gesagt: XNA ist schon ein nettes Framework für den Einstieg in eine eigene Engine, weil es einem viel Arbeit schon abnimmt, aber für ein wirklich ernsthaftes Projekt, für das ich etwas mehr Zeit hätte, würde ich es nicht verwenden wollen.
Klar. Habe ich denn was anderes behauptet? Ich bin ja nicht auf den Kopf gefallen. Natürlich sind Referenzen in C# nichts anderes als Pointer. Fakt ist aber, dass du sie nicht als Pointer verwendest. Das macht C# eben schon automatisch für dich. Für dich als Programmierer hingegen gibt es in C# in der Nutzung erstmal keinen Unterschied zwischen Reference-Typen und Value-Typen, die werden alle wie letzterer verwendet. Was ich damit sagen will: Wenn du beispielsweise eine Funktion mit Parametern schreibst, macht es für dich keinen Unterschied, ob du einen int übergibst oder eine Klasse. C# wählt automatisch die bestmögliche Option für dich. In C++ hingegen müsstest du selbst entscheiden, ob du die Klasse lieber als Daten oder als Referenz übergibst.Zitat:
Zitat von Whiz-zarD
Auch das alles hat natürlich nicht nur gute Seiten. Ein Problem hiervon ist zum Beispiel, dass du an die Vorgaben von C# gebunden bist. So kannst du beispielsweise einen int niemals als Referenztyp und eine Klasse niemals als Valuetyp übergeben. Das ist zwar nur in den seltensten Fällen überhaupt nötig, aber durchaus nicht komplett ausgeschlossen. Zumindest der erste Fall. Um das in C# hinzukriegen musst du schon einen Umweg gehen und den Valuetyp irgendwie extra in eine Klasse packen. Und das ist eben genau das, was ich meine. Wirklich mit Pointern arbeiten tust du in C# eigentlich nur in Unmanaged Code. Ansonsten tut C# das automatisch und es kann dir egal sein, ob da gerade Pointer verwendet werden oder nicht. Eben auch wegen der automatischen Speicherverwaltung und so.
Deswegen "Altsysteme". Ich tue mir das in der Uni auch grad an und kann daher gut mit dir mitfühlen auch wenn es bei uns nicht so schlimm ist.Zitat:
Zitat von Whiz-zarD
Das fasst meine Meinung über XNA gut zusammen. Es stellt sich zwar mächtig hin, versagt aber bei den kleinen Sachen (Versuch mal ordentlich Primitves zu zeichnen...). Ich weiß jetzt nicht wie MonoGame ist und kenne auch nur ein Game damit (Bastion), aber das ist Open Source und daher würde ich nie das tote XNA empfehlen.Zitat:
Zitat von RPG Hacker
In XNA kannst du eine Textur nicht stretchen? Das glaub ich irgendwie nicht :o Also wenn der Laser eine komplizierte horizontale Animation hat sondern einfach nur ein Streifen, hätte es auch ein Strech getan denke ich. Ich dachte immer RenderTargets sind einfach nur FrameBuffer. Das man da soviel kaputt machen kann wusste ich nicht (also, das die engine Entwickler offenbar da Probleme hatten.).Zitat:
Eine andere Sache, die mir in XNA nicht gefällt, ist dass es viele Sachen komplizierter macht als nötig. Zur Erläuterung: In unserem Spiel gibt es einen Laser, der Ray-Tracing verwendet und genau bis zur nächsten Wand fliegt. Zur Darstellung verwenden wir Tiles, die wir x-mal wiederholen. Nun dachten wir uns, dass es vielleicht einen ganz guten Effekt gäbe, wenn wir den Laser per Add-Blending darstellen. War auch an und für sich keine schlechte Idee, nur haben die Tiles sich an den Übergängen überlappt (was in XNA sonst kaum anders lösbar wäre aufgrund gewisesr Eigenschaften), was bei Add-Blend natürlich bedeutet, dass an dieser Stelle doppelt addiert wird und man Übergangskanten hat. Schön und gut dachte ich mir. Zeichne ich den Laser einfach vorher per Alpha-Blend auf einen Buffer und dann von da per Add-Blend auf den Bildschirm. Aber nein, Pustekuchen. Das einzige, was ich dafür hätte verwenden können, sind RenderTargets. Und die sind einfach so ziemlich das schlimmste, was es in XNA gibt. Jeder, der damit schonmal gearbeitet hat, kennt sicher das Problem mit der lilanen Farbe im Hintergrund. Ich schwöre: Ich habe ein paar Stunden lang gegoogelt und diverse als funktionierend abgestempelte Methoden teilweise eins zu eins übernommen. Ich habe es einfach nicht geschafft, die Farbe rauszukriegen. In anderen Libraries, beispielsweise Allegro, hätte ich an diesem Problem vielleicht fünf Minuten gesessen.
Naja für simple pixelbasirende Spiele wird es gehen. Auch für simples 3D. Siehe Terraria oder Secret of Grindea.Zitat:
Also wie gesagt: XNA ist schon ein nettes Framework für den Einstieg in eine eigene Engine, weil es einem viel Arbeit schon abnimmt, aber für ein wirklich ernsthaftes Projekt, für das ich etwas mehr Zeit hätte, würde ich es nicht verwenden wollen.
Ich meine Pointer zeigen auf nichts oder? Aber eine Referenz zeigt doch auf etwas selbst wenn man nichts darauf verweißt. Zumindest ist das in Java so.Zitat:
Klar. Habe ich denn was anderes behauptet? Ich bin ja nicht auf den Kopf gefallen. Natürlich sind Referenzen in C# nichts anderes als Pointer.
Doch, es gibt einen gravierenden Unterschied. Wertetypen werden im Stack alloziert und wird durch einen sog. Stack Pointer direkt vom Prozessor unterstützt.Zitat:
Zitat von RPG Hacker
Referenztypen hingegen werden im Heap alloziert. Das allozieren muss man explizit mit dem new-Schlüsselwort einleiten, ansonsten hat man hier einen Null-Pointer. Wertetypen hingegen können nicht null als Wert besitzen. Wer sowas braucht, der muss Wrapper-Klassen benutzen. Unter C# wäre dies z.B. int?. Das Fragezeichen deutet darauf hin, dass sich um eine Wrapper-Klasse von einem Wertetyp handelt.
Ein weiterer Unterschied ist der Pointer selbst:
Hier haben wir zwei unabhängige Wertetypen, die jeweils den Wert 5 besitzen.Code:int a = 5;
int b = a;
Hier zeigen beide Referenztypen auf das selbe Objekt, und es ist auch egal, ob ich circle1 oder circle2 nehme.Code:Circle cirlce1 = new Cirlce();
Circle circle2 = circle1;
Beide Code-Abschnitte machen im Prinzip das selbe, wir deklarieren zwei Variablen, eine Initialisieren wir und der zweiten übergeben wir dem Wert der ersten Variable, aber wir haben hier zwei unterschiedliche Ergebnisse.
Im ersten Beispiel übergeben wir den Wert und im zweiten Beispiel die Referenz.
Soll heißen: Nur weil man nicht explizit mit Pointern arbeitet, heißt es ja lange nicht, dass es keine Pointer mehr gibt, und der letzte zitierte Satz:
Zeigt, dass du die Pointer nicht so ganz verstanden hast, denn das tust du unter C# auch. Nur ist die Syntax in C# nicht ganz so kryptisch, wie bei C/C++.Zitat:
In C++ hingegen müsstest du selbst entscheiden, ob du die Klasse lieber als Daten oder als Referenz übergibst.
Auch bei C# musst du entscheiden, ob du einen Werteparameter (Call-by-Value), oder einen Referenzparameter (Call-by-Reference) an eine Methode übergeben möchtest.
Machts für dich keinen Unterschied mit einer Kopie oder dem Original zu arbeiten? Nie?Zitat:
Zitat von RPG Hacker
Ref: http://msdn.microsoft.com/de-de/libr...=VS.80%29.aspxZitat:
Zitat von RPG Hacker
Out: http://msdn.microsoft.com/de-de/libr...=vs.80%29.aspx
Nicht die empfohlenste Art in C# mit Parametern zu hantieren aber ganz praktisch.
Mach einen Clon O_o , es gibt Klassen, die akzeptieren ihre eigene Art im Konstruktor, wenn man es denn unbedingt einfach haben will, oder man schreibs sich selber kurz.Zitat:
Zitat von RPG Hacker
Wenn das Ding eh nur Daten speichern soll mach 'n Struct draus.
Ach, da hätte ich noch was vergessen:
b1 vergleicht die Werte. b2 und b3 vergleichen allerdings die Referenzen.Code:int a = 5;
int b = 5;
Circle c1 = new Circle();
c1.Radius = 10;
Circle c2 = new Circle();
c2.Radius = 10;
Circle c3 = c1;
boolean b1 = a == b; // ergibt True
boolean b2 = c1 == c2, // ergibt False
boolean b3 = c1 == c3; // ergibt True
Auch hier wird deutlich, dass wir mit Pointern arbeiten. Wer c1 und c2 vergleichen möchte, muss die Equals()-Methode verwenden, und ggf. sogar die Equals()-Methode oder den Vergleichsoperator überschreiben.
Wie Corti schon sagt:Zitat:
Zitat von RPG Hacker
Im ersten Fall gibt es die Schlüsselwörter ref und out.
Im zweiten Fall gibt es die Structs, die nämlich im Stack alloziert werden und somit als Wertetypen gelten.
Structs sind aber ein Überbleibsel aus der strukturellen Programmierung. Klassen sind im Prinzip eine Erweiterung der Structs. In dieser Hinsicht ist C# nicht ganz konsequent. Es kann aber durchaus Sinnvoll sein, unter C# Structs zu verwenden, weil hier der Overhead deutlich geringer ist. Wer also viele Objekte auf einmal erzeugen muss, die nur Daten bereitstellen, kann mit Structs ein wenig Performance rausholen, aber C# ist hier eine Ausnahme. Z.B. unter Java gibt es für beide Fälle keine Lösung.
C# sucht keine Option aus. C# erzeugt eine Kopie. Entweder eine Kopie des Wertetyps, oder eine Kopie der Referenz, je nachdem um was für ein Typ es sich handelt.Zitat:
Zitat von RPG Hacker
Natürlich geht das. Weiß nur nicht, ob das auch noch so gut funktioniert, wenn du den Laser rotierst (du gibst bei der Skalierung X- und Y-Skalierung an). Vor allen Dingen aber wollten wir eben keinen langweiligen Laser, der einfach nur aus einem Strahl besteht. Wir wollten schon ein bisschen mehr Struktur reinbringen.Zitat:
Zitat von R.D.
Was ich nie auch nur ansatzweise behauptet habe.Zitat:
Zitat von Whiz-zarD
Sei mal nicht so arrogant. Das unterstreicht nur die Vorurteile, die man ohnehin schon gegenüber Programmierern hat. Ich verstehe echt nicht, warum 95% der Programmierer so verdammt arrogant sein müssen. Bloß, weil ich mich anders ausdrücke, als du, heißt das noch lange nicht, dass ich etwas nicht verstehe. Ich programmiere nun immerhin auch schon seit gut fünf Jahren und das zwar bisher noch nicht für ein Unternehmen, aber immerhin schon in den verschiedensten Programmiersprachen, darunter sogar ASM für das SNES. Und da es im guten alten Turbo Pascal noch nicht so Datentypen wie Listen oder Vektoren gab, habe ich selbst verständlich auch schon mit selbst programmierten, dynamisch verlinkten Listen gearbeitet. Zu behaupten, ich würde Pointer nicht verstehen, ist hier also pure Arroganz, bloß weil ich anderer Ansicht bin, als du (oder denselben Standpunkt anders darstelle). Komm mal von deinem hohen Ross runter, du göttlicher Super-Programmierer!Zitat:
Zitat von Whiz-zarD
Faktisch tatsächlich eher selten. Kann mich bisher eigentlich nur an einen Fall erinnern, wo ich mal die Kopie einer Klasse brauchte. Und da hätte ich theoretisch auch mit dem Original arbeiten können. Generell ist es eben einfach so, dass man Klassen meistens als Referenzen und andere Sachen meistens nur als Wert braucht. Das Standardverhalten ist in C# ja nicht grundlos so definiert. In 90% der Fälle ist das eben genau das, was man braucht.Zitat:
Zitat von Corti
Naja, ich habe da tatsächlich etwas ganz anderes gemeint, als ich gesagt habe. Was ich meinte war, dass du beispielsweise in einer Klasse nicht ohne Umwege eine Referenz auf einen Wertetyp deklarieren kannst. Also dass du beispielsweise in einer Klasse eine Eigenschaft namens intPointer hast, die auf einen int zeigt. Dafür müsstest du dann erst einen Wrapper oder so verwenden. In C++ (oder Unmanaged Code) könntest du ja einfach int* nehmen.Zitat:
Zitat von Corti
Ja, das ist auch nicht unbedingt das beste Beispiel. Der umgekehrte Fall, einen Wertetyp als Referenz zu verwenden, ist eh wahrscheinlicher.Zitat:
Zitat von Corti
Das ist doch überhaupt nicht der Punkt. Rede ich denn gegen eine Wand? Alles, was ich sage, ist dass der Unterschied zwischen Referenztypen und Wertetypen in C# einfach in 90% der Fälle für den Programmierer egal ist. Natürlich gibt es da Unterschiede, natürlich wird da mit Pointern gearbeitet, natürlich gibt es Ausnahmen. In 90% der Fälle - so war es zumindest bei mir bisher - arbeitet C# aber immer genau so, wie du es gerade erwartest bzw. brauchst. Das liegt eben auch daran, dass C# eben automatische Speicherverwaltung hat. Wenn du in C++ eine Funktion nimmst und ihr einen Pointer übergibst, musst du dir anschließend oft sagen "so, und jetzt nach der Funktion bloß nicht vergessen, den Speicher wieder freizugeben". In dieser Hinsicht unterscheiden sich in C++ Pointer stark von Wertetypen, denn Wertetypen musst du nie manuell freigeben. In C# hingegen musst du ja so gut wie nie Speicher manuell freigeben. Dadurch verschwimmen die Grenzen zwischen Referenztyp und Wertetyp in der Anwendung. Du musst dir nie erst sagen "Ach ja, das ist ja eine Referenz, also bloß nicht vergessen, den Speicher wieder freizugeben", sondern kann sie ähnlich, wie Wertetypen verwenden. Das ist doch wirklich alles, was ich damit habe sagen wollen. War das nun wirklich so schwer zu verstehen und diese ganze Diskussion wert? Mann, Mann, Mann...Zitat:
Zitat von Whiz-zarD
Ich bin nicht arrogant. Anstatt die Fehler bei den anderen zu suchen, solltest du dich vielleicht mal fragen, warum du so empfindest, dass 95% der Programmierer arrogant seien.Zitat:
Zitat von RPG Hacker
Es liegt einfach nur daran, dass du missverständliche Dinge von dir gibst, die ein Programmierer für falsch ansieht und dich lediglich korrigiert. Dein jetziger Beitrag ist auch wieder voller falschen Aussagen. Das fängt schon damit an, dass du den Gabage Collector und Pointer in einen Pott schmeißt. Auch in C/C++ kannst du ohne weiteres einen Garbage Collector implementieren.
Genau das meine ich doch mit arrogant. Anstatt mich einfach nur sachlich auf die Fehler hinzuweisen (natürlich habe ich keine perfekte Ausdrucksweise und natürlich ist nicht alles, was ich sage, 100%ig korrekt - immerhin beginne ich gerade erst mit dem Studium und habe zuvor fast nur als Hobby programmiert) musst du mir natürlich noch unter die Nase reiben, WIE falsch ja alles sei, was ich sage, und wie viel besser du es wüsstest. Es ist schon ein deutlicher Unterschied, ob man sagt "Das ist so nicht ganz richtig. Tatsächlich gibt es da dieses und jenes.", oder ob man sagt "Das, was du gesagt hast, ist ja mal alles sowas von falsch und zeigt, dass du offensichtlich überhaupt keine Ahnung vom Programmieren hast". Ja, ich weiß, so krass hast du es nicht ausgedrückt. Aber ungefähr so kam es zumindest bei mir rüber. Mir ist klar, dass du deutlich mehr Erfahrung in der Programmierung hast, als ich und ich auch manchmal unbewusst Blödsinn verzapfe. Aber kannst du nicht versuchen, mich sachlich darauf hinzuweisen, anstatt dich als überlegen und mich als Idioten darzustellen? Und dass 95% der Programmierer auf mich arrogant wirken liegt sicher nicht daran, dass ich überhaupt etwas falsches sage, es liegt eher daran, dass diese 95% der Programmier so scheiße darauf reagieren, wenn mal jemand etwas falsches sagt. Ich kenne durchaus auch einige Programmierer, die deutlich besser sind als ich und mit denen ich mich trotzdem super verstehe, weil sie ihre Erfahrung vermitteln können, ohne dabei mit ihrer Überlegenheit zu prahlen. Und gleichzeitig bestätigt gerade mein Studium aber, dass es eben auch diverse Programmierer gibt, die gar nicht anders können, als mit ihrer Überlegenheit (oder gar Pseudo-Überlegenheit) zu prahlen. Zwar sind wir insgesamt nur 7 Programmierer im Jahrgang und davon nur 4 in meinem Kurs, aber gerade bei der geringen Menge fällt jeder eben umso mehr auf. So hat mich beispielsweise in der allerersten Woche ein Kollege total in den Boden geflamed, bloß weil ich gesagt habe - und ich zitiere - "Ach, Free Pascal ist gar nicht sooo schlecht". Daraufhin entbrannte eine Riesen-Diskussion und er wollte mir unbedingt unter die Nase reiben, dass Free Pascal scheiße und C++ das Tollste sei. Und auf meine Argumente, dass Free Pascal durchaus auch einige Vorteile gegenüer C++ biete, reagierte er nur umso bestürzter und war nichtmal mehr in der Lage, eine objektive Diskussion zu führen. Und das ist nun wirklich nicht der erste Fall, in dem irgendein Programmierer mir seine Überlegenheit reindrücken wollte und das wegen einer total unwichtigen und kleinen Sache. Also tut mir Leid, wenn ich in dieser Hinsicht überempfindlich reagiere, aber sowas kotzt mich einfach an und meine Erfahrung zeigt mir, dass an meiner Behauptung (mit den 95%) durchaus ein Fünkchen Wahrheit dran ist.
Oh man, ich hatte in meinem Informatik-Studium ebenso eine Erfahrung gemacht. Man hat echt das Gefühl, die meisten Informatiker wären sozial völlig inkompetente, autistisch anmutende Fachidioten. ;D
Ich dachte, ich hätte nur eine besonders schlechte Erfahrung gemacht, aber anscheinend geht es anderen auch so *g*
Ich bin ja selbst nicht der sozial kompetenteste, aber zumindest bemühe ich mich darum. :P
@RPG Hacker:
Nimm bitte nicht alles so persönlich. Wenn man über Sachen spricht kanns vorkommen, dass man im (Streit-)Gespräch feststellt, dass man irgendwo Wissenslücken hat oder Sachen falsch weiss. Das liegt daran, dass man nicht alles wissen kann, man mal Sachen falsch versteht, oder man Sachen einfach falsch vermittelt bekam. Normalstes Ding auf der Welt, dann kriegt man halt ein Update und weiss danach mehr.
Da z.B. Whiz-zarD dich nicht persönlich kennt und in deine Gedanken blicken kann woher soll er da wissen, ob du Sachen wirklich schon verstanden hast und nur so formulierst als wär es nicht der Fall oder ob du sie nicht verstehst? Deine Formulierungen sagen eindeutig aus, dass dir bei Pointern etwas Verständnis fehlt, du kannst in dem Fall nicht erwarten, dass er eine Information verarbeitet, die er nicht hat. Zu sagen "Ich habe Pointer verstanden - gefolgt von einer fachlich falschen Erklärung" ist keine Information, die eindeutig beinhaltet, dass du sie verstanden hättest, es ist eine Information, die primär beinhaltet, dass das Gegenteil der Fall ist mit einer geringen Chance, dass die Formulierung misslungen ist, der Inhalt aber stimmt.
Was erwartest du also? Dass man das liest und denkt "ah, nicht ganz richtig, aber das ist RPG Hacker, der wurde in seinem Leben so oft von Programmierern niedergemacht, den verbesser ich lieber nicht, der nimmt das nur wieder persönlich und fühlt sich niedergemacht"~ okey man hat gelegentlich Leute im Forum von denen man weiss, dass jede Minute des Schreibens vergebens ist weil sies eh nicht checken wolle und werden und nur rumweinen, aber zu denen zähle ich dich nicht und dazu gehören willst du sicherlich auch nicht.
Zwei Dinge:
- Wenn dir jemand etwas vermittelt, dass du nicht (so gut, ausreichend, ganz genau) wusstest, sieh es nicht als Verletzung deiner Programmiererehre sondern nimms souverän, du hast dann gerade was gelernt. Gut!
- Die Sprachendebatte ist hinfällig: Auch wenn C++ in allen fachlichen Dingen >>>>>>>> FreePascal, für einfache Dinge tuts die einfachste Sprache. Tada, Thema durch. Programmiersprachen sind keine Religionen, man kann durchaus mehrere haben, können, benutzen und mögen und man muss die Ungläubigen nicht abschlachten oder bekehren ;-)
Ich versuche mich an deinen Rat zu halten. ;)
Und ja, du hast Recht. Ich habe durchaus ein wenig überreagiert. Gewisse Formulierungen kamen mir eben mehr als Überheblichkeit und weniger als einfache Verbesserungen rüber. Aber gut, genauso wie Whiz-zarD mich noch nicht so gut kennt, kenne ich ihn natürlich auch noch nicht so gut. Deswegen tut es mir Leid, falls ich mit meinen Behauptungen daneben gelegen habe.