Ottimizzare C++/Ottimizzazione del codice C++/Numero di istruzioni: differenze tra le versioni

Supponi che stai scrivendo la seguente funzione di libreria, in cui sia <code>x</code> che <code>y</code> non hanno un valore definito in fase di sviluppo della libreria:

 

int f1(int x, int y) { return x * y; }

 

Tale funzione può essere chiamata dal seguente codice applicativo, nel quale <code>x</code> non ha un valore costante, ma <code>y</code> è la costante 4:

 

int a = f1(b, 4);

 

Se, mentre scrivi la libreria, sai che il chiamante ti passerà sicuramente una costante intera come argomento <code>y</code>, puoi trasformare la tua funzione nel seguente template di funzione:

 

template <int Y> int f2(int x) { return x * Y; }

 

Tale funzione può essere chiamata dal seguente codice applicativo:

 

int a = f2<4>(b);

 

Tale chiamata istanzia automaticamente la seguente funzione:

 

int f2(int x) { return x * 4; }

 

Quest'ultima funzione è più veloce della precedente funzione <code>f1</code>, per i seguenti motivi:

Supponi che stai scrivendo la seguente classe base di libreria:

 

class Base {

public:

virtual void f() = 0;

};

 

In questa classe, la funzione <code>g</code> esegue un algoritmo che chiama la funzione <code>f</code> come operazione astratta per l'algoritmo.

Lo scopo di questa classe è consentire di scrivere il seguente codice applicativo:

 

class Derivata1: public Base {

private:

Base* p1 = new Derivata1;

p1->g();

 

In tal caso, è possibile convertire il precedente codice di libreria nel seguente:

 

template <class Derivata> class Base {

public:

void f() { static_cast<Derivata*>(this)->f(); }

};

 

Il codice applicativo, di conseguenza, diventerà il seguente:

 

class Derivata1: public Base<Derivata1> {

public:

Derivata1* p1 = new Derivata1;

p1->g();

 

In tal modo, si ha binding statico alla funzione membro <code>Derivata1::f</code> della chiamata a <code>f</code> fatta all'interno della funzione membro <code>Base<Derivata1>::g</code>, cioè la chiamata a tale funzione non è più di tipo <code>virtual</code>, e può essere espansa ''inline''.

Tuttavia, supponiamo che si volesse aggiungere la seguente definizione:

 

class Derivata2: public Base<Derivata2> {

public:

void f() { ... }

};

 

Con questa soluzione non sarebbe più possibile definire un puntatore o riferimento a una classe base comune sia a <code>Derivata1</code> che a <code>Derivata2</code>, in quanto tali classi risultano due tipi senza alcuna relazione; di conseguenza, questa soluzione non è applicabile se si vuole permettere al codice applicativo di definire un contenitore di oggetti arbitrari derivati dalla classe Base.

Supponi che stai scrivendo il seguente codice di libreria, che implementa il design pattern ''Strategy'':

 

class C;

class Strategy {

Strategy s_;

};

 

Questo codice di libreria ha lo scopo di consentire il seguente codice applicativo:

 

class MyStrategy: public Strategy {

public:

c.set_strategy(s); // Assegnazione della strategia personalizzata.

c.f(); // Esecuzione dell'algoritmo con la strategia assegnata.

 

In tal caso, è possibile convertire il precedente codice di libreria nel seguente:

 

template <class Strategy>

class C {

}

};

 

Il codice applicativo, di conseguenza, diventerà il seguente:

 

class MyStrategy {

public:

C<MyStrategy> c; // Oggetto con strategia assegnata staticamente.

c.f(); // Esecuzione con strategia assegnata staticamente.

 

In tal modo, si evita l'oggetto-strategia, e si ha il binding statico delle funzioni membro <code>MyStrategy::is_valid</code> e <code>MyStrategy::run</code>, cioè si evitano chiamate a funzioni <code>virtual</code>.