🚀 go-pugleaf

A.L. wrote:

> Tak jest w Javie. A jak jest w C++?...
> 
> A.L.
> 
> "You might imagine that List<Integer> stands for a version of List
> where E has been uniformly replaced by Integer:
> 
> public interface IntegerList { void add(Integer x)
> Iterator<Integer> iterator();
> }
> 
> This intuition can be helpful, but it’s also misleading.
> It is helpful, because the parameterized type List<Integer> does
> indeed have methods that look just like this expansion.
> 
> It is misleading, because the declaration of a generic is never
> actually expanded in this way. There aren’t multiple copies of the
> code: not in source, not in binary, not on disk and not in memory.
> If you are a C++ programmer, you’ll understand that this is
> very different than a C++ template. 
> 
> A generic type declaration is compiled once and for all, and turned
> into a single class file, just like an ordinary class or interface
> declaration. Type parameters are analogous to the ordinary
> parameters used in methods or constructors.
> Much like a method has formal value parameters that describe the
> kinds of values it operates on, a generic declaration has formal
> type parameters. When a method is invoked, actual arguments are
> substituted for the formal parameters, and the method body is
> evaluated. When a generic declaration is invoked, the actual type
> arguments are substituted for the formal type parameters..."

To co Pan tu przytacza może się wydawać ciekawym rozróżnieniem dwóch 
różnych podejść, ale z drugiej strony szybko się załamuje, jeśli 
popatrzymy na różne warianty implementacyjne jakiejś jednek koncepcji 
projektowej. W przypadku C++ polecam rozmyślania nad interpreterami w 
przeciwieństwie do kompilatorów. W przypadku tego powyżej polecam 
rozmyślania nad optymalizacją w stylu JIT.

Nadal uważa Pan, że mamy tu do czynienia z kompletnie odrębnymi 
podejściami? ML kompilowany przez JIT może wygenerować osobny kod 
maszynowy dla typów, z którymi dana generyczna metoda była do tej pory 
wywołana (oops, zabrzmiało jak MAKROGENERATOR), podczas gdy interpreter 
C++ może nie tworzyć osobnego kodu dla każdej konkretyzacji, tylko 
najnormalniej w świecie interpretować ciało szablonu instrukcja po 
instrukcji i korzystając np. z wzorca Strategy realizować różne 
zachowania zależnie od typu parametrów aktualnych.

Nie obraź się Pan, ale emocje odbierają Panu umiejętność zachowania 
równowagi.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/