--"C# je jednoznačně bezpečnější, než C/C++. Jazyk bez pointerů je typicky bezpečnější, než jazyk s nimi."
Typicky žádný jazyk bez pointerů neexistuje. Pointery (ukazatele - v podstatě nic jiného než adresa hodnoty/oběktu v paměti) jsou minimálně používané skrytě programovacím jazykem, popřípadně přímo v binárním kódu po kompilaci - jak už tady někdo upozornil.
Pokud bych potřeboval z nějakého důvodu skrýt adresu nějaké proměné, či zacházet s takovýmto pointerem "bezpečně" v kontextu kódu C++, existuje hned několik možností jak to provést, včetně tzv. inteligentních ukazatelů (díky nímž se mimochodem dá velice jednoduše implementovat podobná správa paměti, jakou zajišťuje např. tzv. garbage collector), které všechny potencionálně nebezpečné operace schovají ve své implementaci a navíc se zhlediska kódu chovají jako klasické ukazatele (popř. i reference). Většinou jsou implementovány jako tzv generické třídy, takže je lze typově bezpečně a plně přispůsobit dané situaci, a žádným způsobem se neprojevý (či jen velmi minimálně) na výsledném výkonu či oběmu projektu. Nemusím je ani implementovat, protože to už udělala spousta lidí předemnou (už jsem tu zmiňoval loki, nebo boost - co mě momentálně napadá a které sám používám, avšak existují i jiné). Obdobně je to i s jinými features jiných jazyků a C++. (Mimochodem všichni takový flameři zapomínají ještě dodat, že nebýt C a obvzláště C++ - jeho možnosti tvorby velmi sofistikovaných abstrakcí, kde se bez vlastní zprávy prostředků a pointerů neobejdete, žádný C#, java, atpd. by asi ani neexistoval)
--"Jaký jazyk je lepší, to záleží na kontextu."
To je jen účelové překroucení, nemá ani smysl se k tomu nadále vyjadřovat.
--"C# se pochopitelně uchytilo nejvíc ve Windows, protože je to primární jazyk pro .NET Framework. S chybným SW to nemá souvislost."
Zase si protiřečíte. Psal jste (volně řečeno, takže si laskavě odpusťte vaše slovíčkaření), že většinové nasazení C# by mělo - díky jeho konstrukci - vést k potencionálně bezpečnému kódu aplikací a eliminovat důsledky chyb omylů programátorů. Pokud (díky platformě .NET ) byl tento jazyk tolik rozšířen převážně na Windows, pokládám otázku proč se toto neprojevilo a naopak se zdá, že chybovost aplikací (včetně vámi zmiňovaných zákeřných, nebo neidentifikovatelných chyb) je stále stejná? Máte samozřejmě pravdu - s použitým jazykem to nesouvisí, jen mi připadá, že jste ochoten to připustit jen tehdy, když se vám to hodí do krámu. Takže ano, ale pak kdo/co je na vině?
Moje odpověď zní : Chyby programátorů, nerespektování pravidel a zásad platných v daném systému a jazyce, benevolentnost systému jako takového, hloupá a najivní představa, že se o něco postará systém/nebo někdo jiný (říká se tomu různě: nezodpovědnost, důvěřivost, nebo taky blbost - typická to lidská vlastnost).
--"Nemusím dohledávat analýzy, abych vám řekl, že buffer overflow chyby..."
IMHO za tuto chybu může vždy nepozornost či omyl programátora - ne jazyk. Viz výše. Mimochodem, od toho jsou v C++ STL konteinery (a nejen ty), které nabízejí bezpečnější a sofistikovanější způsob práce s datovými poly. Každý programátor, který přesto použije klasická pole moc dobře ví, že C++ nekontroluje jejich přetečení/podtečení. Tím pádem bere odpovědnost za ně na sebe (někde jsem slyšel, že neznalost zákona neomlouvá). Prostě je to stejné jako s těmi pointery, jen je jednoduší to svést na špatný jazyk - jak jsem říkal IT-Alibizmus.
--"Nemyslím si, že by použití managed prostředí ubíralo možnost reagovat na neočekávané události...."
Já ano - nepochopil jste to. Už jen proto, že v C++ nejsem omezen strojem, který rádoby myslí za mě a proto mohu reagovat na různé požadavky (z hlediska výkonu výsledného projektu, zprávy systémových prostředků, hardvarové platformy a specifik cílového stroje, atpd...) mnohem flexibelněji - aniž by mi do toho někdo kafral. Je zcela na mém výběru a uvážení zda využiji již existující řešení, nebo implementuji své vlastní a převezmu za něj plnou zodpovědnost. (A řek bych dal krk za to, že tohle je ten hlavní důvod proč se některým lidem C++ nelibí a radši se vzdají těchto možnosti, a mnohem výší míry flexibility při návrhu a implementace projektu... Že jsem se trefil? ;) ).
--"Faktem je, že to většina programátorů nedělá důsledně, takže programy na neočekávané věci (třeba neočekávané vstupy) reagují v lepším případě core dumpem s chybou "nelze zapsat adresu 0x0c" apod. V horším (ale přesto častém) případě reagují tichým přepsáním nějaké části vlastní paměti, následným zcela záhadným chováním, nebo dokonce spuštěním nežádoucího kódu."
Někde jste sám psal, že prý Linux nepoužíváte a nijak podrobně nesledujete. Můžete mi tedy říci, kde berete tu drzost tady šířit FUDY o tom, že Linuxové aplikace padají (a hlavně jak?). Krom svých projektů (kde jsem udělala chybu já sám) a testů windowsáckých aplikací pod Wine jsem už dlouho neviděl pád nějaké stable aplikace (Nepadají mi kupodivu ani moje vlastní odladěné aplikace). A to že já jim dávám někdy pěkně zabrat. Takže zase tvrdíte věci, které nemáte ověřeny?
--"To, co nabízíte jako řešení vy, je jen pokračování současných problémů..."
Do jisté míry ano. Jenže já bohužel jiné řešení nevidím. Všechno od polovodiče po OS (včetně programovacích jazyků a programů) dělají lidé. A dokud se nezmění lidé, nezmění se ani nynější situace a ani její řešení (pře sebe lépe navržený kompilátor). Já preferuji C++ a to se asi hned tak nezmění (přesto, že jazyků znám řadu - minimálně v základech, programováním si přividělávám opravdu jen příležitostně, ale programy a scripty píšu dost často) Za vnucováním jedné jediné pravdy (o tom jsem koneckonců už říkal) vidím pouze fanatickou zaslepenost, nebo prasácké finanční zájmy...
ČLÁNKY DO MAILU