Newsgroup: it.comp.lang.c++
Titolo: 35 anni, troppi per programmare?

Ciao a tutti,
ho 35 anni e una discreta conoscenza informatica. Vorrei sapere se sono
troppo vecchio  per cominciare a programmare (mi piacerebbe studiare il c++)
e se ho prospettive di lavoro.
Grazie mille.

 e se ho prospettive di lavoro.
La bella notizia e' che non sei troppo vecchio per cominciare a programmare.
La brutta notizia e' che sei troppo vecchio per avere prospettive di 
lavoro. E' molto raro che un'azienda assuma come programmatore una 
persona di 35 anni che non ha mai fatto il programmatore. Suppongo che 
questo sia dovuto al fatto che un'azienda e' disposta a pagare ben poco 
un apprendista programmatore, e una persona di 35 anni tipicamente 
aspira a uno stipendio decente.
Puo' piu' facile la situazione se lavori gia' in un'azienda e vuoi 
cambiare mansione.
Comunque il c++ e' probabilmente il piu' difficile dei linguaggi e viene 
normalmente usato in applicazioni che richiedono competenze tecniche 
particolari, quindi non e' detto che sia il linguaggio migliore per 
trovare lavoro. Dipende da quali conoscenze applicative hai, e a quale 
settore applicativo sei interessato.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 (mi piacerebbe studiare il c++) e se ho prospettive di lavoro.
Direi che il lavoro nell'informatica in generale non manca ma purtroppo è 
spesso rovinato da falsi imprenditori. Quindi occhio.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 


Come ti han già detto, il C++ non è una buona scelta nella tua 
situazione: richiede molto tempo per essere appreso ed è meno produttivo 
di altri linguaggi RAD come il Visual Basic o il C#... al tuo posto 
opterei per uno di questi due.
Prospettive di lavoro... BOH? Anche a me piacerebbe averne una diversa 
dal fare l'operaio... ed ho 39 anni :-|

Antonio Russo ha scritto:

Non sei troppo vecchio per programmare, anzi se avrò il cervello ancora 
tutto intero a 60, mi piacerebbe imparare ancora nuovi linguaggi, 
speriamo bene.
Per quanto riguarda il lavoro in ambito di programmazione è un schifezza 
(almeno dalla mie parti) perchè non si è ancora capito cos'è un 
programma... quindi il problema non è solo il tuo :D
Impara il c++ per la tua vera goduria, .net/java/o quant'altro per il lavoro
Cya!

 lavoro
Perché farsi del male col c++, potendo scegliere?
Kiuhnm

 ha scritto nel messaggio 
news:4491779d$0$16934$4faf...@reader4.news.tin.it...


 perchè?
Non esiste un linguaggio "per il lavoro".
Ogni linguaggio ha i suoi pro e contro.
Il linguaggio C è quello che offre, tra i più conosciuti, le migliori 
prestazioni, ma rende difficile (ci vuole una grandissima disciplina e 
pazienza) creare vasti progetti. Il C++ sopperisce a quest'ultimo 
difetto, ma è un po' meno efficiente poiché introduce automatismi 
(costruttori, distruttori, funzioni virtuali, ecc...) che, se usati, 
producono solitamente operazioni ridondanti. Non pensare però che il C++ 
sia inefficiente. E' leggermente più inefficiente del C, ma ne vale la 
pena. Inoltre le parti critiche possono essere scritte tranquillamente 
in plain C (saranno un 20% più veloci o poco di più).
Quindi consiglio il C++ se si vuole efficienza e una buona 
corrispondenza tra linee di codice sorgente e linee di codice asssembly.
Se invece ci si vuole concentrare solo sul problema, a scapito 
dell'efficienza e del controllo completo, ma col vantaggio di una 
produttività nettamente più alta, si può andare verso Lisp, Scheme, 
Haskell, Python, Ruby, C#, ecc...
Cerca degli articoli che parlino di questi linguaggi su 
http://www.wikipedia.org/
.
Kiuhnm

 perchè?
Dipende dal lavoro. Diciamo semplicemente che per usarlo bene il C++ è
certamente fra i linguaggi "di massa" il più complesso.
Per usarlo male... ma perchè qualcuno vorrebbe usare qualcosa male?
Se poi non ci dici quello che vuoi farci, è difficile aiutarti.
Complessivamente C++ potrebbe rivelarsi pure poco adatto (o magari
essere l'unica alternativa). Dipende dal campo.
Un programmatore non conosce mai *un* linguaggio. Ce ne sarà uno in cui
è più skillato, ma ne conoscerà bene più di uno, e questo proprio perchè
non c'è un "linguaggio universale". Ogni linguaggio/piattaforma ha
problematiche diverse per quanto riguarda efficienza, portabilità,
scalabilità verso l'alto o "verso il basso", deployment, disponibilità e
uso di librerie.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 in plain C (saranno un 20% più veloci o poco di più).
Mi pare una cifra un po' alta.
Ciao,
Nicola

 grossomodo sono performanti allo stesso modo ?
Secondo me la similitudine di prestazioni resta anche utilizzando eccezioni e 
metodi virtuali, ovviamente a paritą di risultati ottenuti dal codice scritto. 
Tutto si paga e non avere a disposizione certi costrutti non significa 
trovarsi in una situazione migliore dal punto di vista dell'efficienza.



Non è una questione di usare certe funzionalità a sproposito. Puoi 
usarle anche bene. La differenza rimane. Non puoi avvalerti dei vantaggi 
del C++ senza pagarne il prezzo.
Le parti critiche infatti le scrivo in C usando puntatori nudi e crudi, 
ecc...
La percentuale è quella riportata da varie fonti.
Kiuhnm

 linguaggi grossomodo sono performanti allo stesso modo ?
Dipende da cosa intendi per "grossomodo".
http://citeseer.ist.psu.edu/549129.html
"Object-oriented programming is widely accepted as a methodology for 
writing modular and reusable code. In embedded applications however, 
designers should consider when taking hardware/software decisions, the 
performance penalty that is introduced by the use of object-oriented 
code. In this paper, it has been demonstrated, through the compilation 
and execution of benchmarks on an embedded processor simulator, that OOP 
can result in a significant increase of both execution time and power 
consumption. In embedded systems where low power operation is the 
primary requirement, object oriented techniques can result in an energy 
dissipation overhead in all system components such as the processor 
core, the instruction and data memories. Since compilers usually cannot 
optimize code to reach the level of procedural programming performance, 
the number of executed instructions increases, increasing proportionally 
the instruction level power consumption. Moreover, care should be taken 
when opting for object oriented style, especially in large programs, 
since data abstraction can lead to a large code size increase resulting 
in a significantly higher power consumption of the instruction memory."
Kiuhnm

 La percentuale è quella riportata da varie fonti.
Continua a tornarmi poco. Giusto per fare un esempio, se devi
implementare un meccanismo di dispatching magari userai uno switch,
magari un'array di puntatori a funzione; se usi l'array di puntatori
non c'e' una gran differenza ad usare funzioni membro virtuali. Del
fatto poi che di default i costruttori e i distruttori di default non
fanno proprio niente abbiamo gia' parlato.
Quello che invece puo' giocare negativamente e' un'implementazione non
ottimale delle eccezioni che, in effetti, puo' avere effetti negativi
senza motivo.
Altrimenti l'unico caso concreto di differenza prestazionale di cui
sono a conoscenza e' un'applicazione su cui lavora un mio amico in C++
su Linux. Questi, almeno qualche anno fa, avevano il loop fondamentale
che era costituito per ragioni prestazionali da un unico switch
generato automaticamente, il cui file sorgente era compilato piu'
efficientemente da gcc come sorgente C che come sorgente C++. Il mio
amico non e' mai riuscito a individuare il motivo in modo certo.
Ciao,
Nicola


Non discuto i loro risultati, ma vanno presi con un grano di sale. Loro
hanno verificato che uno specifico compilatore non compila il C++ in
modo ottimale. Per il resto si rifanno ad una letteratura che ha
mediamente dieci anni. Sarebbe interessante vedere come stanno le cose
con tecnologie un po' piu' aggiornate.
C'e' poi embedded ed embedded. Se ci si fa andare persino Java...
Ciao,
Nicola

 con tecnologie un po' piu' aggiornate.
Purtroppo l'interesse dei ricercatori si è spostato verso altri linguaggi.
Kiuhnm

Nicola Musatti ha scritto:

sapreste dirmi se, con il compilatore sottostante a visual C++ . 
net (versione express), esiste la possibilità di creare codice 
assembler intermedio come output ?
Il vecchio borland lo faceva, ricordo, ma sul C++ M$ non ho 
trovato opzioni utili allo scopo.
Sarebbe forse il modo migliore di toccare effettivamente con 
mano quale e quanta è questa differenza di efficienza nella 
compilazione.
Ciao
Soviet

 fanno proprio niente abbiamo gia' parlato.
Mah, su internet si trovano molti risultati contrastanti e non ho 
trovato nessuna pubblicazione recente, imparziale e allo stesso tempo 
affidabile.
Kiuhnm

 ha scritto nel messaggio 
news:449e6a41$0$16931$4faf...@reader4.news.tin.it...


 richiedono le aziende di solito?grandi e piccole.
Dipende molto dall'ambito applicativo.
E' ben diverso sviluppare il software di contabilità per una banca, 
sviluppare il software di controllo di un sistema aerospaziale, o 
sviluppare un sito Web per il commercio elettronico. E ci sono tanti 
altri settori applicativi.
Poi dipende dalla dimensione del progetto.
E' ben diverso sviluppare una soluzione in un paio di settimane su 
commissione, dallo sviluppare un complesso insieme di applicazioni su 
cui lavorano decine di programmatori da una quindicina d'anni.
Poi dipende anche dal mercato. E' ben diverso sviluppare una soluzione 
per un singolo cliente che la installerà su una sola macchina, dallo 
sviluppare un pacchetto che viene commercializzato a migliaia di utenti 
che lo installano su computer di vari tipi.
Raramente le aziende hanno bisogno di una persona che sappia solo 
programmare. Gli sviluppatori devono conoscere un po' anche il settore 
applicativo.


 Soviet
Ho sotto mano solo .net2002, project properties -> c/c++ -> Output Files
->
Assembler output.
Tommaso
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 La percentuale è quella riportata da varie fonti.
I puntatori nudi e crudi non sono mai stati il punto forte di efficienza
del C, specialmente i puntatori a funzione.


 del C, specialmente i puntatori a funzione.
Ehi, siamo nel 2006 ;)
Kiuhnm

 Ehi, siamo nel 2006 ;)
e nel 2006 i puntatori a funzione sono ancora meno efficienti dei
function objects ad esempio...
vedi ad esempio std::sort passando un function object e qsort del C
passando un puntatore a funzione.
Tommaso


 function objects ad esempio...
Non è colpa mia se confronti cose diverse.
Kiuhnm

>>Ehi, siamo nel 2006 ;)
e poi ho parlato di puntatori a funzione vs function objects per dare un
esempio in cui i puntatori a funzione non sono il massimo di efficienza.
in fine, visto che la discussione verteva verso C vs C++ mi sono
appoggiato al discorso puntatori a funzione vs function objects per fare
un esempio concreto:
qsort in C usa puntatori a funzione e sort in C++ puo' prendere function
objects e sort del C++ e' piu' performante (proprio per il fatto che non
usa puntatori a funzione (a meno che tu non decida di passarne uno)).


 esempio in cui i puntatori a funzione non sono il massimo di efficienza.
Potresti scrivere un piccolo test autocontenuto (niente std)?
Kiuhnm


Già che c'ero, ho scritto un piccolo test.
I risultati sono:
_debug_
funzione = 23906
functor = 26547
_release_
funzione = 578
functor = 2375
 >>>>>>>>
typedef int (*SumPtr)(int, int);
int sum(int a, int b)
{
	return a+b;
}
struct Sum
{
	virtual int operator()(int, int) = 0;
};
struct MySum : Sum
{
	int operator()(int a, int b)
	{
		return a+b;
	}
};
int SumN(SumPtr f, unsigned n)
{
	int t = 0;
	++n;
	while (--n)
	{
		t = f(t, n);
	}
	return t;
}
int SumN(Sum& f, unsigned n)
{
	int t = 0;
	++n;
	while (--n)
	{
		t = f(t, n);
	}
	return t;
}
#include "windows.h"
#include <iostream>
unsigned const N = (unsigned)5e8;
int main()
{
	DWORD start, time;
	int r;
	start = GetTickCount();
	r = SumN(sum, N);
	time = GetTickCount() - start;
	std::cout << time << " (" << r << ")" << std::endl;
	start = GetTickCount();
	r = SumN(MySum(), N);
	time = GetTickCount() - start;
	std::cout << time << " (" << r << ")" << std::endl;
}
<<<<<<<<
Kiuhnm

 
GAZIE 1000
ciao
soviet

 	r = SumN(MySum(), N);
grazie!!!
provalo cosi senza metodi virtuali ed inheritance, altrimenti non stai
testando stessa cosa:
typedef int (*SumPtr)(int, int);
int sum(int a, int b)
{
	return a+b;
}
struct MySum
{
	int operator()(int a, int b)
	{
		return a+b;
	}
};
int SumN(SumPtr f, unsigned n)
{
	int t = 0;
	++n;
	while (--n)
	{
		t = f(t, n);
	}
	return t;
}
int SumN(MySum& f, unsigned n)
{
	int t = 0;
	++n;
	while (--n)
	{
		t = f(t, n);
	}
	return t;
}
#include "windows.h"
#include <iostream>
unsigned const N = (unsigned)5e8;
int main()
{
	DWORD start, time;
	int r;
	start = GetTickCount();
	r = SumN(sum, N);
	time = GetTickCount() - start;
	std::cout << time << " (" << r << ")" << std::endl;
	start = GetTickCount();
	r = SumN(MySum(), N);
	time = GetTickCount() - start;
	std::cout << time << " (" << r << ")" << std::endl;
}
e ora dimmi il risultato, il mi pc dice:
2234
0
in release


 	r = SumN(MySum(), N);
r2 = SumN(???, N);
Kiuhnm

 r2 = SumN(???, N);
quindi diventa semplicemente:
r = SumN(MySum(), N);
r2 = SumN(MySum2(), N);
Vedi, il C fornisce i puntatori a funzione e questi rendono difficile il
compito del optimiser. Usando alcune caratteristiche del C++, in questo
caso i funciton objects ed i templates, puoi raggiungere nella maggior
parte dei casi un risultato simile ma con codice piu' efficiente.
Nota che ovviamente anche utilizzando i templates il tempo di esecuzione
e' 0 ed e' zero in quanto il compilatore riesce ad ottimizzare talmente
tanto da calcolare tutto at comile time. In altri casi la differenza non
e' cosi' netta, ma ottieni il vantaggio di avere la funzione inline,
cosa che di solito non avviene con i puntatori a funzione (usando
virtual, rendi impossibile il compito del optimiser di mettere il
function object inline).
Ora so bene che il tuo esempio con virtual ed inheritance si avvicina di
piu' all'uso dei puntatori a funzione, in particolare se cerchiamo
comportamenti run-time invece che compile time. In pratica pero' spesso,
come nella maggior parte degli usi di qsort e sort, la funzione da usare
la sai at compile time e non solo at run time e putroppo i puntatori a
funzione non ti aiutano a sfruttare questo vantaggio.
Nel caso tu sappia la funzione solo at-compile-time, puoi in alcuni casi
usare i templates:
if(cond)
   SumN(MySum1(), N);
else
   SumN(MySum2(), N);
ma in pratica questo e' molto restrittivo ed e' sicuramente piu' potente
usare virtual ed inheritance (immagina una lista di funzioni da usare
una dopo l'altra, per fare un esempio stupido).
Come al solito si tratta di bilanciare l'uso delle features del C++.
Sappiamo tutti che la parola virtual si traduce in overhead. Pero'
sappiamo anche che i function objects sono piu' facili da rendere inline
e che i templates e la programmazione generica non hanno nessun overhead
in tempi di esecuzione (non in grandezze eseguibile).
In sostanza se ti serve un sistema veloce ed efficiente, spesso non
bisogna ricorrere al C (od al sotto insieme C del C++), ma si puo'
benissimo fare una scelta razionale di quali features del C++ usare,
quali usare sporadicamente e quali evitare. Ricorrere al C e' spesso la
scleta che fa colui che non conosce il C++.
Per completezza riporto il tuo esempio, in cui, visto che uso i
templates, lascio al compilatore il compito di generare SumN che prende
un puntatore a funzione (invece di farlo io a mano):
#include "windows.h"
#include <iostream>
int sum(int a, int b)
{
	return a+b;
}
struct MySum
{
	int operator()(int a, int b)
	{
		return a+b;
	}
};
template <typename T>
int SumN(T &f, unsigned n)
{
	int t = 0;
	++n;
	while (--n)
	{
		t = f(t, n);
	}
	return t;
}
unsigned const N = (unsigned)5e8;
int main()
{
	DWORD start, time;
	int r;
	start = GetTickCount();
	r = SumN(sum, N);
	time = GetTickCount() - start;
	std::cout << time << " (" << r << ")" << std::endl;
	start = GetTickCount();
	r = SumN(MySum(), N);
	time = GetTickCount() - start;
	std::cout << time << " (" << r << ")" << std::endl;
}
ed il risultato e' sempre:
1906 
(-2083310976
)
0 
(-2083310976
)
Come gia' ho detto fancendo un esempio meno trivial la differenza e'
meno netta.


 funzione non ti aiutano a sfruttare questo vantaggio.
In realta' con i function objects spesso si puo' evitare l'uso di
templates e persino di virtual ed ottenere cmq una flessibilita' at run
time!
Supponi di avere:
typedef int (*OpPtr)(int, int);
Ovvero una operazione che prende due int e restituisce un int. Questi
sono due esempi:
int sum(int a, int b)
{
	return a+b;
}
int prod(int a, int b)
{
	return a*b;
}
e quindi possiamo scrivere:
int OpN(OpPtr f, unsigned n)
{
	int t = 0;
	++n;
	while (--n)
	{
		t = f(t, n);
	}
	return t;
}
e chiamare OpN:
OpN(sum, N);
OpN(prod, N);
Ovviamente questa implementazione permetted i passare un OpPtr senza
sapere cosa esso sia fino at run time (ad esempio prenderlo da una lista
di OpPtr).
Possiamo ottenere lo stesso risultato con i function objects e senza
l'uso di virtual ne di templates. L'implementazione non e'
elegantissima, se cerchi una implementazione elegante usa virtual, ma
spesso la seguente implementazione e' piu' veloce:
struct MyOp
{
	enum OP { SUM, PROD };
	MyOp(OP op):m_op(op){}
	int operator()(int a, int b)
	{
		if(m_op==SUM) return a+b;
		else return a*b;
	}
private:
	OP m_op;
};
a questo punto possiamo fare:
OpN(MyOp(MyOp::SUM), N);
OpN(MyOp(MyOp::PROD), N);
e anche in questo caso si puo' avere una implementazione dove si sappia
solo l'operazione at run time e si puo' avere una lista di oggetti di
tipo MyOp, alcuni avranno m_op come somma ed altri come prodotto.
Quindi invece di ricorrere all'elegante OO ed all'uso di virtual,
abbiamo usato il costruttore e lo state dell'oggeto (tramite memeber
variable).
Il risultato e' che l'optimiser ancora puo' fare miracoli e nel caso di:
OpN(MyOp(MyOp::SUM), N);
OpN(MyOp(MyOp::PROD), N);
ancora metterci tempo 0.


Tommaso Galleri wrote:
[...]
Rispondo a tutto in una volta sola.
Usando
struct MyOp
{
	enum OP { SUM, PROD };
	MyOp(OP op):m_op(op){}
	int operator()(int a, int b)
	{
		if (m_op==SUM)
			return a+b;
		else
			return a*b;
	}
private:
	OP m_op;
};
ottengo tempi uguali.
Controlliamo che codice genera il compilatore:
r1 = OpN(sum, N);
genera
00401017  xor         ecx,ecx
00401019  mov         eax,1DCD6500h
0040101E  mov         edi,edi
00401020  add         ecx,eax
00401022  sub         eax,1
00401025  jne         main+20h (401020h)
00401027  mov         dword ptr [esp+14h],ecx
ovvero
   tot = 0;
   n = 5e8;
here:
   tot += n;
   --n;
   if (n) goto here;
   ris = tot;
Nota "mov edi,edi". Ecco un motivo per il quale il compilatore batte 
spesso l'uomo nel produrre codice asm ottimizzato. Pochi si sognerebbero 
di aggiungere istruzioni "inutili".
Tale istruzione, tra le altre cose, fa sì che "here:" si trovi a un 
indirizzo multiplo di 16.
Invece,
r2 = OpN(MyOp(MyOp::SUM), N);
genera
00401035  xor         ebx,ebx
00401037  mov         eax,1DCD6500h
0040103C  lea         esp,[esp]
00401040  add         ebx,eax
00401042  sub         eax,1
00401045  jne         main+40h (401040h)
che è equivalente al codice precedente.
Nota come questa volta venga usato
lea esp, [esp]		; nop!
La differenza è minima perché fuori dal loop.
Ti faccio notare che, senza scrivere direttamente il risultato(!), non 
si può fare di meglio.
Inoltre il risultato ottenuto in questo test (531,531) è paragonabile a 
quello che ottenevo già nel test precedente (578).
Anche usando i template (ho compilato il tuo test), ottengo sempre gli 
stessi risultati.
Non si può fare di meglio. Se il tuo compilatore restituisce tempo 0, 
significa che sostituisce l'intero loop con un
mov ris, VALUE.
Non molto leale, vero? ;)
Prova a usare una variabile al posto di N.
Adesso capisci perché dico che siamo nel 2006?
Kiuhnm

 Rispondo a tutto in una volta sola.
Dimenticavo una cosa.
Nel vecchio West, quando ancora non esistevano i template e i 
compilatori non erano cosě ottimizzanti, facevamo cosě:
 >>>>>>
#define MakeOpN(OPERATOR)		\
int OPERATOR##OpN(unsigned n)	\
{								\
	int t = 0;					\
								\
	++n;						\
	while (--n)					\
	{							\
		t = OPERATOR(t, n);		\
	}							\
								\
	return t;					\
}
int sum(int a, int b)
{
	return a+b;
}
int prod(int a, int b)
{
	return a*b;
}
#include "windows.h"
#include <iostream>
const unsigned N = (unsigned)5e8;
MakeOpN(sum)
MakeOpN(prod)
int main()
{
	DWORD start, time1, time2;
	int r1, r2;
	start = GetTickCount();
	r1 = sumOpN(N);
	time1 = GetTickCount() - start;
	start = GetTickCount();
	r2 = prodOpN(N);
	time2 = GetTickCount() - start;
	std::cout << time1 << " (" << r1 << ")" << std::endl;
	std::cout << time2 << " (" << r2 << ")" << std::endl;
}
<<<<<<
Kiuhnm

 Adesso capisci perché dico che siamo nel 2006?
no! sara' che il mio compilatore e' del 2002 forse? Ma forse no visto
che il tuo del 2006 non riesce ad ottimizzare a tempo 0 calcolando tutto
at compile time!
Ad ogni modo basta leggere:
- C++ standard library
- Effective STL
- Technical report on C++ performance (
http://www.research.att.com/~bs/performanceTR.pdf
 )
- e sicuramente altro
per trovare qualche paragrafo che dica come i function objects si
prestino ad essere ottimizzati meglio rispetto ai puntatori a funzione e
come questo porti a prestazioni migliori.
In sostanza la maggior parte della letteratura supporta la mia tesi e
non la tua. A questo punto se non ti ho convinto credo che dovro'
rinunciare...


 rinunciare...
Ho ampiamente dimostrato quanto ho affermato. I test si devono sapere 
analizzare, altrimenti č inutile farli.
Fare calcolare direttamente il risultato non č consentito perché č un 
caso particolare.
Tu hai detto che i puntatori a funzione sono meno efficienti e io ti ho 
dimostrato che i compilatori attuali generano codice inline.
Dovresti arrivarci anche tu al fatto che se il compilatore genera due 
codici equivalenti sia per ptr a funzione che per functor, allora come 
calcola direttamente il risultato per uno puņ generarlo anche per l'altro.
Ma il tempo che ti dedico finisce qui.
Kiuhnm

 Ma il tempo che ti dedico finisce qui.
E per fortuna. E poi ero convinto di essere io a dedicare tempo a te
per
metterti a conoscenza di un concetto semplice, dimostrabile e di cui
tutta la letteratura parla (sostenendo la mia tesi), ma purtroppo non
vuoi vedere la verita'.
Alla prossima.
Tommaso

"Kiuhnm" wrote :
Questo e' facilmente ottimizzabile, ma e' "orribile". Inoltre devi
manaulmente istanziare le varie funzioni:
MakeOpN(sum)
MakeOpN(prod)
Se ti interessa questo comportamento compile time, ora che ci sono i
template perche' ferirsi da soli con le macro?
Allora torniamo ai function objects ed ai templates, no?
Siamo nel 2006 ;-) Ovvimente questa e' una battuta visto che parlavi di
vecchio west...
Tommaso

 Alla prossima.
Spinto dalla curiosità, ho dato un'occhiata al test proposto nel pdf da 
te segnalato.
Considera
sort( v_table.begin(), v_table.end(), less_than_function2 );
Questa linea produce codice più lento per il semplice fatto che il 
compilatore non inserisce la funzione sort in linea perché troppo lunga 
e non è stato istruito a creare una seconda sort come farebbe in 
presenza dei template.
Non c'è alcun impedimento tecnico poiché less_than_function2 è un 
puntatore costante conosciuto a compile/linking time.
Se non si vuole avere il minimo dubbio, si può definire il puntatore 
costante in modo che il compilatore sia sicuro che non venga modificato 
all'interno di f.
typedef int (fptr)(int);
int f(fptr* const p, int i)
{
     return p(i);
}
Non c'è veramente nessun impedimento tecnico.
Kiuhnm

 Purtroppo l'interesse dei ricercatori si è spostato verso altri linguaggi.
Sai dire quali ? 
Ciao,
Marco.


 Sai dire quali ? 
Java, C#, Python, ecc...
La sfida principale è quella di renderli il più efficienti possibile.
Kiuhnm