W dniu 2014-04-06 18:55, AlexY pisze:
> Użytkownik Mario napisał:
>> W dniu 2014-04-06 14:28, AlexY pisze:
> [..]
>>> 2. ASM rozumiem, C C++ i pochodne to dla mnie sieczka stworzona żeby
>>> wyrwać kasę na szkolenie specjalistów, bardzo lubiłem basic'a, jest
>>> przejrzysty, nie można było go rozbudować?
>>
>> Uważasz, że żeby nauczyć się c to trzeba się odpłatnie szkolić u
>> specjalistów? No to może w tym jest twój problem. Ja po nastu latach
> [..]
>
> Wszystkiego idzie się samemu nauczyć, ja na razie jakoś nie mam
> motywacji, a jest ona mi niezbędna po pierwszych podejściach do C

Tak jak pisałem dla mnie wystarczającą motywacją było przejście z asm na
51 do asm na AVR.
>
>>> 4. Czas pisania programu, to najbardziej mnie załamuje, prawda że asm
>>> zajmuje dużo czasu, ale błędy są wtedy moje a nie kompilatora.
>>
>> Napisz coś konkretnego o tych błędach kompilatora. I w czym są gorsze od
>> błędów własnych?
>
> Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
> co stworzył, a to w sumie tak jakbyś od razu w asm pisał.


No ale na błędy kompilacji narzekają chyba tylko ci co nie kompilują.
Chyba to jest dla nich odpowiednik takich niedostępnych winogron które
zapewne i tak są kwaśne.

>>> Załamka
>>> polega na tym że w imię przyśpieszenia programowania poświęca się jakość
>>> ale to niestety normalne w obecnych czasach, program napisany ze 3 razy
>>> szybciej wychodzi 2 razy większy i 5 razy wolniejszy,
>>
>> I wrzuca się go na 10 razy szybki procek. W efekcie czas realizacji
>> zadania jest mniejszy, koszt zarazem też niższe, a wydajność procka wraz
>> z oprogramowania wyższa.
>
> Właśnie, i ten procek zamiast zrobić co trzeba to tańczy lambadę nagraną
> przez kompilator, dlatego musi być 10x szybszy.

Dostajesz kod np 1.6 wolniejszy niż byś go napisał sam w asm a
uruchamiasz go na 10 razy szybszym procku. Nie opłaca się? W dodatku
czas przesiadki programisty na ten 10 razy szybszy procek jest też
wielokrotnie szybszy w przypadku c niż asm.

>>> a do tego mimo że
>>> napisany prawidłowo zawiera błędy kompilatora, znane i nieznane.
>>
>> Z błędami kompilatora jest tak jak z błędami w architekturze procka. Są
>> znane i nieznane. Jak masz pecha to możesz na nie trafić.
>> Jak siedzisz w temacie i korzystasz z wiedzy zawartej w dużej
>> społeczności masz duże szanse dowiedzieć się o tych błędach i ich
>> unikać. A największe społeczności są teraz zgromadzone wokół ARMów i gcc.
>
> Co do błędów kompilatorów nie podam konkretów bo ich nie mam, co jakiś
> czas gdzieś trafie na jakieś info że coś źle z kompilatora wychodzi ale
> nie kolekcjonuje tego, mam zakodowane że przy kompilatorach mój program
> z moimi błędami jest nakładany na cudzy program (kompilacja) z cudzymi
> błędami, tak jak piszesz trzeba być na bieżąco z danym kompilatorem aby
> znać i omijać jego bolączki. Przy ASMie trzeba być na bieżąco jedynie z
> erratą procka.

Tylko, że z błędami spowodowanymi przez siebie programista walczy co
chwila, a błąd kompilatora masz szansę spotkać raz na dziesięć lat. No
chyba, że używasz ne opartych na gcc, komercyjnych kompilatorów dla
niezbyt popularnych architektur.

> Przypomniało mi się coś:
> http://bash.org.pl/4845689/
> <Lukasz> w C++ o błędach mówi nam kompilator
> <Lukasz> w PHP klient

No ale to jest o błędach programisty :)



--
pozdrawiam
MD