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
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)
Hallo Peter Ich habe aber die Express-Version (Gratisversion) um mal reinzuschauen. Gruss
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.
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.
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"
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
Wie kann ich das verstehen? Sind mit der Expressversion nur NET-Anwendungen möglich oder bin ich falsch vorgegangen?
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.
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
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.
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
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.
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.
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.
Als Nutzer von OS X möchte ich aus Gründen der Hygiene kein "Silverlight" verwenden.
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)).
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 ...
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.
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.
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.
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.
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)
> 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)
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.
@ 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
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).
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.
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++.
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.
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.
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.
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.
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?
> 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.
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?
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.
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.
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.
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
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.
No.Net schrieb: > Allerdings ist es im Netz weiterhin verfügbar und durchaus für den > produktiven Einsatz verwendbar. http://www.turbomirror.com/
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.
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.
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.
>> 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!
> 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.
> 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.
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.
> 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).
Ü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. ;)
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
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.