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?
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/ccli-und-winforms-macht-keinen-sinn/
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.
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/rebuilding-intellisense.aspx "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."
Guter Zeitpunkt direkt auf C# umzusteigen ;D
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...
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.
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?
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.
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
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
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.
Anwendungs- und Einsatz-Zweck ist doch das entscheindenste! Eigentlich ist alles der letzte dreck! Sorry - konnt mich net zurückhalten. ;-)
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.
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.
Viele Programmierer schaffen das ohne Tools.
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...
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!
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 !
Klaus Wachtler schrieb: > Viele Programmierer schaffen das ohne Tools. Ja, vor allem viele C-Programmierer, die sich für besonders intelligent halten. :)
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.
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.
.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.
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"
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
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.
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).
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.
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.
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.
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.
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...
Vll sollte man .net einfach mal unabhängig gegen c++ testen ich hatte bis jetzt keine perfomance probleme mit c#
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.
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.
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 ...)
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.
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.
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/languages/benchmarks.html Und wenn du noch wissen willst was an c++ schlecht ist: http://www.mistybeach.com/articles/WhyIDontLikeCPlusPlusForLargeProjects.html 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.
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.
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/languages/benchmarks.html 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 :)
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!
Da wirst du irgendwann Ossi-Angie treffen, die musst du dauernd anschauen! Und hinter dir steht Wessiwelle. Freu dich also nicht zu früh...
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.
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.
ja, beim Buchstabieren. Es hat ein Zeichen weniger.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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/02/15/wpf-in-visual-studio-2010-part-1.aspx, 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?FamilyID=f8c623ae-aef6-4a06-a185-05f59be47d67&displaylang=en). 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?FamilyId=8C09FD61-3F26-4555-AE17-3121B4F51D4D&displaylang=en > > 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/silverlight-as-an-alternative-to-powerpoint/ http://nui.joshland.org/2010/06/naturalshow-and-new-interviews.html ähnliches gibt's seit einigen Jahren in einer ganzen Reihe von WPF-Demos
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.
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/SquidReportOperatingSystems.htm http://en.wikipedia.org/wiki/Usage_share_of_operating_systems Linux: 1.88 % iPhone + iPad 1.97 %
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/SquidReportOperatingSystems.htm > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > 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.
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.
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/SquidReportOperatingSystems.htm > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > 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.
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.
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.
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.
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.
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.
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 :)
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/dd567722.aspx den Quelltext des NET-Frameworks bekommt jeder Entwickler frei Haus http://weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx 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/windowslp.mspx
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/dd567722.aspx > den Quelltext des NET-Frameworks bekommt jeder Entwickler frei Haus > http://weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx 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.
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?
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
Kama schrieb: > bei dem man Schadenersatz einfordern kann grööööööhl Du willst Schadensersatz bei einem kostenlosen Produkt fordern? Von wem denn?
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..
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
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...
@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 ;-)
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.
Ist me schrieb: > Eine Instanz von "Hello World" bei .Net ~700 MB Arbeitsspeicher Das macht deinen gesamten Beitrag unglaubwürdig.
Aber .NET auch nicht zwangsläufig besser :-)
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?
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?FamilyID=2bfc3187-74aa-4154-a670-76ef8bc2a0b4 > 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.
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.
Ist das eine Ribbon Designer für WPF oder die Integration ?
> 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."
> 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.
@ä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
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 ..
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/number-of-types-in-the-net-framework.aspx > 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-Zuzug-Gemischte-Reaktionen-auf-Beschluesse-der-Bundesregierung-166996.html > 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.
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.
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
1 | public Tuple<int, int, int> GetStats(string baseDir, int numClasses, int numStructs, int numMethods) { |
2 | if (Directory.Exists(baseDir + @"\WPF")) GetStats(baseDir + @"\WPF", numClasses, numStructs, numMethods); |
3 | var dllNames = from fileName in Directory.GetFiles(baseDir) where Path.GetExtension(fileName) == ".dll" select fileName; |
4 | |
5 | foreach (var dllName in dllNames) { |
6 | try { |
7 | var asm = Assembly.LoadFrom(dllName); |
8 | var types = asm.GetTypes(); |
9 | foreach (var type in types) { |
10 | if (type.IsValueType && type.IsPublic && !type.IsEnum) { |
11 | numStructs++; |
12 | numMethods += type.GetMethods(BindingFlags.Public | BindingFlags.Instance).Length; |
13 | numMethods += type.GetMethods(BindingFlags.Public | BindingFlags.Static).Length; |
14 | }
|
15 | if (type.IsClass && type.IsPublic) { |
16 | numClasses++; |
17 | numMethods += type.GetMethods(BindingFlags.Public | BindingFlags.Instance).Length; |
18 | numMethods += type.GetMethods(BindingFlags.Public | BindingFlags.Static).Length; |
19 | }
|
20 | }
|
21 | } catch { |
22 | }
|
23 | }
|
24 | return Tuple.Create<int, int, int>(numClasses, numStructs, numMethods); |
25 | }
|
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/number-of-types-in-the-net-framework.aspx > 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.
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
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ß.
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
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
1 | using System; |
2 | namespace Hello_World |
3 | {
|
4 | class Program |
5 | {
|
6 | static void Main(string[] args) |
7 | {
|
8 | Console.WriteLine("Hello World"); |
9 | }
|
10 | }
|
11 | }
|
1360KB Als WinForm
1 | using System.Windows.Forms; |
2 | namespace Hello_World |
3 | {
|
4 | class Program |
5 | {
|
6 | static void Main(string[] args) |
7 | {
|
8 | Form f = new Form(); |
9 | f.Text = "Hello World"; |
10 | Button b = new Button(); |
11 | b.Text = "Beenden"; |
12 | b.Dock = DockStyle.Fill; |
13 | b.DialogResult = DialogResult.OK; |
14 | f.Controls.Add(b); |
15 | f.ShowDialog(); |
16 | }
|
17 | }
|
18 | }
|
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.
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.
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.)
@ 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.
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
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 ?
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
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
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]
Wenn du fertig bist, kann man sich jetzt wieder vernünftig weiter unterhalten, ja?
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.
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.
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.
> 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.
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.
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.
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.