.net libs statisch linken?
-
Das wird schon von vielen anderen gemacht... schon wenn Du eine ATI Grafikkarte hast wird es automatisch (ohne Nachfrage) installiert...
PS: Und es kommt auch immer darauf an, wieviel Zeit und Geld Du in die Entwicklung des Produktes stecken willst. Der Aufwand für ein UI in C++ (MFC/QT) ist um ein wesentliches höher als mit Windows-Forms und C#...
-
Mit QT dürfte der Aufwand ungefähr der selbe sein.
-
hmmmmmmmmmmm schrieb:
Mit QT dürfte der Aufwand ungefähr der selbe sein.
Der selbe wie mit MFC... aber bei weitem grösser als mit C# und Windows-Forms...
-
Warum? Man hat doch bei QT auch einen Designer mit dem das Ruck-Zuck geht.
-
Das hast Du ja bei der MFC auch, oder?
Hast Du schon mal je mit C# und Windows-Forms gearbeitet?
Hast Du je schon mal eine bisschen komplexere und ansprechendere UI gemacht?
-
bei MFC hat man nur einen Resourcen-Editor. Das ist kein Vergleich.
-
Wie so eigentlich immer MFC (heißt Microsoft Foundation Classes) hat mit einem Editor so viel zu tun wie eine Indische "heilige" Kuh mit Pferderennen.
Visual Visual C++, HAWK IDE, usw. das meintest du warscheindlich. Die besitzen einen Resourcen-Editor.
-
rc schrieb:
bei MFC hat man nur einen Resourcen-Editor. Das ist kein Vergleich.
Der visuelle Part spielt i.d.R. bei einer etwas komplexen Applikation nur *einen* Teil der gesamten Aufwendungen für die Anwendung. Und meines Erachtens nach den geringsten...
Die effizient den .NET-Frameworkes (und hier speziell C#) IMHO wesentlich besser als mit C++ (egal ob MFC oder QT oder sonstwas). Zu beachten gilt auch das für debuggen im C++ Bereich viel mehr Zeit aufgewendet wird, da hier wesentlich einfach unetdeckte Fehler entstehen können (Pointer / casting / usw.)
-
Die effizient den .NET-Frameworkes (und hier speziell C#) IMHO wesentlich besser als mit C++ (egal ob MFC oder QT oder sonstwas).
bla bla bla
-
*will genaue infos schrieb:
bla bla bla
foreach / using / kein delete / viele UI-controls / UI-anchor / UI-docking / UI-builtin-RTL / UI-builtin-double-buffer / simple db-anbindung / events/delegates / properties / simples XML / builtin-XML-serialization / reflection / runtime-activate / klares override/new/virtual / internal (endlich kein friend mehr) / is / typeof / as / nullable-types / keine pointer / keine speicherüberschreiber / class-designer / refactoring / simples data-binding / inline-initialisation / einheitliches typsystem / vollständig objektorientiert / ...
-
Jochen Kalmbach schrieb:
*will genaue infos schrieb:
bla bla bla
foreach / using / kein delete / viele UI-controls / simple db-anbindung / events/delegates / properties / simples XML / builtin-XML-serialization / reflection / runtime-activate / klares override/new/virtual / internal (endlich kein friend mehr) / is / typeof / as / nullable-types / keine pointer / keine speicherüberschreiber / class-designer / refactoring / ...
sauber
Und nicht zu vergessen die DataBindings, mit denen man die Daten von Controls von den Daten von anderen Controls abhängig machen kann. Es fällt viel Form1::List1_Changed(...) weg :).
-
damit ist man sogar produktiver als in java.
-
Jochen Kalmbach schrieb:
hahgeh schrieb:
Ist es möglich eine Anwendung so zu erstellen, dass der Nutzer kein .net-Framework installiert haben muss, um das Programm auszuführen?
Nein. (es gibt zumindest keine offizielle Möglichkeit).
Doch
Thinstall - aber die Preise sind wohl indiskutabel für kleine Anwendungen und das System verfehlt den Sinn eines Frameworks vollkommen.Zum Thema Produktivität kann ich aber auch nur sagen dass man mit einer .Net Sprache zig mal produktiver arbeitet. Wenn dann die WPF erstmal in Mode kommen haben selbst Windows Forms ausgedient
-
WPF
-
WPF: Windows-Presentation-Foundation (ala Avalon)
-
Jochen Kalmbach schrieb:
WPF: Windows-Presentation-Foundation (ala Avalon)
Wenn dann aka, nicht ala
Gibts z.b. nen Rss Reader in unter 20 Zeilen irgendwo auf MSDN. Das nenn ich produktiv
-
Talla schrieb:
Wenn dann aka, nicht ala
Ich war zu lange im badischen...
