Zbych pisze:
> Sebastian Biały pisze:
>> Zbych wrote:
>>> Piszesz tak jakby gcc nie miało szmaciarskich błędów i
>>> niestandardowych rozszerzeń.
>>
>> Które są poprawiane. Nie ma sytuacji typu wymuszanie haraczu: "Nie
>> działa wam wersja 1.0 ? Mamy 2.0 za $10000". W ostateczności poprawisz
>> sam jesli Cie przyciśnie.
>
> Już to wiedzę, jak programiści odrywają się od swojej roboty, żeby
> grzebać w gcc. Prędzej tak napiszą kod, żeby ominąć błąd i modlą się,
> żeby w następnej wersji był poprawiony.

Jak dla mnie to populistyczny argument. Bledy sa wszedzie. Ale jakos nie
wierze w szanse na powazny blad w gcc, ktore jest testowane na kilku
platformach sprzetowych i na codzien sluzy do kompilacji projektow
zawierajacych setki milionow linii kodu - np. GNU/Linux i otoczenie.
Jesli piszesz o bledach portu na AVR to przejrzyj chociazby liste
AVRFreaks. Powazne bledy sa naprawiane przy kolejnym wydaniu WinAVR, a
czesto patche sa juz dostepne w SVN w ciagu doslownie paru dni.
I zeby bylo smieszniej Atmel wspiera community rozwiajajace port na AVR,
chociazby przez fakt zatrudniania developerow AVR-libc. Wiec masz
wysokiej jakosci kompilator z supportem zupelnie za darmo. Pokaz mi cos
porownywalnego na '51 lub dowolny inny mikrokontroler.

Piszesz o dziwnych niekompatybilnych rozszerzeniach gcc. Tak sie sklada,
ze pisze sobie GUI w c++ na AVR i symulator na PC. 99% kodu GUI jest
wspolna, roznica dotyczy paru klas scisle zwiazanych ze sprzetem, ktore
symuluje na PC. Nie ma zadnych problemow.
Gdybym korzystal z np. IAR to calosc szlag by trafil bo nijak nie daloby
sie tego skompilowac zywcem na PC.