🚀 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
`\/\/'

On Mon, 04 Sep 2006 14:13:13 +0200, Seweryn Habdank-Wojewódzki
<habdank@gmail.com> wrote:
 
>
>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. 

Who cares?...

A.L.

Odpowiedź do listu Wielce Szanownej Pani / Szanownego Pana ‹Seweryn
Habdank-Wojewódzki›. Wysłannik wyższej inteligencji tako rzecze :):

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

Czy nie jest tak, że trzeba posiadać tyle programów, że ich suma będzie
używać absolutnie każdej funkcji z biblioteki standardowej, więc
integracja (inline) funkcji standardowych w jednym programie (jeśli nie
są to małe funkcje, składające się z kilku instrukcji maszynowych)
prowadzi do zwiększenia sumarycznego rozmiaru oprogramowania?

> 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

static int N = 4;

int po_co_mi_ta_stala_w_funkcji( int n )
{
	return n;
}

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

Faktycznie– w C++ występuje efekt przenoszenia wyniku w strumieniu,
czyli typowo przy użyciu operatora przypisania bądź ‚<<’, tak samo jak w
uniksowych potokach. Czy o to chodziło? Lecz to tylko jednowymiarowa
liniowość a nie obiektowość.


Wasz
--
: qo   |)     =@=N%_g=v=a=g_ed_e=c()=d=8= %IGn@8're: w8in ad
:    _x/ ,     H'%'a'h4'HA.XO'Xo'xo'xO.R %expo1ited: *-1 teh
:    |    ng  __%-- __ -- __ -- __ -- __%/by$qVerCo: &GooMee
^.__ -- __ -- %yahoo.com group: opRWTng%/^v^'^ww^v^;_<E-O-F>

Witam

A.L. wrote:

> On Mon, 04 Sep 2006 14:13:13 +0200, Seweryn Habdank-Wojewódzki
> <habdank@gmail.com> wrote:
>  
>>
>>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.
> 
> Who cares?...

Nie "who cares", tylko lekkość w tym kontekście implikuje szybkość. Wydaje
mi się, że ten post jest poniżej Pańskiego poziomu. Szkoda, że Pan tak
często obniża loty, bo obaj wiemy, że potrafi Pan wykazywać rozsądek. Ale
jakoś w kontekście C++ to jakoś chyba emocje biorą górę. A szkoda.

Pozdrawiam.

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

"A.L." <alewando@fala2005.com> wrote

>"For one thing, templates hurt the C++ compiler's ability to generate 
>efficient code" ......
> " C++ templates hide your intentions from the compiler: did you mean type 
> abstraction? Did you mean a
> syntax extension? Did you mean constant-folding or compile-time code
> generation? The compiler doesn't know, so it has to just blindly
> apply the copy-and-paste strategy and then see what happens."

Wytknijcie mi gdzie sie myle, ale dla mnie ten fragment nie ma krzty sensu. 
Autor tutaj najwyrazniej strzela sobie samoboja. Jesli przyjac - za 
autorem - , ze kompilator stosujac copy&paste z czegos takeigo :

template<typename T> void Fun(T val)
{
    std::cout << "Val = " << val << "\n";
}

wygeneruje np. 2 funkcje

void Fun(int  val);    (1)
void Fun(double val); (2)

to gdzie tu szablony "hurt the C++ compiler's ability to generate efficient 
code" ?
Czym sie to bedzie roznic od sytuacji gdy programista sam sobie napisze 
funkcje (1) i (2) zamiast szablonu?
Kompilator bedzie szczesliwszy? Nie sadze... Pomijam tu w ogole kwestie 
optymalizacji konkretnych kompilatorow bo o tym autor chyba tez zapomnial. A 
tak ogolnie to caly ten "artykul" to mi wyglada na hymn pochwalny ML na tle 
przypadkowo dobranej ofiary. Nie dowiedzialem sie co jest nie tak z 
szablonami C++, za to wiem czemu ML jest taki fantastyczny.

pzdr
Muchomor

On Mon, 4 Sep 2006 23:56:06 +0200, "Muchomor"
<muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:

 
>
>Wytknijcie mi gdzie sie myle, ale dla mnie ten fragment nie ma krzty sensu. 
>Autor tutaj najwyrazniej strzela sobie samoboja. Jesli przyjac - za 
>autorem - , ze kompilator stosujac copy&paste z czegos takeigo :
>
>template<typename T> void Fun(T val)
>{
>    std::cout << "Val = " << val << "\n";
>}
>
>wygeneruje np. 2 funkcje
>
>void Fun(int  val);    (1)
>void Fun(double val); (2)
>
>to gdzie tu szablony "hurt the C++ compiler's ability to generate efficient 
>code" ?
>Czym sie to bedzie roznic od sytuacji gdy programista sam sobie napisze 
>funkcje (1) i (2) zamiast szablonu?
>Kompilator bedzie szczesliwszy? Nie sadze..

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..."
 

On Mon, 04 Sep 2006 19:28:54 -0500, A.L. <alewando@fala2005.com>
wrote:
 
>
Kawalek mi ucielo

A.L.
>

>Here is a small excerpt from the definitions of the interfaces List and Iterator in package
>Java.util:
>public interface List<E> { void add(E x);
>     Iterator<E> iterator();
>}
>public interface Iterator<E> { E next();
>     boolean hasNext();
>}
 
>
>"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..."
> 

"A.L." <alewando@fala2005.com> wrote in message 
news:g1hpf2hs913nsgggpv1dntbhpojg98mcts@4ax.com...
> On Mon, 4 Sep 2006 23:56:06 +0200, "Muchomor"
> <muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:
>
>
>>
>>Wytknijcie mi gdzie sie myle, ale dla mnie ten fragment nie ma krzty 
>>sensu.
>>Autor tutaj najwyrazniej strzela sobie samoboja. Jesli przyjac - za
>>autorem - , ze kompilator stosujac copy&paste z czegos takeigo :
>>
>>template<typename T> void Fun(T val)
>>{
>>    std::cout << "Val = " << val << "\n";
>>}
>>
>>wygeneruje np. 2 funkcje
>>
>>void Fun(int  val);    (1)
>>void Fun(double val); (2)
>>
>>to gdzie tu szablony "hurt the C++ compiler's ability to generate 
>>efficient
>>code" ?
>>Czym sie to bedzie roznic od sytuacji gdy programista sam sobie napisze
>>funkcje (1) i (2) zamiast szablonu?
>>Kompilator bedzie szczesliwszy? Nie sadze..
>
> Tak jest w Javie. A jak jest w C++?...
>
Ja nie wiem "jak jest w C++". W kazdym kompilatorze C++ inaczej zapewnie, 
ale nie tak jak w Javie - "A generic type declaration is compiled once and 
for all". Mi chodzi o to, ze autor pisze bzdury jesli zalozyc, ze kompilator 
C++ stosuje do szablonow taktyke copy&paste.

pzdr
Muchomor 

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/

On Tue, 05 Sep 2006 10:17:34 +0200, Maciej Sobczak
<no.spam@no.spam.com> wrote:
 
>
>Nie obraź się Pan, ale emocje odbierają Panu umiejętność zachowania 
>równowagi.

Co sie Panu pomieszalo. Ten tekst po angielsku to nie ja napisalem,
ja go zacytowalem. To widac Panu emocje odbieraja mozliwosc
rozroznienia co kto napisal.

A.L>

On Tue, 5 Sep 2006 08:02:49 +0200, "Muchomor"
<muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:
 
>>
>Ja nie wiem "jak jest w C++". W kazdym kompilatorze C++ inaczej zapewnie, 
>ale nie tak jak w Javie - "A generic type declaration is compiled once and 
>for all". Mi chodzi o to, ze autor pisze bzdury jesli zalozyc, ze kompilator 
>C++ stosuje do szablonow taktyke copy&paste.

A jaka taktyke stosuje?..

A.L.

"A.L." <alewando@fala2005.com> wrote in message 
news:lntqf29rstc4m2qht63kbpqmevd0bekahp@4ax.com...
> On Tue, 5 Sep 2006 08:02:49 +0200, "Muchomor"
> <muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:
>
>>>
>>Ja nie wiem "jak jest w C++". W kazdym kompilatorze C++ inaczej zapewnie,
>>ale nie tak jak w Javie - "A generic type declaration is compiled once and
>>for all". Mi chodzi o to, ze autor pisze bzdury jesli zalozyc, ze 
>>kompilator
>>C++ stosuje do szablonow taktyke copy&paste.
>
> A jaka taktyke stosuje?..
>

Panie A.L. Pan sie przestanie wyglupiac, dobrze? Nie tego dotycza moje 
posty.

pzdr
Muchomor 

On Tue, 5 Sep 2006 18:05:26 +0200, "Muchomor"
<muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:

>
>"A.L." <alewando@fala2005.com> wrote in message 
>news:lntqf29rstc4m2qht63kbpqmevd0bekahp@4ax.com...
>> On Tue, 5 Sep 2006 08:02:49 +0200, "Muchomor"
>> <muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:
>>
>>>>
>>>Ja nie wiem "jak jest w C++". W kazdym kompilatorze C++ inaczej zapewnie,
>>>ale nie tak jak w Javie - "A generic type declaration is compiled once and
>>>for all". Mi chodzi o to, ze autor pisze bzdury jesli zalozyc, ze 
>>>kompilator
>>>C++ stosuje do szablonow taktyke copy&paste.
>>
>> A jaka taktyke stosuje?..
>>
>
>Panie A.L. Pan sie przestanie wyglupiac, dobrze? Nie tego dotycza moje 
>posty.
>

Rozumiem ze Pan nie ma argumentow wiec sie Pan zdenerwowal. 

Zas w kwestii "czego dotycza Panskie posty":

a) W artykule napisano ze C++ stosuje "cut and paste"
b) Pan napisal ze nei stosuje
c) Ja zapytalem "a jaka taktyke stosuje"? zakladajac ze jezeli Pan
mowi ze nei stosuje "cut and paste" to Pan wie jaka taktyke stosuje
d) Pan sie wzbudzil

Wynika stad ze Pan nei wie. Jak Pan nei wie, to neich Pan siedzi
cicho i patrzy jak starsi dyskutuja.

A.L.

"A.L." <alewando@fala2005.com> >
>>Panie A.L. Pan sie przestanie wyglupiac, dobrze? Nie tego dotycza moje
>>posty.
>>
>
> Rozumiem ze Pan nie ma argumentow wiec sie Pan zdenerwowal.
>
> Zas w kwestii "czego dotycza Panskie posty":
>
> a) W artykule napisano ze C++ stosuje "cut and paste"
> b) Pan napisal ze nei stosuje

nieprawda "Jesli przyjac - za autorem - , ze kompilator stosujac copy&paste 
" - ja tu niczego nie neguje. Co wiecej z tym copy&paste to jest blizej 
prawdy niz dalej, ale nazywanie tej taktyki copy&paste bez dodatkowych 
wyjasnien to mocne naduzycie. Poza tym przypominam, ze nie to jest tematem 
tej rozmowy.

> c) Ja zapytalem "a jaka taktyke stosuje"? zakladajac ze jezeli Pan
> mowi ze nei stosuje "cut and paste" to Pan wie jaka taktyke stosuje
> d) Pan sie wzbudzil
>
> Wynika stad ze Pan nei wie. Jak Pan nei wie, to neich Pan siedzi
> cicho i patrzy jak starsi dyskutuja.
>

Panie A.L. ma Pan fascynujacy dar odwracania kota ogonem.
Pozwoli Pan, ze przypomne :
"Wytknijcie mi gdzie sie myle, ale dla mnie ten fragment nie ma krzty sensu" 
itd..
Zadalem pytanie dotyczace pewnego fragmentu artykulu, ktory mi sie nie 
spodobal i poprosilem o wyjasniene liczac, ze zobacze "jak starsi 
dyskutuja". Na roboczo przyjalem, ze - tak jak pisze autor - kompilatory C++ 
stosuja copy&paste do szablonow, zaznaczajac, ze nie interesuje mnie 
dyskusja czy tak jest czy nie.
Nie wyobrazam sobie by ktos, kto znalazl artykul, przeczytal go, zrozumial i 
doceniajac jego wartosc merytoryczna postanowil sie nim podzielic z szerszym 
gronem, nie ustosunkowal sie do jego fragmentow. No wiec jak to jest Panie 
A.L. - uwaza Pan, ze autor sie pomylil, brak mu wiedzy, swiadomie klamie, ma 
racje czy jeszcze cos innego? Przypomne, ze chodzi mi o "templates hurt the 
C++ compiler's ability to generate efficient code" a nie o copy&paste.

pzdr
Muchomor 

Muchomor napisał(a):
> "A.L." <alewando@fala2005.com> wrote in message 
> news:lntqf29rstc4m2qht63kbpqmevd0bekahp@4ax.com...
>> On Tue, 5 Sep 2006 08:02:49 +0200, "Muchomor"
>> <muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:
>>
>>> Ja nie wiem "jak jest w C++". W kazdym kompilatorze C++ inaczej zapewnie,
>>> ale nie tak jak w Javie - "A generic type declaration is compiled once and
>>> for all". Mi chodzi o to, ze autor pisze bzdury jesli zalozyc, ze 
>>> kompilator
>>> C++ stosuje do szablonow taktyke copy&paste.
>> A jaka taktyke stosuje?..
>>
> 
> Panie A.L. Pan sie przestanie wyglupiac, dobrze? Nie tego dotycza moje 
> posty.
> 

nie, on nie przestanie, splonkuj go i niech się nie wychyla, ja tak 
zrobiłem i jest spokój, czasem tylko jak ktoś odpowiada to mi się w oczy 
rzucają jakieś brednie

Witam

Muchomor wrote:

> Nie wyobrazam sobie by ktos, kto znalazl artykul, przeczytal go, zrozumial
> i doceniajac jego wartosc merytoryczna postanowil sie nim podzielic z
> szerszym gronem, nie ustosunkowal sie do jego fragmentow.

Zobacz co napisałem i jakie fragmenty poddałem pod praktyczną rowagę
pokazując dotkliwe kawałki kodu dla teorii autora tej już nieco
przestarzałej publikacji.

> Przypomne, ze chodzi mi 
> o "templates hurt the C++ compiler's ability to generate efficient code" a
> nie o copy&paste.

Copy & Paste. W innym wątku pokazałem konstrukcję w C++ wyrażenia typowego
dla języków funkcyjnych czyli "compose" 

Coś ala lispowe 
( define ( compose f g )
  ( lambda (x y) ( f ( g ( x y ) g ( x y ) ) ) ) ).

Tutaj strategia copy & paste ot tak po prostu nie działa, potrzebne jest
trochę sprytu, proszę spróbować napisać np: #define który działa podobnie.

Pozdrawiam.

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

"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:

> Czym sie to bedzie roznic od sytuacji gdy programista sam sobie napisze 
> funkcje (1) i (2) zamiast szablonu?

Dokladnie niczym.

Tzn.. niedokladnie :).

Napisanie funkcji jest bezpieczneijsze bo w przypadku szablonu
gdy programista sie "wlansie" i wywola:
char x;
...
Fun(x)

to jednak funkcja void Fun(char val) zostanie wygenerowana
a w przypadku "recznego" napisania nie.

Szablony C++ sa bledogene bo czasami generowane sa "po cichu"
rzeczy ktorych wcale nie chcemy i ktorych nie przewidzielismy.

AK 

"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:

> Ja nie wiem "jak jest w C++". W kazdym kompilatorze C++ inaczej zapewnie, 
> ale nie tak jak w Javie - "A generic type declaration is compiled once and 
> for all". Mi chodzi o to, ze autor pisze bzdury jesli zalozyc, ze 
> kompilator C++ stosuje do szablonow taktyke copy&paste.

Kompilator C++ stosuje do szablonow taktyke copy&paste.

AK 

"Adam Karpierz" <karpierz@NOOOOSPAAAAMpython.pl> writes:

> Kompilator C++ stosuje do szablonow taktyke copy&paste.

Ale na poziomie drzew składni, a nie tekstu. Bliżej szablonom do makr
Lispa niż do makr C.

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

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

>> Kompilator C++ stosuje do szablonow taktyke copy&paste.
>
> Ale na poziomie drzew składni, a nie tekstu.

Dokladnie.
Nie ma to jednak znaczenia dla semantyki.
Semantyka jest copy&paste.

> Bliżej szablonom do makr Lispa niż do makr C.

Nie wspomnialem nic na temat preprocesora C.

AK 

Witam

Adam Karpierz wrote:

> Szablony C++ sa bledogene bo czasami generowane sa "po cichu"
> rzeczy ktorych wcale nie chcemy i ktorych nie przewidzielismy.

Poproszę o przykład.

Pozdrawiam.

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

Dnia Fri, 8 Sep 2006 13:15:08 +0200, Adam Karpierz skrobie:
> "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

> >> Kompilator C++ stosuje do szablonow taktyke copy&paste.
> >
> > Ale na poziomie drzew składni, a nie tekstu.

> Dokladnie.
> Nie ma to jednak znaczenia dla semantyki.
> Semantyka jest copy&paste.

Copy&Paste&Select&Expand&Simplify itd.

Masz ty pojęcie o wzorcach gorsze, niż ja o Javie.

> > Bliżej szablonom do makr Lispa niż do makr C.

> Nie wspomnialem nic na temat preprocesora C.

To podaj przykład istniejącego makrogeneratora, któremu do wzorców jest
bliżej.



-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(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"

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

> Witam
>
> Adam Karpierz wrote:
>
>> Szablony C++ sa bledogene bo czasami generowane sa "po cichu"
>> rzeczy ktorych wcale nie chcemy i ktorych nie przewidzielismy.
>
> Poproszę o przykład.

Przykładami usiane jest Piekło Tych, Co Nie Znają Się Na Rzeczy ;>

On Fri, 8 Sep 2006 16:38:27 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 
>
>To podaj przykład istniejącego makrogeneratora, któremu do wzorców jest
>bliżej.

M4, ML/1

A.L.

Dnia Fri, 08 Sep 2006 11:48:31 -0500, A.L. skrobie:
> On Fri, 8 Sep 2006 16:38:27 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
>  
> >
> >To podaj przykład istniejącego makrogeneratora, któremu do wzorców jest
> >bliżej.

> M4, ML/1

Oj... jeszcze bardzo daleko, niestety.

Mam pytanie do "wielibicieli makrogeneratorów": czy coś, poza faktem, że
konkretyzacje funkcji w kodzie wynikowym (powiedzmy: na poziomie plików *.o)
są osobnymi procedurami, usprawiedliwia nazwanie wzorców makrogeneratorem? Bo
jak do tej pory to mam wrażenie, że nic. Poproszę o dalsze przykłady
podobieństw.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(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"

On Fri, 8 Sep 2006 17:57:02 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

>Dnia Fri, 08 Sep 2006 11:48:31 -0500, A.L. skrobie:
>> On Fri, 8 Sep 2006 16:38:27 +0000 (UTC), Sektor van Skijlen
>> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
>>  
>> >
>> >To podaj przykład istniejącego makrogeneratora, któremu do wzorców jest
>> >bliżej.
>
>> M4, ML/1
>
>Oj... jeszcze bardzo daleko, niestety.
>
>Mam pytanie do "wielibicieli makrogeneratorów": czy coś, poza faktem, że
>konkretyzacje funkcji w kodzie wynikowym (powiedzmy: na poziomie plików *.o)
>są osobnymi procedurami, usprawiedliwia nazwanie wzorców makrogeneratorem?

Wzorce to wzorce. Wzorce to dane wejsciowe do makrogeneratora.
Makrogenerator to procesor pzrtwarzajacy wejscie na wyjscie wedlug
programu napisanego w jezyku makroprocesora.  

Proponuej apozanc sie z jakas lietratura, na przyklad wydana pzred
laty po polsku ksiazka Browna "Makroprocesory"

A.L.

Dnia Fri, 08 Sep 2006 14:13:30 -0500, A.L. skrobie:
> On Fri, 8 Sep 2006 17:57:02 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

> >Dnia Fri, 08 Sep 2006 11:48:31 -0500, A.L. skrobie:
> >> On Fri, 8 Sep 2006 16:38:27 +0000 (UTC), Sektor van Skijlen
> >> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
> >>  
> >> >
> >> >To podaj przykład istniejącego makrogeneratora, któremu do wzorców jest
> >> >bliżej.
> >
> >> M4, ML/1
> >
> >Oj... jeszcze bardzo daleko, niestety.
> >
> >Mam pytanie do "wielibicieli makrogeneratorów": czy coś, poza faktem, że
> >konkretyzacje funkcji w kodzie wynikowym (powiedzmy: na poziomie plików *.o)
> >są osobnymi procedurami, usprawiedliwia nazwanie wzorców makrogeneratorem?

> Wzorce to wzorce. Wzorce to dane wejsciowe do makrogeneratora.
> Makrogenerator to procesor pzrtwarzajacy wejscie na wyjscie wedlug
> programu napisanego w jezyku makroprocesora.  

Panie AL, wiem co to jest makroprocesor i jak działa. Co do tego się akurat
całkiem zgadzamy.

Nie zgadzamy się natomiast, że to, jak działają wzorce w C++, jest z tym
zgodne.

Pytałem o przykłady właściwości wzorców w C++, które są tożsame z
właściwościami makrogeneratorów. I prosiłbym o przykłady związane z wzorcami
klas.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(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"

On Fri, 8 Sep 2006 20:14:09 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 
>
>Pytałem o przykłady właściwości wzorców w C++, które są tożsame z
>właściwościami makrogeneratorów. I prosiłbym o przykłady związane z wzorcami
>klas.


Powyzsze zdanie nei ma sensu, w szczegolnosci pytanie o "wlasiwosci
makrogeneratorow". Suponuje w dalszym czigu ze Pan nie rozumie co to
ejst makrogenerator. Makrogenerator nei ma zadnych "wlasciwosci".

A.L.

Dnia Fri, 08 Sep 2006 15:29:18 -0500, A.L. skrobie:
> On Fri, 8 Sep 2006 20:14:09 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
>  
> >
> >Pytałem o przykłady właściwości wzorców w C++, które są tożsame z
> >właściwościami makrogeneratorów. I prosiłbym o przykłady związane z wzorcami
> >klas.


> Powyzsze zdanie nei ma sensu, w szczegolnosci pytanie o "wlasiwosci
> makrogeneratorow". Suponuje w dalszym czigu ze Pan nie rozumie co to
> ejst makrogenerator. Makrogenerator nei ma zadnych "wlasciwosci".

Jest to zatem aksjomat?

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(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"