🚀 go-pugleaf

Sektor van Skijlen napisał(a):
> Dnia Sat, 22 Oct 2005 16:39:18 +0200, jarekr skrobie:
> 
>>>>(w dowolnym assemblerze wskaźnik do funkcji ustawić 
>>>>można w jednej linijce i nawet sie typem nie trzeba przejmować !).
>>>
>>>
>>>Ale nie rozumiem, co to ma do tematu ;)
>>
>>Do jest do tego co dopiero przed chwilą napisałeś (musiałem wyprzedzić 
>>dyskusje). Przeczytaj swój paragraf.
> 
> 
> Nie, nie rozumiem, co ma argument dotyczący asemblera do rzeczy. Asembler
> traktujemy jak kod wynikowy, jaki by ten asembler nie był. Co mnie obchodzi
> asembler?

To jest ogólny argument na to ile linijek sie trzeba napisać w jakim
języku. Zajrzyj na 99 bottles, żeby zobaczyć do czego to prowadzi.


> 
> 
>>Przestań pleść dyrdymały i napisz w końcu - kod - o co Ci chodzi?
> 
> 
> Jaki kod mam ci pokazać, skoro mówię o rzeczy, której w Javie zrobić NIE
> MOŻNA? A w innych językach - cóż, w różnych językach jest to możliwe na różne
> sposoby (poza Javą, każdy znany mi język to umożliwia).
> 
> Jeśli nie rozumiesz o czym mówię, to nie krępuj się; wytnik po prostu ten
> akapit i daj sobie spokój. Powiedziałem wyraźnie w jednym zdaniu najpierw,
> potem doprecyzowałem w drugim akapicie - jest to właściwość, jakiej Java po
> prostu nie posiada, w odróżnieniu od chyba wszystkich pozostałych
> imperatywnych języków (mówię "chyba", bo przecież wszystkich nie znam).


Nie... weż wreszcie w C++ mi pokaż odpowiednik tego czego nie można w javie.

>>>Po pierwsze, to ja mimo wszystko wolę mieć dowolny kompilator do wyboru, niż
>>>jedno centrum decyzyjne tworzące język i jego implementację.
> 
> 
>>Bzdury pleciesz.
>>W javie jest jedno centrum (SUN) zarządzające standardem. Dostarcza też 
>>jedną implementację.
>>Inne implementacje dostarcza IBM, BEA (JRockit). Korzystałem z tych 
>>implementacji wielokrotnie - wiem, ze są bardzo dobrze zgodne z sunowską 
>>javą.
> 
> 
> Implementację CZEGO? Kompilatora, czy VM?

Dokładnie jednego i drugiego. Można sobie co więcej zamiennie stosować
np. kompilator z IBM do javy sunowskiej - jak chcesz - wymagania są
DOKŁADNIE napisane.

>>Jest też (absurdalny)  gcj. (zgodny ale powolny )
>>Te wszystkie implementacje muszą spełniać pewne standardy (albo dostają
>>czerwoną kartkę jak MS Java).
> 
> 
> Taa... o ile pamiętam, to MS dostał tą kartkę za wprowadzanie "nielegalnych
> rozszerzeń" (a nie za braki w zgodności z istniejącą wersją języka). Nazywanie
> tego strzeżeniem standardu jest co najmniej kpiną i hipokryzją.
> 
> MS się zresztą nie przejął specjalnie wyrokiem, tylko wypuszczał swoją Javę
> dalej pod nazwą J++. A potem zrobili C#.
> 
> Sun zawłaszczył Javę po to, żeby się częściowo zabezpieczyć przed konkurencją,
> przecież to jasne. Nawet kiedy Rational próbował zrobić implementację Javy na
> .NET, to Sun wytoczył mu proces.


TO czemu GNU, IBMowi i BEI nie zabronił - nie kumam. A moze jednak
java na .NET to może nie być do końca Java ?  (Ja to nazwałbym  nauczyli 
sie na przykładzie ms javy )

>>Dzięki temu nie mam w kodzie ton makr, 
>>które muszą naprawiać niekompatybilności i inne takie.
> 
> 
> Po prostu, zwyczajny język katedralny. Nie, sory, mnie te makra w najmniejszym
Idź sie naprawde umyj. TO jest naprawde ciekawe, że w tej chwili jeden z
   najczęsciej przemysłowo stosowanych jezyków jest katedralny :-)


> Może powiedzmy to bardziej szczerze: nie ma tych ton makr, bo po prostu nie ma
> w tym języku makr. Dywagowanie, dlaczego makra nie są używane do naprawienia
> problemów kompatybilności jest co najmniej bezcelowe.

A jednak - posiadanie języka w którym nie trzeba łatać i można sobie
podmieniać dostawce kompilatora (bo np. BEA JRockit czasem jest istotnie
szybsza od sunowskiej) ma pewne plusy.


> 
>>TO ty zasugerowałeś zebym zaglądał do boost::mpl. Pech chciał, że 
>>zaglądnąłem.
> 
> 
> To co, mam rozumieć, że jak ty mi podpowiesz, żebym sobie zobaczył jakąś
> bibliotekę Javy, to powinienem zajrzeć do jej implementacji?

Cała dyskusja była  na temat jakie to piękne rzeczy można templatami
stworzyć w C++ co miało być widać w boost::mpl. Ale boost::mpl jest 
daleki od piękna - i taka jest niestety codzienność C++.

>>>No, bardzo chętnie się dowiem, jakie to techniki w Javie są stosowane zamiast
>>>RAII i zapewniają tą samą skuteczność zarządzania zasobami. I nie rozśmieszaj
>>>mnie znów argumentem, że to rzadka potrzeba i nic nie szkodzi, że mało
>>>wygodne.
> 
> 
>>Znowu się rozwodzisz nad finally -  a ja napisałem jest inna prosta 
>>technika.
> 
> 
>>Po prostu zamiast takiego zapisu jak w C++:
>>{
>>        DBConnection db("bla");/*klasa DBConnection ma odpowiednio napsiany 
>>destruktor i konstruktor*/
> 
> 
>>        [kod koprzystający z db]
>>}
> 
> 
>>mam taki (java):
>>{
>>        dbManager.execute ( new DBMethod()  {
>>                        public void run(final DBContext context)
>>                        {
>>                                DBConnection db =                               context.createConnection("bla");
>>                                [kod koprzystający z db]
>>                        }
>>                } );
>>}
> 
> 
>>po prostu o ile w C++ kluczowe zarządzanie zasobami mam w konstruktorze 
>>i destruktorze to w Javie wywalam do odpowiedniego menadżera.
> 
> 
> O jaciekrence...
> 
> A czegoś takiego, żeby można tego było użyć po ludzku?

To jest po ludzku - ja tego używam, w kodach różnych OR mapperów to
znajdziesz itp.

> Bo takiego czegoś to można również użyć w C# (tyle że wyszłoby znacznie
> prościej i krócej).

Super. Ja też sie ciesze, że C# daje rade.

> I co, do każdego typu będziesz sobie tworzył takie opakowanie, żeby ci się
> zrobiło ładne RAII? Zaleta C++ nie polega na tym, że można sobie samemu
> zaplanować akcje w konstruktorze i destruktorze, tylko że zwykle w
> istniejących już typach konstruktor i destruktor mają odpowiednio zaplanowane
> działanie. Trzeba ich tylko po prostu użyć.
> 
> Wiesz, na dobrą sprawę, to preprocesora C też możesz używać w Javie. Co to za
> problem.

Wiem, ale nie używam preprocesora C.

>>Dla programisty końcowego efekt jest podobny. Może sobie tworzyć ile 
>>chce  - po wylezieniu z funkcji (klamry) - wszystko jest zamykane. (bo 
>>metoda execute w menadżerze ma finally :-) .)
> 
> 
> Ale dla programisty początkowego różnica jest diametralna.
> 
> A może użyjesz generyków, żeby móc to zastosować do różnych typów?
> 
> Wiemy przecież, że nie użyjesz, bo te generyki są zbyt jujowe, żeby się tak
> dało.

Szczerze mówiąc - używam w tym celu :-)


> 
>>gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
> 
> 
> Ta, jasne. I sądzisz, że będzie ci to działało na każdej platformie i każdej
> wersji każdego kompilatora z każdym zestawem opcji? Oj ty młody i naiwny ;)

A ty piszesz kod, który działa na każdej platformie, z każdym zestawem
opcji ? (to bedzie ciekawe - biorąc pod uwagę, ze każdy release
kompilatorów C++ uzupełnia kolejne braki (pamietam jak długo czekałem na
"export template")

> Użyłeś tutaj niegwarangowanej właściwości: że referencja będzie
> zaimplementowana tak, jak wskaźnik, oraz, że możesz swobodnie dokonać
> "rzutowania przez unię" referencji na wskaźnik. Nie ma takiej gwarancji
> niestety w standardzie; kompilator mógł cię oszukać. Nawet na tym samym
> kompilatorze w tej samej wersji może ci to działać lub nie w zależności od
> opcji kompilacji.
Swoją drogą zamierzałem użyc jeszcze bardziej niegwarantowanej własności
(unia).

> Zatem to już jest pierwszy minus.
> 
> Drugi minus: Popatrz, ile musiałeś się namęczyć i natworzyć własnych typów
> danych i narzutować po kilka razy, żeby uzyskać void* będący i tak jedynie
> hipotetycznym adresem tego obiektu w pamięci (jak wspomniałem, jest to
> nie gwarantowane przez standard, podobnie np. jak to że dla dwóch kolejno
> zadeklarowanych zmiennych lokalnych x i y tego samego typu nie musi być
> prawdą, że &x+1 == &y).

Działa... nie jest to takie wielkie namęczenie. Zauważ, że kod napisałem
dość czytelnie. Można to pewnie było w 2 linijki walnąć.

> Przykro mi, niezaliczone. Zgłosi się pan za tydzień.
taa minusy wsadź sobie w...
ja uważam, że wisisz mi połówkę.
działa - możesz sprawdzić.
Poza tym:
1. właśnie widzisz co oznacza brak standardu i dlaczego tyle jest makr w
bibliotekach standardowych - wychodzi na to, że całkiem nie taki
hakerski kod w C++ może zupełnie różnie działać... pięknie.

2. naprawdę myślisz że znajdziesz kompilator w którym sobie nie poradze
? (czy może szybko taki machniesz)


>>(nie przykładałem sie do nazw i kodu - tak z palca strzeliłem za drobną 
>>poprawką - przyznam, sie ze pierwszy pomysł nie działał (referencje nie 
>>mogą być częścią uni ) )
> 
> 
> Ten pomysł też tak naprawdę nie działa.
> 
> Rzutowanie dowolnego wskaźnika na void* działa i będzie działać. Można go też
> zrzutować spowrotem i też będzie działać. To standard gwarantuje.
> 
> To, co ty wyczyniłeś, nie gwarantuje, bo nigdzie nie jest napisane, że pola
> typów referencyjnych mają taką samą reprezentację, jak wskaźniki do tych
> typów.

Działa - działa. :-)
Mam to na ekranie - możesz sam sobie sprawdzić.
Powiem więcej - uznasz porażkę - albo ja uznam, ze nie warto z tobą
dyskutować bo masz pan błone półprzepuszczalną.


>>dokładnie tylko i wyłacznie konkurencja - dla tego samego powodu w javie 
>>są annotacje. nie ma tego w C++ i chyba nie płaczesz.
>>Nie będe Cie przekonywać, że są niezbędne. (bo nie są)
> 
> 
> Oczywiście, że nie płaczę, podobnie jak w C++ mam RTTI i też mi to jak dziura
> w zębie potrzebne.
> 
> A co do annotacji - cóż, najwyraźniej faktycznie zadziałała konkurencja, nawet
> wiadomo dokładnie która i na czym te annotacje wzorowano.
> 
> 
> 
> 
> Cóż, faktem jest, że doświadczenia w tych językach się nie krzyżują. Ale, jak
> wspomniałem, bardzo chętnie się dowiem, jakież to techniki bazowane na C++ są
> niefortunnie stosowane w Javie. Jakieś przykłady, chętnie ze źródłami.

(odpisałem w innym msg) ale tak dla dodatku ( troche mi sie przypomniało)
  number 1 - double checked locking... który, zeby było zabawniej w C++
też nie ma gwarancji działania :-)
number 2 - metody wirtualne w konstruktorze - nie ma chyba programisty
C++, który by po przejsciu na javę się na tym nie wyłożył
number 3 - jest dużo koncepcji typu
	object = null; } // 	ludzie wierzą, że to przypisanie działa jak delete
(chyba zapełniają pustkę po delect object; )   -ale to fakt
jest nie od ludzi mądrych - tyle, że nie mogłem pominąć - bo to jest
wręcz wyznacznik kodu pisanego przez konwertytę
number 4 - nieużywanie tablic - w javie są normalne i porządne tablice
	ale doświadczony programista C++ nawet na nie nie patrzy tylko
	używa ślepo wszędzie List<> itp. - to jest np. mój problem :-) 	
number 5 - brak zrozumienia  dla koncepcji
	niestatycznych klas wewnętrznych ogólnie	
	- te w javie dodają jednak troche lukru syntaktycznego  i 	
	rozwiązują mnóstwo pozornych braków Javy


-- 
http://www.99-bottles-of-beer.net/language-java-866.html