Hi da. Ich möchte mir gerne eine Win/MAC-Programmiersprache anschauen und würde deswegen gerne wissen welche Sprache bei Steinberg Cubase verwandt wird. Ich finde es interessant, dass die Sprache hohe Perfomance und gleichzeitig auf mehreren Betriebssystemen gut läuft. Tim
nimm c++, mit qt bist du fast plattformunabhängig.
offenbar c++ http://www.steinberg.net/en/company/jobs/softwareentwickler_elicenser.html Welche Oberfläche weiss ich nicht, wahrscheinlich haben sie ein abstraction Layer und benutzen dann MFC für windows und cocoa für mac osx. Das ist aber nur ein kleiner Teil der Problematik, cubase braucht ja auch anbindung and soundkarten und dsp-karten mit kontrollierter latenz.
Die C++-Klassenbibliothek wxWidgets ist die Grundlage für den Audioeditor Audacity, den gibt es auf verschiedenen Betriebssystemen.
Hi Ihr! Danke für die Tips! Wenn man jetzt die Frage in den Raum stellt - Was ist Zukunft sicherer und performanter: - das erwähnte C++ - oder C# Würde C# nicht von sich selber (wegen .net) schon Crossplatform tauglich sein? Kann man Qt in etwar mit wxWidgets vergleichen oder sehe ich da was falsch? Tim
Tim schrieb: > Was ist Zukunft sicherer und performanter: > - das erwähnte C++ > - oder C# bei c++ sollte man wissen was man macht, dann ist es auch performanter. C# ist sehr schnell ohne das man sich viele gedanken machen muss. c# ist halt von MS - ich finde es aber eine schöne sprache. läuft bei mir auch unter linux - aber ohne GUI
Benutzt Du C# dann ohne diese Bibliotheken? Das heißt in C# würde eine Programmierung schneller von statten gehen. Jedoch wäre C++ bei richtiger Handhabung und Erfahrung performanter denke ich. Nutzt man für große, neu angefangene Programme dann eher C++ oder C#? Habe schon einige Threads zwischen den beiden Sprachen gelesen - trotzdem kann ich mich nur schwer entscheiden. Sorry also das ich schon wieder das Thema ausgrabe ;-) Tim
Tim schrieb: > Nutzt man für große, neu angefangene Programme dann eher C++ oder C#? Das kann man nur beantworten wenn man weiss welche Librarys oder Frameworks du benutzen möchtest. z.B. wenn du eine GUI unter .NET programmieren willst, sehe ich keinen Grund warum C++ performanter sein sollte als C#. Hier würde ich also C# empfehlen. Eine Ausnahme könnte dann sein, dass du bestimmte Header verwenden willst/musst die unter C/C++ geschrieben wurden. Dann würde ich C++ nehmen, weil es einfach näher an C dran ist. Ist aber auch nur EINE Meinung zu diesem Thema, ich bin schon gespannt was die Anderen vorschlagen und argumentieren.
Tim schrieb: > Nutzt man für große, neu angefangene Programme dann eher C++ oder C#? Richtig große Projekte? C oder C++. Böse Zungen behaupten: C# Vereint die Nachteile von C++ mit den Nachteilen von Java. Lern einfach beide, schau was dir besser gefällt. Platformunabhängigkeit ist zwar schön, aber eigentlich hauptsächlich für Firmen interressant, die gleichzeitig eine Windows, Mac und Linux-Version verkaufen möchten. Z.B. Eagle: das ist C++ mit QT.
Tim schrieb: > Würde C# nicht von sich selber (wegen .net) schon Crossplatform tauglich > sein? Nö, denn das setzt voraus, daß das .Net-Geraffel auch auf andere Plattformen portiert wird und dort genauso funktioniert, wie die aktuelle Vorgabe aus Redmond. Zwar gibt es mit Mono ein entsprechendes Projekt für Linux, das aber unterscheidet sich im Funktionsumfang vom MS-"Standard" und hinkt den ständig neu erscheinenden Varianten immer hinterher. Tim schrieb: > Nutzt man für große, neu angefangene Programme dann eher C++ oder C#? "Man" nutzt das, was man besser kennt, und was besser zur Aufgabe passt. In C++ kann man ein Programm schreiben, das auch auf kleineren Systemen (embedded Linux o.ä.) läuft, mit dem .Net-Geraffel ist immer ein größerer Unterbau erforderlich.
Edding schrieb: > Platformunabhängigkeit ist zwar schön, aber eigentlich hauptsächlich für > Firmen interressant, die gleichzeitig eine Windows, Mac und > Linux-Version verkaufen möchten. Es ist auch für Entwickler interessant, die sich auf dem Arbeitsmarkt flexibler einen Arbeitgeber aussuchen können möchten.
Rufus Τ. Firefly schrieb: > Es ist auch für Entwickler interessant, die sich auf dem Arbeitsmarkt > flexibler einen Arbeitgeber aussuchen können möchten. http://www.joinvision.com/jv/x/n/t-TStatOfferDetail-statistic-pl
Rufus Τ. Firefly schrieb: > Es ist auch für Entwickler interessant, die sich auf dem Arbeitsmarkt > flexibler einen Arbeitgeber aussuchen können möchten. Deswegen: Edding schrieb: > Lern einfach beide, schau was dir besser gefällt. Dann kann man sowohl C# als auch C++ in der Bewerbung erwähnen. In der Arbeit programmier ich zur Zeit C++ mit QT für Client-Anwendungen (Mac + Windows), C++ "pur" für den Server-Teil (Linux). Dazu diverse Script-Sprachen + DHTML + Javascript für passende Web-Clients. Wenn wegen eines Auftrags halt noch C# dazu kommt, was solls, dann lern ich das halt. Und zum Ausspannen in der Freizeit programmier ich ATTinies in C ;)
Ich möchte es für ein größeres Projekt gewerblich nutzen. Dazu brauchen wir eine performante GUI die auch auf MAC und Win laufen sollte. Lern einfach beide ist gut :) Glaube nicht das mein Arbeitgeber das zahlen wird - mir wäre eine Vorab - Entscheidung sehr wichtig. Wenn ich mit C# Crossplatform arbeiten möchte, gibt es doch bestimmt auch eine Bibliothek wie QT oder. Tim
@Edding: Das mit den Atmels kommt mir bekannt vor ;) Da nutze ich den GCC. Tim
Tim schrieb: > Ich möchte es für ein größeres Projekt gewerblich nutzen. > Dazu brauchen wir eine performante GUI die auch auf MAC und Win laufen > sollte. C# Auf dem Mac (über Mono) ist IMHO noch nicht so weit. C++ mit QT ist für beide schon lange verfügbar, ausgereift und angenehm zu programmieren. QT kann lizenzkostenfrei in komerziellen Anwendungen verwendet werden (Seit der 4er Version unter der LGPL) solange dynamisch gelinkt wird. Support und abweichende Lizensierung gibts bei Bedarf von Nokia.
Tim schrieb: > Ich möchte es für ein größeres Projekt gewerblich nutzen. > Dazu brauchen wir eine performante GUI die auch auf MAC und Win laufen > sollte. Dann nimm C++, das ist der Standard. C# ist ein nettes Spielzeug, ähnlich wie Visual Basic, aber das steht und fällt mit der Laune von Microsoft. So wie J++ da kräht kein Hahn mehr danach. Wenns hauptsächlich im Web (Webservices, dyn. Webseiten etc.) laufen soll ist wegen der absolut besten Cross-Plattform (und cross-database) Tauglichkeit auch Java zu empfehlen. Für Windows Anwendungen mit dicken GUIs dann aber eher nicht.
U.R. Schmitt schrieb: > Dann nimm C++, das ist der Standard. > C# ist ein nettes Spielzeug, Vorsicht, von MS gibt es mit "Managed C++" bzw. "C++/CLI" eine Perversion, die mit C++ nicht viel mehr als den Namen gemein hat und auch auf dem .Net-Geraffel aufsetzt. Wenn C++, dann "echtes" C++, also welches, das auch von Nicht-MS-Compilern übersetzt werden kann (nicht, daß der C++-Compiler von MS schlecht wäre). Eine Alternative zu Qt ist übrigens wxWidgets - wie ich in diesem Thread bereit schrieb, ist das die Grundlage für Audacity, das bekanntlich unter Windows, OS X und Linux verwendbar ist. Wer nativ unter OS X entwickeln will, der sollte sich allerdings auch in Sachen Objective-C umsehen, denn das ist AFAIK Voraussetzung für die Nutzung des Cocoa-Frameworks*, und das wiederum Voraussetzung für 64-Bit-Anwendungen. Mit dem C-basierten Carbon**-Framework lassen sich nur 32-Bit-Anwendungen erstellen. *) http://en.wikipedia.org/wiki/Cocoa_%28API%29 **) http://en.wikipedia.org/wiki/Carbon_%28API%29
Rufus Τ. Firefly schrieb: > Wer nativ unter OS X entwickeln will, der sollte sich allerdings auch in > Sachen Objective-C umsehen, denn das ist AFAIK Voraussetzung für die > Nutzung des Cocoa-Frameworks, QT kann auf dem Mac übrigens PPC + Intel, sowie 32 + 64 Bit und Carbon + Cocoa: http://doc.trolltech.com/4.7/developing-on-mac.html Und QT benutzt die MacOS-X-APIs zum Rendern der GUI, schaut also "Native" aus, benutzt systemweite Themes und verhält sich im großen und ganzen automatisch so, wie sich die Mac-User das erwarten. http://doc.trolltech.com/4.7/qtmac-as-native.html
Vielen Danke auf jeden Fall einmal für all Eure Hilfe. Die Tips haben mir bisher schon extrem viel weiter geholfen! Ich habe eigentlich damit gerechnet, das ich nicht so nette Antworten bekommen würde wenn ich nach C# oder C++ frage ;-) Hoffentlich finden den Threat auch viele Leute die genau so hin und her gerissen sind... Audacity habe ich mir einmal angeschaut - das scheint ja schonmal super bei Mac und Win zu laufen. Eagle habe ich auch auf meinem Mac getestet. Es steht in unserem Fall einiges für C++ statt C#. Nun noch die genauen Unterschiede zwischen QT und wxWidgets nachschlagen - ich glaube ich habe bald meine Frage komplett beantwortet, jeappie :) Tim
> Wenn ich mit C# Crossplatform arbeiten möchte, gibt es doch bestimmt > auch eine Bibliothek wie QT oder. Nichts was wirklich an Qt oder wxWidgets rankommt. Wenn Crossplatformfähigkeit dein Hauptkriterium ist, bist du mit C++ mit Qt oder wxWidgets besser bedient.
Bartli schrieb: > Nichts was wirklich an Qt oder wxWidgets rankommt. Wenn > Crossplatformfähigkeit dein Hauptkriterium ist, bist du mit C++ mit Qt > oder wxWidgets besser bedient. Siehe hier: http://www.mono-project.com/Mono:OSX#Building_Client_Applications d.H. für Windows+Mac müsstest du entweder GTK# oder Windows.Forms verwenden. Bei beiden vermerkt: > Applications look foreign on OSX. Worauf Mac-User erfahrungsgemäẞ recht allergisch reagieren.
> ...GTK# oder Windows.Forms...
Eben, sag ich doch. Nichts was wirklich an Qt oder wxWidgets rankommt.
Bartli schrieb: >> Wenn ich mit C# Crossplatform arbeiten möchte, gibt es doch bestimmt >> auch eine Bibliothek wie QT oder. > > Nichts was wirklich an Qt oder wxWidgets rankommt. Wenn > Crossplatformfähigkeit dein Hauptkriterium ist, bist du mit C++ mit Qt > oder wxWidgets besser bedient. Wenn OSX und Windows reichen kann man sich auch Silverlight ansehen... (vom geringeren Entwicklungsaufwand gegenüber anderen Frameworks und C++ mal abgesehen scnr). http://channel9.msdn.com/Blogs/mtaulty/Silverlight-3-Running-Out-Of-Browser-Apps-on-the-Macintosh
Edding schrieb: > QT kann lizenzkostenfrei in komerziellen Anwendungen verwendet werden > (Seit der 4er Version unter der LGPL) solange dynamisch gelinkt wird. Genauer gesagt seit Version 4.5.
Wenn du wirklich gute Interoperatibilität willst, dann nimm Java. Das ist wirklich überall gleich gut. Auch große GUIs gehen damit. Vielleicht laufen die Anwendungen dann nicht mehr auf 15 Jahre alter Hardware, aber auf den meisten anderen, auch auf Tablet PCs und Smartphones mit Android. Wenn dann noch eine "Ähpp" (schrecklicher Ausdruck!) verlangt wird, kein Problem dank des JavaME, das sogar Touchscreens unterstützt. Ich habe es auch schon gesehen, dass die eigentliche Anwendung als DLL in C++ geschrieben war und dann eine Java-Oberfläche hatte. So konnten die Teile, die wirklich Geschwindigkeit brauchten, optimiert werden (Viele Anwendung brauchen gar nicht die gesamte Rechnenpower heutiger CPUs) und die Oberfläche sah trotzdem gleich aus. Auch wenn es hier viele verärgert, ist C# keine schlechte Sprache. Heutzutage werden sogar Computerspiele bis auf die 3D-Engines in C# geschrieben. C# ist im Grunde genommen ein Java, das auf Windows optimiert wurde. Und solange Windows marktführend ist, tja, sollte man das nicht ignorieren. Wichtig ist zu wissen, dass ein einfaches Dialogfeld eher gut aussehen muss als dass die Reaktionszeit bei 15 Nanosekunden anstatt 10 Mikrosekunden liegt. Also: Immer drauf gucken, was man braucht. Mit freundlichen Grüßen, Valentin Buck
Nö, C# ist an sich tatsächlich keine schlechte Sprache.
Das eigentliche Problem ist das .NET Framework: Windows.Forms z.B. kann
sich also echt nicht mit QtGui messen. Monos Framework (nicht die
Compiler, die halten besser mit) hinkt notorisch hinter MS.NET her,
Crossplatformfähig ist man daher also auch nur bedingt.
> Wenn OSX und Windows reichen kann man sich auch Silverlight ansehen...
Silverlight wird für mich ab dann wieder interessant, wenn das Teil (so
wie Silverlight Embedded) ganz ohne Sandbox betrieben werden kann (ja,
dafür ist WPF da. Ich hätte das trotzdem gerne auch für Silverlight).
Ist da was im Gange?
Bartli schrieb: > Nö, C# ist an sich tatsächlich keine schlechte Sprache. > > Das eigentliche Problem ist das .NET Framework: Windows.Forms z.B. kann > sich also echt nicht mit QtGui messen. Sehe da zwar keine großen Unterschiede, außer das es für WinForms keinen deklarativen Ansatz gibt wie bei Qt mit QtQuick/QML (was aber im Vergleich zu WPF+XAML mehr als unausgegoren ist, Javascript im deklarativen Teil etc. pp.). Vernünftiges DataBinding gibt's dagegen für WinForms und WPF, für Qt aber immer noch nicht. >> Wenn OSX und Windows reichen kann man sich auch Silverlight ansehen... > > Silverlight wird für mich ab dann wieder interessant, wenn das Teil (so > wie Silverlight Embedded) ganz ohne Sandbox betrieben werden kann (ja, > dafür ist WPF da. Ich hätte das trotzdem gerne auch für Silverlight). > Ist da was im Gange? In SL4 wurde schon einiges umgestellt (Stichwort: Trusted Applications http://msdn.microsoft.com/en-us/library/ee721083(v=vs.95).aspx). Für SL5 wird das nochmals erweitert (http://www.microsoft.com/silverlight/future/ und abwarten was die Beta bringt...).
Hmm, die zeitkritischen Sachen könnte man in der Applikation auch in eine .dll auslagern, das stimmt schon... Wäre Java wirklich zu verwenden wenn man eine große GUI hat die auch Gesten und bewegte Timelines verwalten muß? Tim
Tim schrieb: > Wäre Java wirklich zu verwenden wenn man eine große GUI hat die auch > Gesten und bewegte Timelines verwalten muß? ich würde sage nein, java fühlt sich auf vielen Platformen wie ein fremdkörper an. z.b. Standard tastenkombination gehen nicht. Dialoge sind nur den nativen nachgebaut verhalten sich aber anders usw.
Java hat seinen ganz eigenen Style. Gestenerkennung geht mit den eingebauten Mitteln gut und die GUI ist viel flexibler als man denkt. Nur, wie schon gesagt wurde, die Tastenkombinationen muss man selber setzen. Die Beschwerden über Dialoge kenne ich jetzt nicht so (in Win7 und Debian funktionieren die ganz gut!). Leider funktioniert der Windows-Style nicht als Aero-Oberfläche, da wird langsam mal ein Update nötig! Mit freundlichen Grüßen, Valentin Buck
Ich würde C++ mit QT nehmen, relativ wenig Aufwand, wenn man es beherrscht, super Performance und Plattformunabhänig (zum großen Teil, klar muss für jedes neu kompiliert werden, aber der Code sollte gleich bleiben). Java ist auch nicht schlecht, aber etwas unperformant (aber besser als .NET) und wie gesagt, meine Erfahrung zeigt es passt sich nie dem System an. Außerdem wird wie bei C# Zusatzsoftware beim Endbenutzer gebraucht (halt Java oder .NET Framework, wobei ich dann lieber Java nehmen würde, alleine weil man die JAR Datei einfach weiter geben kann ohne Änderungen). Fazit: C++ und QT oder wxWiggets (Geschmackssache, ich bevorzuge QT...). MfG
DDT schrieb: > Ich würde C++ mit QT nehmen, relativ wenig Aufwand, wenn man es > beherrscht, super Performance und Plattformunabhänig (zum großen Teil, > klar muss für jedes neu kompiliert werden, aber der Code sollte gleich > bleiben). Wenn man vor der Konkurrenz fertig werden will: C# oder Java und nur die wirklich kritischen Teile in C++. Die Grafikdarstellung ist sowohl bei Java als auch bei .NET(WPF) seit längerem hardwarebeschleunigt und somit auch kein Grund für C++. Hinzukommt das es die zu C# und Java gehörigen Frameworks nicht für C++ gibt (abgesehen von C++/CLI) und Qt nur einen winzigen Bruchteil dessen zur Verfügung stellt etc.pp.
Nur um mal was in den Raum zu werfen: http://www.joinvision.com/jv/x/n/t-TStatOfferHistoryDetail-statistic-pl Daran sieht man, was industriell gefragt ist... Mit freundlichen Grüßen, Valentin Buck
Arc Net schrieb: > Wenn man vor der Konkurrenz fertig werden will: C# oder Java und nur die > wirklich kritischen Teile in C++. Du hast noch nie mit der QT gearbeitet, oder? Soviel schneller bist du beim Programmieren mit java nicht, viel kleiner wird der Code auch nicht. Wenn man aber Java nehmen will, und nicht auf die Vorteile der QT verzichten möchte: http://doc.qt.nokia.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-index.html http://en.wikipedia.org/wiki/Qt_Jambi
DDT schrieb: > Java ist auch nicht schlecht, aber etwas unperformant (aber besser als > .NET) gibt es für diese Behauptung auch Belege? Meine Erfahrung und was ich gelesen hatte deuten auf das gegenteil hin. .NET wurde extra auf Performace ausgelegt und schon die ersten Versionen waren teilweise schneller als Java.
Edding schrieb: > Wenn man aber Java nehmen will, und nicht auf die Vorteile der QT > verzichten möchte: Völliger Schwachsinn. Java bringt eine eigene GUI mit. Guck dir mal die Marktanteile an! C++ wird nur noch für wirkliche Leistungsanwendungen verwendet, wie Spiele, Videobearbeitung und Crypto. Der Rest ist am Absterben. Java und .NET haben ein zu mächtiges Framework, als dass C++ da was machen könnte. Teilweise werden ganze Blöcke Code durch eine Zeile ersetzt. Das Visual Studio (und übrigens auch das freie SharpDevelop) haben eine GUI-zusammenklick-Oberfläche. Klar kann man das mit Pixelangaben und selbst gebauten Steuerelementen alles noch viel schöner machen, aber dafür ist einfach zu viel da. Du willst eine Musikdatei abspielen und den User das kontrollieren lassen? Schnapp dir das Windows Media ActiveX. Oder das VLC ActiveX. Oder Quicktime. Oder... Der größte Nachteil von .NET ist, dass es sehr leicht zu dekompilieren ist. Mit teilweise sogar kostenlosen Tools ist man schnell am Quellcode. In der Sprache deiner Wahl. Auch für Java gibt es so etwas. Das kann man verhindern, indem man die Dinger einfach nativ in echten Maschinencode kompiliert (geht wirklich, aber dann geht die Interoperatibilität flöten) oder vielleicht so etwas wie eine Lizenz einbaut. Wenn man Angst hat, dass einem das Programm gestohlen wird, sollte man in einen anderen Bereich wechseln. Wenn es eine gute Software gibt, dann dauert es meistens nicht lange, bis es einen Klon gibt. Verbergen von Inhalten ist sowiso der falsche Ansatz. Guck dir mal Open-Source-Softwarefirmen an. Komisch. Jeder kann das kompilieren und die machen trotzdem Geld. Und warum? Weil die dann einfach die kompilierte Version verkaufen. Oder Support (Siehe SUN (jetzt Oracle)). Die gesamte Branche wird sich entscheidend ändern. In einigen Jahren wird Software nichts mehr kosten. Weil es zu viel davon gibt. Weil Information keine Materie ist. Und Geld wird man nur noch mit Wissen verdient. Oder so was... Mit freundlichen Grüßen, Valentin Buck
Vielleicht sollte man die Statistik mal gescheit aufdröseln. Fraglich ist auch, wie sich 'Plattformunabhängigkeit' definiert. Mit MFC/C# binde ich mir effektiv einen x86-Klotz ans Bein. Selbst bei ARM rudert man ja schon wieder um Kreis und es will mit Windows nicht gescheit vorangehen (http://www.heise.de/newsticker/meldung/ARM-Chef-daempft-Spekulationen-ueber-Windows-Systeme-und-Server-1169698.html ). Bezogen auf WinCE/Mobile herrscht nichtmal unter Windows selbst Portabilität. Auch so Dinger wie ActiveX oder COM sind letztlich Augenwischerei. Verlassen kann man sich dabei auf garnichts, Abhängigkeiten werden nicht gepflegt. Dann lieber wohldefinierte API in eine Bibliothek hinein. Aber ne, Microsoft muss erstmal den dynamischen Linker grundlegend reparieren... Schreibe ich sauberes C(++) und dann z.B. mit QT, dann erschlage ich damit so ziemlich alles, was heute irgendwie bootbar ist und sicherlich auch alles, was in zehn Jahren am Markt sein wird. Je mehr ich mich mit Windows-Programmierung auseinandersetze, umso mehr wird es ein Fass ohne Boden. Redundanz in tausend Varianten, gegen die selbst die 100. Regexp-Bibliothek unter Unix alt aussieht :-) Auf welches Pferd soll man denn noch setzen? Viel Spaß damit :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.