Formatovany tisk pro 8bit

[Pavel Hudeček]

Zajímavé je, jak různé konstrukce můžou vést k různé délce kódu.

Rozdíl 500 B trochu překvapil, ale OK. Použito je long a double.
Vlastně bych to čekal spíš naopak, když se u té delší verze nepředává 
val. Ale chápu, že tohle asi snadno sežere nějaká optimalizace, když se 
v val nic nedělá.

Nějaké nápady na další konstrukce, které by mohly být menší?

Dost ale překvapilo 30 B u *nepoužitých funkcí* test.
WTF?

PH


template <typename T> class clDetTyp { // ===========================
public:
     //const char det() const;
      char det(unsigned int x)  {return 'u';}
      char det(int x)  {return 'i';}
      char det(unsigned long x)  {return 'U';}
      char det(long x)  {return 'L';}
      char det(float x)  {return 'f';}
      char det(double x)  {return 'd';}
};

/*// tohle bylo delsi o ~500B, const nemají vliv
template <> const char clDetTyp<unsigned int>::det() const { return 'u';}
template <> const char clDetTyp<int>::det() const { return 'i';}
template <> const char clDetTyp<long>::det() const { return 'L';}
template <> const char clDetTyp<float>::det() const { return 'f';}
template <> const char clDetTyp<double>::det() const { return 'd';}*/

template<typename T>
void uartSendF(const char *t, T val, uint8_t mist) { // =============
     clDetTyp<T> d;
     if (d.det(val)=='f' || d.det(val)=='d') {
         float m = 1.0;
         for (uint8_t n=0; n<mist; n++) m*=10.0;
         uartSendF_(t, static_cast<long>(val*m), mist);
     } else if (d.det(val)=='L') uartSendF_(t, val, mist);
     else uartSendF_(t, static_cast<long>(val), mist);
}

/*// tyhhle funkce nejsou použitý, ale zakomentování ušetří 30B 
(uartSendF s jedním PSTR se používá i jinde)
// Změna délky PSTR v nich nevede ke změně rozdílu zabrané flash
const void test(int x) {
     uartSendF(PSTR("test: int\r\n"));
}
void test(char x) {
     uartSendF(PSTR("test: char\r\n"));
}*/


------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20240422/5fd7c898/attachment.htm>