Typumwandlung: int -> char[4]
-
Vertexwahn schrieb:
Deine Funktion wandelt die letzten vier stellen einer int Zahl in einen "String" um - das war nicht gesucht und bringt den fragenden nicht weiter
ausserdem gibts 'itoa' und 'sprintf'....
-
groovemaster schrieb:
DailyWTF?
harry3 schrieb:
hab jetzt auch nicht das komplette Topic gelesen
Wäre aber vielleicht besser gewesen.
Aus dem ersten Beitrag ist nicht gerade gut herauslesbar gewesen, was wirklich gewünscht ist.
Und man kann nicht verlangen, dass man 2 Seiten liest und erst dann postet.
Deshalb hab ich auch dazugeschrieben dass ich mir nicht sicher bin. (also KEEP COOL, nicht gleich wegen jedem Blödsinn aufregen wenns denn gut gemein ist :p )@Vertexwahn: Was würdest du vorschlagen um den Code optisch aufzupeppen?
Allerdings sollte er gleichschnell bleiben und gleich klein(im Speicher), also keine Schleifen etc.(mit zusätzlichen Variablen) einbauen!!!(ist nämlich nicht für einen PC geschrieben->wenig Speicher, wenig Power).@net: Aufm PC schon, aber nicht für das Kastl(Texas Instruments 200), für den ich programmiere.
sprintf() gäbs zwar schon, aber das braucht knapp 100byte an Speicher!!! Während meine Funktion wohl nur ein paar bytes braucht. Warm ich um jedes byte kämpfe? Siehe oben!Grüße,
Harri
-
harry3 schrieb:
@Vertexwahn: Was würdest du vorschlagen um den Code optisch aufzupeppen?
Konsequentes Einrücken
ich konnte ja nicht wissen das du auf einer Umgebung arbeitest, die nicht den vollen sprachumfang unterstützt und das du versuchst auf geschwindigkeit zu optimieren und nicht auf sauberen, wartbaren codeharry3 schrieb:
Und man kann nicht verlangen, dass man 2 Seiten liest und erst dann postet
doch - kann man - ansonsten könnte es ja passieren, dass man glatt am problem vorbeiredet
-
Sie unterstützt schon fast den gesamten Sprachumfang von Ansi C, aber das problem ist eben, das viele C-typische Befehle zwar nutzbar sind, aber eben langsam sind und vor allem viel Speicher brauchen.
Wegen den Zeileneinrückungen: In der IDE passts, aber scheinbar übernimmt das Forum die Tabs nicht 1:1 von dem IDE Text-Editor.
doch - kann man - ansonsten könnte es ja passieren, dass man glatt am problem vorbeiredet
Ja, kann man, aber ich hab gestern noch einiges zu tun gehabt, und ich dachte ich stell mal schnell den Code online, vielleicht hilfts ja, und wenn nicht, naja, kann man ja auch drüber hinwegsehen. War ja gut gemeint.
Nur keine Angst, ansonsten lese ich schon wenn möglich alles.
Grüße,
Harri
-
harry3 schrieb:
@net:
sprintf() gäbs zwar schon, aber das braucht knapp 100byte an Speicher!!!das ist aber ein sparsames printf
biste sicher das das nicht irgendwo im rom steckt?
-
Hab gerade "nachgemessen": printf("") braucht doch ganze 206bytes.(ist aber für PC Verhältnisse immer noch winzig)
Der Compiler optimiert sehr gut in Bezug auf Größe, mein Spiel "Memory" hat z.B. nur knapp 5kbytes. Das ist sehr klein, allerdings ist das auch notwendig bei einer RAM Größe von 256kb und einem Archivspeicher von 2.5mb, wovon 1.5mb nutzbar sind.Im ROM ist printf nicht vorhanden. Der TI200 hat im Rom primitivere Funktionen gespeichert, wie z.B. DrawStr(...) um Strings auszugeben oder DrawChar(...) für ein einzelnes Zeichen.
Die printf Funktion ist erst aus den verschiedenen Rom-Funktionen zusammengebastelt worden.
Wenn man nun nur eine einfache Aufgabe zu lösen hat, so ist es besser, man verwendet eine eigene Funktion als (s)printf(), weil man damit doch sehr viel Speicher spart.Wenns interessiert: http://tigcc.ticalc.org/
Grüße,
Harri
-
harry3 schrieb:
Aus dem ersten Beitrag ist nicht gerade gut herauslesbar gewesen, was wirklich gewünscht ist.
Tja, dann hättest du einfach mal 2 Beiträge weiterlesen sollen.
harry3 schrieb:
Und man kann nicht verlangen, dass man 2 Seiten liest und erst dann postet.
Doch, entweder man postet ontopic oder lässt es bleiben. Und du musst auch nicht alles im Detail durchlesen, aber zumindest überfliegen sollte schon drin sein.
harry3 schrieb:
also KEEP COOL, nicht gleich wegen jedem Blödsinn aufregen
Keine Sorge, mach ich schon nicht.
harry3 schrieb:
Allerdings sollte er gleichschnell bleiben und gleich klein(im Speicher), also keine Schleifen etc.
Klein und Schleifen stehen aber grundsätzlich in keinem Widerspruch zueinander.
harry3 schrieb:
sprintf() gäbs zwar schon, aber das braucht knapp 100byte an Speicher!!!
harry3 schrieb:
Hab gerade "nachgemessen": printf("") braucht doch ganze 206bytes.
Hehe, sehr schön. Mit Sicherheit sind das aber keine Implementationen, die die volle Funktionalität unterstützen. Und was hast du da eigentlich gemessen? Die Funktion selber? Was ist mit den ganzen Funktionen, die in ...printf() aufgerufen werden?
-
@groovemaster :
Klein und Schleifen stehen aber grundsätzlich in keinem Widerspruch zueinander.Ich habs zwar jetzt nicht ausprobiert, aber ich glaube, dass eine Schleife etwas mehr Speicher braucht. Man braucht nämlich im Gegensatz zu meiner Variante mindestens 1 Laufvariable, und dann noch eine Bedingung fürn Schleifenabbruch.
Hehe, sehr schön. Mit Sicherheit sind das aber keine Implementationen, die die volle Funktionalität unterstützen. Und was hast du da eigentlich gemessen? Die Funktion selber? Was ist mit den ganzen Funktionen, die in ...printf() aufgerufen werden?*
Die volle Funktionalität wird eh nicht unterstützt. Aus dem Manual:
"printf is nearly full implementation of standard ANSI C printf function, which sends the formatted output to the screen in terminal (TTY) mode. In fact, it does the following: ..."
Das einzige, was soweit ich weiß nicht vorhanden ist, sind Streams(stdout, stdin, stderr) und all damit verbundenen Dinge.Wegen der Größe:
Ich hab einmal ein Programm ohne Inhalt geschrieben:#include <tigcclib.h> // Main Function void _main(void)//keine Sorge, beim TI ist die _main Fkt. wirklich void!!! { //hier geschieht nix }
Und einmal mit printf:
#include <tigcclib.h> // Main Function void _main(void) { printf(""); }
Der Unterschied der Größen beträgt 206byte. Dies sollte also die Größe von printf darstellen.
Grüße,
Harri
-
harry3 schrieb:
Ich habs zwar jetzt nicht ausprobiert, aber ich glaube, dass eine Schleife etwas mehr Speicher braucht.
Glauben und wissen sind immer noch zwei Sachen. Grundsätzlich verkürzen Schleifen die Schreibarbeit und damit auch die Codegrösse. Sie wirken sich eher negativ auf die Laufzeit aus. Ohne genau zu messen, kannst du bei so kleinen Sachen nichts konkretes sagen. Und du darfst nicht vergessen, dass ein Compiler auch in der Lage ist zu optimieren. So muss für eine Laufvariable kein zusätzlicher Speicher benötigt werden. Genauso gut kann diese in einem Register gehalten werden. Und selbst mit zusätzlichem Speicher - der ist lokal und liegt damit vermutlich auf dem Stack. Und der steht nach dem Verlassen der Funktion 'eh wieder zur Verfügung.
harry3 schrieb:
Das einzige, was soweit ich weiß nicht vorhanden ist, sind Streams(stdout, stdin, stderr) und all damit verbundenen Dinge.
Das versteh ich nicht. Du hast printf aber keine Streams?
C Standard schrieb:
The printf function is equivalent to fprintf with the argument stdout interposed
before the arguments to printf.stdout muss es in irgendeiner Form dann doch geben.
harry3 schrieb:
Und einmal mit printf:
#include <tigcclib.h> // Main Function void _main(void) { printf(""); }
Der Unterschied der Größen beträgt 206byte. Dies sollte also die Größe von printf darstellen.
So kannst du die Grösse aber nicht bestimmen. Mal abgesehen davon, dass du hier noch den Code beachten musst, der beim Aufruf in main entsteht (Parameterübergabe, Stackhandling, etc.), weisst du trotzdem nicht, was zu printf gehört und was nicht.
-
Das versteh ich nicht. Du hast printf aber keine Streams?
Standardein/ausgabe Kanäle meinte ich. Ich verwechsle das Wort immer mit Streams...obwohl das AFAIK C++ ist.(bin kein c++er, also korrigiert mich wenns nicht stimmt)
stdout muss es in irgendeiner Form dann doch geben.
*Nicht so wie man es z.B. von Turbo C++ oder so gewohnt ist. Man kann also nicht die Ausgabekanäle ändern.
stdout,-in,-err ist laut Entwicklern nicht dabei.So kannst du die Grösse aber nicht bestimmen. Mal abgesehen davon, dass du hier noch den Code beachten musst, der beim Aufruf in main entsteht (Parameterübergabe, Stackhandling, etc.), weisst du trotzdem nicht, was zu printf gehört und was nicht.
Es ist mir auch egal ob die Funktion jetzt 206 oder 210 bytes hat. Was ich weiß ist dass die Funktion riesig im Vergleich zu DrawStr ist, und ich sie daher nicht verwende.
Wird sogar von den Entwicklern empfohlen auf printf zu verzichten, v.a. bei einfachen Texten!*Glauben und wissen sind immer noch zwei Sachen. Grundsätzlich verkürzen Schleifen die Schreibarbeit und damit auch die Codegrösse. Sie wirken sich eher negativ auf die Laufzeit aus. Ohne genau zu messen, kannst du bei so kleinen Sachen nichts konkretes sagen. Und du darfst nicht vergessen, dass ein Compiler auch in der Lage ist zu optimieren. So muss für eine Laufvariable kein zusätzlicher Speicher benötigt werden. Genauso gut kann diese in einem Register gehalten werden. Und selbst mit zusätzlichem Speicher - der ist lokal und liegt damit vermutlich auf dem Stack. Und der steht nach dem Verlassen der Funktion 'eh wieder zur Verfügung.
*So viel kürzer ist die Schreibarbeit nicht, dafür ist d. Programm jetzt um ca. 100bytes größer als zuerst.(unter anderem auch deswegen, weil ich pow() verwenden muss. Ich werd morgen mal probieren das ganze ohne dem pow() zu machen um einen wirkluchen Vergleichswert zu haben.
Allerdings traue ich mich zu wetten dass die Schleifenversion trotzdem größer ist.
Ich belasse es also bei meinem Code, der ist klein und außerdem auch nicht so wahnsinnig aufwendig.Grüße,
Harri
-
So, es ist wie ichs gesagt habe: Der Code (ohne pow) ist immer noch etwas größer als der Originalcode.
Es ist in diesem Fall also doch noch am sinnvollsten, wenn man das ganze Schritt für Schritt hinschreibt. Bei 3 Stellen geht das ja noch.
Grüße,
Harri
-
Poste mal bitte deine Funktion ohne pow.
-
Voila:
unsigned char *int_to_ascii(int punkte) { static unsigned char temp[4]={'\0','\0','\0', '\0'}; int faktor=1,n=0; for(n=3;n>0;n--) { if(((punkte%(faktor*10)-punkte%faktor)/faktor)!=0) temp[n-1]=(punkte%(faktor*10)-punkte%faktor)/faktor+'0'; else temp[n-1]='0'; faktor=faktor*10; } //temp[3]='\0'; return temp; }
mfg,
Harri