🚀 go-pugleaf

Witam

A.L. wrote:

> For one thing, templates hurt the C++ compiler's ability to generate
> efficient code. 

To jest nie prawda. Proszę przestudiować następujący kawałek kodu:

// pierwszy.hpp
// -------------------------------------------
double foo ( const double & x )
{
  ...
}

double foo ( const int & x )
{
  ...
}

// drugi.hpp
// -------------------------------------------
templates < typename T >
double foo ( const T & x )
{};

template <>
double foo ( const double & x )
{
  ...
}

template<>
double foo ( const int & x )
{
  ...
}

Tutaj właśnie pojawia się siła szablonów i programowania z ich użyciem.
Kiedy w kodzie NIE zostanie użyta żadna funkcja foo to kiedy zaincludujemy
pierwszy.hpp to i tak kod zostanie wyposażony w te funkje foo. W sytuacji
kiedy zaincludujemy drugi.hpp to kompilator nie stworzy, żadnej
konkretyzacji tej funkcji, a tatem kod ich nie będzie zawierał, przez co
będzie lżejszy. Teraz proszę sobie wyobrazić ogólną bibliotekę, która
została przygotowana pod kątem wielu różnych typów i klasycznie napisany
kod będzie zawierał wszystkie metody, które zostały zaincludowane, a
szablonowy kod, będzie zawierał TYLKO takie które "mają pokrycie" w kodzie
programu - to sprawdza kompilator a nie programista, i kompilator
wyoptymalizuje kod tak, aby był zgrabny i nie zawierał niepotrzebnego
narzutu.

Autor publikacji jest nie objektywny, bo porównuje np.

int myCleverFunction() {
  return 4;
}

is just a regular function, but

template <int N>
int myCleverFunction() {
  return N;
}

Porównywanie takiego kodu jest złe ponieważ obie funkcje są diametralnie
różne, a to z prostej przyczyny, że gdyby chciał mieć wiele np. 30, 50, 100
funkcji myCleverFunction, to musiałby je sam wygenerować - dowolnie wybraną
przez siebie słudszną metodą, począwszy od pisania ręcznego, skońszywszy na
mało sprytnych generatorach kodu. Natomiast szablon sam to za niego
załatwi. Pomijam fakt, że to co poniżej się nieskompiluje i trzeba użyć
triku, który pozwoli napisać coś w tym stylu.

int myCleverFunction() {
  return 4;
}

int myCleverFunction() {
  return 13;
}

Autor pisze o różnych kostrukcjach typu: fun h(a,b) = g(f(a,b)) szkoda, że
nie napisał kodu w C++, którym takie złożenia sią robi, jakby przeczytał
opis biblioteki standardowej to rozumiałby, że da się to zrobić bardzo
efektywnie (przykład już podawałem w innym wątku).

Dalej.

#include <stdio.h>

template <int n>
class Fact {
public:
  static const int val = Fact<n-1>::val * n;
};

class Fact<0> { public: static const int val = 1; };

int main() {
  printf("fact 4 = %d\n", Fact<4>::val);
  printf("fact 5 = %d\n", Fact<5>::val);
  printf("fact 6 = %d\n", Fact<6>::val);
  printf("fact 7 = %d\n", Fact<7>::val);

  return 0;
}

I autor pisze, że g++ -S generuje kiepski kod. Autor w tym przypadku wykazał
się brakiem wiedzy o procesie kompilacji, bo wszyscy wiedzą, że:

1) g++ a dokładnie gcc nie jest rewelacyjny, i użyty bez jakiej kowiek flagi
optymalizacji generuje kod asemblera bardzo zły, gorszy niż to mógłby
zrobić zły koder. Uzywając samego g++ sprawdzamy tylko i wyłącznie
poprawność kodu, a nie towrzymy jego optymalnej wersji.

2) użycie g++ ale z opcją -O1 już nie mówię o -O3 i serii opcji
poprawiających optymalizację szablonów pozwala na wygenerowanie takiego
kodu, że autor nie miałby się do czego przyczepić.

Jeżeli celem publikacji było napisanie, że C++ jest "be" a Lisp jest super
to autor i tak pobłądził, bo od lispa Haskel jest chyba lepszy. Po drugie,
nie bardzo rozumiem porównania teoretycznej jakości wygenerowanego kodu a
tym co pisze o kawałkach funkcyjnych, zresztą to że pisze kod tylko w
Lispie świadczy, że nie umie ich napisać w C++, a zatem jego ocena
porównania jest nie całkiem obiektywna. Po ostatnie, języki funkcyjne są
językamie funkcyjnymi, a C++ nie jest nim, więc "panie ale ło so chosi".
Można niektóre kostrukcje "functional-like" napisać w C++, ale to nie czyni
go językiem funkcyjnym.

Szkoda, że nie porównał Lispa z Pythonem.

Pozdrawiam.

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