Soll ich mit C# oder mit C++ anfangen?

[Blue-Tiger]

ja damit gehts. Was du sonst noch brauchst findest du in jedem guten C# Lehrbuch

[Blue-Tiger]

Phill schrieb:

Bei mir kommt ein Fehler: Microsoft .NET Framework 1.1 was not found on this system.

das .NET Framework bekommst du unter downloads.microsoft.com

[guenni81]

aber denk daran, dass du auch das .NET Framework SDK brauchst.

[Phill]

Also ich habe erstmal das normale Framework 1.1.
So ein Buch werde ich erst später kaufen können nun kommt die Frage ob jmd. ein wirklich gutes Tutorial kennt was mit C# anfängt von Anfang an.
Und das C# Sharp IDE da hab ich jetzt auch auf meinem PC

mfg Phill

[Noodles]

http://www.galileocomputing.de/openbook/csharp/

[Phill]

Also und dieses Tutorial ist wirklich gut für den Anfang?

mfg Phill

[Aussenseiter]

Schaust einfach mal, was man so in der MSDN zu
Eric Gunnerson (der Autor dieses Buches) findet.

Ergebnisse

Du darfst also mal annehmen, dass er weiß wovon er redet.

Falls du aber meinst, dass das Buch eventuell zu kompliziert für den Anfang ist, darf ich dich beruhigen, wobei du es trotzdem mehrmals lesen solltest, vor allem
wenn du noch nicht weiß was objektorientiert ist. Damit konfrontiert er dich in
dem Buch relativ früh, was eventuell beim 2. oder 3. Durchgang sehr viel klarer
wird.

grüße,
ein Aussenseiter

[dreaddy]

Wird C# eigentlich inzwischen auch mal von wem genutzt ausser zum lernen und rumspielen?
Ich überleg auch ob ich da smal lerne, aber Microsofts vor Jahren angekündigten Träume und Ankündigungen bezüglich .net sehe ich bis heute nicht in die Tat umgesetzt... deswegen frage ich mich schon ob es sich überhaupt lohnt.

[Script-Kiddie]

dreaddy schrieb:

Wird C# eigentlich inzwischen auch mal von wem genutzt ausser zum lernen und rumspielen?

Ich weiß nicht, ob es heute bereits so stimmt, aber z.B: würde ich mal sagen,
dass Novell zu ner Firma für C# werden könnte, wie es imo IBM für Java ist.

Bisher hab ich in der Tat kein kommerzielles Programm gesehen - ausser von Microsoft eben, wäre das aber
nicht würde ich von C# die Finger lassen - das auf C# basiert. Wobei ich fast nur OpenSource verwende, und
auch noch nicht mit einem kommerz. Java Programm zu tun hatte (wobei es die natürlich geben wird).
Soll also nichts heißen ..

Außerdem ist zum Beispiel die .NET 1.0 Version erst am 27. März, 2002 schienen, vorher war es nur eine
Beta-Version (mit Sicherheit kann ich das nicht sagen, dazu programmiere ich noch nicht lang genug C#).
Vielleicht waren die 3 Jahre also nicht lang genug für manche ihre Programme umzuschreiben.

Aber .NET ist ja nicht nur ein Programmier-Framework sondern ein Lösungsansatz für Probleme wie DLL-Hells,
Kopieren von Programmen nicht möglich - sondern nur dort auch installieren, etc.. Ich sag Lösungsansatz
deswegen, weil es eben noch nicht konsequent durchgesetzt wurde, immerhin werden ja noch
normale WinAPI-, bzw. MFC-Programme erlaubt.

Wie einer meiner Lehrer aber bereits gesagt hat, der Abbruch von MFC, wird wohl viele Firmen abgeschreckt haben,
die in Java solche Stimmungsschwankungen nicht befürchten. Ich sag also mal, wäre C# vor Java rausgekommen,
sähe alles ganz anders aus, aber sowas kann man im Nachhinein immer behaupten

Ich sag mal so, verinzelt erblickt man zwar ein oder zwei Jobangebote für C# Programmierer. Aber ich seh selbst
als eingefleischter C#-Programmierer ein, dass am zur Zeit hauptsächlich Angebote als Java-Programmierer finden
wird. Auch die Universitäten werden wohl fest in den Händen von Java bleiben, überlegen muss man sich es also wohl
schon.

grüße,
ein Script-Kiddie

[DEvent]

als sprache ist c# super, das .net framework kenn ich nicht.
hab aber mit managed directx ein bischen rumgespielt und da ist es weitaus einfacher komplexe programme zu schreiben als im normalen dx. 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. das hat mich bei managed dx so gestört wieso ich nicht einfach einen Mesh von M$ nehme und für meine zwecke spezialisieren kann.
achja das andere was mich an c# stört ist die fehlende mehrfache vererbung. naja aber da streiten sich die leute ja ob mehrfachvererbung überhaupt sinnvoll ist....

(wobei es die natürlich geben wird).

die wird es nicht geben, es gibt jetzt schon haufenweise komerz java-programme.

[Shade Of Mine]

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.

[net 0]

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'.

[Aussenseiter]

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

[DEvent]

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).

[Shade Of Mine]

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= dafuer

man 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...

[Phill]

Also sollte ich eurer Meinung nach mit C# anfangen oder habe ich das jetzt falsch verstanden?

mfg Phill

[Gast]

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.

[net 0]

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.

[DEvent]

stimmt alleine wegen dem eingebauten garbage container ist java, c# um einiges einfacher. aber man sollte doch eher mit c++ anfangen IMHO.

[Michael E.]

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= dafuer

Wer kommt denn auch da auf die Idee zu vererben?