🚀 go-pugleaf

Marek Kotowski (mkot@imm.org.pl) wrote:
: Karpierz wrote:
: >> Niech Pan  sie nie  dziwi. Nie wszyscy sa tacy lotni jak
: >> Pan. :-)
: > Widze ze zaczynasz (Pan) coraz bardziej "merytoryczna" dyskusje...
: > To miala byc zlosliwosc lepiej wiedzacego ??? smutne...
:   To nie miala byc zlosliwosc. Jesli Pan to tak odebral,
: bardzo przepraszam. Uwagi takie, przynajmniej w dyskusji
: z Panem, juz sie nie powtorza.
: >> BTW -  nie musi Pan stosowac rzutu przy wywolaniu malloc.
: >> Jest to zbedne, a nawet niewskazane.
: > Oooo :) czepiamy sie !

Ej, losie kwadratowe!

Klocie sie o pierdoly: typy, nawiasy, itp. Zobacz sobie jeden 
z drugim jakikolwiek kawalek fachowe kodu to sie dowiecie, ze
zamiast robic hocki-klocki standardowo pisze sie makrodefinicje,
np: #define	malloct(type)	((type *)malloc(sizeof(type)))
i guzik kogo obchodza nawiasy i inne duperele.

Marcin Laszewski <laser@priam.umcs.lublin.pl> napisal

[...]
> Ej, losie kwadratowe!
> 
> Klocie sie o pierdoly: typy, nawiasy, itp. Zobacz sobie jeden 
> z drugim jakikolwiek kawalek fachowe kodu to sie dowiecie, ze
> zamiast robic hocki-klocki standardowo pisze sie makrodefinicje,
> np: #define	malloct(type)	((type *)malloc(sizeof(type)))
> i guzik kogo obchodza nawiasy i inne duperele.

i co to pomoze ?

zamieni Ci to Twoje malloct(type) na ((type *)malloc(sizeof(type)))
_PRZED_ faktyczna kompilacja i problem pozostanie tylko, ze 
Twoje slabe oczka tego nie dostrzega, jak zapewne i wiele innych
"pierdol" w C/C++.
Dlaczego ?
Bo my moze i jestesmy losiami, ale Ty napewno jestes 
owieczka plci meskiej (pomine do ktorej potegi), a ten gatunek 
ma slabe oczy... /za to mocne i twarde co innego..../

a wracajac do meritum juz lepiej stosuj tak (wg racji Pana Kotowskiego):

#ifdef __cplusplus
#define	malloct(type)  ((type *)malloc(sizeof(type)))
#else
#define	malloct(type)  (malloc(sizeof(type)))
#endif

PS: (bez obrazy prosze :). U mnie ze zlosliwoscia jak z nalogiem,
       ciagle walcze... 
       Aha, jak myslisz ile widzialo sie kodu w ciagu 15 lat pisania
       w C ? Mowie tylko za siebie. A to jest nic w stosunku do
       Pana Kotowskiego, ktory pisal ksiazki o C gdy Ty zapewne 
       sikales w pieluchy.
       Tak ze walnales jak w/w owieczka w mur...  

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Marek Kotowski <mkot@imm.org.pl> wrote cos, czego nie moglem zostawic bez
odpowiedzi:

: Karpierz wrote:
:>> Jest to zbedne, a nawet niewskazane.

:> Oooo :) czepiamy sie !

:   Tez nie. Po prostu, rzutowanie takie jest bardzo czesto
: traktowane przez programistow jako obligatoryjne i uznalem,
: ze mozna podkreslic, ze jest ono zbedne i niewskazane.
: Wiecej: uznalem, ze rzecz jest na tyle typowa, ze nalezy
: ja ujac w oddzielnym postingu.

:> Tak :) ? A to mnie ubawiles (Pan) :).
:> Wszedzie w ksiazce K&C jest stosowane takie rzutowanie i tez 
:> bylem przekonany ze wlasnie tak jest bardziej prawidlowo, a tu
:> masz.. taka wolta.. nawet niewskazane...
:> Prosze o uzasadnienie.

: 2. Funkcja malloc jest typu void *. Na mocy definicji
:    wskaznik taki spelnia najsilniejsze warunki ulozenia
:    obiektow w pamieci i moze byc przypisany kazdemu innemu.
:    Zatem rzut przy malloc jest zbedny.
Jasna sprawa. Jednak sprawa sie komplikuje, jezeli chcemy miec do czynienia
z C++...

: 3. Jest jeszcze jedna, byc moze istotniejsza przyczyna,
:    dla ktorej nie nalezy rzutowac wartosci zwracanej przez
:    malloc. Otoz kasuje to - czy tez moze kasowac - ostrzezenie
:    kompilatora o braku pliku definicyjnego z prototypem malloc,
:    jesli pliku takiego do modulu nie wlaczono. W takiej sytuacji
:    kompilator sam zbuduje sobie prototyp funkcji malloc na podstawie
:    jej wywolania i nada jej domyslny typ int.
Oj, bylbym na panskim miejscu ostrozniejszy z takimi teoriami!
W kazdym razie na pewno kompilator (dobry kompilator!) wygeneruje dwa
ostrzezenia:
1. Wywolano funkcje nie posiadajaca prorotypu.
2. Uzyto nielegalnej konwersji z (int) na (char*) [np.]
Prosze wiec nie mowic o niebezpieczenstwach. Programista powinien zwracac
uwage na takie ostrzezenia i ZAWSZE wlaczac pliki naglowkowe (albo pisac
jawnie naglowki samemu). Zaznacze tu tylko, ze C++ akurat nie dopuszcza
wywolania funkcji nie posiadajacej prototypu.

:    W rezultacie na skutek rzutu moze zostac przeoczony blad
:    niewlaczenia do modulu odpowiedniego pliku definicyjnego.
I ten blad panskiego rozumowania chcialem wytknac.

: 4. Uprzedze od razu argument, ze rzut przy malloc wyjasnia
:    intencje programisty. Tak sie czasami sadzi, mowiac np, ze.

:    p = (char *)malloc(100);

:    wyjasnia, na co alokowana jest pamiec. Jest to chybiony argument,
:    bo rzecz tu jest w samej nazwie zmiennej wskaznikowej, ktora
:    powinna wyjasniac nature wskazywanego obiektu. 
A tu sie zgadza!
Linijka przez pana zacytowana swiadczy TYLKO I WYLACZNIE o glupocie progra-
mujacego. Bo jezeli juz to piszemy albo:

p = malloc( 100*sizeof (char) );

albo

p = calloc( 100, sizeof (char) );

W innym wypadku mowienie ze wyjasnia to intencje programisty jest idiotyzmem.

: 5. Brak rzutu przy malloc jest zgodny ze standardem,
:    wiecej: z jego duchem. Po to wprowadzono miedzy innymi
:    jasne zasady rzutowania wskaznikow w standardzie,
:    by nie trzeba bylo w takich sytuacjach stosowac rzutow.

:> Osobiscie wszystkim zalecam wlasnie stosowanie rzutowania.
Niby po co ? W standardzie C rzutowanie wskaznika void* nigdy nie jest
konieczne. Co innego C++, o ktorym zaraz napisze.

:   Coz, kazdy zaleca to, co uwaza za wskazane. Moim
: zdaniem rada Panska jest zla. Rzecza czytelnikow
: jest osadzic, ktore zalecenie jest bardziej racjonalne.

:> Dlaczego ?

:> Podam tylko jeden prosty przyklad, na tyle malo teoretyczny 
:> co bardzo zyciowy:

:> char * x = malloc (123);

:> Pod C sie kompiluje ? rzeczywiscie... No to piszemy "krocej"...
:> Po co sie meczyc... Po kilku latach stwierdzamy ze mamy
:> juz kilka MB kodu w C...
:> No tak, ale te obiekty i to C++. Wypada sprobowac.
:> cannot convert void * to char * !
:> lub tym podobnych.

: To prawda. Kompilator C++ tak zareaguje w tym przypadku.
: Ale C++ jest innym jezykiem niz C.
Ano wlasnie.
Powiedzcie mi panowie: KTO PRZY ZDROWYCH ZMYSLACH uzywa w programie w C++
funkcji malloc!?
Z operatorem new jest taki akurat dowcip, ze zwraca on co prawda typ void*
(vide: przeciazanie operatora new), ale nie wymaga nigdy konwersji.
Poniewaz C++ jest jezykiem o silnej typizacji, takie numery nie moga byc
dozwolone. I w praktyce niestey nie nalezy stosowac w C++ funkcji malloc,
tylko operator new. Jezeli komus koniecznie zalezy na stosowaniu malloc,
to powinien przeciazyc operator new. Dlaczego ?
Zarowno new jak i malloc dokonuja konstrukcji obiektu. Jednak...
Funkcja malloc robi to zle. Jedyne bowiem co robi to przydziela pamiec.
Podam dwa przyklady, dowodzace, ze w C++ nie nalezy stosowac malooc:

1. Jezeli np. klasa Klocek jest abstrakcyjna, to po deklaracji:
Klocek* pk;
kompilator odrzuci stanowczo:
pk = new Klocek;
ale nie ma powodu, by odrzucic:
pk = (Klocek*) malloc( sizeof (Klocek) );
Moze to spowodowac trudne do wykrycia bledy.

2. Jezeli klasa Klocek ma konstruktor z parametrami, to w jaki sposob
poda sie owe parametry ? No ? Slucham uprzejmie. A co jezeli klasa NIE
ZAWIERA konstruktora bezparametrowego ? Znow:
pk = new Klocek;
kompilator odrzuci, bo konstruktor ma niewlasciwe parametry. Jednak
pk = (Klocek*) malloc( sizeof (Klocek) );
konstruktor nie odrzuci, bo nie traktuje tego jako konstrukcje obiektu.

A jak w przyszlosci komus sie pomysli, zeby np. odrzucac proby odwolania sie
do nieskonstruowanego obiektu ? Wtedy nawet jezeli przydzieli sie pamiec
funkcja malloc, to kompilator stwierdzi, ze "nie przydzielono pamieci na
obiekt - dziekuje za uwage" (oczywiscie moze zrobic taki numer tylko na
zmiennych referencyjnych).

Dlatego tez od razu stwierdzam: malloc stosujemy w C, a w C++ new.
A skoro malloc jest tylko dla C, to mnie wisi i powiewa co na to powie
kompilator C++.

A taka mala dygresja: co zrobic jak np. ma pan program zlozony z 20 plikow,
wszystkie uzywaja pliku naglowkowego z deklaracja struktury, a jedno z pol
struktury nazywa sie 'class' ?

: To, co Pan - byc moze nie
: do konca swiadomie - sugeruje, to wziac modul napisany w C, nadac
: mu rozszerzenie CPP i kompilowac jako C++. To tez, moim zdaniem,
: zla rada. C i C++ to sa inne filozofie programowania.
I wlasnie dlatego nie nalezy przenosic takich programow "zywcem".
Jak juz, to odpowiednio taki program przerobic (jedna z tych przerobek bedzie
oczywiscie zamiana malloc na new).

: Jezyk C jest do programowania strukturalnego, C++ - do
: obiektowego. Jesli Pan ma duzo kodu w jezyku C, to, owszem,
: mozna go wykorzystac w projekcie programistycznym w C++,
: ale jako moduly w C wlasnie, a nie jako kod w C, ktory ma
: stac sie kodem w C++ (program strukturalny nie stanie sie przez
: to obiektowym). 
Tu zaczyna pan zlekka przeginac. Czyzby pan sugerowal, ze C++ nie nadaje sie
do programowania strukturalnego ? Ale jak najbardziej sie nadaje!
IMHO jezyk C nadaje sie WYLACZNIE dla ludzi, ktorzy nie potrafia zrozumiec
jezyka C++. Kazdy program, zamierzony do napisania w C, mozna napisac w C++
(a nawet lepiej go w tym jezyku napisac!). Przeciez nikt nie kaze stosowac
programowania obiektowego w C++! Przeciez ma on poza obiektami tyle mozliwosci
i udogodnien, ze ja np. jak chce napisac jakis program to nawet nie mysle o
tym, zeby uzyc do tego czystego C.

: Nie nalezy tez kodujac w C, myslec,
: czy kupi to kompilator C++, bo wtedy grozi programiscie
: swoista schizofrenia: czy ten kod w C akceptuje kompilator C++,
: czy nie? A jezeli kod napisany w C jest zgodny z wymogami C++,
: to czy jest to C, czy moze juz C++? A moze to juz jest nawet
: programowanie obiektowe? :-)
Moze wyjasnijmy sobie co to bedzie programowanie obiektowe ? Czy polega na
uzywaniu obiektow ze standartowej biblioteki, czy tez deklarowaniu wlasnych ?
Jezeli uzywa sie np. jedynie obiektow z biblioteki iostream, czy fstream, to
IMHO to nie jest jeszcze programowanie obiektowe. Natomiast np. pisanie
programow pod biblioteka OWL to juz jest.

:   I tyle. Takie sa Panskie rady (moim zdaniem zle) i argumenty,
: a takie sa moje. Reszte zostawmy Czytelnikom.
Zwlaszcza przystosowywanie malloc do wymogow C++.

Pozdrawiam serdecznie,

-- 
.---.     .   . - 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...

Marcin Laszewski <laser@priam.umcs.lublin.pl> wrote:
: Marek Kotowski (mkot@imm.org.pl) wrote:
: : Karpierz wrote:
: : >> Niech Pan  sie nie  dziwi. Nie wszyscy sa tacy lotni jak
: : >> Pan. :-)
: : > Widze ze zaczynasz (Pan) coraz bardziej "merytoryczna" dyskusje...
: : > To miala byc zlosliwosc lepiej wiedzacego ??? smutne...
: :   To nie miala byc zlosliwosc. Jesli Pan to tak odebral,
: : bardzo przepraszam. Uwagi takie, przynajmniej w dyskusji
: : z Panem, juz sie nie powtorza.
: : >> BTW -  nie musi Pan stosowac rzutu przy wywolaniu malloc.
: : >> Jest to zbedne, a nawet niewskazane.
: : > Oooo :) czepiamy sie !

: Ej, losie kwadratowe!

: Klocie sie o pierdoly: typy, nawiasy, itp. Zobacz sobie jeden 
: z drugim jakikolwiek kawalek fachowe kodu to sie dowiecie, ze
: zamiast robic hocki-klocki standardowo pisze sie makrodefinicje,
: np: #define	malloct(type)	((type *)malloc(sizeof(type)))
: i guzik kogo obchodza nawiasy i inne duperele.

Tez dobry sposob. Ale w poprzednim postingu wyjasnilem caly sens.

-- 
.---.     .   . - 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...

Michal Malecki wrote:
> : 3. Jest jeszcze jedna, byc moze istotniejsza przyczyna,
> :    dla ktorej nie nalezy rzutowac wartosci zwracanej przez
> :    malloc. Otoz kasuje to - czy tez moze kasowac - ostrzezenie
> :    kompilatora o braku pliku definicyjnego z prototypem malloc,
[...]
> Oj, bylbym na panskim miejscu ostrozniejszy z takimi teoriami!
> W kazdym razie na pewno kompilator (dobry kompilator!) wygeneruje dwa
> ostrzezenia:
> 1. Wywolano funkcje nie posiadajaca prorotypu.
> 2. Uzyto nielegalnej konwersji z (int) na (char*) [np.]

  Trafna uwaga. BC daje wlasnie dwa komunikaty. Dlatego piszac
powyzsze, poprawilem sie ("czy tez moze kasowac"). Niestety, trafne
jest tez Panskie zastrzezenie o dobrym kompilatorze. Kompilatory
nie maja obowiazku generowania ostrzezen. Jest to sprawa 
implementacji jezyka.

> Linijka przez pana zacytowana swiadczy TYLKO I WYLACZNIE o glupocie progra-
> mujacego. Bo jezeli juz to piszemy albo:
> 
> p = malloc( 100*sizeof (char) );
> 

Za najlepsze stylistycznie rozwiazanie uchodzi - mysle,
ze slusznie - konstrukcja:

p = malloc(100 * sizeof(*p));

> Ano wlasnie.
> Powiedzcie mi panowie: KTO PRZY ZDROWYCH ZMYSLACH uzywa w programie w C++
> funkcji malloc!?

  Moj znajomy, ktoremu "new nie chodzi"! :-)

  Co do fragmentu o C i C++ - zgoda.

  Pozdrawiam

  Marek Kotowski

Michal Malecki <sektor@zly.kis.p.lodz.pl> napisal
[...]

> : To prawda. Kompilator C++ tak zareaguje w tym przypadku.
> : Ale C++ jest innym jezykiem niz C.
> Ano wlasnie.
> Powiedzcie mi panowie: KTO PRZY ZDROWYCH ZMYSLACH uzywa w
> programie w C++ funkcji malloc!?

A kto pisze o uzywaniu malloc w nowo pisanym kodzie w C++ ?
Pisalem wyraznie o przenieszeniu kodu z C na C++.
Ale nawet w C++ w poczatkowym okresie wielu ludzi ktorzy umia juz C 
stosuje funkcje malloc bo ja zna poprostu i nie ma w tym nic dziwnego
zreszta. Mowisz, ze nie wolno ? No to po coz znalazla sie ona w C++ ?
To ze jest to funkcja C nie znaczy ze nie wolno jej uzywac w C++.
Pomimo, ze nalezy tego unikac na ile sie tylko da, to jednak
sa czasem przypadki ze jest to wprost wymuszone.
Pozostawiam Ci to jako zagadke...

Probowales przeniesc w rozsadnym czasie np 2 MB = ok 1200 stron
kody zrodlowego z C na C++ ? 
Sprobuj wytlumaczyc szefowi, ze liczac 10 stron dziennie
przeniesienie kodu systemu na C++ zajmie Ci 120 dni nie 
wliczajac w to dni wolnych i ze w tym czasie system nie bedzie mogl 
byc serwisowany, bo nie bedzie sie kompilowal bo bedziesz musial 
pozamieniac wszystkie malloc na new i free na delete i inne 
w/g Ciebie "niedopuszczalne" w C++ konstrukcje. 
Uslyszysz zapewne cos w rodzaju:

"KTO PRZY ZDROWYCH ZMYSLACH napisal ten kod w C tak,
 zeby tyle trwalo przenoszenie na C++ ktory przeciez 
 jest wlasciwie nadzbiorem C."

> IMHO jezyk C nadaje sie WYLACZNIE dla ludzi, ktorzy nie potrafia 
> zrozumiec jezyka C++. 

Tu dales przyklad totalnej BZDURY i SWOJEJ IGNORANCJI !!!

>Kazdy program, zamierzony do napisania w C, mozna napisac w 
> C++

Zareczam Ci, ze nie kazdy :).  Oczywiscie sa to szczegolne przypadki
ale sie zdazaja.

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

[...]
> do programowania strukturalnego ? Ale jak najbardziej sie nadaje!
> IMHO jezyk C nadaje sie WYLACZNIE dla ludzi, ktorzy nie potrafia zrozumiec
> jezyka C++. [...]

A to juz bardzo smiale zdanie. Wyglada to na zdanie kogos, kto sie
nauczyl (i zrozumial ??) C++ i zachlysnal sie nim. Otoz nie zawsze
nalezy wytaczac dzialo to zabicia muchy. A o jezykach takich  jak Perl
slyszales? Po co na przyklad prosty programik typu
getchar();...putchar(); pisac w C++. A dlaczego nie warto do niektorych
rzeczy uzywac C, tylko latwiej napisac prosty programik w perlu? A po co
np. pisac program, skoro akurat takie zadanie da sie wykonac jako skrypt
shella? Nie dopasowuj zycia do Twojego ukochanego jezyka, tylko jezyki
programowania, ktorych uzywasz, do zadan, ktore maja wykonac.


								pozdrawiam

						Mirek

On 27 Jan 1998, Karpierz wrote:

> Michal Malecki <sektor@zly.kis.p.lodz.pl> napisal
> [...]
> 
> > : To prawda. Kompilator C++ tak zareaguje w tym przypadku.
> > : Ale C++ jest innym jezykiem niz C.
> > Ano wlasnie.
> > Powiedzcie mi panowie: KTO PRZY ZDROWYCH ZMYSLACH uzywa w
> > programie w C++ funkcji malloc!?
> 
> A kto pisze o uzywaniu malloc w nowo pisanym kodzie w C++ ?
> Pisalem wyraznie o przenieszeniu kodu z C na C++.
> Ale nawet w C++ w poczatkowym okresie wielu ludzi ktorzy umia juz C 
> stosuje funkcje malloc bo ja zna poprostu i nie ma w tym nic dziwnego
> zreszta. Mowisz, ze nie wolno ? No to po coz znalazla sie ona w C++ ?
> To ze jest to funkcja C nie znaczy ze nie wolno jej uzywac w C++.
> Pomimo, ze nalezy tego unikac na ile sie tylko da, to jednak
> sa czasem przypadki ze jest to wprost wymuszone.
> Pozostawiam Ci to jako zagadke...

Jedna sprawa panowie, odczepcie sie od tego malloc() bo to mieszanie
pojec. Malloc jest funkcja POSIXowa, i kazdy uzywa malloc kto pisze 
w C++, tyle ze niejawnie. Sa zreszta rozne malloce i zaleza one
od strategi obslugi pamieci w C++ jaka przyjmiemy. Zrobienie wlasnego
managera pamieci w C++ sprowadza sie zazwyczaj do zdefiniowania
operatorow new.

> 
> Probowales przeniesc w rozsadnym czasie np 2 MB = ok 1200 stron
> kody zrodlowego z C na C++ ? 

2MB to duzo duzo wiecej niz 1200 stron. To kilka lat pracy kilku
ludzi.

> > IMHO jezyk C nadaje sie WYLACZNIE dla ludzi, ktorzy nie potrafia 
> > zrozumiec jezyka C++. 
> 
> Tu dales przyklad totalnej BZDURY i SWOJEJ IGNORANCJI !!!
> 
> >Kazdy program, zamierzony do napisania w C, mozna napisac w 
> > C++
> 
> Zareczam Ci, ze nie kazdy :).  Oczywiscie sa to szczegolne przypadki
> ale sie zdazaja.
> 

Zgadzam sie z bzdura i totalna ignorancja. Jest bardzo bardzo wiele rzeczy
do ktorych metodologia OOP kompletnie sie nie nadaje, a co za tym idzie
C++. Jest to juz bowiem jezyk o wiele wyzszego poziomu niz C i kompilator
robi za nas mnostwo rzeczy. Np. zwijanie stosu przy obludze wyjatkow,
albo obiekty tymczasowe. Jest to nie do pomyslenia w wielu systemach.
Np. wyobrazcie sobie Linux Kernel w C++. Poza tym C++ nie jest do konca
rozwiniete, nie ma pod niego naprawde dobrych kompilatorow, i ludzie
po prostu boja sie pod tym pisac. Nie zastanawialiscie sie kiedys dlaczego
tak malo dobrego oprogramowania Gnu jest tworzonego w C++ ? Prawie na 
palcach mozna policzyc.

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Karpierz <karpierz@inter.intertele.pl> wrote:
: Marcin Laszewski <laser@priam.umcs.lublin.pl> napisal

: [...]
:> Ej, losie kwadratowe!
:> 
:> Klocie sie o pierdoly: typy, nawiasy, itp. Zobacz sobie jeden 
:> z drugim jakikolwiek kawalek fachowe kodu to sie dowiecie, ze
:> zamiast robic hocki-klocki standardowo pisze sie makrodefinicje,
:> np: #define	malloct(type)	((type *)malloc(sizeof(type)))
:> i guzik kogo obchodza nawiasy i inne duperele.

: i co to pomoze ?

: zamieni Ci to Twoje malloct(type) na ((type *)malloc(sizeof(type)))
: _PRZED_ faktyczna kompilacja i problem pozostanie tylko, ze 
: Twoje slabe oczka tego nie dostrzega, jak zapewne i wiele innych
: "pierdol" w C/C++.
A PO JASNA CHOLERE ?
A moze, prosze pana, w ogole nie uzywajmy preprocesora, piszmy wszystko
z jak najwieksza iloscia nawiasow i za kazdym razem pozywsza konstrukcje.
Kolega zaproponowal tutaj akurat BARDZO dobre rozwiazanie (ktorego ja nawet
swego czasu uzywalem).

: Dlaczego ?
: Bo my moze i jestesmy losiami, ale Ty napewno jestes 
: owieczka plci meskiej (pomine do ktorej potegi), a ten gatunek 
: ma slabe oczy... /za to mocne i twarde co innego..../
No coz... biorac pod uwage, ze kolega zaproponowal tu bardzo sluszne
rozwiazanie, raczej mysli w odroznieniu od pana. Niech sie pan cieszy, ze
nazwal pana losiem, a nie np. nosorozcem (panskie argumenty j.w.).

: a wracajac do meritum juz lepiej stosuj tak (wg racji Pana Kotowskiego):

: #ifdef __cplusplus
: #define	malloct(type)  ((type *)malloc(sizeof(type)))
: #else
: #define	malloct(type)  (malloc(sizeof(type)))
: #endif

Poniewaz w C++ nie nalezy uzywac malloc (jak to opisalem w poprzednim
artykule) taka propozycja jest zupelnie niedorzeczna. Wymaga ona specjalnego
traktowania C++, to znaczy specjalnego przerobienia programu w C, zeby mogl
sie kompilowac pod oboma kompilatorami. W obecnej chwili istnieja albo
kompilatory C, albo mogace pracowac zarowno w trybie C jak i C++. Totez
jaki ma sens przystosowywanie programu w C pod kompilacje pod C++ ?

: PS: (bez obrazy prosze :). U mnie ze zlosliwoscia jak z nalogiem,
:        ciagle walcze... 
:        Aha, jak myslisz ile widzialo sie kodu w ciagu 15 lat pisania
:        w C ? Mowie tylko za siebie. A to jest nic w stosunku do
:        Pana Kotowskiego, ktory pisal ksiazki o C gdy Ty zapewne 
:        sikales w pieluchy.
:        Tak ze walnales jak w/w owieczka w mur...  
Tak wlasnie mysle, panowie, ze troche za dlugo juz siedzicie w C.
Ja wam nawet do piet nie dorastam pod wzgledem stazu, niemniej jednak dziwi
mnie, jak przez taki dlugi czas nie mogliscie zrozumiec takiej prostej rzeczy.
Najwyrazniej taka jest wasza wiedza o C++.

Pozdrawiam jak najbardziej serdecznie,

-- 
.---.     .   . - 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...

Michal Malecki <sektor@zly.kis.p.lodz.pl> napisal
[...]
> Tak wlasnie mysle, panowie, ze troche za dlugo juz siedzicie w C.
> Ja wam nawet do piet nie dorastam pod wzgledem stazu, niemniej jednak
dziwi
> mnie, jak przez taki dlugi czas nie mogliscie zrozumiec takiej prostej
rzeczy.
> Najwyrazniej taka jest wasza wiedza o C++.

Jeszcze jeden wszystkowiedzacy eh... Cos duzo tych owieczek ostatnio...
Nawet nie bede sie silil odpowiedzec normalnie.
Mysle ze troche zarozumialosci nie zaszkodzi... (za co innych przepraszam).

Jak myslisz "fachowcu" czy 7 latek w C++ (w moim przypadku)
i w dwoch przypadkach stycznosc i kilkukletnia praca z kodami wielkosci 
3MB i 8MB zrodel to duzo czy malo zeby jednak chociaz troche lepiej od 
Ciebie poznac te jezyk... ?
A i tak mi sie wydaje ze ciagle czegos nie wiem napewno...
(np. mam klopoty ze skomplikowanymi "templatesami") i czesto siegam do
Stroustrupa, Grebosza czy Hansena... (wg mnie te dwie ostatnie to chyba 
najlepsze, a napewno najprzyjemniejsze polskojezyczne ksiazki do C++). 
Po czesci to wina wad samego jezyka (wcale nie jestem jego zagorzalym
fanatykiem), a po czesci tego ze uwazam ze znajomosc C++ to nie sucha
znajomosc gramatyki, ale "myslenie" w tym jezyku w sposob obiektowy, 
czyli widzenie ("czucie") problemu przez pryzmat hierarchii obiektow 
(w kontekscie jezyka). Przyznam sie ze z tym mam jeszcze ciagle klopoty 
i dlatego uwazam ze pisze ciagle w sposob raczej "obiektawy" i nie jestem 
specem w C++ (a gdzie mi do np. stosowania patterns... przygladam sie
dopiero 
w wolnych chwilach ACE...), STL slabo jeszcze znam, z wyjatkow tez nie 
korzystam nagminnie :), z GUI tylko wxWindows i to tylko prywatnie a
nie w pracy..., a gdzie CORBA , obiektowe bazy danych... RPC.. itp, itd...
Ze wspomne o metodologiach projektowania (te wszystkie Rationale, UML-e
itp...). Szkoda mowic...

No dobra :)... koniec "moralizatorstwa dziadka". I tak to przeciez nic nie
da.

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

On 28 Jan 1998, Karpierz wrote:

> Stroustrupa, Grebosza czy Hansena... (wg mnie te dwie ostatnie to chyba 
> najlepsze, a napewno najprzyjemniejsze polskojezyczne ksiazki do C++). 

A Lipmana widziales ? Kumpel Stroustrupa. Calkiem niezly.

> Po czesci to wina wad samego jezyka (wcale nie jestem jego zagorzalym
> fanatykiem), a po czesci tego ze uwazam ze znajomosc C++ to nie sucha
> znajomosc gramatyki, ale "myslenie" w tym jezyku w sposob obiektowy, 
> czyli widzenie ("czucie") problemu przez pryzmat hierarchii obiektow 
> (w kontekscie jezyka). Przyznam sie ze z tym mam jeszcze ciagle klopoty 
> i dlatego uwazam ze pisze ciagle w sposob raczej "obiektawy" i nie jestem 
> specem w C++ (a gdzie mi do np. stosowania patterns... przygladam sie
> dopiero 
> w wolnych chwilach ACE...), STL slabo jeszcze znam, z wyjatkow tez nie 
> korzystam nagminnie :), 

A co to sa te "patterns" ? Wyjatki rulez, tylko gcc je slabo wykorzystuje,
to jest minus... STL to standard template library ? To Cie rozumiem :-)
Aha, co to jest to ACE, bo nie nadazam za TLSami.

pozdrawiam 
c.

PS. TLS=TrzyLiterowySkrot

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Maciej MOCHOL <mmochol@elka.pw.edu.pl> napisal
[...]
> Jedna sprawa panowie, odczepcie sie od tego malloc() bo to mieszanie
> pojec. Malloc jest funkcja POSIXowa, i kazdy uzywa malloc kto pisze 
> w C++, tyle ze niejawnie. Sa zreszta rozne malloce i zaleza one
> od strategi obslugi pamieci w C++ jaka przyjmiemy. Zrobienie wlasnego
> managera pamieci w C++ sprowadza sie zazwyczaj do zdefiniowania
> operatorow new.

Zgadzam sie, wlasnie tak.
Ale jednak trzeba miec na uwadze ze new _TWORZY_ obiekt 
(wywoluje konstruktor), a malloc przydziela tylko "sucha" pamiec.
Wiem, ze o tym wiesz, a pisze to tylko dla podkreslenia dla tych ktorzy
moga sie dopiero uczyc.

> > Probowales przeniesc w rozsadnym czasie np 2 MB = ok 1200 stron
> > kody zrodlowego z C na C++ ? 
> 
> 2MB to duzo duzo wiecej niz 1200 stron. To kilka lat pracy kilku
> ludzi.

Masz racje.
Mialo byc 1MB = 1200 stron.
Pomylily mi sie strony z kartkami. 
To jest chyba dosc dobre oszacowanie dla przecietnego "zbitego" kodu.

[...]

Z reszta tez sie zgadzam prawie w 100%.

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

On 28 Jan 1998, Karpierz wrote:

> Z reszta tez sie zgadzam prawie w 100%.

Ciesze sie ze mamy wspolne poglady ;-)))))))))))

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Michal Malecki <sektor@zly.kis.p.lodz.pl> napisal
> Marek Kotowski <mkot@imm.org.pl> wrote cos, 
>czego nie moglem zostawic bez odpowiedzi:
[...]
> : 4. Uprzedze od razu argument, ze rzut przy malloc wyjasnia
> :    intencje programisty. Tak sie czasami sadzi, mowiac np, ze.
> 
> :    p = (char *)malloc(100);
> 
> :    wyjasnia, na co alokowana jest pamiec. Jest to chybiony argument,
> :    bo rzecz tu jest w samej nazwie zmiennej wskaznikowej, ktora
> :    powinna wyjasniac nature wskazywanego obiektu. 
> A tu sie zgadza!
> Linijka przez pana zacytowana swiadczy TYLKO I WYLACZNIE o glupocie 
> programujacego. Bo jezeli juz to piszemy albo:
> 
> p = malloc( 100*sizeof (char) );

[...]

To co napisales swiadczy rowniez TYLKO I WYLACZNIE o glupocie
"przedpiscy" /gdzies widzialem uzycie tego potworka :) fajne/
(przepraszam za ostre slowa, ale oko za oko....).
Akurat w kazdym raporcie C czy to K&R czy ANSI stoi jak byk
ze z definicji sizeof (char) == 1 (i ze char jest najmniejsza mozliwa do 
przydzielenia porcja pamieci) bez wzgledu na faktyczny rozmiar (w bitach) 
typu char wiec konstrukcja typu:

p = (char *)malloc(100);

nie swiadczy o zadnej glupocie.
/pisal przeciez juz o tym wyraznie w ktoryms z postingow Gracjan Ziolek, 
a jego bym na Twym miejscu nie posadzal o glupote.../

Mozna dyskutowac na temat konserwencji piszacego, ze moze lepiej 
konsekwentniej bedzie tak jak Ty proponujesz:

p = malloc( 100*sizeof (char) );

ale znajda sie zapewne tacy ktorzy stwierdza ze to glupie bo standard 
wyraznie mowi jw. i ze kazdy to powinien wiedziec i kto wtedy wyjdzie 
na glupka ? Jak myslisz ?

To jest po prostu sprawa stylu i oczywiscie nadaje sie do dyskusji,
a nie kwestia czyjejs glupoty.

Bardzo dobre podejscie pokazal moim zdaniem Pan Kotowski poniewaz
jest uniwersalne:

p = malloc (100 * sizeof (*p));

Ma tylko moze ta wade, ze trzeba odszukac deklaracje p zeby sie dowiedziec 
co faktycznie jest przydzielane, ale w/g mnie wada drobna w stosunku do 
zalety, zreszta nie da sie pogodzic jednego z drugim.

PS: cos nerwowy jestem.. zawsze jest tak przed spodziewana premia :))).
      /Zona jeszcze bardziej :)/

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Gracjan Ziółek <Gracjan.Ziolek@bdk.lublin.pl> napisal
Karpierz wrote:
[...]

>Bardzo mile slowa, ale przecie zaden ze mnie autorytet, jezeli chodzi o
>C. No, chyba ze lokalnie w Lublinie ;).

Ja tez lokalnie... w Tyczynie... hehe

Nie chodzi mi tylko o C /bedzie Ritchie w piekle/niebie (do wyboru) 
za ten jezyk odpowiadal :)/, chodzi o ogolny poziom Twych wypowiedzi.

>Ale sprowokowales mnie do odezwania sie w koncu :). Przygladam sie
>dyskusji juz od dluzszego czasu i zaczynam coraz bardziej denerwowac. Bo
>wyglada mi to calkiem podobnie do niedawnej awantury C vs. Pascal na
>pl.comp.programming. Dlatego wypowiem sie krotko i zwiezle (mam
>nadzieje).

Wlasnie zauwazylem ze juz siedze w tym watku po uszy .. wstyd mi...

>Standard zezwala na rzutowanie malloc(), podobnie jak zezwala na brak
>tego rzutowania. Wobec tego decyzja o stosowaniu nalezy do programisty
>lub szefa zespolu, do ktorego nalezy. Inaczej: w malym programie na
>pewno nie uzywam rzutowania. 

Nareszcie ktos mlody trafil w 10 :). 
Nam starym chyba sie juz lufy powykrzywialy....

[...]

>Jeszcze inaczej: ja jem potrawy lyzka, a Chinczycy paleczkami. 
>I co, ktos z nas jest lepszy z tego powodu?

Wlasnie :). Dodam jeszcze tylko ze czasem lepiej pozostac przy 
swoim sprawdzonym sposobie ...
Zamienilismy sie raz z Chinczykiem lyzka i paleczkami...
Po posilku on mial usta dwa razy szersze, a ja o malo oczu sobie
nie wydziobalem... :)

-- 
Pozdrawiam  (na wesolo)                               Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Karpierz wrote:
> 
> Michal Malecki <sektor@zly.kis.p.lodz.pl> napisal
> > Marek Kotowski <mkot@imm.org.pl> wrote cos,
> >czego nie moglem zostawic bez odpowiedzi:
> [...]
> > : 4. Uprzedze od razu argument, ze rzut przy malloc wyjasnia
> > :    intencje programisty. Tak sie czasami sadzi, mowiac np, ze.
> >
> > :    p = (char *)malloc(100);
> >
> > :    wyjasnia, na co alokowana jest pamiec. Jest to chybiony argument,
> > :    bo rzecz tu jest w samej nazwie zmiennej wskaznikowej, ktora
> > :    powinna wyjasniac nature wskazywanego obiektu.
> > A tu sie zgadza!
> > Linijka przez pana zacytowana swiadczy TYLKO I WYLACZNIE o glupocie
> > programujacego. Bo jezeli juz to piszemy albo:
> >
> > p = malloc( 100*sizeof (char) );
> 
> [...]
> 
> To co napisales swiadczy rowniez TYLKO I WYLACZNIE o glupocie
> "przedpiscy" /gdzies widzialem uzycie tego potworka :) fajne/
> (przepraszam za ostre slowa, ale oko za oko....).
> Akurat w kazdym raporcie C czy to K&R czy ANSI stoi jak byk
> ze z definicji sizeof (char) == 1 (i ze char jest najmniejsza mozliwa do
> przydzielenia porcja pamieci) bez wzgledu na faktyczny rozmiar (w bitach)
> typu char wiec konstrukcja typu:
> 
> p = (char *)malloc(100);
> 
> nie swiadczy o zadnej glupocie.
> /pisal przeciez juz o tym wyraznie w ktoryms z postingow Gracjan Ziolek,
> a jego bym na Twym miejscu nie posadzal o glupote.../

Bardzo mile slowa, ale przecie zaden ze mnie autorytet, jezeli chodzi o
C. No, chyba ze lokalnie w Lublinie ;).
Ale sprowokowales mnie do odezwania sie w koncu :). Przygladam sie
dyskusji juz od dluzszego czasu i zaczynam coraz bardziej denerwowac. Bo
wyglada mi to calkiem podobnie do niedawnej awantury C vs. Pascal na
pl.comp.programming. Dlatego wypowiem sie krotko i zwiezle (mam
nadzieje).
Standard zezwala na rzutowanie malloc(), podobnie jak zezwala na brak
tego rzutowania. Wobec tego decyzja o stosowaniu nalezy do programisty
lub szefa zespolu, do ktorego nalezy. Inaczej: w malym programie na
pewno nie uzywam rzutowania. A jezeli chodzi o duze, to mysle, ze Twoja
wypowiedz, Adamie (o przenoszeniu kodu itp.) ma sporo praktycznego
sensu.
Jeszcze inaczej: ja jem potrawy lyzka, a Chinczycy paleczkami. I co,
ktos z nas jest lepszy z tego powodu?

	pozdrawiam :)

PS Niektorzy zapewnie wiedza, jest calkiem ciekawa grupa comp.std.c.
Polecam.

-- 
gracjan ziółek
system administrator

>Zgadzam sie z bzdura i totalna ignorancja. Jest bardzo bardzo wiele rzeczy
>do ktorych metodologia OOP kompletnie sie nie nadaje, a co za tym idzie
>C++. Jest to juz bowiem jezyk o wiele wyzszego poziomu niz C i kompilator
>robi za nas mnostwo rzeczy. Np. zwijanie stosu przy obludze wyjatkow,
>albo obiekty tymczasowe. Jest to nie do pomyslenia w wielu systemach.
>Np. wyobrazcie sobie Linux Kernel w C++. Poza tym C++ nie jest do konca
>rozwiniete, nie ma pod niego naprawde dobrych kompilatorow, i ludzie
>po prostu boja sie pod tym pisac. Nie zastanawialiscie sie kiedys dlaczego
>tak malo dobrego oprogramowania Gnu jest tworzonego w C++ ? Prawie na
>palcach mozna policzyc.


Witam uprzejmie,
takie dwie uwagi: po pierwsze, stwierdzenie, ze w C++ da sie tylko
programowac obiektowo jest delikatnie mówiac nieprawdziwe. Dla Stroustrupa
mozliwosc programowania w wielu metodologiach, np. zgodnie z zasadami
programowania strukturalnego byla jednym z podstawowych zalozen przy
tworzeniu C++. Stepanov, twórca STL - najwazniejszej biblioteki ogólnego
zastosowania dla C++ - obwieszcza wszem i wobec ze nie lubi programowania
obiektowego i STL nie korzysta z dziedziczenia (moze cos sie tam znajdzie,
ale ogólne idee nie sa obiektowe).
"Kompilator robi za nas mnóstwo rzeczy" - jezeli o to poprosimy. Proponuje
dowolny program w C przekompilowac kompilatorem C++ - trzeba bedzie pewnie
dodac troche kastów itd. Jezeli w kodzie wynikowym znajdzie sie "zwijanie
stosu przy obsludze wyjatków" albo "obiekty tymczasowe" itd. to trzeba
wyrzucic ten kompilator, bo samowolnie dodal do kodu zródlowego obsluge
wyjatków, deklaracje klas i wyrazenia, w których wystepuja obiekty
tymczasowe.

Pozdrowienia,
WS

Cześć!

>Nie chodzi mi tylko o C /bedzie Ritchie w piekle/niebie (do wyboru) 
>za ten jezyk odpowiadal :)/, chodzi o ogolny poziom Twych wypowiedzi.

A Kernigham?

			Piotrek

Piotr Kuszewski <pkusze@sgh.waw.pl> napisal
> Cześć!
> 
> >Nie chodzi mi tylko o C /bedzie Ritchie w piekle/niebie (do wyboru) 
> >za ten jezyk odpowiadal :)/, chodzi o ogolny poziom Twych wypowiedzi.
> 
> A Kernigham?

On odpowie za wspoludzial.... :))

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Karpierz (karpierz@inter.intertele.pl) wrote:
: Marcin Laszewski <laser@priam.umcs.lublin.pl> napisal
: 
: [...]
: i co to pomoze ?
: zamieni Ci to Twoje malloct(type) na ((type *)malloc(sizeof(type)))
: _PRZED_ faktyczna kompilacja i problem pozostanie tylko, ze 
: Twoje slabe oczka tego nie dostrzega, jak zapewne i wiele innych
: "pierdol" w C/C++.

Moje oczka dostrzegaja, bo jak inaczej bym tego nie stosowal.
Jak Ty masz problem, przezuc sie na robienie rabatek bo wieksza
lopata od klawiatury.

: Dlaczego ?
: Bo my moze i jestesmy losiami, ale Ty napewno jestes 
: owieczka plci meskiej (pomine do ktorej potegi), a ten gatunek 
: ma slabe oczy... /za to mocne i twarde co innego..../

Wyslil sie na bardziej wiecej elokwencji.
 
: a wracajac do meritum juz lepiej stosuj tak (wg racji Pana Kotowskiego):
: 
: #ifdef __cplusplus
: #define	malloct(type)  ((type *)malloc(sizeof(type)))
: #else
: #define	malloct(type)  (malloc(sizeof(type)))
: #endif

ANSI tez wymaga jawnej konwersji, a ANSI to zwykle C bez plusow jak
bys nie wiedzial.
 
: PS: (bez obrazy prosze :). U mnie ze zlosliwoscia jak z nalogiem,
:        ciagle walcze... 
Nie walcz, syzyfowa praca.

:        Aha, jak myslisz ile widzialo sie kodu w ciagu 15 lat pisania
:        w C ?

Mam cos powiedziec o betonie?

:	Mowie tylko za siebie. A to jest nic w stosunku do
:        Pana Kotowskiego, ktory pisal ksiazki o C...

Lenin tez pisal duzo grubsze. Napisz i Ty ale to o niczego zmeni -
inni nie stana sie w ten sposob glupsi.

:	...gdy Ty zapewne sikales w pieluchy.

Trzymasz poziom. Jak ja sikalem w pieluchy to jeszcze C bylo w powijakach
(Beatlesi juz sie rozpadli).

:        Tak ze walnales jak w/w owieczka w mur...  

Powiadom policje.

: -- 
: Pozdrawiam                                         Adam Karpierz   

Obejdzie sie

On 29 Jan 1998, Marcin Laszewski wrote:

> Moje oczka dostrzegaja, bo jak inaczej bym tego nie stosowal.
> Jak Ty masz problem, przezuc sie na robienie rabatek bo wieksza
> lopata od klawiatury.
> 
> Wyslil sie na bardziej wiecej elokwencji.
> Nie walcz, syzyfowa praca.
> Mam cos powiedziec o betonie?
> Lenin tez pisal duzo grubsze. Napisz i Ty ale to o niczego zmeni -
> inni nie stana sie w ten sposob glupsi.
> :	...gdy Ty zapewne sikales w pieluchy.
> Trzymasz poziom. Jak ja sikalem w pieluchy to jeszcze C bylo w powijakach
> (Beatlesi juz sie rozpadli).
> :        Tak ze walnales jak w/w owieczka w mur...  
> Powiadom policje.
> : -- 
> : Pozdrawiam                                         Adam Karpierz   
> 
> Obejdzie sie


Eeeechh dzieciaki ... Ze Wam sie chce takie glupoty klepac...

A co do glownego watku to owszem, mozna se nawstawiac tyle makrodefinicji
ile dusza zapragnie. Tylko kto sie w tym polapie potem...

I owszem takie malloct jest wygodne bo o te 20 znakow mniej pisania.
Tylko jak sie potem pomyli Exc_SetLowByteToLowQuery z
Exc_SetLowCharToLowQuery to sam diabel potem nie dojdzie czemu wam sie
program chrzani. 

Zreszta zawsze twierdzilem ze nalezy robic tak jak to robia madrzejsi.
Wystarczy zobaczyc kod jakiegos wiekszego projektu i zerknac jak
programerzy z DECu stosuja makra. I czy tak zaciemniaja konwersje typow.

pozdrawiam
c.

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Marcin Laszewski <laser@priam.umcs.lublin.pl> napisal
> Karpierz (karpierz@inter.intertele.pl) wrote:
[...]
> : a wracajac do meritum juz lepiej stosuj tak 
> :(wg racji Pana Kotowskiego):
> : 
> : #ifdef __cplusplus
> : #define	malloct(type)  ((type *)malloc(sizeof(type)))
> : #else
> : #define	malloct(type)  (malloc(sizeof(type)))
> : #endif
> 
> ANSI tez wymaga jawnej konwersji, a ANSI to zwykle C 
> bez plusow jak bys nie wiedzial.

/Nie odpowiadal bym bo nie warto gdyby nie powyzsze zdanie.../

Malo ze sam zaczales obrazac ludzi od glupich (patrz 
poprzednie listy) to sam gadasz _chorendalne_ glupoty:

ANSI C _nie wymaga_  jawnej konwersji z void *.
Czy ktos ja stosuje jest wylacznie kwestia stylu.
Wez sobie doczytaj.

[...]

> :        Aha, jak myslisz ile widzialo sie kodu w ciagu 15 lat pisania
> :        w C ?
> 
> Mam cos powiedziec o betonie?

O sobie juz powiedziales wystarczajaco.. dziekujemy...

> :	Mowie tylko za siebie. A to jest nic w stosunku do
> :        Pana Kotowskiego, ktory pisal ksiazki o C...
> 
> Lenin tez pisal duzo grubsze. Napisz i Ty ale to o niczego zmeni -
> inni nie stana sie w ten sposob glupsi.

Nie martw sie... Od Ciebie napewno nie...

> :        Tak ze walnales jak w/w owieczka w mur...  
> 
> Powiadom policje.

Raczej Bakutil...

Karpierz <karpierz@inter.intertele.pl> wrote:

: Jeszcze jeden wszystkowiedzacy eh... Cos duzo tych owieczek ostatnio...
Coz... jak "pan" uwaza. IMHO dobrze jest czasem spojrzec tez obiektywnie
na siebie.

: Nawet nie bede sie silil odpowiedzec normalnie.
: Mysle ze troche zarozumialosci nie zaszkodzi... (za co innych przepraszam).
Tez tak mysle. Ale dlaczego "normalnie" ? Czy to cos zlego ? Czy tez uwaza
mnie "pan" za takiego niedorozwoja, ze nie warto z nim normalnie rozmawiac ?

: Jak myslisz "fachowcu" czy 7 latek w C++ (w moim przypadku)
: i w dwoch przypadkach stycznosc i kilkukletnia praca z kodami wielkosci 
: 3MB i 8MB zrodel to duzo czy malo zeby jednak chociaz troche lepiej od 
: Ciebie poznac te jezyk... ?
HA HA HA! Dobre sobie!
Ja moglbym przerobic i 20 GB kodu! I mysli pan moze, ze bylbym wtedy
ekspertem od tego jezyka ? Nawet po 20 latach pracy ?

IMHO: Nie staz i ilosc gigabajtow swiadczy o programiscie, lecz to, jak
zna on jezyk no i ... jak zna sie na programowaniu. Bo to sa - prawde mowiac
- dwie rozne rzeczy. O tym - mam nadzieje - "pan" wie.

: A i tak mi sie wydaje ze ciagle czegos nie wiem napewno...
: (np. mam klopoty ze skomplikowanymi "templatesami") i czesto siegam do
: Stroustrupa, Grebosza czy Hansena... (wg mnie te dwie ostatnie to chyba 
: najlepsze, a napewno najprzyjemniejsze polskojezyczne ksiazki do C++). 
Tia, szczegolnie ta Stroustrupa. Nie wiem, ktora pozycje ma pan na mysli
(bo widzialem juz ich kilka), ale jezeli ta pierwsza, "Jezyk C++" to po
prostu dziwie sie tylko, ze takie cos da sie trawic. Jest to owszem calkiem
niezla pozycja, jezeli ktos uwaza sie za prawie eksperta, ale na pewno
nie do nauki tego jezyka.

: Po czesci to wina wad samego jezyka (wcale nie jestem jego zagorzalym
: fanatykiem), a po czesci tego ze uwazam ze znajomosc C++ to nie sucha
: znajomosc gramatyki, ale "myslenie" w tym jezyku w sposob obiektowy, 
: czyli widzenie ("czucie") problemu przez pryzmat hierarchii obiektow 
: (w kontekscie jezyka). 
Ja za to - przyznam bez ukrycia - jestem zagorzalym zwolennikiem tego
jezyka i nauczylem sie juz myslec w sposob obiektowy. Przyznam, nie bez
problemow. Ale zrozumienie mechanizmow obiektowych, jak rowniez innych
ciekawych mechanizmow w C++ zajelo mi troche mniej, niz 7 lat.

: Przyznam sie ze z tym mam jeszcze ciagle klopoty 
: i dlatego uwazam ze pisze ciagle w sposob raczej "obiektawy" i nie jestem 
: specem w C++ (a gdzie mi do np. stosowania patterns... przygladam sie
: dopiero 
: w wolnych chwilach ACE...), 
Coz, ja - prawde mowiac - stosuje obiekty, jezeli musze i to calkiem
sporadycznie. Ja wcale nie mysle o tym, czy program pisze obiektowo, czy
jakos inaczej. Ja po prostu programuje. A co z tego wyjdzie zalezy od mojej
tworczosci.

: STL slabo jeszcze znam, z wyjatkow tez nie 
: korzystam nagminnie :), 
Wyjatki powinny byc wyjatkowe. W malych programach nie ma potrzeby z nich
korzystac. Ale dobrym pomyslem jest np. przetlumaczenie sygnalow na wyjatki.
Co prawda mechanizm sygnalow jest troche inny, niz wyjatkow, przede wszystkim
dlatego, ze handler sygnalu po zakonczeniu wraca do miejsca, z ktorego zostala
przerwana funkcja wywolujac handler. Natomiast wyjatek przerywa biezaca
funkcje i juz jej nie kontynuuje (dalej :). Nie przeszkadza to jednaj, bo
wyjatki ulegaja propagacji.

: z GUI tylko wxWindows i to tylko prywatnie a
: nie w pracy..., a gdzie CORBA , obiektowe bazy danych... RPC.. itp, itd...
Ech... prosze pana bo sie zaraz zalamie i pojde zebrac na centralny...

: Ze wspomne o metodologiach projektowania (te wszystkie Rationale, UML-e
: itp...). Szkoda mowic...
Pewnie ze szkoda. Czy nie lepiej sie skupic na jedynym slusznym C++ ?
Jeden jezyk, a mozliwosci wiele. Moze wiecej maja tylko jezyki tokenizowane.

: No dobra :)... koniec "moralizatorstwa dziadka". I tak to przeciez nic nie
: da.
Owszem. Ja mam swoje przyzwyczajenia i mnie nic nie przekabaci.

-- 
.---.     .   . - 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...

Maciej MOCHOL <mmochol@elka.pw.edu.pl> wrote:
: A co to sa te "patterns" ? Wyjatki rulez, tylko gcc je slabo wykorzystuje,
Jak to slabo ? Z wyjatkow albo sie korzysta, albo nie. Niestety trzeba
przyznac, ze wyjatki sa tak nowa rzecza, ze nie sa w ogole nalezycie
wykorzystane. Ale da sie przetlumaczyc sygnaly na wykatki.

: to jest minus... STL to standard template library ? To Cie rozumiem :-)
: Aha, co to jest to ACE, bo nie nadazam za TLSami.
: TLS=TrzyLiterowySkrot

Tak, uzywajcie ich jeszcze wiecej, to moze bedziecie bardziej elokwentni.

-- 
.---.     .   . - 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...

Karpierz <karpierz@inter.intertele.pl> wrote:
:> ANSI tez wymaga jawnej konwersji, a ANSI to zwykle C 
:> bez plusow jak bys nie wiedzial.

: /Nie odpowiadal bym bo nie warto gdyby nie powyzsze zdanie.../

: Malo ze sam zaczales obrazac ludzi od glupich (patrz 
: poprzednie listy) to sam gadasz _chorendalne_ glupoty:

: ANSI C _nie wymaga_  jawnej konwersji z void *.
: Czy ktos ja stosuje jest wylacznie kwestia stylu.
: Wez sobie doczytaj.
Musze tutaj przyznac racje. Niemniej jednaj poza tym wymaga sie konwersji.

:> :	Mowie tylko za siebie. A to jest nic w stosunku do
:> :        Pana Kotowskiego, ktory pisal ksiazki o C...
:> 
:> Lenin tez pisal duzo grubsze. Napisz i Ty ale to o niczego zmeni -
:> inni nie stana sie w ten sposob glupsi.

: Nie martw sie... Od Ciebie napewno nie...
Musze przyznac, ze wysilil sie "pan" (bo juz nie wiem, czy ktos sie
nie obrazi) na bardzo nieoryginalny komentarz. Rodem z podstawowki.

Czy nie moglaby byc to troche kulturalniejsza dyskusja ? Jezeli sie
uwazacie za takich ekspertow od programowania, to moze wykazcie sie
przede wszystkim kultura ? Przestancie mowic o sraniu w pieluchy,
pisaniu ksiazek, latach stazu i megabajtach kodu. Slowo wam daje,
ze nikogo w ten sposob o swojej wiedzy nie przekonacie.

Wykazcie sie jakas znajomoscia, wytlumaczcie, co wiecie itd. A jak
zamierzacie tutaj wywyzszac sie nad "malolatami" to lepiej zmiencie
grupe.

:> :        Tak ze walnales jak w/w owieczka w mur...  
:> 
:> Powiadom policje.

: Raczej Bakutil...

Ja proponuje powiadomic zaklad psychiatryczny. Skutek murowany.



-- 
.---.     .   . - 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...

Karpierz <karpierz@inter.intertele.pl> wrote:
: Ale nawet w C++ w poczatkowym okresie wielu ludzi ktorzy umia juz C 
: stosuje funkcje malloc bo ja zna poprostu i nie ma w tym nic dziwnego
: zreszta. Mowisz, ze nie wolno ? No to po coz znalazla sie ona w C++ ?
To ja panu powiem, dlaczego. Wynika to z tego, ze C++ jest nadzbiorem C
i kazda funkcja C jest dostepna w C++. I tylko dlatego sie tam znajduje.
Ale na pewno nie dlatego, zeby lamerstwo wychowane na C jej uzywalo
zamiast new.

: To ze jest to funkcja C nie znaczy ze nie wolno jej uzywac w C++.
Zgadza sie. Ale new ma troche wieksze znaczenie niz zwykla funkcja
i prosze o tym nie zapominac. Chocby kompilator odrzuci probe wywolania
jej dla abstrakcyjnej klasy.

: Pomimo, ze nalezy tego unikac na ile sie tylko da, to jednak
: sa czasem przypadki ze jest to wprost wymuszone.
: Pozostawiam Ci to jako zagadke...
Coz. Jezeli chodzi o zagadki to na razie w C++ nie widzialem godnych mnie
zagadek. Ta jest prosta.

Tylko mnogosc kodu do przepisania moze zmusic do unikania new (z przyczyn
technicznych - za duzo roboty). Poza tym nie widze powodu.

: Probowales przeniesc w rozsadnym czasie np 2 MB = ok 1200 stron
: kody zrodlowego z C na C++ ? 
Probowalem. Moze nie 2 MB, ale prawie 800 kilo. Jezeli cos to panu
mowi, to byl to mud. Akurat bylem na tyle glupi, ze wydawalo mi sie,
ze wystarczy pozamieniac zastrzezone slowa na cos innego i mud sie
skompiluje. Poza ustawicznie powtarzajacymi sie warningami, ze funkcja
alloc_mem zwraca nie taki wskaznik (mud posiada wlasny dyspozytor pamieci),
mialem tez pare bledow.

Tak tez nie da sie tego skompilowac na C++. I ja wlasnie od pewnego czasu
(z zadnym jak na razie skutkiem) probuje napisac to od nowa w C++ (bazujac
na tym, co juz jest napisane w C). Mimo to jednak nie zmienie swojego
zdania nt. C++.

: Sprobuj wytlumaczyc szefowi, ze liczac 10 stron dziennie
: przeniesienie kodu systemu na C++ zajmie Ci 120 dni nie 
: wliczajac w to dni wolnych i ze w tym czasie system nie bedzie mogl 
: byc serwisowany, bo nie bedzie sie kompilowal bo bedziesz musial 
: pozamieniac wszystkie malloc na new i free na delete i inne 
: w/g Ciebie "niedopuszczalne" w C++ konstrukcje. 
: Uslyszysz zapewne cos w rodzaju:

: "KTO PRZY ZDROWYCH ZMYSLACH napisal ten kod w C tak,
:  zeby tyle trwalo przenoszenie na C++ ktory przeciez 
:  jest wlasciwie nadzbiorem C."

To zalezy jakiego ma sie szefa.
Jezyk C++ jest nie do konca nadzbiorem C. I lepiej jest napisac to
specjalnie dla C++. Niektorym szefom to tez nie sposob wytlumaczyc,
ze administrator powinien zarabiac konkretne pieniadza. Dla niego
to przeciez on tylko siedzi i sie opieprza. Tak tez IMHO jest to tez
sprawa szefa.

:> IMHO jezyk C nadaje sie WYLACZNIE dla ludzi, ktorzy nie potrafia 
:> zrozumiec jezyka C++. 

: Tu dales przyklad totalnej BZDURY i SWOJEJ IGNORANCJI !!!

Tak ? Poprosze o cos wiecej, niz tylko napisane duzymi literami
pustoslowie. Bo - jak powiedzialem nizej, ...

:>Kazdy program, zamierzony do napisania w C, mozna napisac w 
:> C++

: Zareczam Ci, ze nie kazdy :).  Oczywiscie sa to szczegolne przypadki
: ale sie zdazaja.

Przyklad ? Bo ja sobie nie potrafie wyobrazic.
Chyba, ze lubuje sie pan w przystosowywaniu 200 MB kodu w C do jezyka
C++. Ale ja akurat nie o tym mowilem. 

-- 
.---.     .   . - 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...

Maciej MOCHOL <mmochol@elka.pw.edu.pl> wrote, a ja skomentuje, bo nie moge...
: Jedna sprawa panowie, odczepcie sie od tego malloc() bo to mieszanie
: pojec. Malloc jest funkcja POSIXowa, i kazdy uzywa malloc kto pisze 
: w C++, tyle ze niejawnie. Sa zreszta rozne malloce i zaleza one
: od strategi obslugi pamieci w C++ jaka przyjmiemy. Zrobienie wlasnego
: managera pamieci w C++ sprowadza sie zazwyczaj do zdefiniowania
: operatorow new.
Czy ty w ogole rozumiesz, o co chodzi ? KOGO obchodzi jak standartowo
jest zrobiony operator new w C++ ? My tutaj kolego mowimy o PRAWIDLOWOSCI
wywolania funkcji, a nie o PROBLEMACH W REALIZACJI WEWNETRZNEJ tego
zadania.

:> > IMHO jezyk C nadaje sie WYLACZNIE dla ludzi, ktorzy nie potrafia 
:> > zrozumiec jezyka C++. 
:> 
:> Tu dales przyklad totalnej BZDURY i SWOJEJ IGNORANCJI !!!
:> 
:> >Kazdy program, zamierzony do napisania w C, mozna napisac w 
:> > C++
:> 
:> Zareczam Ci, ze nie kazdy :).  Oczywiscie sa to szczegolne przypadki
:> ale sie zdazaja.
:> 

: Zgadzam sie z bzdura i totalna ignorancja. Jest bardzo bardzo wiele rzeczy
: do ktorych metodologia OOP kompletnie sie nie nadaje, a co za tym idzie
: C++. 

Chyle czola przed dwoma glupotami. Coz sprawa jest tak banalna, ze gdyby
nie rozmiar owej glupoty, to nawet nie mialoby sensu komentowanie tego.

Jak to jeden z was slusznie zauwazyl, jezyk C++ jest nadzbiorem C. Co
prawda nie pelnym, ale jest. Pytam was panowie: Czy MACIE ABSOLUTNY
OBOWIAZEK stosowania programowania obiektowego, piszac program w C++ ?
Zgadzam sie, ze do niektorych zagadnien OOP nie ma zastosowania. ALE
CZY KTOS WAM KAZE STOSOWAC OOP w C++ ? Juz to wczesniej mowilem, jezyk
C++ posiada tyle wspanialych udogodnien nawet bez stosowania OOP.
A obowiazek konwersji wskaznikow mozecie mu chyba wybaczyc.

: Jest to juz bowiem jezyk o wiele wyzszego poziomu niz C i kompilator
: robi za nas mnostwo rzeczy. Np. zwijanie stosu przy obludze wyjatkow,
: albo obiekty tymczasowe. 
Gwoli scislosci: C tez czasami tworzy obiekty tymczasowe, a to ile
rzeczy zrobi za nas kompilator zalezy tylko od tego, jak napiszemy program.

: Jest to nie do pomyslenia w wielu systemach.
: Np. wyobrazcie sobie Linux Kernel w C++. 
Nic nadzwyczajnego. Problem jest tylko jeden - mogloby to wymusic pisanie
wszystkich aplikacji w C++. A to nie kazdemu przychodzi latwo.

: Poza tym C++ nie jest do konca
: rozwiniete, nie ma pod niego naprawde dobrych kompilatorow, i ludzie
: po prostu boja sie pod tym pisac. 
Tak, musze przyznac, ze g++ to na prawde bardzo kiepski kompilator.
A tak na powaznie, to ludzie boja sie pod tym pisac, jezeli tego do konca
nie rozumieja. Ja osobiscie sie nie boje. Co prawda gdb stwarza mi
drobne problemy, ale mam nadzieje, ze niedlugo sie to zmieni.

: Nie zastanawialiscie sie kiedys dlaczego
: tak malo dobrego oprogramowania Gnu jest tworzonego w C++ ? Prawie na 
: palcach mozna policzyc.
Wynika to widocznie z tego, ze jest to jezyk dla wybranych. Albo...
sprawa moze tez byc innego rodzaju. Ja np. najpierw poznalem C++,
a potem dowiedzialem sie, ile z tych rzeczy nie mozna robic w C.
Dzieki temu w C++ jestem w swoim zywiole, a w duzych programach niestety
C mnie denerwuje. Chocby dlatego, ze musze strasznie duzo rzeczy robic
recznie.


-- 
.---.     .   . - 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...

Michal Malecki <sektor@zly.kis.p.lodz.pl> napisal
> Karpierz <karpierz@inter.intertele.pl> wrote:
> 
> : Jeszcze jeden wszystkowiedzacy eh... Cos duzo tych owieczek ostatnio...
> Coz... jak "pan" uwaza. IMHO dobrze jest czasem spojrzec tez obiektywnie
> na siebie.

Obiektywnie na siebie spojrzalem na koncu poprzedniego listu.
Wyliczylem dokladnie i szczerze mala czesc z tego czego nie umiem,
a i tak jest to zaledwie maly fragment czesc tego co powinien znac 
albo przynajmniej sie orientowac dobry programista... 

> : Nawet nie bede sie silil odpowiedzec normalnie.
> : Mysle ze troche zarozumialosci nie zaszkodzi... (za co innych
przepraszam).
> Tez tak mysle. Ale dlaczego "normalnie" ? Czy to cos zlego ? Czy tez
uwaza
> mnie "pan" za takiego niedorozwoja, ze nie warto z nim normalnie
rozmawiac ?

Uwazam Cie po prostu za pozbawionego kultury w dyskusji i zbyt 
zadufanego w swa wiedze mlodego zdolnego i niedoswiadczonego 
goscia (co nie przeczy Twej inteligencji) i dlatego taka "nienormalna"
byla moja odpowiedz, czyli w stylu w ktorym Ty zaczales.

> : Jak myslisz "fachowcu" czy 7 latek w C++ (w moim przypadku)
> : i w dwoch przypadkach stycznosc i kilkukletnia praca z kodami wielkosci

> : 3MB i 8MB zrodel to duzo czy malo zeby jednak chociaz troche lepiej od 
> : Ciebie poznac te jezyk... ?
> HA HA HA! Dobre sobie!
> Ja moglbym przerobic i 20 GB kodu! I mysli pan moze, ze bylbym wtedy
> ekspertem od tego jezyka ? Nawet po 20 latach pracy ?

Napewno wiekszym niz w tej chwili. Bo w tej chwili nawet nie czujesz 
co ta praktyka daje i nie czujesz czego nie umiesz i z tego sie bierze
Twoja zarozumialosc.  

> IMHO: Nie staz i ilosc gigabajtow swiadczy o programiscie, lecz to, jak
> zna on jezyk no i ... jak zna sie na programowaniu. Bo to sa - prawde
mowiac
> - dwie rozne rzeczy. O tym - mam nadzieje - "pan" wie.

Eh.. mlodziezy... :) Tez kiedys tak mi sie zdawalo ...

> : najlepsze, a napewno najprzyjemniejsze polskojezyczne ksiazki do C++). 
> Tia, szczegolnie ta Stroustrupa. Nie wiem, ktora pozycje ma pan na mysli
> (bo widzialem juz ich kilka), ale jezeli ta pierwsza, "Jezyk C++" to po
> prostu dziwie sie tylko, ze takie cos da sie trawic. 

Szkoda slow...  Jest tam taki rozdzial. Zwie sie "Raport jezyka".
Sprobuj go docenic.

>Jest to owszem calkiem niezla pozycja, jezeli ktos uwaza sie 
> za prawie eksperta, ale na pewno nie do nauki tego jezyka.

Dla ekspertow jest zdecydowanie smiesznie niewystarczajaca...
Ale Tobie i wszystkim (szczegolnie pracodawcom) polecam jeden 
rozdzial z tej ksiazki. 11. "Projektowanie i konstrukcja oprogramowania",
a w niej szczegolny podrozdzial 11.4.3 "Ludzie".. 
Tak trafne spostrzezenia mogl napisac tylko ktos kto naprawde jadl 
chleb z niejednego pieca i to nie tylko z perspektywy akademickiej. 

A tu przyklad "konsekwencji":
[...] napisales
> Ja za to - przyznam bez ukrycia - jestem zagorzalym zwolennikiem tego
> jezyka i nauczylem sie juz myslec w sposob obiektowy. Przyznam, nie bez
> problemow. Ale zrozumienie mechanizmow obiektowych, jak rowniez innych
> ciekawych mechanizmow w C++ zajelo mi troche mniej, niz 7 lat.
[...] a za chwile
> Coz, ja - prawde mowiac - stosuje obiekty, jezeli musze i to calkiem
> sporadycznie. Ja wcale nie mysle o tym, czy program pisze obiektowo, czy
> jakos inaczej. Ja po prostu programuje. A co z tego wyjdzie zalezy od
mojej
> tworczosci.

komentarz chyba zbyteczny

[...] 

> Wyjatki powinny byc wyjatkowe. 

Nie zgadzam sie. To bardzo dobry mechanizm i powinien byc
stosowany (zwlaszcza w jezykach obiektowych w polaczeniu
z "garbage collection") jak najczesciej.

[...]

> : z GUI tylko wxWindows i to tylko prywatnie a
> : nie w pracy..., a gdzie CORBA , obiektowe bazy danych... RPC.. itp,
itd...
> Ech... prosze pana bo sie zaraz zalamie i pojde zebrac na centralny...

Twoj wybor :) ale nie lepiej poswiecic jeszcze kilka latek na nauke ? :)

> : Ze wspomne o metodologiach projektowania (te wszystkie Rationale, UML-e
> : itp...). Szkoda mowic...
> Pewnie ze szkoda. Czy nie lepiej sie skupic na jedynym slusznym C++ ?
> Jeden jezyk, a mozliwosci wiele. Moze wiecej maja tylko jezyki
tokenizowane.

Nie lepiej, jezyki tez przemijaja. Jezyk to tylko narzedzie i tak je nalezy
traktowac. Nie ma narzedzi slusznych do wszystkiego.
Sprobuj napisac np system ekspertowy nie w Lispie czy w Prologu
a w C, lub sprobuj napisac kernel Linuxa w SQL-u albo w UML-u...

Co rozumioesz pod pojeciem "jezyki tokenizowane" ?

Istnieje cale mnostwo starych i nowych jezykow ktore maja wieksze
mozliwosci od C++. I C++ raczej w sensie formalnym i mozliwosci
zostaje w tyle. Gdzie indziej tkwi przyczyna sily i popularnosci C++.

> Owszem. Ja mam swoje przyzwyczajenia i mnie nic nie przekabaci.

Zycie czyli praca, praktyka, szefowie , zona itd/itp :)
Porozmawiamy za kilka lat...

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Wojtek Surowka <WojtekS@aldec.katowice.pl> wrote:
: takie dwie uwagi: po pierwsze, stwierdzenie, ze w C++ da sie tylko
: programowac obiektowo jest delikatnie mówiac nieprawdziwe. Dla Stroustrupa
: mozliwosc programowania w wielu metodologiach, np. zgodnie z zasadami
: programowania strukturalnego byla jednym z podstawowych zalozen przy
: tworzeniu C++. Stepanov, twórca STL - najwazniejszej biblioteki ogólnego
: zastosowania dla C++ - obwieszcza wszem i wobec ze nie lubi programowania
: obiektowego i STL nie korzysta z dziedziczenia (moze cos sie tam znajdzie,
: ale ogólne idee nie sa obiektowe).
Ciesze sie, ze tak dokladnie owa zasade wyjasniles, juz sie obawialem,
ze moje argumenty niespecjalnie beda trafiac. Coz, jest jeszcze wielu
ludzi, ktorzym sie wydaje, ze jak ktos uzywa C++, to juz programuje
obiektowo.

: "Kompilator robi za nas mnóstwo rzeczy" - jezeli o to poprosimy. Proponuje
: dowolny program w C przekompilowac kompilatorem C++ - trzeba bedzie pewnie
: dodac troche kastów itd. 
No... nie tak do konca dowolny. Ale wiekszosc krotkich programow nie powinna
sprawiac klopotow.

Najwazniejsza cehca jezyka C++ jest nie obiektowosc - jak sie niektorym
wydaje - ale to, ze istnieje w nim wiele rzeczy, ktore wykonuja sie
niejawnie. Niemniej jednak dobry programista wie o wszystkich sztuczkach,
jakie stosuje kompilator. Dlatego jest to nie tak do konca jezzyk wysokiego
poziomu. Ktos sie ze mna nie zgadza ? 

: Jezeli w kodzie wynikowym znajdzie sie "zwijanie
: stosu przy obsludze wyjatków" albo "obiekty tymczasowe" itd. to trzeba
: wyrzucic ten kompilator, bo samowolnie dodal do kodu zródlowego obsluge
: wyjatków, deklaracje klas i wyrazenia, w których wystepuja obiekty
: tymczasowe.

Dobre kompilatory wymagaja flag dla dolaczania roznych dodatkowych rzeczy.
Ewentualnie same wiedza, zeby dolaczyc (g++ wymaga np do obslugi wyjatkow
-fhandle-exceptions). 


-- 
.---.     .   . - 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...

Mirek Prywata <mpry@fuw.edu.pl> wrote:
: [...]
:> do programowania strukturalnego ? Ale jak najbardziej sie nadaje!
:> IMHO jezyk C nadaje sie WYLACZNIE dla ludzi, ktorzy nie potrafia zrozumiec
:> jezyka C++. [...]

: A to juz bardzo smiale zdanie. Wyglada to na zdanie kogos, kto sie
: nauczyl (i zrozumial ??) C++ i zachlysnal sie nim. Otoz nie zawsze
: nalezy wytaczac dzialo to zabicia muchy. 
Niespecjalnie jest to stwierdzenie szczesliwe akurat tutaj.

: A o jezykach takich  jak Perl
: slyszales? Po co na przyklad prosty programik typu
: getchar();...putchar(); pisac w C++. 
Roznica jest niewielka. Zgadzam sie. Tyle tylko, ze czlowiek ma swoje
przyzwyczajenia.

Nie zauwazyles np., ze C wymaga deklaracji wszystkich zmiennych na poczatku
bloku, a C++ gdziekolwiek w bloku ?

Jedyna zaleta C nad C++ (powtarzam: JEDYNA) to to, ze wymaga mniej pamieci
i programy sie szybciej kompiluja. W wiekszosci wypadkow nie ma to znaczenia.

: A dlaczego nie warto do niektorych
: rzeczy uzywac C, tylko latwiej napisac prosty programik w perlu? A po co
: np. pisac program, skoro akurat takie zadanie da sie wykonac jako skrypt
: shella? Nie dopasowuj zycia do Twojego ukochanego jezyka, tylko jezyki
: programowania, ktorych uzywasz, do zadan, ktore maja wykonac.
No coz, jak sie nie zna C++, to sie pisze takie bzdury. Czy tobie sie
wydaje, ze pisanie w C++ zamiast w C, to tak jakby pisac w C zamiast
w perlu czy w shellu ? Chyba mylisz pojecia.
Pamietaj np. ze wiele rzeczy duzo latwiej jest napisac w shellu, niz w C.
Przyklad: z mojego konta odpalam muda. Jak robi sie reboot, to program sie
sklada, a potem odpala sie na nowo. Ale nie sam. Wstaje jezeli postawi
go specjalnie do tego celu napisany skrypt. Jak mialbym ten skrypt do
startowania napisac w C, czy C++, to chyba bym predzej glowa mur przebil.
A robi on pare dodatkowych czynnosci, np. przy ewentualnym core produkuje
odpowiedni raport, zmienia kod na nowy, jezeli jest itd. No i odpala muda.
W C byloby to straszliwie ciezkie do napisania (co nie znaczy, ze niemozliwe).

Podalem drobny przyklad, kiedy stosowac skrypty.

Ale zapamietaj, ze __NIE_MA__ takiego problemu, do ktorego lepiej stosowac
C, niz C++. 



-- 
.---.     .   . - 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...

On 29 Jan 1998, Michal Malecki wrote:
>: Zgadzam sie z bzdura i totalna ignorancja. Jest bardzo bardzo wiele rzeczy
>: do ktorych metodologia OOP kompletnie sie nie nadaje, a co za tym idzie
>: C++. 
>Chyle czola przed dwoma glupotami. Coz sprawa jest tak banalna, ze gdyby
>nie rozmiar owej glupoty, to nawet nie mialoby sensu komentowanie tego.
A co w tym, co on powiedzial jest takiego glupiego ?

>prawda nie pelnym, ale jest. Pytam was panowie: Czy MACIE ABSOLUTNY
>OBOWIAZEK stosowania programowania obiektowego, piszac program w C++ ?
Nie, ale programujac nieobiektowo wole do tego celu uzywac C.

>: Jest to nie do pomyslenia w wielu systemach.
>: Np. wyobrazcie sobie Linux Kernel w C++. 
>Nic nadzwyczajnego. Problem jest tylko jeden - mogloby to wymusic pisanie
>wszystkich aplikacji w C++. A to nie kazdemu przychodzi latwo.
Hihihihihi ! Jak dla mnie to bylby czas apokalipsy...

>Dzieki temu w C++ jestem w swoim zywiole, a w duzych programach niestety
>C mnie denerwuje. Chocby dlatego, ze musze strasznie duzo rzeczy robic
>recznie.
Nasuwa mi sie tutaj analogia pomiedzy Windowsami a Linuxem (bardzo
czesto podejmowana na pl.comp.os.advocacy). W Linuxie trzeba robic
duzo rzeczy recznie, ale jak juz to zrobic, to wiesz, ze wszystko
bedzie Ci dzialac. Z kolei w Windowsach nie wszystko trzeba robic
recznie, ale wszyscy wiemy jak to sie czasami konczy.

Kris
-- 
Krzysztof G. Baranowski - Prezes Klubu Nieszkodliwych Manjaków
"Smith & Wesson - The original point and click interface..."
http://www.knm.org.pl/              <prezes@manjak.knm.org.pl>

On 29 Jan 1998, Michal Malecki wrote:
>Jedyna zaleta C nad C++ (powtarzam: JEDYNA) to to, ze wymaga mniej pamieci
>i programy sie szybciej kompiluja. W wiekszosci wypadkow nie ma to znaczenia.
I to nie ma znaczenia ?!?!? Chyba nam sie rodzi kolejny Bill Gates... ;-)

>Ale zapamietaj, ze __NIE_MA__ takiego problemu, do ktorego lepiej stosowac
>C, niz C++. 
Jest... The Linux Kernel na przyklad.

Kris
-- 
Krzysztof G. Baranowski - Prezes Klubu Nieszkodliwych Manjaków
"Smith & Wesson - The original point and click interface..."
http://www.knm.org.pl/              <prezes@manjak.knm.org.pl>

Maciej MOCHOL <mmochol@elka.pw.edu.pl> napisal
[...]
> A Lipmana widziales ? Kumpel Stroustrupa. Calkiem niezly.

Nie. Nie mam i nie zetknalem sie, chociaz slyszalem ze to tez
wlasciwie standard i az wstyd nie miec jesli ktos pisze w C++. 
Ale jesli polecasz sprobuje zdobyc. 
Napisz moze w dwoch zdaniach dlaczego ja polecasz jesli
Ci to nie sprawi klopotu ?

[...]

> A co to sa te "patterns" ? Wyjatki rulez, tylko gcc je slabo
wykorzystuje,
> to jest minus... 

Zgadzam sie. To bardzo cenny i od dawna przynajmniej przeze mnie
"oczekiwany" mechanizm.
Borland tez ma niekiedy narowy z wyjatkami (v.4.5).
Ale jest juz gcc 8.0.0. Zapewne systuacja sie poprawila.

>STL to standard template library ? To Cie rozumiem :-)
> Aha, co to jest to ACE, bo nie nadazam za TLSami.

ACE jest jedna z bibliotek realizujacych "design patterns" czyli 
wzorce projektowe. Ale oczywiscie pakietow "pattern" jest wiele
z tym ze ACE jest darmowa. Nie wiem czy najlepsza czy najgorsza
po prostu wpadla mi w rece.
Panuje opinia (nie wiem czy sluszna, do takich radykalizmow 
podchodze z zasady z ostroznoscia) , ze kto nie zna "paterns" 
ten dzis nie moze powiedziec ze programuje w C++.
Wzorce projektowe to cos wiecej niz sama biblioteka. 
To ogolnie reguly projektowania programu i rozwiazywania 
problemow programistycznych (biblioteka daje tylko narzedzia do 
realizacji tego), ale rowniez przenoszace sie na sposob pisania 
programow w konkretnym jezyku. Ale sam jestem za cienki na razie 
aby Ci cos wiecej powiedziec bo moge nagadac glupot. 
Nie mam jeszcze czucia tego tematu. 
Moze ktos z doswiadczeniem sie wypowie. 
Chociaz to raczej temat na pl.comp.objects

> PS. TLS=TrzyLiterowySkrot

Masz racje z tymi skrotami :). 
Sam sie zastanawialem co to TLS zanim sie przeczytalam PS :)

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Karpierz <karpierz@inter.intertele.pl> napisal
> Marcin Laszewski <laser@priam.umcs.lublin.pl> napisal
[...]
> > Lenin tez pisal duzo grubsze. Napisz i Ty ale to o niczego zmeni -
> > inni nie stana sie w ten sposob glupsi.
> 
> Nie martw sie... Od Ciebie napewno nie...
> 
> > :        Tak ze walnales jak w/w owieczka w mur...  
> > 
> > Powiadom policje.
> 
> Raczej Bakutil...

Z tym Bakutilem wyraznie przesadzilem, przepraszam.

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

On 29 Jan 1998, Michal Malecki wrote:

> : to jest minus... STL to standard template library ? To Cie rozumiem :-)
> : Aha, co to jest to ACE, bo nie nadazam za TLSami.
> : TLS=TrzyLiterowySkrot
> 
> Tak, uzywajcie ich jeszcze wiecej, to moze bedziecie bardziej elokwentni.
> 

Nie chwal sie lamerstwem, Sektorze.

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

On 29 Jan 1998, Michal Malecki wrote:

> Ja moglbym przerobic i 20 GB kodu! I mysli pan moze, ze bylbym wtedy
> ekspertem od tego jezyka ? Nawet po 20 latach pracy ?

Wtedy bylbys. Po 20 GB glupot bys nie gadal.

> 
> IMHO: Nie staz i ilosc gigabajtow swiadczy o programiscie, lecz to, jak
> zna on jezyk no i ... jak zna sie na programowaniu. Bo to sa - prawde mowiac
> - dwie rozne rzeczy. O tym - mam nadzieje - "pan" wie.

Jezyka mozna sie nauczyc na 2 sposoby. Piszac programy i czytajac
dobre kody. 

> Tia, szczegolnie ta Stroustrupa. Nie wiem, ktora pozycje ma pan na mysli
> (bo widzialem juz ich kilka), ale jezeli ta pierwsza, "Jezyk C++" to po
> prostu dziwie sie tylko, ze takie cos da sie trawic. Jest to owszem calkiem
> niezla pozycja, jezeli ktos uwaza sie za prawie eksperta, ale na pewno
> nie do nauki tego jezyka.

Strostrup wymyslil ten jezyk. W tej ksiazce jest raport jezyka, i dla 
C++ jest ona tym czym dla C K&R's Ansi C. Jesli ktos jej nie rozumie
to nie ma sie czym chwalic.

> Ja za to - przyznam bez ukrycia - jestem zagorzalym zwolennikiem tego
> jezyka i nauczylem sie juz myslec w sposob obiektowy. Przyznam, nie bez
> problemow. Ale zrozumienie mechanizmow obiektowych, jak rowniez innych
> ciekawych mechanizmow w C++ zajelo mi troche mniej, niz 7 lat.

Tak Ci sie tylko wydaje. Znasz metodologie OOP ? Wiesz co to sa diagramy
... tego, jak mu tam... Verdiego ? Albo potrafisz powiedziec kiedy
nalezy uzywac wielodziedziczenia, a kiedy nie, jak go uzywac, jak
odczytywac diagram zbiorow wylaczajacych (a la Murray) i dlaczego
mozna sie wlasciwie obyc bez niego ?

> Coz, ja - prawde mowiac - stosuje obiekty, jezeli musze i to calkiem
> sporadycznie. Ja wcale nie mysle o tym, czy program pisze obiektowo, czy
> jakos inaczej. Ja po prostu programuje. A co z tego wyjdzie zalezy od mojej
> tworczosci.

Przed chwila mowiles ze znasz sie na obiektach. W/g Ciebie to znaczy
wiedziec do czego jest klauzula public ?

> Wyjatki powinny byc wyjatkowe. W malych programach nie ma potrzeby z nich
> korzystac. Ale dobrym pomyslem jest np. przetlumaczenie sygnalow na wyjatki.
> Co prawda mechanizm sygnalow jest troche inny, niz wyjatkow, przede wszystkim
> dlatego, ze handler sygnalu po zakonczeniu wraca do miejsca, z ktorego zostala
> przerwana funkcja wywolujac handler. Natomiast wyjatek przerywa biezaca
> funkcje i juz jej nie kontynuuje (dalej :). Nie przeszkadza to jednaj, bo
> wyjatki ulegaja propagacji.

Ty chyba na oczy wyjatkow nie widziales i nie wiesz do czego sluza.
Wiesz tylko jak dzialaja.

> : z GUI tylko wxWindows i to tylko prywatnie a
> : nie w pracy..., a gdzie CORBA , obiektowe bazy danych... RPC.. itp, itd...
> Ech... prosze pana bo sie zaraz zalamie i pojde zebrac na centralny...

Pewnie tam wyladujesz z takim podejsciem.

> 
> : Ze wspomne o metodologiach projektowania (te wszystkie Rationale, UML-e
> : itp...). Szkoda mowic...
> Pewnie ze szkoda. Czy nie lepiej sie skupic na jedynym slusznym C++ ?
> Jeden jezyk, a mozliwosci wiele. Moze wiecej maja tylko jezyki tokenizowane.

O matko...

> 
> : No dobra :)... koniec "moralizatorstwa dziadka". I tak to przeciez nic nie
> : da.
> Owszem. Ja mam swoje przyzwyczajenia i mnie nic nie przekabaci.

Yeah. Jak Klapouch z Chatki Puchatka.

pozdrawiam
c.

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Przyznam ze poczatkowo Twoje posty mnie wkurzaly, ale teraz
powoli to sie robi zabawne. Przypominasz mi chakera, ktory 
wlasnie sie nauczyl kompilowac exploity.

On 29 Jan 1998, Michal Malecki wrote:

> Czy ty w ogole rozumiesz, o co chodzi ? KOGO obchodzi jak standartowo
> jest zrobiony operator new w C++ ? My tutaj kolego mowimy o PRAWIDLOWOSCI
> wywolania funkcji, a nie o PROBLEMACH W REALIZACJI WEWNETRZNEJ tego
> zadania.

Standar_d_owo kotku. Standardowo. Jak jest zrobiony operator new, he he...

> : Zgadzam sie z bzdura i totalna ignorancja. Jest bardzo bardzo wiele rzeczy
> : do ktorych metodologia OOP kompletnie sie nie nadaje, a co za tym idzie
> : C++. 
> 
> Chyle czola przed dwoma glupotami. Coz sprawa jest tak banalna, ze gdyby
> nie rozmiar owej glupoty, to nawet nie mialoby sensu komentowanie tego.

He he... Glupota powiadasz...

> 
> Jak to jeden z was slusznie zauwazyl, jezyk C++ jest nadzbiorem C. Co
> prawda nie pelnym, ale jest. Pytam was panowie: Czy MACIE ABSOLUTNY
> OBOWIAZEK stosowania programowania obiektowego, piszac program w C++ ?
> Zgadzam sie, ze do niektorych zagadnien OOP nie ma zastosowania. ALE
> CZY KTOS WAM KAZE STOSOWAC OOP w C++ ? Juz to wczesniej mowilem, jezyk
> C++ posiada tyle wspanialych udogodnien nawet bez stosowania OOP.
> A obowiazek konwersji wskaznikow mozecie mu chyba wybaczyc.

To programowania w czystym C, to poza tym ze trzeba stosowac prototypy,
to tych wspanialych udogodnien cos sobie wyobrazic nie moge. Poza tym
kwestia optymalizacji i rezygnacji z udogodnien zwyklych kompilatorow
C.

> 
> : Jest to juz bowiem jezyk o wiele wyzszego poziomu niz C i kompilator
> : robi za nas mnostwo rzeczy. Np. zwijanie stosu przy obludze wyjatkow,
> : albo obiekty tymczasowe. 
> Gwoli scislosci: C tez czasami tworzy obiekty tymczasowe, a to ile
> rzeczy zrobi za nas kompilator zalezy tylko od tego, jak napiszemy program.

Chyba nie zrozumiales... ale to szczegol...

> 
> : Jest to nie do pomyslenia w wielu systemach.
> : Np. wyobrazcie sobie Linux Kernel w C++. 
> Nic nadzwyczajnego. Problem jest tylko jeden - mogloby to wymusic pisanie
> wszystkich aplikacji w C++. A to nie kazdemu przychodzi latwo.

He he... Nic nadzwyczajnego. Kernel wymusza programowanie w C++ hehe...

> 
> : Poza tym C++ nie jest do konca
> : rozwiniete, nie ma pod niego naprawde dobrych kompilatorow, i ludzie
> : po prostu boja sie pod tym pisac. 
> Tak, musze przyznac, ze g++ to na prawde bardzo kiepski kompilator.

> A tak na powaznie, to ludzie boja sie pod tym pisac, jezeli tego do konca

Hehe, faktycznie, zart przedni

> nie rozumieja. Ja osobiscie sie nie boje. Co prawda gdb stwarza mi
> drobne problemy, ale mam nadzieje, ze niedlugo sie to zmieni.

UUahahaha... rozmiesz C++ tylko GDB stwarza drobne problemy... 

> Wynika to widocznie z tego, ze jest to jezyk dla wybranych. Albo...

Heheheheh, uuuahahahaa Pewnie goscie pokroju Linusa sa za glupi zeby
zrozumiec :)))

> sprawa moze tez byc innego rodzaju. Ja np. najpierw poznalem C++,
> a potem dowiedzialem sie, ile z tych rzeczy nie mozna robic w C.

Taaaa... moze to tlumaczy....

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

On 30 Jan 1998, Karpierz wrote:

> Nie. Nie mam i nie zetknalem sie, chociaz slyszalem ze to tez
> wlasciwie standard i az wstyd nie miec jesli ktos pisze w C++. 
> Ale jesli polecasz sprobuje zdobyc. 
> Napisz moze w dwoch zdaniach dlaczego ja polecasz jesli
> Ci to nie sprawi klopotu ?
> 
> [...]

Nie miesza tak jak Stroustrup... Latwiej sie go czyta, a efekt jest
ten sam.

> Ale jest juz gcc 8.0.0. Zapewne systuacja sie poprawila.

8.0.0 !!??? 

> ACE jest jedna z bibliotek realizujacych "design patterns" czyli 
> wzorce projektowe. Ale oczywiscie pakietow "pattern" jest wiele
> z tym ze ACE jest darmowa. Nie wiem czy najlepsza czy najgorsza
> po prostu wpadla mi w rece.

A skad to mozna sciagnac ?

> 
> -- 
> Pozdrawiam                                         Adam Karpierz   
> mailto:karpierz@intertele.pl
> http://www.intertele.pl/users/karpierz 
> 
> 

...rowniez
c.

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

On Fri, 30 Jan 1998, Maciej MOCHOL wrote:
>Nie miesza tak jak Stroustrup... Latwiej sie go czyta, a efekt jest
>ten sam.
>> Ale jest juz gcc 8.0.0. Zapewne systuacja sie poprawila.
>8.0.0 !!??? 
Pomylilo mu sie, chodzi o 2.8.0.

Kris
-- 
Krzysztof G. Baranowski - Prezes Klubu Nieszkodliwych Manjaków
"Smith & Wesson - The original point and click interface..."
http://www.knm.org.pl/              <prezes@manjak.knm.org.pl>

Michal Malecki wrote:
[...rozne bzdury...]

Chlopiec nauczyl sie obslugiwac mlotek i wydaje mu sie, ze podbije tym
caly swiat. Powodzenia.

-- 
gracjan ziółek
system administrator

Maciej MOCHOL <mmochol@elka.pw.edu.pl> napisal
[...]
> > Ale jest juz gcc 8.0.0. Zapewne systuacja sie poprawila.
> 
> 8.0.0 !!??? 

Hihi :) No lekko przesadzilem :) 
Oczywiscie 2.8.0.0

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

On 29 Jan 1998 19:19:16 GMT, Michal Malecki <sektor@zly.kis.p.lodz.pl>
wrote:

>Wyjatki powinny byc wyjatkowe. W malych programach nie ma potrzeby z nich
>korzystac. Ale dobrym pomyslem jest np. przetlumaczenie sygnalow na wyjatki.
>Co prawda mechanizm sygnalow jest troche inny, niz wyjatkow, przede wszystkim
>dlatego, ze handler sygnalu po zakonczeniu wraca do miejsca, z ktorego zostala
>przerwana funkcja wywolujac handler. Natomiast wyjatek przerywa biezaca
>funkcje i juz jej nie kontynuuje (dalej :). Nie przeszkadza to jednaj, bo
>wyjatki ulegaja propagacji.

 Co wspominane tu wyjatki maja wspolnego z wyjatkami zglaszanymi
sprzetowo ( np. przy dzieleniu przez zero ) ? Z wczesniejszej dyskusji
wnioskuje, ze nie chodzi o to samo...

milosz danielewski

On Thu, 29 Jan 1998, Krzysztof G. Baranowski wrote:

> Nasuwa mi sie tutaj analogia pomiedzy Windowsami a Linuxem (bardzo
> czesto podejmowana na pl.comp.os.advocacy). W Linuxie trzeba robic
> duzo rzeczy recznie, ale jak juz to zrobic, to wiesz, ze wszystko
> bedzie Ci dzialac. Z kolei w Windowsach nie wszystko trzeba robic
> recznie, ale wszyscy wiemy jak to sie czasami konczy.

Z tym że w C++ w odróżnieniu od Windowsów raczej _mogę_ wszystko robić
ręcznie, jeśli mam na to ochotę, nieprawdaż? Nikt nie zmusza do
stosowania obiektów.

Dlaczego uważasz, że jądra Linuxa nie dałoby się pisać w C++?

Czy znasz jakieś inne przykłady programów, do których C++ miałby się nie
nadawać? Jądro systemu operacyjnego to nie jest przecież taki sam
program jak każdy inny!

-- 
                                 QRCZAK
    __("<              Marcin Kowalczyk
    \__/              qrczak@knm.org.pl
     ^^      http://qrczak.home.ml.org/

On Sat, 31 Jan 1998, Qrczak wrote:
>Dlaczego uważasz, że jądra Linuxa nie dałoby się pisać w C++?
Wszystko daloby sie napisac, ale po co. C ma lepszy kompilator, 
generuje mniejszy, szybszy kod. Jak ktos poprzednio napisal w
<6aqpca$p7k@polonez.man.lodz.pl>:

>Jedyna zaleta C nad C++ (powtarzam: JEDYNA) to to, ze wymaga mniej pamieci
>i programy sie szybciej kompiluja. W wiekszosci wypadkow nie ma to znaczenia.

Przerazily mnie te slowa, szczegolnie ostatnie zdanie. :-)

Kris
-- 
Krzysztof G. Baranowski - Prezes Klubu Nieszkodliwych Manjaków
"Smith & Wesson - The original point and click interface..."
http://www.knm.org.pl/              <prezes@manjak.knm.org.pl>

On Fri, 30 Jan 1998 15:23:53 +0100, in pl.comp.lang.c Maciej MOCHOL
<mmochol@elka.pw.edu.pl> wrote:

>On 29 Jan 1998, Michal Malecki wrote:
>> Owszem. Ja mam swoje przyzwyczajenia i mnie nic nie przekabaci.
>
>Yeah. Jak Klapouch z Chatki Puchatka.
Nie obrażaj Kłapouchego, bo był znacznie sympatyczniejszy.

Hobbit

--
-------------------------------------|
Krzysztof Swiatkowski - Lodz, Poland | replying cut bezspam from my address
e-Mail:  hobbit@dom.vr.pl.bezspam    | odpowiadajac usun bezspam z adresu

Life is a tragedy for those who feel and a comedy for those who think

Karpierz <karpierz@inter.intertele.pl> wrote:
: Uwazam Cie po prostu za pozbawionego kultury w dyskusji i zbyt 
: zadufanego w swa wiedze mlodego zdolnego i niedoswiadczonego 
: goscia (co nie przeczy Twej inteligencji) i dlatego taka "nienormalna"
: byla moja odpowiedz, czyli w stylu w ktorym Ty zaczales.
Ma pan absolutna racje.

:> : Jak myslisz "fachowcu" czy 7 latek w C++ (w moim przypadku)
:> : i w dwoch przypadkach stycznosc i kilkukletnia praca z kodami wielkosci

:> : 3MB i 8MB zrodel to duzo czy malo zeby jednak chociaz troche lepiej od 
:> : Ciebie poznac te jezyk... ?
:> HA HA HA! Dobre sobie!
:> Ja moglbym przerobic i 20 GB kodu! I mysli pan moze, ze bylbym wtedy
:> ekspertem od tego jezyka ? Nawet po 20 latach pracy ?

: Napewno wiekszym niz w tej chwili. Bo w tej chwili nawet nie czujesz 
: co ta praktyka daje i nie czujesz czego nie umiesz i z tego sie bierze
: Twoja zarozumialosc.
A wcale niekoniecznie!
Ja rozumiem, jezeli sie te iles megabajtow kodu napisze samemu. I przerobi
sie najrozniejsze metodologie programowania. Ale to JAKOSC, a nie ILOSC
tej pracy "swiadczy". I wylacznie to mialem na mysli.

:> IMHO: Nie staz i ilosc gigabajtow swiadczy o programiscie, lecz to, jak
:> zna on jezyk no i ... jak zna sie na programowaniu. Bo to sa - prawde
: mowiac
:> - dwie rozne rzeczy. O tym - mam nadzieje - "pan" wie.

: Eh.. mlodziezy... :) Tez kiedys tak mi sie zdawalo ...
No coz... i znow wprowadzilem nieporozumienie piszac trzy rzeczy i dodajac
"to sa dwie rozne rzeczy". Mnie oczywiscie chodzilo o rozroznienie
znajomosci jezyka i znajomosci programowania. Przeciez chyba pan nie
zaprzeczy.

: Szkoda slow...  Jest tam taki rozdzial. Zwie sie "Raport jezyka".
: Sprobuj go docenic.

:>Jest to owszem calkiem niezla pozycja, jezeli ktos uwaza sie 
:> za prawie eksperta, ale na pewno nie do nauki tego jezyka.
Jak ja owa ksiazke pierwszy raz wzialem do reki, to sie przerazilem. Mimo,
ze akurat wtedy znalem C++ juz w miare dobrze. Ale przerazilem sie, jak
zareagowalby ktos, kto sie pierwszy raz z tym jezykiem zetknal.

: Dla ekspertow jest zdecydowanie smiesznie niewystarczajaca...
A ciekaw jestem dlaczego ? Czy brakuje tam jakichs szczegolow na temat
jezyka ?
Z tego co sie orientuje, ksiazka ta jest o mozliwosciach jezyka, a nie o
metodologiach programowania.

: Ale Tobie i wszystkim (szczegolnie pracodawcom) polecam jeden 
: rozdzial z tej ksiazki. 11. "Projektowanie i konstrukcja oprogramowania",
: a w niej szczegolny podrozdzial 11.4.3 "Ludzie".. 
: Tak trafne spostrzezenia mogl napisac tylko ktos kto naprawde jadl 
: chleb z niejednego pieca i to nie tylko z perspektywy akademickiej. 
Ano domyslam sie. Juz od jakiegos czasu zamierzam sie na ta ksiazke. Ale
ciagle cos mi w tym przeszkadza (wszystko by bylo juz ok, gdyby nie brak kasy).

: A tu przyklad "konsekwencji":
: [...] napisales
:> Ja za to - przyznam bez ukrycia - jestem zagorzalym zwolennikiem tego
:> jezyka i nauczylem sie juz myslec w sposob obiektowy. Przyznam, nie bez
:> problemow. Ale zrozumienie mechanizmow obiektowych, jak rowniez innych
:> ciekawych mechanizmow w C++ zajelo mi troche mniej, niz 7 lat.
: [...] a za chwile
:> Coz, ja - prawde mowiac - stosuje obiekty, jezeli musze i to calkiem
:> sporadycznie. Ja wcale nie mysle o tym, czy program pisze obiektowo, czy
:> jakos inaczej. Ja po prostu programuje. A co z tego wyjdzie zalezy od
: mojej
:> tworczosci.
: komentarz chyba zbyteczny

Mozliwe. Ale moim zdaniem cale cytowanie bylo zbyteczne. I to ma byc przyklad
konsekwencji (lub nie) ?


:> Wyjatki powinny byc wyjatkowe. 

: Nie zgadzam sie. To bardzo dobry mechanizm i powinien byc
: stosowany (zwlaszcza w jezykach obiektowych w polaczeniu
: z "garbage collection") jak najczesciej.

A ja sie zgadzam. Co prawda powinny byc stosowane, ale tylko do tego,
zeby zuniwersalizowac obsluge bledow. I tu - zgadzam sie, ze jak najczesciej.
Niemniej jednak wyjatki to bardzo silny mechanizm i dajacy multum mozliwosci.
A jak to zwykle z takimi rzeczami bywa, bardzo latwo jest uzyc je w sposob
zupelnie niezamierzony przez ich implementatora, np. w celu przekazywania
sterowania programu z jednego miejsca do drugiego.

: [...]

:> : z GUI tylko wxWindows i to tylko prywatnie a
:> : nie w pracy..., a gdzie CORBA , obiektowe bazy danych... RPC.. itp,
: itd...
:> Ech... prosze pana bo sie zaraz zalamie i pojde zebrac na centralny...

: Twoj wybor :) ale nie lepiej poswiecic jeszcze kilka latek na nauke ? :)
Tak tez zmierzam zrobic (oczywiscie to drugie). Coz, moze bedzie to wiecej,
niz pare lat. W koncu czlowiek uczy sie cale zycie.

:> : Ze wspomne o metodologiach projektowania (te wszystkie Rationale, UML-e
:> : itp...). Szkoda mowic...
:> Pewnie ze szkoda. Czy nie lepiej sie skupic na jedynym slusznym C++ ?
:> Jeden jezyk, a mozliwosci wiele. Moze wiecej maja tylko jezyki
: tokenizowane.
Oczywiscie zlekka przesadzilem. No ale ...

: Nie lepiej, jezyki tez przemijaja. Jezyk to tylko narzedzie i tak je nalezy
: traktowac. Nie ma narzedzi slusznych do wszystkiego.
Zgoda.

: Sprobuj napisac np system ekspertowy nie w Lispie czy w Prologu
: a w C, lub sprobuj napisac kernel Linuxa w SQL-u albo w UML-u...
Nie widze problemu. Oczywiscie w zrobieniu tego wszystkiego w C++.

Ale niekiedy nie ma co wytaczac armate na wrobie. Jezeli to ma byc program,
ktory ma cos warunkowo odpalac (z crontaba powiedzmy) to chyba lepiej
napisac skrypt shella.

: Co rozumioesz pod pojeciem "jezyki tokenizowane" ?
Np. Jave. Wieksze mozliwosci wynikaja z dwoch rzeczy: po pierwsze mozna
odpalic to na dowolnym sprzecie po skompiloaniu. Druga zaleta to to, ze
pola struktur identyfikowane sa po nazwie (czyli pelne wiazanie nastepuje
w momencie uruchomienia). Niemniej jednak ten jezyk jest po pierwsze obciety
o pewne mozliwosci w stosunku do C++, a po drugie jest wielokrotnie wolniejszy
(co chyba nie jest dziwne). 

: Istnieje cale mnostwo starych i nowych jezykow ktore maja wieksze
: mozliwosci od C++. I C++ raczej w sensie formalnym i mozliwosci
: zostaje w tyle. Gdzie indziej tkwi przyczyna sily i popularnosci C++.
Tak ? Gdzie ? Wiem, ze takie jezyki istnieja, ale prosze mi podac mozliwosci,
jakich C++ nie posiadajac zostaje w tyle (przy okazji: wielozadaniowosc
nie bedzie tu najszczesliwszym przykladem, przynajmnije dla UNIX'a).

:> Owszem. Ja mam swoje przyzwyczajenia i mnie nic nie przekabaci.

: Zycie czyli praca, praktyka, szefowie , zona itd/itp :)
: Porozmawiamy za kilka lat...
Nie, nic z tego. Chyba, ze ktos wymysli lepszy jezyk. Ale to nie bedzie
zmiana przyzwyczajen.



-- 
.---.     .   . - 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...

milosz danielewski <mdaniel@priv.onet.pl> wrote:
: On 29 Jan 1998 19:19:16 GMT, Michal Malecki <sektor@zly.kis.p.lodz.pl>
: wrote:

:>Wyjatki powinny byc wyjatkowe. W malych programach nie ma potrzeby z nich
:>korzystac. Ale dobrym pomyslem jest np. przetlumaczenie sygnalow na wyjatki.
:>Co prawda mechanizm sygnalow jest troche inny, niz wyjatkow, przede wszystkim
:>dlatego, ze handler sygnalu po zakonczeniu wraca do miejsca, z ktorego zostala
:>przerwana funkcja wywolujac handler. Natomiast wyjatek przerywa biezaca
:>funkcje i juz jej nie kontynuuje (dalej :). Nie przeszkadza to jednaj, bo
:>wyjatki ulegaja propagacji.

:  Co wspominane tu wyjatki maja wspolnego z wyjatkami zglaszanymi
: sprzetowo ( np. przy dzieleniu przez zero ) ? Z wczesniejszej dyskusji
: wnioskuje, ze nie chodzi o to samo...
Nic. Wyjatki zglaszane sprzetowo - jak to nazwales - maja rozna implementacje
na roznnych systemach. Ja akurat mowilem o UNIX'ie i zglaszanych przez niego
sygnalach. Sygnaly da sie "przetlumaczyc na wyjatki" w nastepujacy sposob:

void caught_SIGFPE( int )
{
    signal( SIGFPE, caught_SIGFPE );
    throw ExFPE();
}

... gdzie ExFPE jest specjalnie stworzona klasa na potrzeby zglaszania
wyjatkow. Oczywiscie nalezy na poczatku funkji main zarejestrowac owa
funkcje od razu piszac wywolanie jakie jest w pierszej linijce ciala funkcji.
W tej funkcji nalezy zarejestrowac ja ponownie, gdyz po zgloszeniu sygnalu
owa rejestracja jest anulowana.

Jezeli teraz zrobimy:

try
{
	a = x/0;
}
catch( ExFPE )
{
	cout << "Dzielenie przez zero!\n";
}

to wyjatek ExFPE zostanie zgloszony w tej linijce, gdzie sie dzieli przez zero.

Pozdrawiam,

-- 
.---.     .   . - 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...

Gracjan Ziółek <Gracjan.Ziolek@bdk.lublin.pl> wrote:
: Michal Malecki wrote:
: [...rozne bzdury...]

: Chlopiec nauczyl sie obslugiwac mlotek i wydaje mu sie, ze podbije tym
: caly swiat. Powodzenia.

Musze przyznac, ze wysililes sie na __VERY__ oryginalny komentarz.
Moze lepiej cofnij sie do tylu i kontynuuj dalej prace w swojej robocie.


-- 
.---.     .   . - 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...

Krzysztof G. Baranowski <kgb@manjak.knm.org.pl> wrote:
: On 29 Jan 1998, Michal Malecki wrote:
:>: Zgadzam sie z bzdura i totalna ignorancja. Jest bardzo bardzo wiele rzeczy
:>: do ktorych metodologia OOP kompletnie sie nie nadaje, a co za tym idzie
:>: C++. 
:>Chyle czola przed dwoma glupotami. Coz sprawa jest tak banalna, ze gdyby
:>nie rozmiar owej glupoty, to nawet nie mialoby sensu komentowanie tego.
: A co w tym, co on powiedzial jest takiego glupiego ?
Naucz sie kolego czytac postingi w calosci. Moze wtedy nie bede musial
odpowiadac ci na glupie pytania.

:>prawda nie pelnym, ale jest. Pytam was panowie: Czy MACIE ABSOLUTNY
:>OBOWIAZEK stosowania programowania obiektowego, piszac program w C++ ?
: Nie, ale programujac nieobiektowo wole do tego celu uzywac C.
Ty wolisz, ja nie. Z tego widac, ze nie potrafisz po prostu korzystac
z mozliwosci tego jezyka (albo ich nie znasz/nie rozumiesz).

:>: Jest to nie do pomyslenia w wielu systemach.
:>: Np. wyobrazcie sobie Linux Kernel w C++. 
:>Nic nadzwyczajnego. Problem jest tylko jeden - mogloby to wymusic pisanie
:>wszystkich aplikacji w C++. A to nie kazdemu przychodzi latwo.
: Hihihihihi ! Jak dla mnie to bylby czas apokalipsy...
Coz ja ci na to poradze. Niektorzy wola uzywac pascala i co z tego.

:>Dzieki temu w C++ jestem w swoim zywiole, a w duzych programach niestety
:>C mnie denerwuje. Chocby dlatego, ze musze strasznie duzo rzeczy robic
:>recznie.
: Nasuwa mi sie tutaj analogia pomiedzy Windowsami a Linuxem (bardzo
: czesto podejmowana na pl.comp.os.advocacy). W Linuxie trzeba robic
: duzo rzeczy recznie, ale jak juz to zrobic, to wiesz, ze wszystko
: bedzie Ci dzialac. Z kolei w Windowsach nie wszystko trzeba robic
: recznie, ale wszyscy wiemy jak to sie czasami konczy.

Wrecz, powiedzialbym, szczyt trafnosci, jesli chodzi o znajdowanie analogii.

Ja ci podam kolego inny przyklad.

Zamiast pisac:

char buf [180];

if ( !strcmp( arg, "duzy" ) )
{
    strcpy( buf, arg );
	strcat( buf, arg2 );
	strcat( buf, " i maly " );
	strcat( buf, arg3 );
}

Czy tez ewentualnie

if ( !strcmp( arg, "duzy" ) )
	sprintf( buf, "%s%s%s%s", arg, arg2, " i maly ", arg3 );

Wole napisac sobie tak:


if ( arg == "duzy" )
	arg += arg2 + " i maly " + arg3;

Podalem przyklad BARDZO PROSTEJ sekwencji w C. Nad bardziej skomplikowana
nie chcialo mi sie myslec. Ale dlaczego ja sie mam wysilac, zeby kogos
przekonywac do C++. Jak nie chce to trudno. Niech sobie nie wie, co traci.

-- 
.---.     .   . - 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...

Krzysztof G. Baranowski <kgb@manjak.knm.org.pl> wrote:
: On Sat, 31 Jan 1998, Qrczak wrote:
:>Dlaczego uważasz, że jądra Linuxa nie dałoby się pisać w C++?
: Wszystko daloby sie napisac, ale po co. C ma lepszy kompilator, 
: generuje mniejszy, szybszy kod. Jak ktos poprzednio napisal w
: <6aqpca$p7k@polonez.man.lodz.pl>:

:>Jedyna zaleta C nad C++ (powtarzam: JEDYNA) to to, ze wymaga mniej pamieci
:>i programy sie szybciej kompiluja. W wiekszosci wypadkow nie ma to znaczenia.

: Przerazily mnie te slowa, szczegolnie ostatnie zdanie. :-)

No wiec na co czekasz ? Lepiej sie zacznij uczyc, zamiast wychwalac cos,
czego ostatni standard pochodzi z czasow swietnosci starego dobrego 65XE.


-- 
.---.     .   . - 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...