Könnt ihr mir gute Seiten empfehlen, wo ich mich über Details von Android informieren kann? Insbesondere das Angebot an derzeit verfügbaren Apps (und deren Preise) interessieren mich. Danke.
> Bieten sie keinen Debugger an? Oder erschwert er es nur absichtlich?
Naja, das Debuggen in C/C++ ist ja immer erschwert im Vergleich zu Java; bei letzterem kriegt man bei ungefangenen Exceptions einen Stacktrace mit Zeilennummern, bei C++ erst mal überhaupt nicht mal einen Stacktrace...
> Was hat bitte eine Programmiersprache mit > der Komplexität der Anwendung zu tun?
Sehr viel sogar. Grundsätzlich gilt: je höher das Abstraktionslevel, desto einfacher wird es komplexe Programme zu entwickeln.
Im Kontext des Satzes ist wohl gemeint dass man sich bei den C-APIs mit mehr low-level Problemen herumschlagen muss.
> Ist genau gleich, für jede Plattform muss man es neu kompilieren. > In Java wäre das Dalvik und das normale von Sun.
Haarspalterei! In der Praxis zählt was es man Anwender bringt. Eine Java Application lädst du dir einfach im Appstore runter (und dort gibt es genau eine Version davon), und sie läuft garantiert auf deinem Android-Handy. Wenn Applikation A für Handy X, Y, und Z zum Download zur Verfügung steht, dann bringt es dir wenig, dass es theoretisch, unter den richtigen Bedingungen, möglich gewesen wäre auch eine Version für dein Handy H zu kompilieren.
> aber nativen ARM Code nicht sinnvoll aus Java heraus emulieren kann.
Warum sollte man das wollen?
> Bieten sie keinen Debugger an? Oder > erschwert er es nur absichtlich?
Siehe Komplexität. Je komplexer ein Programm aus Sicht des Entwicklers ist, desto schwerer ist es auch zu debuggen.
> Was hat bitte eine Programmiersprache mit > der Komplexität der Anwendung zu tun? Sehr viel sogar. Grundsätzlich gilt: je höher das Abstraktionslevel, desto einfacher wird es komplexe Programme zu entwickeln.
Nur erreicht man einen hohen Abstraktionslevel bei fast allen modernen Programmiersprachen durch Bibliotheken.
Das stimmt zu einem gewissen Grad natürlich. Doch auch die Sprache selbst spielt dabei eine Rolle. Bei C++ fehlt z.B. ein Garbage Collector, auch die explizite Behandlung von Pointer macht einem das Leben im Vergleich zu Java (oder anderen moderneren Sprachen) deutlich schwerer.
Bei C kommen noch mehr fehlende Features dazu: kein objektorientiertes Programmieren, kein Exception Handling. Für ersteres gibt es zwar gobject, doch diesem Fehlen auch wichtige Features, wie überladen von Methoden und es bietet keine Namespaces.
Auch die Lesbarkeit des produzierten Codes spielt eine Rolle. Auch hier sind meiner Meinung modernere Sprachen deutlich im Vorteil.
> Bei C++ fehlt z.B. ein Garbage Collector Nein, natürlich fehlt kein Garbage Collector. Der "Garbage Collector" ist bei C++ der Scope.
> auch die explizite Behandlung von Pointer macht einem das Leben im Vergleich zu Java [...] deutlich schwerer Du musst sie ja nicht nutzen.
> Auch die Lesbarkeit des produzierten Codes spielt eine Rolle. Auch hier sind meiner Meinung modernere > Sprachen deutlich im Vorteil. Im Alltag nutzen nur die wenigsten Entwickler sauber die entsprechenden Strukturierungs- und Dokumentationselemente, sodass sich der Code kaum signifikant unterscheidet. Und wer sich daran stört, dass er Ressourcen explizit allokieren und freigeben muss, der kann ja gern andere Sprachen einsetzen.
> Bei C++ fehlt z.B. ein Garbage Collector, ... In C++ lässt sich ein GC integrieren und der zukünftige C++ Standard wird das sogar noch einfacher machen. Im Gegensatz zu Java hast du die Wahl wie du deinen Speicher verwaltest. Entweder manuell (new/delete), über Referenzzähler (smart_ptr), oder mit einem GC. You only get what you pay for, don't you? ...
> Bei C++ fehlt z.B. ein Garbage Collector, auch die explizite Behandlung von Pointer > macht einem das Leben im Vergleich zu Java (oder anderen moderneren Sprachen) deutlich > schwerer.
Es gibt wie unten schon erwaehnt den Scope, was das ungemein nuetzliche RAII-Pattern erst moeglich macht. Ausserdem gibt es boost::shared_ptr und Konsorten.
Ein GC macht dem Anfänger das Leben leichter, dem Profi allerdings das Leben schwerer. Man kann ja nicht voraussehen wann der GC läuft und Resourcen freigegeben werden. Überhaupt verwaltet der GC ja nur die Resource Memory, während Destruktoren auch file handles freigeben können oder Locks freigeben können. Viele Probleme können nicht von Sprachen gelöst werden, die Speicher nur über einen GC verwalten. GC und Exception safety ist sehr schwer hinzubekommen (Soviel zum Thema lesbarer Code in Java...).
Zudem funktioniert ein GC nur dann gut wenn das Programm viel mehr Speicher unter Beschlag nimmt als es eigentlich braucht. Interessant ist auch das C++ die bessere Sprache für einen GC wäre, weil es so weing Garbage erzeugt. Ein GC für C++ ist von Hans Böhm erhältlich, wird aber oft (zu recht) als problematisch im Bezug auf Performance angesehen. Man denke auch mal an GC und Multi-threading. Es gibt übrigens noch andere Möglichkeiten Speicher automatisch zu verwalten, auto_ptr, shared_ptr usw...
Zeiger muss man erstens nicht nutzen und sollte man auch nur selten nutzen. Aber einige Dinge lassen sich nur mit Zeigern effiient lösen.
Zudem würde ich Java nicht als modern ansehen. Es gibt dort kein Feature welches nicht schon in den 80er Jahren oder früher bekannt gewesen wäre. Die Idee von GC ist schon sehr alt. Generics sind nur ein armseeliger Schatten der C++ Templates und die objekt-orientierung ist auch eher "light".
Von Anonymer Feigling am Sa, 27. Juni 2009 um 23:00 #
Also das mit Profis finde ich nun irgendwie sehr komisch. Profis verwalten ihren Speicher selbst, weil sie nicht mit dem GC zurecht kommen? Also bitte. Und außerdem kann man mit einem GC auch wunderbar Filehandles freigeben, siehe in Python. Natürlich ist es schlauer Dateien explizit zu schließen, aber der GC kann das durchaus.
"Also das mit Profis finde ich nun irgendwie sehr komisch. Profis verwalten ihren Speicher selbst, weil sie nicht mit dem GC zurecht kommen?"
Das ist präzise der Punkt! Wenn du z.B. ein sehr deterministisches Verhalten des Programmes benötigst, dann soll Speicher genau dann freigegeben werden wenn der Programmierer es wünscht und irgendwann der GC das System blockieren.
"mit einem GC auch wunderbar Filehandles freigeben"
Ich könnte dir noch viele Fälle nennen, rollbacks bei Datenbanken, Mutex locks, irgendwelche anderen handles aus C libraries... Mit Konstruktoren/Destruktoren kann man das alles einfach, deterministisch und exeption-safe erreichen. Mit einem GC nicht. Selbst wenn der GC file-handles schliesst wird es erst irgendwann mal in der Zukunft passieren wenn der GC läuft und nicht sofort. Das ist ein enormer Nachteil der Anfängern oft nicht bewusst ist.
> Das ist präzise der Punkt! Wenn du z.B. ein sehr deterministisches Verhalten des > Programmes benötigst, dann soll Speicher genau dann freigegeben werden wenn der > Programmierer es wünscht und irgendwann der GC das System blockieren.
Du scheinst "professionell" mit "Low-Level" zu verwechseln. Professionell bedeutet nicht nur das man effiziente Programme entwickelt, sondern auch dass die Entwicklung effizient ist. Das bedeutet auch für die passenden Tools für die vorgegebenen Aufgaben zu verwenden. Wenn die von dir angegebenen Low-Leven-Probleme wirklich relevant sind, dann soll man natürlich auch die passenden Low-Level Tools verwenden. Damit macht es durchaus Sinn einen Treiber, eine Grafik-Bibliothek, oder ein Datenbank-System in einer Low-Level-Sprache zu entwickeln.
In der Benutzer-Anwendungsentwicklung sind diese Probleme aber in der Regel nicht relevant. Hier es notwendig die Business-Logik effizient umzusetzen. Man schlägt sind nicht damit herum wie genau der Rollback in einer DB implementiert ist, oder wie man ein Bild am effizientesten rotieren kann. Dazu greift man einfach auf die passenden APIs effizienter Implementierungen zurück. Sich um solche Probleme selbst zu kümmern wäre alles andere als professionell, es würde dem Endprodukt wenig bis nichts bringen, jedoch deutlich höhere Kosten verursachen.
> Selbst wenn der GC file-handles schliesst wird es erst irgendwann > mal in der Zukunft passieren wenn der GC läuft und nicht sofort.
Sollte das wirklich mal relevant sein, kann man einen GC durchaus auch Manuell kontrollieren. Aber das ist einem pseudo-Profi oft nicht bewusst.
Der Programmierer muss dafür sorgen das der DB rollback passiert, auch im Falle einer exception. Konzeptinell ältere Sprachen wie Java bieten hier nur die try-catch-Spaghetti-code-Methode an.
Dein GC löst ein Problem erzeugt aber 10 neue Probleme.
Wirklich robuster code ist in C++ deutlich kürzer als in Java und Programme viel effizenter.
AOP erzeugt wieder 10 neue Probleme und löst das Problem lange nicht so elegant wie die automatische Resourcenverwaltung durch C++ Destruktoren.
Folgendes z.B. ist fürchterlich: https://entwickler.com/zonen/portale/psecom,id,101,online,634,.html
AOP ist schon seit über 15 Jahen bekannt und lebt bis heute nur in Nischen. Die üblichen Beispiele für AOP und exceptions sind total lächerlich und unwartbar. Es mag andere Anwendungsfälle für AOP geben ( oder auch nicht ).
> Bei C++ fehlt z.B. ein Garbage Collector, auch die explizite Behandlung von Pointer macht einem das Leben im Vergleich zu Java (oder anderen moderneren Sprachen) deutlich schwerer.
Nein, es gibt in C++ die Möglichkeit Garbage Collector einzubauen. Außerdem kann man sich mit RAII, Smart References usw. automatisch alles aufräumen lassen (nicht nur Speicher, sondern auch Dateien, Mutex, ...).
Hingegen es ist schwierig in Java ein deterministisches aufräumen von Speicherlecks hinzubekommen. Das Problem gibt es bei C++ nicht.
> Bei C kommen noch mehr fehlende Features dazu: kein objektorientiertes Programmieren, kein Exception Handling. Für ersteres gibt es zwar gobject, doch diesem Fehlen auch wichtige Features, wie überladen von Methoden und es bietet keine Namespaces.
objektorientiertes Programmieren im weiteren Sinne ist schon möglich, aber du hast grundsätzlich recht.
> Auch die Lesbarkeit des produzierten Codes spielt eine Rolle. Auch hier sind meiner Meinung modernere Sprachen deutlich im Vorteil.
Eigentlich sind genau die mit C-ähnlicher Syntax sehr erfolgreich, z.b. C++, Java, C#. Andere wie Eiffel geraten ins hintertreffen.
>Nur erreicht man einen hohen Abstraktionslevel bei fast allen modernen Programmiersprachen durch Bibliotheken.
Weniger, denn Sprachkonstrukte und Abstrakte Datentypen gibt die Sprache bzw. der Compiler vor. Beispiele: Generics oder der Template Mechanismus, Threads & Synchron.,Maps etc. . Nebenbei würde ich C++ nicht als moderne Sprache bezeichnen.
Ich glaube auf heise oder golem hatte ich gelesen, das dieses SDK(NDK) sich für rechenintensivere, hardwarenahe Anwendungen eignet.
Das was die Unwissenden "Defekte" nennen, ist es jedoch auch was C++ so effizient und schnell macht. C++ hat nicht das Ziel W*chsvorlage für Hobbyisten zu sein, sondern ein mächtiges Tool für den profssionellen Programmierer.
Von Die ernüchternde Wahrheit am Sa, 27. Juni 2009 um 19:10 #
Grundsätzlich: Professionell heißt, so schnell und gut wie möglich da Einkommensbezogen, nicht möglichst viel Frickelarbeit. Das einzige, was man mit C++ und C professionell machen kann, sind low-level Sachen, da es in dem Bereich keine Alternative gibt.
Von Bullshit Detektor am Sa, 27. Juni 2009 um 19:25 #
Du hast eine sehr seltsame Vorstellung von Professionalität. Ich dachte immer es geht darum robuste und effiziente Programme zu schreiben. Java und .Net aufbocken um mal schnell was hinzurotzen ist keine nachhaltige Entwicklung.
Von Anonymer Feigling am Sa, 27. Juni 2009 um 23:01 #
Professionell heißt nicht unbedingt effizient. Effizient dort wo es ankommt, aber ob jetzt die Berechnung von irgendeinem Wert 1 Sekunde länger dauert oder nicht, das interessiert keinen.
Komisch, dass ich mit "high-level" C++ mein Geld verdiene, in einem Unternehmen, wo das mehr als 30 Leute sehr erfolgreich tun. Und zwar mit GUIs und deren Unterbau und nicht mit Treiberentwicklung.
Why, wenn dadurch der Wettlauf gegen einen Konkurrenten gewonnen wird, interessiert die Firmenleiter und die Kunden das in der Regel nicht wirklich, um es mal aus der Sicht eines Managers zu beschreiben.
Nun ja. Wir stellen gerade mal wieder ein, es läuft ganz gut. Tun viele Unternehmen in unserem (C++-affinen) Umfeld. Viele Ex-Kommilitonen die bei Java-Shops angefangen haben, sind jetzt in Kurzarbeit und/oder bangen um ihren Job.
Wenn man C++ als defekt bezeichnet, sollte man auch eine gleichwertige Alternative nennen. Kennst du diese? Ich werde es einfach machnen und dir die Frage schon vorher beantworten: Nein!
http://www.android.com/
http://phandroid.com/ <- Mein Favorit
www.androidmobil.de
www.android-hilfe.de
Also direkt starten geht nicht?
> größerer Komplexität der Anwendungen
Was hat bitte eine Programmiersprache mit der Komplexität der Anwendung zu tun?
> reduzierter Kompatibilität
Ist genau gleich, für jede Plattform muss man es neu kompilieren.
In Java wäre das Dalvik und das normale von Sun.
Gibt es schon nicht-ARM Geräte?
> fehlendem Zugriff auf die Framework-APIs
Das haben ja wohl die selbst verbockt wenn man nicht auf alles zugreifen kann.
Tatsache ist halt dass man eine Java VM in C/C++ schreiben kann, aber nativen ARM Code nicht sinnvoll aus Java heraus emulieren kann.
> erschwertem Debugging
Bieten sie keinen Debugger an? Oder erschwert er es nur absichtlich?
Naja, das Debuggen in C/C++ ist ja immer erschwert im Vergleich zu Java; bei letzterem kriegt man bei ungefangenen Exceptions einen Stacktrace mit Zeilennummern, bei C++ erst mal überhaupt nicht mal einen Stacktrace...
Mit Debugger dann schon :-)
Aber du hast natürlich recht, C++ hat keinen Debugger integriert.
lg
Erik
lg
Erik
> der Komplexität der Anwendung zu tun?
Sehr viel sogar. Grundsätzlich gilt: je höher das Abstraktionslevel, desto einfacher wird es komplexe Programme zu entwickeln.
Im Kontext des Satzes ist wohl gemeint dass man sich bei den C-APIs mit mehr low-level Problemen herumschlagen muss.
> Ist genau gleich, für jede Plattform muss man es neu kompilieren.
> In Java wäre das Dalvik und das normale von Sun.
Haarspalterei! In der Praxis zählt was es man Anwender bringt. Eine Java Application lädst du dir einfach im Appstore runter (und dort gibt es genau eine Version davon), und sie läuft garantiert auf deinem Android-Handy. Wenn Applikation A für Handy X, Y, und Z zum Download zur Verfügung steht, dann bringt es dir wenig, dass es theoretisch, unter den richtigen Bedingungen, möglich gewesen wäre auch eine Version für dein Handy H zu kompilieren.
> aber nativen ARM Code nicht sinnvoll aus Java heraus emulieren kann.
Warum sollte man das wollen?
> Bieten sie keinen Debugger an? Oder
> erschwert er es nur absichtlich?
Siehe Komplexität. Je komplexer ein Programm aus Sicht des Entwicklers ist, desto schwerer ist es auch zu debuggen.
> der Komplexität der Anwendung zu tun?
Sehr viel sogar. Grundsätzlich gilt: je höher das Abstraktionslevel, desto einfacher wird es komplexe Programme zu entwickeln.
Nur erreicht man einen hohen Abstraktionslevel bei fast allen modernen Programmiersprachen durch Bibliotheken.
Bei C++ fehlt z.B. ein Garbage Collector, auch die explizite Behandlung von Pointer macht einem das Leben im Vergleich zu Java (oder anderen moderneren Sprachen) deutlich schwerer.
Bei C kommen noch mehr fehlende Features dazu: kein objektorientiertes Programmieren, kein Exception Handling. Für ersteres gibt es zwar gobject, doch diesem Fehlen auch wichtige Features, wie überladen von Methoden und es bietet keine Namespaces.
Auch die Lesbarkeit des produzierten Codes spielt eine Rolle. Auch hier sind meiner Meinung modernere Sprachen deutlich im Vorteil.
Nein, natürlich fehlt kein Garbage Collector. Der "Garbage Collector" ist bei C++ der Scope.
> auch die explizite Behandlung von Pointer macht einem das Leben im Vergleich zu Java [...] deutlich schwerer
Du musst sie ja nicht nutzen.
> Auch die Lesbarkeit des produzierten Codes spielt eine Rolle. Auch hier sind meiner Meinung modernere
> Sprachen deutlich im Vorteil.
Im Alltag nutzen nur die wenigsten Entwickler sauber die entsprechenden Strukturierungs- und Dokumentationselemente, sodass sich der Code kaum signifikant unterscheidet. Und wer sich daran stört, dass er Ressourcen explizit allokieren und freigeben muss, der kann ja gern andere Sprachen einsetzen.
lg
Erik
In C++ lässt sich ein GC integrieren und der zukünftige C++ Standard wird das sogar noch einfacher machen.
Im Gegensatz zu Java hast du die Wahl wie du deinen Speicher verwaltest. Entweder manuell (new/delete), über Referenzzähler (smart_ptr), oder mit einem GC.
You only get what you pay for, don't you? ...
> macht einem das Leben im Vergleich zu Java (oder anderen moderneren Sprachen) deutlich > schwerer.
Es gibt wie unten schon erwaehnt den Scope, was das ungemein nuetzliche RAII-Pattern erst moeglich macht. Ausserdem gibt es boost::shared_ptr und Konsorten.
Zudem funktioniert ein GC nur dann gut wenn das Programm viel mehr Speicher unter Beschlag nimmt als es eigentlich braucht. Interessant ist auch das C++ die bessere Sprache für einen GC wäre, weil es so weing Garbage erzeugt. Ein GC für C++ ist von Hans Böhm erhältlich, wird aber oft (zu recht) als problematisch im Bezug auf Performance angesehen. Man denke auch mal an GC und Multi-threading. Es gibt übrigens noch andere Möglichkeiten Speicher automatisch zu verwalten, auto_ptr, shared_ptr usw...
Zeiger muss man erstens nicht nutzen und sollte man auch nur selten nutzen. Aber einige Dinge lassen sich nur mit Zeigern effiient lösen.
Zudem würde ich Java nicht als modern ansehen. Es gibt dort kein Feature welches nicht schon in den 80er Jahren oder früher bekannt gewesen wäre. Die Idee von GC ist schon sehr alt. Generics sind nur ein armseeliger Schatten der C++ Templates und die objekt-orientierung ist auch eher "light".
Das ist präzise der Punkt! Wenn du z.B. ein sehr deterministisches Verhalten des Programmes benötigst, dann soll Speicher genau dann freigegeben werden wenn der Programmierer es wünscht und irgendwann der GC das System blockieren.
"mit einem GC auch wunderbar Filehandles freigeben"
Ich könnte dir noch viele Fälle nennen, rollbacks bei Datenbanken, Mutex locks, irgendwelche anderen handles aus C libraries... Mit Konstruktoren/Destruktoren kann man das alles einfach, deterministisch und exeption-safe erreichen. Mit einem GC nicht. Selbst wenn der GC file-handles schliesst wird es erst irgendwann mal in der Zukunft passieren wenn der GC läuft und nicht sofort. Das ist ein enormer Nachteil der Anfängern oft nicht bewusst ist.
> Programmes benötigst, dann soll Speicher genau dann freigegeben werden wenn der
> Programmierer es wünscht und irgendwann der GC das System blockieren.
Du scheinst "professionell" mit "Low-Level" zu verwechseln. Professionell bedeutet nicht nur das man effiziente Programme entwickelt, sondern auch dass die Entwicklung effizient ist. Das bedeutet auch für die passenden Tools für die vorgegebenen Aufgaben zu verwenden.
Wenn die von dir angegebenen Low-Leven-Probleme wirklich relevant sind, dann soll man natürlich auch die passenden Low-Level Tools verwenden. Damit macht es durchaus Sinn einen Treiber, eine Grafik-Bibliothek, oder ein Datenbank-System in einer Low-Level-Sprache zu entwickeln.
In der Benutzer-Anwendungsentwicklung sind diese Probleme aber in der Regel nicht relevant. Hier es notwendig die Business-Logik effizient umzusetzen. Man schlägt sind nicht damit herum wie genau der Rollback in einer DB implementiert ist, oder wie man ein Bild am effizientesten rotieren kann. Dazu greift man einfach auf die passenden APIs effizienter Implementierungen zurück. Sich um solche Probleme selbst zu kümmern wäre alles andere als professionell, es würde dem Endprodukt wenig bis nichts bringen, jedoch deutlich höhere Kosten verursachen.
> Selbst wenn der GC file-handles schliesst wird es erst irgendwann
> mal in der Zukunft passieren wenn der GC läuft und nicht sofort.
Sollte das wirklich mal relevant sein, kann man einen GC durchaus auch Manuell kontrollieren. Aber das ist einem pseudo-Profi oft nicht bewusst.
Der Programmierer muss dafür sorgen das der DB rollback passiert, auch im Falle einer exception. Konzeptinell ältere Sprachen wie Java bieten hier nur die try-catch-Spaghetti-code-Methode an.
Dein GC löst ein Problem erzeugt aber 10 neue Probleme.
Wirklich robuster code ist in C++ deutlich kürzer als in Java und Programme viel effizenter.
Nein, da bietet sich AOP an.
Folgendes z.B. ist fürchterlich:
https://entwickler.com/zonen/portale/psecom,id,101,online,634,.html
AOP ist schon seit über 15 Jahen bekannt und lebt bis heute nur in Nischen. Die üblichen Beispiele für AOP und exceptions sind total lächerlich und unwartbar. Es mag andere Anwendungsfälle für AOP geben ( oder auch nicht ).
Nein, es gibt in C++ die Möglichkeit Garbage Collector einzubauen. Außerdem kann man sich mit RAII, Smart References usw. automatisch alles aufräumen lassen (nicht nur Speicher, sondern auch Dateien, Mutex, ...).
Hingegen es ist schwierig in Java ein deterministisches aufräumen von Speicherlecks hinzubekommen. Das Problem gibt es bei C++ nicht.
> Bei C kommen noch mehr fehlende Features dazu: kein objektorientiertes Programmieren, kein Exception Handling. Für ersteres gibt es zwar gobject, doch diesem Fehlen auch wichtige Features, wie überladen von Methoden und es bietet keine Namespaces.
objektorientiertes Programmieren im weiteren Sinne ist schon möglich, aber du hast grundsätzlich recht.
> Auch die Lesbarkeit des produzierten Codes spielt eine Rolle. Auch hier sind meiner Meinung modernere Sprachen deutlich im Vorteil.
Eigentlich sind genau die mit C-ähnlicher Syntax sehr erfolgreich, z.b. C++, Java, C#. Andere wie Eiffel geraten ins hintertreffen.
Weniger, denn Sprachkonstrukte und Abstrakte Datentypen gibt die Sprache bzw. der Compiler vor. Beispiele: Generics oder der Template Mechanismus, Threads & Synchron.,Maps etc. . Nebenbei würde ich C++ nicht als moderne Sprache bezeichnen.
Ich glaube auf heise oder golem hatte ich gelesen, das dieses SDK(NDK) sich für rechenintensivere, hardwarenahe Anwendungen eignet.
Weswegen?
lg
Erik
Nein, weil bei der Entwicklung auf Teilkompatiblität zu C geachtet wurde, was sehr alt ist.
Siehe:
http://www.research.att.com/~bs/dne.html
Professionell heißt, so schnell und gut wie möglich da Einkommensbezogen, nicht möglichst viel Frickelarbeit.
Das einzige, was man mit C++ und C professionell machen kann, sind low-level Sachen, da es in dem Bereich keine Alternative gibt.
Kein Wunder, dass manche von der Krise so hart getroffen werden.
lg
Erik
bg
NichtErik
Kennst du diese?
Ich werde es einfach machnen und dir die Frage schon vorher beantworten: Nein!
Es gibt kaum eine Programmiersprache die so erfolgreich ist wie C++.
Ausser C vielleicht.
Der Omega13.
"[...]steht nun auch das Native Development Kit zur Verfügung[...]"
Ergo: NDK = Native Development Kit