1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › IMHO: Qt vor dem Abgrund

QT? War das nicht C++?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. QT? War das nicht C++?

    Autor: ilja 16.02.11 - 16:04

    Ich kann verstehen, warum Nokia QT loswerden will. C++ ist nicht mehr auf der Höhe der Zeit. Damit jetzt noch ein neues UI Framework für Mobilgeräte zu erstellen, bringt es nicht.
    Die Sprache hängt von den Features und dem Design hinter Java und C# hinterher. Selbst Apple hat mit Version 2.0 Objective-C nochmal aufgewertet.
    Da stinkt C++ einfach ab.

    Features, die C++ Fehlen:
    - Blocks/Closures
    - Introspektion/Member availability ("Hey, unbekanntes Objekt, kannst Du Funktion mit Namen "xyz" ausführen?")
    - Objektbibliothek, Runtime und Sprache kommen von verschiedenen Organisationen/Firmen. Da kann man nicht einfach mal wie Apple oder MS zum nächsten OS-Update ein paar neue Features ausrollen.
    - Bindings zw. Userinterface und Datenobjekten

    Features, die C++ hat - die man aber nicht will:
    - Operator Overloading (write once, read never ! - kann man auch gleich Perl nehmen)
    - Templates (gibt wohl schon eine Grund, warum es das nur hier gibt)
    - Multiple Vererbung (damit man auch richtig unverständliche Objekt-Architekturen entwerfen kann)
    - default-Parameter für Funktion (oh Graus)

    Grüße,
    Ilja

  2. Re: QT? War das nicht C++?

    Autor: bstea 16.02.11 - 16:13

    Ich mag default-Parameter, irgendwie pythonisch.

  3. Re: QT? War das nicht C++?

    Autor: thomas001le 16.02.11 - 16:45

    C++ hängt hinter Java hinterher? Am Anfang dachte ich du wllst trollen, aber nach 2 mal lesen sieht das so aus als glaubst du das sogar ;)
    > - Blocks/Closures
    Jo, es gibt zwar Funktionsobjekte, also die operator() überladen, aber keine funktionsliterale wie eine lambda expression, kommt in C++1X.

    > - Introspektion/Member availability ("Hey, unbekanntes Objekt, kannst Du Funktion mit Namen "xyz" ausführen?")
    Und dann? du musst ja die Signatur von "xyz" kennen um xyz aufzurufen, also musst du schon fragen "Kannst du 'xyz' mit Signatur void (int) aufrufen", das geht nicht stimmt, bringt aber auch viel overhead in die RTTI, und wenn "xyz" ein fester Name ist, kann man das durch Vererbung lösen.

    > - Objektbibliothek, Runtime und Sprache kommen von verschiedenen Organisationen/Firmen. Da kann man nicht einfach mal wie Apple oder MS zum nächsten OS-Update ein paar neue Features ausrollen.
    Und das ist auch gut so...mir sind Sprachen sympatischer wo ein "ISO" vor der Sprachversion steht. Wieviel C++ Implementierungen gibt es, wieviele Java implementierungen gibt es? Ach halt...man darf sich ja erst Java nennen wenn man so ein Oracle toolkit bestanden hat was komische Lizenzbedingungen hat?

    > - Bindings zw. Userinterface und Datenobjekten
    öhm whut?

    > - Operator Overloading (write once, read never ! - kann man auch gleich Perl nehmen)
    Na klar, overloading ist soo böse, viel schöner ist natürlich
    M1.matrixProduct(M2.scalarProduct(k)).vectorProduct(v1.add(v2)) statt M1*(k*M2)*(v1+v2)
    dieser teufliche unlesbare C++ Code mit überladungen....

    > - Templates (gibt wohl schon eine Grund, warum es das nur hier gibt)
    Wahrscheinlich weil keiner der Zielgruppe von Java sowas kompliziertes wie partielle Spezialisierungen oder SFINAE zumuten will....

    > - Multiple Vererbung (damit man auch richtig unverständliche Objekt-Architekturen entwerfen kann)
    Ob dus glaubst oder nicht, Mehrfachvererbung kann sehr praktisch sein. Nebenbei geht die in Java auch, aber eben nur für interfaces, was ja im prinzip spezielle klassen in c++ sind. Man kann also die gleichen Hierachien in Java wie in C++ erzeugen.

    > - default-Parameter für Funktion (oh Graus)
    sind wohl ähnlich negativ für die lesbarkeit wie operator overloading
    vector<int> v(allocator<int>()) ist viel klarer als vector<int> v;
    durch den default parameter sieht man wieder mal nicht was passiert.

  4. Re: QT? War das nicht C++?

    Autor: xcvb 16.02.11 - 17:06

    > - Bindings zw. Userinterface und Datenobjekten
    Qt hat mit dem Signal/Slot-Konzept doch die Perfekte Lösung dazu geschaffen. Außerdem ist Qt nur eine Api und kann auch von anderen Sprachen verwendet werden.

  5. Re: QT? War das nicht C++?

    Autor: ilja 16.02.11 - 17:08

    thomas001le schrieb:
    --------------------------------------------------------------------------------

    > > - Blocks/Closures
    > Jo, es gibt zwar Funktionsobjekte, also die operator() überladen, aber
    > keine funktionsliterale wie eine lambda expression, kommt in C++1X.

    Es ist schön, dass es bald in den Sprachstandard kommt. Aber das zeigt auch wieder eines der Probleme von QT/C++. Das Feature muss erst in den Standard, dann in den Compiler und die Runtime, dann in die Klassenbibliothek. In dem Tempo kommt man schwer mit Apple/MS/Google mit.

    > > - Introspektion/Member availability ("Hey, unbekanntes Objekt, kannst Du
    > Funktion mit Namen "xyz" ausführen?")
    > Und dann? du musst ja die Signatur von "xyz" kennen um xyz aufzurufen, also
    > musst du schon fragen "Kannst du 'xyz' mit Signatur void (int) aufrufen",
    > das geht nicht stimmt, bringt aber auch viel overhead in die RTTI, und wenn
    > "xyz" ein fester Name ist, kann man das durch Vererbung lösen.

    Es soll ja Umgebungen geben, die können einen String zur Laufzeit in einen Funktionssignatur umwandeln. Ganz praktisch das.

    > > - Objektbibliothek, Runtime und Sprache kommen von verschiedenen
    > Organisationen/Firmen. Da kann man nicht einfach mal wie Apple oder MS zum
    > nächsten OS-Update ein paar neue Features ausrollen.
    > Und das ist auch gut so...mir sind Sprachen sympatischer wo ein "ISO" vor
    > der Sprachversion steht. Wieviel C++ Implementierungen gibt es, wieviele
    > Java implementierungen gibt es? Ach halt...man darf sich ja erst Java
    > nennen wenn man so ein Oracle toolkit bestanden hat was komische
    > Lizenzbedingungen hat?

    Das mag im Allgemeinen schon so sein, trifft aber auf die aktuelle Mobillandschaft nicht zu. Da gibt es ein 1:1 Mapping von Hersteller zu Sprache/Runtime/Bibliothek. (Was auch immer das Java-Derivat das Google nutzt nun genau auch ist).

    []

    Über meine restlichen Punkt kann man in der Tat trefflich streiten. In meiner Erfahrung haben sich diese C++ Features bei größeren Projekten immer negativ ausgewirkt.

    Grüße,
    Ilja

  6. Re: QT? War das nicht C++?

    Autor: bstea 16.02.11 - 17:13

    Signal/Slots - Ist das nicht dieser Aufsatz auf C++, dass einem QT bietet?

  7. Re: QT? War das nicht C++?

    Autor: thomas001le 16.02.11 - 17:28

    ilja schrieb:
    --------------------------------------------------------------------------------
    > Es ist schön, dass es bald in den Sprachstandard kommt. Aber das zeigt auch
    > wieder eines der Probleme von QT/C++. Das Feature muss erst in den
    > Standard, dann in den Compiler und die Runtime, dann in die
    > Klassenbibliothek. In dem Tempo kommt man schwer mit Apple/MS/Google mit.

    Also Compiler, Runtime und Laufzeitbibliothek kommen doch aber meistens zusammen? ist bei der MS und der GNU Implementierung von C++ jedenfalls so. Und es gibt ja standard drafts (kennt man ja von html5 inzwischen) und die werden auch jetzt schon zum Teil von compilern implementiert. das angesprochenene lambda geht in gcc schon.
    Und ja klar, wenn sich MS eine Änderung an C# ausdenkt, kann MS die sofort implementieren und veröffentlichen, dann gibt es dann halt nur die MS implementierung und du bist auf diese angewiesen. Bei C++ hast du die Wahl. Okay bei C# hat man Mono, was aber auch nicht aktuell mit der referenz mithält.


    > Es soll ja Umgebungen geben, die können einen String zur Laufzeit in einen
    > Funktionssignatur umwandeln. Ganz praktisch das.

    Und wie mach ich dann statische compile-zeit typprüfung? Klar ich kann auch alles in einen boost::any kapseln, aber das ist nicht sinn der sache ;)

    > Das mag im Allgemeinen schon so sein, trifft aber auf die aktuelle
    > Mobillandschaft nicht zu. Da gibt es ein 1:1 Mapping von Hersteller zu
    > Sprache/Runtime/Bibliothek. (Was auch immer das Java-Derivat das Google
    > nutzt nun genau auch ist).
    Wenn man damit leben kann, dass es ein Google-Java, ein Oracle-Java, usw gibt, ist die sichtweise schon richtig, ob das allerdings ein qualitätsmerkmal der sprache ist, weiss ich nicht.

    > Über meine restlichen Punkt kann man in der Tat trefflich streiten. In
    > meiner Erfahrung haben sich diese C++ Features bei größeren Projekten immer
    > negativ ausgewirkt.

    Klar, je mehr man schiessen kann, umso größer sind die chancen seinen eigenen fuß zu treffen :D

    Grüße, Thomas

  8. Re: QT? War das nicht C++?

    Autor: TheUltimateStar 16.02.11 - 17:29

    ilja schrieb:
    --------------------------------------------------------------------------------
    > Ich kann verstehen, warum Nokia QT loswerden will. C++ ist nicht mehr auf
    > der Höhe der Zeit. Damit jetzt noch ein neues UI Framework für Mobilgeräte
    > zu erstellen, bringt es nicht.
    > Die Sprache hängt von den Features und dem Design hinter Java und C#
    > hinterher. Selbst Apple hat mit Version 2.0 Objective-C nochmal
    > aufgewertet.
    > Da stinkt C++ einfach ab.
    Ich liebe solche Diskussionen, einfach weil sie die Programmiersprache, eigentlich nur Mittel zum Zweck, total überbewerten. Die höhere integrierte Abstraktion diverser Dinge in anderen tollen bequemen Programmiersprachen lassen sich in C++ oft auch über entsprechende Bibliotheken nutzen. Da haben aber natürlich beide Seiten Vor- und Nachteile. Diese Features werden einem nie Geschenkt. Oft benötigen sie halt zusätzliche Informationen zu den verwendeten Objekten, diese müssen irgendwo erfasst, gespeichert und abrufbar gehalten werden. Benutzt man sie regelmäßig ist der Komfort einer Sprachintegration oft eine bequeme Sache, nutzt man sie aber nicht so wird man diesen Overhead trotzdem nicht los. Bei C++ sind solche Features hingegen oft nicht ganz so bequem, dafür hat man halt auch selbst in der Hand was man tut/braucht/nutzt.

    > Features, die C++ Fehlen:
    > - Blocks/Closures
    Die Anonymität, also die Angabe von namenslosen Funktionsblöcken, bekommt man sicher nicht hin, aber mit Funktionszeigern bekommt man dieses Paradigma auch in C abgebildet. Aber man rückt auch hier näher heran, in der Tat wird dieses Feature derzeit vom C++ Standards Committee beraten, und laut Wikipedia unterstützen dies bereits(also wohl eine Working-Draft-Implementerung) der Visual C++ 2010 und der GCC-4.5 Compiler.

    > - Introspektion/Member availability ("Hey, unbekanntes Objekt, kannst Du
    > Funktion mit Namen "xyz" ausführen?")
    Qt liefert dir das, das Spielchen kannst du mit jeder von QObject abgeleiteten Klasse spielen.

    > - Objektbibliothek, Runtime und Sprache kommen von verschiedenen
    > Organisationen/Firmen. Da kann man nicht einfach mal wie Apple oder MS zum
    > nächsten OS-Update ein paar neue Features ausrollen.
    Ist das nicht zum einen überall so und was hat das mit einer Programmiersprache wie C++ zu tun? Bei .NET kommt die Sprache von Microsoft, die Runtime meist auch, kann aber wie bei Mono auch von einem Dritten kommen und für jede Sprache gibt es zusätzliche Bibliotheken von Dritten. Letztlich ist dies ein eher organisatorisches Problem. Bringe ich ein neues Feature so muss dies verfügbar gemacht werden, dazu müssen entsprechende Bibliotheken für die angebotenen Entwicklungsumgebungen zur Verfügung gestellt werden. Aber dazu muss doch keine Programmiersprache extra erweitert werden, von was für OS-Features redest du denn?

    > - Bindings zw. Userinterface und Datenobjekten
    Keine Ahnung was du da genau meinst, aber eine derartige Trennung der Datenhaltung, Programmlogik und der Oberfläche bietet doch jedes Anwendungsframework(Sprachfeature sind das zudem schon mal gar keine)?

    > Features, die C++ hat - die man aber nicht will:
    > - Operator Overloading (write once, read never ! - kann man auch gleich
    > Perl nehmen)
    > - Templates (gibt wohl schon eine Grund, warum es das nur hier gibt)
    > - Multiple Vererbung (damit man auch richtig unverständliche
    > Objekt-Architekturen entwerfen kann)
    > - default-Parameter für Funktion (oh Graus)
    Und wer zwingt dich diese zu nutzen? Besser als anders herum, gern Features nutzen wollen die es aber leider nicht gibt.

  9. Re: QT? War das nicht C++?

    Autor: Satan 16.02.11 - 20:19

    Bist du ein von Oracle bezahlter Java-Fanboy oder hast du einfach nur keine Ahnung von Programmierung?

    > Features, die C++ hat - die man aber nicht will:
    > - Operator Overloading (write once, read never ! - kann man auch gleich Perl nehmen)
    Also.. ich finds schon toll und nutze das teilweise auch recht exzessiv. (nebenbei in Pascal.) Brauch ich nicht dauernd "VectorC := VectorA.Add(VectorB)" schreiben, sodndern einfach ein lesbares "VectorC := VectorA + VectorB".

    > - Templates (gibt wohl schon eine Grund, warum es das nur hier gibt)
    Okay, hab ich nichts mit am Hut, hat aber schätzungsweise seine Daseinsberechtigung.

    > - Multiple Vererbung (damit man auch richtig unverständliche Objekt-Architekturen
    > entwerfen kann)
    Eben, man *kann* es, das heisst nicht, dass man es *muss*. Würd ich mir unter Freepascal auch wünschen, ohne den Umweg über noch mehr Parent-Klassen oder Interfaces.
    So eine Sprache muss einen ja nicht daran hindern, wenn man damit nicht klarkommt, nutzt man es halt nicht, fertig.

    > - default-Parameter für Funktion (oh Graus)
    Benutz ich auch dauernd. Gibt so viele Anwendungsgebiete dafür, bspw. wenn man was suchen möchte, aber die *Möglichkeit* haben möchte, erst ab einem bestimmten Zeichen zu suchen (z.b. wenn man in einer anderen Funktion die Liste aller Matches ausgeben will). Beherrscht nebenbei praktisch jede Programmiersprache.

  10. Re: QT? War das nicht C++?

    Autor: Satan 16.02.11 - 20:25

    Und die hier hab ich noch vergessen:

    > Features, die C++ Fehlen:
    > - Blocks/Closures
    Da ich jetzt mal keine Ahnung hab, was du meinst, halte ich lieber die Klappe.

    > - Introspektion/Member availability ("Hey, unbekanntes Objekt, kannst Du Funktion
    > mit Namen "xyz" ausführen?")
    "Nö" - und nun?
    Das kann man bei ner Scriptsprache machen, nicht bei ner - sagen wir ruhig relativ maschinennahen - Hochleistungssprache.

    > - Objektbibliothek, Runtime und Sprache kommen von verschiedenen
    > Organisationen/Firmen. Da kann man nicht einfach mal wie Apple oder MS zum nächsten
    > OS-Update ein paar neue Features ausrollen.
    Die Bibliotheken sind wirklich ein Chaos.

    > - Bindings zw. Userinterface und Datenobjekten
    Ich frage mich gerade, seit wann C++ oder irgendeine andere Sprache ein Userinterface besitzt. Und was du eigentlich verlangst, ist mir auch schleierhaft.

  11. Re: QT? War das nicht C++?

    Autor: aiscape 16.02.11 - 21:41

    ilja schrieb:
    --------------------------------------------------------------------------------
    > ... C++ ist nicht mehr auf
    > der Höhe der Zeit. ...

    (YAWN)

  12. Re: QT? War das nicht C++?

    Autor: Hello_World 17.02.11 - 01:26

    ilja schrieb:
    --------------------------------------------------------------------------------
    > Features, die C++ Fehlen:
    > - Blocks/Closures
    Gibt es z. B. in Boost.Phoenix.

    > - Introspektion/Member availability
    Der Speicheroverhead dafür ist in einer Low-Level-Sprache wie C++ nicht akzeptabel.

    > - Objektbibliothek, Runtime und Sprache kommen von verschiedenen
    > Organisationen/Firmen. Da kann man nicht einfach mal wie Apple oder MS zum
    > nächsten OS-Update ein paar neue Features ausrollen.
    Jeder Hersteller eines C++-Compilers kann alle Erweiterungen einbauen, die ihm passen (und das wird auch gemacht). Ob eine Klassenbibliothek diese dann benutzt, ist eine andere Frage. Die Herstellerunabhängigkeit ist jedenfalls eher eine Stärke als eine Schwäche.

    > - Bindings zw. Userinterface und Datenobjekten
    Es ist völlig unklar, was Du damit meinst.

    > Features, die C++ hat - die man aber nicht will:
    > - Operator Overloading (write once, read never)
    Sinnvoll eingesetzt verbessert es die Lesbarkeit des Codes erheblich. Und wenn ein Programmierer es an einer sinnlosen Stelle einsetzt, dann ist dieser Programmierer das Problem und nicht die Sprache. Diese Einsicht hat sich mittlerweile auch weithin durchgesetzt, schließlich erlaubt so ziemlich jede moderne Sprache das heute (z. B. C#, Scala, Python, Haskell uvm.).

    > - Templates (gibt wohl schon eine Grund, warum es das nur hier gibt)
    Das ist falsch, D hat z. B. auch Templates. Und sie sind in C++ zwar nicht perfekt, aber noch schlimmer als Templates wäre es, wenn man sie nicht hätte.

    > - Multiple Vererbung (damit man auch richtig unverständliche
    > Objekt-Architekturen entwerfen kann)
    Hier gilt das gleiche wie bei der Operatorüberladung. Wenn ein Programmierer damit unverständlichen Mist baut, dann ist dieser Programmierer das Problem. Und man kann es auch durchaus für Sinnvolles einsetzen, z. B. zur Implementierung von Mixins.

    > - default-Parameter für Funktion (oh Graus)
    Naja, man braucht es nicht, aber die Welt geht davon auch nicht unter.

  13. Re: QT? War das nicht C++?

    Autor: ichundso 17.02.11 - 09:26

    Also Binding ist kein Sprachfeature! Und Templates werden in Java/C# als Generics umgesetzt.

    Meiner Meinung nach ist das wichtigste Feature das für die Verwendung von c# spricht die Entwicklungsumgebung als ganzes. Ein C# .NET Programm zu entwerfen und zu programmieren ist definitiv kosten-/zeiteffizienter als es in jeder anderen Programmiersprache/Entwicklungsumgebung ist. Der entscheidende Vorteil der Plattform besteht vor allem im Umfang in der sie ausgeliefert wird und in der Unterstzützung durch die darauf getrimmte IDE. Ohne jeden Zweifel lässt sich alles was jemand in c# programmiert auch mit QT umsetzen. In c# jedoch in der Hälfte der Zeit ;-)

  14. Re: QT? War das nicht C++?

    Autor: greenhorn 17.02.11 - 11:19

    ichundso schrieb:
    --------------------------------------------------------------------------------
    > Also Binding ist kein Sprachfeature! Und Templates werden in Java/C# als
    > Generics umgesetzt.
    >
    > Meiner Meinung nach ist das wichtigste Feature das für die Verwendung von
    > c# spricht die Entwicklungsumgebung als ganzes. Ein C# .NET Programm zu
    > entwerfen und zu programmieren ist definitiv kosten-/zeiteffizienter als es
    > in jeder anderen Programmiersprache/Entwicklungsumgebung ist. Der
    > entscheidende Vorteil der Plattform besteht vor allem im Umfang in der sie
    > ausgeliefert wird und in der Unterstzützung durch die darauf getrimmte IDE.
    > Ohne jeden Zweifel lässt sich alles was jemand in c# programmiert auch mit
    > QT umsetzen. In c# jedoch in der Hälfte der Zeit ;-)

    Ich habe noch nie mit C# .NET gearbeitet. Ich schätze mal, du allerdings auch noch nicht mit Qt. Deswegen würde ich mich über eine gleiche Liste wie die folgende von dir freuen.

    Vorteile an Qt:
    - Alle Qt-Klassen haben ein Parent-Object und werden automatisch gelöscht, wenn das Parent-Object gelöscht wird, quasi Memory Management. (Man kann parent=0 setzen und dennoch selbst alles in die Hand nehmen)
    - Signals und Slots

    Damit umgeht Qt meines Erachtens schonmal die größten C++-Lästigkeiten.

    Außerdem mag ich sehr an Qt:
    - Schönes, einfaches und mächtiges Layout-System (d.h. man kann einstellen welche Widgets sich vergrößern/verkleinern sollen, wenn man die Fenstergröße ändert)
    - Alle Widgets lassen sich über CSS stylen
    - Gute Performance und relativ geringer Speicherverbrauch
    - Webkit-Widget
    - Gute bis sehr gute Datenbankklassen, inkl. Support für transactions und prepared statements und Mapping von Widgets auf Spalten
    - MVC Klassen (wie in Java/Cocoa), wobei mir Qt's Implementation über Model/View/Delegate sehr gut gefällt. Ist sicher auch Geschmackssache, auf jeden Fall funktioniert sie gut.
    - Guter GUI-Editor. Definitiv besser als z.B. der Interface Builder von XCode
    - Mächtige und performante grafische Operationen wie Alpha, Einfärben o.Ä. mit allen Widgets möglich.


    Was mich stört an Qt:
    - Keine animierten Layouts - damit wird ihr ganzes schönes Animation Framework unwichtig (obwohl das richtig viel kann)
    - Keine große Community - KDE zählt nicht, da muss man ganz kdelibs mitschleppen. Wenn man mal nach fertigen Klassen für Qt sucht, findet man Qxt, Qwt und sonst nur noch wenig. Ist meines Erachtens das Hauptproblem von Qt, und wenn sich das nicht ändert, wird das Toolkit auch nie wichtig werden.


    Insgesamt habe ich Qt damals gewählt, weil es mir erlaubt hat, eine GUI exakt so zu erstellen, wie ich es möchte, und das mit guter bis sehr guter Datenbankanbindung. Ich habe mich aber auch auf ein Betriebssystem (Windows) festgelegt und keine Cross-Platform-Anwendung geschrieben. Eine gute GUI ist OS abhängig.

  15. Re: QT? War das nicht C++?

    Autor: ichundso 17.02.11 - 12:08

    All das was du aufgezählt hast ist mit .NET ebenso machbar und der Plattform als Eigenschaft zuzuordnen. Nur dass die Datenbankanbindung bzw. der OR Mapper allem anderen um Längen vorraus ist.
    Zudem erzeugt man Web- und Desktop Anwenungen ohne die Entwicklungsumgebung oder die Plattform zu verlassen.
    Die Code Erzeugungsmechanismen von Visual Studio suchen definitiv ihresgleichen. Die gesamte Plattform wird von einem Konzern supported und kommt vollständig aus einer Hand.
    Die Anbindung des SQL Servers ist praktisch, da dieser Assemblies direkt aufnehmen und ausführen kann. Zudem kann man Datenbankprozeduren debuggen. Die Community rund um .NEt lässt aus meiner Sicht kaum Wünsche offen.
    Die gesamte Umgebung ist ideal aufeinander abgestimmt. Vom datenbankdesign über VS mit dem SQL Server, über den integrierte OR Mapper bis hin zum Oberflächendesigner der letztlich daten via Binding der oberfläche zuweist. Keine weiteren Tools. Kein Fremder Code. Maximale Effizienz. Und einfachste Migration nach einem Update der Plattform.

    In bestimmten Anwenungsfällen kommen dann noch besondere Features wie Reporting, oder Konzepte wie die Membership API, oder WCf hinzu. Alles vollkommen einheitlich im Naming, einfach zu verstehen wenn man mal begonnen hat und nahezu vollständig über Konfigurationsdialoge und Designer steuerbar ohne dem Entwickler die Möglichkeit zu rauben jederzeit auf alles Einfluss nehmen zu können. Funktionalität wird abonniert nicht darauf aufgebaut.

  16. Re: QT? War das nicht C++?

    Autor: /mecki78 17.02.11 - 12:20

    ilja schrieb:
    --------------------------------------------------------------------------------
    > Ich kann verstehen, warum Nokia QT loswerden will. C++ ist nicht mehr auf
    > der Höhe der Zeit.

    C++ war nie auf der Höhe der Zeit. Der Urvater der objektorientierten Programmierung hat mal so schön gesagt "Als er den Begriff objektorientierte Programmierung geprägt hat, hatte er mit Sicherheit nicht C++ im Sinn!". C++ ist ein fehlgeschlagener Versuch, C zu einer OO Sprache zu machen und das fatale an der Sprache ist, dass so ziemlich alle nur denkbaren und noch so abstrusen OO Features in die Sprache eingebaut wurden, was sie unnötig komplex macht. Die meisten anderen Sprachen haben einfach Features rausgeworfen, wenn sie diese nicht unbedingt als wichtig empfunden haben (weder C#, noch Java, noch Obj-C z.B. kennen Multivererbung). Außerdem konnte man sich bei C++ anscheinend nicht einigen, ob die Sprache jetzt mehr zur Compile- oder mehr zur Laufzeit bestimmte OO Features umsetzen soll, daher hat man beide Möglichkeiten eingebaut, was zwar deren Vor-, aber eben auch deren Nachteile miteinander vereint. Die meisten anderen Sprachen setzen auf Laufzeitbindings, was sie deutlich dynamischer macht. Klar kann man das auch bei C++ erreichen, nur lastet hier wieder alle Arbeit auf dem Programmierer. Ich konnte C++ noch nie etwas abgewinnen.

    Aber ich denke nicht, dass Nokia Qt wegen C++ verworfen hat, denn sie wollen ja jetzt Windows auf ihren Phones einsetzen und dort benutzen die meisten Apps ja MSVC, also Microsoft Visual C++. Die Windows API ist zwar in ihrem Kern überall C, AFAIK, aber wer benutzt die denn bitte heute noch direkt? Sofern eine Windows App nicht in einer .NET Sprache geschrieben ist (C#, VB.NET, J#) benutzt sie in aller Regel die C++ Api von Microsoft für UI Elemente, weil es hier auch IDE Editoren für gibt, um sich seine UI zusammen zu klicken.

    /Mecki

  17. Re: QT? War das nicht C++?

    Autor: ichundso 17.02.11 - 12:23

    Windows Phone Apps kann man NUR in c# oder VB.NET programmieren. Alles andere ist ausgeschlossen. Also nix mit VC++

  18. Re: QT? War das nicht C++?

    Autor: Genesis 17.02.11 - 13:00

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > C++ ist ein fehlgeschlagener Versuch, C zu einer OO Sprache
    > zu machen und das fatale an der Sprache ist, dass so ziemlich alle nur
    > denkbaren und noch so abstrusen OO Features in die Sprache eingebaut
    > wurden, was sie unnötig komplex macht.
    Du nennst es komplex, ich sage es ist flexibel.
    > Die meisten anderen Sprachen haben
    > einfach Features rausgeworfen, wenn sie diese nicht unbedingt als wichtig
    > empfunden haben (weder C#, noch Java, noch Obj-C z.B. kennen
    > Multivererbung).
    Du sagst es ist einfach, ich nenne es beschränkt.

    MfG Genesis

  19. Re: QT? War das nicht C++?

    Autor: ichundso 17.02.11 - 13:03

    Tja. Deine Sicht lässt sich vor dem Hintergrund der kosteneffizienten Entwicklung von Anwendungen meist nicht halten! Die "Flexibilität" wird schlicht nicht benötigt. Zumal man auf den anderen Plattformen genauso alles programmieren kann, was dein Argument der Beschränktheit entkräftet.

  20. Re: QT? War das nicht C++?

    Autor: Genesis 17.02.11 - 13:13

    ichundso schrieb:
    --------------------------------------------------------------------------------
    > Tja.
    Das soll ein Satz sein?
    > Deine Sicht lässt sich vor dem Hintergrund der kosteneffizienten
    > Entwicklung von Anwendungen meist nicht halten!
    Es kommt darauf an wer etwas zu welchem Zweck mit welchen Methoden entwickelt.
    > Die "Flexibilität" wird schlicht nicht benötigt.
    Nein, bei keinem Projekt in keinem Zusammenhang von keinem Entwickler auf der Welt, wird jemals diese Flexibilität benötigt.
    Natürlich sind überall die Anforderungen gleich, deshalb werden sie auch meistens nicht beachtet!
    </Sarkasmus>
    > Zumal man auf den anderen Plattformen genauso
    > alles programmieren kann, was dein Argument der Beschränktheit entkräftet.
    Meine Aussage zielt nicht darauf ab, dass es möglich ist, sondern darauf wie es möglich ist.

    MfG Genesis

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. dSPACE GmbH, Paderborn
  2. Beuth Verlag GmbH, Berlin
  3. Radeberger Gruppe KG, Frankfurt am Main
  4. operational services GmbH & Co. KG, verschiedene Standorte

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 266€ inkl. 20-Euro-Steam-Gutschein
  2. (u. a. Die Bud Spencer Jumbo Box XXL (Blu-ray) für 44,97€, Das Boot - Staffel 2 (Blu-ray) für...
  3. (u. a. 4S LED TV 55 Zoll für 545,38€, Redmi Note 9 Pro 128GB für 199,16€, Mi Basic 2 In-ear...
  4. 154,54€ inkl. 20-Euro-Steam-Gutschein


Haben wir etwas übersehen?

E-Mail an news@golem.de


BVG: Lieber ungeschützt im Nahverkehr
BVG
Lieber ungeschützt im Nahverkehr

In einem Streit mit dem BSI definiert sich die BVG als klein, um unsicher bleiben zu dürfen. Das ist kleinkariert und absurd.
Ein IMHO von Moritz Tremmel

  1. Mobilitätswende Berlin schickt 100. Elektrobus auf die Straße
  2. Solaris Urbino 18 electric Berliner Verkehrsbetriebe mit elektrischen Gelenkbussen
  3. Dekarbonisierung Alle Berliner Busse werden elektrisch

Data-Mining: Wertvolle Informationen aus Datenhaufen ziehen
Data-Mining
Wertvolle Informationen aus Datenhaufen ziehen

Betreiber von Onlineshops wollen wissen, was sich verkauft und was nicht. Mit Data-Mining lassen sich aus den gesammelten Daten über Kunden solche und andere nützliche Informationen ziehen. Es birgt aber auch Risiken.
Von Boris Mayer


    Elektromobilität: Diese E-Autos kommen 2021 auf den Markt
    Elektromobilität
    Diese E-Autos kommen 2021 auf den Markt

    2020 war ein erfolgreiches Jahr für die Elektromobilität. Dieser Trend wird sich fortsetzen: ein Überblick über die Neuerscheinungen 2021.
    Ein Bericht von Dirk Kunde

    1. Elektromobilität 2020/21 Nur Tesla legte in der Krise zu
    2. Prototyp vorgestellt VW-Laderoboter im R2D2-Style kommt zum Auto
    3. E-Auto VDA-Chefin fordert schnelleren Ausbau von Ladesäulen