[C++] Tuple e argomenti typelist

[giuseppe500]

ciao.
Sto cercando di capire come si crea un function object parametrizzato;
il primo parametro template(double) èil tipo di ritorno del function object , e la typelist , tratta da Loki sono i tipi dei parametri

// Define a Functor that accepts an int and a double and
// returns a double
Functor<double, TYPELIST_2(int, double)> myFunctor;

il function object viene poi specializzato cosi':

template <typename R>
class FunctorImpl<R, NullType>
{
public:
virtual R operator()() = 0;
virtual FunctorImpl* Clone() const = 0;
virtual ~FunctorImpl() {}
};
template <typename R, typename P1>
class FunctorImpl<R, TYPELIST_1(P1)>
{
public:
virtual R operator()(P1) = 0;
virtual FunctorImpl* Clone() const = 0;
virtual ~FunctorImpl() {}
};
template <typename R, typename P1, typename P2>
class FunctorImpl<R, TYPELIST_2(P1, P2)>
{
public:
virtual R operator()(P1, P2) = 0;
virtual FunctorImpl* Clone() const = 0;

virtual ~FunctorImpl() {}
};

mi chiedevo dato che esistono le tuple nel tr1 , fosse possibile utilizzare in qualche modo quelle.
è possibile specializzare un template che accetta delle tuple in base ai tipi della tuple?
Il problema ruota attorno ai parametri che devo passare al FunctorImpl(implementazione del function object) i parametri devono avere un tipo e un valore di quel tipo ew possono essere molti.
Sul libro consiglia di usare un numero alto di parametri nella typelist, ad es 12 per risolvere i problemi.

se potessi uare le tuple non dovrei integrare loki nei miei progetti , almeno per quanto riguarda i functon object parametrizzati, che sono alla fine degli oggetti command(secondo gof).

il fatto è che queste typelist sono spesso comode , ma hanno un implementazione incasinata.
Forse è possibile includere solo i file di questetypelist nel mio sorgente, voi mi consigliereste di utilizzarle? o di farne a meno?


grazie.

[shodan]

Considera che il libro di Alexandrescu è uscito prima (e in qualche modo è precursore) dello standard C++11, per cui alcune cose sono state inserite in tale standard.
Una di queste sono proprio i function objects parametrici che prendono il nome di function.
Tornando alla tua domanda:

mi chiedevo dato che esistono le tuple nel tr1 , fosse possibile utilizzare in qualche modo quelle.
è possibile specializzare un template che accetta delle tuple in base ai tipi della tuple?

la questione è marginale. Usando delle tuple sposti solo il problema dagli N parametri che prende il function objects a 1 parametro (la tupla) che prende N parametri. Per cui alla fine non risolvi niente.

il fatto è che queste typelist sono spesso comode , ma hanno un implementazione incasinata.

Se non hai esigenze davvero particolari (tipo risolvere un bug dell'implementazione di VC++2010 di std::function o capire cosa succede davvero dietro le quinte, che è sempre molto istruttivo): si, l'implementazione è incasinata.

voi mi consigliereste di utilizzarle? o di farne a meno?

Usa std::function (o std::tr1::function se pre VC++2010); come detto prima, sviluppa e amplia la Loki di Alexandrescu.
Però tieni presente che al massimo accetta 10 argomenti (tipo di ritorno escluso).

[giuseppe500]

grazie.

[giuseppe500]

solo un altra cosa:
è comodo inserire i command(per es della gof) in una coda per via di creare un meccanismo di undo , magari accoppiato ad un memento e a una funzone undo(), oppure per creare dei macrocomandi.

E possibile inserire dei std::function anche di diversi parametri in un container?
come va definito questo container sempre se è possibile.

grazie.

[shodan]

Originariamente inviato da giuseppe500
E possibile inserire dei std::function anche di diversi parametri in un container?
come va definito questo container sempre se è possibile.

Non direttamente, ma puoi usare std::bind per uniformare il tipo di funzione.

void test() {
    cout << "test" << endl;
}

void mytest(int i) {
    cout << i << endl;
}

int main(int argc, char* argv[]) {
    array<function<void()>,2> v;
    v[0] = test;
    v[1] = bind(mytest,4);
    v[0]();
    v[1]();
}

[giuseppe500]

ciao,
una cosa : è possibile fare la stessa cosa anche con tipi di ritorno differenti delle funzioni?
mi piacerebbe creare una collezione eterogenea di std::function sia come parametri(e mi sono documentato sul bind , e ho capito) sia (ma mi sembra un po impossibile) sui tipi di ritorno delle funzioni attorno a cui sta std::function.

ho cercato su google ma purtroppo non ho trovato molta documentazione.
è una ricerca vana per qualche motivo?

grazie.

[shodan]

Originariamente inviato da giuseppe500
è possibile fare la stessa cosa anche con tipi di ritorno differenti delle funzioni?

No, non direttamente almeno.
Però puoi usare un oggetto proxy come tipo di ritorno che si comporti in maniera diversa in base al contesto di chiamata e al tipo reale che intendi ritornare.
Esempio qui:
http://www.eptacom.net/pubblicazioni/pub_it/nl_7.html

[giuseppe500]

grazie 1000

[giuseppe500]

ciao.
Cio che viene fatto col metodo del proxy e dell' overload è quello che mi serve ,
ti volevo chiedere se l'overloading come le funzioni virtual riducono il tempo di accesso ai dati,le funzioni virtuali per via della virtual table,
l'overloading non lo so.
quello che vorrei fare , ho scritto un post ma non si capiva niente
è generalizzare i dati(da qui questa domanda) e le funzioni(da tua risposta su questa post sull array di std::function)
e permettere in questo modo una combinazione per mezzo dei template con le policy di queste due entità, rendendo un po trasparente a chi lo usa
e focalizando il tutto sulla coppia dati(risorsa) / function (che trasformano una risorsa parametrizzata in un altra risorsa per mezzo dei std::function).
Inoltre dividendo i dati dalle funzioni potrei semplificare la gestione di librerie come tbb e le sue classi task.
progettando meglio la concorrenza,se le risorse (i dati parametrizzati) ad es se servono ad una sola entità posso incapsularle in questa
entità e essere sicuro che non abbiano accessi in scrittura da altre entità rendendole "sicure".

per precisare

mi chiedevo quando ho fatto la domanda come facesse per es. php a rendere il tipo delle variabili generico.
pero' ho provato a leggere i sorgenti di php ma non c'ho capito molto, forse perchè non ho una grade esperienza, ma mi
sa che sia legato al fatto che php è un linguaggio interpretato , non nativo , come il c++ quindi non ho chiesto niente su quest argomento


ciao.

[shodan]

Originariamente inviato da giuseppe500
ti volevo chiedere se l'overloading come le funzioni virtual riducono il tempo di accesso ai dati,le funzioni virtuali per via della virtual table,

Nella teoria si, ma nella pratica no. Per poter misurare un eventuale ritardo dovresti mettere il loop la chiamata alla funzione virtuale di almeno 10^6 volte, per misurare magari 1ms di ritardo. Per una singola chiamata avresti 1ps (10^-12) e magari alla fine scopri che il collo di bottiglia è in un algoritmo sbagliato.
Per come la vedo nemmeno mi pongo il problema.

l'overloading non lo so.

Il compilatore può decorare il nome della funzione in modo da avere nomi univoci e si ricade nella chiamata univoca.
Es.

// il programmatore la vede così:
int pippo();
int pippo(int);

// il compilatore può vederla così:

int pippo();
int pippo_int(int);

è generalizzare i dati(da qui questa domanda) e le funzioni(da tua risposta su questa post sull array di std::function)
e permettere in questo modo una combinazione per mezzo dei template con le policy di queste due entità, rendendo un po trasparente a chi lo usa
e focalizando il tutto sulla coppia dati(risorsa) / function (che trasformano una risorsa parametrizzata in un altra risorsa per mezzo dei std::function).

Scusa, ma proprio non ho capito. Protresti chiarire con un esempio alla buona?

Inoltre dividendo i dati dalle funzioni potrei semplificare la gestione di librerie come tbb e le sue classi task.

Ma se passi i dati alle funzioni, essi sono già divisi. Anche qui: che intendi?

mi chiedevo quando ho fatto la domanda come facesse per es. php a rendere il tipo delle variabili generico.

Quindi ti serve solo un tipo variant?

pero' ho provato a leggere i sorgenti di php ma non c'ho capito molto, forse perchè non ho una grade esperienza,

Più probabile che siano i sorgenti un po' incasinati.

ma mi sa che sia legato al fatto che php è un linguaggio interpretato , non nativo , come il c++ quindi non ho chiesto niente su quest argomento

Lo static type checking non ha niente a che vedere col fatto se un linguaggio è interpretato o compilato: è solo una scelta progettuale. Nulla vieta in futuro che possa esistere un Php2 (fatto meglio di quello attuale) che sia interpretato e con lo static type checking.