<account_deleted>

Uważam, że użytkownicy tego forum staną się bardziej szczęśliwi, gdy to pseudo-programiści będą im "wciskać kit"... Zauważyłem tą tendencję już dawno, dlatego poprosiłem ULLISSES'a o skasowanie/usunięcie mojego konta parę lat temu, gdy zmieniłem nazwę użytkownika na "account_deleted". Jako że debile mają na tym forum przewagę, a moja obecność tutaj wydaje się być wysoce nieporządana - proszę o usunięcie mojego konta - prosiłem o to wcześniej ULLISESS'a (parę lat temu)- ale zignororwał moją prośbę... W związku z powyższym, ZPP mnie nie "przeraża" - oczekuję raczej spełnienia mojej prośby - w przeciwnym razie nie będę w stanie powstrzymać się od dementowania debilnych pseudo-porad pisanych przez ludzi z zerowym doświadczeniem, wspieranych przez wikipedię... Best Regards.

Wow! "warstwy abstrakcji": to pojęcie zarezerwowane dla "kumających" - Ty nie kumasz....nudzi misie... Pozdrawiam.

kretyn? - nic innego nie przychodzi mi na myśl... @Małpożer: Może być to dla Ciebie szokujące, ale sytuacja wygląda następująco: "The Open Group", czyli instytucja stojąca za specyfikacjami dla języka c/c++ "zaklepuje" wszystko za co im płacą - bo czują "bat na tyłku" w postaci nowszych specyfikacji dla OpenCL (Kronos) Poza tym: istnieją przynajmniej 2 podstawowe specyfikacje dla C++ : oficjalna i GNU C++ GNU ma "w d.u.p.i.e" corporacyjne specyfikacje: it just works. Pozdrawiam.

niekoniecznie o to chodziło... C kładzie na łopatki każdy program napisany w języku "wyższego" poziomu - powyższy link zawiera testy porównujące jak bardzo powolne są inne języki w odniesieniu do C ... szybszy jest tylko assembler ;) Dlaczego? Wszystkie języki wyższego poziomu powstały głównie w celu przeniesienia kosztów testowania/optymalizacji na klienta - który zazwyczaj jest głupi - jak mu winblows wolno działa to kupuje kolejnego/nowszego laptopa... ... Edit: hmm.. zero odpowiedzi? - spodziewałem się raczej ataku niedokształconych kretynów, twierdzących że przecież C nie jest językiem obiektowym... cóż... zatem niech ta kwestia pozostanie "nierozwiązana"... /Edit. Edit2: ...to może chociaż wytłumaczenie co to jest "vtable" - aka: po co C++ tworzy tablice wskaźników funkcji? - i jaka jest alternatywa? Nie spodziewam się żadnych wyjaśnień odnośnie SEH <Structured Exception Handling> - to by była "jazda" - ;) ...

Chociaż ogólnie jestem przeciwnikiem syfu znanego pod ogólną nazwą: "technologie web-owe", to jednak pierdzielisz waść bzdury o php: z dniem wprowadzenia wsparcia dla shared memory, PHP kopie tyłki wszystkim innym "technologiom" - czy raczej - porażkom technologicznym zaliczanym do "web-technology"W praktyce, wsparcie dla shared memory oznacza że nie trzeba tworzyć żadnych specjalizowanych modułów dla PHP - można gadać z jakimkolwiek programem, który jest w stanie wypluć "coś" do stdout - wszystko co działa w shell/bash. Mało tego, jak chcesz przesłać dane ze swojego "Hello world" do serwera na którym lata PHP, wystarczy stworzyć bufor tekstowy w shm. Rewelacja - niestety większość głąbów nadal uważa, że shared memory to sposób na "kaszowanie" pewnych danych... ...brak podstaw, again...

Nie prawda: (powtarzam): *niektóre* architektury oferują przyspieszenie przy porównaniach ze stałymi mieszczącymi się w zakresie zdefiniowanym dla "stałych natychmiastowych", który to zakres co prawda obejmuje zero ale też nie tylko zero - w związku z tym, stwierdzenie że "porównanie z zerem jest szybsze niż ze stałą" jest fałszywe.

Niestety Nie - "poniekąd" to jest mitologia... 1. Instrukcje asm sprawdzające relacje miedzy wartościami sprawdzają rejestr statusowy - i zawsze ich wykonanie zajmuje tyle samo cyki zegara - bo operacja sprowadza się do porównania masek bitowych. 2. Nie, zero też jest stałą - "porównanie z zerem" zajmuje tyle samo czasu co porównanie z jakąkolwiek inną stałą - różnica polega na tym, że większość architektur/platform oferuje funkcję zerowania rejestru, która często (nie zawsze) jest szybsza od załadowania stałej wartości z RAM. Większość architektur oferuje również "natychmiastowe stałe" <immediate costants> - czyli stałe zawarte w samej instrukicji CPU (z reguły 3-4 bity) -> porównanie z liczbami z zakresu 0..7 jest tak samo szybkie jak z zerem. Nie mam czasu ani ochoty tego dłużej ciągnąć, bo poziom jest zerowy... - co było do przewidzenia. Rozwiązanie: 1. wersja portowalna: /* returns non-zero in case of int32 overflow */ int chk_mult_overflow(int32_t aval, int32_t bval) { int64_t chk64; chk64 = aval; chk64 *= bval; aval = (chk64 <= 0x7FFFFFFF) ? 0 : 1; return aval; } Wyjaśnienie:Oczywiście można wykonywać obliczenia na liczbach 64bit na platformie 32bit - jak? - trzeba znać ASM żeby wiedzieć jak kompilator "to robi"... Dlaczego ten kod jest najbardziej optymalny: - najmniej skoków warunkowych, najmniej operacji porównywania liczb, a przy okazji najmniej instrukcji ASM. 2. Wersja nie-portowalna (nie-przenośna jak kto woli) *NIC - nie potrzeba pisać żadnego kodu* ;) To jest najlepsze w całym tym wątku: Ludzie bez znajomości zasad działania komputera od lat wypisują bzdury i tworzą wątki na temat jak sprawdzić przepełnienie zmiennej typu <int> - chociaż każdy istniejący na świecie procesor robi to sprzętowo w jednostce ALU, z zerowym kosztem w sencie opóźnienia wykonywania kodu - wystarczy tylko sprawdzić czy ALU wystawiło flagę "overflow" w rejestrze statusowym. Myślę że sprawa jest już jasna - znajomość assemblera i zasad działania komputera jest podstawą do świadomego tworzenia oprogramowania - bez tego, powstają "gnioty" - niskiej jakości i o niskiej wydajności... Pozdrawiam.

Zimno, ciekły azot, -273.15 ... 0x7FFFFFFF to jest po prostu maksymalna wartość jaką da się zapisać w 32-bitowej wersji typu <int> (bo <int> niekoniecznie musi być 32-bitowy). Nie ma tu większego znaczenia czy będziemy mnożyć czy sumować a i b - ale wiecej przykładów w sieci dotyczy operacji sumowania - więc chodziło o "zmylenie przeciwnika" - ostateczne rozwiązanie jest takie samo: chodzi po prostu o sprawdzanie czy doszło do przepełnienia zmiennej typu <int> - "integer overflow". Pozdrawiam.

No własnie ... Wikipedia ... - podaje, że test przesiewowy to pojęcie związane z medycyną - co tylko częściowo jest prawdą - to jest pojęcie z zakresu statystki... Niestety, poprzednie pytania testowe były niedoskonałe, ponieważ odpowiedzi są łatwe do znalezienia w sieci - co jednak nie przeszkodziło w uzyskaniu prawidłowych wyników - wręcz przeciwnie - pojawiła się wartość dodana w postaci przykładu pokazującego, że niektórzy nie odróżniają przypadku ogólnego od szczególnego ;) Interesuje mnie jeszcze jedna kwestia, mianowicie uzasadnienie/wykazanie dlaczego znajomość zasady działania/budowy komputerów i języka maszynowego (czyli podstawy) są niezbędne dla każdego, kto chce kiedyś nazywać się programistą... Proponuję więc quiz: (wstęp do podstaw, ale większość nawet nie zajarzy o co chodzi - powodem jest brak podstaw właśnie...) Jak optymalnie (minimum kodu wynikowego, maksymalna szybkość działania) sprawdzić prawdziwość nastepującego wyrażenia: (a * b) <= 0x7FFFFFFF gdzie: a,b są zmiennymi typu int (integer) i do dyspozycji mamy 32-bitowy procesor? Są tylko 2 *optymalne* rozwiązania tego problemu - jedno portowalne i jedno nie (ale za to ultra-szybkie ;) ). Rozwiązania da się znaleźć w sieci - ale żeby je znależć, najpierw trzeba wiedzieć o co chodzi w tym przykładzie. Z tego co sprawdziłem, większość rozwiązań w sieci jest błędna - co mam nadzieję wyeliminuje "cwaniaczków" i trolle... Panie "Małpożer": proponuję najpierw dać ze 2 dni forów dla mniej ogarniętych - potem śmiało może Pan zniszczyć mnie swoim profesjonalizmem i doświadczeniem ;) (swoją drogą jestem naprawdę ciekawy co z tego wyjdzie...) Pozdrawiam.

W zasadzie powiedziałem już wszystkto... Ale, jako że jest jeszcze trochę czasu do "wyrwania" - czy sformułowanie "test przesiewowy" <screening test> coś Panu mówi, czy "nie bardzo"? ...pytanie w sumie retoryczne - ale spróbujmy... Pozdrawiam.

Mój poprzedni post był niepotrzebny - szkoda czasu, bo testy już się skończyły - anyway - ludzie czytający ze zrozumienim będą w stanie zrozumieć o co chodzi, a tylko tacy są warci uwagi. Pozdrawiam.

Pytania były jasno sformułowane - zła dpowiedź to po prostu zła odpowiedź. Powyższy komentarz kompromiutuje Cię totalnie - tyle że jesteś zbyt głupi żeby to zrozumieć... Jesteś waść również zbyt głupi, żeby zrozumieć, że wspomniałem o języku assembler jako o "wstępie do podstaw" - oczywiście tylko w bardzo niewielu/extremalnych przypadkach używa się dzisiaj assemblera - ale też, znajomość języka maszynowego jest podstawą do zrozumienia "jak działa komputer" - o czym wspomniałem wcześniej... Rozumiem, że Twój debilny komentarz (odnośnie systemów "finansowych") został wykopany z google'a - i na tej podstawie postanowiłeś wyrazić samozadowolenie w postaci stwierdzenia, że "przecież też się pomyliłem" - tylko że sytuacja jest raczej kompletnie przeciwna - jesteś debilem do kwadratu, ponieważ właśnie libquadmath (o której wspomniałem) gwarantuje dokładność na poziomie conajmniej 10^-8, podczas gdy systemy bankowe używają co najwyżej dokładności na poziomie 10^-4. Spodziewam się kolejnego "ataku" spreparowanego przez debila ukrywającego się pod nickiem (aktualnie) - Małpożer - ale z drugiej strony, mam nadzieję że ludzie realnie zainteresowani nauką programowania są w stanie odróżnić forumowego trolla od gościa, który od ~15 lat programuje systemy produkcyjne... Pozdrawiam.

Nie odpisałeś w skrócie, tylko udzieliłeś błędnej odpowiedzi. "Dobrze wiedziałem, tylko mi się napisać nie chciało" ... i wszystko jasne ...

Bardzo by się to przydało, bo cała masa "speców" nie jarzy dlaczego sizeof(bool) jest niezdefiniowany... ...i jak obliczyć rozmiar dynamicznie alokowanej tablicy bitów... Naukę zaczyna się od podstaw - a w programowaniu komputerów podstawą jest zrozumienie "jak działa komputer" - tymczasem, większość "lolków" zaleca rozpoczęcie nauki od zainstalowania VisualStudio... Bez podstaw, zdolność pojmowania kończy się zazwyczaj na jednym 2 etapów: - aplikacje sterowane zdarzeniami - synchronizacja wątków, czyli rozwiązywanie problemów z wyścigami logicznymi przy dostępie do zasobów. ... albo wcześniej. (Oczywiście to jest hejt - nienawidzę głupoty.) Moja rada: zacząć od jakiegoś prostego assemblera i prostej architektury, np. 8-bitowy AVR, który ma masę ciekawych możliwości, dobre narzędzia, w pełni otwartą, powszechnie dostępną dokumentację + bardzo dobre wsparcie ze strony użytkowników.

Hmm, tak jak myślałem... słabiutko... Kontekst procesora, to nie jest "fragment programu", tylko: a) Stan procesora w danej chwili, gdzie poprzez "stan" rozumie się zbiór wartości wszystkich rejestrów, w szczególności wskaźnika stosu, wskaźnika instrukcji oraz rejestru statusowego. b) Kontekstem procesora nazywa się również strukturę przechowującą stan procesora. Struktura ta jest używana przez jądro systemu operacyjnego do przełączania zadań (procesów/wątków), co sprowadza się właśnie do "podmiany" stanu procesora. Ilość rdzeni czy procesorów nie ma tu nic do rzeczy. No... nie. Przerwanie jest również wyjątkiem. Mówiąc inaczej wyjątki można sklasyfikować jako sprzętowe (przerwania) i jako programowe, gdzie nadal nazywane są wyjątkami. Główna różnica polega na tym, że procedury obsługi przerwań są wykonywane w przestrzeni jądra systemu, natomiast wyjątki niekoniecznie (zazwyczaj w przestrzeni użytkownika). Stwierdzenie że "wyjątek jest obarczony dużym kosztem obsługi" świadczy że nie masz waść bladego pojęcia o czym mówisz. No nie, zdecydowanie nie chodzi o "sposób zapisu czesci ulamkowej na komputerach", tylko o ograniczenia wynikające ze stosowania standardu IEEE-754. Najbardziej znanym sposobem obejścia problemu dokładności jest rozszerzenie formatu IEEE-754 z 64 do 80-bitów, co w wielu przypadkach jest całkowicie wystarczające. Inne rozwiązania to np. "poczwórna" precyzja zapisu liczb (np: libquadmath: 128bit). Może zamiast rozwodzić się nad wyższością C# nad C++ albo nad tym, które IDE ładniej koloruje składnię, warto by jednak zacząć od (albo wrócić do) podstaw... Co to ma wspólnego z tematem? - wszystko.