Ich habe vor, mal wieder mit einem neuen Projekt zu beginnen, kann mich aber nicht so recht entscheiden, welche Kombination ich am besten Wähle. Grundsätzlich gilt, eigenlich bin ich mit allen oben genannten Sprachen/Frameworks vertraut und ich könnte mein Projekt im Grunde in jeder Sprache/Framework realisieren. Letztens habe ich mal einen Geschwindigkeitsvergleich zwischen C#, C++/CLI (managed/unmanged) und C++ (MFC) gemacht. Da ich von umfangreichen Opperationen auf Arrays ausgehe, habe ich mal ein 1GB großes byte/unsinged char Array erzeugt, dieses gefüllt und einige einfache Opertionen durchgeführt und die Zeiten gemessen. Specherallokierung und freigabe lagen außerhalt meiner Meßschleife. Hier war C++/MFC mit 1250ms/1350ms (64bit/32bit) ab schnellsten. (VS2008 Std, Release version) C# war mit 2050ms ca 50% langsammer. Im managed mode brauchte die 32bit Version von C++/CLI genau so lange. Die 64 bit Version war etwas schnelle. Was mich allerdings erstaunt hat ist, daß in C++/CLI im unmanaged Mode deutlich langsammer war als im managed Mode. Zur Info, die komplette Schleife war entweder managed oder unmanaged. Es gab eine ständigen übergänge zwischen beiden Mode. Eigentlich hätte ich ja erwartet, daß unmanged C++/CLI (also native C++ Klassen und deren Code) genau so schnell ausgeführt werden, wie C++/MFC, aber irgendwie ist das wohl nicht so. Weiß einer woran das liegen kann? Die andere Frage, die ich mir stelle ist, soll ich .NET verwenden. Ich habe durchaus die Absicht das Programm vielleicht zu Verkaufen und da einen Kopierschutz einzubauen. Nach allem was man so über .Net Assemblies ließt, kann man die ja komplette zurückübersetzen. Klar ist das mit Sicherheit auch bei nativem Code möglich, aber wohl schwieriger als bei .NET. Oder kann man .NET Projekte auch vernünftig vor dem Zurückübersetzten schützen? Da das GDI+ auch in der MFC zur Verfügung steht, wäre das für mich eigentlich ok. Hat schon mal jemand die Kontainerklassen von STL und .NET verglichen. Wie sieht es da mit der Geschwindigkeit beim Sortieren und Suchen aus? Gibt es eigentlich Kommerzielle Produkte, welche auf .NET vertrauen? Ich meine nicht Büro, Verwaltungs oder Web Anwendungen, sondern eher so Dinge wie Textverarbeitungenssysteme, Videoschnitt, Bildbearbeitung, Datenbanken (Engine nicht Interface), CAD und CAM Software? Also reine Softwareprodukte die für Teuer Geld verkauft werden? Ich könnte mir vorstellen, daß Hardwaredongles nicht lange Bestand haben, wenn man den Code so leicht Zurückübersetzen kann. Von daher ein klares nein zu .NET?
Be Bo schrieb: > Nach allem was man so über .Net > Assemblies ließt, kann man die ja komplette zurückübersetzen. Um einen Kopierschutz zu umgehen muss der Quelltext nicht komplett zurück-übersetzt werden. Es gibt .NET-Obfuscator, ich denke damit kriegt man zumindest die Funktions- und Variablennamen heraus. Dongles sind einfach ein Pain-in-the-ass, für alle Beteiligten. JEDE SOFTWARE KANN KOPIERT WERDEN!!! Wie kommst du auf die Idee, du könntest Softwarekopien besser unterbinden als die großen Spielehersteller?
> JEDE SOFTWARE KANN KOPIERT WERDEN!!! Wie kommst du auf die Idee, du > könntest Softwarekopien besser unterbinden als die großen > Spielehersteller? Ich komme nicht auf die Idee. Ich habe nur gelesen, daß mit .NET Reflector so einiges möglich sein soll. Gibt's da eigentlich auch was freies ohne Zeitbeschränkung zum Rumspielen? > Dongles sind einfach ein Pain-in-the-ass, für alle Beteiligten. Es ging nicht um Dongles, sondern um teure/aufwendige Software für den Massenmarkt, welche in .NET geschrieben ist. Denn, wenn .NET so toll ist, warum benutzt das dann kaum ein großer Anbieter? Ich hatte mal ein Diktiergerät von Philips, da war die SW in .NET, aber das war's auch schon. Also auch wieder nur ein Utility und keine richtg große Software.
Be Bo schrieb: > Denn, wenn .NET so toll ist, warum benutzt das dann kaum ein großer > Anbieter? woran sieht du das es niemand nutzt. Ist doch eine exe wie jedes andere Programm auch. Und dem sieht man nicht sofort an ob es .net ist oder nicht. Wenn das Programm eine umfangreiche Oberfläche haben soll, denn nutzt ich .net. Für consolenprogramm die viel rechnen soll und da auch noch schnell nehme ich c++. In .net wird einem viel arbeit abgenommen, wo man in c++ erst viel irgendwelche libs braucht (datenbanken, imagebearbeitung ) Dein Geschwindigkeitsvergleich würde ich erstmal in frage stellen, es gibt viele was man in C++ und auch .net falsch machen kann. Wenn du das Programm nicht wirklich an die sprache angepasst hast, dann ist es kein wirklicher vergleich. (bei .net z.b. for statt foreach).
> woran sieht du das es niemand nutzt. Ist doch eine exe wie jedes andere > Programm auch. Und dem sieht man nicht sofort an ob es .net ist oder > nicht. Na ja, 1) sieht man es, wenn man es installiert. Die Installer wollen dann auch die .NET Bibliotheken updaten. Außerdem steht es meißtens unter den Systemvorraussetzungen. 2) habe ich mir mal die Mühe gemacht und verschiedene Programme auf meinem Rechner auf ILDasm gezogen. Bis auf die Programme, von denen ich wußte, daß sie auf .NET basieren, konnte ILDasm die anderen Programme nicht öffnen. Wenn .NET so toll wäre, dann müßten doch langsam auch mal große Softwarehäuser ihre Top-Applikationen auf .NET portieren. Damit würde ja die Entwicklung in Zukunft einfacher. Oder bringt denen das nichts, da sie die Funktionallität sowieso schon haben? > Geschwindigkeitsvergleich Nun ja, ich kann jetzt nicht behaupten, daß ich der große C# Experte bin, aber bei all meinen bisherigen Vergleiche waren die .NET varianten immer langsammer. Ich hatte auch mal mit C++/CLI ein und die gleiche Text-Renderfunktion benutze. Einmal als Komponente des .NET Frameworks und einmal die WinAPI Versionen. Und auch dort waren Unterschiede. Selbst wenn die Funktionen nicht 100% Deckungsgleich waren, aber sie haben für mich sichtbar die selber Aufgabe erfüllt. Ein mal war .NET 6x langsammer und einmal sogar 60x. Mag zwar fragwürdig sein, das so zu Vergleichen, aber für das Programm hätten alle 3 Funktionen funktionniert. Dabei war bei einer .NET Funktion die Ausgabe sogar schlechter. Und dann ist mir aufgefallen, daß .NET Formulare relativ langsam sind. Ich habe mal 250 Buttons in ein .NET-Form geklebt und das Form gestartet. Dann habe ich 250 Buttons in ein MFC Dialog geklebt und gestartet. Auch hier war ein geschätzter Unterschied von 3-4x langsammer gegenüber C++/MFC zu erkennen. Die Hauptfrage aber wäre: Warum ist unmanged C++/CLI Code (also C++) langsammer, als reiner C++ (native) Code. Und warum ist er sogar langsammer als managed C++/CLI Code. Oder optimiert der C++ Compieler hier nicht richtig? Ich hatte alle Speed Optimierungen aktiviert. Und der Block, den ich gemessen hatte war komplett im "#pragma unmanged" Block.
Be Bo schrieb: >> Denn, wenn .NET so toll ist, warum benutzt das dann kaum ein großer > Anbieter? Autodesk, MS2010 u. MSVS2012, MSO 2010 ... Wenn ich immer lese, das ".NET Geraffel", verstehe ich die Welt nicht mehr. Seltenst wurde uns Entwicklern soviel konform zu Tage. Mit dem Mono sogar Plattform unabhängig. Die ewig Gestrigen werden sich noch wundern, wenn ihre IDE oder ihre Compiler Tools nur noch mit OS unterstützt werden, die bei Ebay einen scheine Schmott kosten. Anstelle von Atmel wäre langsam mal Zeit. Ich hab nicht vor, einen Streit zu provozieren: aber wenn MS mit WIN8 scheitert: lernt schon mal Objective-C. Und gewöhnt euch daran, das Atmel Studio 7 nicht mehr kostenlos ist.
Be Bo schrieb: > Wenn .NET so toll wäre, dann müßten doch langsam auch mal große > Softwarehäuser ihre Top-Applikationen auf .NET portieren. also in Firmenumgebungen kenn ich schon einige Anwendungen. (Zeiterfassung, Auftragswesen) viele Anwendungen sind ja nicht neu und werden nicht komplett neu geschrieben. Es gibt keinen Grund eine C++ Anwendung die nur erweitert werden soll komplett neu zu schreiben. > .NET varianten immer langsammer. ja das ist ja ok, die frage wie viel langsamer sie sind. Dafür gibt es auch keine stack überschreiber und speicherzugriffsfehler. > Dann habe ich 250 Buttons in ein MFC Dialog geklebt und > gestartet. Auch hier war ein geschätzter Unterschied von 3-4x langsammer > gegenüber C++/MFC zu erkennen. naja in .net werden die button alle dynmaisch an das Kontrol angehangen. MFC läuft da komplett anders.
> (Zeiterfassung, Auftragswesen)
Das man kleine Tools und Helferlein in .NET schreibt, macht ja auch
Sinn. Da wäre der Overhead mit WinAPI wohl zu groß.
Be Bo schrieb: > Denn, wenn .NET so toll ist, warum benutzt das dann kaum ein großer > Anbieter? Weil es noch zu jung ist. Auch bei C++ haben erst nach etwa 10 Jahren einige Pioniere unter den Softwarefirmen begonnen zu überlegen, Neuent- wicklungen künftig in C++ statt in C zu entwickeln. Bis dann die ersten wirklich großen Produkte in C++ auf den Markt kamen, dauerte es noch einmal ein paar Jahre. .NET/C# ist heute etwa 10 Jahre alt, wir sind also gerade in der Phase, wo der eine oder andere Softwarehersteller sich Gedanken über einen Umstieg macht. Das betrifft aber nur komplette Neuentwicklungen, für bestehende Produkte oder bereits laufende Entwicklungen würde ein Umstieg sehr viel mehr Kosten als Nutzen bringen. Vielleicht werden zu Zeit tatsächlich Entwicklungen von Videoschnitt- oder CAD/CAM-Softwaren gestartet. Mit dem Erscheinen entsprechender Produkte ist aber erst in einigen Jahren zu rechnen. Komplette Neuentwicklungen sind heutzutage allerdings sehr selten, weil einfach die Kosten dafür zu hoch sind. Meistens wird auf Bestehendes (also bspw. in C++ programmierte Bibliotheken und Frameworks) aufgebaut, so dass es nicht sinnvoll ist die, Programmiersprache zu wechseln. Und Zwischenlösungen wie C++/CLI stehen die meisten Entwickler recht skep- tisch gegenüber, weil sie nur scheinbar einen weichen Übergang bieten. Auch Java, das schon deutlich älter als .NET/C# ist, hat es nie so rich- tig geschafft, außerhalb des Bereichs von Web-Anwendungen Fuß zu fassen. Im Web trumpft es mit dem "Write-Once-Run-Anywhere"-Prinzip auf, was aber in Arbeitsplatzumgebungen kein Vorteil, sondern eher ein Nachteil ist. .NET/C# als der "bessere" Java-Nachfolger muss sich zunächst einmal mit den gleichen Problemen herumschlagen und zusätzlich auch noch gegen Java ankämpfen. Auf breiter Basis durchsetzen wird sich .NET/C# — wenn überhaupt — wohl erst dann, wenn sich die Generation der C++- und Java-Programmierer allmählich zur Ruhe setzt. Aber wer weiß, ob bis dahin nicht schon die nächste softwaretechnische Errungenschaft als Ablösung von .NET und C# auf dem Plan steht. @Be Bo: Da du in der glücklichen Lage bist, mit vielen Alternativen (C++, C++/ CLI, C# und .NET, MFC, WinAPI) vertraut zu sein, würde ich an deiner Stelle diejenige wählen, in der das Entwickeln am meisten Spaß macht. Größere Projekte werden nämlich meist nicht durch fehlende Bleeding- Edge-Softwareentwicklungstechnologien ausgebremst, sondern durch die nachlassende Motivation der Entwickler. Kleinere technische Probleme wie das zu leichte Reverse-Engineering beim Einsatz von .NET als Plattform sind immer irgendwie lösbar und sollten die Entscheidung nicht wesentlich beeinflussen. Falls ein Obfuscator nicht ausreicht, kannst du immer noch die wirklich innovativen Teile deiner Software (die meist nur einen kleinen Anteil an der Gesamtsoft- ware haben) in einer Sprache schreiben, für die Native-Compilierung möglich ist.
Be Bo schrieb: > Dann habe ich 250 Buttons in ein MFC Dialog geklebt Wozu brauchst du 250 Buttons in einem Dialog? Unrealistische Test-Szenarien sind Zeitverschwendung. Die Frage ist doch nicht, wie schnell es ist, sondern ob es schnell genug ist. Für die Benutzeroberfläche kannst du nehmen, was du magst. Wenn du keine kapitalen Fehler einbaust, dann wird es schnell genug sein. Wenn deine Rechenzeiten bei 2050ms für "große" Datenmengen liegen, musst du dir keinen Kopf machen. eugler schrieb: > Mit dem > Mono sogar Plattform unabhängig. (dezentes hüsteln)
Be Bo schrieb: > Denn, wenn .NET so toll ist, warum benutzt das dann kaum ein großer > Anbieter? Ich hatte mal ein Diktiergerät von Philips, da war die SW in > .NET, aber das war's auch schon. Also auch wieder nur ein Utility und > keine richtg große Software. Wenn .NET keine richtig große Software 1) ist oder VS2010 45 Mio SLOCs davon die Hälfte Managed Code 2) oder Dynamics CRM oder das Bing Front-End 3) oder Paint.NET oder auf Umwegen u.a. Office Web Apps 4), Sims3, Developer.Mozilla.org 5) 1) http://referencesource.microsoft.com/netframework.aspx zu faul zum Zählen 2) http://channel9.msdn.com/shows/Going+Deep/Rico-Mariani-Visual-Studio-Today-Tomorrow-and-Beyond/ 3) http://channel9.msdn.com/Blogs/Charles/NET-45-in-Practice-Bing 4) http://projects.nikhilk.net/ScriptSharp/ 5) http://www.mono-project.com/Companies_Using_Mono Benchmarks: YMMV http://shootout.alioth.debian.org/
Be Bo schrieb: > Hier war C++/MFC mit 1250ms/1350ms (64bit/32bit) ab schnellsten. (VS2008 > Std, Release version) C# war mit 2050ms ca 50% langsammer. Im managed > mode brauchte die 32bit Version von C++/CLI genau so lange. Die 64 bit > Version war etwas schnelle. Was mich allerdings erstaunt hat ist, daß in > C++/CLI im unmanaged Mode deutlich langsammer war als im managed Mode. > Zur Info, die komplette Schleife war entweder managed oder unmanaged. Es > gab eine ständigen übergänge zwischen beiden Mode. > > Eigentlich hätte ich ja erwartet, daß unmanged C++/CLI (also native C++ > Klassen und deren Code) genau so schnell ausgeführt werden, wie C++/MFC, > aber irgendwie ist das wohl nicht so. Weiß einer woran das liegen kann? Thunking, siehe beispielsweise: http://de.wikipedia.org/wiki/Thunk http://msdn.microsoft.com/de-de/library/ms235292.aspx
Be Bo schrieb: >> JEDE SOFTWARE KANN KOPIERT WERDEN!!! Wie kommst du auf die Idee, du >> könntest Softwarekopien besser unterbinden als die großen >> Spielehersteller? > > Ich komme nicht auf die Idee. Ich habe nur gelesen, daß mit .NET > Reflector so einiges möglich sein soll. Gibt's da eigentlich auch was > freies ohne Zeitbeschränkung zum Rumspielen? ILSpy: http://wiki.sharpdevelop.net/ILSpy.ashx
Yalu X.: Ich habe mir jetzt mal die IDE von C# angesehen. Auch wenn ich nur das Std C# 2008 und die Express 2010 testen kann, muß ich zugeben, daß die .NET IDEs für c#/VBA um Welten besser sind, als die von C++(/CLI), leider :-( Mal abwarten was das VS2012 mit sich bringt und ob es da ein günstiges Update von der Std Version gibt. Gab's ja letztes auch. Zumindest das neue C++ soll ja deutlich besser geworden sein. Ansonsten beginne ich jetzt erst mal mit C#. Ich hatte auch mal über das MFC nachgedacht, aber da gibt's keine Dokumentation mehr und keiner weiß, wie es damit weitergeht. Es ist ohnehin erstaunlich, daß es derzeit für native Windowsprogrammierung keine vernünftige Tools mehr gibt. Alles was man findet scheint 10 Jahre alt zu sein. Und so etwas wie den Petzold zu Win95 gibt's für Win7 / Windows 8 auch nicht mehr. Ist schon irgendwie schade. Dabei sieht man doch bei der GDI++ Bibliothek, daß es möglicht ist einfachen Syntax und Top Performance unter einen Hut zu bekommen. @Konrad S.: 250 Control war nur zum testen. Real ist mir das mal aufgefallen, als ich ein Programm geschrieben haben, daß direkt beim Starten 6 Fenster mit durchschnittlich je 100 Custom Controls geladen hat. Das war das reinsten Pixelgewitter. Es hat ca. 3 Sekunden gedauert, bis alles aufgebaut war. Anfangs dachte ich, daß das an den umfangreichen Zeichenoperationen in meinen CustomControls lag. Also habe ich einfach mal ein Form generiert und eine ähnliche Anzahl enfacher Button hineingeklebt. Ergebnis: Es lag nicht an meinen CustomControls, sondern an .NET. Das witzige daran war, daß die CPU garnicht unter Volllast lieft. Im Grunde hätte es also schneller von statten gehen können. Bei nativer Windows Programmierung ist mir das noch nie so stark aufgefallen. @Ahellwig: Ich habe mir gerade mal mit ILSpy den Code meinem Test C# Programm angesehen. Das ist ja erschreckend, wie nah die Darstellung an den orginal Quelltext heranreicht. Nach dem ich das ganze dann mal mit dem Dotfuscator, der im VS-2008 enthalten ist, geschickt habe, sah es dann schon etwas besser aus. Zwar habe ich die Codekonstruktionen alle wiedergefunden, aber ohne aussagekräftige Class/Funktions/Variablen-Namen war nicht mehr gleich auf Anhieb klar, was das Programm machen sollte. Nur sollte man möglichst keine konstannten Strings verwenden, da die dann wieder etwas verraten. Leider erkennt man welche Assemblies verwendet wurden. So sieht man sofort, wo sich Forms/Controls verstecken. Leider funktionniert der Dotfuscator nicht bei Mixed-Mode Code. Was das Thunking angeht ist mir schon klar, daß der Datenaustausch zwischen beiden Welten Overhead mit sich bringt. Ich habe die Zeitmessung allerdings komplett in einer Nativen Klassen-Funktion durchgeführt, die mit den #pragmas unmanaged/managed umgeben war. Innerhalb der Funktion sollte da doch nun wirklich alles native laufen, oder? Einstellung war /clr.
Yalu X. schrieb: > Auch Java, das schon deutlich älter als .NET/C# ist, hat es nie so rich- > tig geschafft, außerhalb des Bereichs von Web-Anwendungen Fuß zu fassen. Da gibt es schon so einiges, was nicht web-spezifisch ist. Ich würde z.B. eclipse und Netbeans sehr wohl als erfolgreich bezeichnen. Teile von MATLAB und Lotus Notes und OpenOffice sind in Java geschrieben, dann die ganzen Android Apps, die SAP setzt Java ein, dann wäre da noch SPSS, Maple ist zum Teil in Java geschrieben, OSGi verwendet Java, MagicDraw ist in Java geschrieben, ...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.