Hat schon mal jemand mit euch mit C++ für Symbian OS gecodet?
-
hatte es eher so verstanden das die STL aus Performance Gründen rausgelassen wurde. Suche gerade etwas rum und es sieht so aus als müsste man wirklich mal wieder mit malloc() etc arbeiten..
-
new hat nun aber nichts mit der STL zu tun. Naja, zu not kannst du ja versuchen STLPort mit dem Compiler zu kompilieren bzw. die Teile, die du brauchst
-
stimmt hatte nur gerade gelesen das man die "tolle" STDLIB verwenden darf, darum kam es mir in den Sinn.
Was ist den STLPort? Gibt es STLPort für jede Plattform? (Symbian)
-
musst nur schauen, ob du das mit dem Compiler zum laufen bekommst und ob es nicht zu groß ist (wird ja einen Grund haben, warum die keine komplette stdlib mitliefern).
-
warum zu groß? Compiliert wird auf dem Rechner da ist genug Platz
Auf der Symbian Plattform brauche ich ja nicht die gesammte STL sondern nur die Klassen die ich eben verwende..
-
Höchstwahrscheinlich kann der Compiler doch wohl keine Templates, oder?
Das ist meistens der Hauptgrund, warum keine STL enthalten ist... beliebt bei allen Embedded-C++-Compilern.
-
dann hast du wirklich ein Problem. Naja, vielleicht lässt sich dann ja ein STL ähnliches System mittels eines basis object Typ wie in Java erzeugen, ist natürlich nicht so schön. Aber anders gehts nicht.
(ot)
warum machen die Embedded Platform bauer das? Templates brauchen ja keine Runtime Unterstützung. Ist der Entwicklungsaufwand zu hoch?Naja, man könnte einfach ein GCC Backend schreiben und hat schon Template Support und ein Backend muss man AFAIK nicht mal unter die GPL stellen, falls die Firmen Angst davor haben "Geheimnisse" zu verraten.
$
-
kingruedi schrieb:
(ot)
warum machen die Embedded Platform bauer das? Templates brauchen ja keine Runtime Unterstützung. Ist der Entwicklungsaufwand zu hoch?Gute Frage.
Das Komitee für EC++ hat sich darauf verständigt, die Begründung war sowas in der Art von "braucht man nicht", aber vermutlich waren die bloß zu faul das zu implementieren.
Letztlich kann man ja zumindest primitive Templates über einen simplen Präprozessor realisieren, das wäre ja ein Hilfsweg.
Die haben noch was weggelassen... weiß jetzt nicht mehr was... war auch so ein Unding. Fällt mir gerade nicht mehr ein. Ach hier http://www.caravan.net/ec2plus/question.html
Steht völliger Blödsinn drin meiner Meinung nach. Ich sehe nur die Exceptions ein - das ist bei Mikrocontrollern vielleicht wirklich knifflig und man kann auch ohne leben. Aber die Begründung für Templates ist völliger Schwachsinn - ob ich eine Liste zweimal ausprogrammiere oder sie im Code einmal mit Templates habe und zweimal instanziiere bleibt sich gleich. Und wer Speicher sparen will, kann ja einen Java-Weg gehen und einen COntainer für eine abstrakte Oberklasse realisieren, der steht dann nur einmal im Speicher - ABER diesen Container will ich natürlich mit der zuverlässigen STL-Templates-Klasse erhalten.
Schau Dir mal die Stdlib von EC++ an (hier Beispiel string):
https://www.dinkumware.com/manuals/reader.aspx?b=a/&h=string2.html
Die Lösung ist klar... für string sehe ich es ja noch ein, daß man das direkt spezialisiert für char.
-
The subset should offer upward compatibility with ISO/ANSI Standard C++ and retain the major advantages of C++
*lol* die haben C++ ja alles was sinn macht weggenommen.
btw:
"Though 'xxx' has no runtime overhead, it is too new to be used widely."
halte ich fuer eine sehr doofe begruendung.
-
hab mir gerade mal den iX Artikel angeguckt. Das SDK benutzt den GCC zum kompilieren (als Crosscompiler für ARM). Also sollte man auch STLport zum laufen bringen können. Man muss die Library eben nur statisch linken!