4. Typumwandlung: int -> char[4]

Typumwandlung: int -> char[4]

  • ?

    Vertexwahn schrieb:

    Ein int besteht aus sizeof(int) * 8 Bits

    Ein char besteht aus sizeof(char) * 8 Bits

    Nörgler würden sagen, dass ein char nicht zwingend aus 8 Bits besteht. Das betrifft aber nur absolute Exoten.

    Vertexwahn schrieb:

    Zunächst stellt sich die doch erst die Frage ob ein int vier chars passt (C99 definiert doch nicht das ein int in vier chars passt - oder?):

    Richtig, der Standard sagt nichts darüber aus, wie groß ein int ist, lediglich dass es >= short ist.

    Vertexwahn schrieb:

    Falls siezof(int) / sizeof(char) == 4 (true) gleich eins ist, dann ja

    Das sizeof(char) kannst du dir sparen, denn es ist immer 1. Das ist vom Standard definiert.

    Vertexwahn schrieb:

    ...

    Unabhängig davon ob es funktioniert oder nicht. Aber wäre es mit memcpy() nicht schneller erledigt?

    0
  • V

    > The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type.

    > When applied to an operand that has type char, unsigned char, or signed char,
    (or a qualified version thereof) the result is 1.

    soll das jetzt heißen ein char ist immer ein Byte groß?

    mmh dann könnte sizeof(char) einen anderen wert haben wie:
    char array[10];
    sizeof(array[0]);

    oder?

    0
  • G

    TactX schrieb:

    Vertexwahn schrieb:

    Ein int besteht aus sizeof(int) * 8 Bits

    Ein char besteht aus sizeof(char) * 8 Bits

    Nörgler würden sagen, dass ein char nicht zwingend aus 8 Bits besteht. Das betrifft aber nur absolute Exoten.

    Naja, der Standard würde es eher so schreiben:
    Ein int besteht aus 'sizeof(int) * CHAR_BIT' Bits.
    Ein char besteht aus 'sizeof(char) * CHAR_BIT' bzw. 'CHAR_BIT' Bits.
    🙂

    Vertexwahn schrieb:

    müsste man mal testen ob Shiften um 4 Bits schneller oder langsammer ist als die Multiplikation mit 16

    Sehr unwahrscheinlich, dass Shiften langsamer ist, vielleicht auf irgendwelchen Exoten.

    Vertexwahn schrieb:

    Angenommen ein int ist 32 Bit groß und ein char 8 Bit – dann werden die Bits 32 bis 9 vom Integer verworfen und nur die Bits von 8 bis 0 in den char übertragen

    Nicht ganz. Da int hier nur 32 Bits hat, wird ein gängiger Prozessor Bit 0 bis 7 ins char kopieren und Bit 8 bis 31 verwerfen. Abhängig davon, ob char signed oder unsigned ist, werden noch entsprechende Anpassungen vorgenommen.

    @Vertexwahn
    Könntest du dir mal bitte angewöhnen, ordentlich zu quoten?

    0
  • V

    C99:

    Values stored in non-bit-field objects of any other object type consist of n * CHAR_BIT bits, where n is the size of an object of that type, in bytes.

    Ich dachte eine Byte hat immer 8 Bit

    Könntest du dir mal bitte angewöhnen, ordentlich zu quoten?

    ich versuchs 😉 - wie ersetze ich "Zitat" durch einen Namen?

    0
  • ?

    groovemaster schrieb:

    Vertexwahn schrieb:

    müsste man mal testen ob Shiften um 4 Bits schneller oder langsammer ist als die Multiplikation mit 16

    Sehr unwahrscheinlich, dass Shiften langsamer ist, vielleicht auf irgendwelchen Exoten.

    Der P4 ist ein Exot? 😮

    Der P4 hat keinen Barrel Shifter. Viele Leute sagen, dass er auch deswegen so lahm ist...

    0
  • G

    Vertexwahn schrieb:

    ich versuchs 😉 - wie ersetze ich "Zitat" durch einen Namen?

    Indem du in das Editfeld hinter dem Quote Button einen Namen reinschreibst.

    TactX schrieb:

    Der P4 hat keinen Barrel Shifter. Viele Leute sagen, dass er auch deswegen so lahm ist...

    Whoa, das hört sich ja ziemlich übel an. Naja, dazu kann ich leider nix sagen, weil ich meinen letzten Pentium '00 zu Grabe getragen hab. Aber normalerweise sollte sich Shiften auf Hardwareebene schon schneller realisieren lassen wie Multiplikationen, oder zumindest nicht langsamer.

    0
  • ?

    groovemaster schrieb:

    TactX schrieb:

    Der P4 hat keinen Barrel Shifter. Viele Leute sagen, dass er auch deswegen so lahm ist...

    Whoa, das hört sich ja ziemlich übel an. Naja, dazu kann ich leider nix sagen, weil ich meinen letzten Pentium '00 zu Grabe getragen hab. Aber normalerweise sollte sich Shiften auf Hardwareebene schon schneller realisieren lassen wie Multiplikationen, oder zumindest nicht langsamer.

    Google mal nach "p4 barrel shifter". Kommen einige Links dazu. Auf die Gefahr, dass das jetzt zu sehr OT wird, aber intel sollte die P4-Kacke endlich einstampfen...

    0
  • V

    groovemaster schrieb: schrieb:

    Whoa, das hört sich ja ziemlich übel an. Naja, dazu kann ich leider nix sagen, weil ich meinen letzten Pentium '00 zu Grabe getragen hab. Aber normalerweise sollte sich Shiften auf Hardwareebene schon schneller realisieren lassen wie Multiplikationen, oder zumindest nicht langsamer.

    Früher war es in Programmiererkreisen üblich, Ganzzahlmultiplikationen mit 2 bzw. Ganzzahldivisionen durch 2 mit Hilfe der entsprechenden Shift-Operationen durchzuführen, da dies einen kleinen Performancegewinn im Vergleich zur "echten" mathematischen Operation darstellte. Heutzutage ist dieser Performancegewinn nicht mehr vorhanden, da alle
    derzeitigen Architekturen auf solche Operationen optimiert sind. Aus Gründen der Leserlichkeit sollte man also heutzutage nicht mehr auf diese Art der trickreichen Programmierung zurückgreifen. Darüber hinaus optimiert der Compiler in den meisten Fällen solche Dinge automatisch.

    0
  • G

    Vertexwahn schrieb:

    Darüber hinaus optimiert der Compiler in den meisten Fällen solche Dinge automatisch.

    Das ist schon klar. Ist auch der Hauptgrund, warum man auf solche Shift Tricks heutzutage verzichten kann.
    Nur sind die CPU's heutzutage wirklich so effizient? Hab leider nur einen "alten" Athlon Barton, und weiss, dass dort Multiplikationen sehr schnell sind. Aber schneller oder zumindest genauso schnell wie Shifts? Hört sich zumindest ungewohnt an. Aber das ist jetzt zu sehr OT. 🙂

    0
  • ?

    Vielleicht hilft dir folgende Funktion welche ich mal geschrieben habe:
    (ich verstehe jetzt nicht ganz den Unterschied zwischen char[4] und String, hab jetzt auch nicht das komplette Topic gelesen, aber vielleicht nutzt dir der Code ja trotzdem was)

    unsigned char *int_to_ascii(int punkte)
{
	static unsigned char temp[4]={'\0','\0','\0', '\0'};
  //punkte darf maximal 3stellen haben

  if(((punkte-punkte%100)/100)!=0 )
	 temp[0]=((punkte-punkte%100)/100)+'0';	
	else
	 temp[0]=' ';

	if((((punkte%100-punkte%10)/10)!=0) || (temp[0]!=' ') )
   temp[1]=((punkte%100-punkte%10)/10)+'0';
  else
   temp[1]=' ';

  if((punkte%10)!=0 || (temp[1]!=' ') )
	 temp[2]=(punkte%10)+'0';
	else
	 temp[2]=' ';  

	temp[3]='\0';

	return temp;
}

    Grüße,
    Harri

    0
  • G

    😮 DailyWTF? 😃

    harry3 schrieb:

    hab jetzt auch nicht das komplette Topic gelesen

    Wäre aber vielleicht besser gewesen.

    0
  • V

    @harry3:

    Deine Funktion wandelt die letzten vier stellen einer int Zahl in einen "String" um - das war nicht gesucht und bringt den fragenden nicht weiter

    harry3 schrieb:

    temp[0]=((punkte-punkte%100)/100)+'0';

    das funktioniert zwar auf den meisten Rechnern ist, aber nicht besonders schön - ich will dir ja nicht viel zu programmierstill sagen - aber für größere Projekte (z. B. kleine Computerspiele) solltest du erst ein wenig etwas über allgemeine Prinzipien von Softwareentwicklung lernen - macht sich später vielleicht einmal bezahlt

    0
  • N

    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'....

    0
  • ?

    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

    0
  • V

    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 code

    harry3 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

    0
  • ?

    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

    0
  • N

    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?

    0
  • ?

    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

    0
  • G

    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?

    0
  • ?

    @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

    0
Anmelden zum Antworten