🚀 go-pugleaf

Użytkownik "Aleksander Galicki" <no@no.com> napisał w wiadomości 
news:06031921120637@polnews.pl...
>
> Ten jezyk 21 stulecia bedzie w 2009...

A wszystko szlag trafi ze wzgledu na kompletnie niechwytliwą, 
niemarketingową nazwę.
C++0x ?
Jak to w ogóle wymówić, żeby se zębów nie połamać ? 

"Filip Sielimowicz" <sielim@poczta.onet.pl> writes:

> A wszystko szlag trafi ze wzgledu na kompletnie niechwytliwą,
> niemarketingową nazwę.
> C++0x ?
> Jak to w ogóle wymówić, żeby se zębów nie połamać ?

Zazwyczaj nie trzeba jawnego rozróżniania, która to wersja C++,
i będzie się mówiło po prostu C++.

Podobnie jak zwykle mówi się C, a tylko przy potrzebie odróżnienia
C89 od C99 mówi się C89 i C99. To i tak nieformalne nazwy.

Jeśli C++0x będzie w 2009 roku, to będzie się nazywał C++09. Ten x
zastępuje nieznaną na razie cyfrę.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Dnia Sun, 19 Mar 2006 21:12:06 +0100, Aleksander Galicki skrobie:

> Ten jezyk 21 stulecia bedzie w 2009...

> A tak wyglada dosc typowa reakcja http://beust.com/weblog/archives/000374.html

:) hehe, typowa ;)

Jeśli za "normę" uważamy reakcję po przeczytaniu 10% propozycji.

> "I recently attended a presentation of C++0x by Bjarne Stroustrup.  It wasn't
> pretty.

> C++0x is the next version of the C++ specification and it's scheduled to be
> final in 2009.  Yes, you read that right:  2009.  

No tak. No i co?

> "Well, okay, I guess that with such a distant deadline, the changes to C++ are
> going to be completely revolutionary, right?"

> Right?

A niby dlaczego? C++ nigdy nie przeżywał rewolucji. Wszystko co zrobiono w nim
od ARM-a to "poprawki i usprawnienia".

> Not really.

> If you are a hardcore C++ developer, I'm sure you will welcome these
> modifications, but anyone with a simple passing (or forced) interest in C++
> will be less than impressed and will probably shrug the whole effort away and
> go back to using gcc while avoiding templates because they are still buggy in
> that implementation.

Ciekawe, co to za bugi, swoją drogą. Wydaje mi się, że taka biblioteka jak
boost powinna je znaleźć. Tymczasem nie widzę, żeby tam jakikolwiek test nie
przechodził w gcc.

> Scoped macros, one of my favorite features:  you can now clearly delineate
> where your macros apply and when they become undefined with...  well, macros
> (#scope / #endscope). The intent is noble, but rescoping existing macros is
> probably not going to happen, so this change will only benefit new macros. 

Jak to nie? Wyraźnie ten ficzer jest skierowany właśnie do biblioteki
standardowej. Żeby można było deklarować lokalne makra. Poza tym makra są dość
użyteczne do tworzenia niestandardowej składni i z tego chociażby względu
przydaje się używanie #scope.

> "Admit the GC as a valid implementation technique".  I am quoting this directly
> from Stroustrup's slides because the phrasing is too precious.  It looks like
> there is something to learn from "next generation languages" (Java, C#) after
> all...

Taaa... next generation. Padnę ze śmiechu.

> ype inference, woohoo!  In C++0x, variables can declared with auto.  Now we're
> talking 21st century.  

Jasne, pewnie te "next generation languages" mają to już od dawna ;)))

> As you can see, nothing that is really going to help C++ programmers raise the
> level of abstraction where they are currently stuck:  no closures,

Lambdy podobno mają być, tylko są jeszcze niedopracowane. Przecież standard
nie wychodzi za pół roku.

> no LINQ,

LINQ :))) Dobry żart. Tego typu pierdoły będzie można sobie napisać samemu
(lub znajdą się w bibliotece standardowej).

> no
> new keywords,

Taaa, szczególnie ilośćsłów kluczowych świadczy o jakości języka. Szczególnie
o tym, czy należy on do "next generation".

> and still this unavoidable exposure to all these low-level
> details that fewer and fewer people care for these days.

Nie do końca, to po pierwsze. Można się bez nich obejść, to po drugie.

> Why do I even need to
> know about the existence of iterators when all I want is to work on every
> element of a collection?

Taaa... wygląda na to, że autor o nowej pętli for też nie słyszał.

Ciekawe musi być jego używanie C++, skoro dla niego iterator służy tylko do
przeglądania zawartości kolekcji.

> I wrote my last line of C++ about nine years ago, so my exposure to Java, C#
> and Ruby these past years has undoubtedly made me very biased, but I have to
> say I found all the snippets of code that Bjarne showed absolutely dreadful to
> read.  Coding conventions have never been the forté of C++ programmers, but
> with the advent of templates, partial specialization, traits and other advanced
> programming techniques, C++ code has become a terrible alphabet soup mixing
> lower case, upper case, all caps, camel case, *, & and [] and const appearing
> sometimes left and sometimes right, underscore sometimes followed by a capital,
> other times by a lowercase character or an all-caps word, etc...

I to jest typowa wypowiedź człowieka, który C++ ogląda wyłącznie z boku.
Naczytałem się takich, że aż się rzygać chce.

> Having said that, it's becoming increasingly clear to me that C++ is turning
> into a niche language, and if you want to start a new project, you'd better
> have some very good reasons to pick C++.

Unfortunately, there are many :)

> Good bye, C++.  I'm looking forward to reusing my C++ brain cells for concepts
> that will help me tackle the software challenges of the next twenty years as
> opposed to not forgetting to insert a space in my code or remembering to free
> the memory that I'm not even sure I allocated in the first place."

Good bye C++ to ja już słyszę od co najmniej 10 lat.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

[...]

> Good bye C++ to ja już słyszę od co najmniej 10 lat.

C++ nie jest takie złe, dopóki nie korzysta się z większości bajerów,
które oferuje :-)

Dnia Mon, 20 Mar 2006 19:13:08 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> writes:

> [...]

> > Good bye C++ to ja już słyszę od co najmniej 10 lat.

> C++ nie jest takie złe, dopóki nie korzysta się z większości bajerów,
> które oferuje :-)

No to teraz jest jasne, dlaczego Java ma tak mało bajerów. Bo z nimi byłaby
zła :)

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

> To JEST ironia. Jezyk bez odsmiecacza to zwykly smiec.  A jezeli Pan
> tego nie wie, to pisze Pan programy trywialne.

Hmm, moim zdaniem Ci co duzo smieca w kodzie musza korzystac z  
odsmieczaczy...

> Ja sobie kpie z C++. Z mojego punktu siedzenia widze jak firmy
> pozbywaja sie C++ jak zarazy.

Oczywiscie...

-- 
uno (unodgs@tlen.pl)

"Daniel Kos" <unodgs@tlen.pl> writes:

> Radzilbym ignorowac Pana A.I. To zwykly troll.. niestety

Pozwolę sobie się nie zgodzić.

Daniel Kos napisał(a):
>> To JEST ironia. Jezyk bez odsmiecacza to zwykly smiec.  A jezeli Pan
>> tego nie wie, to pisze Pan programy trywialne.
> 
> 
> Hmm, moim zdaniem Ci co duzo smieca w kodzie musza korzystac z  
> odsmieczaczy...

Moim zdaniem nie używanie odśmiecaczy przeważnie powoduje niepotrzebny 
wzrost kosztów. Ponieważ wytwarzam oprogramowanie "dla zysku", a nie 
"dla idei", to podobne kwestie estetyczne pozostawiam estetykom :-).

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

[...]

> Moim zdaniem nie używanie odśmiecaczy przeważnie powoduje
> niepotrzebny wzrost kosztów. Ponieważ wytwarzam oprogramowanie 
> "dla zysku", a nie "dla idei", to podobne kwestie estetyczne 
> pozostawiam estetykom :-).

Estetykom czy estetom?

Piotr Dembiński napisał(a):
> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
> 
> [...]
> 
> 
>>Moim zdaniem nie używanie odśmiecaczy przeważnie powoduje
>>niepotrzebny wzrost kosztów. Ponieważ wytwarzam oprogramowanie 
>>"dla zysku", a nie "dla idei", to podobne kwestie estetyczne 
>>pozostawiam estetykom :-).
> 
> 
> Estetykom czy estetom?

Mającym złe wrażenia estetyczne, gdy widzą środowisko z odśmiecaczem :-).

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Michal Przybylek wrote:

> Jeszcze gorzej, ze o tym sie nie uczy...

Ale tu chyba nie ma wiele do nauki poza zwróceniem uwagi na możliwość 
wystąpienia takich sytuacji ;).

-- 
mgl

"Jedrzej Dudkiewicz" <jedrzej.dudkiewicz@poczta.interia.pl> wrote:

> > Glownie dlatego, ze programisci piszacy w jezykach z GC nie zdaja sobie
> > sprawy z tego, ze GC nie gwarantuje braku wyciekow pamieci.
>
> Mogę prosić o szczegóły? Bo wydawało mi się, że jeżeli jest GC to zwykle
nie
> ma możliwości, by explicite ją dealokować, co jest warunkiem sine qua non
> dla wycieków. Masz może na myśli odwołania cykliczne albo podobne
> konstrukcje?

Nie.

Problem powstaje kiedy logiczny czas zycia obiektu nie jest dobrze
aproksymowany przez czas zycia wyznaczony przez dostepnosc referencji.

Czasami zdarza sie tak, ze dany obiekt nie powinien w danym momencie juz
istniec choc referencje sa nadal. Wtedy najczesciej trzeba recznie poodcinac
owe referencje. Niestety, nie zawsze jest to trywialne.

Jeszcze gorzej, ze o tym sie nie uczy...


mp

Dnia Sat, 01 Apr 2006 12:21:46 -0600, A..L. skrobie:
> A jak idzie o "mode" to proponuje Panu powtorke z historii.
> Odsmeicacz mial Lisp juz pod koniec lat 50. Odsmiecacz miala Simula
> 67, jak sama nazwa wskazuje, pod koniec lat 60. Odsmiecacz mial
> Smalltalk.

Tak, i jeszcze pewnie dominowały w produkcji oprogramowania.

Niestety, prawo Gatesa wtedy jeszcze działało słabo, a prawo Wirtha dobrze im
dało w dupę.

Teraz jest znacznie lepiej, bo prawo Gatesa działa wyraźniej, a prawo Wirtha
nieco osłabło.

Ale ośmielę się przypomnieć sytuację, jaka doprowadziła do powstania C++.
Wszystkiemu winien Bjarne Stroustrup ze swoim uwielbieniem dla Simuli:
zajebisty język, tylko czego k... tak się ślimaczy!? I przeszedł na BCPL.

> I to bynajmniej nie z powodu mody: napisanie zlozonego
> programu OBIEKTOWEGO bez odsmiecacza tak aby nie mial "memory leaks"
> jest bardzo trudne i zajmuje czas. A wiec jest kosztowne.

Bardzo jestem ciekaw, jak pan do tego doszedł. Niech pan wymieni może
przynajmniej jeden język obiektowy, i to obiektowy w takim sensie, jak
Smalltalk, który istniał w latach 60-80, i który nie miał odśmiecacza.

A jak pan taki wymienisz, to jestem w stanie opowiedzieć, dlaczego jest to tam
takie toporne, oraz dlaczego ów problem nie istnieje w języku C++.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Wed, 5 Apr 2006 17:30:58 +0200, Jedrzej Dudkiewicz skrobie:
> > Glownie dlatego, ze programisci piszacy w jezykach z GC nie zdaja sobie
> > sprawy z tego, ze GC nie gwarantuje braku wyciekow pamieci.

> Mogę prosić o szczegóły? Bo wydawało mi się, że jeżeli jest GC to zwykle nie
> ma możliwości, by explicite ją dealokować, co jest warunkiem sine qua non
> dla wycieków. Masz może na myśli odwołania cykliczne albo podobne
> konstrukcje?

Czyś ty się z choinki urwał? Co ma jawne zwalnianie pamięci (to po polsku) do
wycieków?

Wycieki nie istnieją przez to, że pamięć się dealokuje, tylko przez to, że się
tego nie robi. Jak nie wiesz, co to są wycieki i skąd się biorą, to proszę
cię, doinformuj się z łaski swojej na Wikipedii.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Wed, 5 Apr 2006 18:12:01 +0200, Michal Przybylek skrobie:
> Problem powstaje kiedy logiczny czas zycia obiektu nie jest dobrze
> aproksymowany przez czas zycia wyznaczony przez dostepnosc referencji.

> Czasami zdarza sie tak, ze dany obiekt nie powinien w danym momencie juz
> istniec choc referencje sa nadal. Wtedy najczesciej trzeba recznie poodcinac
> owe referencje. Niestety, nie zawsze jest to trywialne.

Powiem więcej - synchroniczne pozbywanie się obiektu i wskazania na niego jest
znacznie łatwiejsze do zaprogramowania, niż ucinanie referencji, zwłaszcza gdy
mając do dyspozycji pełną swobodę kopiowania referencji istnieje duże
potencjalne ryzyko rozsiewania jej gdzie popadnie.

Nawet jeśli właściciel, powiedzmy, biblioteki, zadbał o to, żeby referencje do
jego obiektów nie były przechowywane za długo, to jednak biblioteki nie
istnieją w próżni.

Wiem, można stosować słabe referencje. A ktoś mi nakaże?


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

> > Mogę prosić o szczegóły? Bo wydawało mi się, że jeżeli jest GC to zwykle
nie
> > ma możliwości, by explicite ją dealokować, co jest warunkiem sine qua
non
> > dla wycieków. Masz może na myśli odwołania cykliczne albo podobne
> > konstrukcje?
>
> Czyś ty się z choinki urwał? Co ma jawne zwalnianie pamięci (to po polsku)
do
> wycieków?

> Wycieki nie istnieją przez to, że pamięć się dealokuje, tylko przez to, że
się
> tego nie robi.

No shit, Sherlock :)

Chodziło mi o to, że jeżeli jest GC, to nie ma ręcznej gospodarki pamięcią.
Jeżeli nie ma ręcznej gospodarki pamięcią, to nie może powstać wyciek, bo,
rozumowałem, żeby powstał, to w takim C albo C++ trzeba pamięć z palca
przydzielić, potem jej poużywać (albo i nie), a następnie przestać zwracać
na nią uwagę, tj. zlikwidować wszelkie odwołania do niej bez kasowania jej.

Swoją drogą "nieużywane referencje leżące na dnie kontenera" jakoś nie
pasują mi do wycieków, bardziej do nieuważnej gospodarki obiektami. Różnica
jest taka, że taką nieużywaną referencję możemy jeszcze kiedyś przypadkiem
zwolnić a pamięć, która wyciekła, jest stracona "na wieki".

JD

"Michal Przybylek" <mrp@neostrada.pl> wrote:

> Glownie dlatego, ze programisci piszacy w jezykach z GC nie zdaja sobie
> sprawy z tego, ze GC nie gwarantuje braku wyciekow pamieci.

No kurcze normalnie struchlalem.
Pisalem w Simuli troche (nie dni) i w zyciu bym nie pomyslal ze siedzialem
na takiej "bombie" ! bo mi sie nie zdarzyl _ani jeden_ wyciek pamieci.

Hm..
Widocznie mialem "niebywale" szczescie zmiescic sie w ogonie widma :)

AK 

Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

> Ale ośmielę się przypomnieć sytuację, jaka doprowadziła do powstania C++.
> Wszystkiemu winien Bjarne Stroustrup ze swoim uwielbieniem dla Simuli:
> zajebisty język, tylko czego k... tak się ślimaczy!? I przeszedł na BCPL.

Chlopcze kochany. Mlodzianie.

Nie piernicz na tematy o ktorych nie masz pojecia.
A jesli juz to <AL> piernicz z sensem</AL>.

C++ ma sie tak doSimuli jak wol do karety,

Pod kazdym wzgledem, skladniowym , logocznym ., metodolicznym,
bezpieczenstwa..

O slimaczeniu to moglbys powiedziec dopiero wtedy gdybys _cokolwiek_
w tej  Simuli napisal i uruchomil.
O numeryce w czasach Algolu i Simuli i Algolu zamilknij lepiej (wiesz,
numeryka jest czula na szybkosc o wiele bardziej niz twoje "super optymalme"
C++ szczegolnie gdy czytasz z dysku czy wyswietlasz jakies GUi albo
dobierasz sie do jakiegos DB, albo socketa) bo sie narazasz na smiesznosc.
Poczytaj sobie np o Algolu na Odra1024.
Osobiscie nawet na Odra1325/1305 na Algol nie narzekalem.
(a pisalem jednoczesnei w Algolu i Fortranie).

> Bardzo jestem ciekaw, jak pan do tego doszedł. Niech pan wymieni może
> przynajmniej jeden język obiektowy, i to obiektowy w takim sensie, jak
> Smalltalk, który istniał w latach 60-80, i który nie miał odśmiecacza.

Ja nie pamietam takowego.
Prawda, ze wtedy byly prawie wylacznie dobre jezyki.

Pamietam jednak ze w tych "nieoptymalnych" czasach uskutecznialem
optymalizacje wielokryterialna na Odrze1325 z 32kW (24bitowych)
pamieci operacyjnej z przewijakami tasmy w roli "randow access storage"
i "hulalo" lepiej niz dzis na pecetach.

Wy w czasach C++ zapomnieliscie o jednym.
W algorytmach sila (i pomyslunku) a nie w silver bullets jak
super hiper jezyk/kompilator.
No ale C/C++ skutecznie kastruje z takiego podejscia

No bo jak sie ma "mainstream" jezyk to po co sie wysilac na
_prawdziwa_ optymalizacje ? :) Prawda ?

Parafrazujac.
Mysmy mieli tylko jedna/dwie kobiety (j.progr:).
Ale znalismy ja na tyle dobrze, ze potrafilismy z niej wycisnac
naprawde duzo.
Wy w dzisiejszych czasach macie harem, tyle tylko
ze nie jestescie w stanie ani go dobrze poznac ani nad nim zapanowac
Mam wrazenie ze to juz harem rzadzi Wami i ze sie role odwrocily
i ze to Wy wylacznie uslugujecie juz haremowi :)?
Jak sie nazywali Ci co spelniali role sluzebna w haremie ? eee.... uu..? :)

> A jak pan taki wymienisz, to jestem w stanie opowiedzieć, dlaczego
> jest to tam takie toporne, oraz dlaczego ów problem nie istnieje w języku 
> C++.

Chlopie ! _CO_ toporne ?
Konkretnie.
Wyjmij palec z ust i nie snij go piszac _CO_.
Ok ?

AK

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote in message

> Polecam wątek:
> http://groups.google.pl/group/pl.comp.lang.c/browse_frm/thread/acc3cfd2c1bbd0ad/1ee9382868c25c69?> 
> lnk=st&q=c%2B%2B0x+GC+group%3Apl.comp.lang.c&rnum=1&hl=pl#1ee9382868c25c69

W kwestii GC.
Sorry, ale pl.comp.objects nie posiada poki co odsmiecacza.
Moglyc wiec nie wprowadzac tu smieci ?

AK 

Witam

Adam Karpierz wrote:

> W kwestii GC.
> Sorry, ale pl.comp.objects nie posiada poki co odsmiecacza.

A myślałem, że taka wspaniała grupa ma zaimplementowane same rewelacyjne
rozwiązania.

> Moglyc wiec nie wprowadzac tu smieci ?

Jak się nie ma nic do powiedzenia, to się szczeka co?

Pozdrawiam.

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/   

Witam

Adam Karpierz wrote:

> Pamietam jednak ze w tych "nieoptymalnych" czasach uskutecznialem
> optymalizacje wielokryterialna na Odrze1325 z 32kW (24bitowych)
> pamieci operacyjnej z przewijakami tasmy w roli "randow access storage"
> i "hulalo" lepiej niz dzis na pecetach.

Myślę, że to jest trochę nuta sentymentalizmu, bo samo przewijanie taśmy jest
wolne, ale rozumiem o co chodzi, bo sam piszę różne algorytmy.

> Wy w czasach C++ zapomnieliscie o jednym.
> W algorytmach sila (i pomyslunku) a nie w silver bullets jak
> super hiper jezyk/kompilator.
> No ale C/C++ skutecznie kastruje z takiego podejscia
> 
> No bo jak sie ma "mainstream" jezyk to po co sie wysilac na
> _prawdziwa_ optymalizacje ? :) Prawda ?

Co ma, przepraszam bardzo, język do optymalizacji algorytmu. Jeśli, ktoś
napisze sortowanie bąbelkowe, to nic mu język ani nie pomoże ani nie
zaszkodzi. W najlepszym przypadku procesor z jakąś pipelinką. Ale język, w
szczególności jego specyfikacja, nic. No chyba, że mówimy o algorytmach
pracujących na wyrażeniach to wtedy tak, ale to jest raczej działka dla
języków funkcyjnych. I ani fortran, ani java ani C++, simula i algol pewnie
tez nic nie pomogą.  

Algotym można napisać dobrze i źle, język nic do tego nie ma.

Pozdrawiam.

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/   

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote:

> Myślę, że to jest trochę nuta sentymentalizmu,

Owszem :) Swiadoma ale..  uzasadniona.

> bo samo przewijanie taśmy jest
> wolne, ale rozumiem o co chodzi, bo sam piszę różne algorytmy.

To prawda, Bylo bardzo wolne.
Ale skutkowalo optymalizacja optymalizacji czyli minimalizacja
odwolac do succesorow/accesorow w stosowanej odmianie
metody podzialu i ograniczen (bo to byla optymalizacja dyskretna)

>> No bo jak sie ma "mainstream" jezyk to po co sie wysilac na
>> _prawdziwa_ optymalizacje ? :) Prawda ?
>
> Co ma, przepraszam bardzo, język do optymalizacji algorytmu.
[...]
> Algotym można napisać dobrze i źle, język nic do tego nie ma.

Jesli jezyk (poprzez jego otoczke, czyli wszelkiego rodzaju buzzy dziejace
sie wokolo  niego:) jest postrzegany jako _sam z siebie_ zapewniajacy
optymalnosc i szybkosc programow to owszem, jezyk "tez tu cos ma"

AK

Dnia Thu, 6 Apr 2006 09:26:40 +0200, Jedrzej Dudkiewicz skrobie:
> Chodziło mi o to, że jeżeli jest GC, to nie ma ręcznej gospodarki pamięcią.
> Jeżeli nie ma ręcznej gospodarki pamięcią, to nie może powstać wyciek, bo,
> rozumowałem, żeby powstał, to w takim C albo C++ trzeba pamięć z palca
> przydzielić, potem jej poużywać (albo i nie), a następnie przestać zwracać
> na nią uwagę, tj. zlikwidować wszelkie odwołania do niej bez kasowania jej.

Zlikwidować obiekty, lub nadpisać wskaźniki, które ją trzymały.

Poza tym, lekko przesadzasz. "Wszelkie odwołania" to znaczy, że było ich twoim
zdaniem wiele. Tymczasem obiekty współdzielone to rzadkość. Co więcej,
współdzielenie obiektów poprzez trzymanie do nich kilku referencji to bardzo
niebezpieczna technika programowania. GC załatwia ci tutaj problem usunięcia
obiektu i pozostawienia wskaźnika wiszącym, ale nie załatwi ci problemu
tożsamości obiektów. Znacznie sensowniej jest pozostawić jakiejś klasie opiekę
nad tym obiektem i dać jej metodę, która zwróci wskaźnik/referencję do niej.
Wtedy mamy pewność, że zawsze mamy do czynienia z tym obiektem, co trzeba.

> Swoją drogą "nieużywane referencje leżące na dnie kontenera" jakoś nie
> pasują mi do wycieków, bardziej do nieuważnej gospodarki obiektami. Różnica
> jest taka, że taką nieużywaną referencję możemy jeszcze kiedyś przypadkiem
> zwolnić a pamięć, która wyciekła, jest stracona "na wieki".

Nie rozumiem. Dlaczego?

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Thu, 6 Apr 2006 10:57:54 +0200, Adam Karpierz skrobie:
> Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

> > Ale o?mielę się przypomnieć sytuację, jaka doprowadziła do powstania C++.
> > Wszystkiemu winien Bjarne Stroustrup ze swoim uwielbieniem dla Simuli:
> > zajebisty język, tylko czego k... tak się ?limaczy!? I przeszedł na BCPL.

> Chlopcze kochany. Mlodzianie.

Spieprzaj, dziadu. ;P

> Nie piernicz na tematy o ktorych nie masz pojecia.
> A jesli juz to <AL> piernicz z sensem</AL>.

No jasne. Po co dwóch ma pierniczyć bez sensu, w tym jeden piernik.

> C++ ma sie tak doSimuli jak wol do karety,

W tym kontekście wspominanie C++ akurat nie ma za wiele sensu. To przecież
oczywiste, że więcej do C++ zostało zaczerpnięte z C, niż z Simuli.

> Pod kazdym wzgledem, skladniowym , logocznym ., metodolicznym,
> bezpieczenstwa..

Wydajności... ;P

> O slimaczeniu to moglbys powiedziec dopiero wtedy gdybys _cokolwiek_
> w tej  Simuli napisal i uruchomil.

Adamie, nie rozumiem, coś się tak czepił jak wół karety. Napisałem to, co BS
napisał w DEC++. Nie ustosunkowuję się do tego, gdyż nie mam za wiele ku temu
kompetencji. Jeśli się chcesz do tego ustosunkować, to proszę bardzo, tyle że
porównywanie jej z C++ nie ma za wiele sensu, mimo wszystko.

> O numeryce w czasach Algolu i Simuli i Algolu zamilknij lepiej (wiesz,
> numeryka jest czula na szybkosc o wiele bardziej niz twoje "super optymalme"
> C++

No nie wiem. Z tego co słyszałem, to w tzw. "numeryce" stosuje się dziś
głównie C++. I słyszałem to od ludzi, którzy się teraz właśnie nią zajmują.
Ale tylko słyszałem, więc nie jest to moja prywatna opinia.

> szczegolnie gdy czytasz z dysku czy wyswietlasz jakies GUi albo
> dobierasz sie do jakiegos DB, albo socketa) bo sie narazasz na smiesznosc.

Adamie, może najpierw ty się nie narażaj na śmieszność w sytuacji gdy numerykę
wiążesz z czytaniem z dysku, GUI i połączeniami zdalnymi. Tak się składa
akurat, że kwestie wydajności związanej z tymi właśnie rzeczami, to moja
działka od kilku lat.

> Poczytaj sobie np o Algolu na Odra1024.
> Osobiscie nawet na Odra1325/1305 na Algol nie narzekalem.
> (a pisalem jednoczesnei w Algolu i Fortranie).

Adamie, nie sądzę, żeby nauka odległej (jak na informatyczne standardy)
historii mogła wpłynąć na moją wiedzę ze współczesnej inżynierii.

> > Bardzo jestem ciekaw, jak pan do tego doszedł. Niech pan wymieni może
> > przynajmniej jeden język obiektowy, i to obiektowy w takim sensie, jak
> > Smalltalk, który istniał w latach 60-80, i który nie miał od?miecacza.

> Ja nie pamietam takowego.
> Prawda, ze wtedy byly prawie wylacznie dobre jezyki.

Adamie, nie rozśmieszaj mnie.

15 lat temu też nie pamiętam, żeby na jakimkolwiek pececie chodził inny
system, niż majkrosoftowy. No, ale wtedy były prawie wyłącznie dobre systemy
;P

> Pamietam jednak ze w tych "nieoptymalnych" czasach uskutecznialem
> optymalizacje wielokryterialna na Odrze1325 z 32kW (24bitowych)
> pamieci operacyjnej z przewijakami tasmy w roli "randow access storage"
> i "hulalo" lepiej niz dzis na pecetach.

Jasne, robiłeś lepsze rzeczy, niż wszyscy twórcy systemów operacyjnych razem
wziętych. Ty to jesteś jednak gigaloman.

> Wy w czasach C++ zapomnieliscie o jednym.
> W algorytmach sila (i pomyslunku) a nie w silver bullets jak
> super hiper jezyk/kompilator.

Nie martw się, Adamie, większość prostych algorytmów jest teraz dostępna
ot-tak [tu pstrykam palcami]. Bardziej złożone stosuje się tylko specyficznie,
bo nikomu się to w powszechnej praktyce nie opłaca - nie zapominaj o prawie
Gatesa. Bardzo wydajne algorytmy są silnie strzeżoną tajemnicą, a ich twórcy
są ciężko opłacani.

> No ale C/C++ skutecznie kastruje z takiego podejscia

A Simula, Smalltalk, Algol, czy Lisp biją je pod względem wydajności na dwie
głowy i cztery jaja.

> No bo jak sie ma "mainstream" jezyk to po co sie wysilac na
> _prawdziwa_ optymalizacje ? :) Prawda ?

Prawdziwą, to znaczy jaką?

> Parafrazujac.
> Mysmy mieli tylko jedna/dwie kobiety (j.progr:).
> Ale znalismy ja na tyle dobrze, ze potrafilismy z niej wycisnac
> naprawde duzo.
> Wy w dzisiejszych czasach macie harem, tyle tylko
> ze nie jestescie w stanie ani go dobrze poznac ani nad nim zapanowac

Brawo, Adamie! Nareszcie zdałeś sobie sprawę z tego, jak działa prawo Gatesa.

> Mam wrazenie ze to juz harem rzadzi Wami i ze sie role odwrocily
> i ze to Wy wylacznie uslugujecie juz haremowi :)?
> Jak sie nazywali Ci co spelniali role sluzebna w haremie ? eee.... uu..? :)

Światem nie rządzi nauka, tylko ekonomia. Jeśli komuś opłaca się wziąć byle
jaki algorytm, bo ma szybką maszynę i tak, to nie będzie się silił na lepszy
algorytm tylko dlatego, że jest lepszy. Ta lepszość musi się zaznaczyć w
pieniądzach. Jeśli nie zaznaczy się w pieniądzach, to nie istnieje.

Maszynę parową wynaleziono już w starożytnym Egipcie. Dlaczego przypisuje się
jej wynalezienie Jamesowi Wattowi?

> > A jak pan taki wymienisz, to jestem w stanie opowiedzieć, dlaczego
> > jest to tam takie toporne, oraz dlaczego ów problem nie istnieje w języku 
> > C++.

> Chlopie ! _CO_ toporne ?
> Konkretnie.

Zarządzanie pamięcią.

> Wyjmij palec z ust i nie snij go piszac _CO_.

Spieprzaj dziadu ;P


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Thu, 6 Apr 2006 13:00:35 +0200, Adam Karpierz skrobie:
> Jesli jezyk (poprzez jego otoczke, czyli wszelkiego rodzaju buzzy dziejace
> sie wokolo  niego:) jest postrzegany jako _sam z siebie_ zapewniajacy
> optymalnosc i szybkosc programow to owszem, jezyk "tez tu cos ma"

Problem w tym, że język tu akurat nic nie ma - jeśli mówimy o C++


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Witam

Adam Karpierz wrote:

> To prawda, Bylo bardzo wolne.
> Ale skutkowalo optymalizacja optymalizacji czyli minimalizacja
> odwolac do succesorow/accesorow w stosowanej odmianie
> metody podzialu i ograniczen (bo to byla optymalizacja dyskretna)

Myślę, że to nadal jest aktualne. Bo zamiast pamięci na taśmach mamy pamięć
komputera i ona, a w zasadzie dostęp do niej, też nie jest rewelacyjnie szybki
w porównaniu np. z cache w procesorze.

Rozumiem co jest ważne i wiem oco chodzi w tych walkach. Ostatnio instalowałem
system na procesorze DSP i tam, może nie jak na Odrze, ale jest mało bo 700kB
pamięci o szybkim dostępie i 16MB o wolnym dostępie (swap na zewnętrznym
flashu). Też robi się cuda na kiju, aby tak pracować w programie z blokami
pamięci, aby te najbardziej potrzebne były blisko. I procedury tak się pisze,
że jak coś się dossa do jakiegoś bloku pamięci to niech robi ile wlezie, bo
zaraz mu go podmienia na inny, a stary blok wyląduje na swpie.

Nic się nie zmieniło - tyle, że na DSP nie ma fortrana, algola, simuli, akurat
chyba nawet javy, jest tylko nielubiany przez wielu, a przeze mnie właśnie
dlatego szanowany C i częściowo dołączone C++, ale trzeba uważać, bo C++ jest
mocno okrojony.

Krótko mówiąc nie ma zlituj się. Język C dziś jest generalnie dostępny tak jak
asembler na większość procesorów (uC, DSP) i innych jest C. Oczywiście po
drugiej stronie szalki na FPGA jest równie "objektowy" język VHDL. I tam
ludzie cieszą się, że mają język, a nie muszą sami bitów ustawiać.

Procesory DSP i uC potrafią uczyć pokory, ale potrafią za pokorę się odpłacić
pięknym działaniem, nawet jeśli zmusza się je do pracy z logiką rozmytą jako
system diagnostyczny oraz filtrem Kalmana-Bucy'ego jako predyktorem stanu
systemu pomiędzy analizą strumienia obrazu 25fps pod kątem wyszukiwania
ruchomych obiektów.

Pozdrawiam.

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/   

> > Swoją drogą "nieużywane referencje leżące na dnie kontenera" jakoś nie
> > pasują mi do wycieków, bardziej do nieuważnej gospodarki obiektami.
Różnica
> > jest taka, że taką nieużywaną referencję możemy jeszcze kiedyś
przypadkiem
> > zwolnić a pamięć, która wyciekła, jest stracona "na wieki".
>
> Nie rozumiem. Dlaczego?

Przykro mi, ale nie rozumiem, czego i dlaczego nie rozumiesz. Wydawało mi
się, że napisałem, jak na siebie, jasno. Wydawało mi się?

JD

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote:

> Myślę, że to nadal jest aktualne. Bo zamiast pamięci na taśmach mamy 
> pamięć
> komputera i ona, a w zasadzie dostęp do niej, też nie jest rewelacyjnie 
> szybki
> w porównaniu np. z cache w procesorze.

Jednak nie jest tak aky=tulane.
Dzis bym tak nie pisal jak dawniej bo.. stosuj ezasade ze optymalizuje tam
gdzie napraewde potrzeba i gdzie sa bootlenecki.
Na Odrze byly wszezdzie, dzis sa rzadziej (i dobrze) co nie znaczy
ze nalezy "szalec" bez opamietania.
Po prostu dzisaij czesc tamtych algorytmow nei ma sensu, ale
czesc bedzie maila sens zawsze..

> Nic się nie zmieniło - tyle, że na DSP nie ma fortrana, algola, simuli, 
> akurat
> chyba nawet javy, jest tylko nielubiany przez wielu, a przeze mnie właśnie
> dlatego szanowany C i

Do C nic nie mam.
Dobrze spelnia swa role i nie pretenduje do wyzszej.
Pretensje mam do C++ ktore jest 1 mile od C a 50 do Simuli ze
pretenduje do bycia "programing language of universum"
a tymczasem sloma mu z butow wylazi gzdei nei spojrzec.

AK

Witam

Adam Karpierz wrote:

> Jednak nie jest tak aky=tulane.
> Dzis bym tak nie pisal jak dawniej bo.. stosuj ezasade ze optymalizuje tam
> gdzie napraewde potrzeba i gdzie sa bootlenecki.
> Na Odrze byly wszezdzie, dzis sa rzadziej (i dobrze) co nie znaczy
> ze nalezy "szalec" bez opamietania.
> Po prostu dzisaij czesc tamtych algorytmow nei ma sensu, ale
> czesc bedzie maila sens zawsze..

Sugerowałem raczej, że pewne doświadczenia są nadal istotne.

> Pretensje mam do C++ ktore jest 1 mile od C a 50 do Simuli ze
> pretenduje do bycia "programing language of universum"
> a tymczasem sloma mu z butow wylazi gzdei nei spojrzec.

Wydaje mi się jednak, że te pretensje wynikają z niepełnego zrozumienia języka
i słabej znajomości bibliotek. Właśnie piszę sieć Kohonena w C++ i z kolegą w
Javie i okazuje się, że projekt UML dla Javy jest trochę bardziej
skomplikowany, bo pewne aspekty objektowości są jakoś nie osiągalne i trzeba
je łatać sztuczkami. W C++ tych problemów nie mam.

Kiedy zrobi Pan 10 oddechów, policzy do 10 i wypije szklankę zimnej wody.
Proszę spróbować konstruktywnie podejść do tego języka. Zaprojektować jakiś
algorytm objektowo i zobaczy Pan ile pracy jest w nim, a ile daje to zysku.
Naprawdę proszę spróbować wykorzystać np. możliwość przeładowania szablonów,
albo proszę skorzystać z możliwości sprawdzania s jakiej klasy dziedziczy się
inna klasa w celu grupowania klas o podobnych interfejsach. Jeżeli jest Pan
otwarty na pewnepozytywne aspekty, to przoszę przeanalizować następujący
problem:

Mamy kontener K może być listą macierzą, grafem, czymkolwiek. I on zawiera
metodę getElement. Ale z powodu jego kształtu wygląda tak getElement ( Index
I ). Ale jeżeli Indeks jest raz np. int raz Integer a raz
Pair<Integer,Integer>. Proszę spróbować w Javie zaprojektować tak kontener,
który zawiera rzezywisty zbiornik danych, aby pracował najlepiej dla ArrayList
i podobnych (chodzi o RandomAcces) dla macierzy (jakkolwiek zrealizowanych),
ale proszę zobaczyć, że Indeks dla ArrayList nie moze byc uzyty dla Macierzy i
naodwrót. Kolejnym krokiemjest użycie tego cudaka do formowania sieci i
procesów uczenia jej a potem pozyskiwania wiedzy z niej. W C++ to jest dość
proste, szybko się pisze i jest bardzo ogólne. W Javie mam pewne problemy, ale
może Pan, umie to rozwiązać szybko.

Tak jak pisałem kiedyś w innym wątku. Kiedyś byłem orędownikiem Javy, zresztą
dziś nie mówię, że jest to język zły. Ale po pewnej ilości zaprogramowanych
algorytmów doszedłem do wniosku, że istotnie lepiej i bardziej uniwersalnie
pisze się w C++.

Próbowałem Fortrana, ale jakoś nie znalazłem fortrana w wersji objektowej.

Jeżeli może mi Pan podać jakiś internetowy kurs Simuli i Algola, chętnie
zobaczę. Jeśli będzie to dla moich zastosowań język odpowiedni chętnie kupę
książki i się nauczę.

Pozdrawiam.

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/   

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote:

> Sugerowałem raczej, że pewne doświadczenia są nadal istotne.

Zgadzam sie z Panem.

> Wydaje mi się jednak, że te pretensje wynikają z niepełnego
> zrozumienia języka
[...]
> Kiedy zrobi Pan 10 oddechów, policzy do 10 i wypije szklankę
> zimnej wody.

Robie to od 20 lat (tyle lat pisze przemyslowo w C/C++).
Nie pomaga :(.

> Proszę spróbować konstruktywnie podejść do tego języka.
> Zaprojektować jakiś algorytm objektowo i zobaczy Pan ile
> pracy jest w nim, a ile daje to zysku.

Duzo pracy, malo zysku.
Niepewnosc dzialania.

> Naprawdę proszę spróbować wykorzystać np. możliwość
> przeładowania szablonów,

Taaa. Wlasnie dzisiaj walcze z szalenstwem mlodych czyli wlasnie
_dokladnie_ przeladowaneim szablonow
Zamiast sobie odpoczywac to sobie sam wyznaczylem "wolna"
sobote _dokladnie_ z powodu szalenczo przeladowwanych szablonow
uczynionych przez "mlodziez" nieswiadoma jej skutkow.

Powiem bez owijek.
Za chore szablony C++sowe, za wymysly szalencow typu MPL
z boosta itp "mainsteamowe wynalazki" powinno sie preogramistom
ja^H^Hpaluchy obcinac.

> W Javie mam pewne problemy, ale może Pan, umie to rozwiązać szybko.

Nie pisze w ogole w Javie.
Tzn... juz pisze :) .
Wlasnie wczoraj napisalem w niej pierszy "program" w zyciu (40 linijek :)

> Próbowałem Fortrana, ale jakoś nie znalazłem fortrana w wersji objektowej.

Fortran95, Fortran200x.
Tyle ze dodanie obiektowki do Fortranu (tak sie tylko poprawnie mowi)
to poboczny tor czyli kwiatek do kozucha.

> Jeżeli może mi Pan podać jakiś internetowy kurs Simuli i Algola, chętnie
> zobaczę. Jeśli będzie to dla moich zastosowań język odpowiedni chętnie 
> kupę
> książki i się nauczę.

Niestety nie bedzie.
Algol wspiera jedynei Unisys na swoich mainfreimach
Dla swiata maluczkich jest neiznany i niewspierany.
Owszem, ostatnio jakis mlody Norweg zrobil frontend Simuli67
do gcc ale nie pamietam linka.

AK

Witam

Adam Karpierz wrote:

>> Proszę spróbować konstruktywnie podejść do tego języka.
>> Zaprojektować jakiś algorytm objektowo i zobaczy Pan ile
>> pracy jest w nim, a ile daje to zysku.
> 
> Duzo pracy, malo zysku.
> Niepewnosc dzialania.

Ale w kontekście tego co jest na pisane na końcu posta, to chyba tylko
przenieść się trzeba na języki funkcyjne?
 
> Taaa. Wlasnie dzisiaj walcze z szalenstwem mlodych czyli wlasnie
> _dokladnie_ przeladowaneim szablonow
> Zamiast sobie odpoczywac to sobie sam wyznaczylem "wolna"
> sobote _dokladnie_ z powodu szalenczo przeladowwanych szablonow
> uczynionych przez "mlodziez" nieswiadoma jej skutkow.

No ale, czemu za błędy programistów wiesza się psy na języku. Nie wiem czy
znana jest strona: http://thedailywtf.com/.
Tam generalnie można zobaczyć różne bzdury, niektóre naprawdę warto poznać, bo
heureza ich powstania jest ciekawa, to znaczy początkowe założenia są dobre, a
potem kiedy dodaje się kod i dodaje, bez refaktoringu i innych spraw
związanych z przeprojektowywaniem kodu to na końcu powstaje gniot. Ciekawe, że
znaczna większość skarajnie durnych gniotów tam reprezentowanych jest napisana
w Javie, ale nie powiedziałbym, ze to wina Javy.
 
> Powiem bez owijek.
> Za chore szablony C++sowe, za wymysly szalencow typu MPL
> z boosta itp "mainsteamowe wynalazki" powinno sie preogramistom
> ja^H^Hpaluchy obcinac.

Pozwolę sobie niezgodzić się z tym :-). A mogę zapytać w czym jest problem, ale
nie z bibliotekami, tylko naczym problem polega w projekcie? Mi jakoś nigdy
ani MPL, ani szablony nie przeszkodziły, wręcz odwrotnie, są mi cały czas
potrzebne. A generyki w Javie nie są tak rozwinięte i to odrazu czuć nawet na
poziomie projektu aplikacji.

>> W Javie mam pewne problemy, ale może Pan, umie to rozwiązać szybko.
> 
> Nie pisze w ogole w Javie.
> Tzn... juz pisze :) .
> Wlasnie wczoraj napisalem w niej pierszy "program" w zyciu (40 linijek :)

Warto zobaczyć różne implementacje tego samego kodu w obu językach w Javie i w
C++. Mało tego warto pomyśleć o projekcie jak byłby napisany w Javie i w C++,
to jest bardzo dobre ćwiczenie, choć czasem (tak jak teraz) mnie trochę
ciśnie, dlatego w Javie kolega pisze ze mna, sam bym tylko mięsem rzucał.
 
>> Próbowałem Fortrana, ale jakoś nie znalazłem fortrana w wersji objektowej.
> 
> Fortran95, Fortran200x.
> Tyle ze dodanie obiektowki do Fortranu (tak sie tylko poprawnie mowi)
> to poboczny tor czyli kwiatek do kozucha.

Dla mnie objektowość w algorytmach nie jest kwiatkiem do korzucha. Oczywiście
nawet w C można pisać objektowo, tylko, że na schemacie "klas" się kończy
objektowość, co i tak metody tak jak w gtk nazywają się okropnie. Już nie
mówię jak trzeba coś naprawdę poważnego napisać. Inna sprawa to chociażby
biblioteka GSL, moim zdaniem jest świetna, ale w niej jest po prostu jeden
wielki "pointer". Więc kiedy coś z niej potrzebuję to piszę sobie wraper. Mało
tego bardzo łatwo w C++ zasymulować generiksy z Javy oraz równocześnie
prawdziwe szablony z C++. Piszę sobie dwie specjalizacje szablonu. Jedną dla
klasy (normalnej) i to jest w czasie kompilacji fiksowane w kodzie (o ile
potrzeba). A druga dla wskaźnika, do klasy w korzeniu drzewa dziedziczenia i
to mi symuluje generiksy w Javie i mam pełen dynamizm. Mało tego, kiedy mam
takie szablony, nie ma znaczenia, co jest w nich w środku, bo szablon, sam wie
czy np. użyć obiekt.metoda(), czy obiekt->metoda(). Nic mnie nie obchodzi -
piszę obiekt.metoda(), a dotego jeśli ktoś potrzebuje np. coś ala wzorzec
projektowy Pyłek to bierze smartpointer'y i jest dobrze, jednak nie zawsze
chcę mieć wszystko smartpointerami załatwione.

>> Jeżeli może mi Pan podać jakiś internetowy kurs Simuli i Algola, chętnie
>> zobaczę. Jeśli będzie to dla moich zastosowań język odpowiedni chętnie
>> kupę
>> książki i się nauczę.
> 
> Niestety nie bedzie.
> Algol wspiera jedynei Unisys na swoich mainfreimach
> Dla swiata maluczkich jest neiznany i niewspierany.
> Owszem, ostatnio jakis mlody Norweg zrobil frontend Simuli67
> do gcc ale nie pamietam linka.

Więc właśnie, Simula i Algol odpadają w przedbiegach. Fortran jak mówię, jest
miły. Pozostają więc języki funkcyjne - polecam Koguta, choć słabiuteńko go
znam.

Pozdrawiam.

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/   

W artykule <e18ap9$vne$1@tkdami.pl> Seweryn Habdank-Wojewódzki napisal(a):
>>> Jeżeli może mi Pan podać jakiś internetowy kurs Simuli i Algola, chętnie
>>> zobaczę. Jeśli będzie to dla moich zastosowań język odpowiedni chętnie
>>> kupę
>>> książki i się nauczę.
>> 
>> Niestety nie bedzie.
>> Algol wspiera jedynei Unisys na swoich mainfreimach
>> Dla swiata maluczkich jest neiznany i niewspierany.
>> Owszem, ostatnio jakis mlody Norweg zrobil frontend Simuli67
>> do gcc ale nie pamietam linka.
>
> Więc właśnie, Simula i Algol odpadają w przedbiegach. Fortran jak mówię, jest
> miły. Pozostają więc języki funkcyjne - polecam Koguta, choć słabiuteńko go
> znam.

	Adam Karpierz
		ftp://ftp.ifi.uio.no/pub/cim/win32/index.html

		Port cim-a (kompilatora Simuli) na Win32.
		Oparty na mingw (dolaczone).

		Dla dinozaurow i cierpiacych na nostalgie :)
		Ale tez dla innych z otwarta glowa co chca
		zobaczyc jak wygladaly jezyki programowania
		w latach 60-tych. 


http://groups.google.pl/groups?as_oq=algol+simula&as_ugroup=pl.comp.objects


-- 
Pozdrawiam,
Piotr Kuć