On Feb 1, 3:46 pm, "R. P." <r...@w...pl> wrote:
> W dniu 2011-02-01 16:44, Andrzej Jarzabek pisze:
>
> > Nieprawda. "Chytre rzuty" nie wnosz nic w kwestii wydajno ci.
>
> Pozawalaj np. omin tablic funkcji wirtualnych, kt ra daje narzut
> czasowy.

Podasz może jakiś przykład, gdzie dzięki "chytrym rzutom" w C udaje
się napisać coś, co np. w C++ możnaby osiągnąć wyłącznie przy
dodatkowym narzucie ze strony tablicy funkcji wirtualnych?

do góry

W dniu 2011-02-01 16:51, Stachu 'Dozzie' K. pisze:
> On 2011-02-01, R. P.<r...@w...pl> wrote:
>> W dniu 2011-02-01 16:46, Andrzej Jarzabek pisze:
>>> On Feb 1, 2:42 pm, "R. P."<r...@w...pl> wrote:
>>>> W dniu 2011-02-01 15:36, A.L. pisze:
>>>>
>>>> Ale to już się stało i się nie odstanie. Stworzysz teraz system
>>>> operacyjny od nowa, w czymś innym niż w C, który będzie mógł być
>>>> konkurencyjny z Unixem, Linuxem czy Windowsem?
>>>
>>> A stworzysz od nowa system operacyjny w C, który będzie mógł byc
>>> konkurencyjny z Unixem, Linuxem czy Windowsem?
>>
>> Nie, ale można rozwijać te systemy tak, żeby jeszcze bardziej umacniać
>> ich potęgę.
>
> #define potęga
>

Popularność, użyteczność, mnogość oprogramowania na nie.

do góry

On 2011-02-01, R. P. <r...@w...pl> wrote:
>>> Chciałem jedynie wykazać, że jest ważnym punktem w historii informatyki.
>>> Bardzo ważnym.
>>
>> A potem wtrąciłeś, że jest potężnym i wysokopoziomowym językiem. Przy
>> czym ani tego że jest potężnym językiem, ani że wysokopoziomowym, nie
>> raczyłeś uzasadnić.
>
> Wysokopoziomowym strukturalnym. A to drobna różnica.

W argumentacji? Żadna. Wysokopoziomowym strukturalnym jest Matlab.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2011-02-01 16:50, Stachu 'Dozzie' K. pisze:
> On 2011-02-01, R. P.<r...@w...pl> wrote:
>>>>> Wieksosc neisczesc spowodowana jest tym ze "programy systemowe"
>>>>> napisane sa w C z "chytrymi rzutami"
>>>>
>>>> Zgadza się. Są źródłem błędów. Ale dzięki nim pisane oprogramowanie może
>>>> też być bardzo wydajne... O tym nie wspominasz.
>>>
>>> Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
>>> bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
>>> (asymptotycznej).
>>>
>>> Tak, w jądrze systemu operacyjnego też.
>>>
>>
>> Gadasz jak typowy teoretyk.
>
> Gadasz jak typowy pożal-się-Boże-praktyk bez przygotowania
> teoretycznego.

Kulturą wypowiedzi to ty nie grzeszysz. Nie wiesz kim jestem i jakie mam
przygotowanie teoretyczne. A ja nie mam obowiązku tobie się z tego tłuaczyć.

>> Ten sam algorytm o złożoności np. O(n)
>> napisany w języku wysokiego poziomu (np. w C++) może być kilkukrotnie
>> przyspieszony, gdy się go przepisze na C.
>
> Ten sam algorytm o złożoności O(n) napisany w C może być kilkukrotnie
> przyspieszony, gdy przepisze się go w języku wyższego poziomu. Bo
> użyjesz już gotowych i efektywnych struktur danych z języka wyższego
> poziomu, zamiast paprać w C. I bo kompilator lepiej zoptymalizuje kod
> pośredni niż ma to miejsce dla C.

Taka np. klasa string w C++ na pewno właściwą strukturą nie jest, bo to
samo napisane w interpretowanym awk (ten sam algorytm przetwarzania
tekstu) potrafi zadziałać 3x szybciej... Podobnie wiele innych klas w
std jest w c++ spapranych. Chociażby stream'y też są wydajnościowo
skopane i w C zawsze wychodzi szybciej.

do góry

W dniu 2011-02-01 16:53, Andrzej Jarzabek pisze:
> On Feb 1, 3:46 pm, "R. P."<r...@w...pl> wrote:
>> W dniu 2011-02-01 16:44, Andrzej Jarzabek pisze:
>>
>>> Nieprawda. "Chytre rzuty" nie wnosz nic w kwestii wydajno ci.
>>
>> Pozawalaj np. omin tablic funkcji wirtualnych, kt ra daje narzut
>> czasowy.
>
> Podasz może jakiś przykład, gdzie dzięki "chytrym rzutom" w C udaje
> się napisać coś, co np. w C++ możnaby osiągnąć wyłącznie przy
> dodatkowym narzucie ze strony tablicy funkcji wirtualnych?

Z założenia C++ jest nadzbiorem C (choć nie do końca), więc to co
zrobisz w C możesz również zrobić w C++. Po prostu w C++ robisz
hierarchię klas (tak jest ładnie) a w C pojęcia klasy nie masz, odpada
więc dziedziczenie itp. Nie ma więc w ogóle mowy o "robieniu tego
samego" celem symulacji polimorficznych wywołań, bo inaczej projektuje
się struktury.

do góry

W dniu 2011-02-01 16:54, Stachu 'Dozzie' K. pisze:
> On 2011-02-01, R. P.<r...@w...pl> wrote:
>>>> Chciałem jedynie wykazać, że jest ważnym punktem w historii informatyki.
>>>> Bardzo ważnym.
>>>
>>> A potem wtrąciłeś, że jest potężnym i wysokopoziomowym językiem. Przy
>>> czym ani tego że jest potężnym językiem, ani że wysokopoziomowym, nie
>>> raczyłeś uzasadnić.
>>
>> Wysokopoziomowym strukturalnym. A to drobna różnica.
>
> W argumentacji? Żadna. Wysokopoziomowym strukturalnym jest Matlab.
>

Słuzy do konkretnych zastosowań. Zlinkujesz go z C w trybie jądra?

do góry

On Tue, 01 Feb 2011 16:14:11 +0100, "R. P." <r...@w...pl>
wrote:

>W dniu 2011-02-01 16:08, Grzegorz Krukowski pisze:
>> On Tue, 01 Feb 2011 15:42:41 +0100, "R. P."<r...@w...pl>
>> wrote:
>>
>>> Ale to już się stało i się nie odstanie. Stworzysz teraz system
>>> operacyjny od nowa, w czymś innym niż w C, który będzie mógł być
>>> konkurencyjny z Unixem, Linuxem czy Windowsem?
>>
>> A cóżeś się tak przyczepił pisania od nowa. Czy ktoś każe tobie
>> przepisywać kernel od początku? Asemblerowatość C umożliwia
>> podlinkowanie gotowych elementów do prawie wszystkiego co się zwie
>> ,,językiem programowania'' także nie ma żadnych niebezpieczeństw z tej
>> strony. Przeciw jest moda i, co za tym idzie, mała
>> popularność/znajomość innych języków.
>
>Niebezpieczeństw nie ma, ale czy to ma sens, jak cały dotychczasowy
>kernel powstał w C? Nie posypie się w nowym kawałku napisanym w języku
>super-wysokiego poziomu, ale posypie się przy wywołaniu starych funkcji ;)

No i? Idąc tokiem Twojego myślenia, to wiele rzeczy do dziś pozostalo
by w asemblerze bo (tu wstaw powyższe argumenty).

Tym bardziej, że jest dostępne ,,lepsze C'' pod nazwą C++, gdzie
zostało prawie całe jądro C ale podwyższono domyślny stopień
bezpieczeństwa, dodano trochę ozdóbek składniowych, statyczne klasy
oraz makrogenerator pracujący na poziomie języka pt. szablony. Tu nic
szybkościowo nie tracisz.

Za to cały dynamizm doszyto w stylu C. gdyż jawnie musisz używać
wskaźników. Ot cała ,,wysokopoziomowość'' C++.

>
>W kernelu ciągle znajodwane są jakieś dziury. We wszystkich popularnych
>systemach. To jest niezaprzeczalny fakt. Nie bronię C. Pisałem tylko, ze
>jest ważnym punktem w historii, bo stał się jezykiem niesamowicie
>popularnym i napisano w nim zdecydowanie najwięcej linii kodu...

Oczywiście, tylko dlaczego? Bo ówczesne zasobyk komputerów były
malutkie i liczył się każdy bajt. Tyle że obecnie już nie musimy być
tak oszczędni i wychwalanie C/C++ jako leku na całe zło jest już nieco
bez sensu.
--
Grzegorz Krukowski

do góry

On Feb 1, 3:58 pm, "R. P." <r...@w...pl> wrote:
> W dniu 2011-02-01 16:53, Andrzej Jarzabek pisze:
>
> > Podasz może jakiś przykład, gdzie dzięki "chytrym rzutom" w C udaje
> > się napisać coś, co np. w C++ możnaby osiągnąć wyłącznie przy
> > dodatkowym narzucie ze strony tablicy funkcji wirtualnych?
>
> Z założenia C++ jest nadzbiorem C (choć nie do końca), więc to co
> zrobisz w C możesz również zrobić w C++.

No więc właśnie możesz zrobić to samo, ale nie tak samo. Np. różne
"sprytne rzuty" które są legalne w C, nie są legalne w C++ i wymagają
jawnego rzutowania. Które jest tak samo szybkie, ale trudniej zrobić
błąd.

> Po prostu w C++ robisz hierarchię klas (tak jest ładnie)

Hierarcha klas sama z siebie nie generuje żadnego narzutu.

> a w C pojęcia klasy nie masz, odpada więc dziedziczenie itp.

Poproszę jakiś przykład czegoś, co w C można zrobić, albo można zrobić
łatwiej, albo lepiej, przez to, że nie ma klas i dziedziczenia.

> Nie ma więc w ogóle mowy o "robieniu tego
> samego" celem symulacji polimorficznych wywołań, bo inaczej projektuje
> się struktury.

No to proszę podaj mi przykład takiej struktury, której się nie da
równie sprawnie zaimplementować w C++.

do góry

W dniu 01.02.2011 16:57, R. P. pisze:
>
> Taka np. klasa string w C++ na pewno właściwą strukturą nie jest, bo to
> samo napisane w interpretowanym awk (ten sam algorytm przetwarzania
> tekstu) potrafi zadziałać 3x szybciej... Podobnie wiele innych klas w
> std jest w c++ spapranych.
Konkret - co takiego było 3 razy szybsze w AWK?

> Chociażby stream'y też są wydajnościowo
> skopane i w C zawsze wychodzi szybciej.
Ale mierzyłeś, tak? Czy na jakiej podstawie tak twierdzisz? (I w
porównaniu do czego?).

--
Pozdrawiam
Michoo

do góry

W dniu 01.02.2011 16:58, R. P. pisze:
> W dniu 2011-02-01 16:53, Andrzej Jarzabek pisze:
>> On Feb 1, 3:46 pm, "R. P."<r...@w...pl> wrote:
>>> W dniu 2011-02-01 16:44, Andrzej Jarzabek pisze:
>>>
>>>> Nieprawda. "Chytre rzuty" nie wnosz nic w kwestii wydajno ci.
>>>
>>> Pozawalaj np. omin tablic funkcji wirtualnych, kt ra daje narzut
>>> czasowy.
Jaki narzut ma wywołanie funkcji wirtualnej? Na pewno mierzyłeś (ja
mierzyłem ;) ). No słucham.

> Po prostu w C++ robisz
> hierarchię klas (tak jest ładnie) a w C pojęcia klasy nie masz, odpada
> więc dziedziczenie itp.
Jak byś miał trochę praktyki to byś się spotkał z GTK i GLIBem. Jak byś
się spotkał to byś widział czym się kończy kretynizm każący pisać w C a
skutkujący implementowaniem podzbioru C++ (polimorfizm, funkcje wirtualne).

> Nie ma więc w ogóle mowy o "robieniu tego
> samego" celem symulacji polimorficznych wywołań, bo inaczej projektuje
> się struktury.
Tak, na przykład umieszcza się w klasie jako pierwszy bajt wskaźnik na
strukturę zawierającą wskaźniki na funkcje. Efekt jest taki sam jak
funkcje wirtualne w c++, ale wolniej i bardziej podatne na błędy.


--
Pozdrawiam
Michoo

do góry