🚀 go-pugleaf

> > 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