🚀 go-pugleaf

Sektor van Skijlen napisał:

> Z bardzo prostej przyczyny: nikt jeszcze nie podał żadnego racjonalnego
> kontrargumentu. Masz okazję, chwilowo nie wiem dlaczego nie skorzystałeś.
> 
> 
>>to że w javie, żeby wykonywać 
>>operacje na funkcjach potrzeba czasem więcej linijek kodu niż w C++
>>jest słabym argumentem.
> 
> 
> Nie bądź śmieszny. To nie jest tylko "trochę więcej linijek" (nb. nie rozumiem
> dlaczego fakt, że trzeba się więcej opisać w dokładnie tym samym stylu, ma być
> słabym argumentem).
> 
> 
>>(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 pozwala operowa? zmiennymi typów ?cis?ych (jedynie ich warto?ciami)
>>>
>>>
>>>>Ze co?...
>>>
>>>
>>>Przekaż mi pan zmienną do metody. Tak, żeby metoda mogła ją zapisać.
>>>
>>
>>Panu A.L. chodziło, jak mniemam o sens twojego zdania - teraz lekko 
>>doprecyzowałeś. (nadal dziwnie, ale już chyba wiem o co Ci chodzi (ale 
>>nie wierzę ...bo to kuriozalny argument) )
>>Lepiej pokaż konkretnie (kod).
> 
> 
> Oj przestań, nawet mnie nie próbuj zanudzać stwierdzeniami, że w Javie się "po
> prostu piszę inaczej", że powinienem zmienić mój sposób myślenia i stosować
> inne techniki, bo się rozpłaczę do rozpuku. To samo słyszę nt. każdego
> narzekania na właściwości Javy i to narzekania nie tylko takich gołodziobów
> jak ja, którzy jedynie "stosują jak muszą", ale prawdziwych praktyków, którzy
> na z niejednego pieca projektach zęby zjedli.

Przestań pleść dyrdymały i napisz w końcu - kod - o co Ci chodzi?


>>>>>- nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
>>>>> jeden wielki pic na wod?; zwyk?y lukier sk?adniowy)
>>>
>>>
>>>>Niby dlaczego?..
>>>
>>>
>>>Sprawdź sobie pan boost::mpl (co ja mówię! Głupie STL!), to się dowiesz.
> 
> 
>>znajdzie zapewne tak piękne fragmenty jak:
>>
>>>#include <boost/mpl/aux_/config/msvc.hpp>
>>>#include <boost/mpl/aux_/config/workaround.hpp>
> 
> 
> Ty sobie lepiej zajrzyj do implementacji Swings. Bo to, co pokazałeś niżej, to
Nie wiem co to jest Swings.
> jest tylko workaround na badziewny kompilator (co nawet widać po tych dwóch
> pierwszych linijkach). Gdyby to był kod pisany tylko pod kompilatory
> rzeczywiście zgodne ze standardem, nie byłoby żadnych makr. Zresztą, niech
> dzisiaj będzie dzień dziecka:
> 
> 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ą.
Jest też (absurdalny)  gcj. (zgodny ale powolny )
Te wszystkie implementacje muszą spełniać pewne standardy (albo dostają
czerwoną kartkę jak MS Java). Dzięki temu nie mam w kodzie ton makr, 
które muszą naprawiać niekompatybilności i inne takie.


> Po drugie, co mnie obchodzi implementacja? Do implementacji zaglądam jak
> jestem ciekawy, jak to goście wykoncypowali. Użytkownika interesuje jedynie
> interfejs.

TO ty zasugerowałeś zebym zaglądał do boost::mpl. Pech chciał, że 
zaglądnąłem.

>>>>>- nie pozwala stosowa? mechanizmu RAII
>>>
>>>
>>>>Ze co?..
>>>
>>>

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

>>( w końcu wszelkie biblioteki do 
>>obsługi różnych zasobów są dawno popisane  )
> 
> 
> Tak, szczególnie takich, o których twórcy owych bibliotek nie mieli szans
> wiedzieć w czasie pisania.
>>>
>>>>> zezwolenia udzielane s? wybiórczo; w tym wszystkim oczywi?cie te? brak
>>>>> przeci??ania operatorów)
>>
>>Wybiórczo?, zezwolenia w C++? O ile ktoś sie do d... nie dobierze 
>>rzutując na jakiś void*.
> 
> 
> Oj ty młody i naiwny...
> 
> Masz tu klasę:
> 
> class Value
> {
> public:
> 	int in;
> 
> private:
> 	int operator&() const { return 0; }
> 	template <class T>
> 	operator T&();
> 
> 	template <class T>
> 	operator const T&() const;
> };
> 
> Wiszę ci półkę, jak mi zmienną typu Value zrzutujesz na void*. Powodzenia.

to weź to Panie nie naiwny:
#include <iostream>

class Value
{
public:
	int in;

private:
	int operator&() const { return 0; }
	template <class T>
	operator T&();

	template <class T>
	operator const T&() const;
};


class BadValue
{
public:
	int in;
};

class Proof
{
public:
	BadValue*  v;
};

class BadUnion
{
public:
	const Value& v;
	
	BadUnion( const Value& argV)
	: v(argV)
	{
	}		
};

int main()
{

	Value v2;

	v2.in = 3;
	std::cout<<"\ntest a:"<<v2.in;

	BadUnion bu(v2);
				
	Proof* cham = (Proof*)&bu;

	std::cout<<"\ntest b:"<<(int)cham<<"\n";
		
	//i tu mam void*
	void* cham2 = (void*)&(*(cham->v));
	std::cout<<"\ntest f:"<<(int)cham2<<"\n";

	BadValue* cham3 = (BadValue*)(cham2);
	std::cout<<"\ntest c:"<<cham3->in<<"\n";
	cham3->in = 666; //tu jest zło :-)
	std::cout<<"\ntest d:"<<v2.in<<"\n";	
}


gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

(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 ) )
>>A w javie jakoś te aplety, servlety, ejb i inne inszety działają i 
>>"wyoranie się z java security" nie jest takim trywialnym zagadnieniem.
> 
> 
> Mnie średnio interesuje, jakie security muszą przejść te różne napletki i
> serwetki. To ma się nijak do języka - jest to zupełnie osobna kwestia, którą
> dana aplikacja musi przejść niezależnie od języka, w którym jest napisana.
> 
> 
>>>Kiedyś ludzie mówili, że doskonale, że Java nie ma niczego takiego, jak wzorce
>>>w C++. Po czym dodano generyki.
> 
> 
>>Jasne... pewnie dlatego "Generic java" - projekt, który po prostu 
>>niedawno wszedł do standardowej dystrybucji (po pewnych modyfikacjach) 
>>był utworzony gdzieś około roku 1998.
> 
> 
> Całkiem nieźle. Niedawno, czyli będzie to tak ze dwa lata temu (nie pamiętam,
> od kiedy dokładnie generyki są w Javie). Nawet licząc, że stało się to po
> czterech latach od momentu utworzenia i nawet licząc duży overhead formalny,
> to trzeba przyznać, że goście "długo główkowali". Jak na to, co wymyślili, to
> powinno im to zająć góra dwa miesiące, no, trzy powiedzmy, jeśli liczymy, że
> dwa z tych miesięcy zajął formalny overhead.

nie czytasz, nie wiesz, pleciesz - generic java działało gdzieś od 1999 
własnie...
a tylko tyle czasu Sun nie mógł się zdecydować czy to wpleść do 
dystrybucji. (zresztą imho - nie musiał - to był krok czysto 
marketingowy - ja z generic java korzystałem swobodnie dużo wcześniej).

> Skoro jednak zajęło im to aż tyle czasu, to widzę tylko jedno racjonalne
> wyjaśnienie: po prostu generyki zrobili zapaleńcy, którzy doskonale zdawali
> sobie sprawę z tego, że są one potrzebne (dla każdego człowieka, który wie,
> czym się różni statyczna i dynamiczna typizacja, zwłaszcza w języku
> wspierającym OO, jest to co najmniej oczywiste). Ale nikt nie miał zamiaru
> dodawać ich do języka; edukatorzy i piewcy woleli robić z siebie idiotów i
> udowadniać na wszelkie możliwe sposoby, że wzorce są beee... Dopiero gdy się
> okazało, że taktyka namawiania ludzi do "porzucenia starego sposobu myślenia"
> przestaje skutkować, zwłaszcza jak się pojawiła konkurencja - postanowiono
> skorzystać.
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ą)

>>Z drugiej strony, mimo że osobiście bardzo lubię generyki,  to. 
>>zastanawiam się czy w dużych projektach ograniczenie sie do używania 
>>tylko generycznych kolekcji nie byłoby dobrym rozwiązaniem.
> 
> 
> Tak, najlepiej to w ogóle ograniczcie ilość używanych klas do biblioteki
> standardowej i tak po jednej klasie na pakiet. Oczywiście że trzeba wprowadzić
> takie ograniczenia, żeby sobie programiści Javy rączek nie poparzyli.

męczy już mnie twoja buta.
> Nie wiem, jak to się dzieje, że jakoś ANI RAZU (!) nie zdarzyło mi się widzieć
> w C++ jakiegoś "bardzo nieładnego" kodu, który by wykorzystywał wzorce albo
> przeciążanie operatorów. Dokładnie było odwrotnie: kody używające tych
> właściwości były napisane wręcz z wzorcową starannością. Natomiast najgorzej
> i najniechlujniej napisany kod to był kod pisany "w stylu języka C".
> 
> Jestem przekonany, że nie jestem jedynym, ani wyjątkiem, ani ewenementem pod
> tym względem. Tylko jakoś nie słyszę, żeby ktoś wyciągnął z tego jeden
> najbardziej oczywisty w tej sytuacji wniosek: nie należy się obawiać
> programistów używających wzorców i przeciążania operatorów. Należy się,
> however, jak ognia bać programistów, którzy więcej pisali w C, niż w C++.

No to własnie przeżywam to samo, tylko poziom wyżej.
Ja się obawiam zarówno programistów C i takich co przenoszą 
doświadczenia z C++ do javy.

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