> > No więc - skoro już poprawiliśmy tą naszą funkcję, to jaka jest wartość dodana z
użycia kilku kolejnych kompilatorów?
>
> Bardzo prosta. Twój kompilator w poprawnej funkcji dodawania przypadkiem
> zrobił mnożenie kiedy x=15 i y=90.

To wychodzi w pokryciu kodu obiektowego.

> Shit happens.

Nie, nie happens.
Tzn. może są firmy, gdzie happens i się nie bada pokrycia (tak, tak, teraz ja sobie
dorabiam, dla równowagi do Twoich teorii, że w Ariane 5 nie było testów), ale tam
gdzie widzę, bada się i nie happens.

> Czasem to tylko mignie
> szybciej diodą a czasem wyśle samolot w kierunku gruntowym.

Nie było przypadku, żeby samolot poleciał w kierunku gruntowym przez to, że użyto
jednego kompilatora a nie trzech. Dlatego ten pomysł byłby potraktowany jako koszt
bez wartości dodanej.

> A kod działa przypadkiem tylko dlatego że kompilator w jakimś miejscu
> zamiast referencji użył wartości. W kodzie produkcyjnym użyje referencji

Zaraz, zaraz... Testowałeś nieprodukcyjny kod a produkcyjny były jakiś inny?
Tyle mądrości na temat weryfikacji a tu taki klops. Skup się.

> Aby zweryfikować narzędzia do weryfikacji.

O, tu, widzisz, poruszyłeś ciekawe zagadnienie.
Ale kwalifikację narzędzia robi się przed projektem, bo projekt zaczyna się mając już
zatwierdzone narzędzia. I jeśli do tej kwalifikacji chcesz sobie użyć materiału
testowego pochodzącego z różnych kompilatorów, to właściwie może to mieć sens (ale
nie musi). Tylko że nadal nie ma sensu używać więcej niż jednego kompilatora do
robienia tego właściwego projektu.

> > I tu jest cały trick. Kompilator nie jest celem ani centrum tego ćwiczenia.
>
> Jest narzędziem które odpowiada na pytanie czy kod działa czy nie.

Kompilator? Nie, nie odpowiada na takie pytanie. Właściwie to mogłoby nie być żadnego
kompilatora, można posadzić człowieka z zapasem kawy i herbatników i niech
"kompiluje". I to nawet nie jest fikcja.

> Czasami odpowiada źle.

Nie pokazałeś niczego takiego.

> Nie. Wykazałeś że w jakiś warunkach Twój kod działa. A czy to te same
> warunki kiedy będzie używany produkcyjnie?

I w jaki sposób trzy kompilatory mają coś tu zmienić? Ilość kompilatorów wpływa na
to, jak bardzo zmieniają się warunki w użyciu produkcyjnym?

> Może wyjaśnie na przykładzie. Znam człowieka pracujacego dla poważnej
> instytucji związanej z lotnictwem. Aby ich kod przeszedł certyfikat
> pozwalający na stosowanie w samolotach musieli, poza wykazaniem
> testowania we wszystkich odmianach, zarządzania jakością, weryfikacji
> formalnej również to czy zweryfikowali narzędzia. Ponieważ smutni
> panowie od certyfikowania nie są z kosmosu i znają realia to zapytali w
> ILU różnych symulatorach potwierdzono działanie kodu i czy ich
> producenci sami są certyfikowani do użycia w takiej branży.

Wszystko się zgadza.
Ale nie ma tu ani słowa o użyciu wielu kompilatorów.

I jeśli jesteśmy w temacie samolotów i smutnych panów - standardy lotnicze są tak
napisane, że użycie wielu kompilatorów do kompilowania tego samego kodu w projekcie
nie jest podstawą do dodatkowego uznania (tzw. certification credit) w czasie audytu
certyfikacyjnego a weryfikacji kodu wynikowego nie robi się garścią kompilatorów, bo
kod ma być jeden. Ten sam w testach, co na produkcji.

Dlatego ten pomysł nie ma zastosowania w projektach krytycznych, w szczególności w
lotniczych. Prawie byłeś blisko w temacie kwalifikacji narzędzi (np. narzędzie do
badania pokrycia kodu testami można próbować kwalifikować przy użyciu materiału
testowego z jakiegoś zestawu kompilatorów, ale to i tak niewiele wnosi w konteście
danego projektu, gdzie jest jeden kompilator), ale generalnie mylisz pojęcia.

No i fajnie, że znasz "człowieka pracujacego dla poważnej instytucji związanej z
lotnictwem".

> PS. A zupałnie na marginesie wszelkiej certyfikacji. Odpalam mój kod pod
> trzema kompilatorami.

Ja też - wtedy, gdy piszę biblioteki.

Ale w projekcie krytycznym używa się jednego kompilatora. I testuje się kod
produkcyjny.

--
Maciej Sobczak * http://www.inspirel.com