🚀 go-pugleaf

Dnia Wed, 21 Nov 2007 23:00:26 +0100, Seweryn Habdank-Wojewódzki skrobie:
> Witam

> Sektor van Skijlen wrote:

> > Ale jeśli wydaje ci się, że języki, których standardy są robione
> > równolegle z referencyjną implementacją, nie posiadają idiotyzmów, to
> > jesteś w błędzie.
>  
> C++0x powoli dorabia sobie reference implementation w postaci gcc 4.3 :-).
> To dla tych co narzekają, że komitet wymyśli coś czego nie da się
> zaimplementować.

O właśnie!

Bronek: może tam w komitecie ktoś rozważa propozycję, żeby gcc stało się
oficjalną dla X3J16 referencyjną implementacją do C++0x?

Tak w ogóle mi się zresztą przypomniało, że miałem jakiś kod, który kompilował
się normalnie, a nie kompilował się w ConceptGCC.

> > Efekt jest taki, że zamiast skupić się w trakcie "dewelopmentu" na tym,
> > żeby przynajmniej działał optymistyczny scenariusz, a wszelki "error
> > handling" odłożyć na później, pierwsza rzecz, z którą muszę walczyć, żeby
> > mi się kompilował kod, to z zaprogramowaniem polityki obsługi błędnych
> > sytuacji przez wyjątki. Zazwyczaj efekt jest tego taki, że polityka
> > obsługi błędów jest odwalona na kolanie i zrobiona na łapu-capu, bo
> > chciałbym jak najszybciej, najtańszym kosztem otrzymać wreszcie coś, co
> > mogę sprawdzić, czy zechce działać.

> He, he. A kto potem wraca, aby zrobić refaktoring? Jak "działa" to lepiej
> pisać nowe ficzery niż poprawiać politykę obsługi blędów, czy nie ;-)? 

Nie nie, nie o takie rzeczy chodzi.

Mnie potrzeba napisania SZYBKO i przetestowania SZYBKO kodu, który obsługuje
optymistyczne scenariusze. Wiadomo, że NIE MOŻESZ przecież doprowadzić kodu do
release'u, jeśli nie dorobisz obsługi pesymistycznych scenariuszy i nie
zaprogramujesz error-handling - ale w C++ to jest rzecz, którą można odłożyć
na później. Od tego ewentualnie są code reviews, i testy jednostkowe, żeby
zgubione error handlingi wyłapać.

Ale w dzisiejszym podejściu do oprogramowania najważniejsze jest DEMO. Czyli
działająca aplikacja, którą można pokazać klientowi, że mniej więcej tak to ma
działać. Ale uprzedza się, że to jest na razie posklejane drutem i jakość
produkcyjną osiągnie dopiero za jakiś czas.

> > Nawet już są narzędzia, które to robią,

> Jakie?

Nie wiem, czy nie Klocwork - mówię to z głowy, więc może i nie ma. Wydawało mi
się, że widziałem zgłaszane problemy z unexpected exception, ale nie dam
głowy.

Zresztą, jeśli nie ma, to może chwilowo nie ma zapotrzebowania (właśnie przez
to, że nie ma tylu wyjątków :).

> > A co jeszcze ciekawsze, nie wszystkie wyjątki w Javie wymagają jawnej
> > obsługi. Czyli - ścisłe, ale nie do końca?

> Może zarzucić jakimś krótkim kodem? Z tego co pamiętam to rzutowania na zły
> typ powodują paskudne skutki (NullPointerException).

Każda metoda domyślnie przepuszcza RuntimeException (a jak ta, to wszystkie
jej pochodne, w tym NullPointerException). I nie ma sposobu, żeby jej tego
zabronić (chyba że obejmiesz trajem całe ciało metody). Wszelkie inne klasy
wyjątków muszą być jawnie obsługiwane lub jawnie propagowane.

>  
> > z pożywczego, czy bez, heisenbugi zdarzają się tak samo w C++, jak i w
> > Javie.

> {Do Sebastiana}

> A tak przyokazji według Wikipedii heisenbugi również są związane z "race
> conditions". Rozumiem, że np. w Lispie i Pythonie nie można zrobić "race
> condition", czy się mylę? 

:)

> Moim faworytem jest Logo to jest naprawdę bezpieczny język.

:)))))

> > No i słusznie. Ale tak się akurat składa, że Języki
> > Przemysłowo-Biznesowe(tm) są w większości chwytane przez tych, którzy o
> > powyższych sprawach nie mają bladego pojęcia.

> Tak, ale to jest złe.

No ale jeśli biznesowi takie badziewia wystarczają, to jego sprawa i nic w tym
temacie nie poradzisz.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"