IntToHex function

[Martin M. (ats3788)]

Hallo
kennt jemand einen Source Code um die funktion
IntToHex zu bewerkstelligen. Ich dachte dazu kann ich einiges Googeln
aber alles was ich fand war nicht so brauchbar.
Das hatte ich gefunden nur da ist amp undefiniert.

static char hex[] = { '0', '1', '2', '3', '4', '5', '6', '7',
'8', '9' ,'A', 'B', 'C', 'D', 'E', 'F' };

//The function that performs the conversion. Accepts a buffer with 
"enough space" TM
//and populates it with a string of hexadecimal digits.Returns the 
length in digits
int uintToHexStr(unsigned int num, char* buff)
{
  int len = 0, k = 0;
  do//for every 4 bits
  {
    //get the equivalent hex digit
    buff[len] = hex[num& 0xF];
    len++;
    num >>= 4;
  } while (num != 0);
  //since we get the digits in the wrong order reverse the digits in the 
buffer
  for (; k<len / 2; k++)
  {//xor swapping
    buff[k] ^= buff[len - k - 1];
    buff[len - k - 1] ^= buff[k];
    buff[k] ^= buff[len - k - 1];
  }
  //null terminate the buffer and return the length in digits
  buff[len] = '\0';
  return len;
}

[asdf (Gast)]

Hrmf. Ersetze "&" durch "&". Dann wirds wohl gehen...

[imonbln (Gast)]

Ohne weitere Vorgaben ist der Code denn du hast doch gar nicht so 
schlecht.
Gerade die erste while schleife macht doch eigentlich schon das was du 
willst.
Die for schleife würde ich umgehen indem ich vorher bswap aus den GNU 
Utils nutze oder was ähnliches dann stimmt auch die Byteorder wieder.

Alternativ kannst du auch sicher mit snprintf und passenden format 
specifier was machen. Dann könnte die Lösung ein Einzeiler sein. Aber da 
ich mir nicht sicher bin ob es eine Hausaufgabe ist, welche du gerade 
versuchst zu lösen, überlasse ich Dir das googlen wie snprintf das lösen 
kann.

[Martin M. (ats3788)]

Danke ihr lieben, ich habe zwei Funktionen die ohne Problme mit C++ 
Builder funktionieren. Mit dem Arduino UNO
bekomme ich die richtige Länge des Strings, aber Buffer bleibt leer.
Leider kann man die Arduinos nicht debuggen.

uintToHexStr habe ich angepasst.

Der Code


static char hex[] = { '0', '1', '2', '3', '4', '5', '6', '7',
'8', '9' ,'A', 'B', 'C', 'D', 'E', 'F' };

//The function that performs the conversion. Accepts a buffer with 
"enough space" TM
//and populates it with a string of hexadecimal digits.Returns the 
length in digits
int uintToHexStr(unsigned int num, char* buff)
{
  int len = 0, k = 0;
  do//for every 4 bits
  {
    //get the equivalent hex digit
    int tmp = num & 0xF;
    buff[len] = hex[tmp];
    len++;
    num >>= 4;
  } while (num != 0);
  //since we get the digits in the wrong order reverse the digits in the 
buffer
  for (; k<len / 2; k++)
  {//xor swapping
    buff[k] ^= buff[len - k - 1];
    buff[len - k - 1] ^= buff[k];
    buff[k] ^= buff[len - k - 1];
  }
  //null terminate the buffer and return the length in digits
  buff[len] = '\0';
  return len;
}



unsigned int num_hex_digits(unsigned int n) {
  int ret = 0;
  while (n) {
    n >>= 4;
    ++ret;
  }
  return ret;
}

int IntToHex(uint32_t num, char* buffer)
{
  char *p = buffer;
  uint32_t pad = 0;
  uint32_t len = num_hex_digits(num);
  /* if odd number, add 1 - zero pad number */
  if (len % 2 != 0)
    pad = 1;

  /* move to end of number string */
  p += len + pad; //- 1;

  len = 0;
  *p = 0;
  *p--;
  while (num) {

    len++;
    int tmp = num & 0xF;
    if (tmp < 10)
      *p = tmp + '0';
    else
      *p = tmp + 'A' - 10;
    Serial.print("++++>");
    Serial.print(*p);
    num >>= 4;

    p--;
  }
  if (pad) {
    *p = '0';
  }

  return (len);
}

char Buffer[10];
uint32_t hex = 0x7988aa;

uintToHexStr(hex, Buffer);
  Serial.print("Hex Test ");
  Serial.println(Buffer);

[Dr. Sommer (Gast)]

Warum nicht einfach

Serial.print(78, HEX);

https://www.arduino.cc/reference/en/language/functions/communication/serial/print/

oder

String stringOne =  String(45, HEX);

https://www.arduino.cc/en/Tutorial/StringConstructors

[Martin M. (ats3788)]

Hallo das Problem war das unsigned int eine 16 bit integer ist und ich 
eine 32 bit zahl auflösen wollte.
so funktioniert das auch mit einem uno

static char hex[] = { '0', '1', '2', '3', '4', '5', '6', '7',
'8', '9' ,'A', 'B', 'C', 'D', 'E', 'F' };

//The function that performs the conversion. Accepts a buffer with 
"enough space" TM
//and populates it with a string of hexadecimal digits.Returns the 
length in digits
int uintToHexStr(uint32_t num, char* buff)
{
  int len = 0, k = 0;
  do//for every 4 bits
  {
    //get the equivalent hex digit
    uint32_t tmp = num & 0xF;
    buff[len] = hex[tmp];
    len++;
    num >>= 4;
  } while (num != 0);
  //since we get the digits in the wrong order reverse the digits in the 
buffer
  for (; k<len / 2; k++)
  {//xor swapping
    buff[k] ^= buff[len - k - 1];
    buff[len - k - 1] ^= buff[k];
    buff[k] ^= buff[len - k - 1];
  }
  //null terminate the buffer and return the length in digits
  buff[len] = '\0';
  return len;
}

[Rufus Τ. F. (rufus)]

Martin M. schrieb:
> //since we get the digits in the wrong order reverse the digits in the
> buffer

Wie wäre es, die "digits" einfach gleich in der richtigen Reihenfolge 
anzuordnen?

[Nils Pipenbrinck (Gast)]

Rufus Τ. F. schrieb:
> Wie wäre es, die "digits" einfach gleich in der richtigen Reihenfolge
> anzuordnen?

Wäre zu einfach, außerdem kann man dann den "tollen" XOR Trick nicht 
zeigen :-)

[Dr. Sommer (Gast)]

Rufus Τ. F. schrieb:
> Wie wäre es, die "digits" einfach gleich in der richtigen Reihenfolge
> anzuordnen?

Dazu muss man aber wissen, wie viele Ziffern es sind, oder vorher Platz 
lassen. Folgendermaßen könnte man die Ziffern vorab zählen:

#include <type_traits>
#include <cstddef>
#include <iostream>
#include <limits>
#include <algorithm>

#ifdef __GNUC__

constexpr inline std::size_t leadingZeroes (unsigned char x) {
  return __builtin_clz (x);
}

constexpr inline std::size_t leadingZeroes (unsigned short x) {
  return __builtin_clz (x);
}

constexpr inline std::size_t leadingZeroes (unsigned int x) {
  return __builtin_clz (x);
}

constexpr inline std::size_t leadingZeroes (unsigned long x) {
  return __builtin_clzl (x);
}

constexpr inline std::size_t leadingZeroes (unsigned long long x) {
  return __builtin_clzll (x);
}

#endif

template <typename T>
std::size_t leadingZeroes (T x) {
  std::size_t c = 0;
  while ((x & (T { 1 } << (std::numeric_limits<T>::digits - 1))) == 0) { x <<= 1; ++c; }
  return c;
}

template <typename T>
typename std::enable_if<std::is_unsigned<T>::value, std::size_t>::type IntToHex (char* str, T val, std::size_t maxLen) {
  std::size_t digits = std::min<std::size_t> (maxLen-1, val == 0 ? 1 : (((std::numeric_limits<T>::digits-leadingZeroes (val)) + 3) / 4));
  char* p = str + digits;
  *p-- = 0;
  for (std::size_t i = 0; i < digits; ++i) {
    char d = static_cast<char> (val & 0xF);
    *p-- = d >= 10 ? (d - 10 + 'A') : (d + '0');
    val >>= 4;
  }
  return digits;
}

template <typename T, std::size_t N>
typename std::enable_if<std::is_unsigned<T>::value, std::size_t>::type IntToHex (char (&str) [N], T val) {
  return IntToHex (str, val, N);
}

int main () {
  char buf [40];
  std::uint32_t x;
  std::cin >> x;
  IntToHex (buf, x);
  std::cout << buf << std::endl;
}

Implementiert via templates, sodass es direkt für alle Integer-Typen 
funktioniert. Diese müssen aber vorzeichenlos sein. Dafür ist es so 
etwas effizienter und sicherer durch eingebaute Array-Bereichs-Prüfung. 
Funktioniert nur auf AVR-GCC und Arduino leider nicht, weil es da keine 
C++ Standard Bibliothek gibt.

[Gurl (Gast)]

@Dr.Sommer : Waruuum?

[Gurl (Gast)]

Für Controller mit effektivem Bitshifting(barrel shifter):

Leftshift anstelle von Rightshift
Höchtes Nibble runterholen mit >> (sizeof Zahl * 8 -4)  ,..  and 0xf
wenn Null, nicht in String einfügen, ansonst normal von links weg 
einfügen

[zitter_ned_aso (Gast)]

Deine Hex-Darstellung wird ja in einem String gespeichert. Oben wurde 
schon erwähnt, dass du diese Funktion evtl. gar nicht brauchst.

imonbln schrieb:
> Alternativ kannst du auch sicher mit snprintf und passenden format
> specifier was machen. Dann könnte die Lösung ein Einzeiler sein.

Ich weiß nicht was Arduino Uno so alles kann, aber C kann jede dezimale 
Zahl in oktaler/hexadezimaler Darstellung problemlos darstellen.

Bsp.:

for(int i=0; i<20; i++)
          printf("dec: %d, oct: %#o, hex: %#x\n", i, i, i);

Oder halt mit snprintf in einem String ablegen

[PittyJ (Gast)]

Ich hätte auch snprintf verwendet.

[Daniel F. (df311)]

was ich im ganzen thread nicht gefunden habe ist eine (m.e. durchaus 
sinnvolle/wichtige) information:

wozu?

da das ganze unter pc programmierung gepostet ist, nehme ich mal an es 
handelt sich um eine plattform mit etwas mehr cojones als ein arduino 
(wurscht ob mini, nano, uno, ...)

[Rufus Τ. F. (rufus)]

Dr. Sommer schrieb:
> Dazu muss man aber wissen, wie viele Ziffern es sind,

Es ist recht üblich, Hexwerte mit führenden Nullen auszugeben. Und dann 
ist die Anzahl der Stellen implizit gegeben.

[Martin M. (ats3788)]

Danke für die netten Antworten.
Leider geht das alles nicht was vorgeschlagen wurde Arduino UNO sprintf 
verarbeitet nur 16 bit Integer was größer ist wird abgeschnitten.

static char hex[] = { '0', '1', '2', '3', '4', '5', '6', '7',
'8', '9' ,'A', 'B', 'C', 'D', 'E', 'F' };

//The function that performs the conversion. Accepts a buffer with 
"enough space" TM
//and populates it with a string of hexadecimal digits.Returns the 
length in digits
int Int2Hex(uint32_t num, char* buff)
{
  int len = 0, k = 0;
  do//for every 4 bits
  {
    //get the equivalent hex digit
    uint32_t tmp = num & 0xF;
    buff[len] = hex[tmp];
    len++;
    num >>= 4;
  } while (num != 0);
  //since we get the digits in the wrong order reverse the digits in the 
buffer
  for (; k<len / 2; k++)
  {//xor swapping
    buff[k] ^= buff[len - k - 1];
    buff[len - k - 1] ^= buff[k];
    buff[k] ^= buff[len - k - 1];
  }
  //null terminate the buffer and return the length in digits
  buff[len] = '\0';
  return len;
}

Hierbei ist der uint32_t Teil wichtig.

[zitter_ned_aso (Gast)]

Martin M. schrieb:
> Leider geht das alles nicht was vorgeschlagen wurde Arduino UNO sprintf
> verarbeitet nur 16 bit Integer was größer ist wird abgeschnitten.

na vermutlich wegen %d als format spezifier.

Bei den Datentypen aus inttypes.h sollte man auch dazugehörige Makros 
(für die  Eingabe/Ausgabe) benutzen (und nicht %d, %x usw..)

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
#include <limits.h>


int main(void){
  
    #define WHATEVER 100  

    uint32_t num=65535+1;

    char str[WHATEVER]; 
    sprintf(str, "dec: %" PRIu32 "\thex: %" PRIx32  "\n", num, num);
   
    puts(str); 
    
    return EXIT_SUCCESS;
}

Aber so ist es bestimmt noch einfacher und richtiger.

Dr. Sommer schrieb:
> Warum nicht einfachSerial.print(78, HEX);
> 
https://www.arduino.cc/reference/en/language/functions/communication/serial/print/
>
> oder
> String stringOne =  String(45, HEX);
> https://www.arduino.cc/en/Tutorial/StringConstructors

[Martin M. (ats3788)]

Also
die Function die ich gepostet habe die funktioniert ohne Probleme
beim 8 bit UNO muss man einiges beachten der kann auch kein
Float ausgeben mit %f in printf oder sprintf da macht man es mit

dtostrf Beitrag "dtostrf funktion allgemein"

oder auch die Variablen. In PC C++ soll man nach Möglichkeit nur lokale 
Vars benutzen. Mit µMCU ist speicher ein hares gut und man muss Sparsam 
damit umgehen, so definiert man z.B. ein Text Buffer global
char Buffer[50]. Mehr Fallstricke fallen mir nicht ein währe vielleicht 
Sinnvoll in einem anderen Post.

Ein schönes Wochenende.

[Wolfgang (Gast)]

Martin M. schrieb:
> Das hatte ich gefunden nur da ist amp undefiniert.

Das kommt davon, wenn man HTML-Texte kopiert.

[W.S. (Gast)]

Martin M. schrieb:
> Ich dachte dazu kann ich einiges Googeln
> aber alles was ich fand war nicht so brauchbar.

Ach herrje, da hättest du besser dir die steinalte Lernbetty hier im 
Forum heruntergeladen. Hier mal ein Auszug:

const char HexChars[17]   = {"0123456789ABCDEF"};

/* ein Hex-Zeichen ausgeben */
void Nibble_Out (int aHex)
{ V24_CharOut (HexChars[aHex & 0x0F]); }

/* ein Byte als Hexa ausgeben */
void HexB_Out (byte aHex)
{ Nibble_Out (aHex >> 4);
  Nibble_Out (aHex);
}

/* ein Word als Hexa ausgeben */
void HexW_Out (word aHex)
{ HexB_Out (aHex >> 8);
  HexB_Out (aHex);
}

/* ein DWORD als Hexa ausgeben */
void HexL_Out (long aHex)
{ HexW_Out (aHex >> 16);
  HexW_Out (aHex);
}

/* ein QWORD als Hexa ausgeben */
void HexQ_Out (int64* aHex)
{ HexL_Out (*aHex >> 32);
  HexL_Out (*aHex);
}

So, reicht's?
Und wie man den ganzen Schmonzes in einen Puffer schreibt und dann die 
Länge oder nen Zeiger auf das folgende Nullbyte zurückliefert, überlasse 
ich dem TO als Fingerübung.

Und warum HexQ_Out hier einen Pointer anstelle des Values haben will, 
darf bei Bedarf ergrübelt werden. Stichwort SVC.

Manchmal frag ich mich, wieso Aufgaben dieses Levels eine verzweifelte 
Suche im Internet erforderlich machen.

W.S.

[W.S. (Gast)]

Dr. Sommer schrieb:
> Dazu muss man aber wissen, wie viele Ziffern es sind,

Ach, noch nie von der RBI/RBO-Funkionalität gehört? Also Hardware kannst 
du auch nicht.

Nee, das Einfachste - sofern man sowas tatsächlich will (was ich 
bezweifle, das hat Rufus schon richtig zum Ausdruck gebracht) wäre, 
solange die auszugebenden Zeichen zu ignorieren, bis eines ungleich '0' 
kommt oder die Einerstelle erreicht ist. Eben RBI/RBO in Software.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Ach, noch nie von der RBI/RBO-Funkionalität gehört? Also Hardware kannst
> du auch nicht.

Wo ging es in diesem Thread um Hardware?

W.S. schrieb:
> solange die auszugebenden Zeichen zu ignorieren, bis eines ungleich '0'
> kommt oder die Einerstelle erreicht ist.

Was aber nur geht, wenn man die Zeichen von links an produzieren kann. 
Was nur effizient geht, wenn man einen Barrel-Shifter hat (Mr. 
Hardware). Was aber auch schon alles gesagt wurde.

Was passiert eigentlich wenn man deine supertollen Code auf einer 
Plattform mit long=64 bit ausführt? Warum benutzt du auf ARM die 
unsägliche Windows-Nomenklatur mit word=16bit, wo ARM das schon ewig als 
32bit festlegt?

W.S. schrieb:
> Stichwort SVC.

Hast du im Ernst eine Reihe an Hex-Ausgabefunktionen als Syscall 
implementiert? Es aber nicht geschafft dabei mehr als ein 32bit-Word als 
Parameter zu übergeben? Mindestens 4 sollte man hinbekommen. Mehr auch 
mit etwas Stack-Pointer-Gymnastik.

[Dr. Sommer (Gast)]

Für die Lästernden, hier eine Version welche von links an ausgibt und 
daher ohne Barrel-Shifter ineffizient ist:

#include <type_traits>
#include <cstddef>
#include <iostream>
#include <limits>
#include <algorithm>
#include <iterator>

template <typename T, typename Iter>
typename std::enable_if<std::is_unsigned<T>::value, std::size_t>::type IntToHex (Iter outIter, T val, std::size_t minDigits = 1) {
  static constexpr T mask = (T { 0xF } << (std::numeric_limits<T>::digits-4));
  
  std::size_t outDigits = (std::numeric_limits<T>::digits+3)/4;
  while ((val & mask) == 0 && outDigits > minDigits) {
    val <<= 4;
    --outDigits;
  }
  
  for (std::size_t i = 0; i < outDigits; ++i) {
    char d = static_cast<char> ((val >> (std::numeric_limits<T>::digits-4)) & 0xFF);
    *outIter = d >= 10 ? (d - 10 + 'A') : (d + '0');
    ++outIter;
    val <<= 4;
  }
  return outDigits;
}

struct UartOutput {
  UartOutput& operator ++ () { return *this; }
  UartOutput& operator * () {  return *this; }
  UartOutput& operator = (char x) {
    std::cout << "Simulierte UART-Ausgabe: " << x << std::endl;
    // UART_PutChar (x);
    return *this;
  }
};

int main () {
  std::uint64_t x;
  std::cin >> x;

  {  // Indirekte Ausgabe via Puffer
    char buf [40];
    buf [IntToHex (buf, x, 5)] = 0;
    std::cout << "Ausgabe via Puffer  : " << buf << std::endl;
  }
  {  // Direkte Ausgabe auf std::cout via Output-Iterator
    std::cout << "Ausgabe via Iterator: ";
    IntToHex (std::ostream_iterator<char> (std::cout), x, 5);
    std::cout << std::endl;
  }
  {  // Direkte Ausgabe auf UART via Output-Iterator
    IntToHex (UartOutput {}, x, 5);
  }
}

Funktioniert auch wieder dank Templates mit allen Integer-Typen auf 
allen Plattformen (solange die Größe ein Vielfaches von 4bit ist; für 
krumme Längen bräuchte es mehr Fallunterscheidungen). Es kann die 
Mindest-Länge der Ausgabe angegeben werden.

Zusätzlich erfolgt die Ausgabe über einen Output-Iterator. Der Aufrufer 
kann also selbst festlegen, ob in einen Puffer oder direkt in einen 
Output-Stream geschrieben werden soll. Als Beispiel wird in einen 
char-Buffer, direkt auf std::cout und einen Beispiel-Dummy-UART-Output 
geschrieben.

[W.S. (Gast)]

Dr. Sommer schrieb:
> Hast du im Ernst eine Reihe an Hex-Ausgabefunktionen als Syscall
> implementiert? Es aber nicht geschafft dabei mehr als ein 32bit-Word als
> Parameter zu übergeben? Mindestens 4 sollte man hinbekommen. Mehr auch
> mit etwas Stack-Pointer-Gymnastik.

Hast du im Ernst schon jemals einen ARM7TDMI aus der Nähe gesehen?
Nö, haste nicht.
Und das verstehende Lesen scheint dir auch nicht sympathisch zu sein.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Hast du im Ernst schon jemals einen ARM7TDMI aus der Nähe gesehen?

Selbst wenn nicht, hätte ich trotzdem Recht. Die "SVC"-Instruktion 
verändert nicht die Inhalte der 13 General-Purpose-Register, welche 
man somit zur Parameter-Übergabe nutzen kann.

Eine Int2Hex-Funktion ist eine allgemeine datenverarbeitende 
Hilfsfunktion und gehört nicht in einen Syscall. Alles was als 
Userspace-Funktion implementiert werden kann, sollte das auch, ggf. in 
einer Library. Dies trennt die OS-Teile vom Anwendungsteil. Du kannst 
deinen Funktionen anscheinend nichtmal übergeben, auf welchen 
Dateideskriptor oder Hardware die Ausgabe erfolgen soll; du hast hier 
die völlig unabhängigen Dinge "V24-Ausgabe" und "Int2Hex" miteinander 
verknüpft, sodass man sie nicht mehr getrennt nutzen kann. Ganz 
schlechtes Design. Linux macht vor wie das richtig geht: Ein 
"write"-Syscall welcher einen beliebigen Puffer ausgibt, und komfortable 
Formatierungsfunktionen wie printf in der C-Library. Da Syscalls ein 
extra Overhead sind (insbesondere auf Systemen mit virtuellem 
Speicher/MMU) sollte man möglichst viele Daten mit einem Aufruf 
übergeben, und nicht jeden Integer einzeln.

W.S. schrieb:
> Und das verstehende Lesen scheint dir auch nicht sympathisch zu sein.

Du bist doch der, welcher trotz wiederholter Versuche nichts dazulernt. 
Wie war das mit dem mehrdimensionalen Array?

[W.S. (Gast)]

Dr. Sommer schrieb:
> Selbst wenn nicht, hätte ich trotzdem Recht. Die "SVC"-Instruktion
> verändert nicht die Inhalte der 13 General-Purpose-Register, welche
> man somit zur Parameter-Übergabe nutzen kann.

Aha, du kennst also auch nichts von sowas wie einem ABI, also den 
Aufruf-Konventionen für die betreffende Plattform.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Aha, du kennst also auch nichts von sowas wie einem ABI, also den
> Aufruf-Konventionen für die betreffende Plattform.

Der AAPCS, das ABI für ARM, benutzt 4 Register r0-r3 für die Parameter 
Übergabe. Also 4 32bit-Words. Mehr Words kann man auf dem Stack 
übergeben. Also, warum nochmal kannst du nur ein Word per SVC übergeben?

[Dr. Sommer (Gast)]

PS: Und warum muss man sich bei SVC an das normale ABI halten? Selbst 
Linux nutzt hier mehr als 4 Register für mehr Parameter.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Dr. Sommer schrieb:
> Warum benutzt du auf ARM die
> unsägliche Windows-Nomenklatur mit word=16bit, wo ARM das schon ewig als
> 32bit festlegt?

Ach Gottchen. Dann ersetzt man eben word durch uint16_t und long durch 
uint32_t usw. Dafür sind die types ja da. Die Methode von W.S. 
jedenfalls benutze ich auch seit Jahren ohne Problem auf STM32, AVR, 
8051, PIC usw. Nechteilig finde ich nur, das die Tabelle auf manchen 
Plattformen im RAM liegen muss. Aber wer heute keine 16 Bytes mehr frei 
hat, der hat auch noch andere Probleme.

[Dr. Sommer (Gast)]

Matthias S. schrieb:
> Ach Gottchen. Dann ersetzt man eben word durch uint16_t und long durch
> uint32_t usw. Dafür sind die types ja da.

Sollte man halt auch machen anstatt dieses Pascal-in-C zu verbreiten...

[Uhu U. (uhu)]

So kann mans auch machen:

char *uintToHexStr(unsigned num, char* buff, size_t len) {
    if (len <= 2)
        return NULL;
        
    buff[--len] = 0;
    
    if (num == 0) {
        buff[--len] = '0';
        return buff + len;
    }
    
    while (num != 0 && len >= 1) {
        buff[--len] = '0' + (num & 0x0f);
        if (buff[len] > '9')
            buff[len] += 7;
        num >>= 4;
    }
    
    if (num != 0)
        return NULL;
    
    return buff + len;
}

der 3. Parameter ist die Länge des Puffers in char.

Die Funktion gibt einen Zeiger auf den Ergebnis-Puffer zurück, wenn die 
Zahl gewandelt werden konnte und NULL, wenn der Puffer für die Wandlung 
zu kurz war.

[zitter_ned_aso (Gast)]

und warum lässt ihr immer das Präfix "0x" weg?

[Dirk B. (dirkb2)]

zitter_ned_aso schrieb:
> und warum lässt ihr immer das Präfix "0x" weg?

weil das nicht immer nötig ist.
weil das nur eine Notation von C ist (es gibt auch andere)
weil man es auch einfach davor extra ausgeben kann

[Zeno (Gast)]

Dirk B. schrieb:
> zitter_ned_aso schrieb:
>> und warum lässt ihr immer das Präfix "0x" weg?
>
> weil das nicht immer nötig ist.
> weil das nur eine Notation von C ist (es gibt auch andere)
> weil man es auch einfach davor extra ausgeben kann

Das hat überhaupt nichts mit Notation zu tun. mit 0x werden hexadezimale 
Zahlen gekennzeichnet. Da kann man auch nichts extra ausgeben.
Da in den obigen Beispielen nur Zahlen von 0..9 benutzt werden muß es 
nicht hexadezimal sein, da bekanntlich bis zur Ziffer 9 dezimal und 
hexadezimal   identisch sind.

Allerdings gehört es nach meinem Verständnis zum guten 
(Programmier)Stil, das man es in einem Quelltext einheitlich macht. An 
Stelle von 0x0f hätte Uhu dann auch 15 schreiben sollen.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Zeno schrieb:
> An
> Stelle von 0x0f hätte Uhu dann auch 15 schreiben sollen.

Das macht m.E. aber die Maskierung des Nibbles deutlicher, als wenn du 
15 schreibst.

[Zeno (Gast)]

Matthias S. schrieb:
> Zeno schrieb:
>> An
>> Stelle von 0x0f hätte Uhu dann auch 15 schreiben sollen.
>
> Das macht m.E. aber die Maskierung des Nibbles deutlicher, als wenn du
> 15 schreibst.

Ich wollte eigentlich nur ausdrücken, das ich es in einem Quelltext 
einheitlich machen würde.
Also alles wo es um Bit oder Byteoperationen geht würde ich dann 
einheitlich als Hex schreiben alles andere im gewohnten Dezimalsystem.

Letztendlich ist das aber völlig Rille, es soll jeder so schreiben wie 
es ihm angenehm ist und da ist es eben wurscht ob ich 0xff oder 255 oder 
0377 oder 0b11111111 schreibe. Es ist immer die gleiche Zahl, die Frage 
ist halt nur was am Ende lesbarer ist.

[Gurgl (Gast)]

Zeno schrieb:
> Da in den obigen Beispielen nur Zahlen von 0..9 benutzt werden muß es
> nicht hexadezimal sein, da bekanntlich bis zur Ziffer 9 dezimal und
> hexadezimal   identisch sind.

Dachte ich auch beim ersten Hingucken aber hinterher kommt ein +7 damit 
springt er von der 9 zum A ;)

[Zeno (Gast)]

Gurgl schrieb:
> Dachte ich auch beim ersten Hingucken aber hinterher kommt ein +7 damit
> springt er von der 9 zum A ;)

Das A kommt aber in dem Quelltext nicht "optisch" vor, soll heisen man 
sieht es nicht im Quelltext.

Sein Code hat aber einen kleinen Fehler. Die Zeile if (len <= 2) muß 
richtigerweise if (len <= 1) heißen. Ansonsten wird bei einem zu groß 
gewählten Puffer ein Leerstring ausgegeben. Beispiel mit Puffergröße 3:

num=15 müßte 'F' ergeben ergibt aber Leerstring
num=16 ergibt korrekt '10'

Je größer Puffer wird um so extremer wird das Verhalten

[Zeno (Gast)]

Grad noch mal getestet, es geht trotzdem nicht. Die 2 sind schon korrekt 
wegen dem '\0' Zeichen.
Man muß den Puffer vorher mit dem Zeichen '0' initialisieren, wenn man 
ein halbwegs brauchbares Ergebnis haben will.

[Uhu U. (uhu)]

Matthias S. schrieb:
> Zeno schrieb:
>> An
>> Stelle von 0x0f hätte Uhu dann auch 15 schreiben sollen.
>
> Das macht m.E. aber die Maskierung des Nibbles deutlicher, als wenn du
> 15 schreibst.

So ist es…

[Uhu U. (uhu)]

Zeno schrieb:
> Das A kommt aber in dem Quelltext nicht "optisch" vor, soll heisen man
> sieht es nicht im Quelltext.

Als erfahrener Programmierer weiß man, dass ASCII '9' + 7 == 'A' ist…

Das ist ein uralter Trick aus den Zeiten, in denen noch fast alles in 
ASM programmiert wurde.

[Uhu U. (uhu)]

Zeno schrieb:
> Grad noch mal getestet, es geht trotzdem nicht.

Da hast du wohl einen kleinen Fehler gemacht:
Ergebnis ist nicht die Variable buff, sondern der Pointer, den 
uintToHexStr zurück gibt. Der zeigt je nach Länge von Buff und Größe der 
Zahl irgendwo in buff hinein. Was davor steht, interessiert nicht.

Die Routine hat zudem noch einen Vorteil: sie schreibt nichts kaputt, 
wenn der Puffer zu klein ist.

Nebenbei:
   Nach demselben Prinzip kann man eine Zahl auch ins Dezimalsystem
   wandeln. Statt num & 0x0f muss man dann eben num % 10 schreiben und
   statt num >>= 4; num /= 10;. Der Trick mit dem + 7 kann dann
   natürlich entfallen.

Die Anweisung

        if (buff[len] > '9')
            buff[len] += 7;

kann man natürlich auch so schreiben:

        if (buff[len] > '9')
            buff[len] += 'A' - '9';

und wenn man statt 'A' 'a' schreibt, kommt das Ergebnis in 
Kleinbuchstaben…

Diese Schreibweise hat den Vorteil, dass der Code auch in anderen 
(gängigen) Zeichencodierungen funktioniert. Den Ausdruck 'A' - '9' 
berechnet der Compiler und setzt dafür die Konstante 7 ein.

[Johann L. (gjlayde)]

Uhu U. schrieb:
> Den Ausdruck 'A' - '9' berechnet der Compiler und setzt dafür
> die Konstante 7 ein.

Vorteil ist vor allem die bessere Lesbarkeit.  Und man kann es auch in 
Assembler verwenden, die unterstützen solche einfachen Ausdrücke auch.

[PIClig (Gast)]

> template <typename T>
> std::size_t leadingZeroes (T x) {
>   std::size_t c = 0;
>   while ((x & (T { 1 } << (std::numeric_limits<T>::digits - 1))) == 0) { x > <<= 
1; ++c; }
> return c;
> }

Wenn ich diesen CPP-Murx sehe, wird mir schlecht.
Das verbraucht ja selbet im hässlichem PIC-Assembler weniger Zeichen
und ist aussagekräftiger.

[Michael B. (laberkopp)]

Dr. Sommer schrieb:
> Für die Lästernden, hier eine Version welche von links an ausgibt und
> daher ohne Barrel-Shifter ineffizient ist:

Uhu U. schrieb:
> So kann mans auch machen:

char *hexout(char *buf,unsigned x)
{
    if(x>0xF) buf=hexout(buf,x>>4);
    x&=0xF;
    *buf++=(x>9?'A'-10:'0')+x;
    return buf;
}

bzw.

hexout(unsigned x)
{
    if(x>0xF) hexout(x>>4);
    x&=0xF;
    putc((x>9?'A'-10:'0')+x);
}

[Dr. Sommer (Gast)]

PIClig schrieb:
> Wenn ich diesen CPP-Murx sehe, wird mir schlecht.

Ja, der C PräProzessor ist schlimm. Das ist aber C++.

PIClig schrieb:
> Das verbraucht ja selbet im hässlichem PIC-Assembler weniger Zeichen
> und ist aussagekräftiger.

Auch für sämtlich Integer-Typen und Plattformen? Wohl kaum.

Michael B. schrieb:
>> So kann mans auch machen:

Da das nicht Tail-Rekursiv ist - können Optimizer das iterativ umbauen?

[Uhu U. (uhu)]

Dr. Sommer schrieb:
> Da das nicht Tail-Rekursiv ist - können Optimizer das iterativ umbauen?

Vermutlich nicht, aber kann sowas ja auch iterativ programmieren… Man 
muss eben ein f von links nach rechts drüber schieben und mit & die 
betreffende Tetrade heraus picken, die man dann entsprechend nach rechts 
schiebt…

[Dr. Sommer (Gast)]

Uhu U. schrieb:
> Man
> muss eben ein f von links nach rechts drüber schieben und mit & die
> betreffende Tetrade heraus picken, die man dann entsprechend nach rechts
> schiebt…

Dann muss man aber doppelt shiften - sowohl das "f", und jedes mal das 
gewünschte Nibble nach Rechts. Ohne Barrelshifter eher blöd. Besser ist 
es, den Wert selbst kontinuierlich weiter zu shiften.

[Uhu U. (uhu)]

Dr. Sommer schrieb:
> Dann muss man aber doppelt shiften - sowohl das "f", und jedes mal das
> gewünschte Nibble nach Rechts. Ohne Barrelshifter eher blöd.

Wir sind hier im "Forum: PC-Programmierung" - PC-Prozessoren haben 
Barrelshifter…

[Zeno (Gast)]

Uhu U. schrieb:
> Als erfahrener Programmierer weiß man, dass ASCII '9' + 7 == 'A'

Das habe ich ja nicht bezweifelt das dem so ist.

Uhu U. schrieb:
> Zeno schrieb:
>> Grad noch mal getestet, es geht trotzdem nicht.
>
> Da hast du wohl einen kleinen Fehler gemacht:

Stimmt! Ich hatte mir nur den Puffer angeschaut und nicht das Ergebnis 
der Funktion.
Sorry war mein Fehler.