|
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
Und iOS, WinRT & Co sind auch keine problem wenn man eine Online/Webanwendung mit Java macht (Backend Java, Frontend JS/HTML5) Zitat:
Zitat:
|
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
Allerdings muss man da die richtige Niche finden. Die MSDN beschreibt die Positionierung von C# und C++ im Moment so Zitat:
 http://msdn.microsoft.com/en-us/library/hh279654.aspxZitat:
Kein Wunder, dass die platten Anti-C++ Argumente, wie im Startbeitrag dieses Threads, nicht ziehen, um neue Leute für Delphi zu interessieren. ISO C++, von MS gerne Modern C++ genannt, sieht deutlich anders aus, als alter WinApi-Code. Pointer und diesen ganzen Makro Quatsch sieht man da höchst selten. Bin mal gespannt, wie Embarcaderos neue Liebe für C++ in der Delphi Gemeinde ankommt. Das Struppi mal auf einer Delphi Konferenz spricht, hätte ich vorher nicht geglaubt: http://blogs.embarcadero.com/davidi/2012/11/21/41993/ |
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
Ist dieses C++ unstrukturierter und schlecher zu lesen als z.B. C# ?
Code:
oder
vector<unsigned int> RandomPhotoSelector::CreateRandomizedVector(unsigned int vectorSize, unsigned int sampleSize)
{ // Seed the rand() function, which is used by random_shuffle. srand(static_cast<unsigned int>(time(nullptr))); // The resulting set of random numbers. vector<unsigned int> result(vectorSize); // Fill with [0..vectorSize). iota(begin(result), end(result), 0); // Shuffle the elements. random_shuffle(begin(result), end(result)); // Trim the list to the first sampleSize elements if the collection size is greater than the sample size. if (vectorSize > sampleSize) { result.resize(sampleSize); } return result; }
Code:
Das ist die Sprache, mit der Delphi in Zukunft, auch Mobilbereich, konkurriert. Erst recht, wenn der C++ Builder seinen neuen, auf CLang basierenden, Compiler hat. Nicht irgendwelches Zeug, von vor 20 Jahren.
void ImageBrowserViewModel::StartMonthQuery(int queryId, cancellation_token token)
{ m_runningMonthQuery = true; OnPropertyChanged("InProgress"); m_photoCache->Clear(); run_async_non_interactive([this, queryId, token]() { // if query is obsolete, don't run it. if (queryId != m_currentQueryId) return; m_repository->GetMonthGroupedPhotosWithCacheAsync(m_photoCache, token).then([this, queryId] (task<IVectorView<IPhotoGroup^>^> priorTask) { assert(IsMainThread()); if (queryId != m_currentQueryId) { // Query is obsolete. Propagate exception and quit. priorTask.get(); return; } m_runningMonthQuery = false; OnPropertyChanged("InProgress"); if (!m_runningYearQuery) { FinishMonthAndYearQueries(); } try { // Update display with results. m_monthGroups->Clear(); for (auto group : priorTask.get()) { m_monthGroups->Append(group); } OnPropertyChanged("MonthGroups"); } // On exception (including cancellation), remove any partially computed results and rethrow. catch (...) { m_monthGroups = ref new Vector<IPhotoGroup^>(); throw; } }, task_continuation_context::use_current()).then(ObserveException<void>(m_exceptionPolicy)); }); } Argumente wie "Delphi liegt mir einfach besser" oder "Das bin ich so gewohnt", sind doch gute Gründe für Delphi. Aber dieser Thread trägt den Titel "Argumentesammlung und Vergleich". Da muss man schon mit dem richtigen Vergleichen. Und das ist im nativen Bereich der Vergleich Delphi/FireMonkey/Free Pascal mit der ganzen C++11 / Qt / Boost usw. Welt. Ganz ohne Bezug auf MS, Delphi will ja auch Cross Plattform sein. |
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
Zitat:
Zitat:
|
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
In gewisser Weise haben VCL und MFC ja derzeit etwas gemeinsam. Beide sind irgendwie am Ende des Weges angekommen und werden von ihren Herstellern etwas stiefmütterlich behandelt. Kein Zweifel, dass die VCL eine der besten Lösungen für klassische Windows Desktop Anwendungen ist. Höchstens Qt kann da mithalten. MS hat da im nativen Bereich im Moment nix, allerdings haben sie für Win8 Apps gezeigt, dass sie mit C++11 ein natives Gegenstück zu C# haben, siehe die Beispiele oben. Wohlmöglich kommt das demnächst auch für Desktop Anwendungen, dann werden die Karten neu gemischt. Die Liebe von Embarcadero gehört derzeit ganz klar dem "brennenden Affen", sowohl für Delphi als auch dem C++ Builder. Wenn ich mir das so ansehe, im Licht der "Argumente" des Threaderstellers, wie Zitat:
Andere Dinge sind relativ Zitat:
Zitat:
In diesem Punkt steckt etwas wahres Zitat:
Aber ich wage mal die Behauptung, dass viele kommerzielle Win8 (+ Phone) Apps in C++ geschrieben werden, um dieses Problem zu umgehen. Die syntaktischen Unterschiede, s.o., halten sich in Grenzen, beide greifen auf die selbe API und Klassenbibliothek zu, usw. Das ist sicher ein Gebiet, in dem Delphi mit nativer Cross Plattform Entwicklung punkten könnte, wenn die Qualität und Performance stimmen. Performance ist allerdings so ein Gebiet, wo ich mir mehr von Delphi wünschen würde. Es gibt zwar Threads in der Sprache und ein wenig Angebot im Bibliotheksbereich (OmniThread). Aber verglichen mit dem, was es z.B. bei Intel oder MS gibt ist das recht dünn besetzt. Mit einer Visual Studio Express kann man seine C++ Threads mit C++ AMP auch auf der Grafikkarte laufen lassen, in zukünftigen Versionen wohl auch in der Cloud. Es gibt die Parallel Patterns Library, der Compiler hat einen Autovektorisierer und einen Autoparallelisierer. Im Mobilbereich tun sich neue Problemfelder auf, z.B. ARM-Prozessoren mit "big little" Technik, also Prozessoren mit unterschiedlich schnellen Kernen, was Multithreading ein wenig komplitiert. Alles Dinge, wo sich neue Delphis beweisen müssen. Im Moment halte ich es mit abwarten und C++ Programmieren. :-D |
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
Zitat:
|
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
Zitat:
|
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Delphi hat meiner Meinung nach genau einen echten Vorteil: es ist die einzige Sprache, mit der man mit halbwegs (!) schönem Code native Windows-Anwendungen schreiben kann. Mit C++ scheint es ja, relativ zur Gesamtheit der Programmiersprachen, völlig unmöglich zu sein, schönen Code zu schreiben (und auch die in diesem Thread gezeigten Beispiele sind da nicht unbedingt eine Ausnahme. Code-Clutter by Design :roll:). Delphi ist da zwar auch weit vom Optimalzustand entfernt, aber nunja...
Das Dumme an der Sache ist nur: Es gibt immer weniger Gründe, wieso man native Anwendungen entwickeln wollen würde. Einerseits landen immer mehr Anwendungen im Browser (was quasi die billigste Plattformunabhängigkeit ist) und sind damit durchaus erfolgreich (siehe z.B. Google Docs oder Play Music). Andererseits ist der Ressourcenverbrauch von Runtimes wie .Net oder Java, der ja gerne als Gegenargument angeführt wurde / wird, für den überwiegenden Teil der Anwendungsfälle einfach kein Gegenargument mehr. Dafür bekommt man als Entwickler deutlich modernere Sprachen (Java meine ich damit nicht unbedingt... aber es gibt ja durchaus noch mehr, was zu Java-Bytecode kompiliert wird :wink:) mit denen man deutlich schneller ein fertiges, wartbares Produkt produzieren kann. Von der Größe der Communities und verfügbarer Codebase (Libraries etc) mal ganz zu schweigen. |
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
Zitat:
|
AW: Delphi-Projekt-Argumentesammlung u.Vergleich
Zitat:
Zitat:
War schon noch Mobile - Bei dieser permanente Unbenennung des mittlerweilen sterbenden CE-Kerns kommt man leicht durcheinander. Mit Windows Phone hatte es MS schon geschafft irrelevant zu sein und für die neuen Mobilen Entwicklungen kommt erst iOS, dann Android und zum Schluss Windows. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 09:28 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz