🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.lang.c
Article #1008

Re: malloc czy (type *)malloc?

#1008
From: Michal Malecki
Date: Fri, 06 Feb 1998 15:36
92 lines
5669 bytes
Marcin Laszewski <laser@priam.umcs.lublin.pl> wrote:

: Jasne, jest proste i latwe jak cale programowanie obiektowe.
: A teraz wez sobie program w C++ co zgdnie ze wszelkimi regulami
: obraca obiektami, przepusc to przez jakikolwiek front-end ktory
: go przerobi na "C" zwykle. Nastepnie obejrzyj sobie wygenerownay
: kod.

: Mina Ci zrzednia jak zobaczysz, ze C++ to nic innego jak preprocesor
: do "C" zwyklego, a nie tam znowu jakas nowa jakos, a wytworzony kod
: pelny jest roznego rodzaju smieci, tzn. kodu, ktory sie produkuje
: bo tego "kanon" jezyka obiektowego wymaga - sa to olbrzymie ilosci
: wywolan roznego rodzaju pustych funkcji, porownan, sprawdzen,
: niepotrzebnych wyrazen. Teraz kompilujesz to co wyszlo zwyklym
: kompilatorem - okazuje sie, ze brakuje jeszcze kilku dodatkowych
: "runtime-ow" i biblootek - niewielkich na szczescie, ale fakt faktem, ze
: pod "C" nie sa one potrzebne. A teraz uruchamiasz ten program, najpiejej
: z jakims profilerm i okazuje sie, ze 50% czasu Twpj program tylko
: tworzy obiekty, zwlania obiekty, zmienia obiekty, sprawdza czy 3++, to
: napewno 4, itd.... Moglbys jeszcze pogloadac co ma na ten temat "lint"
: do powiedzanie, ale przestrzegam, ze mozesz dostac zawalalu.
Przyznam szczerze, ze mina juz mi zrzedla. Moglbym sie klocic, czy tez ci
nie wierzyc, ale sam pamietam, ze jezeli masz zerowy wskaznik na char, to
printf( ptr );
zakonczy sie SIGSEGV, natomiast
cout << ptr;
zakonczy sie wypisaniem na ekranie "(null)". A wiec jednak ktos tu nas
sprawdza.
Musze ci jednak powiedziec, ze jakbys zobaczyl, jak wyglada kod asemblerowy
programu po skompilowaniu programu w C, tez bys sie pewnie niezle przerazil.
A tak - dla twojej wiadomosci - ogladalem kod wynikowy asemblera,
wyprodukowany przez Borland C++ 3.1, i do tego napisany w C++. Wygladal na
prawde bardzo prosciusienko (co prawda program tez byl prosty, ale jezeli
jest tak, jak mowisz, to nawet uzycie biblioteki iostream sie podobnie
skomplikuje).

Co z tego np., ze zamienia ci "operator =" na __as__, czy tez dwie wersje,
powiedzmy outstr( int ) i outstr( const char* ) zamieni ci na
outstr__1int i outstr__2constcharptr ? Czy to jest dla ciebie juz powod,
zeby nazywac C++ preprocesorem dla C ?

Z powyzszego przykladu wysunales - moim zdaniem - bledny wniosek. Ja raczej
powiedzialbym "widzisz, ile kombinacji trzeba robic w C, zeby napisac cos
podobnego".

Z jedna rzecza tutaj jednak musze sie zgodzic (bo nie moge sie nie zgodzic).
Program spedza za duzo czasu na rozne sprawdzanie. Ale nie wciskaj mi kitu,
ze sprawdza, czy 3++ to na pewno 4! Troche przesadziles.
Coz, jezeli sie chce pisac obiektowo, to takie sa konsekwencje, niestety.
A jezeli sie nie chce, to sie nie pisze. I jezeli program w C++ korzysta
z funkcji C (ktore podlegaja prawom wiazania obowiazujacym w C), to
nic takiego sie nie dzieje.

Coz, front-end moze ci i przerobi program w C++ na C. Ja jednak takiej praktyki
bym nie stosowal. Wole po prostu napisac program i skompilowac. Reszta nalezy
do kompilatora.

: I tylko nie pisz, ze w przypadku "porzadnych" kompilatorow (np. gcc) to
: co mowie nie ma sensu, bo tylko raz przelatuja kod w C++ i tworza od razu
: kod masyznowy - sam sobie sprawdzisz, ze ow balas takze istnieje
: (tyle, ze od razu w kodzia maszynowym).
Sprawdzilbym to chetnie. A wlasciwie to nawet wolalbym obejrzec sobie
zrodlowke asemblera z takim kodem.

: Slowem: Viva objectos! Napisz w obiektach system operacyjny, a potem
: powiesz ze hardware nie nadaza za za Twoim hitech softwarem.
Windows dziwnym trafem jest napisany w C. I nic wiecej nie powiem o nadazaniu.
Niedlugo moze uda mi sie napisac taki calkiem spory program w C++, na podstawie
jednego programu w C, gdzie autorzy doslownie wylazili ze skory, zeby nadrobic
brak obiektowosci. Jezeli bedzie dzialal mi dwukrotnie wolniej - uwierze.

: Czy dalej bedziesz sie upieral, ze nie ma zastosowan gdzie C, czy nawet
: asm, jest lepszy?
Tu bym tego tak nie ujmowal.
W C++ mozna napisac identyczne programy co w C. Nalezy jedynie brac pod
uwage rozne restrykcje i to wszystko.
Jezeli zas chodzi o asembler, to o kodzie wynikowym mozna powiedziec ze jest
wolny zarowno w programie napisanym w C jak i C++. I pisanie w nim jest
najlepsza metoda na uzyzkanie najwyzszej efektywnosci. Jest co prawda duzo
zachodu z taka rzecza, ale czasem stosuje sie - po kompilacji programow w C
na zrodlowke asemblera - przerabianie ich, by uzyskac wieksza efektywnosc.

Coz, kiedy gdb bedzie juz porzadnie supportowany dla C++, zobacze ile stosuje
on kombinacji.

Z piwowarzeniem,

-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...
Technical Details
Message-ID: <6bfam4$q2g@polonez.man.lodz.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!news.icm.edu.pl!uucp-gw.cyf.gov.pl!news.memax.krakow.pl!news.task.gda.pl!news.man.lodz.pl!not-for-mail
References: <34CCAF18.4877@imm.org.pl> <6akmcl$nua@polonez.man.lodz.pl> <34d11f26.6323935@news.icm.edu.pl> <6bafk2$l86@polonez.man.lodz.pl> <6begc6$if5$2@helios.man.lublin.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!news.icm.edu.pl!uucp-gw.cyf.gov.pl!news.memax.krakow.pl!news.task.gda.pl!news.man.lodz.pl!not-for-mail
From: Michal Malecki <sektor@zly.kis.p.lodz.pl>
Newsgroups: pl.comp.lang.c
Subject: Re: malloc czy (type *)malloc?
Date: 6 Feb 1998 15:36:36 GMT
Lines: 92
Message-ID: <6bfam4$q2g@polonez.man.lodz.pl>
References: <34CCAF18.4877@imm.org.pl> <6akmcl$nua@polonez.man.lodz.pl> <34d11f26.6323935@news.icm.edu.pl> <6bafk2$l86@polonez.man.lodz.pl> <6begc6$if5$2@helios.man.lublin.pl>
NNTP-Posting-Host: sektor@zly.kis.p.lodz.pl
User-Agent: tin/pre-1.4-980105 (UNIX) (SunOS/5.5.1 (i86pc))
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit