mikrocontroller.net

Forum: PC-Programmierung Visual Studio 2010 - wurde IntelliSense raus geschmissen?


Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich programmiere grade was in Visual Studio 2010. Und zwar möchte ich 
mit Visual C++ eine Windows Forms Anwendung erstellen. Also habe ich fix 
ein Projekt erstellt und drauf los programmiert. Doch was muss ich 
feststellen? Es gibt kein IntelliSense mehr?!

Wenn ich eingebe System:: dann sollte automatisch schon das 
Dropdown-Feld kommen, wo dann die Members von System aufgelistet werden. 
Doch das geschieht nicht. Es erscheint lediglich in der Statuszeile die 
nüchterne Meldung: "IntelliSense not available for CLR". Was soll denn 
das?
In VS 2008 hat das jedenfalls funktioniert.
Mache ich was falsch, oder wurde IntelliSense wirklich raus geschmissen?

Autor: Thomas K. (tomthegeek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein da hast du leider Recht. Bei VS2010 gibts für Windows Forms kein 
Intellisense mehr. Für MFC allerdings schon noch.
Siehe: 
http://blog.kalmbach-software.de/de/2010/03/05/ccl...

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohje. Das ist ja völlig unbrauchbar. Woher soll man denn jetzt wissen, 
was für Member ein bestimmter Namespace oder eine Klasse hat? :-o
weisst du, ob es einen Grund gibt, warum das entfernt wurde? Es war 
eines der besten Features, die der Code-Editor hatte.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias Plüss schrieb:
> Ohje. Das ist ja völlig unbrauchbar.
> Woher soll man denn jetzt wissen,
> was für Member ein bestimmter Namespace oder eine Klasse hat? :-o
> weisst du, ob es einen Grund gibt, warum das entfernt wurde? Es war
> eines der besten Features, die der Code-Editor hatte.

Das Feature gibt es ja noch, nur nicht mehr für C++/CLI sondern nur für 
richtiges C++.

http://blogs.msdn.com/b/vcblog/archive/2009/05/27/...
"We completely empathize with the need to work with C++/CLI and we think 
it's a great way to do interop between native code and managed code. As 
part of this re-architecture, we had to make the difficult decision to 
reduce the scope to native C++ only for Intellisense. We still index 
symbols coming from C++/CLI code and you can browse them with Class View 
etc...

While the lack of Intellisense for C++/CLI is unfortunate, we expect 
that it only represents a small portion of your source code that you 
don't need to edit nearly as often as the native code. Indeed, the only 
scenario we don't recommend is to use C++/CLI as a first-class .NET 
language. Instead, we think it's the ideal solution for interop."

Autor: bluppdidupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guter Zeitpunkt direkt auf C# umzusteigen ;D

Autor: Winzigweich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias Plüss schrieb:
> Ohje. Das ist ja völlig unbrauchbar. Woher soll man denn jetzt wissen,
> was für Member ein bestimmter Namespace oder eine Klasse hat?

Vielleicht, indem man in der Dokumentation nach sieht? Früher mussten 
ganze Generationen von Programmierern ohne Intellisense auskommen und, 
oh Wunder, haben sogar funktionierende Programme geschrieben...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bluppdidupp schrieb:
> Guter Zeitpunkt direkt auf C# umzusteigen ;D

Vom Regen in die Traufe!
C# ist der letzte Dreck!
Ich bin auf qt umgestiegen und habe es nicht bereut.

Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> Ich bin auf qt umgestiegen...

Sorry, hab ne kurze Ja/Nein-Frage dazu:
Sind die einzelnen QT-Varianten kompatibel miteinander?
Also kann ich ein File, was in "QT for Windows" geschrieben ist, auch 
z.B. für "Qt for S60" benutzen, oder für S60 kompilieren?
Sozusagen Cross-Development?
Weiß das grad jemand?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim S. schrieb:
> Sorry, hab ne kurze Ja/Nein-Frage dazu:
> Sind die einzelnen QT-Varianten kompatibel miteinander?
> Also kann ich ein File, was in "QT for Windows" geschrieben ist, auch
> z.B. für "Qt for S60" benutzen, oder für S60 kompilieren?
> Sozusagen Cross-Development?
> Weiß das grad jemand?

Also ich habe bis jetzt eine Software entwickelt die haupsächlich auf 
einem Windows-Rechner läuft, und die lässt sich ohne Probleme auch für 
Linux, Embedded-Linux und Mac kompilieren.

Autor: Olaf Dreyer (Firma: O.D.I.S.) (dreyero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ja wenn Du nur Qt aufrufe tätigst, ist das kein Problem.
Ich erstelle gerade ein Projekt für Linux und Windows (ich weis kein 
S60) und der Platformabhängige Code ist wirklich minimal.

Gruß

Olaf

Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> und die lässt sich ohne Probleme auch für
> Linux, Embedded-Linux und Mac kompilieren

Mit einem einzigen Source-File? - Geil! Ich sehs auch grad. Gleich mal 
Downloaden!

Danke

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> C# ist der letzte Dreck!
> Ich bin auf qt umgestiegen und habe es nicht bereut.

Was soll den das heißen?

Ich kann auch sagen:
qt ist der letzte Dreck!
Aber dazu kann ich keine Stellung nehmen, da ich nie mit qt programmiert 
habe, höchstens mit Allegro.

Ich möchte mal wissen was du mit qt machen kannst und nicht mit c#?

Mit c# kann mal z.b mit XNA einfach 2D Spiele programmieren, mit MDX 
kann man auch 3D programmieren. Forms sind wunderbar einfach zu machen.

Und das beste warum ich Spiele lieber mit c# programmiere:

Wenn man einen Heapfehler bemerkt und dann seine 5000 Zeilen Code 
durchsuchen muss!

.NET ist auch plattformunabhängig, sofern man den Jitter für das 
jeweilige OS hat.

Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anwendungs- und Einsatz-Zweck ist doch das entscheindenste! Eigentlich 
ist alles der letzte dreck! Sorry - konnt mich net zurückhalten. ;-)

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Was soll den das heißen?

Samuel K. schrieb:
> Ich möchte mal wissen was du mit qt machen kannst und nicht mit c#?

-Wenn du Programme schreibst die du verkaufst solltest du das nicht mit 
C# machen, weil dann kannst du gleich deinen Quellcode veröffentlichen.
-Ein C# Programm wird erst zur Laufzeit vom .Net-Framework übersetzt und 
ausgeführt. Das macht den Programmstart ziemlich langsam.
-Für ein Mini-Tool ist das riesige .Net nötig.

Ich könnte die Liste noch fortführen.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> -Wenn du Programme schreibst die du verkaufst solltest du das nicht mit
> C# machen, weil dann kannst du gleich deinen Quellcode veröffentlichen.

Naja, es gibt ja genügend Tools, daraus einen unlerserlichen 
Spaghetti-Code ohne sinnvolle Namen usw. zu machen. Dann kann der 
geneigte Chinese ja mal versuchen, die Funktion zu errätseln.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Viele Programmierer schaffen das ohne Tools.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> Samuel K. schrieb:
>> Was soll den das heißen?
>
> Samuel K. schrieb:
>> Ich möchte mal wissen was du mit qt machen kannst und nicht mit c#?
>
> -Wenn du Programme schreibst die du verkaufst solltest du das nicht mit
> C# machen, weil dann kannst du gleich deinen Quellcode veröffentlichen.

Deshalb wird auch so viel mit Java entwickelt. Nicht nur in Firmen, 
sondern bspw. für Android. Anders gesagt: Selbst wenn, für 99.9% der 
Anwendungen ist das völlig irrelevant, da dort nichts interessantes drin 
steckt.

> -Ein C# Programm wird erst zur Laufzeit vom .Net-Framework übersetzt und
> ausgeführt.

Falsch, C#, VB, etc wird, wie Java, in Zwischencode übersetzt, der 
JIT-Compiler übersetzt diesen wiederum in Maschinencode. Zusätzlich 
gibt's mit ngen die Möglichkeit die Programme AOT in Maschinencode zu 
übersetzen.

> Das macht den Programmstart ziemlich langsam.

Wie alt ist/war das Testsystem

> -Für ein Mini-Tool ist das riesige .Net nötig.

Für alle Programme die das Framework benötigen wird dies einmalig 
installiert und nicht, wie es gerne Java- oder andere Programme machen, 
die eine eigene Variante ihres Lieblings-Frameworks mitinstallieren.

>
> Ich könnte die Liste noch fortführen.

Ich auch...

Autor: raketenfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das platzprobleme wegen .net ist immer noch das coolste!

-speicherplatz wird immer billiger
-downloads immer flotter
-usb, hdds auch immer flotter

so und jetzt kann man noch überlegen ob das ganze wirklich soviel mbs 
zieht??^^

bei einem .net programm vll doch nicht so gut, aber wenn es sich iwann 
summiert, merkt man das schon, ausserdem finde ich c# auch schön!

Autor: Karolina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Ich möchte mal wissen was du mit qt machen kannst und nicht mit c#?

Ofensichtlicht seinen Job. Er hat sich wenigstens umgeschaut und alles 
funktioniert nun.

> Mit c# kann mal z.b mit XNA einfach 2D Spiele programmieren, mit MDX
> kann man auch 3D programmieren. Forms sind wunderbar einfach zu machen.
>
> Und das beste warum ich Spiele lieber mit c# programmiere:
>

Blub Blub, Über Features kann sich jeder selbst informieren, wenn es 
denn nötig wäre.

> Wenn man einen Heapfehler bemerkt und dann seine 5000 Zeilen Code
> durchsuchen muss!

Der Heap kennt keine Fehler. Der Fehler bist dann du. Und wenn du dann 
deine 5000 Zeilen Code nicht kennst, dann hast du den falschen Job !

> .NET ist auch plattformunabhängig, sofern man den Jitter für das
> jeweilige OS hat.

LOL. Netter Joke !

Autor: puffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Viele Programmierer schaffen das ohne Tools.

Ja, vor allem viele C-Programmierer, die sich für besonders intelligent 
halten. :)

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohje, da hab ich wohl was losgetreten? :)

übrigens mag ich C# auch nicht. Das .NET Geraffel sagt mir auch nicht so 
zu, obwohl ich allerdings zugeben muss, dass es schon ganz praktisch zum 
programmieren ist. man kann sich schön einfach seine gewünschte 
Benutzeroberfläche zusammenklicken, und es ist wirklich einfach, dann 
was sinnvolles damit zu programmieren.
Allerdings stört es mich, wenn ich auch nur ein kleines Tool schreibe, 
dass dieses dann ein Framework von mehreren 10 MB benötigt, obwohl mein 
Tool selber nur aus einer 100 kB grossen EXE besteht.
Ausserdem ist .NET langsam, das stimmt.
Deshalb programmiere ich mit C++, und zwar ohne .NET, damit am Schluss 
Maschinencode rauskommt.

Autor: Winzigweich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias Plüss schrieb:
> Allerdings stört es mich, wenn ich auch nur ein kleines Tool schreibe,
> dass dieses dann ein Framework von mehreren 10 MB benötigt, obwohl mein
> Tool selber nur aus einer 100 kB großen EXE besteht.

Die Größe des Frameworks dazu zu rechnen ist aber eine 
Milchmädchenrechnung, da das Framework ja nur einmal für alle 
.NET-Anwendungen vorhanden sein muss und außerdem auf jedem halbwegs 
aktuell gehaltenen PC ohnehin bereits installiert sein sollte.

Tobias Plüss schrieb:
> Ausserdem ist .NET langsam, das stimmt.

Was bei den heutigen Prozessorgeschwindigkeiten aber sicherlich nicht 
für den Benutzer zu bemerken ist.

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.Net Code wird nach dem JIT wie Nativer C++ Code ausgeführt, und ist 
meist nicht langsamer als dieser.
Es gibt wenn man nur Windows Anwendungen braucht, einfach nix 
effektiveres zum Arbeiten.
Wenn ich mit C# + WPF eine Gui + funktionen gebaut habe, ist man mit c++ 
meist noch nicht eine Zeile für die GUI geschrieben.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias Plüss schrieb:
> ohje, da hab ich wohl was losgetreten? :)
>
> übrigens mag ich C# auch nicht. Das .NET Geraffel sagt mir auch nicht so
> zu, obwohl ich allerdings zugeben muss, dass es schon ganz praktisch zum
> programmieren ist. man kann sich schön einfach seine gewünschte
> Benutzeroberfläche zusammenklicken, und es ist wirklich einfach, dann
> was sinnvolles damit zu programmieren.
> Allerdings stört es mich, wenn ich auch nur ein kleines Tool schreibe,
> dass dieses dann ein Framework von mehreren 10 MB benötigt, obwohl mein
> Tool selber nur aus einer 100 kB grossen EXE besteht.
> Ausserdem ist .NET langsam, das stimmt.

http://www.youtube.com/watch?v=z4Rnrmm0MTI

> Deshalb programmiere ich mit C++, und zwar ohne .NET, damit am Schluss
> Maschinencode rauskommt.

Genau das machts du gerade nicht
> Und zwar möchte ich mit Visual C++ eine Windows Forms Anwendung
> erstellen.
und
> "IntelliSense not available for CLR"

Autor: Kixx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nu auch noch meinen Senf los werden will:

Sebastian___ schrieb:
> Wenn ich mit C# + WPF eine Gui + funktionen gebaut habe, ist man mit c++
> meist noch nicht eine Zeile für die GUI geschrieben.

Dir ist schon klar das in den IDE's für C++, egal welche Biblio. (ob MFC 
oder Qt) die GUI fast identisch "zusammengeklickt" werden kann wie in C#

Gruß Kixx

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kixx schrieb:
> Dir ist schon klar das in den IDE's für C++, egal welche Biblio. (ob MFC
> oder Qt) die GUI fast identisch "zusammengeklickt" werden kann wie in C#

ja, aber WPF ist doch ne andere geschichte.
Zumindest wenn man Databinding und Property Changed Trigger nutzt.
Um mit C++ ne hübsche GUI zu bauen bedarf es doch schon recht viel 
auffwand.

Desweiteren hat man bei C# ein recht umfangreiches Framwork was weit 
über die Standard Lib. bei C++ hinaus geht.
Es sind die kleinigkeiten die einem bei .Net das leben enorm 
erleichtern.
Angefangen von XML serilisation über Generics bis hin zu gut 
verwendbaren Netzwerk klassen.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karolina schrieb:
> LOL. Netter Joke !

Du bist auch ein netter Joke. Ich wette du weißt nicht mal wo .NET schon 
überall läuft. Auf Linux geht es schon, auf MAC soll es entwickelt 
werden und die restlichen 0.01% vernachlässige ich mal.

Winzigweich schrieb:
>> Ausserdem ist .NET langsam, das stimmt.
>
> Was bei den heutigen Prozessorgeschwindigkeiten aber sicherlich nicht
> für den Benutzer zu bemerken ist.

So langsam ist .NET gar nicht. Wenn man sehr effizient in c++ 
programmieren würde, dann könntest du vielleicht etwas rauskitzeln. 
Ansonsten gäbe es sicher immer eine .NET Variante die genauso schnell 
ist.
Bei Spielen ist es sowieso unrelevant: Spiele brauchen immer bessere 
Grakarten und nicht mehr so starke CPUs (höchtes für KI).

Karolina schrieb:
> Blub Blub, Über Features kann sich jeder selbst informieren, wenn es
> denn nötig wäre.

Blub Blub und deine Argumente kannst du auch mal stecken lassen, die hol 
ich mir dann schon selber.

Karolina schrieb:
> Der Heap kennt keine Fehler. Der Fehler bist dann du. Und wenn du dann
> deine 5000 Zeilen Code nicht kennst, dann hast du den falschen Job !

Du programmierst also Fehlerfrei und kennst deinen Code auswendig. 
Herzlichen Glückwunsch. Erzähl das deinem Arbeitgeber und du hast einen 
100% sicheren Job!
Weißt du überhaupt was ein Heapfehler ist?

Und nochmals danke fürs kommentieren. Allein dein unwissendheit über die 
.NET Plattformunabhängigkeit zeigt, dass du keine Ahnung hast!

Trotzdem hab ich mal eine Frage: Wie viel hast du schon in c# 
programmiert. Ich wette höchstens 10min.

Ich habe mit c# und c++ Programme und Spiele programmiert. Ich glaub das 
trifft in c# nicht auf dich zu.


Was ich außerdem an c# so schön finde. Braucht man ein irgendein Tool 
hat man es in 5-10min programmiert und ess sieht nicht mal schlecht aus 
(z.b von ändern einer Farbe in 1000 Bitmaps + konvertieren in png).

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich noch vrgessen:

Ralf schrieb:
> -Wenn du Programme schreibst die du verkaufst solltest du das nicht mit
> C# machen, weil dann kannst du gleich deinen Quellcode veröffentlichen.

Wenn ich das richtig weiß darfst du mit der VS 2010 Express deine 
Software vekaufen, ohne Quellcode zu veröffentlichen.

Autor: Kunze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus .Net-Kompilaten kann man ohne Mühe (quasi mit einem Klick) den 
Quellcode erzeugen.
Ich weiß das, weil mir mal ein Stück Net-Quellcode abhanden kam und mir 
ein Kollege das mir-nichts-dir-nichts aus der Exe wieder rausgeholt hat.

@ Samuel K.
Schau mal über Deinen Tellerrand hinaus.
Ja, c# ist komfortabel.
Ja, die IDE ist klasse und im Debugger kann man Code on-the-fly ändern 
und testen.
Und ja, du musst Dir wg. Bibliotheken keine Gedanken machen.

---
Aber:
Net ist langsamer als nativ, weil es halt verwaltet wird. Die ganze 
Verwaltung kostet seine Zeit (gobject ist auch langsamer als reines c).

Net ist nicht plattformunabhängig!
MS unterstützt nur Windows. Den Rest (Linux + Mac) macht Mono. Und nicht 
umsonst gibt es bei Mono Tools die testen wie wahrscheinlich der Code 
mit Mono laufen wird.

Und man liefert seinen kompletten Quellecode mit aus -> btw. wusste 
garnicht das MS so für open source ist.

---
Und Dein "ich programmier sowas in 5-10 Minuten" glaub ich nicht. 
Überlegen gehört auch zum Programmieren und nicht die reine Tipparbeit.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kunze schrieb:
> Und Dein "ich programmier sowas in 5-10 Minuten" glaub ich nicht.
> Überlegen gehört auch zum Programmieren und nicht die reine Tipparbeit.

Wenn man weiß wie man ein Bitmap in c# konvertiert, muss man nicht 
überlegen. Das ganze Tool war:

Bitmap laden
Jeden Pixel abfragen wenn nötig transparentm machen / Farbe ändern
In anderem Format speichern

+ Interface basteln.

Das dauert doch nicht lange!

Der Code wird in c# optimiert, theoretisch müsste es auch auf kurze 
Variablen und Methoden optimiert werden. Viel Spaß beim lesen. Ich hab 
mal einen 1200 Byte großes Schachprogramm versucht zu verstehen, da hat 
man keine Chance.

Kann man c# Code nicht signieren?

Wie ich geschrieben habe, um ein Programm in c++ schneller zu machen als 
in c# muss man wirklich sehr gut sein.
Der Jitter ist wirklich sehr gut gemacht. Er übersetzt z.b. jeden 
Codeblock nur einmal.

Außerdem ist c# Plattformunabhängig!!! Ich weiß das ich stark zu c# 
tendiere, aber ich denke hier musst du über deinen Tellerrand schauen. 
Der IL Code der erzeugt wird, kann auf jedem System mit dem Jitter 
ausgeführt werden! Selbst auf Systemen, die völlig anderst aufgebaut 
sind, könnte man dadurch die Programme laufen lassen. Und versuch mir es 
ja nicht abzusteiten. Es steht sogar in Büchern von mir drin, dass c# 
Platformunabhängig ist. Zusätzlich habe ich gelesen, dass Microsoft 
plant für Mac .Net zu entwickeln.

Wenn dir es darum geht das letzte Mhz aus deinem Prozessor zu holen, 
warum programmierst du dann nicht in Assembler??? Warum nutzt du 
überhaupt ein Betriebssystem das dauernd den PC verlangsamt? Warum 
schreibst du nicht für jedes Programm sein MinimalOS? Oder gleich ohne 
OS?

Die Prozessoren werden immer schneller, und selbst komplexe Algorithmen 
werden nach dem Übersetzen genauso schnell wie c++ oder gar c Code 
ausgeführt, da nur die Zeit benötigt wird bis die Methode oder Funktion 
in Maschinencode übersetzt ist.


Mein Fazit ist:

c++ kann (!) schneller sein, aber wenn dann ist es minimal. Es ist 
komfortabler damit zu programmieren. Allerdings braucht man .NET, das 
aber keine rolle spielt, Speicherplatz wird immer günstiger.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:

> Außerdem ist c# Plattformunabhängig!!! Ich weiß das ich stark zu c#

Nein, ist es nicht.

> tendiere, aber ich denke hier musst du über deinen Tellerrand schauen.
> Der IL Code der erzeugt wird, kann auf jedem System mit dem Jitter
> ausgeführt werden! Selbst auf Systemen, die völlig anderst aufgebaut
> sind, könnte man dadurch die Programme laufen lassen. Und versuch mir es
> ja nicht abzusteiten. Es steht sogar in Büchern von mir drin, dass c#
> Platformunabhängig ist. Zusätzlich habe ich gelesen, dass Microsoft
> plant für Mac .Net zu entwickeln.

Na wenn es in Büchern so steht, dann muss das ja stimmen. LOL
Dumm nur, dass sich die Realität nicht daran hält, was in Büchern steht 
und die Plattformunabhängigkeit sehr eingeschränkt ist.

> Wenn dir es darum geht das letzte Mhz aus deinem Prozessor zu holen,
> warum programmierst du dann nicht in Assembler??? Warum nutzt du
> überhaupt ein Betriebssystem das dauernd den PC verlangsamt? Warum
> schreibst du nicht für jedes Programm sein MinimalOS? Oder gleich ohne
> OS?

Warum programmierst Du nicht gleich in Basic, wenn Dein Rechner so 
schnell ist?
Die Trägheit von C#-Programmen ist spürbar und wenn es wenigstens eine 
echte Plattformunabhängigkeit mitbringen würde, könnte man das ja noch 
akzeptieren (wenn es auch ohne Geschwindigkeitseinbußen geht, wie man an 
wxWidgets sieht).


> Mein Fazit ist:
>
> c++ kann (!) schneller sein, aber wenn dann ist es minimal. Es ist
> komfortabler damit zu programmieren. Allerdings braucht man .NET, das
> aber keine rolle spielt, Speicherplatz wird immer günstiger.

Mein Fazit:
Du kennst nur C# und damit Du Dich kein bisschen mehr anstrengen musst, 
sollen sich halt die Nutzer Deiner Software mit den Nachteilen von C# 
herumschlagen.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Einstellung, dass heutige Rechner doch schnell genug seien und genug 
Speicherplatz hätten, scheint ganz typisch für .NET-Nutzer zu sein. Der 
Nutzer hat sich offenbar mit seiner Rechnerausstattung den 
Programmiervorlieben des Programmierers anzupassen, nicht umgedreht.

So einen Experten haben wir auch in der Firma, wo das eine oder andere 
Tool gebraucht wird, das durchaus zeitkritische Dinge zu tun hat und 
vergleichsweise große Datenmengen schaufeln muss. Die meisten 
Toolentwickler testen ihre Software (C++, MFC, wxWidgets, QT) auf 
ausgesucht alten Rechnern und Laptops und optimieren viel, damit die 
Tools auch überall problemlos laufen. Die Nutzer haben schließlich keine 
Zeit und Lust, für jedes Tool irgendwelche Kopfstände zu machen.
Der .NET-Experte knallt seinen .NET-Mist einfach zusammen und erwartet, 
dass sich die Leute alle neue Laptops zulegen, weil ja die alten Dinger 
viel zu langsam und für die Aufgabe unbrauchbar seien. Jeder weiß aber 
eigentlich, dass das einzig Unbrauchbare dieser Typ mit seinem 
.NET-Geraffel ist. Allerdings kann der sich hervorragend präsentieren 
und auf Management-Meetings wirken bunte Oberflächen nun mal am 
besten...

Autor: raketenfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vll sollte man .net einfach mal unabhängig gegen c++ testen

ich hatte bis jetzt keine perfomance probleme mit c#

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
raketenfred schrieb:
> Vll sollte man .net einfach mal unabhängig gegen c++ testen

Das kann man sich sparen. Das Ergebnis kann man beliebig gestalten, 
einfach durch die Auswahl der Aufgaben und unterschiedliche Optimierung.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich war neulich nochmal mit einem Browser ohne Werbe-Blockierer im 
Internet unterwegs.
Trotz 2,4 GHz und 1 MBit-Standleitung war 'das Internet' de-facto 
unbenutzbar vor lauter Werbung, Benutzer-Verfolgung (google syndication, 
tracker.*** und so weiter), Flash, Silverlight, Javascript, AJAX etc.

Und jetzt sagt einer, dass Rechenleistung und Speicher ja nichts mehr 
kosten. Na vielen Dank auch.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, 1 MBit-Standleitung, das ist ja auch ein bisschen langsam, nicht?

(Ich erinnere mich noch an den ersten "Netzzugang", den ich in meiner 
Firma nutzen durfte. War gar kein Internet, sondern Compuserve.
Anbindung erfolgte über ein 2400-Baud-Modem mit dem nächsten 
Datex-P-Knoten. Die Nutzung wurde nach Zeit abgerechnet, 25 USD pro 
Stunde zuzüglich einer "Communications Surcharge" von ebenfalls 25 USD 
pro Stunde.

Das war Anfang der 90er Jahre ...)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> Naja, 1 MBit-Standleitung, das ist ja auch ein bisschen langsam, nicht?
Mehr geht hier eben nicht.

Ich würde eher sagen, die meisten Webseiten sind ein bisschen 
unverschämt. Der Quotient von Schrott zu Inhalt übersteigt nur allzu 
leicht 80% und mehr...
Die T-Mobile-Rechnungen kommt gebündelt mit Werbung (ok, kann man noch 
abstellen) im Verhältnis von 15kB Rechnung und 1MB Werbung.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So in etwa meinte ich das auch.

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Jeder weiß aber
> eigentlich, dass das einzig Unbrauchbare dieser Typ mit seinem
> .NET-Geraffel ist. Allerdings kann der sich hervorragend präsentieren
> und auf Management-Meetings wirken bunte Oberflächen nun mal am
> besten...

ich will jetzt keine langen ausführungen machen, aber die letzten drei 
monate durfte ich intensive erfahrungen mit .NET-geraffel, c#ish, ASPx 
usw. sammeln und möchte sagen, dass du es genau auf den punkt bringst.

genauso auch solche aussagen wie:
.NET ist doch sowieso auf jeden PC installiert.

so ein schwachsinn.. und jede lösung, die ich in eigenregie als 
safety-/mission-/business-critical einsetze wird zu 99% niemals auf 
windows und .net-geraffel basieren. (s. z.b. britische atom-uboote) 
diese ganzen microsoft-fanboys und .net-frantics denken alle pcs kommen 
von aldi, heißen medion, laufen mit windows 7 und haben .net, directx, 
ie6 und andere tolle software-pakete am laufen.

solche leute kommen bei mir gleich in die hanswurst-schublade.

Samuel K. schrieb:
> Wie ich geschrieben habe, um ein Programm in c++ schneller zu machen als
> in c# muss man wirklich sehr gut sein.
> Der Jitter ist wirklich sehr gut gemacht. Er übersetzt z.b. jeden
> Codeblock nur einmal.

BOAAAAAAR!! Dann bin ich der Hax0r-King oder was?
wetten ich schreibe blind schnellere c++ programme als du in c#?

Samuel K. schrieb:
> Der IL Code der erzeugt wird, kann auf jedem System mit dem Jitter
> ausgeführt werden

der einzigste jitter hier, den hast du in deiner argumentation.

Rufus t. Firefly schrieb:
> Anbindung erfolgte über ein 2400-Baud-Modem mit dem nächsten
> Datex-P-Knoten.

das waren noch zeiten, wa? da konnte man noch gespannt mitlesen vor dem 
bildschirm, während der text am terminal runterrasselte.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit euch kann man nicht diskutieren! Eure Argumente sind stimmt nicht 
und bla bla.

Wenn .NET nicht Plattfromabhängig ist, warum kann man es dann ohne 
neucompilation auf linux und mac starten?

Dr.Net schrieb:
> BOAAAAAAR!! Dann bin ich der Hax0r-King oder was?
> wetten ich schreibe blind schnellere c++ programme als du in c#?

OK. Ein kleiner Spaceshooter. Min. 2000 Zeilen. Außerdem muss er auf 
min. 3 versch. System laufen. Ich nehme PC, Mac und XBox360. Und damit 
du keinen Scheiß machst sollte er min. ein Partikelsystem und KI haben.

Aber blind wirst du sowas sowieso nicht machen also vergiss es.

ICh werde dich zwar nicht umstimmen können, aber wenigsten die Argumente 
halten, die du versuchst zu vertuschen!

Was vor dem Übersetzen in Maschinencode ist, ist plattform abhängig. 
Oder gib mir eine andere (klare) definition.

Zeit ist Geld. Wenn man ein z.b. ein Spiel schneller mit c# 
programmieren kann, spart Entwicklungstzeit.


Selbst wenn c++ schneller ist: Auf die 1% mehr Geschwindigkeit kommt es 
auch nicht an (oder wo soll es denn darauf ankommen?).

In manchen Sachen ist c# sogar deutlich schneller als c++:

- Der Just in Time Compiler kann zur Laufzeit optimierungen vornehmen
- manche Sachen wie listen, exceptions, matrixen... sind in c# deutlich 
schneller als in c++


Vielleicht bist du zufrieden wenn ich sage, dass es versch. 
Einsatzgebiete für die Sprachen gibt. Es gibt nicht die 
Programmiersprache. Ich finde .NET einfacher. Du findest c++ oder c 
irgendetwas anderes.


Und damit du nicht sagst stimmt nicht:
http://www.tommti-systems.de/main-Dateien/reviews/...

Und wenn du noch wissen willst was an c++ schlecht ist:

http://www.mistybeach.com/articles/WhyIDontLikeCPl...
Da wird unter anderem auch mein Problem, dass man einen Fehler nicht so 
schnell findet beschrieben.

Ach da fällt mir was anderes ein. Komm wir schreiben ein Programm das 
zufällig Sachen in listen einfügt und wieder rausnimmt. Zufällig halt. 
Oder eines das Ausnahmen auslöst und sie abfängt. Mal schauen wer mehr 
pro Sekunde schafft! Dann sehen wir mal wer schneller ist.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr.Net schrieb:
> ich will jetzt keine langen ausführungen machen, aber die letzten drei
> monate durfte ich intensive erfahrungen mit .NET-geraffel, c#ish, ASPx
> usw. sammeln und möchte sagen, dass du es genau auf den punkt bringst.

Mach mal ein Beispiel würde mich interresieren.
c++ hat mich schließlich vor einem Jahr mit dem scheiß Heapfehler 
umgebracht.

> genauso auch solche aussagen wie:
> .NET ist doch sowieso auf jeden PC installiert.

Das hab ich nicht gesagt. Das ist auch ein Nachteil der Vorteile von 
.NET

> so ein schwachsinn.. und jede lösung, die ich in eigenregie als
> safety-/mission-/business-critical einsetze wird zu 99% niemals auf
> windows und .net-geraffel basieren. (s. z.b. britische atom-uboote)
> diese ganzen microsoft-fanboys und .net-frantics denken alle pcs kommen
> von aldi, heißen medion, laufen mit windows 7 und haben .net, directx,
> ie6 und andere tolle software-pakete am laufen.

Also wenn ich einen PC in Aldi kaufen würde, würde die Hälfte auf den 
Schrott fliegen. Mein PCs bau ich mir selber, dann weiß ich auch was 
drin ist und was er kann.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> - manche Sachen wie listen, exceptions, matrixen... sind in c# deutlich
> schneller als in c++

Ja, ja, und sicher auch die verschachtelten Schleifen ;-)

> http://www.tommti-systems.de/main-Dateien/reviews/...

Hast du gesehen, dass in dem von dir geposteten Link über den
Benchmark-Diagrammen jeweils

  "Performance in ms:"

steht?

Das bedeutet, dass kleine Zahlen bzw. kurze Balken besser sind :)

Autor: Programmiere (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Früher BASIC, heute C#. Die einfach Gestrickten sterben nie aus,
wählen Ossitante und gehen in die Kirche.

Warum bin ich 100T Jahre zu früh geboren? Ich freu mich auf die Hölle!

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da wirst du irgendwann Ossi-Angie treffen, die musst du dauernd 
anschauen!
Und hinter dir steht Wessiwelle.

Freu dich also nicht zu früh...

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Ach da fällt mir was anderes ein. Komm wir schreiben ein Programm das
> zufällig Sachen in listen einfügt und wieder rausnimmt. Zufällig halt.
> Oder eines das Ausnahmen auslöst und sie abfängt. Mal schauen wer mehr
> pro Sekunde schafft! Dann sehen wir mal wer schneller ist

na dann zeig mal her.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmiere schrieb:
> Früher BASIC, heute C#. Die einfach Gestrickten sterben nie aus,
> wählen Ossitante und gehen in die Kirche.

Mit Basic ist lange nicht c#. Mit c# hat man in etwa die gleichen 
Möglichkeiten wie in c++. Ich selber kann Basic nicht leiden.

In c++ kannst du einen Fehler produzieren, der auftritt wenn das 
Programm fertig ist und sich vorher nicht zeigt. Mach es dir halt schwer 
wenn du es haben willst. Das c# nicht so langsam ist wie alle denken, 
ist jetzt hoffentlich klar.

Weißt du was ich würde ja auch viel lieber alles in Assembler für jeden 
Computer einzeln programmieren. Ihr alle macht es dch viel zu leicht mit 
c++. Früher Basic heute c++!

Das kann ich genauso sagen. c# ist aus c++ entstanden. Die vielen 
Sicherheitsabfragen machen c# etwas langsamer, dafür findet man Fehler 
einfacher und schneller(und trotzdem ist c# in manchen Bereichen 
schneller).

Weiß du was ich hasse: Wenn ein irgendetwas abstürzt, wenn man nicht 
gespeichert hat. Das trifft komischerweise meistens auf c oder c++ 
Anwendungen zu. Auf .NET Software komischerweise seltenst. Hmmm...

Yalu X. schrieb:
> "Performance in ms:"

Sry hab ich überlesen, trotzdem gibt es noch Bereiche in denen c# 
schneller ist.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, beim Buchstabieren. Es hat ein Zeichen weniger.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> In c++ kannst du einen Fehler produzieren, der auftritt wenn das
> Programm fertig ist und sich vorher nicht zeigt. Mach es dir halt schwer
> wenn du es haben willst.
Das geht in C# nicht? Cool.


> c# ist aus c++ entstanden.
Nein, C# hab bis auf ein wenig Syntax nichts mehr mit C und C++ zu tun.
PHP und Perl auch nicht.

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> ja, beim Buchstabieren. Es hat ein Zeichen weniger.

zu geil die antwort.

Sven P. schrieb:
> Samuel K. schrieb:
>> In c++ kannst du einen Fehler produzieren, der auftritt wenn das
>> Programm fertig ist und sich vorher nicht zeigt. Mach es dir halt schwer
>> wenn du es haben willst.
> Das geht in C# nicht? Cool.

das geht tatsächlich zu 80% in Ada nicht. und Ada ist um etliche male 
stärker typisiert als c#

das über c-hashish zu sagen zeigt deine inkompetenz.

Samuel K. schrieb:
> ICh werde dich zwar nicht umstimmen können, aber wenigsten die Argumente
> halten, die du versuchst zu vertuschen!

also, wo ist jetzt dein listen-benchmark?

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
>> c# ist aus c++ entstanden.
> Nein, C# hab bis auf ein wenig Syntax nichts mehr mit C und C++ zu tun.
> PHP und Perl auch nicht.

stimmt, c#ish ist wohl eher ein java-rip. java ist aber schon so 
beschränkt (mehrfachvererbung über interfaces, grundlegende 
datenstrukturen...) das man durch das hinzufügen von partial classes die 
sache nur schlimmer machen kann.

das einzigste was dieses sprachen populär macht und am leben hält, sind 
die umfangreichen APIs/Frameworks.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr.Net schrieb:
> Sven P. schrieb:
>> Samuel K. schrieb:
>>> In c++ kannst du einen Fehler produzieren, der auftritt wenn das
>>> Programm fertig ist und sich vorher nicht zeigt. Mach es dir halt schwer
>>> wenn du es haben willst.
>> Das geht in C# nicht? Cool.
>
> das geht tatsächlich zu 80% in Ada nicht. und Ada ist um etliche male
> stärker typisiert als c#
>
> das über c-hashish zu sagen zeigt deine inkompetenz.
Was hab ich denn über C# gesagt, was dir meine Inkompetenz zeigt?
[x] Du hast gelesen, was ich geschrieben hab.
[ ] Du hast verstanden, was ich geschrieben hab.

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Was hab ich denn über C# gesagt, was dir meine Inkompetenz zeigt?
> [x] Du hast gelesen, was ich geschrieben hab.
> [ ] Du hast verstanden, was ich geschrieben hab.

nicht du, sondern olle samuel k. war gemeint.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn's etwas offtopic ist (die ursprüngliche Frage scheint ja schon
längst beantwortet zu sein):

Verwendet eigentlich Microsoft C# auch für die eigenen Produktentwick-
lungen? Ein paar Demoprogramme wurden ja schon vorgestellt, aber wie
sieht es mit schwergewichtigeren Anwendungen aus, bei denen C# nach
eigener Aussage die Produktivität deutlich erhöhen soll?

Ist bspw. MS Office 2010 in C# programmiert?

Oder der Internet Explorer 9?

Oder Visual Studio 2010?

Zumindest der C#-Compiler selbst sollte ja in seiner eigenen Sprache
programmiert sein, wie es bei den meisten universell einsetzbaren
Programmiersprachen üblich ist (C, Java, Lisp, Pascal, Haskell usw.).
Falls dies tatsächlich der Fall ist: Könnte man den MS-Compiler auch
unter Mono verwenden, wenn man mit dem Opensource-Compiler aus
irgendeinem Grund nicht zufrieden wäre?

Oft hatte ich allerdings schon das Gefühl, dass MS intern nicht die
offiziell verkauften Tools, sondern wesentlich bessere (entweder selbst
entwickelte oder zugekaufte) verwendet. Dieses Gefühl beschränkt sich
nicht auf die Softwareentwicklung, sondern betrifft auch Dokumentations-
und Präsentationstools. So gab es bspw. schon vor etlichen paar Jahren
auf dem CeBIT-Stand von MS eine Präsentation mit einer Software, bei der
sogar mir fast die Spucke weg blieb. Es kann aber kaum eine Vorversion
von Powerpoint gewesen sein, da selbst das aktuelle Powerpoint in Sachen
Animationseffekte und Darstellungsqualität nicht einmal ansatzweise
damit konkurrieren kann.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr.Net schrieb:
> also, wo ist jetzt dein listen-benchmark?

Ich gebs ja zu das da c++ schneller ist, ich hab das ja überlesen. Die 
Diskusion wird sowieso kein Ende nehmen. Man kann nicht sagen c++ ist 
besser als c#, oder andersherum.

Aber anscheinend willst du das nicht begreifen. Oder wie soll ich das 
olle verstehen?

Das Gerede oben mit den Tests sollte zeigen, dass wenn ich bestimmte 
Gebiete rauspicke c# besser steht. Das selbe kann man auch in c++ 
machen. Aber c# mit Basic zu vergleichen find ich eine Frechheit.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr.Net schrieb:
> mehrfachvererbung über interfaces

eher so: interfaces statt mehrfachvererbung

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Verwendet eigentlich Microsoft C# auch für die eigenen Produktentwick-
> lungen?

Ich meine mich zu entsinnen, daß das VS weitgehend in C# gestrickt ist.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin inkompetent. Aha, und du trägst wohl was zu Thema bei:

Dr.Net schrieb:
> ich will jetzt keine langen ausführungen machen, aber die letzten drei
> monate durfte ich intensive erfahrungen mit .NET-geraffel, c#ish, ASPx
> usw. sammeln und möchte sagen, dass du es genau auf den punkt bringst.

Eine leere Ausage. Ich habe gesagst warum mir vor einem Jahr c++ 
gestunken hat. Vielleicht verräts du auch deine Abneigungen gegen .Net.

> genauso auch solche aussagen wie:
> .NET ist doch sowieso auf jeden PC installiert.

Das hat niemand gesagt.

> BOAAAAAAR!! Dann bin ich der Hax0r-King oder was?
> wetten ich schreibe blind schnellere c++ programme als du in c#?

Das bringt sowieso nichts. Da jede Sprache seine Vorteile hat. Manchmal 
lassen sich Sachen einfach besser in c#/c++/c lösen.

> Samuel K. schrieb:
>> Der IL Code der erzeugt wird, kann auf jedem System mit dem Jitter
>> ausgeführt werden
>
> der einzigste jitter hier, den hast du in deiner argumentation.

Weiß du überhaupt was der Jitter ist?

> das über c-hashish zu sagen zeigt deine inkompetenz.

Wenn man nichts mehr weiß, fängt man mit Beleidigungen an.

Dr.Net schrieb:
> das einzigste was dieses sprachen populär macht und am leben hält, sind
> die umfangreichen APIs/Frameworks.

Das glaube ich nicht. Hast du da Quellen?

Dr.Net schrieb:
> nicht du, sondern olle samuel k. war gemeint.

siehe inkompetenz.



Tatsache ist, dass man sich mit einem kleinen Fehler bei Zeigern einen 
ganz schönen Fehler reinbauen kann.

In c# hab ich es noch nicht geschafft.

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Könnte man den MS-Compiler auch
> unter Mono verwenden, wenn man mit dem Opensource-Compiler aus
> irgendeinem Grund nicht zufrieden wäre?

das wird wahrscheinlich schon nicht gehen, weil das C# was in der 
MS-welt gebräuchlich ist kein ECMA-C# ist. soweit ich weiß wurden da 
einige neue patentgeschütze operatoren und features zur sprache 
hinzugefügt und ich gehe davon aus, dass MS davon sehr rege gebrauch 
macht, um ihre produkte zu vergällen.

der mono-c#-compiler ist soweit ich weiß in c++ geschrieben (ein 
gcc-frontend?)

Klaus Wachtler schrieb:
> Dr.Net schrieb:
>> mehrfachvererbung über interfaces
>
> eher so: interfaces statt mehrfachvererbung

soweit ich weiß, gab es ursprünglich interfaces nicht und die leute 
haben sich beschwerrt, dass sie mehrfachvererbung wollen, aber sun hat 
gesagt das ist zu kompliziert.. ich weiß nicht, ob das richtig ist, aber 
das habe ich so gehört..

Yalu X. schrieb:
> Oft hatte ich allerdings schon das Gefühl, dass MS intern nicht die
> offiziell verkauften Tools, sondern wesentlich bessere (entweder selbst
> entwickelte oder zugekaufte) verwendet

zumindest im compiler-bereich, v.a. semantische fehlersuche zur 
compile-time, weiß ich das microsoft hier einige sehr raffinierte tools 
einsetzt, die mit der großen sicherheits-revolution bei microsoft nach 
XP/2001 eingekehrt sind. das ganze wissen und die kompetenz kamen alle 
durch den einkauf anderer firmen ins unternehmen. ein teil wurde zu den 
programmierern durchgereicht.

wenn ich allerdings so sachen lese wie: windows server 2008 ist ein 
sicheres produkt, weil microsofts sicherheitsethik sagt, dass alle 
überflüssigen dienste im auslieferungszustand abgeschaltet sein sollen, 
dann ist das doch relativ lächerlich. aber wie überall gibt es hier wohl 
ein mehrklassen-system, in dem die consumer immer die dummen sind. das 
sieht man ja auch bei den notebook-displays.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Weiß du überhaupt was der Jitter ist?
Jitter ist zeitlicher Drift.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Wenn .NET nicht Plattfromabhängig ist, warum kann man es dann ohne
> neucompilation auf linux und mac starten?

Weil es wahrscheinlich nicht sehr weit über "Hello World" hinausgeht. 
Ansonsten hechelt Mono der aktuellen .NET-Implementierung immer nur 
hinterher und die Plattformunabhängigkeit ist sehr, sehr überschaubar. 
Die Anzahl der größeren, in .NET geschriebenen Windows-Programme, die 
problemlos unter Linux starten, ist sehr überschaubar. Da laufen mehr 
herkömmliche MFC- und Windows-API-Programme in einer Wine-Umgebung...

Dazu passt auch eine für mich recht lustige Anekdote am Rande, die ich 
vor kurzem erlebt habe:
Firmenvertreter stellt interessante Software vor, die in seiner Firma 
entwickelt wird. Die Symbole auf der Oberfläche sehen mir nach QT aus, 
deswegen Frage ich nach. Ja, so der Vertreter, die Oberfläche ist mit QT 
gemacht. Daraufhin frage ich ihn, ob das Programm dann auch für Linux 
verfügbar ist. Seine Antwort: "Theoretisch sollte man das denken, ja, 
aber wir haben auch eine ganze Menge in .NET geschriebener Module. 
Deswegen ist das praktisch nicht wirklich so einfach portierbar."
Der Grund, warum man so einen Mix fährt, habe ich dann nicht mehr 
erfahren, ich vermute mal, dass die verteilte Entwicklung (Indien, 
Deutschland) einen gehörigen Anteil daran hat...

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Das Gerede oben mit den Tests sollte zeigen, dass wenn ich bestimmte
> Gebiete rauspicke c# besser steht. Das selbe kann man auch in c++
> machen. Aber c# mit Basic zu vergleichen find ich eine Frechheit.

Der Vergleich C# und C++ ist eigentlich nicht das, was den Kern des 
Problems trifft. Das Problem ist .NET, das mit C# kommt.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Samuel K. schrieb:
>> Wenn .NET nicht Plattfromabhängig ist, warum kann man es dann ohne
>> neucompilation auf linux und mac starten?
>
> Weil es wahrscheinlich nicht sehr weit über "Hello World" hinausgeht.

ASP.NET-Anwendungen bis zur aktuellen 4.0 sollten/sind (habe schon lange 
nicht mehr auf den mono-Seiten nachgesehen) laufen, ebenso WinForms 2.0 
basierte Sachen. WPF dagegen überhaupt nicht. Silverlight gibt's dafür 
direkt von MS für OSX (die restlichen System sind in diesem Bereich ehe 
irrelevant).

Yalu X. schrieb:
> Auch wenn's etwas offtopic ist (die ursprüngliche Frage scheint ja schon
> längst beantwortet zu sein):
>
> Verwendet eigentlich Microsoft C# auch für die eigenen Produktentwick-
> lungen? Ein paar Demoprogramme wurden ja schon vorgestellt, aber wie
> sieht es mit schwergewichtigeren Anwendungen aus, bei denen C# nach
> eigener Aussage die Produktivität deutlich erhöhen soll?
>
> Ist bspw. MS Office 2010 in C# programmiert?
>
> Oder der Internet Explorer 9?
>
> Oder Visual Studio 2010?

VS2010 sind die grundlegenden Teile WPF 
http://blogs.msdn.com/b/visualstudio/archive/2010/...,
kleinere Teile waren schon ab VS2002/2003 managed Code.
Expression Blend und die anderen Produkte aus dieser Reihe sind WPF,
alles was auf ASP.NET (bspw. msdn) basiert, ist managed Code, Sharepoint 
Portal Server,  Outlook BCM, Outlook Mobile Access, Biztalk Server 
etc.pp. F# ist managed Code (inkl. Quelltext 
http://www.microsoft.com/downloads/en/details.aspx...).
Die div. .NET-Frameworks natürlich auch...

Dazu zwei Betriebssysteme...
Singularity und Midori

> Zumindest der C#-Compiler selbst sollte ja in seiner eigenen Sprache
> programmiert sein, wie es bei den meisten universell einsetzbaren
> Programmiersprachen üblich ist (C, Java, Lisp, Pascal, Haskell usw.).

Umgestellt werden sollte der Compiler, ob er das z.Z. schon ist k.A. 
Bartok, der Compiler, der für Singularity eingesetzt wurde, ist in C# 
geschrieben worden.

> Falls dies tatsächlich der Fall ist: Könnte man den MS-Compiler auch
> unter Mono verwenden, wenn man mit dem Opensource-Compiler aus
> irgendeinem Grund nicht zufrieden wäre?

Einen OS-Compiler gibt's von MS...
http://www.microsoft.com/downloads/en/details.aspx...

>
> Oft hatte ich allerdings schon das Gefühl, dass MS intern nicht die
> offiziell verkauften Tools, sondern wesentlich bessere (entweder selbst
> entwickelte oder zugekaufte) verwendet. Dieses Gefühl beschränkt sich
> nicht auf die Softwareentwicklung, sondern betrifft auch Dokumentations-
> und Präsentationstools. So gab es bspw. schon vor etlichen paar Jahren
> auf dem CeBIT-Stand von MS eine Präsentation mit einer Software, bei der
> sogar mir fast die Spucke weg blieb. Es kann aber kaum eine Vorversion
> von Powerpoint gewesen sein, da selbst das aktuelle Powerpoint in Sachen
> Animationseffekte und Darstellungsqualität nicht einmal ansatzweise
> damit konkurrieren kann.

http://www.scottlogic.co.uk/blog/colin/2010/10/sil...
http://nui.joshland.org/2010/06/naturalshow-and-ne...
ähnliches gibt's seit einigen Jahren in einer ganzen Reihe von WPF-Demos

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> ASP.NET-Anwendungen bis zur aktuellen 4.0 sollten/sind (habe schon lange

ASP.NET ist für Webanwendungen und das als Grundlage für normale 
Anwendungsprogramme vorzuschlagen, ist schon etwas bizarr.

> nicht mehr auf den mono-Seiten nachgesehen) laufen, ebenso WinForms 2.0
> basierte Sachen. WPF dagegen überhaupt nicht. Silverlight gibt's dafür

WinForms ist tot. Und es zeigt damit (neben anderen toten Pferden von 
MS) auch, dass man sich nicht auf Microsoft-Technologien verlassen 
sollte, wenn man zukunftssicher sein will.

> direkt von MS für OSX (die restlichen System sind in diesem Bereich ehe
> irrelevant).

Klar, alles irrelevant. So kann man "Plattformunabhängigkeit" auch 
definieren. Deine Argumentation ist immer wieder dieselbe...

Die sogenannte "Plattformunabhängigkeit" von .NET-Technologien ist im 
Vergleich zu anderen Systemen wie Java, QT oder wxWindows einfach nur 
erbärmlich. Selbst mit wine, dem Windows-Emulator unter Linux, bekommt 
man mehr normale Windows-Anwendungen zum Laufen als es wirklich 
portierbare .NET-Anwendungen gibt.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Arc Net schrieb:
>> ASP.NET-Anwendungen bis zur aktuellen 4.0 sollten/sind (habe schon lange
>
> ASP.NET ist für Webanwendungen und das als Grundlage für normale
> Anwendungsprogramme vorzuschlagen, ist schon etwas bizarr.

Wo wird das vorgeschlagen?
Es ging um Sachen die "sehr weit über "Hello World"" hinausgehen.

>
>> nicht mehr auf den mono-Seiten nachgesehen) laufen, ebenso WinForms 2.0
>> basierte Sachen. WPF dagegen überhaupt nicht. Silverlight gibt's dafür
>
> WinForms ist tot. Und es zeigt damit (neben anderen toten Pferden von
> MS) auch, dass man sich nicht auf Microsoft-Technologien verlassen
> sollte, wenn man zukunftssicher sein will.

Typisches Argumentationsmuster.
Laufen etwa WinForms-Anwendungen und Tools nicht mehr? Gibt es keine 
Entwicklungsumgebungen mehr für WinForms? Anders gefragt: Warum geht 
Nokia mit Qt bzw. QML in dieselbe deklarative Richtung wie WPF? Wie 
sieht's dort mit der Zukunftssicherheit aus?

>
>> direkt von MS für OSX (die restlichen System sind in diesem Bereich ehe
>> irrelevant).
>
> Klar, alles irrelevant. So kann man "Plattformunabhängigkeit" auch
> definieren. Deine Argumentation ist immer wieder dieselbe...

Weil sich daran bislang nichts geändert hat.
Mal eine Statistik einer etwas häufiger besuchten Webseite
http://stats.wikimedia.org/wikimedia/squids/SquidR...
http://en.wikipedia.org/wiki/Usage_share_of_operat...
Linux: 1.88 % iPhone + iPad 1.97 %

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
>> WinForms ist tot. Und es zeigt damit (neben anderen toten Pferden von
>> MS) auch, dass man sich nicht auf Microsoft-Technologien verlassen
>> sollte, wenn man zukunftssicher sein will.
>
> Typisches Argumentationsmuster.
> Laufen etwa WinForms-Anwendungen und Tools nicht mehr? Gibt es keine
> Entwicklungsumgebungen mehr für WinForms?
Hilft mir das, wenn ich in fünf Jahren einen kritischen Fehler oder eine 
Sicherheitslücke finde, die mein Produkt unmittelbar betrifft?

Normalerweise entwickelt sich ein Programm ja zusammen mit Bibliotheken 
usw. weiter. Nur hier hängt WinForms irgendwann wie ein steinzeitlicher 
Klotz hinten dran und kommt nicht mehr hinterher...


> Weil sich daran bislang nichts geändert hat.
> Mal eine Statistik einer etwas häufiger besuchten Webseite
> http://stats.wikimedia.org/wikimedia/squids/SquidR...
> http://en.wikipedia.org/wiki/Usage_share_of_operat...
> Linux: 1.88 % iPhone + iPad 1.97 %

Da wäre ich vorsichtig mit. Es wird natürlich nicht das Ergebnis 
umwerfen, aber der Vollständigkeit halber: Viele Leute geben sich auch 
unter Linux als Windows-Browser aus, weil manche Webseiten von total 
irrgeleiteten Designern sonst herumzicken.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Windows-Emulator
          ^^^^^^^^
Weißt du was WINE heißt?
Wine is not an emulator!


Übrigens ich finde ich .NET 2.0 für normale Anwendungen völlig 
ausreichend.

Sven P. schrieb:
> Normalerweise entwickelt sich ein Programm ja zusammen mit Bibliotheken
> usw. weiter. Nur hier hängt WinForms irgendwann wie ein steinzeitlicher
> Klotz hinten dran und kommt nicht mehr hinterher...

Naja, man kann durch Ableitung von Control auch selber Forms erstellen. 
Man könnte auch die WinForm ableiten und manche Sachen verändern. Ganz 
einfach ist das aber dann auch nicht.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Wo wird das vorgeschlagen?
> Es ging um Sachen die "sehr weit über "Hello World"" hinausgehen.

Offensichtlich ist Dir entgangen, dass wir hier von normalen Anwendungen 
reden und nicht von Web-Anwendungen. Insofern ist und bleibt der 
ASP.NET-Vorschlag bizarr.

> Typisches Argumentationsmuster.

Nicht nachplappern. Das wirkt einfallslos.

> Laufen etwa WinForms-Anwendungen und Tools nicht mehr? Gibt es keine
> Entwicklungsumgebungen mehr für WinForms? Anders gefragt: Warum geht
> Nokia mit Qt bzw. QML in dieselbe deklarative Richtung wie WPF? Wie
> sieht's dort mit der Zukunftssicherheit aus?

WinForms ist tot und durch einen komplett neuen Nachfolger abgelöst 
worden. Das mit einer Weiterentwicklung zu vergleichen, ist Unsinn.
Und wer wirtschaftlich von seinem Produkt und dessen Basistechnologie 
abhängt, wird sich (hoffentlich) wohl zweimal überlegen, ob er auf 
Technologien setzt, die in ein paar Jahren nicht mehr auf der dann 
aktuellen Plattform laufen und/oder keine Sicherheitsupdates mehr 
erhalten.

> Weil sich daran bislang nichts geändert hat.
> Mal eine Statistik einer etwas häufiger besuchten Webseite
> http://stats.wikimedia.org/wikimedia/squids/SquidR...
> http://en.wikipedia.org/wiki/Usage_share_of_operat...
> Linux: 1.88 % iPhone + iPad 1.97 %

Nach der Logik ist auch MFC "plattfomunabhängig", weil es nur die 
angeblich relevanten Betriebssysteme unterstützt. Das ist aber krude 
Microsoft-Logik, der ich mich nicht anschließen kann. 
Plattformunabhängigkeit beschreibt die Unabhängigkeit von bestimmten 
Plattformen und nicht die Ausrichtung auf eine oder zwei der 
vermeintlich wichtigsten Plattformen.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
       ^^^^^^^^
> Weißt du was WINE heißt?
> Wine is not an emulator!

Schön, spielt nur überhaupt keine Rolle.

BTW:
Du weißt hoffentlich auch, woher dieser Name kommt? Man will nicht den 
Eindruck erwecken, eine komplette Windows-Maschine zu emulieren. Man 
emuliert aber durchaus eine Windows-Umgebung. Im Endeffekt laufen native 
Windowsprogramme unter einem anderen OS.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> VS2010 sind die grundlegenden Teile WPF
> http://blogs.msdn.com/b/visualstudio/archive/2010/...,
> kleinere Teile waren schon ab VS2002/2003 managed Code.
> ...

Danke für diese interessanten Informationen.

>> Es kann aber kaum eine Vorversion von Powerpoint gewesen sein, da
>> selbst das aktuelle Powerpoint in Sachen Animationseffekte und
>> Darstellungsqualität nicht einmal ansatzweise damit konkurrieren
>> kann.
>
> http://www.scottlogic.co.uk/blog/colin/2010/10/sil...
> http://nui.joshland.org/2010/06/naturalshow-and-ne...
> ähnliches gibt's seit einigen Jahren in einer ganzen Reihe von WPF-Demos

Ich glaube, die Präsentation war im Frühjahr 2006. WPF und Silverlight
wurden zwar lt. Wikipedia offiziell erst später herausgegeben, könnten
aber trotzdem schon die Basis des Präsentationsprogramms gewesen sein.

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Du weißt hoffentlich auch, woher dieser Name kommt? Man will nicht den
> Eindruck erwecken, eine komplette Windows-Maschine zu emulieren. Man
> emuliert aber durchaus eine Windows-Umgebung. Im Endeffekt laufen native
> Windowsprogramme unter einem anderen OS.

sorry, aber das ist falsch. es mag der eindruck einer emulation 
entstehen. aber im endeffekt werden nur windows libraries für linux zur 
verfügung gestellt. im bereich von directx kann man, da hier auf opengl 
"übersetzt" wird (wobei ich nicht weiß, ob auch teilweise direkt in den 
fb gerendert wird), von emulieren sprechen, aber in der masse ist wine 
kein emulator, sondern eine sammlung von funktionslibrarys, die 
funktionen, die auf windows vom bs bereitgestellt werden, auf 
linux/mac/bsd/X.. betriebssystemen zur verfügung stellen.

ich würde eher von einer portierung von unten sprechen, als von einer 
emulation.

Gastino G. schrieb:
> WinForms ist tot und durch einen komplett neuen Nachfolger abgelöst
> worden. Das mit einer Weiterentwicklung zu vergleichen, ist Unsinn.
> Und wer wirtschaftlich von seinem Produkt und dessen Basistechnologie
> abhängt, wird sich (hoffentlich) wohl zweimal überlegen, ob er auf
> Technologien setzt, die in ein paar Jahren nicht mehr auf der dann
> aktuellen Plattform laufen und/oder keine Sicherheitsupdates mehr
> erhalten.

das unterzeichne ich so 100%, aber man muss auch mal schauen, was zum 
beispiel mit einem computer-kassensystem, ERP-systemen, datenbanken usw. 
passiert. ich würde hier schon aus dem grunde, dass man bei windows 
unterbau in der regel nicht garantieren kann, dass es laufen wird, nicht 
auf windows/ms setzen. ja - man hat dann, wenn was passiert jemanden in 
der pflicht, aber man ist doch nur einer von tausenden leuten mit 
problemen und bevor ms die bugs fixt, die man gefunden hat.. da würde 
ich nicht drauf setzen..

beispiel computer-kassensystem: hier würde doch eine 
bsd/qt/postgres-lösung z.b. eine durchgehend solide struktur bieten, das 
ist relativ zeitlos und man kann bugs - sollte es in 20 jahren keinen 
support mehr geben - auch selbst beheben. ich verstehe nicht, wie man in 
solchen bereichen auch nur daran denken kann windows CE mit winforms und 
irgendwelchen anderem krempel  einzusetzen.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr.Net schrieb:
> sorry, aber das ist falsch. es mag der eindruck einer emulation
> entstehen. aber im endeffekt werden nur windows libraries für linux zur
> verfügung gestellt. im bereich von directx kann man, da hier auf opengl
> "übersetzt" wird (wobei ich nicht weiß, ob auch teilweise direkt in den
> fb gerendert wird), von emulieren sprechen, aber in der masse ist wine
> kein emulator, sondern eine sammlung von funktionslibrarys, die
> funktionen, die auf windows vom bs bereitgestellt werden, auf
> linux/mac/bsd/X.. betriebssystemen zur verfügung stellen.

Und genau das "zur Verfügung stellen" ist doch eigentlich nichts weiter 
als eine Emulation. ;) Etwas anderes wird in Emulatoren auch nicht 
gemacht, bei wine wollte man nur zum Ausdruck bringen, dass keine 
komplette Maschine inklusive Hardware emuliert wird wie zum Beispiel bei 
virtuellen Maschinen. Aber ehrlich gesagt halte ich den Namen "wine" 
bzw. dessen Bedeutung für reichlich unsinnig und irreführend.

> ich würde eher von einer portierung von unten sprechen, als von einer
> emulation.

Na ja...
Die Programme greifen auf eine Umgebung zu, die denen eine native 
Umgebung vorgaukelt. Nenne es lieber "Teil-Emulation".

> das unterzeichne ich so 100%, aber man muss auch mal schauen, was zum
> beispiel mit einem computer-kassensystem, ERP-systemen, datenbanken usw.
> passiert. ich würde hier schon aus dem grunde, dass man bei windows
> unterbau in der regel nicht garantieren kann, dass es laufen wird, nicht
> auf windows/ms setzen. ja - man hat dann, wenn was passiert jemanden in
> der pflicht, aber man ist doch nur einer von tausenden leuten mit
> problemen und bevor ms die bugs fixt, die man gefunden hat.. da würde
> ich nicht drauf setzen..

Ich würde ohnehin immer vermeiden wollen, meine wirtschaftliche 
Grundlage von der Technologie einer Firma abhängig zu machen.

> support mehr geben - auch selbst beheben. ich verstehe nicht, wie man in
> solchen bereichen auch nur daran denken kann windows CE mit winforms und
> irgendwelchen anderem krempel  einzusetzen.

Ich auch nicht.

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Und genau das "zur Verfügung stellen" ist doch eigentlich nichts weiter
> als eine Emulation. ;) Etwas anderes wird in Emulatoren auch nicht
> gemacht

gut, das ist natürlich dann sache der definition. für mich ist eine 
emulation irgendetwas, was mit der recompilation/interpretation von 
opcodes bzw. instruktionen an die hardware zu tun hat. das 
"interpretieren" von library calls durch eigene librarys ist mir da 
etwas zu high-level. aber im grunde ist es ja eine art verfügbar-machung 
auf einem anderen system, als dem ursprünglichem ziel-system.

Gastino G. schrieb:
> Ich würde ohnehin immer vermeiden wollen, meine wirtschaftliche
> Grundlage von der Technologie einer Firma abhängig zu machen.

embrace, extend, extinguish nicht.. viele firmen ziehen aber grade 
daraus riesenprofit. die sagen ihren kunden dann: ja hier neue 
microsoft-produkte, das ist ganz toll, da kann man videos auf schrift 
abspielen. und scheffeln damit nochmal kohle.. microsoft schubst also 
eigentlich nur mal den übertrieben gebloateten markt wieder an.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema Wine und Emulator:

Ursprünglich hieß Wine tatsächlich "Windows Emulator". Auch in der
Ankündigung ist explizit von einer "Emulation Library" die Rede:

  "The finished product will essentiaily consist of two parts:

       a) A program loader, ...

       b) The second part of the finished product is an emulation
          library, which takes calls to Windows functions, and somehow
          translates these into calls to X11 in one fashion or another,
          so that equivalent functionality is achieved."

Weil aber viele bei "Emulator" sofort an einen "CPU-Emulator" und als
Nächstes an "schnarchlahm" denken, wurde die Abkürzung irgendwann in
"Wine is not an emulator" umdefiniert (möglicherweise auch, um Streitig-
keiten mit MS wegen des Namens "Windows" aus dem Weg zu gehen).

Man braucht sich also wegen der Frage, ob Wine ein Emulator ist, nicht
in die Haare zu kriegen :)

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Arc Net schrieb:
>> Wo wird das vorgeschlagen?
>> Es ging um Sachen die "sehr weit über "Hello World"" hinausgehen.
>
> Offensichtlich ist Dir entgangen, dass wir hier von normalen Anwendungen
> reden und nicht von Web-Anwendungen. Insofern ist und bleibt der
> ASP.NET-Vorschlag bizarr.

QML geht wie auch XAML in dieselbe Richtung. D.h. eine klare, bei QML 
eher weniger, Trennung von UI und Code. Der Schritt zu reinen 
Webanwendungen ist damit nicht mehr weit bzw. auf einigen mobilen 
Plattformen (webOS, Android z.B. mit PhoneGap) schon gegangen worden.
Bspw. sind webOS Anwendungen HTML+CSS+Javascript, die man mittlerweile 
auch mit nativem Code "unterstützen" kann.

> WinForms ist tot und durch einen komplett neuen Nachfolger abgelöst
> worden. Das mit einer Weiterentwicklung zu vergleichen, ist Unsinn.

QML ist keine Weiterentwicklung, sondern eine an Javascript angelehnte 
Neuentwicklung.

> Und wer wirtschaftlich von seinem Produkt und dessen Basistechnologie
> abhängt, wird sich (hoffentlich) wohl zweimal überlegen, ob er auf
> Technologien setzt, die in ein paar Jahren nicht mehr auf der dann
> aktuellen Plattform laufen und/oder keine Sicherheitsupdates mehr
> erhalten.

Es gibt bei MS klare Aussagen zum Produkt-Lifecycle. D.h. fünf Jahre 
nach dem Erscheinen Mainstream-Support (Feature requests, security 
updates, non-security hotfixes) und zehn Jahre Extended-Support 
(security updates und EHSA non-security hotfixes, letztere sind 
kostenpflichtig)

Dr.Net schrieb:
> embrace, extend, extinguish nicht.. viele firmen ziehen aber grade
> daraus riesenprofit. die sagen ihren kunden dann:

Jede Firma die Produkte entwickelt, verhält sich so.

> beispiel computer-kassensystem: hier würde doch eine
> bsd/qt/postgres-lösung z.b. eine durchgehend solide struktur bieten, das
> ist relativ zeitlos und man kann bugs - sollte es in 20 jahren keinen
> support mehr geben - auch selbst beheben. ich verstehe nicht, wie man in
> solchen bereichen auch nur daran denken kann windows CE mit winforms und
> irgendwelchen anderem krempel  einzusetzen.

Windows CE ist seit geraumer Zeit fast vollständig im Quelltext 
verfügbar
http://msdn.microsoft.com/en-us/windowsembedded/ce...
den Quelltext des NET-Frameworks bekommt jeder Entwickler frei Haus
http://weblogs.asp.net/scottgu/archive/2008/01/16/...
das Micro Framework ist Open Source (Apache 2.0-Lizenz)
ähnliches gibt's auch für die Desktop-Variante 
http://www.microsoft.com/resources/sharedsource/wi...

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> QML geht wie auch XAML in dieselbe Richtung. D.h. eine klare, bei QML
> eher weniger, Trennung von UI und Code. Der Schritt zu reinen
> Webanwendungen ist damit nicht mehr weit bzw. auf einigen mobilen
> Plattformen (webOS, Android z.B. mit PhoneGap) schon gegangen worden.
> Bspw. sind webOS Anwendungen HTML+CSS+Javascript, die man mittlerweile
> auch mit nativem Code "unterstützen" kann.

Bei normalen PC-Anwendungen ist das alles kein großes Thema. Alles, was 
nur ansatzweise zeitkritisch ist, ist ohnehin kein Thema für 
Webanwendungen. Webanwendungen wiederum haben den Vorteil, dass auf dem 
Desktop nicht viel Software außer einem Browser+Plugin vorhanden sein 
muss. Da sehe ich eigentlich auch kein .NET. Und ob der Anbieter nun 
unbedingt auf eine Microsoft-Lösung setzen muss, ist sein Problem. Das 
geht aber mittlerweile auch meilenweit vom Thema weg...

> QML ist keine Weiterentwicklung, sondern eine an Javascript angelehnte
> Neuentwicklung.

QML ist zusätzlich zum Framework (insbesondere für mobile Anwendungen) 
hinzugekommen und damit ist das eine Weiterentwicklung des gesamten 
Frameworks (es sind eben neue Funktionen hinzugekommen) und kein 
"Wegwerfen und Ersetzen", wie das bei WindowsForms der Fall ist.

> Es gibt bei MS klare Aussagen zum Produkt-Lifecycle. D.h. fünf Jahre
> nach dem Erscheinen Mainstream-Support (Feature requests, security
> updates, non-security hotfixes) und zehn Jahre Extended-Support
> (security updates und EHSA non-security hotfixes, letztere sind
> kostenpflichtig)

5 Jahre sind nichts, wenn man Anwendungen entwickelt, die man über viele 
Jahre pflegen, supporten und weiterentwickeln muss.
WindowsForms 2.0 gilt beispielsweise seit 2008 als komplett in Mono 
abgebildet und ist schon seit WPF wieder tot. Das sind nicht annähernd 5 
Jahre, das ist gar nichts. Und auf solchen Technologien soll man seine 
Geschäftsgrundlage aufbauen? Das kann doch nur ein schlechter Witz sein.

> Windows CE ist seit geraumer Zeit fast vollständig im Quelltext
> verfügbar
> http://msdn.microsoft.com/en-us/windowsembedded/ce...
> den Quelltext des NET-Frameworks bekommt jeder Entwickler frei Haus
> 
http://weblogs.asp.net/scottgu/archive/2008/01/16/...

Und was nützt das dem Entwickler? Offene Quellen sind gut und schön, 
aber wenn Microsoft meint, das Produkt zu beerdigen, dann wird das ohne 
Wenn und Aber beerdigt. Offene Quellen heißt ja noch lange nicht, dass 
der Quelltext auch frei ist und von anderen weiterentwickelt oder 
verändert werden darf.

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Und was nützt das dem Entwickler? Offene Quellen sind gut und schön,
> aber wenn Microsoft meint, das Produkt zu beerdigen, dann wird das ohne
> Wenn und Aber beerdigt. Offene Quellen heißt ja noch lange nicht, dass
> der Quelltext auch frei ist und von anderen weiterentwickelt oder
> verändert werden darf.

und außerdem heißt das nicht, dass man ein system ähnlich zuverlässig, 
wie openBSD, lynxOS, oder, oder ,oder hat.. ich gehe bei windows nicht 
davon aus, dass der kernel ähnlich gut "auditiert" ist, wie bei solchen 
systemen. außerdem zielt windows auf eine ganz andere userbase ab. ich 
möchte ich wichtigen geschäftsprozessen auf simple, flache 
funktionierende und sichere lösungen setzen und nicht auf kernel und OS, 
die für den consumer markt und das wohnzimmer entwickelt wurden. ich 
will kein klickibunti, ich will professionelle und kompetente lösungen, 
die jahrelang halten und auf die man sich verlassen kann. die meisten 
firmen scheinen das leider anders zu sehen.

Arc Net schrieb:
> Dr.Net schrieb:
>> embrace, extend, extinguish nicht.. viele firmen ziehen aber grade
>> daraus riesenprofit. die sagen ihren kunden dann:
>
> Jede Firma die Produkte entwickelt, verhält sich so.

das stimmt nicht und ich finde es unethisch, die eigenen produkte nach 
einer bestimmten zeitspanne wegzuwerfen und den kunden zum umstieg zu 
nötigen. das ist ja wohl das ziel der sache. ich befürworte lösungen die 
für jetzt und die zukunft einsetzbar und fortschrittlich sind und sofern 
ich so etwas bekomme, zahle ich als firma auch lieber für 
professionellen support, als für immer neue lizenzen und die immer 
wieder neue entwicklungsarbeit, die ja eigentlich nur zum geld 
generieren verwertet wird.

welche seriöse firma kann heute sagen sie läuft heute mit den gleichen - 
zwar gewarteten und geupdateten systemen, aber im grunde den gleichen 
systemen, wie vor 10-20-30 jahren?

braucht eine tankstellen-kasse oder ein datenbankcluster oder die 
verwaltung einer bank immer die neueste software, die neuen 
schnickschnack mitbringt?

grade zum beispiel im bankensektor wird doch, denke ich zu einem großen 
teil auf BSD-abkömmlinge und Eiffel usw. gebaut. oder hat jemand in der 
innersten infrastruktur einer bank schonmal windows 7 mit .net 4 und 
silverlight gefunden?

in einer bank gehts ums geld und da muss das alles stimmen. aber was ist 
mit anderen branchen? kommt es da nicht auf korrektheit, sicherheit usw. 
an?

Autor: Kama (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch die Banken interessiert das nicht, genausowenig, wie Siemens. 
Zumindest wenns um Consumer geht.

Geldautomaten laufen nicht selten unter Windows, und das mit 
Netzerkanschluss. Wie und warum Siemens kürzlich mit WinCE und den SPSen 
aufs Maul gefallen ist, hat sich wohl auch herumgesprochen.

Glücklicherweise hat man ja bei Microsoft (im Gegensatz zu Linux) einen 
Ansprechpartner, bei dem man Schadenersatz einfordern kann grööööööhl

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kama schrieb:
> bei dem man Schadenersatz einfordern kann grööööööhl

Du willst Schadensersatz bei einem kostenlosen Produkt fordern? Von wem 
denn?

Autor: Dr.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Kama schrieb:
>> bei dem man Schadenersatz einfordern kann grööööööhl
>
> Du willst Schadensersatz bei einem kostenlosen Produkt fordern? Von wem
> denn?

seit wann ist windows kostenlos?

Kama schrieb:
> Auch die Banken interessiert das nicht, genausowenig, wie Siemens.
> Zumindest wenns um Consumer geht.

verdammt schade..

Autor: Aeon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C# hat wie jeder sagt, sehr wenig mit C++ zu tun.
Da kannse schon die Klassenbibliothek bzw. die Klassen nehmen und 
vergleichen. Und dann noch die: Pointer, Fehlerbehandlung usw.
Vom C# kann man außerdem den Quellcode auslesen, was ziemlich schlecht 
ist, wenn du dein Programm verkaufen willst. Wie schon gesagt braucht C# 
immer die .Net Framework, die nicht jeder hat.
Und C# ist sehr wohl fast das gleiche wie VB. Der Unterschied liegt 
meist nur darin, dass in VB die Befehle in Wörtern ausgeschrieben werden 
zb.:
die For Schleife, in C# aber diesmal wie in C++.
Weil die .Net Framework auf die Windows Api aufgebaut ist, wird niemals 
eine funktionierende Framework für Linux oder andere Plattformen geben.
C# = für einfache Anwendungen, Privatgebrauch
C++ = für schnelle und größere Anwendungen, für den Verkauf(zb.: 
Spieleprogrammierung)

Das erstma von meiner Seite

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kinder Kinder Kinder. Immer das selbe Gehampel. Mich wundert nur, dass 
noch niemand popkorn ausgepackt hat. Da lässt einer etwas von wegen 
"Mir gefällt c# besser" fallen, und sei es nur in einem Nebensatz und 
schon geht die Schlammschlacht los...

Autor: Kixx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sven H.
> Mich wundert nur, dass
> noch niemand popkorn ausgepackt hat

FullACK...

P.S. Ich hab das Popkorn seit ein paar Beiträgen neben mir ;-)

Autor: Ist me (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian___ schrieb:
> Kixx schrieb:
>> Dir ist schon klar das in den IDE's für C++, egal welche Biblio. (ob MFC
>> oder Qt) die GUI fast identisch "zusammengeklickt" werden kann wie in C#
>
> ja, aber WPF ist doch ne andere geschichte.
> Zumindest wenn man Databinding und Property Changed Trigger nutzt.
> Um mit C++ ne hübsche GUI zu bauen bedarf es doch schon recht viel
> auffwand.
>
> Desweiteren hat man bei C# ein recht umfangreiches Framwork was weit
> über die Standard Lib. bei C++ hinaus geht.
> Es sind die kleinigkeiten die einem bei .Net das leben enorm
> erleichtern.
> Angefangen von XML serilisation über Generics bis hin zu gut
> verwendbaren Netzwerk klassen.

Du hast aber schon gesehen das der Ribbon Designer im VS nur für MFC C++ 
Nativ Code ist?

Du hast recht das .net Framwork ist umfangreich, leider endet die 
Sprache am Ende des Frameworks, ein anderes für C# gibbet bisher 
nicht.Für C++ etliche, einige davon sind um einiges umfangreicher sind 
als .net andere spezifisch.
C# ist eine portable Sprache auf allen Systemen wo .net läuft, also Win 
NT ab W2k bis W7 ,also wenn portabilität wichtig ist währe das so nicht 
die richtige Sprache ^^.Prozeduale oder Funktionale Ansätze fehlen 
völlig. Methaprogrammierung ein Graus, default Werte für Funtionen hat 
man gerade nachgereicht. Eine Funktion als Parameter übergeben ist ein 
Riesentipper , bei c++ dagegen ein mini Brainer . Design teilweise 
schlecht, z.b.console Eingabe dann Cast dabei wird die Exeption geworfen 
also bei der Verarbeitung nicht bei der Eingabe und diverse anderes.
Eine Instanz von "Hello World" bei .Net ~700 MB Arbeitsspeicher ^^, Cpp 
~5 MB. Und ja gestützte Versuche haben gezeigt das c++ genauso langsam 
seien kann wie c# oder Java in der Ausführung, wenn mann denn auch so 
progt wie in Java oder C#, wenn mann das richtig macht schaut das anders 
aus. Oder neulich der Supergaudi wo mir einer zeigt das C++ sogar die 
gleiche Berechnunsgzeit hat wie C#, jop mit Cpp/cli Copy Paste und 
bischen Syntax korrigiert ^^.

Microsofts Statement Native Code /MFC hat bei MS priorität A , .net ist 
die Antwort auf Java. MFC hat beim letzten VS 2010 mehr neue Klassen 
bekommen als das .Net gesamt an Klassen hat.
Gerade für Studis die sich auf Algos konzentrieren statt auf den Rest 
super. Die günstigeren Entwicklungskosten ergeben sich eher aus den 
geringeren Stundenlöhnen als aus der Enwticklungszeit.

-----

@ Topic . schau dir mal MFC oder Qt an, für Visual STudio Pro mit MFC 
gibt es Schulversionen für lau oder Evaluierungsversionen die 180 Tage 
laufen. Auch gibt es Visual Studio Plugins für QT.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist me schrieb:
> Eine Instanz von "Hello World" bei .Net ~700 MB Arbeitsspeicher

Das macht deinen gesamten Beitrag unglaubwürdig.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber .NET auch nicht zwangsläufig besser :-)

Autor: Ist me (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Autor: Samuel K. (sam1994)
>
> Datum: 06.11.2010 01:19
>
>
>
>
>
>
>
> Ist me schrieb:
>
>> Eine Instanz von "Hello World" bei .Net ~700 MB Arbeitsspeicher
>
>
>
> Das macht deinen gesamten Beitrag unglaubwürdig.


Is aber so, deswegen kann ich dir jetzt nicht unbedingt folgen?

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist me schrieb:
> Du hast aber schon gesehen das der Ribbon Designer im VS nur für MFC C++
> Nativ Code ist?

WPF-Variante
http://www.microsoft.com/downloads/en/details.aspx...

> Für C++ etliche, einige davon sind um einiges umfangreicher sind
> als .net andere spezifisch.

Es gibt kein einziges C++Framework, welches auch nur annähernd so 
umfangreich ist.

> Prozeduale oder Funktionale Ansätze fehlen völlig.

C# ist wie C++ eine Multiparadigmen-Programmiersprache und unterstützt 
dies sehr wohl. Funktionale Programmierung inkl. Higher-Order-Functions, 
Currying etc.

> Methaprogrammierung ein Graus,

In C++, richtig. Wirkliche Metaprogrammierung mit Reflection, 
Introspection, Expression-Trees gibt's in C++ nicht.

> default Werte für Funtionen hat
> man gerade nachgereicht. Eine Funktion als Parameter übergeben ist ein
> Riesentipper , bei c++ dagegen ein mini Brainer .

Viel Spaß mit Member-Function-Pointer in C++

> Design teilweise
> schlecht, z.b.console Eingabe dann Cast dabei wird die Exeption geworfen
> also bei der Verarbeitung nicht bei der Eingabe und diverse anderes.
> Eine Instanz von "Hello World" bei .Net ~700 MB Arbeitsspeicher ^^, Cpp
> ~5 MB.

Jetzt wird's lächerlich, Hello World liegt, wenn's hochkommt, bei 1/100

> Microsofts Statement Native Code /MFC hat bei MS priorität A , .net ist
> die Antwort auf Java. MFC hat beim letzten VS 2010 mehr neue Klassen
> bekommen als das .Net gesamt an Klassen hat.

Das ist schon Heise-Niveau...
Die MFC (10.0) bestehen aus etwa 400 Klassen  .NET (3.5) aus etwa 10000.

Autor: Zabou (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist so nicht ganz eichtig, MFC hat mit dem letzten Visual Studio 400 
neue Klassen, zu den bestehenden, bekommen. Und da MS nie alte Zöpfe 
abschneidet ist die MFC so die derzeit größte Klassenbibliotek, einfach 
ewig gewachsen. 10000 Klassen soll das .net haben ? Sind doch wohl eher 
so um die 10000 Funtionen und ca 400 Klassen ohne sie genau gezählt zu 
haben.

Zur Methaprogrammierung gibt es eigentlich nichts besseres als CPP. In 
c# geht eigentlich nur OOP, auch wenn Lamdaausdrücke und co schon 
vorhanden, nur mit Namespace und Klasse. Für Funktionales halt F#, was 
noch in den Kinderschuhen steckt. Als wirklich Multiparadigma Sprache 
ist mir nur C++ bekannt und halt Scriptsprachen.

Unbeachtet der Tatsache das C# die first Class .Net Sprache ist, und das 
.Net für vieles extrem interesant ist, so gibt es viele Projekte wo C 
oder C++ interesanter sind. Eigentlich immer da wo Performance wichtig 
ist.
Und wie bischen weiter oben geschrieben wurde, Native Code und MFC 
empfiehlt MS wenn Performance wichtig ist. Genau wie Arbeitsspeicher, 
gerade bei mehreren Instanzen einer Application, wie zum Beispiel in 
Terminalserver Umgebungen.
Natürlich ist die Hardware heute viel besser als vor Jahren, und im 
Verhältniss auch günstiger. Allerdings stehen gerade in großen Firmen 
Netzwerke die da seit 10-15 Jahren stehen und nur Apö Apö ausgebaut 
werden, also Gurken mit 500 Mhz und Windows Nt 4.0 und o Graus auch im 
Serverbereich^^. Ein MFC Client einer CRM/ERP App läuft halt mit 20 oder 
40 MB Arbeitspeicher,ob Hello World nun genau 700 MB braucht in .Net 
müßte man sich nochmal anschauen , waren aber einige hundert MB.

Die Einschätzung bischen weiter oben ist gar nicht so Praxisfern, .Net 
und Java als Schulsprachen und oft Nativc Code in der Praxis. Auch wenn 
ich mitterweile neben Perl und Korn Shell die Power Shell richtig lieb 
gewonnen habe, mit .Net mach ich nur kleine Sachen, alles was bischen 
größer ist mit MFC oder auch mit QT ( welches mit C++ ähnlich 
abstrahiert arbeiten läst wie mit .net und performancetechnisch zwichen 
MFC und .Net liegt. ).  Wenn ich mir anschau was ein C# Developper in 
Berlin verdient 1600,- Brutto. Dafür würde ich mir den Wecker nicht 
stellen, erst recht nicht eine MFC App erweitern / entwickeln. Dafür ist 
der Bildungsaufwand gerade bei MFC um einiges höher als bei .Net.

Autor: Zabou (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das eine Ribbon Designer für WPF oder die Integration ?

Autor: ähem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 10000 Klassen soll das .net haben ? Sind doch wohl eher
> so um die 10000 Funtionen und ca 400 Klassen ohne sie genau gezählt zu
> haben.

http://de.wikipedia.org/wiki/.NET

"Die Framework Class Library (FCL) umfasst in der aktuellen Version 3.5 
etwa 11.400 Klassen und andere Datentypen, die in mehr als 300 
sogenannte Namensräume (Namespaces) unterteilt sind."

Autor: ähem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn ich mir anschau was ein C# Developper in
> Berlin verdient 1600,- Brutto. Dafür würde ich mir den Wecker nicht
> stellen, erst recht nicht eine MFC App erweitern / entwickeln.

Na wenn die Leistung so billig zu haben ist dann wären die Firmen doch 
geradzu dumm weiterhin viel Geld für C++/MFC Entwicklung auf den Tisch 
zu legen oder? Das gesparte Geld wäre dann frei um die alten 500 MHz 
Gurken zu entsorgen und sich endlich mal aktuelle HW anzuschaffen.

Autor: Zabou (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ähem
Die Kosten für Hardware sind der kleinste Teil, Lizenzen sind das was 
Geld kostet. Gerade Cytrix, Exchange, Office und und und.

Und wenn du dir mal vorstellst das z.b. in einem größerem Call Center, 
wie zum Bsp SNT für E Plus, in der Prime Time ca 1 K User gleichzeitig 
auf eine Terminalserverfarm zugreift kannst du dir ausrechnen, auch wenn 
die Hardware in solchen Umgebungen relativ aktuell ist, warum Nativ Code 
bei den Apps bevorzugt wird.

Und mal zu deinen 11400 Klassen und 300 Nampespaces. Traue keinem Wiki 
Artikel den du nicht selber gefälscht hast ^^. Die 11400 Klassen möchte 
ich mal sehen, vermutlich reden die von Funktionen. MFC ist wie schon 
erwähnt das älteste der aktuellen Framworks und über die Zeit stetig 
gewachsen, und auch laut Aussage MS das größte Framwork von MS. Und wenn 
die das nicht wissen, wer dann ?
Bis Visualstudio 2008 war der einzige Unterschied von Express ( 
kostenfrei ) zu VS Standart die MFC. Wenn das .Net so interesannt ist im 
Vergleich zur MFC, warum gibt es die Entwicklungsumgebung für .Net für 
umsonst und MFC kostet Geld ?

/*
Erinnert ein wenig an die Schulzeit, Quartet von Autos und co . Glaub 
gab auch ein Dönerquartet neulich irgendie gesehen, mach doch ein 
Frameworkquartet mit Anzahl Klassen. ^^ */

Schau dir mal die Übersicht MFC Klassen an, dazu Winapi ohne Framwork, 
Posix ( unglaublich gibts auch bei WIndows NT), und diverse andere 
Frameworks/Libs wie qt, gtk++, fltk, Boost und und und . Dazu noch den 
Sprachumfang von C++ selbst. All das geht zu nutzen mit C++.

Hast du schon mal mit MFC und C++ gearbeitet?

Aber irgendwie sorry, das hier eigentlich ein Trollalarm Topic, bzw die 
Discussion

Autor: ähem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zabou (Gast) schrieb:

> Und mal zu deinen 11400 Klassen und 300 Nampespaces.

Genauigkeit fängt mit der Sprache an. Es sind nicht MEINE Klassen. MS 
gehört mir (leider) nicht.

> Traue keinem Wiki
> Artikel den du nicht selber gefälscht hast ^^.

Weißt du was mir schon oft aufgefallen ist, immer dann wenn Unwissenheit 
verbreitet wird beruft man sich der Verbreiter gerne auf angebliche 
"Fälschungen". Wenn du meinst hier wurde gefäschlt, dann beweise es 
gefälligst.

> Die 11400 Klassen möchte
> ich mal sehen,

Dann schau sie dir halt an. Ist alles öffentlich und nichts geheim.

> Wenn das .Net so interesannt ist im
> Vergleich zur MFC, warum gibt es die Entwicklungsumgebung für .Net für
> umsonst und MFC kostet Geld ?

Weil das .NET (inzwischen) integraler Bestandteil des Microsoft Windows 
Betriebssystems ist und MFC nur eine (von vielen) externen 
Klassenbibliotheken ist (die jedoch von MS stammt). Warum das Ding 
zusätzlich Geld erfordert fragste besser MS.

> Hast du schon mal mit MFC und C++ gearbeitet?

Um die MFC habe ich immer einen großen Bogen gemacht, weil mir die good 
old Win32-API durchschaubarer und damit sympathischer waren. Herr 
Petzold lässt grüßen.

> Aber irgendwie sorry, das hier eigentlich ein Trollalarm

Auch das ist immer wieder die gleiche Leier. Wenn etwas nicht passt ist 
es getrollt. Kinder, Kinder ..

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zabou schrieb:
> 10000 Klassen soll das .net haben ? Sind doch wohl eher
> so um die 10000 Funtionen und ca 400 Klassen ohne sie genau gezählt zu
> haben.

Wie schon erwähnt, nein.
Klassendiagramm MFC
http://msdn.microsoft.com/en-us/library/ws8s10w4.aspx
Statistik für das .NET-Framework
http://blogs.msdn.com/b/brada/archive/2008/03/17/n...

> Zur Methaprogrammierung gibt es eigentlich nichts besseres als CPP. In
> c# geht eigentlich nur OOP, auch wenn Lamdaausdrücke und co schon
> vorhanden, nur mit Namespace und Klasse.

Lambdaausdrücke haben nichts mit Metaprogrammierung zu tun.
Kurz gesagt ist Metaprogrammierung das Programmieren eines Programms, 
das ein anderes oder sich selbst schreibt und/oder verändert (auch zur 
Laufzeit).
Je nach Anforderungen braucht's dazu die oben schon erwähnten Merkmale 
Reflection, (Type-) Introspection und Expression Trees / ASTs und nicht 
nur Templates und den rudimentären typeid/dynamic_cast Kram aus C++.

> Für Funktionales halt F#, was noch in den Kinderschuhen steckt.

Deshalb wird's mit VS2010 ausgeliefert und in etlichen Banken und 
Versicherungen produktiv eingesetzt...

> Als wirklich Multiparadigma Sprache
> ist mir nur C++ bekannt und halt Scriptsprachen.

Aus dem Stegreif mal einige (die größtenteils weit über das mit C++ 
mögliche hinausgehen): C#, F#, VB, Ada, Scala, Python, Ruby, Java, 
OCaml, ATS, Javascript, Erlang, Lisp

>
> Unbeachtet der Tatsache das C# die first Class .Net Sprache ist, und das
> .Net für vieles extrem interesant ist, so gibt es viele Projekte wo C
> oder C++ interesanter sind. Eigentlich immer da wo Performance wichtig
> ist.

Auch da wird's zunehmend für C++ eng bzw. werden dann nur die 
vergleichsweise kleinen Codeteile, die wirklich optimiert werden müssen, 
in C oder C++ gemacht.

> Ein MFC Client einer CRM/ERP App läuft halt mit 20 oder
> 40 MB Arbeitspeicher,ob Hello World nun genau 700 MB braucht in .Net
> müßte man sich nochmal anschauen , waren aber einige hundert MB.

Was dort leicht verwirren kann sind die Angaben im Task Manager etc. Was 
interessiert sind die Private Bytes und der Working set, nicht wie groß 
der virtuelle (nicht benutzte) Arbeitsspeicher ist.

> Wenn ich mir anschau was ein C# Developper in
> Berlin verdient 1600,- Brutto.

Für einen Fachinformatiker vllt. wer als Ing./Inf. dafür arbeitet -> 
selber schuld. Nächstes Jahr gibt's die Arbeitnehmerfreizügigkeit auf 
die Bitkom/BDI etc. schon so lange gewartet haben... 
http://www.heise.de/newsticker/meldung/Fachkraefte...

> Dafür würde ich mir den Wecker nicht
> stellen, erst recht nicht eine MFC App erweitern / entwickeln. Dafür ist
> der Bildungsaufwand gerade bei MFC um einiges höher als bei .Net.

Nicht wenn man das - vernünftig - nutzen will.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zabou schrieb:
> Und mal zu deinen 11400 Klassen und 300 Nampespaces. Traue keinem Wiki
> Artikel den du nicht selber gefälscht hast ^^.

Der Wiki-Schreiber hat sich diese Informationen nicht aus den Fingern
gesaugt, sondern er verweist auf eine Seite von Microsoft höchstselbst.

> Die 11400 Klassen möchte ich mal sehen, vermutlich reden die von
> Funktionen.

Von den Members gibt es sogar 109657 :)

Kein Zweifel, diese Bibliothek ist ein wahres Monster. Allerdings rela-
tivieren sich die Zahlen etwas, wenn man sich vor Augen hält, was da
alles gezählt wird:

Die Zahl 11417 bezieht sich nicht nur auf Klassen, sondern auf Datenty-
pen jeglicher Art, darunter fallen bspw. auch Enums, von denen es sehr
viele gibt. Aber auch unter den Klassen gibt es viele triviale, die
keine eigenen Methoden definieren, sondern ihre gesamte Funktionalität
erben. Fast alle Exception-Klassen gehören dazu. Auch davon gibt es sehr
viele.

Zu der astronomischen Zahl der Members von 109657, zählt bspw. jedes
einzelne Enum-Element, da kommt schon einiges zusammen.

Die MFC-Bibliothek ist mit der .NET-FCL nicht direkt vergleichbar. Die
MFC stellt im Wesentlichen einen C++-Wrapper für das Windows-API dar,
die FCL hingegen enthält sehr viele Funktionalitäten, die bei der
klassischen MFC-Programmierung in Zusatzbibliotheken enthalten sind, da
sie sich nicht auf das Windows-API beziehen.

Nimmt man die MFC und alle von MS gelieferten Zusatzbibliotheken
zusammen und zählt alle darin enthaltenen Datentypen und -Elemente in
gleicher Weise wie bei der FCL, kommen auch hier sehr große Zahlen
heraus, die weit über den oben genannten 400 liegen. Ganz so viele wie
bei der FCL werden es aber trotzdem nicht sein, allein schon deswegen,
weil die ganzen Funktionen zur Verwaltung der Laufzeitmaschinerie von
.NET entfallen.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Die Zahl 11417 bezieht sich nicht nur auf Klassen, sondern auf Datenty-
> pen jeglicher Art, darunter fallen bspw. auch Enums, von denen es sehr
> viele gibt. Aber auch unter den Klassen gibt es viele triviale, die
> keine eigenen Methoden definieren, sondern ihre gesamte Funktionalität
> erben. Fast alle Exception-Klassen gehören dazu. Auch davon gibt es sehr
> viele.



>
> Zu der astronomischen Zahl der Members von 109657, zählt bspw. jedes
> einzelne Enum-Element...

Nein, GetStats liefert hier für 
GetStats(@"C:\Windows\Microsoft.NET\Framework\v4.0.30319", 0, 0, 0);
8680 öffentliche Klassen, 230 öffentliche Structs mit insgesamt 237960 
öffentlichen Methoden
Bei den Internen kämen dann noch über 19000 Klassen mit >400000 Methoden 
hinzu.

Quick&Dirty
       public Tuple<int, int, int> GetStats(string baseDir, int numClasses, int numStructs, int numMethods) {
            if (Directory.Exists(baseDir + @"\WPF")) GetStats(baseDir + @"\WPF", numClasses, numStructs, numMethods);
            var dllNames = from fileName in Directory.GetFiles(baseDir) where Path.GetExtension(fileName) == ".dll" select fileName;  
            
            foreach (var dllName in dllNames) {
                try {
                    var asm = Assembly.LoadFrom(dllName);
                    var types = asm.GetTypes();
                    foreach (var type in types) {
                        if (type.IsValueType && type.IsPublic && !type.IsEnum) {
                            numStructs++;
                            numMethods += type.GetMethods(BindingFlags.Public | BindingFlags.Instance).Length;
                            numMethods += type.GetMethods(BindingFlags.Public | BindingFlags.Static).Length;
                        }
                        if (type.IsClass && type.IsPublic) {
                            numClasses++;
                            numMethods += type.GetMethods(BindingFlags.Public | BindingFlags.Instance).Length;
                            numMethods += type.GetMethods(BindingFlags.Public | BindingFlags.Static).Length;
                        }
                    }
                } catch {
                }
            }
            return Tuple.Create<int, int, int>(numClasses, numStructs, numMethods);
        }

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Yalu X. schrieb:
>> ...
>
> Nein,

Ok, dann hat MS bzw. ihr Angestellter Brad Abrams eben gelogen:

  http://blogs.msdn.com/b/brada/archive/2008/03/17/n...

> GetStats liefert hier für
> GetStats(@"C:\Windows\Microsoft.NET\Framework\v4.0.30319", 0, 0, 0);
> 8680 öffentliche Klassen, 230 öffentliche Structs mit insgesamt 237960
> öffentlichen Methoden
> Bei den Internen kämen dann noch über 19000 Klassen mit >400000 Methoden
> hinzu.

Das ist ja kein Widerspruch. Wahrscheinlich sind in .NET 4.0 gegenüber
der oben diskutierten Version 3.5 etliche neue Klassen und Methoden
hinzugekommen.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Arc Net schrieb:
>> Yalu X. schrieb:
>>> ...
>>
>> Nein,
>
> Ok, dann hat MS bzw. ihr Angestellter Brad Abrams eben gelogen:

Nein, Member != Methods, Classes + Structs != Types

>> 8680 öffentliche Klassen, 230 öffentliche Structs mit insgesamt 237960
>> öffentlichen Methoden
>> Bei den Internen kämen dann noch über 19000 Klassen mit >400000 Methoden
>> hinzu.
>
> Das ist ja kein Widerspruch. Wahrscheinlich sind in .NET 4.0 gegenüber
> der oben diskutierten Version 3.5 etliche neue Klassen und Methoden
> hinzugekommen.

Das auch

Autor: hmmmm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Qualität einer Sprache am Umfang des Frameworks festmachen, naja das 
ist Geschmacksache.

Schon spannend anzuschauen wie MS von 0 auf 100, oder zumindest in 
relativ kurzer Zeit, mit .Net ein richtig ausgewachsenes Framework auf 
die Beine gestellt hat.

Jedoch wie weiter oben beschrieben, Anwendung die auf Terminalservern 
laufen sowie alles was rechenintensiv ist, würde ich kein .net nehmen.

Und wenn es janz Chick werden soll nimm Delphi o0

@ Topic , vermutlich wird irgendwann die Intellisense nachgereicht fürs 
CLI bei VS 2010, aber entscheident ist das eher für Projekte die in 
Arbeit sind. Für neue Projekte sollte man eher mit C# für das .Net oder 
auch Native Code mit MFC oder qt sich beschäftigen.

Es schadet auch nix, sich eine ganze weile mit c++ in der Konsole 
aufzuhalten. Wenn man das kann ist der Weg in viele Frameworks relativ 
leicht. Da sowohl Java als auch C# sich am C++ Syntax bedienen, ist der 
Schritt dahinn auch nicht allzu groß.

Autor: Valentin Buck (nitnelav) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmmm schrieb:
> nimm Delphi

NEEEIIIN!!! Bitte nicht. Das ist das Schlimmste, was der Menschheit 
passieren konnte. Generationen von Schüler, mich eingeschlossen wurden 
und werden immer noch damit gefoltert!!!

An seine Informatikklausur denkend,
Valentin Buck

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist me schrieb:
>> Ist me schrieb:
>>
>>> Eine Instanz von "Hello World" bei .Net ~700 MB Arbeitsspeicher
>>
>>
>>
>> Das macht deinen gesamten Beitrag unglaubwürdig.
>
>
> Is aber so, deswegen kann ich dir jetzt nicht unbedingt folgen?

Ok damit du es auch verstehst:

Als Konsole
using System;
namespace Hello_World
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }
}
1360KB

Als WinForm
using System.Windows.Forms;
namespace Hello_World
{
    class Program
    {
        static void Main(string[] args)
        {
            Form f = new Form();
            f.Text = "Hello World";
            Button b = new Button();
            b.Text = "Beenden";
            b.Dock = DockStyle.Fill;
            b.DialogResult = DialogResult.OK;
            f.Controls.Add(b);
            f.ShowDialog();
        }
    }
}
6208KB

Beenden eines Programmes durch DialogResult sollte man eigentlich 
nicht verwenden. Ich habe das jetzt nur gemacht um nicht noch ein Event 
einzubauen. Dadurch ist der Code kürzer.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Als Konsole
> ...
> 1360KB
>
> Als WinFormusing System.Windows.Forms;
> ...
> 6208KB

Zum Vergleich, falls es jemanden interessiert:
als C mit puts unter Linux (gcc 4.3):
6.3 kB

Als C++ mit std__cout<<...:
8 kB

Aus der Erinnerung auf einem alten Atari ST mit Prospero-C: 2 kB
- und damals hat man sich darüber aufgeregt, daß ein leeres Programm
so groß ist in der aufgeblasenen Sprache C.

Autor: ikarus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Ich möchte mal wissen was du mit qt machen kannst und nicht mit c#?
Anwendungen auch für nicht MS-Betriebssysteme schreiben?
(Nein, mono gilt nicht, da nur bedingt kompatibel.)

Autor: hmmmm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Samuel, da fehlt bei der Konsolenversion ein getline, sonst kannst du 
dir nicht wirklich den Speicherverbrauch anschauen.

1360 gegenüber 400 in cpp ist schon ein Unterschied, auch der Dialog ist 
schon recht hungrig, da geht bei schlanker Programmierung schon ein ein 
Mainwindow mit MDi und diversen andockbaren Fenstern in Native Code.

Das ist halt der Tribut an die "Höhe" der Sprache, das schöne ist ja das 
mann die Wahl hat bei der Sprache für verschiedene Einsatzzwecke.

Autor: hmmmm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Zum Vergleich, falls es jemanden interessiert:
>
> als C mit puts unter Linux (gcc 4.3):
>
> 6.3 kB
>
>
>
> Als C++ mit std__cout<<...:
>
> 8 kB

Wow, meine 400 K waren VS mit W7 x64, 8 kb ist mal schlank

Autor: hmmmm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hab ich mal mit MFC getestet, 1088 KB mit OK / Cancel Standart 
buttons, statik Text und Dialogtitel , W7 x64 . ( Ohne eine Zeile Code 
zu schreiben, klicki klacki )

Hat jemand qt gerade griffbereit ?

Autor: Markus Volz (valvestino)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Leider kann ich Eure Behauptungen bzgl. der C#-Programmgröße nicht ganz 
nachvollziehen. Bei mir hat das oben angeführte Hello-World-Programm in 
C# mit VS2010, Platform AnyCPU unter Win7 x64, gerade mal 4.608 Bytes, 
wohlgemerkt Bytes, nicht KiloBytes! Allerdings habe ich es noch um einen 
Console.ReadKey() Aufruf erweitert. Insofern ist das bicht wirklich 
vergleichbar... ;-)

Im Arbeitsspeicher zur Laufzeit belegt das ganze dann tatsächlich ca. 
7,2 MB. Solche Zahlen sind allerdings immer mit Vorsicht zu 
interpretieren. Eine weitere Instanz des Programms belegt z.B. "nur 
noch" weitere 2,1 MB.

Gruß
Markus

Autor: Jean Player (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
mal meine 2 cents:
Qt Console "Hello World" als Release --> 10752 bytes
Qt Form mit Standard Buttons und statischem Text als Release -->27648 
bytes

Gruss

Autor: c# liebhaber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

[Ironie]
Ihr eingeschworene MemLeak freie C (C++) Gemeinde; fürchtet ihr euch so 
sehr vor Leak freier Programmierung? Fürchtet ihr euch, dass jeder 
einigermaßen fähige Programmierer eure perfekte, Leak freie Arbeit, mit 
einem so bösen Framework nachempfinden kann? Sogar mehr; eventuell sogar 
schneller (Dev Zeit) ist als ihr? Fürchtet ihr, mit eurer Multi OS 
Software (Linux 2% ?) am Kuchen nicht mehr teilhaben zu dürfen? 
(Immerhin bleibt euch SUN OS) Wehe dem, der die Zeit des RAD nicht 
erkennt. Aber solange man der unwissenden Geschäftsleitung sein 
Old-Shool-Wissen aufdrücken kann, bleibt zum Glück alles beim Alten. Und 
wenn nicht, bleibt die Hoffnung auf einen neuen Millenium Bug im 
Framework; auch 2000 erlebten die COBOL Mumien ihre neue Renaissance. 
Ein Horido auf viele MM für ein simplems "Hello World" ;-).
[/Ironie]

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du fertig bist, kann man sich jetzt wieder vernünftig weiter 
unterhalten, ja?

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmmm schrieb:
> Wow, meine 400 K waren VS mit W7 x64, 8 kb ist mal schlank

Also über 8k, 400k oder 5MB, darüber müssen wir uns bei den heutigen 
rampreisen nicht mehr streiten, oder?

Ich habe für meine 4GB Ram 40€ gezahlt (gut die waren auch gebraucht, 
trotzdem sehr guter Markenram). Zu wenig frei hatte ich nur einmal, als 
ein Programm ein Image von einer DVD komplett in den Ram laden wollte 
(4.7GB in 4GB). Da hat es leicht geruckelt!

Markus Volz schrieb:
> Leider kann ich Eure Behauptungen bzgl. der C#-Programmgröße nicht ganz
> nachvollziehen. Bei mir hat das oben angeführte Hello-World-Programm in
> C# mit VS2010, Platform AnyCPU unter Win7 x64, gerade mal 4.608 Bytes,
> wohlgemerkt Bytes, nicht KiloBytes! Allerdings habe ich es noch um einen
> Console.ReadKey() Aufruf erweitert. Insofern ist das bicht wirklich
> vergleichbar... ;-)

Ich hab unter Priv. Arbeitsspeicher verglichen.

Autor: hmmmm (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Also über 8k, 400k oder 5MB, darüber müssen wir uns bei den heutigen
>
> rampreisen nicht mehr streiten, oder?

So hab mal zum Spaß das Demopojekt von MS New Controls als Release 
getestet, Speicherverbrauch im Bild. Dazu kommt keine Virtuelle 
Maschiene was einen zweiten Heap Erzeugt und verwaltet.

Wenn mann jetzt mal die Kosten Differenz, für 2K oder 3K User die an 
einer Terminalserverfarm arbeiten, hochrechnet. Also mehr an Hardware / 
Strom / Kühlung, und selbst in kleinen Serverräumen mit 20-30 Servern 
steht eine Klima mit 15-20 KW, kann keine .Net Programmierung günstiger 
sein.

Was nicht bedeutet das mann bestimmte Dinge nicht besser oder 
effizienter mit c# lösen kann, halt das richtige für den richtigen 
Zweck.

Autor: hmmmm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c# liebhaber schrieb:
> mit eurer Multi OS
>
> Software (Linux 2% ?

Ich versuch dich mal über deinen Tellerrand schauen zu lassen.


Linux als Unix oides System (nicht Posix zertifiziert ) hat im Client 
Bereich mal abgesehen von Freaks nicht wirklich eine Bedeutung, wenn 
dann im Web Server Bereich. Apache hat da auch gut über 33 % 
Marktanteil. Was 2 gute Gründe hat, gemietete Web Server kommen mit 
kostenloser Serversoftware daher und SSH/SFTP ist gegenüber WEB DAV /FTP 
praktisch und sicher. Inhouse Server sind oft MS IIS.
Auch nicht schwach im Handy OS Bereich.
Die Schwächen von Linux sind kosten für Administration, 
Informationsbeschaffung sowie den grauenvollem Idealismus. Und mann hat 
die Wahl zwichen Stabel und Security Testet aber veraltet ( Read Head EP 
 Suse EP  Debian Stable ) oder open, nicht stable und security testet 
und Free Opensuse / Ubuntu ( Debian Testing ) Fedora.


MS ist im Home sowie in fast allen Officebereichen ganz weit vorne, 
vorallem durch einfache und kostengünstige Administration/Verwaltung. Zu 
den Stärken gehören vor allem ADS , Exchange & Office , MSSQL sowie 
Informationsbeschaffung und Softwarentwicklung für MS Systeme.

Aber MS macht noch mehr, mit XENIX hat MS die erste UNIX portierung für 
den X86 entwickelt, sowie mit IBM OS2 , MSDOS war gekauft.
MS überlies der SCO Group die Patentnutzungsrechte für Xenix, bezahlt 
hat SCO mit Aktien von SCO ( über 50 % ). SCO entwickelte daraus System 
5.
System 5 sowie Net BSD  sind die Basis aller Posix Zertifizieten System 
( HPUx , IBM ux , Sun Solaris und WIndows NT ).
MS kasiert hier für jede Lizenz indirekt, warum sich auch MAC von System 
5 trennte als Kern und die freie nicht Posix Version open / free BSD 
nutzte.



Wenn man jetzt mal vom Home und Office Bereich absieht, da läuft ganz 
viel mit UNIX, alle Telekomunikationsnetzte, viele Banken, Datenbanken 
und und und . Systeme die seit 30 Jahren stetig ausgebaut werden wo ein 
Einsatz von MS Windows Systemen nicht rechenbar oder SInnvoll ist.




Programmierung geht weit über den Bereich Windows CLient hinaus, und 
nicht nur zu Linux oder Mac hinn.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn man jetzt mal vom Home und Office Bereich absieht, da läuft ganz
> viel mit UNIX, alle Telekomunikationsnetzte, viele Banken,

Unsere Hausbank nutzte in ihren Clients noch nie Unix. Früher nutzten 
sie OS/2 später dann Windows NT.

Autor: hmmmm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Client bereich ja, viele der Anwendungen sind Terminalanwendungen und 
UNIX Datenbanken.
Das ist nebenbei eine gigantische Dimension, wenn alle Banken Weltweit 
Buchungen durchführen untereinander.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmmm schrieb:
> Samuel K. schrieb:
>> Also über 8k, 400k oder 5MB, darüber müssen wir uns bei den heutigen
>>
>> rampreisen nicht mehr streiten, oder?
>
> So hab mal zum Spaß das Demopojekt von MS New Controls als Release
> getestet, Speicherverbrauch im Bild. Dazu kommt keine Virtuelle
> Maschiene was einen zweiten Heap Erzeugt und verwaltet.
>
> Wenn mann jetzt mal die Kosten Differenz, für 2K oder 3K User die an
> einer Terminalserverfarm arbeiten, hochrechnet. Also mehr an Hardware /
> Strom / Kühlung, und selbst in kleinen Serverräumen mit 20-30 Servern
> steht eine Klima mit 15-20 KW, kann keine .Net Programmierung günstiger
> sein.
>
> Was nicht bedeutet das mann bestimmte Dinge nicht besser oder
> effizienter mit c# lösen kann, halt das richtige für den richtigen
> Zweck.

Wenn ich das richtig verstanden habe, meinst du, dass 2k * 5MB dann 
zuviel sind.

Das ist ja völlig richtig, aber wer lässt schon diesselbe Software 
gleichzeitig 3k mal  laufen. Da gibt es dann ein Programm das alles 
organisiert, verteilt und regelt.

Wenn ich was in c# schreibe bin ich deutlich schneller fertig als in 
c++. Das ist einer der Hauptgründe für mich meistens zu c# zu greifen.

Autor: hmmm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Wenn ich das richtig verstanden habe, meinst du, dass 2k * 5MB dann
>
> zuviel sind.
>
>
>
> Das ist ja völlig richtig, aber wer lässt schon diesselbe Software
>
> gleichzeitig 3k mal  laufen. Da gibt es dann ein Programm das alles
>
> organisiert, verteilt und regelt.

5 Mb sind in diesem Fall ein Dialog mit "Hello World" , da ist kein 
Datenmodell bei , kein Main WIndow und und und. CRM oder ERP Client 
unter .net dürfte pro Instanz so auf ca 60-100 MB kommen. Bei Native 
Code kommt man da mit ca 10-20 MB aus. Dazu kommt der Overhead an 
Prozessorlast. Das Frameworl selbst will auch ein bischen versorgt 
werden.

Ein Programm das alles Organisiert verteilt und Regelt ? Moderne 
Betriebssysteme sind in der Lage Prozessorlast und Speicher der 
Anwendungen zu Sharen. Ja bei einer Terminalserver Farm wird Last 
verteilt. Im Falle einer DB als Backend werden die Anwendungen auf den 
Terminalservern über ein NLB Cluster, je nach Last verteilt. Die 
Terminalserver müssen aber genug Speicher und Rechenkapazität, in der 
Summe,  für alle Instanzen haben.  Das bedeutet was man hier an 
Enntwicklungskosten spart kommt x fach an Strom und Hardwarekosten 
wieder drauf.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.