TYPE "Michoo":
>> Żeby programista mógł napisać niezależną od sprzętu część
>> oprogramowania (czyli typowo- w języku wysokiego poziomu), nie może
>> używać typów (ograniczmy się wstępnie do liczbowych) danych związanych
>> ze sprzętem. Żeby kompilator mógł wytorzyć działającyc program-- musi
>> je znać, gdyż ich użyje w miejsce abstrakcyjnych typów. W związku z
>> tym-- pytanie o rzeczywistą realizację: wymyślone typy danych, z ich
>> własnymi limitami, które następnie są albo dopasowywane do typów danych
>> maszyny, albo symulowane przez kompilator na maszynie lub w środowisku
>> wykonywania, czy może analogicznie do prostego "typedef", które tylko
>> zmienia nazwy typów, uniemożliwiając programiście oparcie się na
>> właściwościach typu zależnego od maszyny.
> stdint.h inttypes.h
> Używasz tego co potrzebujesz - jeżeli potrzebujesz 32bitową zmienną
> całkowitą, bo większego zakresu nie użyjesz, a będzie ich dużo i zależy
> ci na upakowaniu danych to piszesz int32_t, jak potrzebujesz zmienną
> 64bitową, piszesz int64_t i nie przejmujesz się, czy ktoś skompiluje kod
> pod i386,amd64, czy avr, bo będzie działał. Jak z to potrzebujesz czegoś
> co będzie *minimum* 16 bit, ale ma być możliwie szybkie na tej
> platformie (np zmienna lokalna, w której coś liczysz) to używasz
> int_fast16_t i na i386 dostajesz int32_t, na amd64 dostaniesz int64_t, a
> na avr int16_t.
>
> To jest właśnie potęga C/C++ - jeżeli napisałeś program porządnie to
> skompiluje się na wszystkim na co jest kompilator.
A algorytm nie musi być optymalny i kompilator nic z nim już nie zrobi oprócz
usiłowań.
--
/ qo |) :@=N%_g=v=a=g_eD_e=c()=d=8! =%!gN@8'Re. w8in/ad
\ _x/ , ;h-%-a'hA'H4,X0'Xo~xo~xO,R`-%EXp01ITed: *-7/+eh
/ | ng `-%__%--'__%--'__%--~__%--^%B`/$qV3r[o; &GooMee
L ,_o_O http://groups.yahoo.com/group/opRWTng O_o_, /L"EnOF"