www.mikrocontroller.net

Forum: PC-Programmierung Ist Visual C++ express 2010 NET?


Autor: Aalmarmelade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Ich habe früher mal hobbymässig mit Borland C++ Builder programmiert.
Später habe ich es dann mal mit Visual C++ 2008 express versucht. Mir 
wurde dann gesagt, dass sei eigentlich NET und nicht gewöhnliches C++.
Der Syntax von VS C++ 2008 express war jedenfalls nicht mit C++ von 
Borland zu vergleichen.

Stimmt dies?

Jetzt habe ich Visual C++ 2010 express installiert. Ist dies jetzt auch 
NET oder normales C++ oder kann man da wählen?

Auf eine Antwort würde ich mich freuen.


MfG

Aalmarmelade

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aalmarmelade schrieb:
> Ist dies jetzt auch
> NET oder normales C++ oder kann man da wählen?

das kann man auswählen, beim einen neuen Projekt muss du dich für die 
sprache entscheiden. (C++, C#, c++.net, J#, VB.net usw)

Autor: Aalmarmelade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter

Ich habe aber die Express-Version (Gratisversion)  um mal reinzuschauen.

Gruss

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

Bewertung
0 lesenswert
nicht lesenswert
Hinzu kommt noch die Möglichkeit, C zu nutzen. Das wird zwar im "Wizard" 
für neue Projekte nicht angeboten, es genügt aber, neu zu einem Projekt 
hinzugefügte Dateien als *.c abzuspeichern.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aalmarmelade schrieb:
> Ich habe aber die Express-Version (Gratisversion)  um mal reinzuschauen.

und was willst du damit sagen? Soweit ich weiss geht das dort genauso.

Autor: mkeller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt darauf an was du anwähltst:

MFC--> ist C++ mit MFC Klassenbibliothek
Win32 --> reines C++
Windows Forms --> .NET mit C++/CLI --> kein reines c++

Wenn du "reines"

Autor: Aalmarmelade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir Jemand sagen, wie ich die IDE richtig Einstellen muss, damit 
ich "normal" C++ ohne NET programmieren kann?


Ich habe ein Projekt angelegt.

_Datei
_Projekt
_Linke Seite "Visual C++" markiert
_Rechte Seite "Windows Forms-Anwendungen"
_Name vergeben

Habe ich jetzt das Programm so eingestellt dass ich ohne NET 
programmieren kann? Oder was habe ich falsch gemacht?

Wäre gut wenn ich so loslegen könne. Nicht dass ich danach das ganze 
Programm neu schreiben muss?

Gruss

Aalmarmelade

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

Bewertung
0 lesenswert
nicht lesenswert
Aalmarmelade schrieb:
> _Rechte Seite "Windows Forms-Anwendungen"

Das setzt auf .Net auf.

Autor: Aalmarmelade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann ich das verstehen?

Sind mit der Expressversion nur NET-Anwendungen möglich oder bin ich 
falsch vorgegangen?

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

Bewertung
0 lesenswert
nicht lesenswert
Nein, die Express-Version kann auch "echtes" C++ - nur die MFC fehlt. Du 
wirst also entweder eine andere oder keine C++-Klassenbibliothek nutzen 
müssen.

Autor: Aalmarmelade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok danke für die Hilfe

Autor: No.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Visual Studio 200xx ob Express oder Standard oder xxx
ist bezüglich C++ für WIN32-Anwendungen nicht mit
Borland C++ Builder (Turbo C++) vergleichbar, wenn
du GUI-Anwendungen erstellen willst.

Visual Studio ist, was den Komfort bezüglich des GUI-Design
betrifft, auf dem Stand von Visual Studio 6.0 stehen geblieben.

Für .NET-Anwendungen ist aber C# und für Hobby auch VB.NET
zu empfehlen.

Wenn du WIN32-Anwendungen mit dem Komfort des Borland C++
Builders erstellen willst, kann ich dir den Turbo C++ Explorer, der
einem Borland (Codegear) Developer Studio 2006 entspricht, empfehlen. Er 
müsste sich noch irgendwo im Netz downloaden lassen.

Das neuste Embarcadero RAD Studio 2010 (Nachfolger von Borland Delphi 
und
C++ Builder) ist für den Privatgebrauch leider zu teuer.

Das Embarcadero Rad Studio XE soll dann den Crossplatform Gedanken 
wieder
aufnehmen und neben Windows auch Mac und Linux unterstützen.

http://www.embarcadero.com/products/rad-studio

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

Bewertung
0 lesenswert
nicht lesenswert
No.Net schrieb:
> Visual Studio ist, was den Komfort bezüglich des GUI-Design
> betrifft, auf dem Stand von Visual Studio 6.0 stehen geblieben.

Wenn man MFC-Anwendungen damit pflegen oder weiterentwickeln musst, dann 
ist zumindest VS2008 eher ein Rückschritt, jedenfalls was die 
Integration von GUI-Editor und Codegenerator (in Form von Class- und 
App-Wizard) angeht.
Die mitgelieferte MFC selbst ist hingegen gegenüber der von VS6 ein 
deutlicher Fortschritt, da sie etliche neue Konzepte des C++-Standards 
umsetzt.

Die integrierte Onlinehilfe hingegen ist eher lausig, aber da ist man 
bei MS ja schon seit langem stetige Verschlechterung gewohnt.

(Ich beobachte das bereits seit Visual C++ 2.0, dem ersten überhaupt 
benutzbaren Entwicklungssystem für Win32 von Microsoft)

Die Zeit, mir VS2010 anzusehen, hatte ich bislang nicht.

Autor: Aalmarmelade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist dass ich früher einen uralten C++ Builder hatte, den ich 
relativ gut beherrschte. Den besitze ich abe nicht mehr.


Bei Visual C++ dot NET ist für mich die Einarbeitungszeit vermutlich 
sehr sehr sehr gross.

Möchte aber bei C++ bleiben.

Aus gesundheitlichen Gründen kann ich mir im Moment einfach kein 
Entwicklungssystem leisten.

Möchte aber aber mit programmieren ein bisschen Geld verdienen um bald 
ein C++ Entwicklungstool kaufen zu können

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man sollte sich aber doch fragen ob der Umstieg auf C# nicht doch 
sinnvoll ist. Ich schreibe auch gerne Program ohne gui in C++. Aber wenn 
es eine Gui haben soll bin ich mit c# wesentlich schneller. Und es hat 
nich die langen startzeiten wie java und braucht auch geführt nicht so 
viel speicher.

Schau es dir mal an, bevor du es ablehnst.

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

Bewertung
0 lesenswert
nicht lesenswert
Naja, Du könntest Dich auch in die Nutzung eines plattformübergreifenden 
GUI-Toolkits einarbeiten. Das hätte den Vorteil, daß damit entwickelte 
Anwendungen nicht nur unter Windows, sondern auch unter Linux und Mac OS 
X zum laufen zu bringen sind.

Verbreitet sind hier Qt und wxWidgets, beide lassen sich mit dem 
MS-Compiler nutzen.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> Naja, Du könntest Dich auch in die Nutzung eines plattformübergreifenden
> GUI-Toolkits einarbeiten. Das hätte den Vorteil, daß damit entwickelte
> Anwendungen nicht nur unter Windows, sondern auch unter Linux und Mac OS
> X zum laufen zu bringen sind.

Die relevanten Plattformen (Windows, Mac OS X) lassen sich mit 
Silverlight besser abdecken.

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

Bewertung
0 lesenswert
nicht lesenswert
Als Nutzer von OS X möchte ich aus Gründen der Hygiene kein 
"Silverlight" verwenden.

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach all dem was hier gesagt wurde:
Wenn ich auf MS-OS entwickeln möchte - und das möglichst 
voraussetzungsfrei, d. h. ich setze bei meinem Kunden oder Zielsystem 
eine absolut heterogene EDV-Struktur von Win-XP bis Win 7 voraus, habe 
keine Ahnung ob .Net vorhanden ist und wenn ja, in welcher Version.
(Ich meine also, ich gehe davon aus, dass mein Kunde weltweit agiert und 
absolut keine Ahnung hat, was vorzufinden ist, Win XP, SP?; Win 7: 32 
Bit, 64Bit? .Net?. Installation erlaubt? Das sind Fragestellungen, die 
mir persönlich auf den Tisch geknallt werden - also nicht ausgedacht)

Setze ich auf MFC - bleiben mir dann wirklich nur noch MS VC 6 und 7? 
Ist das nach Eurer Einschätzung so?
Sind die neuen Entwicklerwerkzeuge von MS in Bezug auf 
Abwärtskompatibilität so wenig brauchbar?
Oder ist das jetzt eine Überinterpretation meinerseits?
(Ich frage auch deshalb nach, weil ich nach der Überlegung das Visual 
Studio 2010 zu kaufen, nach der Produkt-Recherche bei MS nicht wirklich 
schlauer war, was ich da kaufen würde (und es deshalb vorerst gelassen 
habe)).

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

Bewertung
0 lesenswert
nicht lesenswert
Nils schrieb:
> Setze ich auf MFC - bleiben mir dann wirklich nur noch MS VC 6 und 7?
> Ist das nach Eurer Einschätzung so?

Nein. Auch mit den aktuellen Versionen ist MFC-Entwicklung möglich - ich 
nutze beruflich VS2008 dafür. Damit pflege ich einige Produkte, die 
teilweise seit über 15 Jahren in beständiger Weiterentwicklung sind.

> Sind die neuen Entwicklerwerkzeuge von MS in Bezug auf
> Abwärtskompatibilität so wenig brauchbar?

Man muss sich halt umgewöhnen, wenn man intensiv den Gebrauch der 
Codegeneratoren "AppWizard" und "ClassWizard" gewohnt ist, deren 
Funktionalität ist zwar nach wie vor vorhanden, sogar teilweise 
erweitert (so gibt es eine neue Basisklasse CHTMLDialog), aber gut 
versteckt.

Und die MFC selbst ist inhaltlich verbessert worden, so wurde 
beispielsweise CString gegenüber dem von VC6 her gewohnten massiv 
überarbeitet, und die Kollektionsklassen CList/CArray und Konsorten 
wurden an die neuen Möglichkeiten des C++-Standards angeglichen.

Der Debugger ist erheblich besser geworden, gerade in Hinblick auf das 
Remote Debugging, auch sind die Runtime Checks der CRT deutlich 
aufgebohrt worden.

Zumindest mit VS2008 kann man durchaus MFC-Projekte sowohl warten als 
auch erstellen, man muss sich halt bei einigen Dingen umgewöhnen.

Programmieranfängern rate ich nicht zur MFC, weil es da mittlerweile 
brauchbare Alternativen mit dem Vorteil der Plattformunabhängigkeit 
gibt, aber wer bereits Erfahrung mit der MFC hat, der kann die natürlich 
weiternutzen.

Insofern ist die MFC-Entwicklung nicht tot, auch wenn alle .Net-Freunde 
das gerne und ausgiebig behaupten.

Wenn ich dazu Zeit finde, werde ich mir auch mal die Unterschiede von 
VS2010 zu Gemüte führen, vielleicht hat MS da ja auch was brauchbares 
gemacht, statt mal wieder die Online-Hilfe zu verschlechtern. Das wäre 
dann aber das erste Mal ...

Autor: No.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aalmarmelade schrieb:
> Das Problem ist dass ich früher einen uralten C++ Builder hatte, den ich
> relativ gut beherrschte. Den besitze ich abe nicht mehr.

Empfehlenswert wäre dann wohk für dich der Borland C++ Builder 6.0 
Personal. Den gibt es auf jeden Fall noch frei im Netz. Er war denke ich
auch kostenlos.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> Nils schrieb:
>> Setze ich auf MFC - bleiben mir dann wirklich nur noch MS VC 6 und 7?
>> Ist das nach Eurer Einschätzung so?
>
> Nein. Auch mit den aktuellen Versionen ist MFC-Entwicklung möglich - ich
> nutze beruflich VS2008 dafür. Damit pflege ich einige Produkte, die
> teilweise seit über 15 Jahren in beständiger Weiterentwicklung sind.

Aber nicht mit der Express-Version; da ist m.W. MFC abgestellt.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils schrieb:
> Nach all dem was hier gesagt wurde:
> Wenn ich auf MS-OS entwickeln möchte - und das möglichst
> voraussetzungsfrei, d. h. ich setze bei meinem Kunden oder Zielsystem
> eine absolut heterogene EDV-Struktur von Win-XP bis Win 7 voraus, habe
> keine Ahnung ob .Net vorhanden ist und wenn ja, in welcher Version.
Ich würde sogar sagen da ist .net besser als C++. Wenn du MS2010 
verwendest dann muss auch die aktuelle Runtime (msvcrt*) vorhanden sein. 
Oder du muss sie beim kunden installieren dafür gibt es ein extra msi 
packet.
Auch 64bit geht bei .net von selber. Du kann ja einfach festlegen das du 
nur .net 2.0 verwendest. Dies kann man heute als standard vorraussetzen. 
Sonst geht nicht mal der Graiktreiber von ATI.

> Sind die neuen Entwicklerwerkzeuge von MS in Bezug auf
> Abwärtskompatibilität so wenig brauchbar?
Nein, wenn man weis worauf man achten muss, kann man immer noch für 
Win95 Programm erzeugen.

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

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Aber nicht mit der Express-Version; da ist m.W. MFC abgestellt.

Richtig. Nils aber schien VS20xx kaufen zu wollen, was wohl eine 
andere als die kostenlose Express-Version impliziert.


Peter schrieb:
> Wenn du MS2010
> verwendest dann muss auch die aktuelle Runtime (msvcrt*) vorhanden sein.

Nö, schon seit Ewigkeiten gibt es die Möglichkeit des statischen 
Linkens.
Da werden keinerlei DLLs, weder die der CRT noch --so verwendet-- der 
MFC genutzt.
Ein etwas größeres Exe-File, keine Installation, keine 
"redistributables", fertig.

Und das läuft dann ohne jede weitere Dreingabe auf allen 
Windows-Versionen von NT4 (oder sogar noch älter) bis Windows 7, sofern 
es nicht Systemaufrufe nutzt, die in einer der Versionen nicht vorhanden 
sind.

So etwas hat bereits mit Visual C++ 2.0 funktioniert und geht auch nach 
wie vor mit dem in VS2008 enthaltenen Compiler.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> Und das läuft dann ohne jede weitere Dreingabe auf allen
> Windows-Versionen von NT4 (oder sogar noch älter) bis Windows 7, sofern
> es nicht Systemaufrufe nutzt, die in einer der Versionen nicht vorhanden
> sind.

und das ist eventuell schon das Problem, meist ist man sich gar nicht 
bewuss oder liest es sich nicht genau durch welche Funktionen nicht 
überall laufen.

.net bietet aber schon viel mehr also nur die MFC und die Runtime. Es 
gibt schon für die häufigsten Aufgaben Fertige Klassen wie z.b. Zugriff 
auf Dienst, liste alle Prozesse. Das ganze ist ein C++ ein krampf, klar 
geht es aber schön ist es nicht. Auch die Fehlersuche finde ich in .net 
wesentlich einfacher weil es einen lesbaren callstack gibt. Und nicht 
nur ein speicher abbild.
Wenn man einen Fehler in einem C Programm sucht der nur bei einen kunden 
auftritt lernt man schnell die Vorteile von anderen sprachen kennen.

Man spart sogar zeit, weil .net programm sich wesentlich schneller 
compileren lassen als C. (merkt man bei HalloWorld.cpp aber noch nicht)

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

Bewertung
0 lesenswert
nicht lesenswert
> und das ist eventuell schon das Problem, meist ist man sich gar nicht
> bewuss oder liest es sich nicht genau durch welche Funktionen nicht
> überall laufen.

Ach, das soll ein Problem sein? Gibt es denn eine .Net-Runtime für NT4? 
Kann man das .Net-Geraffel statisch linken, so daß man nur eine einzelne 
Exe-Datei verteilen muss, die ohne Installation irgendwelchen 
Zusatzgeraffels funktioniert? Nö, ist nicht.

Jaja, schöne neue Welt. Missionierungsbedarf gibts keinen.



(Zugegeben, die Frage nach NT4 ist gemein, wo das ja nun wirklich keiner 
mehr braucht)

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> Ach, das soll ein Problem sein? Gibt es denn eine .Net-Runtime für NT4?
ja (aber leider nur 1.0)

> Kann man das .Net-Geraffel statisch linken, so daß man nur eine einzelne
> Exe-Datei verteilen muss, die ohne Installation irgendwelchen
> Zusatzgeraffels funktioniert? Nö, ist nicht.

.net wird überhaupt nicht gelinkt (zumindest nicht wie bei C/C++)

Es gibt immer Systemanforderungen für Software. Da gehört dann einfach
.net 2.0 rein und gut ist.

> Jaja, schöne neue Welt. Missionierungsbedarf gibts keinen.
man sollte sich aber auch nicht dem Fortschritt verschließen, hast du es 
dir überhaupt mal angeschaut?
Ich war am anfang auch sehr skeptisch, kannte nur java und das war 
langsam und nicht schön.
Aber nach dem ich einfach mal eine kleine Anwendung mit .net geschrieben 
habe und auch die performance gestestete habe war ich positiv 
überrascht.

> Jaja, schöne neue Welt. Missionierungsbedarf gibts keinen.
aus dem Grund hatte ich ja oben auch geschrieben, er soll es sich mal 
wenigstens mal ansehen.

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Rufus, Klaus Wachtler, Peter
Danke für die vielen Infos.
Sind ja doch eine Reihe von Dingen, die das Arbeiten erleichtern.
Da werde ich wohl in der Firma nerven müssen...

Was die .Net-Geschichten angeht: Das sehe ich ohne jede Leidenschaft. 
Wenn der Kunde das für bestimmte Produkte nicht möchte, ist das eben so 
(ich schrieb ja bereits: weltweit heterogene Systeme; keine Installation 
von DLLs oder Datenbank-Server erlaubt). Deshalb mache ich es gewöhnlich 
so, wie Rufus es beschrieb:
> Ein etwas größeres Exe-File, keine Installation, keine
> "redistributables", fertig.
Wenn der Kunde .Net-Apps will, werde ich es lernen, oder an einen 
abgeben, der es besser kann. So etwas entscheidet ein Mitarbeiter ja 
nicht allein.

Übrigens:
> Zugegeben, die Frage nach NT4 ist gemein, wo das ja nun wirklich keiner
> mehr braucht
Eine benachbarte Firma (Industrieelektronik) muss bei einem sehr großen 
Kunden heute noch NT-Systeme pflegen.
Der E-Ing, der mir das erzählte war ganz schön am Stöhnen...

Gruß,
Nils

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils schrieb:
>> Zugegeben, die Frage nach NT4 ist gemein, wo das ja nun wirklich keiner
>> mehr braucht
> Eine benachbarte Firma (Industrieelektronik) muss bei einem sehr großen
> Kunden heute noch NT-Systeme pflegen.

Ich habe auch noch einen in Obhut bei einem Kunden, da wird aber nichts
Neues mehr drauf programmiert (außer mal eine Zeile Batchdatei).

Autor: Aalmarmelade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Ich bin jetzt überrascht über die vielen Antworten. Leider sehe ich je 
länger den Wald vor lauter Bäumen nicht mehr.

Ich möchte ein spezielles 3D-Programm machen vermutlich über openGL oder 
DirektX.

Java kommt für mich aus verschiedenen Gründen nicht in Frage.


Eine C++ Builder 6.0 Personal könnte ich noch auftreiben. Aber hat 
dieses Borland-Tool noch einen Zukunft? Kenne kaum jemand der damit 
arbeitet.


Mein Programm wird am Anfang recht bescheiden ausfalllen, könnte aber 
mit der Zeit vermutlich immer stärker wachsen sofern es gelingt mein 
Vorhaben umzusetzen. Es wäre für mich dann eine Katastrophe wenn ich 
z.B. nach 3-4 Jahren das Programm auf einem anderen Tool umschreiben 
müsste nur weil es dann vielleicht keinen anständiges Entwicklungstool 
mehr gibt.


C# kenne ich nicht, sei aber sehr beliebt was man so hört?
Das einarbeiten dürfte wohl viel Zeit in Anspruch nehmen.


Visual C++ .NET habe ich kurz angefangen. Der Umstieg dürfte wohl sehr 
Zeitintensiv sein, könnte mich aber daran gewöhnen. Habe viele Probleme 
damit und finde relativ wenige Lösungen zu meinen Problmen im Internet.


Zahlbar müsste es auch noch sein, da wie gesagt ich aus gesundheitlichen 
Gründen jeden cent 2x umdrehen muss.Ich bin kein Profiprogrammierer 
deshalb sollte die Einarbeitungszeit erträglich sein.

Vielleicht muss ich doch alles in Delphi machen. Damit habe ich am 
meisten Erfahrung. Habe immer alles für MRS in Delphi gemacht. Aber 
Delphi wir mir immer unsicherer. Irgendwie hat man das Gefühl dass hier 
kaum noch weiter entwickelt wird.

Irgendwie ein fast unlösbares Problem das richtige Tool zu finden.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aalmarmelade schrieb:
> Visual C++ .NET habe ich kurz angefangen.

das ist leider weder das eine noch das andere. Entscheide dich zwischen 
.net(C#) und C++.

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

Bewertung
0 lesenswert
nicht lesenswert
Naja, wenn für Dich doch das .Net-Geraffel in Frage kommt, dann ist 
der Kostenfaktor optimal - die .Net-Sprachen ("Managed C++/C++ CLI", 
"C#" etc. lassen sich alle mit den kostenlosen "Express-Editionen" von 
Microsoft lösen.

Wenn Du "echtes" C++ programmieren möchtest, kannst Du das auch mit der 
"Express-Edition", das einzige, was nicht drin ist, ist die 
MFC-Entwicklung.

Dazu aber würde ich einem Anfänger auch definitiv nicht raten. Ich 
nutze die MFC, aber das mache ich beruflich schon seit 1995. Der Weg, 
den Kram zu lernen, war durchaus steinig; sollte ich jetzt, ohne auf 
meine bisherigen Projekte irgendwelche Rücksicht nehmen zu müssen, mich 
für eine C++-Klassenbibliothek entscheiden müssen, würde ich vermutlich 
bei Qt oder wxWidgets landen.

Beide sind mit der kostenlosen "Express-Edition", aber auch anderen 
kostenlosen C++-Compilern nutzbar, und das auch unter anderen 
Betriebssystemen als Windows.

Autor: grastino (gastino unterwegs) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Die relevanten Plattformen (Windows, Mac OS X) lassen sich mit
> Silverlight besser abdecken.

Nie im Leben.
Während bei wxWidgets-Projekten nur ein paar zusätzliche dlls im 
Programmordner mitgegeben werden müssen und die Programme da völlig 
problemlos von Windows 2000 bis Windows 7 (unabhängig von installierten 
Service-Packs) laufen, muss man bei Microsoft-Technologien noch 
Redistributables zusätzlich auf den Zielrechnern installieren, immer mit 
lustigen "Side-by-Side-Assembly"-Problemen rechnen (teilweise in 
Abhängigkeit vom Patchstand des jeweiligen Systems) oder schließt mit 
bestimmten .NET-Versionen ältere Windows-Versionen ganz aus.
Einfach nur grauenhaft im Vergleich zu wxWidgets.

Und was ich bis jetzt an .NET-Software gesehen habe, hat mich (gelinde 
gesagt) nicht gerade vom Hocker gehauen. Die fühlt sich im Gegensatz zu 
wxWidgets-Software wie ein Fremdkörper an, ist lahm und fett.

Und spätestens bei der Portierung auf andere Betriebssysteme hat man mit 
wxWidgets oder QT weitaus bessere Karten. Und wenn man sich nicht aller 
paar Jahre in neue "Microsoft-Technologien" einarbeiten will, weil die 
Vorgänger mal wieder beerdigt werden (VisualBasic, ASP, JScript.NET - 
WindowsForms ist übrigens so ein Kandidat!), sollte man auch lieber 
"stabile" Technologien wie wxWidgets oder QT lernen. Da ist der 
Einarbeitungsaufwand zwar durchaus etwas höher, aber den hat man dann 
auch wirklich nur einmal.

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

Bewertung
0 lesenswert
nicht lesenswert
grastino (gastino unterwegs) schrieb:
> Während bei wxWidgets-Projekten nur ein paar zusätzliche dlls im
> Programmordner mitgegeben werden müssen

Wenn überhaupt, es sollte auch möglich sein, wxWidgets-Projekte statisch 
zu linken, so daß keinerlei DLLs erforderlich sind.

Den restlichen Ausführungen kann ich mich nur ganzheitlich anschließen, 
aber das dürfte nicht weiter überraschen.

Autor: grastino (gastino unterwegs) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> Wenn überhaupt, es sollte auch möglich sein, wxWidgets-Projekte statisch
> zu linken, so daß keinerlei DLLs erforderlich sind.

Ja, das mache ich in den meisten Fällen auch so. Aber im schlimmsten 
Fall (den wollte ich darstellen - war etwas missverständlich 
formuliert), muss man ein paar dlls mitgeben, wenn es nicht statisch 
gelinkt wurde.

Meistens kann man sich mit wxWidgets auch jegliche Installer-Scripts 
sparen. Einfach den Programmordner kopieren - fertig. Die Nutzer müssen 
keine Admin-Rechte haben. Hingegen ist die Installation einer 
.NET-Laufzeitumgebung ohne Admin-Rechte nicht möglich, von der 
unsäglichen Platzverschwendung(*) durch solche Laufzeitumgebungen, die 
man für jede Version dieser Umgebung erneut installieren muss, mal ganz 
abgesehen...

(*) Und wenn gleich einer wieder einwendet, dass ja Plattenplatz 
reichlich da sei: Das ist noch lange kein Argument, den sinnlos zu 
verschwenden, denn ich will da meine Daten darauf speichern, von denen 
ich schon genug habe.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
grastino (gastino unterwegs) schrieb:
> Meistens kann man sich mit wxWidgets auch jegliche Installer-Scripts
> sparen. Einfach den Programmordner kopieren - fertig. Die Nutzer müssen
> keine Admin-Rechte haben.

seid wann dürfen dann anwender in den Programme Ordner schreiben? oder 
soll sich jeder nutzen das Programm unter Eigene-Dateien ablegen?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> von der
> unsäglichen Platzverschwendung(*) durch solche Laufzeitumgebungen, die
> man für jede Version dieser Umgebung erneut installieren muss, mal ganz
> abgesehen..

aber die Lösung alle Programm statisch zu linken ist ja so sparsam?
Noch schlimmer ist es wenn dann die anwendung im Netzwerk liegt und die 
exe dann 20Mb gross ist.
DLL haben genau die Vorteil das sie ebend nicht mit jedem Programm 
ausgeliefert werden müssen.

Also nächsten kommt dann das Problem mit Sicherheitsupdates. Wenn es 
eine neue Version gibt muss du jedes mal dein Program lausliefern.

Aber ich versteht schon. Noch nie etwas mit .net gemacht über schon alle 
nachteile kennen.

Autor: Aalmarmelade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die .NET-Laufzeitumgebung macht mir schon Kopfzerbrechen. Damit handelt 
man sich wohl viele Probleme ein beim Kunden.

Dann bleibt wohl nur noch C++

Programmiert hier niemand mehr mit C++ Builder oder ist der schon so 
veraltet dass niemand damit arbeitet?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aalmarmelade schrieb:
> Die .NET-Laufzeitumgebung macht mir schon Kopfzerbrechen. Damit handelt
> man sich wohl viele Probleme ein beim Kunden.

und welche Probleme sind das? Meine paar kunden haben zumindest damit 
keine Probleme.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
grastino (gastino unterwegs) schrieb:
> Arc Net schrieb:
>> Die relevanten Plattformen (Windows, Mac OS X) lassen sich mit
>> Silverlight besser abdecken.
>
> Nie im Leben.

Schonmal mit Silverlight gearbeitet? Anscheinend nicht.

> muss man bei Microsoft-Technologien noch
> Redistributables zusätzlich auf den Zielrechnern installieren, immer mit
> lustigen "Side-by-Side-Assembly"-Problemen rechnen (teilweise in
> Abhängigkeit vom Patchstand des jeweiligen Systems)

Die sind bekannt und einfach abstellbar.

> oder schließt mit
> bestimmten .NET-Versionen ältere Windows-Versionen ganz aus.

W2k und NT4 werden nicht mehr unterstützt, richtig. Silverlight dagegen 
auch noch auf W2k.
Qt4 wird auch nur ab XP offiziell unterstützt 
http://doc.trolltech.com/4.6/supported-platforms.html

> Und was ich bis jetzt an .NET-Software gesehen habe, hat mich (gelinde
> gesagt) nicht gerade vom Hocker gehauen. Die fühlt sich im Gegensatz zu
> wxWidgets-Software wie ein Fremdkörper an, ist lahm und fett.

Entweder uralt Hardware oder nie eine Anwendung gesehen...
Nur mal ein kleines Beispiel...
http://www.youtube.com/watch?v=z4Rnrmm0MTI
Dagegen dann sowas http://www.wxwidgets.org/about/screensh.htm

> Und spätestens bei der Portierung auf andere Betriebssysteme hat man mit
> wxWidgets oder QT weitaus bessere Karten.

Bei Qt hat man schon Probleme, wenn man neuere Features braucht..
http://doc.trolltech.com/4.0/porting4.html
Zudem sind beide mehr oder weniger reine UI-Frameworks, keine 
vollständigen Frameworks wie Java oder .NET.

> Und wenn man sich nicht aller
> paar Jahre in neue "Microsoft-Technologien" einarbeiten will, weil die
> Vorgänger mal wieder beerdigt werden (VisualBasic, ASP, JScript.NET -
> WindowsForms ist übrigens so ein Kandidat!), sollte man auch lieber
> "stabile" Technologien wie wxWidgets oder QT lernen.

ASP kam 1996 raus und wird bis heute unterstützt (auch wenn die 
Weiterentwicklung zugunsten von ASP.NET, Gott sei dank, eingestellt 
wurde). VB gibt's/gab's seit 1998, JScript.NET afair seit 2000...
Wenn man in über zehn Jahren nichts neues lernen kann oder will, sollte 
man vllt über einen Berufswechsel nachdenken.

Autor: No.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aalmarmelade schrieb:
> Programmiert hier niemand mehr mit C++ Builder oder ist der schon so
> veraltet dass niemand damit arbeitet?

Ich verwende den http://www.turboexplorer.com/ ala C++ Builder Version 
2006,
aber du liest wohl nicht alle Nachrichten.

Im Forum

http://www.c-plusplus.de/forum/index-var-.html

siehst du auch unter

VCL (C++ Builder)     FAQ/Archiv

das es eine recht große FAN-Gemeinde gibt.

Im Microcontroller Forum und auch in den meisten Firmen sind
die Visual Studio Anwender in der Überzahl.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
No.Net schrieb:
> Aalmarmelade schrieb:
>> Programmiert hier niemand mehr mit C++ Builder oder ist der schon so
>> veraltet dass niemand damit arbeitet?
>
> Ich verwende den http://www.turboexplorer.com/ ala C++ Builder Version
> 2006,
> aber du liest wohl nicht alle Nachrichten.

Das Teil ist auch schon lange tot bzw. nicht mehr verfügbar.
"Turbo Delphi 2006, Turbo C++ 2006, and JBuilder Turbo 2008 are no 
longer available. You can download a free 30-day trial version of the 
latest Delphi, C++Builder, and JBuilder products and learn more about 
them using the links below."
http://www.turboexplorer.com/downloads

Autor: No.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Das Teil ist auch schon lange tot bzw. nicht mehr verfügbar.
> "Turbo Delphi 2006, Turbo C++ 2006, and JBuilder Turbo 2008 are no
> longer available. You can download a free 30-day trial version of the
> latest Delphi, C++Builder, and JBuilder products and learn more about
> them using the links below."

Das "Teil" lebt im Embarcadero RAD Studio 2010 weiter.

http://www.embarcadero.com/products/rad-studio

Der Download wurde von dort entfernt, weil viele diese kostenlose 
Version
verwenden (auch für kommerziellen Einsatz kostenlos nutzbar) und dadurch 
die Nachfolgeversionennicht mehr gekauft haben (verständlich).

Allerdings ist es im Netz weiterhin verfügbar und durchaus für den
produktiven Einsatz verwendbar.

Autor: No.Net (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
No.Net schrieb:
> Allerdings ist es im Netz weiterhin verfügbar und durchaus für den
> produktiven Einsatz verwendbar.

http://www.turbomirror.com/

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> seid wann dürfen dann anwender in den Programme Ordner schreiben? oder
> soll sich jeder nutzen das Programm unter Eigene-Dateien ablegen?

Wohin das Programm kopiert wird, spielt ja keine Rolle. Wichtig ist, 
dass man die Möglichkeit hat und das ist manchmal sehr hilfreich.

Peter schrieb:
> aber die Lösung alle Programm statisch zu linken ist ja so sparsam?
> Noch schlimmer ist es wenn dann die anwendung im Netzwerk liegt und die
> exe dann 20Mb gross ist.
> DLL haben genau die Vorteil das sie ebend nicht mit jedem Programm
> ausgeliefert werden müssen.

Ob die exe nun 20 MB groß ist oder die nachzuladenden DLLs, ist herzlich 
egal. Programme aus dem Netz zu starten, ist - gelinde gesagt - 
suboptimal.

> Also nächsten kommt dann das Problem mit Sicherheitsupdates. Wenn es
> eine neue Version gibt muss du jedes mal dein Program lausliefern.

Das muss man so oder so. Die hinzugelinkten wxWidgets-Bibliotheken sind 
nicht sehr groß, weil wxWidgets ohnehin unter jedem Betriebssystem die 
"nativen" Bibliotheken nutzt - es ist nur eine Art Wrapper - und genau 
das ist das Geniale daran.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Schonmal mit Silverlight gearbeitet? Anscheinend nicht.

Kannst Du mir mal erklären, wieso ich mit einer Erweiterung für 
Webbrowser ganz normale Anwendungsprogramme schreiben soll? Es geht hier 
doch nicht um eine Webapplikation oder einen Flash-Ersatz.
Ich fahre doch auch nicht mit dem Ruderboot in den Supermarkt...

> Die sind bekannt und einfach abstellbar.

Einfach abstellbar - der war echt gut. :D :D

> W2k und NT4 werden nicht mehr unterstützt, richtig. Silverlight dagegen
> auch noch auf W2k.

Siehe oben. Silverlight ist für die Aufgabenstellung völlig 
uninteressant. Ich bezweifle, dass der Threadstarter Webapplikationen 
schreiben will und selbst dann würde ich ihm keinesfalls so eine 
proprietäre Microsoft-Lösung empfehlen.

> Qt4 wird auch nur ab XP offiziell unterstützt
> http://doc.trolltech.com/4.6/supported-platforms.html

Keine "offizielle Unterstützung" heißt ja nicht, dass es auf anderen 
Systemen nicht läuft. Hier sind zum Beispiel Hinweise, um QT auf 
Plattformen bis hinunter zu Win98 zum Laufen zu bringen:

http://doc.qt.nokia.com/4.6/platform-notes-windows.html

Und allein schon die offiziell unterstützten Plattformen sind bei QT 
eine ganze Menge, an die .NET nicht ansatzweise herankommt.

> Entweder uralt Hardware oder nie eine Anwendung gesehen...

Mit dem Alter der Hardware hat das Look&Feel der Anwendungen nichts zu 
tun. Sie wirken unter XP irgendwie fremdkörperhaft und dass sie träger 
sind, merkt man auch gleich. Warum sollte man so was seinen Kunden 
antun? Weil die so einen Spaß an der Installation verschiedener 
.NET-Laufzeitumgebungen haben?

> Nur mal ein kleines Beispiel...
> http://www.youtube.com/watch?v=z4Rnrmm0MTI
> Dagegen dann sowas http://www.wxwidgets.org/about/screensh.htm

Bei wxWidgets sehe ich eine nahtlose Integration in das Betriebssystem 
(kein Wunder, denn dessen native Bibliotheken werden ja jeweils 
benutzt), bei Deinem Film ist von einer Betriebssystemoberfläche nichts 
zu sehen (hab ihn aber auch nicht komplett angesehen). Was soll mir also 
der Film sagen?

> Bei Qt hat man schon Probleme, wenn man neuere Features braucht..
> http://doc.trolltech.com/4.0/porting4.html
> Zudem sind beide mehr oder weniger reine UI-Frameworks, keine
> vollständigen Frameworks wie Java oder .NET.

Was ist bei Dir ein "vollständiges Framework"? Eines, das unnötig viel 
Ballast mitbringt und auf die betriebssystemeigenen Bibliotheken noch 
eine Schicht draufsetzt?
Wofür braucht man das? Unter wxWidgets zum Beispiel sind auch nicht nur 
UI-Funktionen verfügbar, sondern alle möglichen weitere Funktionen, die 
eine betriebssystemunabhängige Programmierung ermöglichen 
(Multi-Threading, Netzwerk, Konfiguration etc.).

> ASP kam 1996 raus und wird bis heute unterstützt (auch wenn die
> Weiterentwicklung zugunsten von ASP.NET, Gott sei dank, eingestellt
> wurde). VB gibt's/gab's seit 1998, JScript.NET afair seit 2000...
> Wenn man in über zehn Jahren nichts neues lernen kann oder will, sollte
> man vllt über einen Berufswechsel nachdenken.

Du kannst gern Deine Zeit und Dein Geld für ständig neue und schnell 
veraltende Microsoft-Technologien verpulvern. Ich arbeite mich nur in 
Lösungen gern ein, die mir einen Mehrwert bringen und nicht nur Geld und 
Zeit kosten. Eine Firma muss Geld verdienen und das tut sie nicht, wenn 
sie ihre Produkte aller paar Jahre komplett neu schreiben kann, weil mal 
wieder eine neue Mode "in" ist.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Arc Net schrieb:
>> Schonmal mit Silverlight gearbeitet? Anscheinend nicht.
>
> Kannst Du mir mal erklären, wieso ich mit einer Erweiterung für
> Webbrowser ganz normale Anwendungsprogramme schreiben soll? Es geht hier
> doch nicht um eine Webapplikation oder einen Flash-Ersatz.
> Ich fahre doch auch nicht mit dem Ruderboot in den Supermarkt...

Gibt's seit SL3 und nennt sich Out-Of-Browser
http://msdn.microsoft.com/de-de/library/dd550721(VS.95).aspx

> Und allein schon die offiziell unterstützten Plattformen sind bei QT
> eine ganze Menge, an die .NET nicht ansatzweise herankommt.

Linux -> uninteressant, kein Kunde will's haben
Embedded Linux -> für Nischenanwendungen interessant
WinCE -> Warum Qt, da reichen auch die anderen Möglichkeiten
Symbian -> uninteressant, der Markt geht Richtung Android, iOS und u.U. 
WP7
HPUXi, Solaris, AIX -> Qt auf richtigen Servern oder für die zwei, drei 
Personen, die sowas als Desktop nehmen?

>> Entweder uralt Hardware oder nie eine Anwendung gesehen...
>
> Mit dem Alter der Hardware hat das Look&Feel der Anwendungen nichts zu
> tun. Sie wirken unter XP irgendwie fremdkörperhaft und dass sie träger
> sind, merkt man auch gleich.

Also doch uralt Hardware und den Desktop wahrscheinlich auf W2k-Look 
umgestellt.

> Warum sollte man so was seinen Kunden
> antun? Weil die so einen Spaß an der Installation verschiedener
> .NET-Laufzeitumgebungen haben?

Wieso

>> Nur mal ein kleines Beispiel...
>> http://www.youtube.com/watch?v=z4Rnrmm0MTI
>> Dagegen dann sowas http://www.wxwidgets.org/about/screensh.htm
>
> Bei wxWidgets sehe ich eine nahtlose Integration in das Betriebssystem
> (kein Wunder, denn dessen native Bibliotheken werden ja jeweils
> benutzt),

Sieht größtenteils nach Software aus, die in den 90ern stehengeblieben 
ist, ToolStrip, Icons, teilweise fehlt das entsprechende 
Manifest/Theming etc.


> bei Deinem Film ist von einer Betriebssystemoberfläche nichts
> zu sehen (hab ihn aber auch nicht komplett angesehen). Was soll mir also
> der Film sagen?

Die Aussage war "lahm und fett"

> Was ist bei Dir ein "vollständiges Framework"? Eines, das unnötig viel
> Ballast mitbringt und auf die betriebssystemeigenen Bibliotheken noch
> eine Schicht draufsetzt?

Über was reden wir hier eigentlich? Von richtigen Anwendungen bei denen, 
wenn's hoch kommt, 10% - 20% des Codes für das UI draufgeht oder von 
irgendwelchen Apps.

> Wofür braucht man das? Unter wxWidgets zum Beispiel sind auch nicht nur
> UI-Funktionen verfügbar, sondern alle möglichen weitere Funktionen, die
> eine betriebssystemunabhängige Programmierung ermöglichen
> (Multi-Threading, Netzwerk, Konfiguration etc.).

Ein paar minimale Wrapper sind kein Framework.

> Du kannst gern Deine Zeit und Dein Geld für ständig neue und schnell
> veraltende Microsoft-Technologien verpulvern.

10+ Jahre = schnell veraltend?

> Ich arbeite mich nur in
> Lösungen gern ein, die mir einen Mehrwert bringen und nicht nur Geld und
> Zeit kosten.

Qt und wxWidgets haben wesentlich weniger 
Third-Party-Support/Komponenten, die Produktivität ist deutlich geringer 
etc.pp.

Autor: Eugen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> oder schließt mit
>> bestimmten .NET-Versionen ältere Windows-Versionen ganz aus.

> W2k und NT4 werden nicht mehr unterstützt, richtig. Silverlight dagegen
> auch noch auf W2k.

Unsinn! Auf meinem uralt Notebook mit W2k als OS und weniger als 256k 
RAM läuft ein Microsoft Visual C# 2005 das auf .NET 2.0 aufsetzt. Wenn 
man sich auf dessen Fuktionen beschränkt dann ist alles ab W2k aufwärts 
abgedeckt.

Bitte den Leuten hier nicht einfach solche Falschinformationen 
unterbreiten!

Autor: Eugen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warum sollte man so was seinen Kunden
> antun? Weil die so einen Spaß an der Installation verschiedener
> .NET-Laufzeitumgebungen haben?

Alles was auf dem Rechner zur Ausführung gebracht werden soll muss 
irgendwie vorher installiert werden. Auch Flash Anwendungen brauchen 
ihre Laufzeitumgebungen und auch PDF wird nicht ohne einen installierten 
Reader angezeigt. Da spielt es letztlich keine Rolle ob ein .NET oder 
sonst ein Hilfprogramm (für den Anwender ist nichts anderes als ein 
klicken auf ein Setup.exe) installiert werden muss, um dem Rechner 
erweiterte Funktionalität einzuhauchen. Zumal neuere Windows Versionen 
ab XP .NET Laufzeitumgebungen mitbringen und irgend wann wird auch der 
letzte kein NT4 mehr verwenden, so wie auch praktisch niemand mehr 
heutzutage ein Windows 3.11 oder gar 2.0 oder gar .. verwendet.

Autor: Eugen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du kannst gern Deine Zeit und Dein Geld für ständig neue und schnell
> veraltende Microsoft-Technologien verpulvern.

Das stimmt doch so bezogen auf Microsoft überhaupt nicht. MS hat seinen 
Win16/Win32 unterbau der noch immer vorhanden ist, aber stark in die 
Jahre gekommen ist durch das ein modernes, SEHR UMFANGREICHES .NET 
(sprich dot net) Framework ERGÄNZT. Das war längst überfällig. Von 
"schnell veraltent" kann gar keine Rede sein, wenn man mal überlegt wie 
lange man selbst mit alten W2k oder gar Windows 98 SE noch hantieren 
konnte (und das mit Einschränkungen noch immer kann). Die Systeme sind 
dank ihrer einfachen Bedienbarkeit noch immer für die große Mehrzahl der 
Nutzer attraktiv, sonst wäre wohl inzwischen alle auf Linux umgestiegen. 
Seit W7 ist die Beliebtheit sogar wieder deutlich angestiegen und das 
ist kein Zufall.

Lass das mit den MFC und arbeite dich in .NET ein. Das Framework ist 
ausgereift und bietet umfangreiche Möglichkeiten.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Gibt's seit SL3 und nennt sich Out-Of-Browser
> http://msdn.microsoft.com/de-de/library/dd550721(VS.95).aspx

Und wozu? Für die Kunden, denen "normale" Applikationen zu schnell und 
zu stabil sind? Oder für die, die gern alle möglichen Laufzeitumgebungen 
auf ihrem Rechner sammeln, die keinerlei funktionelle Erweiterung 
darstellen, aber Speicherplatz und Rechenzeit verbrauchen und noch 
zusätzliche Abhängigkeiten und Instabilitäten mitbringen?

> Linux -> uninteressant, kein Kunde will's haben
> Embedded Linux -> für Nischenanwendungen interessant
> WinCE -> Warum Qt, da reichen auch die anderen Möglichkeiten
> Symbian -> uninteressant, der Markt geht Richtung Android, iOS und u.U.
> WP7
> HPUXi, Solaris, AIX -> Qt auf richtigen Servern oder für die zwei, drei
> Personen, die sowas als Desktop nehmen?

Netter Versuch, unterstützte Plattformen als unwichtig abzutun. Ist aber 
nur ein Versuch, davon abzulenken, dass Dein favorisiertes .NET gerade 
bei der Plattformunabhängigkeit gegenüber anderen Lösungen sehr alt 
aussieht.

> Also doch uralt Hardware und den Desktop wahrscheinlich auf W2k-Look
> umgestellt.

Nochmal: Wenn ich auf einem Rechner verschiedene Software vergleiche und 
feststelle, dass sich bestimmte Software im Vergleich zur anderen träge 
anfühlt und die UI nicht wirklich zum Rest passt, dann ist die Frage 
nach der Hardware oder dem verwendeten Style völlig unwichtig. Denn dann 
sieht man zwei Nachteile des .NET-Frameworks, die man seinen Kunden 
nicht antun muss.

> Sieht größtenteils nach Software aus, die in den 90ern stehengeblieben
> ist, ToolStrip, Icons, teilweise fehlt das entsprechende
> Manifest/Theming etc.

Du kannst gern Deine persönlichen Abneigungen gegen das Interface 
bestimmter Software vorbringen, nur mit der Frage nach dem "richtigen" 
Framework hat das rein gar nichts zu tun. Die meiste Software (auch 
.NET-Software) nutzt UI-Elemente, die schon in den 90er bekannt waren 
und die Nutzer erwarten das so. Es gibt nichts Schlimmeres als die 
Experimente untalentierter Informatiker, die vermeintlich moderne UIs 
schaffen wollen.

> Die Aussage war "lahm und fett"

Ja und? Was trägt so ein Werbefilmchen zum Erkenntnisgewinn bei?

> Über was reden wir hier eigentlich? Von richtigen Anwendungen bei denen,
> wenn's hoch kommt, 10% - 20% des Codes für das UI draufgeht oder von
> irgendwelchen Apps.

Von richtigen Anwendungen. Also nochmal die Frage: Was sind für Dich 
"richtige Frameworks"?

> Ein paar minimale Wrapper sind kein Framework.

Es ist ein wenig mehr als nur "minimale Wrapper", aber Du hast 
(wahrscheinlich unbewusst) schon den eigentlichen Vorteil von wxWidgets 
beschrieben: Es ist sehr schlank, benutzt unter den jeweiligen 
Betriebssystemen die "heimischen" Bibliotheken, was die resultierenden 
Programme letztendlich zu ganz normaler "heimischer" Software macht - 
mit allen damit verbundenen Vorteilen: Sie fügen sich nahtlos in die 
restlichen UI-Umgebung ein und bringen keinen Ballast mit. Und trotzdem 
kann man damit sehr umfangreiche Software schreiben, die sehr einfach zu 
portieren ist.

Und wer mehr Ballast als diesen mitbringen will, muss schon sehr gute 
Gründe dafür liefern. Bei .NET bekommt man trotz des ganzen Ballastes ja 
nicht mal ansatzweise die Plattformunabhängigkeit von wxWidgets mit. 
Wieso also sollte man sich so was antun? Weil man nichts anderes kennt?

> 10+ Jahre = schnell veraltend?

Natürlich. Wenn es sich um die Software-Basis handelt, dann ist das 
schnell. Für Hobby-Programmierer mag das irrelevant sein, für Firmen 
kann aber das Überleben auf dem Spiel stehen, wenn sie nach 10 Jahren 
alle ihre Produkte von Grund auf neu entwickeln dürfen, weil ihre Kunden 
mit neuen Windows-Versionen plötzlich Probleme bekommen oder der Kram 
gar nicht mehr läuft. Solche "Microsoft-Technologien" würde ich nicht 
mit der Kneifzange anfassen, wenn mein wirtschaftliches Überleben davon 
abhängt.

> Qt und wxWidgets haben wesentlich weniger
> Third-Party-Support/Komponenten, die Produktivität ist deutlich geringer
> etc.pp.

Sorry, aber das sind doch nur ein paar substanzlose Worthülsen. Wie 
viele Third-Party-Komponenten verfügbar sind, ist völlig irrelevant - es 
kommt nur darauf an, dass man mit dem Gebotenen seine Projekte anständig 
umgesetzt bekommt. Viele Third-Party-Komponenten deuten im Gegenteil 
sogar darauf hin, dass das Framework unvollständig oder stark 
mängelbehaftet ist.
Und die Behauptung zur geringeren Produktivität hätte ich doch gern mal 
belegt.

Autor: Eugen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nochmal: Wenn ich auf einem Rechner verschiedene Software vergleiche und
> feststelle, dass sich bestimmte Software im Vergleich zur anderen träge
> anfühlt und die UI nicht wirklich zum Rest passt, dann ist die Frage
> nach der Hardware oder dem verwendeten Style völlig unwichtig. Denn dann
> sieht man zwei Nachteile des .NET-Frameworks, die man seinen Kunden
> nicht antun muss.

Soso, .NET soll also träge und was bitte soll nicht passen? Das klingt 
alles nach typischer Microsoft Basherei und aus den Fingern gesogen. Ein 
umfangreicheres Framework wie das .NET musst du erst mal finden, zumal 
man sich die Programmiersprache dazu quasi auch noch aussuchen kann.

Du solltest anderen nicht "substanzlose Worthülsen" vorwerfen derer du 
dich selbst bedienst. Denn mit Objektivität hat das was du hier 
schreibst mal gar nichts zu tun, sonst würdest du zumindest mal 
zugestehen welche Plattformen hier signifikannte Marktanteile haben und 
welche eben nicht (die kann man ja dennoch mögen, aber die erste Geige 
spielen sie im Markt nun mal nicht).

Autor: Eugen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigens, was verbreitet ist und was weniger drückt sich auch sehr schön 
darin aus was an Büchern verlegt wird. Vergleiche mal das was zu MS im 
Bereich der Programmiersprachen/Frameworks á la MFC, C++, C#, Visual .. 
Express .. erscheint oder bereits erschienen ist mit wxWidgets und QT .. 
Daran lässt sich schön ablesen was verbreitet ist. Allein die 
zahlreichen Bücher rund um die MS Studio Versionen dokumentieren deren 
Beliebtheit und die Studies waren noch immer scharf ein VS zu erhalten 
(über die Hochschulprogramme von MS) wohl wissend das es auch ein 
Eclipse für umsonst gibt (nichts gegen Eclipse :)). Darauf sollte der 
Threadersteller mal ein wenig achten bei seiner Entscheidung und sich 
nicht so sehr von der Linux Fangemeinde beeinflussen lassen. ;)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Liest du die BILD?

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moinsen,

immerwieder unglaublich, wie krass manche Leute an "ihrem" Microsoft 
festhalten. Das muss eine Abart des Stockhlm-Syndroms sein.

Wer nur für Windows programmiert kann sicher .net/c# nutzen. Ist ne 
ganz schicke sache. Sobald dann aber dochmal irgend eine andere Maschine 
das selbe Programm ausführen soll, ists halt meist essig.

Warum man aber unbedingt in Silverlight Desktopanwendungen schreiben 
soll, entzieht sich jeder Logik. Ist genauso krank, wie User-Interfaces 
für Waschmaschinen in Flash zu entwickeln (soll wohl leider echt 
vorkommen, zumindest Mobiltelefone und media player laufen teils mit 
flash-emu und flash UI - der designer konnte/wollte ja nix anderes...).

Gruß
Andreas

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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