-
141. Data: 2015-09-12 15:36:55
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: "AK" <n...@n...com>
Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:mt158b$rkv$1@node1.news.atman.pl...
>
> Dodawanie liczb calkowitych. A nie, czekaj, może być czy mam wymieniać cała
historię informatyki?
> Ponadto chcialbym tez zapytać jaka będzie na koniec nagroda, bo egzamin trudny,
wykladowca zrzeda
> a student przecietny.
Czyli nie masz pojecia, ale nie przeszkadza ci to "twierdzic" kompletncyh bzdur :)
>> W C++ piszę od 25 lat, a po przesiadce na PC-ty bylem
>> zmuszony napisac cala bibliotke standardowa w ASM 80x86
>
> Bibilteka standardowa to tylko mało istotny kawalek C++.
Hehehe :) Dobre ! "Standardowa" to malo istotny kawalek :) ?
Pikne !
>
>> aby moc _cokolwiek_ zdzialac na na nich, gdyz "super kompilatory"
>> tego super jezyka mialy pelno bykow skutkujacych praca programow
>> 24/24 (czyli 24min/2h).
>
> Bzdury. Wymień je. ja dla zachęty wymienie buga w - o ile pamiętam - visual 2003
który miał wyciek
> pamięci na std::vector oraz jakiś glitch z niewolaniem sie destruktora. No i co z
tego, to kiepski
> kompilator.
Przeciez opisalem napotkane bledy.
Taaa po 30 latach "rozwoju" blad w std::vector.
To rzeczywiscie super swiadczy o C++ :)
VS mowisz ?
Hm.. a taki gcc to niby lepsze ? :)
PS0: Czy std::/stl jest juz wreszcie thread-safe ?
PS1: Byly tylko dwa dobre kompilatory C++.
TopSpeed i MicroWay. Oba szlag trafil.
Sorry. jeszcze Watcom.
PS1: Dlaczego tak trudno wyprodukowac i utrzymac
na dobrym poziomie kompilator C++ ?
AK
---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus
-
142. Data: 2015-09-12 15:58:42
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: "AK" <n...@n...com>
Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:
>>> A język nazywał sie JAS co o dziwo pamiętam bez grzebania w necie, tym
>>> bardziej że książka o której wspomniałem zawierala opis i tego.
>> JAS ? Na Odrze ? :) /tak podejrzewalem:)/
>
> Przykro mi. Fakty zazwyczaj są głupie i nieoczekiwane.
Fakty sa takie, ze na Odrze serii 1300 assemblerem byl PLAN, a nie JAS.
JAS to Odra 1204, a to duzo starsza, _calkiem inna maszyna_ i do _calkiem innych
zastosowan_ (udana zreszta). Tylko nazwa jest zbiezna i glowny projektant/autor.
Proponuje jednak sie przemoc i zorientowac sie nieco w historii
polskiej informatyki.
http://www.itpedia.pl/index.php/Odra
http://www.itpedia.pl/index.php/Kamburelis_Thanasis
AK
---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus
-
143. Data: 2015-09-12 17:02:09
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: Sebastian Biały <h...@p...onet.pl>
On 2015-09-12 15:12, AK wrote:
>> Odra miała X kB ram. Pisuje na systemy oparte o uC które mają X kB ram
>> (wliczając w to multitasking w wywlaszczaniem). Wiem wszystko co musze
>> wiedzieć w temacie programowania niskopoziomowego aby mieć pojęcie o
>> pisaniu na małe systemy.
> Czlowieku ! Odra 1300 (zwlaszcza 1305) to _mainframe_. !
No i co z tego skoro w zasobach sprzetowych przypomina wiekszośc
współczesnych uC?
> Ze wszystkimi jego cechami (wirtualizacja zasobow).
Wirtualizacja zasobow może być sprzetowa, programowa, mieszana.
Wszystkie doskonale znamy i wszystkie używamy. Na uC też.
> Nie ma _nic wspolnego_ z zadnym programowaniem niskopoziomowym.
Programowanie niskopoziomowe to między innymi dbanie o allokowanie
pamięci w sposób kontrolowany, mieszczenie sie w ograniczonych zasobach,
zagadnienia RT przez co wybiera się języki dające kontrole itd. To *NIE*
wyklucza API, a wiele współczesnych uC daje szerokie możliwości wyboru
sporych systemów operacyjnych tworzących Twoje nikomu juz nie potrzebne
wirtualne sesje. Bo i na uC i w Twojej wirtualnej sesji mamy tyle samo
RAM i te same problemy. Zastanawianie się jak 100k danych wsadzić w 32k
nie rozwiązuje sie tylko dlatego że masz mainframe.
> Ba! Standardowo nie bylo tak w ogole dostepu do niskopoziomowych rzeczy.
No i? Głupi windows nie pozwala na dlubanie w rejestrach sprzetowych
inaczej niż przez driver. No i?
> Naprawde sobie poczytaj o GEORGE3
Czytałem lata temu. Taka ciekawostka. Myślę że wiele z tego obecnie nie
ma juz żadnego znaczenia - praktycznie wszystkie współczesne OSy mają
cechy bardziej użyteczne lub wręcz identyczne.
-
144. Data: 2015-09-12 17:04:07
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: Sebastian Biały <h...@p...onet.pl>
On 2015-09-12 15:58, AK wrote:
>>>> A język nazywał sie JAS co o dziwo pamiętam bez grzebania w necie, tym
>>>> bardziej że książka o której wspomniałem zawierala opis i tego.
>>> JAS ? Na Odrze ? :) /tak podejrzewalem:)/
>> Przykro mi. Fakty zazwyczaj są głupie i nieoczekiwane.
> Fakty sa takie, ze na Odrze serii 1300 assemblerem byl PLAN, a nie JAS.
Nic nie pisałes o 1300. Pisaleś o Odrach. Sorry, nastepnym razem
zastawiaj pułapki lepszej jakości.
> JAS to Odra 1204, a to duzo starsza, _calkiem inna maszyna_ i do
> _calkiem innych
> zastosowan_ (udana zreszta). Tylko nazwa jest zbiezna i glowny
> projektant/autor.
Co z pech że o tą nazwę "Odra" właśnie chodziło.
> Proponuje jednak sie przemoc i zorientowac sie nieco w historii
> polskiej informatyki.
Jesteś żalosny stosują ciągle ta samą metodę patrzenia z góry na kazdego
młodszego od siebie. Niech zgadne, były profesor, albo przynajmniej
doktrorant?
-
145. Data: 2015-09-12 17:18:42
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: Sebastian Biały <h...@p...onet.pl>
On 2015-09-12 14:43, AK wrote:
>>>> Oba narzedzia są najbardziej niskopoziome jak tylko się da bez utraty
>>>> kontroli. Spokojnie będa konkurować z dowolnie starymi językami i
>>>> produkowac kod o znakomitej jakości podobnie jak dowolne stare
>>>> narzedzia.
>>> Tak ? To poczytaj sobie o Simuli67.
>>> Moze Ci te dwa ++ z oczu opadna :)
>> Nie podaleś żadnego arumentu poza nazwą doskonale znanego języka.
> Nie masz pojecia o tym jezyku, a i doskonale znany nie jest.
Mam o nim pojęcie. Ostatni raz pisałem jakieś 15 lat temu, z czystej
ciekawości. Przyznam, że nie widzę żadnej znaczacej różnicy z C++ w
ideach. Róznica tylko w składni.
> Ogolnym argumentem przeciwko C++ w zastosowaniech ogolnych jest
> to, ze .. zwyczajnie i po prostu nie jest to jezyk do zastosowan ogolnych.
To nie świadczy o jego jakości i nikt tutaj nie stawia argumentu że C++
jest dobry na wszystko.
> Zostal zaprojektowany i stworzony do zupelnie innych celow.
Których nie wymieniasz.
> Do tych celow niezle (acz nie iodealnie) przystaje.
To znaczy że już się wycofujesz ze stwierdzeń że C++ jest kiepski do
wszystkiego? Szybko, wystarczylo tylko pare postów.
> Do zastosowan
> ogolnych nie,
> gdy jest jezykiem _bardzo niebezpiecznym_
Jest wiele języków bardzo niebezpiecznych jesli sa uzywane przez
ignorantów. Nawet Ada jest niebezpieczna jesli dać do ręki przygłupowi o
czym przekonali się francuzi od rakiet. No i co? C++ to lepszy
assembler. Nikt się po nim nie spodziewa bezpieczeństwa.
> , w dalszym ciagu niskopoziomowym
Nikt nie twierdzi inaczej.
W dodatku wymienileś dwie cechy ktore w wielu projektach mają pozytywne
znaczenie: nadaje się do pewnych zastosowań i można w nim zrobić więcej
rzeczy niebezpiecznych.
> i (zwlaszac po ostatnim "standardzie") _niezwykle skomplikowanym_.
Jest, no i? Programista C++ zazwyczaj ma większą świadomośc o *wszystkim*.
> Simula od poczatku zostala stworzona jako obiektowy jezyk ogolnego
> zastosowanie z ukierunkowaniem na obliczenia symulacyjne.
Efektem czego dzisiaj można ją znaleźć na smietniku historii a
obliczenia wykonuje się na klastrach używając w tym celu obleśnych
językow z gatunku plusowych albo nie daj Boże Pythona. Ale Ci ludzie sa
głupi. Zrobili coś znakomitego a ono nie chce być znakomite. Shit.
>> Simula67 jest martwa przemysłowo poza uczelniami gdzie jeszcze się
>> jej uczy.
>> I co z tego?
> To ze jest martwa to nie znaczy ze jest gorsza :)
Jest gorsza bo bezuzyteczna. Nie ma ani programistów, ani zaplecza w
postaci biblitek, ani kawałka istniejącego rozbudowanego systemu
napisanego w tym języku poza pielęgnowanymi nikomu nie potrzebnymi
kawalakmi zastosowań akademickich. Logo na ZX spectrum był
popularniejszy w latach 80tych. Jest wiele rewolucyjnych pomysłów, nawet
współczesnie jak Closure, które nazwyczajniej przegrają z dowolnym
badziewiem. Tak się to kręci.
> To ze gorsze (C++) wypiera lepsze aktuart mnie nie cieszy
> (tak jak nie ciesza mnie chinskie buty mimo, ze wyparly te porzadne
> normalne).
Ale kto tu jest zadowolony że c++ wygrywa rywalizację? To TY napisaleś
elaborat o młodym pokoleniu które uzywa bezmyslnie ++. Czyli dyskutujesz
sam ze swoimi kompleksami. ja nic nie piszę o lepszości C++ nad
czymkolwiek. Przynajmniej nie w tej dyskusji.
> Jesli Ciebie cieszy to Twoja rzecz (gustu), ale wysnuwanie wniosku, ze
> gdy jakies
> bedziewie wyparlo cos porzadnego to znaczy ze toto nowe jest inzyniersko
> i merytorycznie lepsze, jest gwaltem na logice i rzeczywistosci :)
I KTO tak twierdzi? Nikt. Znowu urojenia.
>> Pokazaleś jezyk który wygląda jak C++.
> Chlopie, przestan sie osmieszac totalnie ! :)
> Simula jest _totalnie niepodobna_ do C++.
Zupelnie niepodobna. Klasy i obiekty. Tam klasy i obiekty. Tu wirtualne
funckjie i tam wirtualne funkcje. Zupelnie niepodobna. Ani trochę.
> Poza ogolnym modelem obiektowosci (pojecie klasy i dziedziczenie -
> zreszta jednokrotne
> - i bardzo dobrze) _nic_ tych jezykow nie laczy.
Jak to poza? Przeciez to *PODSTAWOWA* cecha c++ - klasy i dziedziczenie.
Tobie chodzi o jakieś duperele składniowe? Przecież to bez znaczenia.
> Polecam zajecie sie nieco glebiej historia inzynierii j.programowania.
> Bez tego ani rusz.
Znowu nie możesz się powstrzymać od zrzędzenia. Jesli chcesz zbudowac
swoją pozycję to sugeruje robić to nie umniejszając wiedzy innych.
-
146. Data: 2015-09-12 17:31:28
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: "M.M." <m...@g...com>
On Thursday, September 10, 2015 at 11:20:33 PM UTC+2, AK wrote:
> Gdybys mial troche oleju w glowie niewypartego pzrez "nowoczesne"
> dzisiejsze narzedzia programistyczne typu C czy C++ to bys byc moze
> wydedukowal ze ograniczone zasoby zmuszaly o niebo bardziej do myslenia
> niz dzisiejsze 8GB pamieci.
> Skutkowalo to skupieniem sie na ALGORYTMICE czyli cos o czyms dzisiaj
> wielu adeptow wyzszych uczelni nie ma zielonego pojecia.
> Skutkowalo rozwiazaniami _malo czulymi_ na ograniczonosc zasobow
> hardwareowe (pamiec, dysk, tasma itp).
> Programy oparte o _solidne podstawy naukowe_ (czyli numerykę)
> byly o wiele bardziej uniwersalne, a rozwiazania nowoczesniejsze niz dzis,
> gdzie "para w gwizdek" idzie w jakis mlotek typu C++ WinAPi czy inne
> .NET-API czy JEE zamiast "zasilac" mozgownice wiedza merytoryczna
> i taka ktora _nigdy_ sie nie zestarzeje.
Już dawno się zestarzała. W 99.9% aplikacji inżynieria oprogramowania z
czasów Odry ma dziś żadnego zastosowania. Ta 0.1% może pozostaje aktualne
dla twórców systemów operacyjnych, systemów plików.
> > dadzą radę wydziargać gówniany, pełny ograniczeń, workaroundów i hackerskich
sztuczek system na
> > muzealnej maszynie tylko
>
> Nie udowadniaj ciagle ze nie masz _zielonego pojecia_ o Odrze.
> Na Odrze nie bylo zadnych sztuczek ani "hackerstwa"!.
> To wymysl PC-tow i dziesiejszych czasow (doby badziewncyh C i C++).
> Jedyny jezyk prog. ktorego na Odrze nie poznalem to odrowski assembler
> (wiesz chociaz jak on sie zwal znawco Odry ?)
> Po prostu nigdy mi nie byl potrzebny.
> Niestety zaraz po przejsciu na PC-ty misialem sie doskonale nauczyc assemblera
> 8x086 aby cokolwiek naprawde w miare pewnei dzialajacego moc zrobic,
> bo nawet C/C++ nie dawalo rady (bardziewne bugwiaste kompilatory) a jedyny
> porzadny soft developerski (rodzina kompilatorow NDP MicroWay) wyp..lal sie
> na specjalnie kupionym 386DX z 4MB pamieci juz przy przekraczaniu 1MB
> bo Intel sobie popelnil blad w core procesora skutkujacego wypadem
> w trybie protected przy przelaczaniu blokow pamieci - do ktorego to bledu
> oczywiscie sie nie przyznal, a procesorow (a wtedy kosztowaly "nieco") nie
wymienil.
> Na Odrze (czyli starym dobrym angielskim ICL1900) tego typu rzeczy _nigdy_
> mi sie sie nie zdarzyly.
> Poczytaj sobie o ICL1900, poczytaj sobie o os-sie GEORGE3 (zarzadzaniu
> w nim pamiecia, wielozadaniowoscia, wirtualizacja nie tylko pamieci ale np.
emulacja
> nieistniejacych/niezamontowanych urzadzen zewn. itp itd) zanim cokolwiek jeszcze o
> Odrze, czy jej sofcie pisniesz.
>
> > Do Odry mam szacunek. Do ludzi gloryfikujących jej zastosowanie w PKP do XXI w
nie mam ani grosza
> > szacunku.
>
> Hehe :) Znow zenade uprawiasz. Tak sie sklada ze studiowalem "obok" wydzialu
> transportu Pol Slaskiej i dobrze wiem (a moze nawet bardziej niz dobrze, bo sam
> w nieco inny sposob;) w niej uczestniczylem..) jaka to "glupote softwareowa"
> naukowcy na tym wydziele tworzyli. (niektorzy z nich to przedwojenni Lwowiacy -
> co nie przeszkadzalo im nauczyc sie programowac w wieku dobrze 50+,
> ba!, wrecz tworzyc metody numeryczne do rozwiazac konkretnych problemow
> wystepujacych w transporcie - a to bardzo plodna dziedzina jesli chodzi o numeryke
> i ogolnie informatyke. Np.prof Ludwik Miller - poczytaj sobie o nim).
>
> Powiem krotko.
> To dzieki takim "fachowcom" dziesiejsza polska informatyka w swej przewazajacej
> masie to niestety glownie"ambitny" outsourcing, czytaj: "rozwoj" ktorego nie chca
tchnac
> ani Amerykanie ani Anglicy ani Niemcy czyli w wiekszosci zwyczajne
> g.. programistyczne, w wiekszosci "outsourcingowe" bug-ownice na zasadzie
> kto szybciej i wiecej poprawek w w Jakiejs Jirze albo bugzilli "odfajkuje".
>
> AK
>
>
> ---
> Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie
antywirusowe Avast.
> https://www.avast.com/antivirus
-
147. Data: 2015-09-12 17:39:39
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: Sebastian Biały <h...@p...onet.pl>
On 2015-09-12 15:08, AK wrote:
>>> PS: Moze i jest dzis w srodowisku C++ bardzo wielu dobrych w
>>> numeryce/algorytmice
>>> ludzi, ale _napewno_ Ty do nich nie nalezysz. nie masz
>>> _najmniejszego pojecia_
>>> o rzeczach ktore krytykujesz/dyskredytujesz.
>> A co konkretnie krytykuje / dyskredytuje? I czy możesz na podstawie
>> tych kilku postów oceniacz czlowieka o którym nic niewiedz poza tym że
>> nie ma odcisków na dupie od stołka przy Odrze?
> Moge. Typowe zachowawcze wstecznictwo polegajace na samoograniczeniu
> sie do jednego jezyka/technologii (zwykle C/C++)
Kto się samogranicza do jednego języka. Znowu masz urojenia? Znam kilka
językow biegle, kilanascie mniej biegle. Chyba ze wszystkich
paradygmatów. Czy mozesz w kilku zdaniach opisać jakim magicznym
sposobem dochodzisz do takich wniosków?
, nastepnie zalozeniu
> klapek
> aby nic nie widziec na boki ani w tyl (historia to jednak baardzo
> przydatna nauka:)
Zarzucasz mi że nie znam historii? Na moim biurku leżą C64, ZX Spectrum,
Atari 65XE. Wszystkie gotowe do odpalenia, na wszystkich pisałem od asm
przez Logo po Action! (zgadnij co to). Odry na biurku nie mam bo się nie
mieści i ciezko znaleźć a ponadto za moich nastoletnich czasów
rozlutowałem jedną na częsci. 20% mojej bibliteki to ksiązki starsze ode
mnie. Jak *ŚMIESZ* zarzucać tak chamskie rzeczy osobie o której nic nie
wiesz?
> i atakowaniu wszystkiego (nawet tego o czym sie ma _zielonego pojecia_,
> vide Odra)
NIKT NIE ATAKUJE ODRY w tym watku. Masz problem z rozumieniem intensji
piszących. Tutaj się atakowało fakt, że legacy systemy powodują problemy
w normalnym życiu (jak Elixir). Natomiast od kilku postów jakiś AK
obraża mnie i kilku innych młodszych od siebie w kółko zarzucając brak
wiedzy choć sam nie prezentuje żadnych konkretów.
> dla zasady (czyli utrzymaniu "doskonalosci" obrazu swego bozka:)
> Slowem: "Ayatollahostwo C/C++" czyli czysty fanatyzm :)
Masz urojenia.
> PS: Osobiscie znam/poznalem (w wiekszosci produkcyjnie) dobrze ponad 10
> jezykow
> programowania, a Ty ?
Pisze w kilku zawodowo. Zaczynalem pisanie w wieku lat 9 od pierwszego
dostepnego komputera - ZX Spectrum. Był to Basic i zaraz potem assebler
Z80 i 6502. Przepraszam świat że ośmieliłem się urodzić jak już nie było
dostepu do Odry. Po drodze pisałem na wszystkich domowych maszynach we
wszystkich językach jakie znalazłem, wiele z nich było historycznie
istotnych. Obecnie zawodowo piszę w C++, Javie, asm paru różnych
architektur. Nie są mi obce Lisp, Prolog. Programuje funkcyjnie,
logicznie, strukturalnie i obiektowo w *JEDNEJ* aplikacji. Po drodze
było jak u kazdego Pascal, Delphi i znam od groma śmieci z gatunku Bash,
Python. Jedynie Perla nienawidze ideologicznie. Czy ta wyliczanka jest
wystarczająca, czy dalej spodziewać się mam obrzucania gównem z gatunku
"ba ja się znam lepsiejsze języki"?
Pozwój że teraz przewidzę ciąg dalszy: za chwile urojenia w Twojej
głowie zaczną zakładać że pewnie pisuje jakieś pierdoły i tak naprawdę
moja znajomośc jakiegokolwiek języka i algorytmu jest zerowa a nazwy
nieznanych mi językow znalazłem na wiki. Zaczniesz znowu zrzędzić. Jesli
tak się stanie - chyba zakończe dyskusję.
W mlodosci (a i teraz jeszcze:) z luboscia
> rzucalem sie na
> kazdy nowy/inny i naprawde nie dla skladni czy innych pierdolek,
> ale ze zwyklej
> nieskazonej niczym _checi poszerzenia wiedzy/"horyzontow"_.
To fascynujace. I zakładasz że moje pokolenie nie mialo prawa rzucać sie
na kążdy znaleziony jezyk programowania? W celu poszerzania horyzontów?
Rzucało się. Pochodzę z pokolenia które w wieku nastu lat jedynym dostęp
do informatyki miało przez 8-bitowe maszyny. Nie masz prawa z tej
perspektywy oceniać umiejetności kogokolwiek. Nie znasz ich.
> Dlatego wlasnie mam wieksze prawo niz Ty krytykowac C/C++
Masz prawo krytykowac. Ale na razie nie masz żadnych argumentów.
Żadnych. Pusto i wiatr wieje. I jakieś historyczne języki co mam sobie
je niby zobaczyć choć w większości miałem okazję pisać.
Twoja dyskusja stoi na stanowisku że starsi wiedzą więcej. Niestety to
błedne zalożenie, a obecnie znajomość Simuli nie powoduje że stosujesz
lepsze algorytmy. Znajmomość Lispa i Prologa poszerza horyzont. Simuli
raczej nie. Sorry. Pudło.
-
148. Data: 2015-09-12 17:41:49
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: "AK" <n...@n...com>
Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:
>> Czlowieku ! Odra 1300 (zwlaszcza 1305) to _mainframe_. !
>
> No i co z tego skoro w zasobach sprzetowych przypomina wiekszośc współczesnych uC?
To z tego, ze na tych "ograniczonych zespolach sprzetowych"
dzialaly calkiem spore systemy (w tym np. teletransmisyjne i to grubo przed
doba internetu). No ale wtedy nie bylo takich fachowcow jak ty wiec nie
wiedzili(smy:) ze sie nie da ;))
>> Nie ma _nic wspolnego_ z zadnym programowaniem niskopoziomowym.
>
> Programowanie niskopoziomowe to między innymi dbanie o allokowanie pamięci w sposób
kontrolowany,
I niby takie "dlubanie" to cecha Odry ?
Chlopie, napraewde bzdurzysz.
Ja nawet w czasach Odry pojecia stosu nie znalem (nie liczac sortowania stogowego;)
a co dopiero o jakims" grzebaniu". Naprawde przestan bzdurzyc o rzeczach
ktorych nie dotknales i nie masz o nich zielonego pojecia. Tworzysz jakies chore
mity.
Pamiec rezerwolo sie tak:
begin
integer array a[lbound_expression: ubound_expression, ...];
end
wsio. To kompilator decydowal gdzie/jak ja skladowac badz "zwirtualizowac".
> Zastanawianie się jak 100k danych wsadzić w 32k nie rozwiązuje sie tylko dlatego że
masz
> mainframe.
A zastanawiaj sie dalej.
Za mnie robil to kompilator (ale nie niskopoziomowego C++:)
>> Ba! Standardowo nie bylo tak w ogole dostepu do niskopoziomowych rzeczy.
>
> No i? Głupi windows nie pozwala na dlubanie w rejestrach sprzetowych inaczej niż
przez driver. No
> i?
Czlowieku, czy Ty wiesz czym sie rozni w pelni separowalne zadanie
(a niekiedy i caly system operacyjny uruchamiany wirtualnie)
od tego modelu wspolbieznosci i ochrony pamieci ktory jest znany
z rodziny 8x86 ?
>> Naprawde sobie poczytaj o GEORGE3
>
> Czytałem lata temu. Taka ciekawostka. Myślę że wiele z tego obecnie nie ma juz
żadnego znaczenia -
> praktycznie wszystkie współczesne OSy mają cechy bardziej użyteczne lub wręcz
identyczne.
Tak ?.
1. _Nic_ nie przeczytales o GEORGE3.
2. Nie. Wspoplczesne os-sy PCowe nie maja. Przynajmniej kilku z nich.
AK
---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus
-
149. Data: 2015-09-12 17:54:45
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: Sebastian Biały <h...@p...onet.pl>
On 2015-09-12 15:36, AK wrote:
>> Dodawanie liczb calkowitych. A nie, czekaj, może być czy mam wymieniać
>> cała historię informatyki? Ponadto chcialbym tez zapytać jaka będzie
>> na koniec nagroda, bo egzamin trudny, wykladowca zrzeda a student
>> przecietny.
> Czyli nie masz pojecia, ale nie przeszkadza ci to "twierdzic"
> kompletncyh bzdur :)
Nie, najwyczajniej w świecie pytanie było tak głupie że nie ma na nie
jak odpowiedzieć. A jakie algorytmy udostepniał Atari OS w wersji BASCIa
C? I czy to ważne?
>>> W C++ piszę od 25 lat, a po przesiadce na PC-ty bylem
>>> zmuszony napisac cala bibliotke standardowa w ASM 80x86
>> Bibilteka standardowa to tylko mało istotny kawalek C++.
> Hehehe :) Dobre ! "Standardowa" to malo istotny kawalek :) ?
> Pikne !
Owszem. Przypominam że stl to rzecz której się np. Nie używa np. na uC
mimo używania tam C++ z powodu braku heapu. STL ma tez kilka kłopotów
które powodują że wiele biblitek dostarcza własne implementacje
wszystkiego na zastepstwo (Qt), samą zaś przepisano 10 razy (np.
stlport) bo dostarczane z kompilatorami były kiepskie. Sorry, stl nie
stanowi o *języku*. To był znakomity pomysł w kilku miejscach i żałosna
implementacja w kilku innych. Co zrobić. Takie Delphi dorobiło się
czegokolwiek z zakresu hashmap o wiele za późno, więc należy się cieszyć
że coś w ogóle było.
> Taaa po 30 latach "rozwoju" blad w std::vector.
Bibliteki stl zawieraja błedy. Inne też. Suprise.
> To rzeczywiscie super swiadczy o C++ :)
Błędy w kompilatorze nie świadczą o języku. To nie był błąd standardu.
> VS mowisz ?
> Hm.. a taki gcc to niby lepsze ? :)
Ma inny stl. Ma inne bugi. Z faktu że kompilator X jest kiepski nie
wynika że kompilator Y jest dobry. Sorry, logika tak nie działa.
Pewchowo piszę ten sam kod na oba. Obecnie różnią się bardzo niewiele
pod względem wynikowego kodu i pokrycia standardu.
> PS0: Czy std::/stl jest juz wreszcie thread-safe ?
Czy standard C++ kiedy powstawało stl mówił coś o "thread"? Więc sobie
odpowiedz. I zastanów się również po co *wszystkim* thread safe. W C++
nic nie dostaniesz w promocji. To czasem wada a czasem zaleta.
> PS1: Byly tylko dwa dobre kompilatory C++.
> TopSpeed i MicroWay. Oba szlag trafil.
> Sorry. jeszcze Watcom.
Jest wiele dobrych. Jesli chcesz coś interesującego to proponuje
zapoznać sie z clang. Głównie dlatego że zdołano w kilka lat napisac
produkcyjny kompilator konkurujący z vc i gcc. I kod nie jest pisany
przez ignorantów, co jest dość niespotykane.
> PS1: Dlaczego tak trudno wyprodukowac i utrzymac
> na dobrym poziomie kompilator C++ ?
Bo standard jest niesłychanie skomplikowany. Aczkolwiek przykład clang
pokazał, że niestety również dlatego że projekty kompilatorów
zatrudniają dużo corncobów[1]. Głównie takich którzy zamiast zalet
jakiejs technologii widzą tylko same wady i ciągle żyją w latach 60-tych.
[1] https://sourcemaking.com/antipatterns/corncob
-
150. Data: 2015-09-12 18:10:28
Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Od: Sebastian Biały <h...@p...onet.pl>
On 2015-09-12 17:41, AK wrote:
>>> Czlowieku ! Odra 1300 (zwlaszcza 1305) to _mainframe_. !
>> No i co z tego skoro w zasobach sprzetowych przypomina wiekszośc
>> współczesnych uC?
> To z tego, ze na tych "ograniczonych zespolach sprzetowych"
> dzialaly calkiem spore systemy (w tym np. teletransmisyjne i to grubo przed
> doba internetu). No ale wtedy nie bylo takich fachowcow jak ty wiec nie
> wiedzili(smy:) ze sie nie da ;))
KTO POWIEDZIAŁ ŻĘ SIĘ CZEWGOŚ NIE DA? Znowu urojenia? Współczesne uC
mają takie same zasoby sprzetowe jak Odry. Wspóczesne uC mają systemy
operacyjne z wieloma cechami z dużych systemów. To podobne środowiska,
wiele uC jest w stanie pociągnąć gigabajty ram i gigahz.
>>> Nie ma _nic wspolnego_ z zadnym programowaniem niskopoziomowym.
>> Programowanie niskopoziomowe to między innymi dbanie o allokowanie
>> pamięci w sposób kontrolowany,
> I niby takie "dlubanie" to cecha Odry ?
Każdego systemu który musi być pisany kompromisowo ze względu na
ograniczone zasoby.
> Chlopie, napraewde bzdurzysz.
> Ja nawet w czasach Odry pojecia stosu nie znalem (nie liczac sortowania
> stogowego;)
Musiałeś znać. Inaczej miałeś klopoty przy implementacji byle czego. RAM
i bębny nie są z gumy. Wtedy nie były i dzisiaj ich odpowiedniki nie są.
> a co dopiero o jakims" grzebaniu". Naprawde przestan bzdurzyc o rzeczach
> ktorych nie dotknales i nie masz o nich zielonego pojecia. Tworzysz
> jakies chore mity.
> Pamiec rezerwolo sie tak:
>
> begin
> integer array a[lbound_expression: ubound_expression, ...];
>
> end
>
> wsio. To kompilator decydowal gdzie/jak ja skladowac badz "zwirtualizowac".
Nie da się tak pisać bez kompromisow. Jęsli system to wyrzucił na bęben
z powodu braku ram to jestes w dupie z wydajnością. Magiczna cecha Odry
ktora powodowała że pamięc była z gumy jest nieprawdziwa. Tylko się nie
rozpłacz.
>> Zastanawianie się jak 100k danych wsadzić w 32k nie rozwiązuje sie
>> tylko dlatego że masz mainframe.
> A zastanawiaj sie dalej.
> Za mnie robil to kompilator (ale nie niskopoziomowego C++:)
Naprawde nie widzisz problemu że twoje dane lądują na urzadzeniu które
jest setki razy wolniejsze bo się nie mieści w ram?
Masz kompromis:
a) albo to 100k wrzucisz w "coś" i bedzie dzialać setki razy mniej wydajnie
albo
b) zmniejszysz nazwiska do 10 znakow i upchniesz w 32k
Tak czy inaczej kompromis. A wątek ten jest o tym wlaśnie: gro systemów
uzywanych w administracji publicznej posiada tak kiepskie cechy
(wydajnośc, skalowalnośc itd) że przyczyna być może jest w "lepsze jest
wrogiem dobrego, pracujemy dalej na IBM360".
PS. Każdy duzy współczesny OS potrafi to samo, czyli dac pełna
przestrzeń adresową dla procesu magicznie swapując ją w tle. Gdzie tu
jakaś zaleta mainframe?
>>> Ba! Standardowo nie bylo tak w ogole dostepu do niskopoziomowych rzeczy.
>> No i? Głupi windows nie pozwala na dlubanie w rejestrach sprzetowych
>> inaczej niż przez driver. No i?
> Czlowieku, czy Ty wiesz czym sie rozni w pelni separowalne zadanie
> (a niekiedy i caly system operacyjny uruchamiany wirtualnie)
> od tego modelu wspolbieznosci i ochrony pamieci ktory jest znany
> z rodziny 8x86 ?
Obecnie niczym. Procesy na x86 w win i lin są separowane w sposób
doskonały. Maszyny wirtualne pracujące na x86 znamy od bardzo dawna.
Obecnie (od 5 lat przynajmniej) wszystkie procesory x86 wirtualizuja na
poziomie sprzetowym. Zakładasz że ludzie sa tak głupi że nie wiedzą jak
to działa? Ludzie tego *używają*. Wyjrzyj przez okno. Lub porzedstaw
cechy które są niezbedne do implementacji w systemach, ba jak widac
reszta świata to idioci i czegoś nie zrobili.
>>> Naprawde sobie poczytaj o GEORGE3
>> Czytałem lata temu. Taka ciekawostka. Myślę że wiele z tego obecnie
>> nie ma juz żadnego znaczenia - praktycznie wszystkie współczesne OSy
>> mają cechy bardziej użyteczne lub wręcz identyczne.
> Tak ?.
> 1. _Nic_ nie przeczytales o GEORGE3.
> 2. Nie. Wspoplczesne os-sy PCowe nie maja. Przynajmniej kilku z nich.
Jakie to istotne cechy których nie mają? Jestem (a może "jesteśmy" -
reszta znudzona tym flejmem) ciekawy.