Soll ich mit C# oder mit C++ anfangen?
-
DEvent schrieb:
das einzige was mich an c# stört ist das sealed-schlüsselwort.
imho ist das direkt gegen objektorientierung. denn eins der vorteile davon ist ja, dass man klassen durch vererbung spezialisiert. und woher nehmt sich jemand dann das recht zu sagen, das diese klasse sozusagen "perfekt" ist.In C++ geht das indem man den dtor nicht virtual macht
da man von value typen sowieso nicht ableiten sollte, weil es technisch viele probleme aufwirft, kommt es oft vor, dass du eine klasse sealst. Genauso wie du eine Methode 'sealst' in dem du sie nicht virtual machst.
-
Shade Of Mine schrieb:
DEvent schrieb:
das einzige was mich an c# stört ist das sealed-schlüsselwort.
imho ist das direkt gegen objektorientierung. denn eins der vorteile davon ist ja, dass man klassen durch vererbung spezialisiert. und woher nehmt sich jemand dann das recht zu sagen, das diese klasse sozusagen "perfekt" ist.In C++ geht das indem man den dtor nicht virtual macht
damit kannste doch keine ableitungen verhindern wie mit 'sealed'.
-
die wird es nicht geben, es gibt jetzt schon haufenweise komerz java-programme.
War vielleicht ungünstig ausgedrückt, aber ich bezog mich mit dieser Annahme auch auf die Gegenwart, ich kenne halt
keine, hab aber eben schon oft davon gehört (hör immerhin nur "haufenweis", aber nicht welche, glaubs ja trotzdem,
nur kann ich dann selbst keine auflisten).imho ist das direkt gegen objektorientierung. denn eins der vorteile davon ist ja, dass man klassen durch vererbung spezialisiert. und woher nehmt sich jemand dann das recht zu sagen, das diese klasse sozusagen "perfekt" ist.
Es geht nicht darum zu sagen, die Klasse sei perfekt, sondern eventuell um "die Klasse hantiert höchst sensibel
mit Daten und bei der kleinsten Veränderung läuft garantiert was schief".Ich hab jetzt grad kein passendes Beispiel zur Hand, darum repräsentiert meins jetzt nur den Sinn, nicht aber
die Dramatik .. (ausserdem ist es natürlich relativ schwachsinnig ..)public interface IRunnable { // ... void Run(); void Stop(); } public class Thread : IRunnable { public void Run() { // hier werden irgendwelche Handles angefordert, es // wird eben mit WinAPI gearbeitet .. Console.WriteLine("Thread.Run()"); } public void Stop() { // hier werden dann halt irgendwelche Handles befreit, also // ebenfalls wieder WinAPI .. Console.WriteLine("Thread.Stop()"); } } public class PersonalThread : Thread, IRunnable { public new void Run() { // hier wird jetzt etwas anderes verwendet, zum Beispiel // lässt man, die Methode einfach asynchron ausführen // wie gesagt, ergibt keinen Sinn .. Console.WriteLine("PersonalThread.Run()"); } // Stop definieren wir nicht neu, wir sind einfach dumm und // der Compiler schreibt es auch nicht vor .. } class App { public static void RunThread(IRunnable runnable) { runnable.Run(); runnable.Stop(); } public static void Main() { RunThread(new Thread()); RunThread(new PersonalThread()); } }
In diesem Beispiel, kann man natürlich noch einfach die korrekte Ausführung garantieren (einfach nur Stop auch
neu definieren), aber normalerweise sind Klassen auch ein wenig komplexer ..Man kann sich dann einfach als "Autor" der Klasse Thread auf nichts mehr verlassen (die Methoden sind
nichtmal virtual deklariert). So kann man kritische Ressourcen nicht mehr auf mehrere Methoden verteilen, da
sie vielleicht später nicht mehr zusammenarbeiten. All diese Problematik erspart man sich, wenn man eine
Klasse versiegelt.Es gibt unzählige andere Beispiele (ich denke dabei zum Beispiel an einen String mit lazy evaluation), die
schlicht und einfach ohne sealed nicht möglich sind. Selbst wenn alle Methoden nicht-virtual sind, und keine
Interfaces implementiert werden, bleibt immer noch new mit dem man zumindest
verdecken kann.Warum gibts bloß immer solche Diskussionen um sealed, die Funktionalität gabs doch in Java (final) und
C++ (boost::sealed) auch bereits und da hat es sich doch auch bereits bewährt ..grüße,
ein Aussenseiter
-
dann soll man doch einfach in die doku reinschreiben wer davon eine klasse ableitet sollte dies und jenes beachten. oder sagen das man davon keine ableitungen machen soll.
man kann auch ableiten um neue methoden einzufügen, die man dann fast unabhängig von der basisklasse benutzen kann.
ich finds immer besser wenn man so wenig einschränkungen wie möglich hat. wenn man so ein misst macht ( zB von klasse ableiten, die kein virtual dtor hat ) dann hat man eben den salat.
und welche klassen sind bei java schon final? ich hab zumindest noch keine gesehen ( hantiere mit swing meistens ). bei dem .net framework ist fast jede klasse sealed (zumindest bei managed dx).
-
net schrieb:
damit kannste doch keine ableitungen verhindern wie mit 'sealed'.
es ist effektiv verhindert, weil man das objekt nicht polymorph verwenden kann.
DEvent schrieb:
dann soll man doch einfach in die doku reinschreiben wer davon eine klasse ableitet sollte dies und jenes beachten. oder sagen das man davon keine ableitungen machen soll.
Ja und was spricht dagegen dass in den Code zu schreiben?
Schau dir C++ an: kein virtueller Dtor und schon ist das ableiten eine qual, also lieber layering.
du hast sowieso grosse probleme wenn du von bestimmten typen ableitest:
nimm als beispiel mal einen String. Nun willst du davon einen NonCaseString ableiten der nicht auf gross/klein schreibung achtet.
klingt gut?
falsch, ist eine katastrophe:
denn definiere mal den op== und op= dafuerman sealed oft klassen durch das design. un in C# und Java geht man eben von dem gedanken aus: der programmierer soll so wenig fehler wie moeglich machen koennen. da ist ein sealed praktisch.
ich finds immer besser wenn man so wenig einschränkungen wie möglich hat. wenn man so ein misst macht ( zB von klasse ableiten, die kein virtual dtor hat ) dann hat man eben den salat.
Mag sein dass du das gut findest, und dass du es so bevorzugst, aber gegen den OO Gedanken wiederspricht ein sealed trotzdem nicht.
und welche klassen sind bei java schon final? ich hab zumindest noch keine gesehen ( hantiere mit swing meistens ). bei dem .net framework ist fast jede klasse sealed (zumindest bei managed dx).
und? nur weil in Java sealed weniger oft verwendet wird, ist es dort ok?
ich habe eher das gefuehl du leitest viel zu oft ab. ich erbe quasi nie, meine klassen hierachien sind kaum 3 ebenen tief. idR wird von garnichts abgeleitet...
-
Also sollte ich eurer Meinung nach mit C# anfangen oder habe ich das jetzt falsch verstanden?
mfg Phill
-
Phill schrieb:
Also sollte ich eurer Meinung nach mit C# anfangen oder habe ich das jetzt falsch verstanden?
Meiner Meinung nach nicht. *g*
Sorry, will dich nicht noch weiter verwirren, aber mit dieser Frage haben einige Programmierer zu ringen, ob sie umsteigen, oder nicht.Ich persönlich sehe es so, dass C++ eigentlich die solidere Wissensbasis ist und sollte die Relevanz von C# mal deutlich über 50% steigen, dann ist der Umstieg auch nicht SO schwer.
Ich schätze eine spätere Umgewöhnung von C# auf C++ als schwieriger ein.Aber halt nur meine Meinung.
-
SeppSchrot schrieb:
Ich schätze eine spätere Umgewöhnung von C# auf C++ als schwieriger ein.
ist ja auch so. c++ ist um einiges komplexer als c# und java. das ist auch einer der gründe warum diese sprachen erfunden wurden. selbst bei den c++ compilern gibt es keinen, der 100% c++ kann.
-
stimmt alleine wegen dem eingebauten garbage container ist java, c# um einiges einfacher. aber man sollte doch eher mit c++ anfangen IMHO.
-
Shade Of Mine schrieb:
nimm als beispiel mal einen String. Nun willst du davon einen NonCaseString ableiten der nicht auf gross/klein schreibung achtet.
klingt gut?
falsch, ist eine katastrophe:
denn definiere mal den op== und op= dafuerWer kommt denn auch da auf die Idee zu vererben?
-
Ok aber wo gibt es einen Kostenlosen C++ Editor?
mfg phill
-
- Du willst nur Klassenkamerade beeindrucken mit deinem Programm ?
-> C# ist deine Wahl - Du willst das ganze professionell durchziehen ?
-> Fang mit C++ an, eigne dir einen vernünftigen Stil an und guck dir nach einem
Jahr oder auch zwei C# an. - Du willst eher ein Hobbyprogrammierer werden ?
-> Nimm sofort die Sprache deiner Wahl, und kümmer dich erstmal nicht um die andre.
C# IDEs:
SharpDevelop
Visual C# 2005 Express Beta 1
Borland C# Builder Personal EditionC++ IDEs:
MinGW Studio 2.05
Visual C++ 2005 Express Beta 1
Bloodshed Dev-C++grüße,
ein Pokemon
- Du willst nur Klassenkamerade beeindrucken mit deinem Programm ?
-
Michael E. schrieb:
Wer kommt denn auch da auf die Idee zu vererben?
Was ist los mit euch?
Es macht ja eben _keinen_ sinn von einem value Typen zu erben. Darum geht es doch in meinem Posting!
Es ist aber verlockend fuer Anfaenger da zu erben. Wenn man da ein sealed macht, kann das einem Anfaenger nicht passieren und darum geht es in Java und C# ja -> ein Anfaenger darf keine Fehler machen koennen.
-
Shade Of Mine schrieb:
Wenn man da ein sealed macht, kann das einem Anfaenger nicht passieren und darum geht es in Java und C# ja -> ein Anfaenger darf keine Fehler machen koennen.
ein noob kann aber trotzdem klassen basteln von denen man keine sinnvollen ableitungen machen kann. wenn er kein 'sealed' oder 'final' verwendet (und noobs verwenden das auch nicht), helfen ihm java und c# auch nicht weiter.
btw: in c++ geht doch 'class B : public A' immer. da gibbets keine sealed/final -entsprechung. besser für noobs
oder geht das doch irgendwie?
-
So also für das Visual C++ 2005 brauche ich das Framework 2.0 hab ich aber nicht gesehen auch nicht bei Microsoft.
mfg Phill
-
Shade Of Mine schrieb:
du hast sowieso grosse probleme wenn du von bestimmten typen ableitest:
nimm als beispiel mal einen String. Nun willst du davon einen NonCaseString ableiten der nicht auf gross/klein schreibung achtet.
klingt gut?
nein, aber...
denn definiere mal den op== und op= dafuer
wo ist dabei denn das problem?
-
Phill schrieb:
So also für das Visual C++ 2005 brauche ich das Framework 2.0 hab ich aber nicht gesehen auch nicht bei Microsoft.
Dann such bitte nochmal!
Oder ist es wirklich so schwer bei google ".NET Framework 2.0" einzugeben?
-
Noodles schrieb:
Oder ist es wirklich so schwer bei google ".NET Framework 2.0" einzugeben?
ich glaub um den '.' in .NET schert sich google herzlich wenig, aber das sollte egal sein