KDE TechBase - User contributions [en]

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2009-04-07T20:11:17Z

Fresbeeplayer: Fix delayed initialization link

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser_(it)|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QList<QualcheClasse> container;

// codice che inserisce un grande numero di elementi nel container

QList<QualcheClasse>::ConstIterator end = container.constEnd();
QList<QualcheClasse>::ConstIterator itr = container.constBegin();

for ( ; itr != end; ++itr ) {
// usa *itr (oppure itr.value()) qui dentro
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Ogni volta che usi gli iteratori, utilizza sempre operatori di pre-incremento e pre-decremento (ad esempio, <tt>++itr</tt>) a meno di avere uno motivo specifico per non farlo. L'utilizzo di operatori di post-incrementi e post-decrementi (come <tt>itr++</tt>) causano la creazione di un oggetto temporaneo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code>

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passaggio di tipi non POD ===

I tipi di dato diversi da POD ([http://en.wikipedia.org/wiki/Plain_old_data "Plain Old Data"], dati semplici senza la logica di controllo) dovrebbero essere passati sempre per riferimento costante. Questo include qualunque cosa tranne i tipi base come <tt>char</tt> e <tt>int</tt>.

Prendi, per esempio, {{qt|QString}}. Dovrebbero sempre essere passati ai metodi come <tt>const {{qt|QString}}&</tt>. Anche se {{qt|QString}} è implicitamente condiviso è comunque più efficiente (e sicuro) passarlo per referenza costante piuttosto che come oggetto per valore.

Quindi la dichiarazione canonica di un metodo che prende QString come argomento è:

<code cppqt>
void mioMetodo( const QString & x, const QString & y );
</code>

=== QObject ===

Se avrai mai bisogno di eliminare una classe derivata da QObject dall'interno di uno dei suoi metodi, non farlo mai in questo modo:

<code cppqt>
delete this;
</code>

Prima o poi ciò causerà un crash perché un metodo di quell'oggetto potrebbe essere invocato dal ciclo eventi delle Qt via slots/signals dopo che tu l'hai eliminato.

Invece usa sempre <tt>{{QtMethod|QObject|deleteLater}}</tt> il quale cerca di fare la stessa cosa di <tt>delete this</tt> ma in modo più sicuro.

=== QStrings vuote ===

Si è soliti voler verificare se un {{qt|QString}} è vuoto. Di seguito ci sono tre modi per farlo, dei quali i primi due sono corretti:

<code cppqt>
// Corretto
if ( miaStringa.isEmpty() ) {
}

// Corretto
if ( miaStringa == QString() ) {
}

// Sbagliato! ""
if ( miaStringa == "" ) {
}
</code>

Mentre c'è distinzione tra {{qt|QString}} nulle e vuote, ciò è puramente un artefatto storico e per il nuovo codice se ne scoraggia l'uso.

=== QString e lettura da file ===

Se stai leggendo un file, è più veloce convertirlo dalla codifica locale a Unicode ({{qt|QString}}) tutto in una volta, piuttosto che riga per riga. Questo vuol dire che metodi come <tt>{{qt|QIODevice}}::readAll()</tt> sono spesso una buona soluzione, seguiti da una singola istanza di {{qt|QString}}.

Per file molto grandi, considera la possibilità di leggere un blocco di righe e quindi eseguire la conversione. In questo modo hai l'opportunità di aggiornare la GUI. Ciò può essere fatto rientrando normalmente nel ciclo eventi, contemporaneamente utilizzando un timer per leggere i blocchi in background, oppure creando un ciclo eventi locale.

Anche se si potrebbe usare anche <tt>qApp->processEvents()</tt>, è scoraggiato siccome porta facilmente a subdoli problemi fatali.

=== Leggere QString da un KProcess ===

{{class|KProcess}} emette il segnale <tt>readyReadStandard{Output|Error}</tt> appena arrivano dei dati.
Un errore comune sta nel leggere tutti i dati disponibili nello slot connesso e convertirli in un {{qt|QString}} così come sono: i dati arrivano arbitrariamente segmentati, così caratteri multi-byte potrebbero essere tagliati in pezzi e perciò invalidati. Esistono molti approcci al problema:

* Hai veramente bisogno di processare i dati che arrivano? Se no, basta utilizzare <tt>readAllStandard{Output|Error}</tt> dopo che il processo è uscito. Diversamente da KDE3, KProcess è ora capace di accumulare i dati per te.
* Racchiudi il processo in un {{qt|QTextStream}} e leggi intere righe. Questo dovrebbe funzionare a partire dalle Qt 4.4
* Accumula i pezzi di dati negli slots e processali ogni volta che arriva una riga e dopo un certo timeout. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Codice di esempio]

=== QString e QByteArray ===

Mentre {{qt|QString}} è lo strumento scelto per molte situazioni che richiedono la gestione di stringhe, ce n'è una dove è particolarmente inefficiente. Se stai lavorando con dati in un {{qt|QByteArray}}, fai attenzione a non passarlo a metodi che prendono parametri di tipo {{qt|QString}}, e che ne tirano fuori un QByteArrays di nuovo.

Per esempio:

<code cppqt>
QByteArray mieiDati;
QString mieiNuoviDati = maciullaDati( mieiDati );

QString maciullaDati( const QString& dati ) {
QByteArray str = dati.toLatin1();
// maciulla
return QString(str);
}
</code>

L'operazione dispendiosa che si verifica è la conversione in {{qt|QString}}, la quale internamente fa conversioni a Unicode. Ciò è inutile perché la prima cosa che il metodo fa è riconvertirla di nuovo con <tt>toLatin1()</tt>. Quindi, se sei sicuro che la conversione a Unicode non è necessaria, cerca di evitare di usare inavvertitamente QString.

L'esempio di cui sopra dovrebbe invece essere scritto come:

<code cppqt>
QByteArray mieiDati;
QByteArray mieiNuoviDati = maciullaDati( mieiDati );

QByteArray maciullaDati( const QByteArray& dati )
</code>

=== QDomElement ===

Quando si deve fare il paring di documenti XML, si ha bisogno di iterare su tutti gli elementi. Potresti essere tentato di usare il seguente codice:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

Ebbene non è corretto: questo ciclo si fermerà prematuramente non appena incontra un {{qt|QDomNode}} che è qualcosa di diverso da un elemento, come un commento.

Il ciclo corretto è qualcosa di simile:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-12-10T16:42:55Z

Fresbeeplayer: sincronizzazione con il testo inglese

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser_(it)|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QList<QualcheClasse> container;

// codice che inserisce un grande numero di elementi nel container

QList<QualcheClasse>::ConstIterator end = container.constEnd();
QList<QualcheClasse>::ConstIterator itr = container.constBegin();

for ( ; itr != end; ++itr ) {
// usa *itr (oppure itr.value()) qui dentro
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Ogni volta che usi gli iteratori, utilizza sempre operatori di pre-incremento e pre-decremento (ad esempio, <tt>++itr</tt>) a meno di avere uno motivo specifico per non farlo. L'utilizzo di operatori di post-incrementi e post-decrementi (come <tt>itr++</tt>) causano la creazione di un oggetto temporaneo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code>

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/view/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passaggio di tipi non POD ===

I tipi di dato diversi da POD ([http://en.wikipedia.org/wiki/Plain_old_data "Plain Old Data"], dati semplici senza la logica di controllo) dovrebbero essere passati sempre per riferimento costante. Questo include qualunque cosa tranne i tipi base come <tt>char</tt> e <tt>int</tt>.

Prendi, per esempio, {{qt|QString}}. Dovrebbero sempre essere passati ai metodi come <tt>const {{qt|QString}}&</tt>. Anche se {{qt|QString}} è implicitamente condiviso è comunque più efficiente (e sicuro) passarlo per referenza costante piuttosto che come oggetto per valore.

Quindi la dichiarazione canonica di un metodo che prende QString come argomento è:

<code cppqt>
void mioMetodo( const QString & x, const QString & y );
</code>

=== QObject ===

Se avrai mai bisogno di eliminare una classe derivata da QObject dall'interno di uno dei suoi metodi, non farlo mai in questo modo:

<code cppqt>
delete this;
</code>

Prima o poi ciò causerà un crash perché un metodo di quell'oggetto potrebbe essere invocato dal ciclo eventi delle Qt via slots/signals dopo che tu l'hai eliminato.

Invece usa sempre <tt>{{QtMethod|QObject|deleteLater}}</tt> il quale cerca di fare la stessa cosa di <tt>delete this</tt> ma in modo più sicuro.

=== QStrings vuote ===

Si è soliti voler verificare se un {{qt|QString}} è vuoto. Di seguito ci sono tre modi per farlo, dei quali i primi due sono corretti:

<code cppqt>
// Corretto
if ( miaStringa.isEmpty() ) {
}

// Corretto
if ( miaStringa == QString() ) {
}

// Sbagliato! ""
if ( miaStringa == "" ) {
}
</code>

Mentre c'è distinzione tra {{qt|QString}} nulle e vuote, ciò è puramente un artefatto storico e per il nuovo codice se ne scoraggia l'uso.

=== QString e lettura da file ===

Se stai leggendo un file, è più veloce convertirlo dalla codifica locale a Unicode ({{qt|QString}}) tutto in una volta, piuttosto che riga per riga. Questo vuol dire che metodi come <tt>{{qt|QIODevice}}::readAll()</tt> sono spesso una buona soluzione, seguiti da una singola istanza di {{qt|QString}}.

Per file molto grandi, considera la possibilità di leggere un blocco di righe e quindi eseguire la conversione. In questo modo hai l'opportunità di aggiornare la GUI. Ciò può essere fatto rientrando normalmente nel ciclo eventi, contemporaneamente utilizzando un timer per leggere i blocchi in background, oppure creando un ciclo eventi locale.

Anche se si potrebbe usare anche <tt>qApp->processEvents()</tt>, è scoraggiato siccome porta facilmente a subdoli problemi fatali.

=== Leggere QString da un KProcess ===

{{class|KProcess}} emette il segnale <tt>readyReadStandard{Output|Error}</tt> appena arrivano dei dati.
Un errore comune sta nel leggere tutti i dati disponibili nello slot connesso e convertirli in un {{qt|QString}} così come sono: i dati arrivano arbitrariamente segmentati, così caratteri multi-byte potrebbero essere tagliati in pezzi e perciò invalidati. Esistono molti approcci al problema:

* Hai veramente bisogno di processare i dati che arrivano? Se no, basta utilizzare <tt>readAllStandard{Output|Error}</tt> dopo che il processo è uscito. Diversamente da KDE3, KProcess è ora capace di accumulare i dati per te.
* Racchiudi il processo in un {{qt|QTextStream}} e leggi intere righe. Questo dovrebbe funzionare a partire dalle Qt 4.4
* Accumula i pezzi di dati negli slots e processali ogni volta che arriva una riga e dopo un certo timeout. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Codice di esempio]

=== QString e QByteArray ===

Mentre {{qt|QString}} è lo strumento scelto per molte situazioni che richiedono la gestione di stringhe, ce n'è una dove è particolarmente inefficiente. Se stai lavorando con dati in un {{qt|QByteArray}}, fai attenzione a non passarlo a metodi che prendono parametri di tipo {{qt|QString}}, e che ne tirano fuori un QByteArrays di nuovo.

Per esempio:

<code cppqt>
QByteArray mieiDati;
QString mieiNuoviDati = maciullaDati( mieiDati );

QString maciullaDati( const QString& dati ) {
QByteArray str = dati.toLatin1();
// maciulla
return QString(str);
}
</code>

L'operazione dispendiosa che si verifica è la conversione in {{qt|QString}}, la quale internamente fa conversioni a Unicode. Ciò è inutile perché la prima cosa che il metodo fa è riconvertirla di nuovo con <tt>toLatin1()</tt>. Quindi, se sei sicuro che la conversione a Unicode non è necessaria, cerca di evitare di usare inavvertitamente QString.

L'esempio di cui sopra dovrebbe invece essere scritto come:

<code cppqt>
QByteArray mieiDati;
QByteArray mieiNuoviDati = maciullaDati( mieiDati );

QByteArray maciullaDati( const QByteArray& dati )
</code>

=== QDomElement ===

Quando si deve fare il paring di documenti XML, si ha bisogno di iterare su tutti gli elementi. Potresti essere tentato di usare il seguente codice:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

Ebbene non è corretto: questo ciclo si fermerà prematuramente non appena incontra un {{qt|QDomNode}} che è qualcosa di diverso da un elemento, come un commento.

Il ciclo corretto è qualcosa di simile:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

Development/Tutorials/First program (it)

2008-12-05T23:37:07Z

Fresbeeplayer: sostituito app.exec() con 0 per far chiudere correttamente l'app

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow_(it)|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

== Prefazione ==

Il tuo primo programma dovrebbe salutare il mondo con un amichevole "Ciao Mondo", giusto? Per farlo, useremo un {{class|KMessageBox}} personalizzando uno dei pulsanti.

[[image:Ciaomondo_tutorial1.png|frame|center]]

{{tip|Per avere più informazioni su qualunque classe che incontri, Konqueror offre una veloce scorciatoia. Per cercare informazioni circa KMessageBox, basta digitare "kde:kmessagebox" in Konqueror e sarai portato alla documentazione.}}

{{tip|Vorresti poter usare KDevelop per i tuoi progetti, il quale fa molte cose carine come il completamento del codice, facile accesso alla documentazione delle API, supporto per il debugging.
Leggi [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|questo tutorial]] per configurare KDevelop correttamente. Puoi controllare se il setup è andato a buon fine aprendo un'applicazione KDE4 esistente con KDevelop.
Tuttavia hai ancora bisogno di editare a mano i files di CMake.}}

== Il Codice ==

Tutto il codice di cui abbiamo bisogno starà in un file, <tt>main.cpp</tt>. Crealo con il codice qua sotto:

<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>
#include <QByteArray>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// Il nome del programma, usato internamente.
"tutorial1",
// Il nome nel catalogo messaggi.
// Se nullo, verrà usato il nome del programma.
0,
// Una stringa con il nome del programma.
// Quella che verrà effettivamente visualizzata.
ki18n("Tutorial 1"),
// La stringa con la versione del programma.
"1.0",
// Piccola descrizione su cosa fa il programma.
ki18n("Visualizza una finestra KMessageBox."),
// La licenza con la quale il codice è rilasciato.
KAboutData::License_GPL,
// Copyright
ki18n("(c) 2007"),
// Testo opzionale mostrato in "Informazioni su".
// Può contenere qualunque informazione desiderata.
ki18n("Un po' di testo..."),
// La stringa con la homepage del programma.
QByteArray("http://tutorial.com/"),
// L'indirizzo email per la segnalazione di bug.
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Ciao" ), QString(),
i18n( "Questo è un tooltip" ),
i18n( "Questo è un testo di aiuto CheCos'è?." ) );
KMessageBox::questionYesNo( 0, i18n( "Ciao Mondo" ),
i18n( "Ciao" ), yesButton );
return 0;
}
</code>

Il primo codice specifico di KDE che incontriamo in questo programma è {{class|KAboutData}}. Questa è la classe utilizzata per immagazzinare le informazioni sul programma, come ad esempio una piccola descrizione, gli autori, o le informazioni sulla licenza. Praticamente ogni applicazione KDE dovrebbe usare questa classe.

Poi arriviamo a {{class|KCmdLineArgs}}. Questa è la classe che si usa quando si vogliono specificare istruzioni da riga di comando per, ad esempio, aprire il programma con uno specifico file. Comunque, in questo tutorial, semplicemente lo inizializziamo con l'oggetto {{class|KAboutData}} che abbiamo appena creato, in modo da poter usare le opzioni <tt>--version</tt> o <tt>--author</tt>

Quindi adiamo a creare l'oggetto {{class|KApplication}}. Ciò bisogna farlo esattamente una volta in ogni programma, visto che è necessario per cose come l'[[Development/Tutorials/Localization/i18n|i18n]].

Ora che abbiamo finito con le operazioni indispensabili di KDE, possiamo cominciare a fare cose interessanti con la nostra applicazione. Creeremo una finestra pop-up, ma personalizzeremo uno dei pulsanti. Per la personalizzazione avremo bisogno di un oggetto {{class|KGuiItem}}. Il primo argomento del costruttore di {{class|KGuiItem}} è il testo che apparirà sull'oggetto (nel nostro caso, un pulsante). Quindi ci sarà un opzione per inserire un'icona, ma non ne vogliamo una così gli mettiamo <tt>QString</tt>. Impostiamo quindi il tooltip (quello che appare quando fermi il puntatore su un elemento) ed infine il testo "Che Cos'è?" (accessibile tramite click col tasto destro, con Shift-F1 oppure cliccando su "?" nella barra del titolo e poi sul pulsante "Ciao").

Ora che abbiamo il nostro pulsante, possiamo creare il nostro pop-up. Chiamiamo la funzione <tt>{{class|KMessageBox}}::questionYesNo()</tt> la quale, in modo predefinito, crea una finestra con due pulsanti "Si" e "No". Il secondo argomento compone il testo mostrato nella finestra sopra i due pulsanti. Il terzo è l'intestazione della finestra; e infine impostiamo il KGuiItem di (quello che normalmente è) il pulsante "Si" con il nostro <tt>KGuiItem yesButton</tt> appena creato.

Notare come tutto il testo visibile all'utente passa attraverso la funzione i18n(); questo è necessario per permettere la traduzione della UI. Più informazioni sulla localizzazione possono essere trovate nel [[Development/Tutorials/Localization/i18n|tutorial sulla localizzazione]].

Abbiamo finito per quanto riguarda il codice. Ora la compilazione e la prova.

== Compilazione ==

Vorrai usare [[Development/Tutorials/CMake|CMake]] come ambiente di compilazione. Devi fornire un file chiamato CMakeLists.txt, cmake usa questo file per generare tutti i Makefiles.

=== CMakeLists.txt ===

Crea un file di nome CMakeLists.txt nella stessa cartella di main.cpp con questo contenuto:

<code ini n>
project (tutorial1)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial1_SRCS
main.cpp
)

kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

La funzione <tt>find_package()</tt> trova tutti i pacchetti che hai richiesto (in questo caso KDE4) ed imposta alcune variabili che descrivono la posizione degli header e delle librerie del pacchetto. In questo caso useremo la variabile <tt>KDE4_INCLUDES</tt> contenente il percorso ai files header di KDE4.

Per permettere al compilatore di trovare questi files, passiamo quella variabile alla funzione <tt>include_directories()</tt> la quale aggiunge gli header di KDE4 al percorso di ricerca degli header.

Poi creiamo una variabile chiamata <tt>tutorial1_SRCS</tt> con la funzione <tt>set()</tt>. In questo caso la impostiamo con il nome del nostro unico file sorgente.

Quindi usiamo <tt>kde4_add_executable()</tt> per creare un eseguibile chiamato <tt>tutorial1</tt> dai sorgenti elencati nella nostra variabile <tt>tutorial1_SRCS</tt>. In seguito, facciamo il link del nostro eseguibile alle librerie kdeui di KDE4 con <tt>target_link_libraries()</tt> e la variabile <tt>KDE4_KDEUI_LIBS</tt> precedentemente riempita dalla funzione <tt>find_package()</tt>. La riga che comincia con <tt>install</tt> scrive un target di default "install" dentro al Makefile.

=== Make ed Esecuzione ===

Puoi invocare CMake e make manualmente:

mkdir build && cd build
cmake .. # Nota questi due punti - non è una mancanza,
# stanno per "cartella superiore".
make

Oppure, se hai preparato il tuo ambiente come descritto in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], puoi compilare questo codice con:
cmakekde

Quindi lancialo con:
./tutorial1

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KXmlGuiWindow|usare KXmlGuiWindow]].

[[Category:C++]]

Development (it)

2008-12-01T14:57:34Z

Fresbeeplayer:

__NOEDITSECTION__ __NOTOC__ {{Template:I18n/Language Navigation Bar|Development}}
{| style="margin: 1em 2.5% 0 2.5%; padding: 0 5px;" cellpadding="5"
|-
|colspan=2|[[Image:Discover.png|noframe]]
|-
| style="padding-left: 50px;" |[[Image:Action_launch.svg|noframe|left|40px]] ||
;[[Development/Architecture_(it)|Architettura KDE]]
:Documenti sul design architetturale che spiegano le tecnologie alla base di KDE.
:''Riferimento'': [http://api.kde.org Documentazione API]
|-
| style="padding-left: 50px;"|[[Image:Action_configure.svg|noframe|left|40px]] ||
;[[Development/Tutorials_(it)|Tutorials di programmazione]]
:Tutorials passo passo per lo sviluppo di KDE.
:''Riferimento:'' [[Development/Tools|Strumenti di sviluppo]] | [[Development/FAQs|FAQs]]
|-
| style="padding-left: 50px;"|[[Image:Action_rebuild.svg|noframe|left|40px]] ||
;[[Development/Languages|Bindings ai linguaggi]]
:Linguaggi di programmazione supportati.
|-
| style="padding-left: 50px;"|[[Image:CMake-logo-48.png|noframe|left|48px]] ||
;[[Development/CMake|CMake]]
:Informazioni su CMake.
|-
| style="padding-left: 50px;" |[[Image:Action_note.svg|noframe|left|40px]] ||
;[[Development/Guidelines|Linee Guida & Standards]]
:Linee guida allo sviluppo e uso di tecniche standard per KDE.
:''Riferimento:'' [[Development/Further Information|Ulteriori informazioni]] (links, books, blogs, etc.)
|-
| style="padding-left: 50px;" |[[Image:Action_tool.svg|noframe|left|40px]] ||
;[[Development/Software Engineering Framework|Framework Ingegneria del Software]]
:Strumenti e processi di Ingegneria del Software usati da KDE.
|}

Development (it)

2008-12-01T14:34:15Z

Fresbeeplayer: aggiunte due sezioni (cmake e ing software)

__NOEDITSECTION__ __NOTOC__ {{Template:I18n/Language Navigation Bar|Development}}
{| style="margin: 1em 2.5% 0 2.5%; padding: 0 5px;" cellpadding="5"
|-
|colspan=2|[[Image:Discover.png|noframe]]
|-
| style="padding-left: 50px;" |[[Image:Action_launch.svg|noframe|left|40px]] ||
;[[Development/Architecture|Architettura KDE]]
:Documenti sul design architetturale che spiegano le tecnologie alla base di KDE.
:''Riferimento'': [http://api.kde.org Documentazione API]
|-
| style="padding-left: 50px;"|[[Image:Action_configure.svg|noframe|left|40px]] ||
;[[Development/Tutorials|Tutorials di programmazione]]
:Tutorials passo passo per lo sviluppo di KDE.
:''Riferimento:'' [[Development/Tools|Strumenti di sviluppo]] | [[Development/FAQs|FAQs]]
|-
| style="padding-left: 50px;"|[[Image:Action_rebuild.svg|noframe|left|40px]] ||
;[[Development/Languages|Bindings ai linguaggi]]
:Linguaggi di programmazione supportati.
|-
| style="padding-left: 50px;"|[[Image:CMake-logo-48.png|noframe|left|48px]] ||
;[[Development/CMake|CMake]]
:Informazioni su CMake.
|-
| style="padding-left: 50px;" |[[Image:Action_note.svg|noframe|left|40px]] ||
;[[Development/Guidelines|Linee Guida & Standards]]
:Linee guida allo sviluppo e uso di tecniche standard per KDE.
:''Riferimento:'' [[Development/Further Information|Ulteriori informazioni]] (links, books, blogs, etc.)
|-
| style="padding-left: 50px;" |[[Image:Action_tool.svg|noframe|left|40px]] ||
;[[Development/Software Engineering Framework|Framework Ingegneria del Software]]
:Strumenti e processi di Ingegneria del Software usati da KDE.
|}

Development/Tutorials (it)

2008-11-29T12:05:51Z

Fresbeeplayer: primi due tutorial in itailano

{{Template:I18n/Language Navigation Bar|Development/Tutorials}}

I Tutorials sono la via piu' veloce di comprendere cosa KDE fa per te, e come lo fa.
Qui c'e' una lista dei tutorial disponibilie ''per KDE4''. Materiale per KDE3 e KDE2 e' disponibile in fondo alla pagina.

== Introduzione alla programmazione di KDE 4 ==

Sei interessato a scrivere applicazioni con KDE 4? Questa serie di tutorial e' mirata a questo completamente nuovo modo di programmare KDE.

;[[Development/Tutorials/First program (it)|Hello World]]
:''Un'introduzione preliminare alle basi della programmazione KDE4''

;[[Development/Tutorials/Using KXmlGuiWindow (it)|Creazione della finestra principale (Main Window)]]
:''Questo tutorial ti mostra la magia di un aspetto molto importante di un'applicazione: La finestra principale (main window).''

;[[Development/Tutorials/Using KActions|Usare le KActions]]
:''Come aggiungere eventi ai menu e alle toolbar.''

;[[Development/Tutorials/Saving and loading|Salvataggio e Caricamento]]
:''Introduzione alla libreria KIO per il supporto al caricamento e salvataggio da una propria applicazione.''

;[[Development/Tutorials/KCmdLineArgs|Argomenti della linea di comando]]
:''Aggiungere la capacita' di specificare quale file aprire dalla riga di comando nel proprio editor di testo.''

== Basi ==
;[[Development/Tutorials/KDE4 Porting Guide|Effettuare il porting delle tue applicazioni]]
:''Aiuto per il porting di applicazioni da Qt3/KDE3 a Qt4/KDE4''

;[[Development/Tutorials/CMake|Introduzione a CMake]]
:''Come usare il sistema di build CMake usato da KDE 4.''

;[[Development/Tutorials/Common Programming Mistakes|Errori di Programmazione Comuni]]
:''Svariati errori comuni fatti durante lo sviluppo di Qt e KDE e come neutralizzarli.''

;[[Development/Tutorials/Using Qt Designer|Usare il Qt Designer per costruire interfacce utente]]
:''Come creare file UI con il designer, e come integrarli in un programma KDE.''

;[[Development/Tutorials/Creating Libraries|Creare librerie per condividere il codice]]
:''Come aggiungere una libreria al sistema di build e come predisporre il codice sorgente.''

== Testing e Debugging ==

;[[Development/Tutorials/Debugging|Debugging delle tue applicazioni]]
:''Suggerimenti, strumenti e tecniche da applicare quando si esegue il debug delle proprie applicazioni KDE''

;[[Development/Tutorials/Unittests|Scrivere Unittests per Qt4 e KDE4 con QTestLib]] ([http://developer.kde.org/documentation/tutorials/writingunittests/writingunittests.html Link originale])
:''Tutorial da [mailto:bradh@frogmouth.net Brad Hards] che descrive come scrivere unit test usando il framework QTestLib. E' mostrato come un tutorial basato su esempi, ed e' in fase di sviluppo.''

;[[Development/Tutorials/Code_Checking|Vie Semi-automatiche per rilevare errori nel codice]]
:''Tecniche che si possono usare per rilevare errori nel codice di KDE''

== Gestire i dati di configurazione con KConfig ==
;[[Development/Tutorials/KConfig|Introduzione a KConfig]]
:''Una visione d'insieme delle classi di KConfig e come usarle nelle tue applicazioni''

;[[Development/Tutorials/Using KConfig XT|Usare KConfig XT]]
:''Tutorial su come usare efficientemente il framework KConfig XT.''

;[[Development/Tutorials/Updating KConfig Files|Aggiornare i file di KConfig]]
:''Tutorial su come scrivere uno script di aggiornamento per mantenere i cambiamenti nel formato dei file delle tue applicazioni in sincronia con i file di configurazione degli utenti gia' esistenti''

== Servizi: Applicazioni e Plugins ==
;[[Development/Tutorials/Services/Introduction|Introduzione al Services Framework]]
:''Una visione d'insieme del services framework in KDE e di cosa fornisce agli sviluppatori. Copre la cache alla configurazione di sistema (SyCoCa), i files sorgente dati e come le informazioni indicizzate possono essere usate.''

;[[Development/Tutorials/Services/Traders|Trovare i servizi tramite le queries di scambio (Trader Queries)]]
:''Come trovare servizi, come plugins o mimetypes, che sono indicizzati nella SyCoCa usando la sintassi delle Trader Queries''

;[[Development/Tutorials/Services/Plugins|Creare e Caricare Plugins Usando KService]]
:''Impara come definire tipi di plugin personalizzati, trovare plugin installati (inclusi plugin di terze parti) e caricarli in una maniera facile e portabile usando KService.''

== Localizzazione ==
;[[Development/Tutorials/Localization/Unicode|Introduzione A Unicode]]
:''Una introduzione su cos'e' Unicode e come manipolare i dati Unicode nelle applicazioni KDE.''

; [[Development/Tutorials/Localization/i18n|Scrivere applicazioni con la localizzazione in mente]]
:''Questo tutorial spiega che cos'e' la localizzazione, perche' e' importante e come assicurarsi che le tue applicazioni sono pronte ad essere localizzate. Un MUST per tutti gli sviluppatori.''

; [[Development/Tutorials/Localization/i18n Mistakes|Evitare i rischi comuni legati alla localizzazione]]
:''Ci sono svariati errori comuni che non consentono alle applicazioni di essere correttamente localizzate. Scopri in questo tutorial quali sono e come prevenirli facilmente.''

; [[Development/Tutorials/Localization/Building KDE's l10n Module|Compilare Moduli di localizzazione di KDE]]
:''Potrebbe essere una buona idea effetture la compilazione ed installazione del supporto alle lingue dal modulo di localizzazione (l10n) di KDE lavorandoci sopra. Questo modo ti permettera' di testare le tue applicazioni in altre lingue ed evidenziare le aree problematiche. Impara come farlo in questo tutorial.''

; [[Development/Tutorials/Localization/i18n Build Systems|Incorporare i18n nel sistema di build]]
:''Una volta che la tua applicazione e' pronta per essere localizzata, il prossimo passo e' di assicurarsi che i files di traduzione siano impacchettati automaticamente e mantenuti aggiornati. Questo tutorial tratta della necessarie aggiunte al CMakeFiles.txt oltre che del processo di distribuzione degli elenchi di messaggi risultanti con le tue applicazioni.''

; [[Development/Tutorials/Localization/i18n Challenges|Common i18n Challenges and Solutions]]
:''Questo tutorial mostra le sfide che potrai eventualmente affrontare traducendo gli handbook o altri dati che esistono al di fuori del codice sorgente, fondendo e maneggiando files .po obsoleti, codifiche in altri linguaggi rispetto all'inglese e la creazione di versioni indipendenti di o muovendo applicazioni tra moduli KDE. -- pessima traduzione ---
This tutorial covers challenges that you may eventually run into such as translating handbooks and other data that exists outside of the source code, merging and handling obsolete .po files, dealing with freezes, coding in languages other than English and creating independent releases of or moving applications between KDE modules.''

; [[Development/Tutorials/Localization/i18n_Semantics|Markup Semantico dei Messaggi]]
:''Per assicurare una presentazione consistente e una rappresentazione maggiormente comprensibile nelle applicazioni, il markup semantico puo' essere applicato per le traduzioni usando il sistema KUIT. Questo tutorial descrive come lavora questo sistema.''

; [[Development/Tutorials/Localization/i18n Krazy|Automated i18n Code Checking]]
:''Il validatore di codice Krazy controlla il codice di KDE e riporta errori comuni sull'i18n.''

== Documentazione ==

;[[Development/Tutorials/API_Documentation|Documentazione alle API]]
:''Questo tutorial spiega come documentare correttamente le tue API.''

;[[Development/Tutorials/Man_Pages|Man Pages]]
:''Scrittura e generazione delle Man Pages di riferimento.''

== Automazione e Scripting delle applicazioni ==

=== D-Bus ===
; [[Development/Tutorials/D-Bus/Introduction|Introduzione a D-Bus]]
:''Una introduzione ai concetti chiave di D-Bus dalla prospettiva dello sviluppatore, questo tutorial mostra cos'e' DBus e come puo' essere usato dalle applicazioni.''
; [[Development/Tutorials/D-Bus/Accessing Interfaces|Accesso alle interfacce di D-Bus]]
:''Una guida passo-passo per chiamare i metodi di D-Bus e connettere i segnali di D-Bus tramite QtDBus.''
; [[Development/Tutorials/D-Bus/Intermediate_D-Bus|D-Bus Intermedio]]
:''Suggerimenti per far uso di QtDBus quando si ha a che fare con interfacce del mondo reale problematiche.''
; [[Development/Tutorials/D-Bus/Creating Interfaces|Creare Interfacce D-Bus]]
:''Impara come esporre funzionalita' nella tua applicazione creando ed usando interfacce D-Bus personalizzate. Tratta la generazione di descrizioni XML, instanziazione di interfacce a runtime e impostazione del sistema di build con CMake.''
; [[Development/Tutorials/D-Bus/Autostart Services|Servizi in autoavvio con D-Bus]]
:''Trasforma la tua applicazione in un servizio in autoavvio di D-Bus con questo tutorial. Questa funzionalita' di D-Bus, anche conosciuta come "D-Bus service activation", assicura che quando la tua applicazione non e' avviata le chiamate fatte verso di essa vengono intradate verso il demone di D-Bus che provvede ad avviare l'applicazione se e quando e' necessario.''
; [[Development/Tutorials/Porting_to_D-Bus|Porting da DCOP a D-Bus]]
: ''Effettua il Port della tua applicazione da DCOP a D-Bus con questa maneggevole guida.''

=== Konqueror ===
; [[Development/Tutorials/Creating Konqueror Service Menus|Creare Menu di servizio su Konqueror]]
:''Questo tutorial ti mostra come creare azioni specifiche per mimetype nel menu contestuale di Konqueror (detto "servicemenu").''

=== Kross ===
; [[Development/Tutorials/Kross/Introduction|Introduzione a Kross]]
:''Una introduzione al Framework per lo Scripting Kross.''

; [[Development/Tutorials/Kross/Hello_World|Hello World]]
:''Una prima applicazione che lavora con codice kross.''

; [[Development/Tutorials/Kross/Call_Functions_in_Kross|Chiamare Funzioni in Kross]]
:''Semplice dimostrazione di chiamate a funzioni di scripting''

; [[Development/Tutorials/Kross/Connecting_Signals_and_slots_in_Kross|Connettere Signals e Slots a Kross]]
:''Semplice dimostrazione per la connessione di oggetti signals con script slots''

; [[Development/Tutorials/Kross/Scripts-as-Plugins|Scripts come Plugins con Kross]]
:''Questo tutorial fornisce una introduzione passo passo su come integrare script come plugin in un'applicazione KDE.''

; [[Development/Tutorials/Kross/Script-Actions|Posizionare comandi da script nei menu della tua applicazione]]
:''Semplice dimostrazinoe su come estendere i menu della tua applicazione per eseguire script.''

=== KOffice ===
; [[Development/Tutorials/KOffice Overview|Panoramica su KOffice]]
:''Questo documento mostra una panoramica sui differenti tipi di plugin di KOffice ed illustra per ognuno lo scopo ed i punti di forza. Se sei nuovizio ai plugin di KOffice, questo e' il punto di partenza.''

; [[Development/Tutorials/Write a Flake Plugin|Creare Plugins per KOffice con Flake]]
:''Questo tutorial mostra come costruire un plugin per le applicazioni di KOffice per consentirti di inglobare contenuto di documenti ODF usando Flake.''

; [[Development/Tutorials/KWord Scripting|KWord Scripting]]
:''Questo tutorial mostra come creare script per KWord con Python, Ruby o JavaScript usando Kross.''

; [[Development/Tutorials/KSpread Scripting|KSpread Scripting]]
:''Questo tutorial mostra come creare script per KSpread con Python, Ruby o JavaScript usando Kross.''

; [[Development/Tutorials/Krita Scripting|Krita Scripting]]
:''Questo tutorial mostra come creare script per Krita con Python, Ruby o JavaScript usando Kross.''

=== SuperKaramba ===
; [[Development/Tutorials/SuperKaramba|SuperKaramba Tutorial]]
:''Questo tutorial fornisce una panoramica di SuperKaramba, file di tema e di scripting con Python, Ruby e JavaScript.''

== Plugins e KParts ==

; [[Development/Tutorials/Writing kontact plugins|Scrivere kontact plugins]]
:''Kontact plugins sono KParts. Questo tutorial descrive come scriverne uno.''

; [[Development/Tutorials/Using KParts|Usare KParts]]
:''Impara come caricare una KPart in una finestra di applicazione.''

== Ricerca e Metadati ==

=== Strigi ===

; [[Development/Tutorials/Writing file analyzers|Scrivere analizzatori di file]]
:''Gli analizzatori di file estraggono dati dai file per mostrarli nelle finestre di dialogo e nel file manager. I dati raccolti in questo modo sono anche usati per la ricerca di files. KDE4 permette l'uso di analizzatori multipli per ogni tipo di file. Questo tutorial descrive come puoi scrivere nuovi analizzatori.''

=== [http://nepomuk.kde.org Nepomuk] ===

; [[Development/Tutorials/Metadata/Nepomuk/Quickstart|Introduzione a Nepomuk]]
:''Come usare le risorse di Nepomuk in modo rapido ed indolore senza troppo chiasso.''

; [[Development/Tutorials/Metadata/Nepomuk/RDFIntroduction|RDF e Ontologie in Nepomuk]]
:''Una introduzione a RDF e all'uso delle ontologie in Nepomuk.''

; [[Development/Tutorials/Metadata/Nepomuk/Resources|Gestire risorse con Nepomuk]]
:''Nepomuk e' la libreria KDE che fornisce un semplice accesso ai metadati del sistema. Impara come rendere la tua applicazione abile alla creazione e lettura di metadati usando Nepomuk.''

; [[Development/Tutorials/Metadata/Nepomuk/ResourceGenerator|Usare il Nepomuk Resource Generator]]
:''Nepomuk include un generatore di risorse con cui creare classi di comodo per la gestione dei metadati.''

; [[Development/Tutorials/Metadata/Nepomuk/NepomukServer|Il Server Nepomuk]]
:''Il Server Nepomuk ospita il repository principale dei dati di Nepomuk e puo' essere acceduto direttamente via l'API Soprano.''

; [[Development/Tutorials/Metadata/Nepomuk/NepomukServices|Nepomuk Services]]
:''Il Server Nepomuk gestisce un set di servizi Nepomuk.''

; [[Development/Tutorials/Metadata/Nepomuk/AdvancedQueries|Queries Avanzate]]
:''Il potenziale reale di Nepomuk puo' essere esposto quando si eseguono pesanti queries sul repository dei dati. Questo tutorial fornisce un'introduzione alla semantica ed alla ricerca full-text in Nepomuk.''

== Conoscenza dell'Hardware (Solid) ==

;[[Development/Tutorials/Solid_Tutorials|Introduzione a Solid]]
:''Una introduzione all'uso della ricerca di hardware di Solid e all'interazione del sistema nelle applicazioni KDE.''

;[[Development/Tutorials/Solid_Network_Tutorial|Accesso alle Informazioni di Rete]]
:''Come usare il Sistema Solid per reperire informazioni sulla rete.''

== Multimedia (Phonon) ==

;[[Development/Tutorials/Phonon/Introduction|Phonon]]
:''Come iniziare con le API multimediali''

:''Come compilare e usare Phonon ed il suo backend GStreamer su Linux usando Qt 4.3.x''
::''Questo articolo ti da' un rapida introduzione su come usare checkout, compilare Phonon e il suo backend GStreamer su GNU/Linux con solo Qt 4.3.x. Fino alla fine, l'articolo descrive anche come uno sviluppatore puo' fare uso di Phonon per creare semplici video e audio players. Puoi leggere l'articolo [http://www.vcreatelogic.com/oss/docs/CompilingPhononOnLinux.pdf qui]. Puoi scaricare il file editabile in formato OpenDocumentText da [http://www.prashanthudupa.com/phonon/CompilingPhononOnLinux.odt qui].''

== Plasma ==

;[[Development/Tutorials/Plasma/GettingStarted|Iniziare con i Plasmoidi]]
:''Crea il tuo primo widget Plasma, o Plasmoide, in C++ con uno sfondo SVG, una icona ed un testo di esempio.''

;[[Development/Tutorials/Plasma/DataEngines|Scrivere un DataEngine]]
:''I DataEngines forniscono una [http://api.kde.org/4.0-api/kdebase-apidocs/workspace/libs/plasma/html/classPlasma_1_1DataEngine.html interfaccia standardizzata] a varie sorgenti dati per la visualizzazione e l'uso. Scopri cos'e' un DataEngine e come scriverne uno.''

;[[Development/Tutorials/Plasma/UsingDataEngines|Usare DataEngines in un Plasmoide]]
:''Con un DataEngine, e' possibile recuperare dati per visualizzarli in un modo semplice e standard. Questo tutorial copre l'argomento di come usare i DataEngines per questo scopo nei Plasmoidi.''

;[[Development/Tutorials/Plasma/AbstractRunner|Creare Runners]]
:''I Runners sono plugin che forniscono funzionalita' di ricerca action-based nel dialogo "esegui comando" dello spazio di lavoro di Plasma. Questi plugin possono essere usati da qualsiasi applicazione linkata a libplasma.''

;[[Development/Tutorials/Plasma/Theme|Creare un tema per Plasma]]
:''Guida per la creazione del tuo primo tema per Plasma.''

== Comunicazione (Decibel) ==

;[[Development/Tutorials/Decibel/GettingStarted|Iniziare con Decibel]]
:''Questo tutorial mostra come impostare Decibel.''

;[[Development/Tutorials/Decibel/Handling_TextChannels|Manipolare TextChannels]]
:''Questo tutorial introduce le basi sulla gestione di TextChannels in ingresso guidandoti attraverso la costruzione di una semplice applicazione di chat.''

== Kate / Kwrite ==

;[[Development/Tutorials/Kate/KTextEditor Plugins|Iniziare con i plugins di KTextEditor]]
:''Creare il tuo primo plugin di KTextEditor''

;[[Development/Tutorials/Kate/KTextEditor_Plugins_Advanced|Sviluppare un plugin con il dialogo di configurazione]]
:''Aggiungere un dialogo di configurazione all'esempio "Time & Date"''

;[[Development/Tutorials/Kate/KTextEditor_Example|Un semplice Editor]]
:''Creare una piccola applicazione con KTextEditor''

== Stampa ==

;[[Development/Tutorials/Printing Hello World|Hello World]]
:''Introduzione al sistema di stampa di KDE''

;[[Development/Tutorials/Printing Print Dialog|Finestra di dialogo di Stampa]]
:''Usare la finestra di dialogo di stampa di KDE''

== Get Hot New Stuff ==
; [[Development/Tutorials/K_Hot_New_Stuff2|New introduction to KGet Hot New Stuff2]]
:''A short tutorial about how to use KHotNewStuff2 in your application.''

* old links for KNS1 content:
; [[Development/Tutorials/Introduction to Get Hot New Stuff|Introduction to Get Hot New Stuff]]
:''An introduction to the developer-friendly network update system that allows KDE applications to fetch new application data at runtime in a user friendly manner.''

;[[Development/Tutorials/KNewStuffSecure|KNewStuff Secure]] ([http://developer.kde.org/documentation/tutorials/knewstuffsecure/index.html Original Link])
:''Tutorial showing how to share resources in a secured way (KDE 3.4 and later).'' By András Mantia <amantia@kde.org>.

== Goya ==
; [[Development/Tutorials/Introduction to Goya usage|Introduzione all'uso di Goya]]
:''Una introduzione all'uso del sottosistema Goya, che ti permette di aggiungere widgets semplicemente alle tue itemview e connettere i loro signal al tuo codice, come se fossero widgets reali.''

; [[Development/Tutorials/Introduction to Goya usage 2|Introduzione all'uso di Goya(parte 2)]]
:''La seconda parte del tutorial, con una with a leggera complessita' in piu' rispetto alla prima parte.''

== Sviluppo Rapido di Applicazioni (RAD) ==

=== Python ===

;[[Development/Tutorials/Python introduction to signals and slots|101 Introduzione ai signals e slots]]
:''Una semplice introduzione all'architettura signal e slot di Qt.''

=== Ruby ===

;[http://developer.kde.org/language-bindings/ruby/kde3tutorial/index.html KDE Ruby Korundum tutorial]
:''A ruby version of Antonio Larrosa Jiménez's KDE tutorial by Richard Dale. See the [http://developer.kde.org/language-bindings/ruby/index.html Ruby Developers Corner] for Qt tutorials and other info.''

;[[Development/Tutorials/Qt4_Ruby_Tutorial|Tutorial su Qt4 Ruby]]
:''Favoloso tutorial introduttivo sulle Qt di Trolltech, tradotto in Ruby.''

=== Shell ===

;[[Development/Tutorials/Shell_Scripting_with_KDE_Dialogs|Shell Scripting con i dialoghi di KDE]] ([http://developer.kde.org/documentation/tutorials/kdialog/t1.html Link Originale])
:''Tutorial da [mailto:bradh@frogmouth.net Brad Hards] che descrive come usare le finestre di dialogo di KDE negli script di shell usando kdialog. E' presentato come un tutorial basato su esempi.''

== Programmazione Grafica ==

;[[Development/Tutorials/Graphics/Performance|Perfomance di QPainter]]
:''Suggerimenti per evitare errori comuni che producono scarse prestazioni nell'uso di QPainter''

== Altri tutorials ==

=== Usare la Games Library di KDE ===
;[[Development/Tutorials/Games/KStandardGameAction| KStandardGameAction]]
:''Usare libkdegames per rendere i propri giochi adatti allo standard per i giochi di kde''
;[[Development/Tutorials/Games/Highscores| Highscores]]
:''Implementare una tabella per la classifica nei tuoi giochi''
;[[Development/Tutorials/Games/Theme Selector| Selettore dei temi]]
:''Usare la finestra di dialogo per i temi da libkdegames''

=== 2D Plotting (KPlotWidget) ===
;[[Development/Tutorials/KPlotWidget|Usare il widget data-plotting di kde]]
:''Questo tutorial introduce KPlotWidget, usato per il plotting di dati 2-D. Include informazioni sull'uso semplice del widget (includendo aggiunta e modifica dei data sets, e personalizzazione degli assi e delle etichette), e personalizzazioni avanzate (inclusa l'estensione del widget attraverso sottoclassi).''

=== Controllo Lessicale e Grammaticale (Sonnet) ===
;[[Development/Tutorials/Sonnet/SonnetTutorial|Aggiungere controllo lessicale o grammaticale alle applicazioni KDE]]
:''Questo tutorial introduce Sonnet e come uno puo' usarli per aggiungere la correzione linguistica nelle tue applicazioni KDE. Le funzionalita' ausiliarie di Sonnet saranno descritte in un tutorial separato.''

=== Pixmap cache (KPixmapCache) ===
;[[Development/Tutorials/KPixmapCache|Usare la pixmap cache di KDE]]
:''Questo tutorial mostra come usare KPixmapCache per il caching(per es. pixmaps generate da SVG o altri dati).''

=== Usare MarbleWidget (Marble) ===
;[[Development/Tutorials/MarbleWidget|Usare MarbleWidget]]
:''Questo breve tutorial descrive come usare il MarbleWidget nei tuoi progetti''

=== Usare SCM locali per lo sviluppo di KDE ===
;[[Development/Tutorials/Git|Usare Git per sviluppare per KDE]]
:''Questo tutorial mostra come usare Git per sviluppare per KDE''

== Materiali su KDE2 e KDE3 ==

;[[Development/Tutorials/KDE3|Tutorials su KDE3]]
:''Questi tutorials coprono gli argomenti relativi a KDE3.''

;[[Development/Tutorials/KDE2|Tutorials su KDE2]]
:''Questi tutorials coprono gli argomenti relativi a KDE2.''

[[Category:KDE4]]

Development/Tutorials/First program (it)

2008-11-29T11:58:40Z

Fresbeeplayer: punta al secondo tutorial

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow_(it)|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

== Prefazione ==

Il tuo primo programma dovrebbe salutare il mondo con un amichevole "Ciao Mondo", giusto? Per farlo, useremo un {{class|KMessageBox}} personalizzando uno dei pulsanti.

[[image:Ciaomondo_tutorial1.png|frame|center]]

{{tip|Per avere più informazioni su qualunque classe che incontri, Konqueror offre una veloce scorciatoia. Per cercare informazioni circa KMessageBox, basta digitare "kde:kmessagebox" in Konqueror e sarai portato alla documentazione.}}

{{tip|Vorresti poter usare KDevelop per i tuoi progetti, il quale fa molte cose carine come il completamento del codice, facile accesso alla documentazione delle API, supporto per il debugging.
Leggi [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|questo tutorial]] per configurare KDevelop correttamente. Puoi controllare se il setup è andato a buon fine aprendo un'applicazione KDE4 esistente con KDevelop.
Tuttavia hai ancora bisogno di editare a mano i files di CMake.}}

== Il Codice ==

Tutto il codice di cui abbiamo bisogno starà in un file, <tt>main.cpp</tt>. Crealo con il codice qua sotto:

<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>
#include <QByteArray>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// Il nome del programma, usato internamente.
"tutorial1",
// Il nome nel catalogo messaggi.
// Se nullo, verrà usato il nome del programma.
0,
// Una stringa con il nome del programma.
// Quella che verrà effettivamente visualizzata.
ki18n("Tutorial 1"),
// La stringa con la versione del programma.
"1.0",
// Piccola descrizione su cosa fa il programma.
ki18n("Visualizza una finestra KMessageBox."),
// La licenza con la quale il codice è rilasciato.
KAboutData::License_GPL,
// Copyright
ki18n("(c) 2007"),
// Testo opzionale mostrato in "Informazioni su".
// Può contenere qualunque informazione desiderata.
ki18n("Un po' di testo..."),
// La stringa con la homepage del programma.
QByteArray("http://tutorial.com/"),
// L'indirizzo email per la segnalazione di bug.
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Ciao" ), QString(),
i18n( "Questo è un tooltip" ),
i18n( "Questo è un testo di aiuto CheCos'è?." ) );
KMessageBox::questionYesNo( 0, i18n( "Ciao Mondo" ),
i18n( "Ciao" ), yesButton );
return app.exec();
}
</code>

Il primo codice specifico di KDE che incontriamo in questo programma è {{class|KAboutData}}. Questa è la classe utilizzata per immagazzinare le informazioni sul programma, come ad esempio una piccola descrizione, gli autori, o le informazioni sulla licenza. Praticamente ogni applicazione KDE dovrebbe usare questa classe.

Poi arriviamo a {{class|KCmdLineArgs}}. Questa è la classe che si usa quando si vogliono specificare istruzioni da riga di comando per, ad esempio, aprire il programma con uno specifico file. Comunque, in questo tutorial, semplicemente lo inizializziamo con l'oggetto {{class|KAboutData}} che abbiamo appena creato, in modo da poter usare le opzioni <tt>--version</tt> o <tt>--author</tt>

Quindi adiamo a creare l'oggetto {{class|KApplication}}. Ciò bisogna farlo esattamente una volta in ogni programma, visto che è necessario per cose come l'[[Development/Tutorials/Localization/i18n|i18n]].

Ora che abbiamo finito con le operazioni indispensabili di KDE, possiamo cominciare a fare cose interessanti con la nostra applicazione. Creeremo una finestra pop-up, ma personalizzeremo uno dei pulsanti. Per la personalizzazione avremo bisogno di un oggetto {{class|KGuiItem}}. Il primo argomento del costruttore di {{class|KGuiItem}} è il testo che apparirà sull'oggetto (nel nostro caso, un pulsante). Quindi ci sarà un opzione per inserire un'icona, ma non ne vogliamo una così gli mettiamo <tt>QString</tt>. Impostiamo quindi il tooltip (quello che appare quando fermi il puntatore su un elemento) ed infine il testo "Che Cos'è?" (accessibile tramite click col tasto destro, con Shift-F1 oppure cliccando su "?" nella barra del titolo e poi sul pulsante "Ciao").

Ora che abbiamo il nostro pulsante, possiamo creare il nostro pop-up. Chiamiamo la funzione <tt>{{class|KMessageBox}}::questionYesNo()</tt> la quale, in modo predefinito, crea una finestra con due pulsanti "Si" e "No". Il secondo argomento compone il testo mostrato nella finestra sopra i due pulsanti. Il terzo è l'intestazione della finestra; e infine impostiamo il KGuiItem di (quello che normalmente è) il pulsante "Si" con il nostro <tt>KGuiItem yesButton</tt> appena creato.

Notare come tutto il testo visibile all'utente passa attraverso la funzione i18n(); questo è necessario per permettere la traduzione della UI. Più informazioni sulla localizzazione possono essere trovate nel [[Development/Tutorials/Localization/i18n|tutorial sulla localizzazione]].

Abbiamo finito per quanto riguarda il codice. Ora la compilazione e la prova.

== Compilazione ==

Vorrai usare [[Development/Tutorials/CMake|CMake]] come ambiente di compilazione. Devi fornire un file chiamato CMakeLists.txt, cmake usa questo file per generare tutti i Makefiles.

=== CMakeLists.txt ===

Crea un file di nome CMakeLists.txt nella stessa cartella di main.cpp con questo contenuto:

<code ini n>
project (tutorial1)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial1_SRCS
main.cpp
)

kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

La funzione <tt>find_package()</tt> trova tutti i pacchetti che hai richiesto (in questo caso KDE4) ed imposta alcune variabili che descrivono la posizione degli header e delle librerie del pacchetto. In questo caso useremo la variabile <tt>KDE4_INCLUDES</tt> contenente il percorso ai files header di KDE4.

Per permettere al compilatore di trovare questi files, passiamo quella variabile alla funzione <tt>include_directories()</tt> la quale aggiunge gli header di KDE4 al percorso di ricerca degli header.

Poi creiamo una variabile chiamata <tt>tutorial1_SRCS</tt> con la funzione <tt>set()</tt>. In questo caso la impostiamo con il nome del nostro unico file sorgente.

Quindi usiamo <tt>kde4_add_executable()</tt> per creare un eseguibile chiamato <tt>tutorial1</tt> dai sorgenti elencati nella nostra variabile <tt>tutorial1_SRCS</tt>. In seguito, facciamo il link del nostro eseguibile alle librerie kdeui di KDE4 con <tt>target_link_libraries()</tt> e la variabile <tt>KDE4_KDEUI_LIBS</tt> precedentemente riempita dalla funzione <tt>find_package()</tt>. La riga che comincia con <tt>install</tt> scrive un target di default "install" dentro al Makefile.

=== Make ed Esecuzione ===

Puoi invocare CMake e make manualmente:

mkdir build && cd build
cmake .. # Nota questi due punti - non è una mancanza,
# stanno per "cartella superiore".
make

Oppure, se hai preparato il tuo ambiente come descritto in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], puoi compilare questo codice con:
cmakekde

Quindi lancialo con:
./tutorial1

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KXmlGuiWindow|usare KXmlGuiWindow]].

[[Category:C++]]

User:Fresbeeplayer

2008-11-29T11:57:08Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

* [[Template:TutorialBrowser_(it)]]
* [[Development/Tutorials/First_program_(it)]]
* [[Development/Tutorials/Using_KXmlGuiWindow_(it)]]

== Work in Progress ==

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/Using_KActions]]

User:Fresbeeplayer/Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T11:56:20Z

Fresbeeplayer: User:Fresbeeplayer/Development/Tutorials/Using KXmlGuiWindow (it) moved to Development/Tutorials/Using KXmlGuiWindow (it): Finita la traduzione

#REDIRECT [[Development/Tutorials/Using KXmlGuiWindow (it)]]

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T11:56:20Z

Fresbeeplayer: User:Fresbeeplayer/Development/Tutorials/Using KXmlGuiWindow (it) moved to Development/Tutorials/Using KXmlGuiWindow (it): Finita la traduzione

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Using_KXmlGuiWindow}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Come usare KXmlGuiWindow|

pre=[[Development/Tutorials/First_program_(it)|Tutorial 1 - Ciao Mondo]]|

next=[[Development/Tutorials/Using_KActions|Tutorial 3 - KActions and XMLGUI]]|

reading={{class|KXmlGuiWindow}}
}}

== Prefazione ==

Questo tutorial parte dal precedente [[Development/Tutorials/First_program_(it)|Ciao Mondo]] ed introdurrà la classe {{class|KXmlGuiWindow}}.

Nel precedente tutorial il programma faceva apparire una finestra di dialogo, ma ora faremo dei passi verso un programma funzionale.

[[Image:Kxmlguiwindow_tutorial2.png|frame|center]]

== KXmlGuiWindow ==

{{class|KXmlGuiWindow}} offre una finestra completa con la barra dei menu, una degli strumenti, la barra di stato ed un'area principale al centro per un grande widget. Molte applicazioni KDE deriveranno da questa classe perché fornisce un modo semplice per la disposizione di questi elementi tramite un file XML (questa tecnologia è chiamata XMLGUI). Anche se non useremo XMLGUI in ''questo'' tutorial, la useremo nel prossimo.

Per poter avere un KXmlGuiWindow utile, dobbiamo ereditarlo. Creeremo due files, un <tt>mainwindow.cpp</tt> ed un <tt>mainwindow.h</tt> i quali conterranno il nostro codice.

=== mainwindow.h ===

<code cppqt n>
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <KXmlGuiWindow>
#include <KTextEdit>

class MainWindow : public KXmlGuiWindow
{
public:
MainWindow(QWidget *genitore = 0);

private:
KTextEdit* areaDiTesto;
};

#endif
</code>

Prima di tutto creiamo una sotto-classe di KXmlGuiWindow alla linea 7 con <tt>class MainWindow : public KXmlGuiWindow</tt>.

Poi dichiariamo il costruttore con <tt>MainWindow(QWidget *genitore=0);</tt>.

E in fine definiamo un puntatore all'oggetto che sarà il corpo del nostro programma. {{class|KTextEdit}} è un generico editor di testo ricco con qualche finezza di KDE come il nascondere automaticamente il cursore.

=== mainwindow.cpp ===

<code cppqt n>
#include "mainwindow.h"

MainWindow::MainWindow(QWidget *genitore) : KXmlGuiWindow(genitore)
{
areaDiTesto = new KTextEdit();
setCentralWidget(areaDiTesto);
setupGUI();
}
</code>

Alla riga 1, ovviamente, dobbiamo includere gli headers contenenti la definizione delle classi.

Poi sulla riga 5, inizializziamo il nostro editor di testo con un oggetto. Quindi alla sesta riga usiamo la funzione setCentralWidget() interna a KXmlGuiWindow, la quale gli dice cosa dovrebbe apparire nella sezione centrale della finestra.

Infine viene chiamato KXmlGuiWindow::setupGUI(), il quale fa un sacco di cose dietro le quinte e crea la barra dei menu predefinita (Settings, Help).

== Ritorno a main.cpp ==

Affinché di fatto la finestra funzioni, abbiamo bisogno di aggiungere poche linee in main.cpp:

=== main.cpp ===

<code cppqt n>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <QByteArray>

#include "mainwindow.h"

int main (int argc, char *argv[])
{
KAboutData aboutData("tutorial2", 0,
ki18n("Tutorial 2"), "1.0",
ki18n("Una semplice area di testo."),
KAboutData::License_GPL, ki18n("(c) 2007"),
ki18n("Un po' di testo..."),
QByteArray("http://tutorial.com/"),
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;

MainWindow* window = new MainWindow();
window->show();

return app.exec();
}
</code>

Le sole righe nuove qui (comparate con il primo tutorial) sono 6, 21 e 22. Alla riga 21, creiamo il nostro oggetto MainWindow e alla 22 lo visualizziamo.

== CMake ==

Il miglior modo di compilare il programma è usando CMake. Ciò che cambia dal primo tutorial consiste nell'aggiunta di <tt>mainwindow.cpp</tt> nella lista dei sorgenti e tutti i <tt>tutorial1</tt> diventano <tt>tutorial2</tt>.

=== CMakeLists.txt ===

<code ini n>
project (tutorial2)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial2_SRCS
main.cpp
mainwindow.cpp
)

kde4_add_executable(tutorial2 ${tutorial2_SRCS})
target_link_libraries(tutorial2 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial2 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

=== Compilazione ===

Per la compilazione, il link e l'esecuzione, usa:
mkdir build && cd build
cmake ..
make
./tutorial2

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KActions|usare KActions]].

[[Category:C++]]

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T11:54:43Z

Fresbeeplayer: cursor auto-hiding

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T11:44:44Z

Fresbeeplayer: svista in mainwindow.cpp

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Using_KXmlGuiWindow}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Come usare KXmlGuiWindow|

pre=[[Development/Tutorials/First_program_(it)|Tutorial 1 - Ciao Mondo]]|

next=[[Development/Tutorials/Using_KActions|Tutorial 3 - KActions and XMLGUI]]|

reading={{class|KXmlGuiWindow}}
}}

== Prefazione ==

Questo tutorial parte dal precedente [[Development/Tutorials/First_program_(it)|Ciao Mondo]] ed introdurrà la classe {{class|KXmlGuiWindow}}.

Nel precedente tutorial il programma faceva apparire una finestra di dialogo, ma ora faremo dei passi verso un programma funzionale.

[[Image:Kxmlguiwindow_tutorial2.png|frame|center]]

== KXmlGuiWindow ==

{{class|KXmlGuiWindow}} offre una finestra completa con la barra dei menu, una degli strumenti, la barra di stato ed un'area principale al centro per un grande widget. Molte applicazioni KDE deriveranno da questa classe perché fornisce un modo semplice per la disposizione di questi elementi tramite un file XML (questa tecnologia è chiamata XMLGUI). Anche se non useremo XMLGUI in ''questo'' tutorial, la useremo nel prossimo.

Per poter avere un KXmlGuiWindow utile, dobbiamo ereditarlo. Creeremo due files, un <tt>mainwindow.cpp</tt> ed un <tt>mainwindow.h</tt> i quali conterranno il nostro codice.

=== mainwindow.h ===

<code cppqt n>
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <KXmlGuiWindow>
#include <KTextEdit>

class MainWindow : public KXmlGuiWindow
{
public:
MainWindow(QWidget *genitore = 0);

private:
KTextEdit* areaDiTesto;
};

#endif
</code>

Prima di tutto creiamo una sotto-classe di KXmlGuiWindow alla linea 7 con <tt>class MainWindow : public KXmlGuiWindow</tt>.

Poi dichiariamo il costruttore con <tt>MainWindow(QWidget *genitore=0);</tt>.

<! -- come cacchio si traduce '''cursor auto-hiding''' ??? -->
E in fine definiamo un puntatore all'oggetto che sarà il corpo del nostro programma. {{class|KTextEdit}} è un generico editor di testo ricco con qualche finezza di KDE come il "nascondimento" automatico del cursore.

=== mainwindow.cpp ===

<code cppqt n>
#include "mainwindow.h"

MainWindow::MainWindow(QWidget *genitore) : KXmlGuiWindow(genitore)
{
areaDiTesto = new KTextEdit();
setCentralWidget(areaDiTesto);
setupGUI();
}
</code>

Alla riga 1, ovviamente, dobbiamo includere gli headers contenenti la definizione delle classi.

Poi sulla riga 5, inizializziamo il nostro editor di testo con un oggetto. Quindi alla sesta riga usiamo la funzione setCentralWidget() interna a KXmlGuiWindow, la quale gli dice cosa dovrebbe apparire nella sezione centrale della finestra.

Infine viene chiamato KXmlGuiWindow::setupGUI(), il quale fa un sacco di cose dietro le quinte e crea la barra dei menu predefinita (Settings, Help).

== Ritorno a main.cpp ==

Affinché di fatto la finestra funzioni, abbiamo bisogno di aggiungere poche linee in main.cpp:

=== main.cpp ===

<code cppqt n>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <QByteArray>

#include "mainwindow.h"

int main (int argc, char *argv[])
{
KAboutData aboutData("tutorial2", 0,
ki18n("Tutorial 2"), "1.0",
ki18n("Una semplice area di testo."),
KAboutData::License_GPL, ki18n("(c) 2007"),
ki18n("Un po' di testo..."),
QByteArray("http://tutorial.com/"),
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;

MainWindow* window = new MainWindow();
window->show();

return app.exec();
}
</code>

Le sole righe nuove qui (comparate con il primo tutorial) sono 6, 21 e 22. Alla riga 21, creiamo il nostro oggetto MainWindow e alla 22 lo visualizziamo.

== CMake ==

Il miglior modo di compilare il programma è usando CMake. Ciò che cambia dal primo tutorial consiste nell'aggiunta di <tt>mainwindow.cpp</tt> nella lista dei sorgenti e tutti i <tt>tutorial1</tt> diventano <tt>tutorial2</tt>.

=== CMakeLists.txt ===

<code ini n>
project (tutorial2)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial2_SRCS
main.cpp
mainwindow.cpp
)

kde4_add_executable(tutorial2 ${tutorial2_SRCS})
target_link_libraries(tutorial2 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial2 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

=== Compilazione ===

Per la compilazione, il link e l'esecuzione, usa:
mkdir build && cd build
cmake ..
make
./tutorial2

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KActions|usare KActions]].

[[Category:C++]]

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T11:37:12Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Using_KXmlGuiWindow}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Come usare KXmlGuiWindow|

pre=[[Development/Tutorials/First_program_(it)|Tutorial 1 - Ciao Mondo]]|

next=[[Development/Tutorials/Using_KActions|Tutorial 3 - KActions and XMLGUI]]|

reading={{class|KXmlGuiWindow}}
}}

== Prefazione ==

Questo tutorial parte dal precedente [[Development/Tutorials/First_program_(it)|Ciao Mondo]] ed introdurrà la classe {{class|KXmlGuiWindow}}.

Nel precedente tutorial il programma faceva apparire una finestra di dialogo, ma ora faremo dei passi verso un programma funzionale.

[[Image:Kxmlguiwindow_tutorial2.png|frame|center]]

== KXmlGuiWindow ==

{{class|KXmlGuiWindow}} offre una finestra completa con la barra dei menu, una degli strumenti, la barra di stato ed un'area principale al centro per un grande widget. Molte applicazioni KDE deriveranno da questa classe perché fornisce un modo semplice per la disposizione di questi elementi tramite un file XML (questa tecnologia è chiamata XMLGUI). Anche se non useremo XMLGUI in ''questo'' tutorial, la useremo nel prossimo.

Per poter avere un KXmlGuiWindow utile, dobbiamo ereditarlo. Creeremo due files, un <tt>mainwindow.cpp</tt> ed un <tt>mainwindow.h</tt> i quali conterranno il nostro codice.

=== mainwindow.h ===

<code cppqt n>
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <KXmlGuiWindow>
#include <KTextEdit>

class MainWindow : public KXmlGuiWindow
{
public:
MainWindow(QWidget *genitore=0);

private:
KTextEdit* areaDiTesto;
};

#endif
</code>

Prima di tutto creiamo una sotto-classe di KXmlGuiWindow alla linea 7 con <tt>class MainWindow : public KXmlGuiWindow</tt>.

Poi dichiariamo il costruttore con <tt>MainWindow(QWidget *genitore=0);</tt>.

<! -- come cacchio si traduce '''cursor auto-hiding''' ??? -->
E in fine definiamo un puntatore all'oggetto che sarà il corpo del nostro programma. {{class|KTextEdit}} è un generico editor di testo ricco con qualche finezza di KDE come il "nascondimento" automatico del cursore.

=== mainwindow.cpp ===

<code cppqt n>
#include "mainwindow.h"

MainWindow::MainWindow(QWidget *parent) : KXmlGuiWindow(parent)
{
areaDiTesto = new KTextEdit();
setCentralWidget(areaDiTesto);
setupGUI();
}
</code>

Alla riga 1, ovviamente, dobbiamo includere gli headers contenenti la definizione delle classi.

Poi sulla riga 5, inizializziamo il nostro editor di testo con un oggetto. Quindi alla sesta riga usiamo la funzione setCentralWidget() interna a KXmlGuiWindow, la quale gli dice cosa dovrebbe apparire nella sezione centrale della finestra.

Infine viene chiamato KXmlGuiWindow::setupGUI(), il quale fa un sacco di cose dietro le quinte e crea la barra dei menu predefinita (Settings, Help).

== Ritorno a main.cpp ==

Affinché di fatto la finestra funzioni, abbiamo bisogno di aggiungere poche linee in main.cpp:

=== main.cpp ===

<code cppqt n>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <QByteArray>

#include "mainwindow.h"

int main (int argc, char *argv[])
{
KAboutData aboutData("tutorial2", 0,
ki18n("Tutorial 2"), "1.0",
ki18n("Una semplice area di testo."),
KAboutData::License_GPL, ki18n("(c) 2007"),
ki18n("Un po' di testo..."),
QByteArray("http://tutorial.com/"),
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;

MainWindow* window = new MainWindow();
window->show();

return app.exec();
}
</code>

Le sole righe nuove qui (comparate con il primo tutorial) sono 6, 21 e 22. Alla riga 21, creiamo il nostro oggetto MainWindow e alla 22 lo visualizziamo.

== CMake ==

Il miglior modo di compilare il programma è usando CMake. Ciò che cambia dal primo tutorial consiste nell'aggiunta di <tt>mainwindow.cpp</tt> nella lista dei sorgenti e tutti i <tt>tutorial1</tt> diventano <tt>tutorial2</tt>.

=== CMakeLists.txt ===

<code ini n>
project (tutorial2)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial2_SRCS
main.cpp
mainwindow.cpp
)

kde4_add_executable(tutorial2 ${tutorial2_SRCS})
target_link_libraries(tutorial2 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial2 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

=== Compilazione ===

Per la compilazione, il link e l'esecuzione, usa:
mkdir build && cd build
cmake ..
make
./tutorial2

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KActions|usare KActions]].

[[Category:C++]]

User:Fresbeeplayer

2008-11-29T11:35:57Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

* [[Template:TutorialBrowser_(it)]]
* [[Development/Tutorials/First_program_(it)]]

== Work in Progress ==

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Using_KXmlGuiWindow_(it)]]
* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/Using_KActions]]

Development/Tutorials/First program (it)

2008-11-29T11:33:40Z

Fresbeeplayer: Sistemazione del codice e della descrizione di CMakeLists.txt

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

== Prefazione ==

Il tuo primo programma dovrebbe salutare il mondo con un amichevole "Ciao Mondo", giusto? Per farlo, useremo un {{class|KMessageBox}} personalizzando uno dei pulsanti.

[[image:Ciaomondo_tutorial1.png|frame|center]]

{{tip|Per avere più informazioni su qualunque classe che incontri, Konqueror offre una veloce scorciatoia. Per cercare informazioni circa KMessageBox, basta digitare "kde:kmessagebox" in Konqueror e sarai portato alla documentazione.}}

{{tip|Vorresti poter usare KDevelop per i tuoi progetti, il quale fa molte cose carine come il completamento del codice, facile accesso alla documentazione delle API, supporto per il debugging.
Leggi [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|questo tutorial]] per configurare KDevelop correttamente. Puoi controllare se il setup è andato a buon fine aprendo un'applicazione KDE4 esistente con KDevelop.
Tuttavia hai ancora bisogno di editare a mano i files di CMake.}}

== Il Codice ==

Tutto il codice di cui abbiamo bisogno starà in un file, <tt>main.cpp</tt>. Crealo con il codice qua sotto:

<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>
#include <QByteArray>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// Il nome del programma, usato internamente.
"tutorial1",
// Il nome nel catalogo messaggi.
// Se nullo, verrà usato il nome del programma.
0,
// Una stringa con il nome del programma.
// Quella che verrà effettivamente visualizzata.
ki18n("Tutorial 1"),
// La stringa con la versione del programma.
"1.0",
// Piccola descrizione su cosa fa il programma.
ki18n("Visualizza una finestra KMessageBox."),
// La licenza con la quale il codice è rilasciato.
KAboutData::License_GPL,
// Copyright
ki18n("(c) 2007"),
// Testo opzionale mostrato in "Informazioni su".
// Può contenere qualunque informazione desiderata.
ki18n("Un po' di testo..."),
// La stringa con la homepage del programma.
QByteArray("http://tutorial.com/"),
// L'indirizzo email per la segnalazione di bug.
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Ciao" ), QString(),
i18n( "Questo è un tooltip" ),
i18n( "Questo è un testo di aiuto CheCos'è?." ) );
KMessageBox::questionYesNo( 0, i18n( "Ciao Mondo" ),
i18n( "Ciao" ), yesButton );
return app.exec();
}
</code>

Il primo codice specifico di KDE che incontriamo in questo programma è {{class|KAboutData}}. Questa è la classe utilizzata per immagazzinare le informazioni sul programma, come ad esempio una piccola descrizione, gli autori, o le informazioni sulla licenza. Praticamente ogni applicazione KDE dovrebbe usare questa classe.

Poi arriviamo a {{class|KCmdLineArgs}}. Questa è la classe che si usa quando si vogliono specificare istruzioni da riga di comando per, ad esempio, aprire il programma con uno specifico file. Comunque, in questo tutorial, semplicemente lo inizializziamo con l'oggetto {{class|KAboutData}} che abbiamo appena creato, in modo da poter usare le opzioni <tt>--version</tt> o <tt>--author</tt>

Quindi adiamo a creare l'oggetto {{class|KApplication}}. Ciò bisogna farlo esattamente una volta in ogni programma, visto che è necessario per cose come l'[[Development/Tutorials/Localization/i18n|i18n]].

Ora che abbiamo finito con le operazioni indispensabili di KDE, possiamo cominciare a fare cose interessanti con la nostra applicazione. Creeremo una finestra pop-up, ma personalizzeremo uno dei pulsanti. Per la personalizzazione avremo bisogno di un oggetto {{class|KGuiItem}}. Il primo argomento del costruttore di {{class|KGuiItem}} è il testo che apparirà sull'oggetto (nel nostro caso, un pulsante). Quindi ci sarà un opzione per inserire un'icona, ma non ne vogliamo una così gli mettiamo <tt>QString</tt>. Impostiamo quindi il tooltip (quello che appare quando fermi il puntatore su un elemento) ed infine il testo "Che Cos'è?" (accessibile tramite click col tasto destro, con Shift-F1 oppure cliccando su "?" nella barra del titolo e poi sul pulsante "Ciao").

Ora che abbiamo il nostro pulsante, possiamo creare il nostro pop-up. Chiamiamo la funzione <tt>{{class|KMessageBox}}::questionYesNo()</tt> la quale, in modo predefinito, crea una finestra con due pulsanti "Si" e "No". Il secondo argomento compone il testo mostrato nella finestra sopra i due pulsanti. Il terzo è l'intestazione della finestra; e infine impostiamo il KGuiItem di (quello che normalmente è) il pulsante "Si" con il nostro <tt>KGuiItem yesButton</tt> appena creato.

Notare come tutto il testo visibile all'utente passa attraverso la funzione i18n(); questo è necessario per permettere la traduzione della UI. Più informazioni sulla localizzazione possono essere trovate nel [[Development/Tutorials/Localization/i18n|tutorial sulla localizzazione]].

Abbiamo finito per quanto riguarda il codice. Ora la compilazione e la prova.

== Compilazione ==

Vorrai usare [[Development/Tutorials/CMake|CMake]] come ambiente di compilazione. Devi fornire un file chiamato CMakeLists.txt, cmake usa questo file per generare tutti i Makefiles.

=== CMakeLists.txt ===

Crea un file di nome CMakeLists.txt nella stessa cartella di main.cpp con questo contenuto:

<code ini n>
project (tutorial1)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial1_SRCS
main.cpp
)

kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

La funzione <tt>find_package()</tt> trova tutti i pacchetti che hai richiesto (in questo caso KDE4) ed imposta alcune variabili che descrivono la posizione degli header e delle librerie del pacchetto. In questo caso useremo la variabile <tt>KDE4_INCLUDES</tt> contenente il percorso ai files header di KDE4.

Per permettere al compilatore di trovare questi files, passiamo quella variabile alla funzione <tt>include_directories()</tt> la quale aggiunge gli header di KDE4 al percorso di ricerca degli header.

Poi creiamo una variabile chiamata <tt>tutorial1_SRCS</tt> con la funzione <tt>set()</tt>. In questo caso la impostiamo con il nome del nostro unico file sorgente.

Quindi usiamo <tt>kde4_add_executable()</tt> per creare un eseguibile chiamato <tt>tutorial1</tt> dai sorgenti elencati nella nostra variabile <tt>tutorial1_SRCS</tt>. In seguito, facciamo il link del nostro eseguibile alle librerie kdeui di KDE4 con <tt>target_link_libraries()</tt> e la variabile <tt>KDE4_KDEUI_LIBS</tt> precedentemente riempita dalla funzione <tt>find_package()</tt>. La riga che comincia con <tt>install</tt> scrive un target di default "install" dentro al Makefile.

=== Make ed Esecuzione ===

Puoi invocare CMake e make manualmente:

mkdir build && cd build
cmake .. # Nota questi due punti - non è una mancanza,
# stanno per "cartella superiore".
make

Oppure, se hai preparato il tuo ambiente come descritto in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], puoi compilare questo codice con:
cmakekde

Quindi lancialo con:
./tutorial1

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KXmlGuiWindow|usare KXmlGuiWindow]].

[[Category:C++]]

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T11:26:05Z

Fresbeeplayer: Traduzione completata

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Using_KXmlGuiWindow}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Come usare KXmlGuiWindow|

pre=[[Development/Tutorials/First_program_(it)|Tutorial 1 - Ciao Mondo]]|

next=[[Development/Tutorials/Using_KActions|Tutorial 3 - KActions and XMLGUI]]|

reading={{class|KXmlGuiWindow}}
}}

== Prefazione ==

Questo tutorial parte dal precedente [[Development/Tutorials/First_program_(it)|Ciao Mondo]] ed introdurrà la classe {{class|KXmlGuiWindow}}.

Nel precedente tutorial il programma faceva apparire una finestra di dialogo, ma ora faremo dei passi verso un programma funzionale.

[[Image:Kxmlguiwindow_tutorial2.png|frame|center]]

== KXmlGuiWindow ==

{{class|KXmlGuiWindow}} offre una finestra completa con la barra dei menu, una degli strumenti, la barra di stato ed un'area principale al centro per un grande widget. Molte applicazioni KDE deriveranno da questa classe perché fornisce un modo semplice per la disposizione di questi elementi tramite un file XML (questa tecnologia è chiamata XMLGUI). Anche se non useremo XMLGUI in ''questo'' tutorial, la useremo nel prossimo.

Per poter avere un KXmlGuiWindow utile, dobbiamo ereditarlo. Creeremo due files, un <tt>mainwindow.cpp</tt> ed un <tt>mainwindow.h</tt> i quali conterranno il nostro codice.

=== mainwindow.h ===

<code cppqt n>
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <KXmlGuiWindow>
#include <KTextEdit>

class MainWindow : public KXmlGuiWindow
{
public:
MainWindow(QWidget *genitore=0);

private:
KTextEdit* areaDiTesto;
};

#endif
</code>

Prima di tutto creiamo una sotto-classe di KXmlGuiWindow alla linea 7 con <tt>class MainWindow : public KXmlGuiWindow</tt>.

Poi dichiariamo il costruttore con <tt>MainWindow(QWidget *genitore=0);</tt>.

<! -- come cacchio si traduce '''cursor auto-hiding''' ??? -->
E in fine definiamo un puntatore all'oggetto che sarà il corpo del nostro programma. {{class|KTextEdit}} è un generico editor di testo ricco con qualche finezza di KDE come il "nascondimento" automatico del cursore.

=== mainwindow.cpp ===

<code cppqt n>
#include "mainwindow.h"

MainWindow::MainWindow(QWidget *parent) : KXmlGuiWindow(parent)
{
areaDiTesto = new KTextEdit();
setCentralWidget(areaDiTesto);
setupGUI();
}
</code>

Alla riga 1, ovviamente, dobbiamo includere gli headers contenenti la definizione delle classi.

Poi sulla riga 5, inizializziamo il nostro editor di testo con un oggetto. Quindi alla sesta riga usiamo la funzione setCentralWidget() interna a KXmlGuiWindow, la quale gli dice cosa dovrebbe apparire nella sezione centrale della finestra.

Infine viene chiamato KXmlGuiWindow::setupGUI(), il quale fa un sacco di cose dietro le quinte e crea la barra dei menu predefinita (Settings, Help).

== Ritorno a main.cpp ==

Affinché di fatto la finestra funzioni, abbiamo bisogno di aggiungere poche linee in main.cpp:

=== main.cpp ===

<code cppqt n>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <QByteArray>

#include "mainwindow.h"

int main (int argc, char *argv[])
{
KAboutData aboutData("tutorial2", 0,
ki18n("Tutorial 2"), "1.0",
ki18n("Una semplice area di testo."),
KAboutData::License_GPL, ki18n("(c) 2007"),
ki18n("Un po' di testo..."),
QByteArray("http://tutorial.com/"),
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;

MainWindow* window = new MainWindow();
window->show();

return app.exec();
}
</code>

Le sole righe nuove qui (comparate con il primo tutorial) sono 6, 21 e 22. Alla riga 21, creiamo il nostro oggetto MainWindow e alla 22 lo visualizziamo.

== CMake ==

Il miglior modo di compilare il programma è usando CMake. Ciò che cambia dal primo tutorial consiste nell'aggiunta di <tt>mainwindow.cpp</tt> nella lista dei sorgenti e tutti i <tt>tutorial1</tt> diventano <tt>tutorial2</tt>.

=== CMakeLists.txt ===

<code ini n>
project (tutorial2)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial2_SRCS
main.cpp
mainwindow.cpp
)

kde4_add_executable(tutorial2 ${tutorial2_SRCS})
target_link_libraries(tutorial2 ${KDE4_KDEUI_LIBS})
</code>

=== Compilazione ===

Per la compilazione, il link e l'esecuzione, usa:
mkdir build && cd build
cmake ..
make
./tutorial2

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KActions|usare KActions]].

[[Category:C++]]

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T11:15:54Z

Fresbeeplayer: Numeri di riga

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Using_KXmlGuiWindow}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Come usare KXmlGuiWindow|

pre=[[Development/Tutorials/First_program_(it)|Tutorial 1 - Ciao Mondo]]|

next=[[Development/Tutorials/Using_KActions|Tutorial 3 - KActions and XMLGUI]]|

reading={{class|KXmlGuiWindow}}
}}

== Prefazione ==

Questo tutorial parte dal precedente [[Development/Tutorials/First_program_(it)|Ciao Mondo]] ed introdurrà la classe {{class|KXmlGuiWindow}}.

Nel precedente tutorial il programma faceva apparire una finestra di dialogo, ma ora faremo dei passi verso un programma funzionale.

[[Image:Kxmlguiwindow_tutorial2.png|frame|center]]

== KXmlGuiWindow ==

{{class|KXmlGuiWindow}} offre una finestra completa con la barra dei menu, una degli strumenti, la barra di stato ed un'area principale al centro per un grande widget. Molte applicazioni KDE deriveranno da questa classe perché fornisce un modo semplice per la disposizione di questi elementi tramite un file XML (questa tecnologia è chiamata XMLGUI). Anche se non useremo XMLGUI in ''questo'' tutorial, la useremo nel prossimo.

Per poter avere un KXmlGuiWindow utile, dobbiamo ereditarlo. Creeremo due files, un <tt>mainwindow.cpp</tt> ed un <tt>mainwindow.h</tt> i quali conterranno il nostro codice.

=== mainwindow.h ===

<code cppqt n>
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <KXmlGuiWindow>
#include <KTextEdit>

class MainWindow : public KXmlGuiWindow
{
public:
MainWindow(QWidget *genitore=0);

private:
KTextEdit* areaDiTesto;
};

#endif
</code>

Prima di tutto creiamo una sotto-classe di KXmlGuiWindow alla linea 7 con <tt>class MainWindow : public KXmlGuiWindow</tt>.

Poi dichiariamo il costruttore con <tt>MainWindow(QWidget *genitore=0);</tt>.

<! -- come cacchio si traduce '''cursor auto-hiding''' ??? -->
E in fine definiamo un puntatore all'oggetto che sarà il corpo del nostro programma. {{class|KTextEdit}} è un generico editor di testo ricco con qualche finezza di KDE come il "nascondimento" automatico del cursore.

=== mainwindow.cpp ===

<code cppqt n>
#include "mainwindow.h"

MainWindow::MainWindow(QWidget *parent) : KXmlGuiWindow(parent)
{
areaDiTesto = new KTextEdit();
setCentralWidget(areaDiTesto);
setupGUI();
}
</code>

Alla riga 1, ovviamente, dobbiamo includere gli headers contenenti la definizione delle classi.

Poi sulla riga 5, inizializziamo il nostro editor di testo con un oggetto. Quindi alla sesta riga usiamo la funzione setCentralWidget() interna a KXmlGuiWindow, la quale gli dice cosa dovrebbe apparire nella sezione centrale della finestra.

Infine viene chiamato KXmlGuiWindow::setupGUI(), il quale fa un sacco di cose dietro le quinte e crea la barra dei menu predefinita (Settings, Help).

== Ritorno a main.cpp ==

Affinché di fatto la finestra funzioni, abbiamo bisogno di aggiungere poche linee in main.cpp:

=== main.cpp ===

<code cppqt n>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <QByteArray>

#include "mainwindow.h"

int main (int argc, char *argv[])
{
KAboutData aboutData("tutorial2", 0,
ki18n("Tutorial 2"), "1.0",
ki18n("Una semplice area di testo."),
KAboutData::License_GPL, ki18n("(c) 2007"),
ki18n("Un po' di testo..."),
QByteArray("http://tutorial.com/"),
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;

MainWindow* window = new MainWindow();
window->show();

return app.exec();
}
</code>

The only new lines here (compared to Tutorial 1) are 5, 18 and 19. On line 18, we create our MainWindow object and then on line 19, we display it.

==CMake==
The best way to build the program is to use CMake. All that's changed since tutorial 1 is that <tt>mainwindow.cpp</tt> has been added to the sources list and any <tt>tutorial1</tt> has become <tt>tutorial2</tt>.
===CMakeLists.txt===
<code ini n>
project (tutorial2)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial2_SRCS
main.cpp
mainwindow.cpp
)

kde4_add_executable(tutorial2 ${tutorial2_SRCS})
target_link_libraries(tutorial2 ${KDE4_KDEUI_LIBS})
</code>

===Compile it===
To compile, link and run it, use:
mkdir build && cd build
cmake ..
make
./tutorial2

==Moving On==
Now you can move on to [[Development/Tutorials/Using_KActions|using KActions]].

[[Category:C++]]

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T11:13:25Z

Fresbeeplayer: Traduzione fino al codice di main.cpp

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Using_KXmlGuiWindow}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Come usare KXmlGuiWindow|

pre=[[Development/Tutorials/First_program_(it)|Tutorial 1 - Ciao Mondo]]|

next=[[Development/Tutorials/Using_KActions|Tutorial 3 - KActions and XMLGUI]]|

reading={{class|KXmlGuiWindow}}
}}

== Prefazione ==

Questo tutorial parte dal precedente [[Development/Tutorials/First_program_(it)|Ciao Mondo]] ed introdurrà la classe {{class|KXmlGuiWindow}}.

Nel precedente tutorial il programma faceva apparire una finestra di dialogo, ma ora faremo dei passi verso un programma funzionale.

[[Image:Kxmlguiwindow_tutorial2.png|frame|center]]

== KXmlGuiWindow ==

{{class|KXmlGuiWindow}} offre una finestra completa con la barra dei menu, una degli strumenti, la barra di stato ed un'area principale al centro per un grande widget. Molte applicazioni KDE deriveranno da questa classe perché fornisce un modo semplice per la disposizione di questi elementi tramite un file XML (questa tecnologia è chiamata XMLGUI). Anche se non useremo XMLGUI in ''questo'' tutorial, la useremo nel prossimo.

Per poter avere un KXmlGuiWindow utile, dobbiamo ereditarlo. Creeremo due files, un <tt>mainwindow.cpp</tt> ed un <tt>mainwindow.h</tt> i quali conterranno il nostro codice.

=== mainwindow.h ===

<code cppqt n>
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <KXmlGuiWindow>
#include <KTextEdit>

class MainWindow : public KXmlGuiWindow
{
public:
MainWindow(QWidget *genitore=0);

private:
KTextEdit* areaDiTesto;
};

#endif
</code>

Prima di tutto creiamo una sotto-classe di KXmlGuiWindow alla linea 7 con <tt>class MainWindow : public KXmlGuiWindow</tt>.

Poi dichiariamo il costruttore con <tt>MainWindow(QWidget *genitore=0);</tt>.

<! -- come cacchio si traduce '''cursor auto-hiding''' ??? -->
E in fine definiamo un puntatore all'oggetto che sarà il corpo del nostro programma. {{class|KTextEdit}} è un generico editor di testo ricco con qualche finezza di KDE come il "nascondimento" automatico del cursore.

=== mainwindow.cpp ===

<code cppqt n>
#include "mainwindow.h"

MainWindow::MainWindow(QWidget *parent) : KXmlGuiWindow(parent)
{
areaDiTesto = new KTextEdit();
setCentralWidget(areaDiTesto);
setupGUI();
}
</code>

Alla riga 1, ovviamente, dobbiamo includere gli headers contenenti la definizione delle classi.

Poi sulla riga 5, inizializziamo il nostro editor di testo con un oggetto. Quindi alla sesta riga usiamo la funzione setCentralWidget() interna a KXmlGuiWindow, la quale gli dice cosa dovrebbe apparire nella sezione centrale della finestra.

Infine viene chiamato KXmlGuiWindow::setupGUI(), il quale fa un sacco di cose dietro le quinte e crea la barra dei menu predefinita (Settings, Help).

== Ritorno a main.cpp ==

Affinché di fatto la finestra funzioni, abbiamo bisogno di aggiungere poche linee in main.cpp:

=== main.cpp ===

<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <QByteArray>

#include "mainwindow.h"

int main (int argc, char *argv[])
{
KAboutData aboutData("tutorial2", 0,
ki18n("Tutorial 2"), "1.0",
ki18n("Una semplice area di testo."),
KAboutData::License_GPL, ki18n("(c) 2007"),
ki18n("Un po' di testo..."),
QByteArray("http://tutorial.com/"),
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;

MainWindow* window = new MainWindow();
window->show();

return app.exec();
}
</code>

The only new lines here (compared to Tutorial 1) are 5, 18 and 19. On line 18, we create our MainWindow object and then on line 19, we display it.

==CMake==
The best way to build the program is to use CMake. All that's changed since tutorial 1 is that <tt>mainwindow.cpp</tt> has been added to the sources list and any <tt>tutorial1</tt> has become <tt>tutorial2</tt>.
===CMakeLists.txt===
<code ini n>
project (tutorial2)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial2_SRCS
main.cpp
mainwindow.cpp
)

kde4_add_executable(tutorial2 ${tutorial2_SRCS})
target_link_libraries(tutorial2 ${KDE4_KDEUI_LIBS})
</code>

===Compile it===
To compile, link and run it, use:
mkdir build && cd build
cmake ..
make
./tutorial2

==Moving On==
Now you can move on to [[Development/Tutorials/Using_KActions|using KActions]].

[[Category:C++]]

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T10:11:26Z

Fresbeeplayer: Introduzione + immagine

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Using_KXmlGuiWindow}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Come usare KXmlGuiWindow|

pre=[[Development/Tutorials/First_program_(it)|Tutorial 1 - Ciao Mondo]]|

next=[[Development/Tutorials/Using_KActions|Tutorial 3 - KActions and XMLGUI]]|

reading={{class|KXmlGuiWindow}}
}}

== Prefazione ==

Questo tutorial parte dal precedente [[Development/Tutorials/First_program_(it)|Ciao Mondo]] ed introdurrà la classe {{class|KXmlGuiWindow}}.

Nel precedente tutorial il programma faceva apparire una finestra di dialogo, ma ora faremo dei passi verso un programma funzionale.

[[Image:Kxmlguiwindow_tutorial2.png|frame|center]]

==KXmlGuiWindow==

{{class|KXmlGuiWindow}} provides a full main window view with menubars, toolbars, a statusbar and a main area in the centre for a large widget. Most KDE applications will derive from this class as it provides an easy way to define menu and toolbar layouts through XML files (this technology is called XMLGUI). While we will not be using XMLGUI in ''this'' tutorial, we will use it in the next.

In order to have a useful KXmlGuiWindow, we must subclass it. So we create two files, a <tt>mainwindow.cpp</tt> and a <tt>mainwindow.h</tt> which will contain our code.

===mainwindow.h===
<code cppqt n>
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <KXmlGuiWindow>
#include <KTextEdit>

class MainWindow : public KXmlGuiWindow
{
public:
MainWindow(QWidget *parent=0);

private:
KTextEdit* textArea;
};

#endif
</code>
First we Subclass KXmlGuiWindow on line 7 with <tt>class MainWindow : public KXmlGuiWindow</tt>.

Then we declare the constructor with <tt>MainWindow(QWidget *parent=0);</tt>.

And finally we declare a pointer to the object that will make up the bulk of our program. {{class|KTextEdit}} is a generic richtext editor with some KDE niceties like cursor auto-hiding.

===mainwindow.cpp===
<code cppqt n>
#include "mainwindow.h"

MainWindow::MainWindow(QWidget *parent) : KXmlGuiWindow(parent)
{
textArea = new KTextEdit();
setCentralWidget(textArea);
setupGUI();
}
</code>
First, of course, on line 1 we have to include the header file containing the class declaration.

On line 5, we initialise our text editor with an object. Then on line 6 we use KXmlGuiWindow's built-in setCentralWidget() function which tells the KXmlGuiWindow what should appear in the central section of the window.

Finally, KXmlGuiWindow::setupGUI() is called which does a lot of behind-the-scenes stuff and creates the default menu bars (Settings, Help).

==Back to main.cpp==
In order to actually run this window, we need to add a few lines in main.cpp:
===main.cpp===
<code cppqt n>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>

#include "mainwindow.h"

int main (int argc, char *argv[])
{
KAboutData aboutData( "tutorial2", 0,
ki18n("Tutorial 2"), "1.0",
ki18n("A simple text area"),
KAboutData::License_GPL,
ki18n("Copyright (c) 2007 Developer") );
KCmdLineArgs::init( argc, argv, &aboutData );

KApplication app;

MainWindow* window = new MainWindow();
window->show();

return app.exec();
}
</code>
The only new lines here (compared to Tutorial 1) are 5, 18 and 19. On line 18, we create our MainWindow object and then on line 19, we display it.

==CMake==
The best way to build the program is to use CMake. All that's changed since tutorial 1 is that <tt>mainwindow.cpp</tt> has been added to the sources list and any <tt>tutorial1</tt> has become <tt>tutorial2</tt>.
===CMakeLists.txt===
<code ini n>
project (tutorial2)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial2_SRCS
main.cpp
mainwindow.cpp
)

kde4_add_executable(tutorial2 ${tutorial2_SRCS})
target_link_libraries(tutorial2 ${KDE4_KDEUI_LIBS})
</code>

===Compile it===
To compile, link and run it, use:
mkdir build && cd build
cmake ..
make
./tutorial2

==Moving On==
Now you can move on to [[Development/Tutorials/Using_KActions|using KActions]].

[[Category:C++]]

File:Kxmlguiwindow tutorial2.png

2008-11-29T10:05:27Z

Fresbeeplayer:

Development/Tutorials/Using KXmlGuiWindow (it)

2008-11-29T09:58:13Z

Fresbeeplayer: Inizio - tradotto il tutorial browser

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Using_KXmlGuiWindow}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=How To Use KXmlGuiWindow|

pre=[[Development/Tutorials/First_program_(it)|Tutorial 1 - Ciao Mondo]]|

next=[[Development/Tutorials/Using_KActions|Tutorial 3 - KActions and XMLGUI]]|

reading={{class|KXmlGuiWindow}}
}}

==Abstract==
This tutorial carries on from [[Development/Tutorials/First_program|First Program Tutorial]] and will introduce the {{class|KXmlGuiWindow}} class.

In the previous tutorial, the program caused a dialog box to pop up but we're going to take steps towards a functioning application.

[[image:introtokdetutorial2.png|frame|center]]

==KXmlGuiWindow==

{{class|KXmlGuiWindow}} provides a full main window view with menubars, toolbars, a statusbar and a main area in the centre for a large widget. Most KDE applications will derive from this class as it provides an easy way to define menu and toolbar layouts through XML files (this technology is called XMLGUI). While we will not be using XMLGUI in ''this'' tutorial, we will use it in the next.

In order to have a useful KXmlGuiWindow, we must subclass it. So we create two files, a <tt>mainwindow.cpp</tt> and a <tt>mainwindow.h</tt> which will contain our code.

===mainwindow.h===
<code cppqt n>
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <KXmlGuiWindow>
#include <KTextEdit>

class MainWindow : public KXmlGuiWindow
{
public:
MainWindow(QWidget *parent=0);

private:
KTextEdit* textArea;
};

#endif
</code>
First we Subclass KXmlGuiWindow on line 7 with <tt>class MainWindow : public KXmlGuiWindow</tt>.

Then we declare the constructor with <tt>MainWindow(QWidget *parent=0);</tt>.

And finally we declare a pointer to the object that will make up the bulk of our program. {{class|KTextEdit}} is a generic richtext editor with some KDE niceties like cursor auto-hiding.

===mainwindow.cpp===
<code cppqt n>
#include "mainwindow.h"

MainWindow::MainWindow(QWidget *parent) : KXmlGuiWindow(parent)
{
textArea = new KTextEdit();
setCentralWidget(textArea);
setupGUI();
}
</code>
First, of course, on line 1 we have to include the header file containing the class declaration.

On line 5, we initialise our text editor with an object. Then on line 6 we use KXmlGuiWindow's built-in setCentralWidget() function which tells the KXmlGuiWindow what should appear in the central section of the window.

Finally, KXmlGuiWindow::setupGUI() is called which does a lot of behind-the-scenes stuff and creates the default menu bars (Settings, Help).

==Back to main.cpp==
In order to actually run this window, we need to add a few lines in main.cpp:
===main.cpp===
<code cppqt n>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>

#include "mainwindow.h"

int main (int argc, char *argv[])
{
KAboutData aboutData( "tutorial2", 0,
ki18n("Tutorial 2"), "1.0",
ki18n("A simple text area"),
KAboutData::License_GPL,
ki18n("Copyright (c) 2007 Developer") );
KCmdLineArgs::init( argc, argv, &aboutData );

KApplication app;

MainWindow* window = new MainWindow();
window->show();

return app.exec();
}
</code>
The only new lines here (compared to Tutorial 1) are 5, 18 and 19. On line 18, we create our MainWindow object and then on line 19, we display it.

==CMake==
The best way to build the program is to use CMake. All that's changed since tutorial 1 is that <tt>mainwindow.cpp</tt> has been added to the sources list and any <tt>tutorial1</tt> has become <tt>tutorial2</tt>.
===CMakeLists.txt===
<code ini n>
project (tutorial2)

find_package(KDE4 REQUIRED)
include_directories(${KDE4_INCLUDES})

set(tutorial2_SRCS
main.cpp
mainwindow.cpp
)

kde4_add_executable(tutorial2 ${tutorial2_SRCS})
target_link_libraries(tutorial2 ${KDE4_KDEUI_LIBS})
</code>

===Compile it===
To compile, link and run it, use:
mkdir build && cd build
cmake ..
make
./tutorial2

==Moving On==
Now you can move on to [[Development/Tutorials/Using_KActions|using KActions]].

[[Category:C++]]

User:Fresbeeplayer

2008-11-29T09:56:26Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

* [[Template:TutorialBrowser_(it)]]
* [[Development/Tutorials/First_program_(it)]]

== Work in Progress ==

* [[User:Fresbeeplayer/Development/Tutorials/Using_KXmlGuiWindow_(it)]]

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/Using_KActions]]

User:Fresbeeplayer

2008-11-29T09:42:35Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

* [[Template:TutorialBrowser_(it)]]
* [[Development/Tutorials/First_program_(it)]]

== Work in Progress ==

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/Using_KXmlGuiWindow | Using KXmlGuiWindow]]

User:Fresbeeplayer

2008-11-29T09:41:52Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

* [[Template:TutorialBrowser_(it)]]
* [[Development/Tutorials/First_program | Tutorial Hello World]]

== Work in Progress ==

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/Using_KXmlGuiWindow | Using KXmlGuiWindow]]

Development/Tutorials/First program (it)

2008-11-28T16:13:20Z

Fresbeeplayer: User:Fresbeeplayer/Development/Tutorials/First program (it) moved to Development/Tutorials/First program (it): Traduzione completa, programma funzionante

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

== Prefazione ==

Il tuo primo programma dovrebbe salutare il mondo con un amichevole "Ciao Mondo", giusto? Per farlo, useremo un {{class|KMessageBox}} personalizzando uno dei pulsanti.

[[image:Ciaomondo_tutorial1.png|frame|center]]

{{tip|Per avere più informazioni su qualunque classe che incontri, Konqueror offre una veloce scorciatoia. Per cercare informazioni circa KMessageBox, basta digitare "kde:kmessagebox" in Konqueror e sarai portato alla documentazione.}}

{{tip|Vorresti poter usare KDevelop per i tuoi progetti, il quale fa molte cose carine come il completamento del codice, facile accesso alla documentazione delle API, supporto per il debugging.
Leggi [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|questo tutorial]] per configurare KDevelop correttamente. Puoi controllare se il setup è andato a buon fine aprendo un'applicazione KDE4 esistente con KDevelop.
Tuttavia hai ancora bisogno di editare a mano i files di CMake.}}

== Il Codice ==

Tutto il codice di cui abbiamo bisogno starà in un file, <tt>main.cpp</tt>. Crealo con il codice qua sotto:

<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>
#include <QByteArray>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// Il nome del programma, usato internamente.
"tutorial1",
// Il nome nel catalogo messaggi.
// Se nullo, verrà usato il nome del programma.
0,
// Una stringa con il nome del programma.
// Quella che verrà effettivamente visualizzata.
ki18n("Tutorial 1"),
// La stringa con la versione del programma.
"1.0",
// Piccola descrizione su cosa fa il programma.
ki18n("Visualizza una finestra KMessageBox."),
// La licenza con la quale il codice è rilasciato.
KAboutData::License_GPL,
// Copyright
ki18n("(c) 2007"),
// Testo opzionale mostrato in "Informazioni su".
// Può contenere qualunque informazione desiderata.
ki18n("Un po' di testo..."),
// La stringa con la homepage del programma.
QByteArray("http://tutorial.com/"),
// L'indirizzo email per la segnalazione di bug.
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Ciao" ), QString(),
i18n( "Questo è un tooltip" ),
i18n( "Questo è un testo di aiuto CheCos'è?." ) );
KMessageBox::questionYesNo( 0, i18n( "Ciao Mondo" ),
i18n( "Ciao" ), yesButton );
return app.exec();
}
</code>

Il primo codice specifico di KDE che incontriamo in questo programma è {{class|KAboutData}}. Questa è la classe utilizzata per immagazzinare le informazioni sul programma, come ad esempio una piccola descrizione, gli autori, o le informazioni sulla licenza. Praticamente ogni applicazione KDE dovrebbe usare questa classe.

Poi arriviamo a {{class|KCmdLineArgs}}. Questa è la classe che si usa quando si vogliono specificare istruzioni da riga di comando per, ad esempio, aprire il programma con uno specifico file. Comunque, in questo tutorial, semplicemente lo inizializziamo con l'oggetto {{class|KAboutData}} che abbiamo appena creato, in modo da poter usare le opzioni <tt>--version</tt> o <tt>--author</tt>

Quindi adiamo a creare l'oggetto {{class|KApplication}}. Ciò bisogna farlo esattamente una volta in ogni programma, visto che è necessario per cose come l'[[Development/Tutorials/Localization/i18n|i18n]].

Ora che abbiamo finito con le operazioni indispensabili di KDE, possiamo cominciare a fare cose interessanti con la nostra applicazione. Creeremo una finestra pop-up, ma personalizzeremo uno dei pulsanti. Per la personalizzazione avremo bisogno di un oggetto {{class|KGuiItem}}. Il primo argomento del costruttore di {{class|KGuiItem}} è il testo che apparirà sull'oggetto (nel nostro caso, un pulsante). Quindi ci sarà un opzione per inserire un'icona, ma non ne vogliamo una così gli mettiamo <tt>QString</tt>. Impostiamo quindi il tooltip (quello che appare quando fermi il puntatore su un elemento) ed infine il testo "Che Cos'è?" (accessibile tramite click col tasto destro, con Shift-F1 oppure cliccando su "?" nella barra del titolo e poi sul pulsante "Ciao").

Ora che abbiamo il nostro pulsante, possiamo creare il nostro pop-up. Chiamiamo la funzione <tt>{{class|KMessageBox}}::questionYesNo()</tt> la quale, in modo predefinito, crea una finestra con due pulsanti "Si" e "No". Il secondo argomento compone il testo mostrato nella finestra sopra i due pulsanti. Il terzo è l'intestazione della finestra; e infine impostiamo il KGuiItem di (quello che normalmente è) il pulsante "Si" con il nostro <tt>KGuiItem yesButton</tt> appena creato.

Notare come tutto il testo visibile all'utente passa attraverso la funzione i18n(); questo è necessario per permettere la traduzione della UI. Più informazioni sulla localizzazione possono essere trovate nel [[Development/Tutorials/Localization/i18n|tutorial sulla localizzazione]].

Abbiamo finito per quanto riguarda il codice. Ora la compilazione e la prova.

== Compilazione ==

Vorrai usare [[Development/Tutorials/CMake|CMake]] come ambiente di compilazione. Devi fornire un file chiamato CMakeLists.txt, cmake usa questo file per generare tutti i Makefiles.

=== CMakeLists.txt ===

Crea un file di nome CMakeLists.txt nella stessa cartella di main.cpp con questo contenuto:

<code>
project (tutorial1)
find_package(KDE4 REQUIRED)
include (KDE4Defaults)
include_directories(${KDE4_INCLUDES})
set(tutorial1_SRCS main.cpp)
kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

La funzione <tt>find_package()</tt> trova tutti i pacchetti che hai richiesto (in questo caso KDE4) ed imposta alcune variabili che descrivono la posizione degli header e delle librerie del pacchetto. In questo caso useremo la variabile <tt>KDE4_INCLUDES</tt> contenente il percorso ai files header di KDE4.

Per permettere al compilatore di trovare questi files, passiamo quella variabile alla funzione <tt>include_directories()</tt> la quale aggiunge gli header di KDE4 al percorso di ricerca degli headr.

Poi creiamo una variabile chiamata <tt>tutorial1_SRCS</tt> con la funzione <tt>set()</tt>. In questo caso la impostiamo con il nome del nostro unico file sorgente.

Quindi usiamo <tt>kde4_add_executable()</tt> per creare un eseguibile chiamato <tt>tutorial1</tt> dai sorgenti elencati nella nostra variabile <tt>tutorial1_SRCS</tt>. In seguito, facciamo il link del nostro eseguibile alle librerie kdeui di KDE4 con <tt>target_link_libraries()</tt> e la variabile <tt>KDE4_KDEUI_LIBS</tt> precedentemente riempita dalla funzione <tt>find_package()</tt>. La riga che comincia con <tt>install</tt> scrive un target di default "install" dentro al Makefile.

=== Make ed Esecuzione ===

Puoi invocare CMake e make manualmente:

mkdir build && cd build
cmake .. # Nota questi due punti - non è una mancanza,
# stanno per "cartella superiore".
make

Oppure, se hai preparato il tuo ambiente come descritto in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], puoi compilare questo codice con:
cmakekde

Quindi lancialo con:
./tutorial1

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KXmlGuiWindow|usare KXmlGuiWindow]].

[[Category:C++]]

User:Fresbeeplayer/Development/Tutorials/First program (it)

2008-11-28T16:13:20Z

Fresbeeplayer: User:Fresbeeplayer/Development/Tutorials/First program (it) moved to Development/Tutorials/First program (it): Traduzione completa, programma funzionante

#REDIRECT [[Development/Tutorials/First program (it)]]

Talk:Development/Tutorials/First program

2008-11-28T16:03:44Z

Fresbeeplayer:

Adding authors to wiki pages seems counterintuitive to me. The wiki is editable by everybody. Why does it matter who the author of a tutorial is? IMHO the only thing that matters is that the tutorial is kept up to date. --[[User:Mattr|Mattr]] 03:31, 4 January 2007 (CET)

: I agree with Matt. I usually add a ''Initial Author:'' at the bottom for pages from the old developer wiki code, because they wrote it with often no explicit copyright information. See also [[Talk:Development/Architecture|this page]] --[[User:Dhaumann|Dhaumann]] 17:36, 4 January 2007 (CET)

== ‘ki18n’ was not declared in this scope ==

I don't know if this is the place to post this, but I tried to follow this tutorial and get an "error: ‘ki18n’ was not declared in this scope", when trying to compile using the big command gcc main.cpp ...

:Well I change a little the code so it now compiles under KDE4, it seems that the constructor of KAboutDate was changed...

== Build ==

Does the g++ command work for you as described?
I needed to add -lQtXml, lQtSvg and lQtNetwork.

: I'm getting a 'huge' string of error messages in the underlying include/ files, things like
<code>
include/KDE/../kmessagebox.h:1128: error: expected constructor, destructor, or type conversion before ‘(’ token
</code>
but hundreds, possibly thousands of errors apparently affecting nearly every header.
::I personally haven't tried the g++ method, that was added by someone else. Does linking against those libraries fix the errors? Does it work for you with the cmake method? --[[User:Milliams|milliams]] 20:47, 25 January 2008 (CET)
:::Thanks you, Milliams, it complies with cmake. I copied the g++ instructions, including the additional options, straight from the page and still no joy.

== Make and run before explaining the code ==

As far as I can see,
it presents the code,
explains it,
shows how to build with g++ (without cmake),
building with cmake,
finally running it

Well, I would prefer it to present code and run it (with no explaining), like to a monkey. After showing it works, explaining why it works or how it works.
I would find that much more fun this way.
Got any ideas why it should not be that way?
--Bogdan Bivolaru

== The constructor of KAboutData has changed ==

...or maybe not, I don't know, but in the API doc it is defined with the last two arguments as QByteArray datatype.
I was translating this tutorial in italian and, in order to solve this problem, I'd added QByteArray("string...") to the homepage and bugs mail arguments in the main.cpp code (with the right #include of course).
Now it build and run like a charm. Maybe it is needed to propagate this little mod over all the tutorial serie? --[[User:Fresbeeplayer|Fresbeeplayer]] 12:18, 28 November 2008 (UTC)

Talk:Development/Tutorials/First program

2008-11-28T12:19:25Z

Fresbeeplayer:

Adding authors to wiki pages seems counterintuitive to me. The wiki is editable by everybody. Why does it matter who the author of a tutorial is? IMHO the only thing that matters is that the tutorial is kept up to date. --[[User:Mattr|Mattr]] 03:31, 4 January 2007 (CET)

: I agree with Matt. I usually add a ''Initial Author:'' at the bottom for pages from the old developer wiki code, because they wrote it with often no explicit copyright information. See also [[Talk:Development/Architecture|this page]] --[[User:Dhaumann|Dhaumann]] 17:36, 4 January 2007 (CET)

== ‘ki18n’ was not declared in this scope ==

I don't know if this is the place to post this, but I tried to follow this tutorial and get an "error: ‘ki18n’ was not declared in this scope", when trying to compile using the big command gcc main.cpp ...

:Well I change a little the code so it now compiles under KDE4, it seems that the constructor of KAboutDate was changed...

== Build ==

Does the g++ command work for you as described?
I needed to add -lQtXml, lQtSvg and lQtNetwork.

: I'm getting a 'huge' string of error messages in the underlying include/ files, things like
<code>
include/KDE/../kmessagebox.h:1128: error: expected constructor, destructor, or type conversion before ‘(’ token
</code>
but hundreds, possibly thousands of errors apparently affecting nearly every header.
::I personally haven't tried the g++ method, that was added by someone else. Does linking against those libraries fix the errors? Does it work for you with the cmake method? --[[User:Milliams|milliams]] 20:47, 25 January 2008 (CET)
:::Thanks you, Milliams, it complies with cmake. I copied the g++ instructions, including the additional options, straight from the page and still no joy.

== Make and run before explaining the code ==

As far as I can see,
it presents the code,
explains it,
shows how to build with g++ (without cmake),
building with cmake,
finally running it

Well, I would prefer it to present code and run it (with no explaining), like to a monkey. After showing it works, explaining why it works or how it works.
I would find that much more fun this way.
Got any ideas why it should not be that way?
--Bogdan Bivolaru

== The constructor of KAboutData has changed ==

...or maybe not, I don't know, but in the API doc it is defined with the last two arguments of QByteArray datatype.
I was translating this tutorial in italian and, in order to solve this problem, I'd added QByteArray("string...") to the homepage and bugs mail in the main.cpp code (and the right #include of course).
Now it build and run like a charm. Maybe it is needed to spread this little mod over all the tutorial serie? --[[User:Fresbeeplayer|Fresbeeplayer]] 12:18, 28 November 2008 (UTC)

Talk:Development/Tutorials/First program

2008-11-28T12:18:58Z

Fresbeeplayer: /* The constructor of KAboutData has changed */ new section

Adding authors to wiki pages seems counterintuitive to me. The wiki is editable by everybody. Why does it matter who the author of a tutorial is? IMHO the only thing that matters is that the tutorial is kept up to date. --[[User:Mattr|Mattr]] 03:31, 4 January 2007 (CET)

: I agree with Matt. I usually add a ''Initial Author:'' at the bottom for pages from the old developer wiki code, because they wrote it with often no explicit copyright information. See also [[Talk:Development/Architecture|this page]] --[[User:Dhaumann|Dhaumann]] 17:36, 4 January 2007 (CET)

== ‘ki18n’ was not declared in this scope ==

I don't know if this is the place to post this, but I tried to follow this tutorial and get an "error: ‘ki18n’ was not declared in this scope", when trying to compile using the big command gcc main.cpp ...

:Well I change a little the code so it now compiles under KDE4, it seems that the constructor of KAboutDate was changed...

== Build ==

Does the g++ command work for you as described?
I needed to add -lQtXml, lQtSvg and lQtNetwork.

: I'm getting a 'huge' string of error messages in the underlying include/ files, things like
<code>
include/KDE/../kmessagebox.h:1128: error: expected constructor, destructor, or type conversion before ‘(’ token
</code>
but hundreds, possibly thousands of errors apparently affecting nearly every header.
::I personally haven't tried the g++ method, that was added by someone else. Does linking against those libraries fix the errors? Does it work for you with the cmake method? --[[User:Milliams|milliams]] 20:47, 25 January 2008 (CET)
:::Thanks you, Milliams, it complies with cmake. I copied the g++ instructions, including the additional options, straight from the page and still no joy.

== Make and run before explaining the code ==

As far as I can see,
it presents the code,
explains it,
shows how to build with g++ (without cmake),
building with cmake,
finally running it

Well, I would prefer it to present code and run it (with no explaining), like to a monkey. After showing it works, explaining why it works or how it works.
I would find that much more fun this way.
Got any ideas why it should not be that way?
--Bogdan Bivolaru

== The constructor of KAboutData has changed ==

...or maybe not, I don't know, but in the API doc it is defined with the last two arguments of QByteArray datatype.
I was translating this tutorial in italian and, in order to solve this problem, I'd added QByteArray("string...") to the homepage and bugs mail in the main.cpp code (and the right #include of course).
Now it build and run like a charm. Maybe it is needed to spread this little mod over all the tutorial serie? 
[[User:Fresbeeplayer|Fresbeeplayer]] 12:18, 28 November 2008 (UTC)

Development/Tutorials/First program (it)

2008-11-28T12:02:29Z

Fresbeeplayer: Sistemata l'inizializzazione di KAboutData - QByteArray

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

== Prefazione ==

Il tuo primo programma dovrebbe salutare il mondo con un amichevole "Ciao Mondo", giusto? Per farlo, useremo un {{class|KMessageBox}} personalizzando uno dei pulsanti.

[[image:Ciaomondo_tutorial1.png|frame|center]]

{{tip|Per avere più informazioni su qualunque classe che incontri, Konqueror offre una veloce scorciatoia. Per cercare informazioni circa KMessageBox, basta digitare "kde:kmessagebox" in Konqueror e sarai portato alla documentazione.}}

{{tip|Vorresti poter usare KDevelop per i tuoi progetti, il quale fa molte cose carine come il completamento del codice, facile accesso alla documentazione delle API, supporto per il debugging.
Leggi [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|questo tutorial]] per configurare KDevelop correttamente. Puoi controllare se il setup è andato a buon fine aprendo un'applicazione KDE4 esistente con KDevelop.
Tuttavia hai ancora bisogno di editare a mano i files di CMake.}}

== Il Codice ==

Tutto il codice di cui abbiamo bisogno starà in un file, <tt>main.cpp</tt>. Crealo con il codice qua sotto:

<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>
#include <QByteArray>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// Il nome del programma, usato internamente.
"tutorial1",
// Il nome nel catalogo messaggi.
// Se nullo, verrà usato il nome del programma.
0,
// Una stringa con il nome del programma.
// Quella che verrà effettivamente visualizzata.
ki18n("Tutorial 1"),
// La stringa con la versione del programma.
"1.0",
// Piccola descrizione su cosa fa il programma.
ki18n("Visualizza una finestra KMessageBox."),
// La licenza con la quale il codice è rilasciato.
KAboutData::License_GPL,
// Copyright
ki18n("(c) 2007"),
// Testo opzionale mostrato in "Informazioni su".
// Può contenere qualunque informazione desiderata.
ki18n("Un po' di testo..."),
// La stringa con la homepage del programma.
QByteArray("http://tutorial.com/"),
// L'indirizzo email per la segnalazione di bug.
QByteArray("submit@bugs.kde.org"));

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Ciao" ), QString(),
i18n( "Questo è un tooltip" ),
i18n( "Questo è un testo di aiuto CheCos'è?." ) );
KMessageBox::questionYesNo( 0, i18n( "Ciao Mondo" ),
i18n( "Ciao" ), yesButton );
return app.exec();
}
</code>

Il primo codice specifico di KDE che incontriamo in questo programma è {{class|KAboutData}}. Questa è la classe utilizzata per immagazzinare le informazioni sul programma, come ad esempio una piccola descrizione, gli autori, o le informazioni sulla licenza. Praticamente ogni applicazione KDE dovrebbe usare questa classe.

Poi arriviamo a {{class|KCmdLineArgs}}. Questa è la classe che si usa quando si vogliono specificare istruzioni da riga di comando per, ad esempio, aprire il programma con uno specifico file. Comunque, in questo tutorial, semplicemente lo inizializziamo con l'oggetto {{class|KAboutData}} che abbiamo appena creato, in modo da poter usare le opzioni <tt>--version</tt> o <tt>--author</tt>

Quindi adiamo a creare l'oggetto {{class|KApplication}}. Ciò bisogna farlo esattamente una volta in ogni programma, visto che è necessario per cose come l'[[Development/Tutorials/Localization/i18n|i18n]].

Ora che abbiamo finito con le operazioni indispensabili di KDE, possiamo cominciare a fare cose interessanti con la nostra applicazione. Creeremo una finestra pop-up, ma personalizzeremo uno dei pulsanti. Per la personalizzazione avremo bisogno di un oggetto {{class|KGuiItem}}. Il primo argomento del costruttore di {{class|KGuiItem}} è il testo che apparirà sull'oggetto (nel nostro caso, un pulsante). Quindi ci sarà un opzione per inserire un'icona, ma non ne vogliamo una così gli mettiamo <tt>QString</tt>. Impostiamo quindi il tooltip (quello che appare quando fermi il puntatore su un elemento) ed infine il testo "Che Cos'è?" (accessibile tramite click col tasto destro, con Shift-F1 oppure cliccando su "?" nella barra del titolo e poi sul pulsante "Ciao").

Ora che abbiamo il nostro pulsante, possiamo creare il nostro pop-up. Chiamiamo la funzione <tt>{{class|KMessageBox}}::questionYesNo()</tt> la quale, in modo predefinito, crea una finestra con due pulsanti "Si" e "No". Il secondo argomento compone il testo mostrato nella finestra sopra i due pulsanti. Il terzo è l'intestazione della finestra; e infine impostiamo il KGuiItem di (quello che normalmente è) il pulsante "Si" con il nostro <tt>KGuiItem yesButton</tt> appena creato.

Notare come tutto il testo visibile all'utente passa attraverso la funzione i18n(); questo è necessario per permettere la traduzione della UI. Più informazioni sulla localizzazione possono essere trovate nel [[Development/Tutorials/Localization/i18n|tutorial sulla localizzazione]].

Abbiamo finito per quanto riguarda il codice. Ora la compilazione e la prova.

== Compilazione ==

Vorrai usare [[Development/Tutorials/CMake|CMake]] come ambiente di compilazione. Devi fornire un file chiamato CMakeLists.txt, cmake usa questo file per generare tutti i Makefiles.

=== CMakeLists.txt ===

Crea un file di nome CMakeLists.txt nella stessa cartella di main.cpp con questo contenuto:

<code>
project (tutorial1)
find_package(KDE4 REQUIRED)
include (KDE4Defaults)
include_directories(${KDE4_INCLUDES})
set(tutorial1_SRCS main.cpp)
kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

La funzione <tt>find_package()</tt> trova tutti i pacchetti che hai richiesto (in questo caso KDE4) ed imposta alcune variabili che descrivono la posizione degli header e delle librerie del pacchetto. In questo caso useremo la variabile <tt>KDE4_INCLUDES</tt> contenente il percorso ai files header di KDE4.

Per permettere al compilatore di trovare questi files, passiamo quella variabile alla funzione <tt>include_directories()</tt> la quale aggiunge gli header di KDE4 al percorso di ricerca degli headr.

Poi creiamo una variabile chiamata <tt>tutorial1_SRCS</tt> con la funzione <tt>set()</tt>. In questo caso la impostiamo con il nome del nostro unico file sorgente.

Quindi usiamo <tt>kde4_add_executable()</tt> per creare un eseguibile chiamato <tt>tutorial1</tt> dai sorgenti elencati nella nostra variabile <tt>tutorial1_SRCS</tt>. In seguito, facciamo il link del nostro eseguibile alle librerie kdeui di KDE4 con <tt>target_link_libraries()</tt> e la variabile <tt>KDE4_KDEUI_LIBS</tt> precedentemente riempita dalla funzione <tt>find_package()</tt>. La riga che comincia con <tt>install</tt> scrive un target di default "install" dentro al Makefile.

=== Make ed Esecuzione ===

Puoi invocare CMake e make manualmente:

mkdir build && cd build
cmake .. # Nota questi due punti - non è una mancanza,
# stanno per "cartella superiore".
make

Oppure, se hai preparato il tuo ambiente come descritto in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], puoi compilare questo codice con:
cmakekde

Quindi lancialo con:
./tutorial1

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KXmlGuiWindow|usare KXmlGuiWindow]].

[[Category:C++]]

Development/Tutorials/First program (it)

2008-11-28T11:42:08Z

Fresbeeplayer: Sistemati i codici + altri dettagli

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

== Prefazione ==

Il tuo primo programma dovrebbe salutare il mondo con un amichevole "Ciao Mondo", giusto? Per farlo, useremo un {{class|KMessageBox}} personalizzando uno dei pulsanti.

[[image:Ciaomondo_tutorial1.png|frame|center]]

{{tip|Per avere più informazioni su qualunque classe che incontri, Konqueror offre una veloce scorciatoia. Per cercare informazioni circa KMessageBox, basta digitare "kde:kmessagebox" in Konqueror e sarai portato alla documentazione.}}

{{tip|Vorresti poter usare KDevelop per i tuoi progetti, il quale fa molte cose carine come il completamento del codice, facile accesso alla documentazione delle API, supporto per il debugging.
Leggi [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|questo tutorial]] per configurare KDevelop correttamente. Puoi controllare se il setup è andato a buon fine aprendo un'applicazione KDE4 esistente con KDevelop.
Tuttavia hai ancora bisogno di editare a mano i files di CMake.}}

== Il Codice ==

Tutto il codice di cui abbiamo bisogno starà in un file, <tt>main.cpp</tt>. Crealo con il codice qua sotto:

<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// Il nome del programma, usato internamente.
"tutorial1",
// Il nome nel catalogo messaggi.
// Se nullo, verrà usato il nome del programma.
0,
// Una stringa con il nome del programma.
// Quella che verrà effettivamente visualizzata.
ki18n("Tutorial 1"),
// La stringa con la versione del programma.
"1.0",
// Piccola descrizione su cosa fa il programma.
ki18n("Visualizza una finestra KMessageBox."),
// La licenza con la quale il codice è rilasciato.
KAboutData::License_GPL,
// Copyright
ki18n("(c) 2007"),
// Testo opzionale mostrato in "Informazioni su".
// Può contenere qualunque informazione desiderata.
ki18n("Un po' di testo..."),
// La stringa con la homepage del programma.
"http://tutorial.com/",
// L'indirizzo email per la segnalazione di bug.
"submit@bugs.kde.org");

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Ciao" ), QString(),
i18n( "Questo è un tooltip" ),
i18n( "Questo è un testo di aiuto CheCos'è?." ) );
KMessageBox::questionYesNo( 0, i18n( "Ciao Mondo" ),
i18n( "Ciao" ), yesButton );
return app.exec();
}
</code>

Il primo codice specifico di KDE che incontriamo in questo programma è {{class|KAboutData}}. Questa è la classe utilizzata per immagazzinare le informazioni sul programma, come ad esempio una piccola descrizione, gli autori, o le informazioni sulla licenza. Praticamente ogni applicazione KDE dovrebbe usare questa classe.

Poi arriviamo a {{class|KCmdLineArgs}}. Questa è la classe che si usa quando si vogliono specificare istruzioni da riga di comando per, ad esempio, aprire il programma con uno specifico file. Comunque, in questo tutorial, semplicemente lo inizializziamo con l'oggetto {{class|KAboutData}} che abbiamo appena creato, in modo da poter usare le opzioni <tt>--version</tt> o <tt>--author</tt>

Quindi adiamo a creare l'oggetto {{class|KApplication}}. Ciò bisogna farlo esattamente una volta in ogni programma, visto che è necessario per cose come l'[[Development/Tutorials/Localization/i18n|i18n]].

Ora che abbiamo finito con le operazioni indispensabili di KDE, possiamo cominciare a fare cose interessanti con la nostra applicazione. Creeremo una finestra pop-up, ma personalizzeremo uno dei pulsanti. Per la personalizzazione avremo bisogno di un oggetto {{class|KGuiItem}}. Il primo argomento del costruttore di {{class|KGuiItem}} è il testo che apparirà sull'oggetto (nel nostro caso, un pulsante). Quindi ci sarà un opzione per inserire un'icona, ma non ne vogliamo una così gli mettiamo <tt>QString</tt>. Impostiamo quindi il tooltip (quello che appare quando fermi il puntatore su un elemento) ed infine il testo "Che Cos'è?" (accessibile tramite click col tasto destro, con Shift-F1 oppure cliccando su "?" nella barra del titolo e poi sul pulsante "Ciao").

Ora che abbiamo il nostro pulsante, possiamo creare il nostro pop-up. Chiamiamo la funzione <tt>{{class|KMessageBox}}::questionYesNo()</tt> la quale, in modo predefinito, crea una finestra con due pulsanti "Si" e "No". Il secondo argomento compone il testo mostrato nella finestra sopra i due pulsanti. Il terzo è l'intestazione della finestra; e infine impostiamo il KGuiItem di (quello che normalmente è) il pulsante "Si" con il nostro <tt>KGuiItem yesButton</tt> appena creato.

Notare come tutto il testo visibile all'utente passa attraverso la funzione i18n(); questo è necessario per permettere la traduzione della UI. Più informazioni sulla localizzazione possono essere trovate nel [[Development/Tutorials/Localization/i18n|tutorial sulla localizzazione]].

Abbiamo finito per quanto riguarda il codice. Ora la compilazione e la prova.

== Compilazione ==

Vorrai usare [[Development/Tutorials/CMake|CMake]] come ambiente di compilazione. Devi fornire un file chiamato CMakeLists.txt, cmake usa questo file per generare tutti i Makefiles.

=== CMakeLists.txt ===

Crea un file di nome CMakeLists.txt nella stessa cartella di main.cpp con questo contenuto:

<code>
project (tutorial1)
find_package(KDE4 REQUIRED)
include (KDE4Defaults)
include_directories(${KDE4_INCLUDES})
set(tutorial1_SRCS main.cpp)
kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

La funzione <tt>find_package()</tt> trova tutti i pacchetti che hai richiesto (in questo caso KDE4) ed imposta alcune variabili che descrivono la posizione degli header e delle librerie del pacchetto. In questo caso useremo la variabile <tt>KDE4_INCLUDES</tt> contenente il percorso ai files header di KDE4.

Per permettere al compilatore di trovare questi files, passiamo quella variabile alla funzione <tt>include_directories()</tt> la quale aggiunge gli header di KDE4 al percorso di ricerca degli headr.

Poi creiamo una variabile chiamata <tt>tutorial1_SRCS</tt> con la funzione <tt>set()</tt>. In questo caso la impostiamo con il nome del nostro unico file sorgente.

Quindi usiamo <tt>kde4_add_executable()</tt> per creare un eseguibile chiamato <tt>tutorial1</tt> dai sorgenti elencati nella nostra variabile <tt>tutorial1_SRCS</tt>. In seguito, facciamo il link del nostro eseguibile alle librerie kdeui di KDE4 con <tt>target_link_libraries()</tt> e la variabile <tt>KDE4_KDEUI_LIBS</tt> precedentemente riempita dalla funzione <tt>find_package()</tt>. La riga che comincia con <tt>install</tt> scrive un target di default "install" dentro al Makefile.

=== Make ed Esecuzione ===

Puoi invocare CMake e make manualmente:

mkdir build && cd build
cmake .. # Nota questi due punti - non è una mancanza,
# stanno per "cartella superiore".
make

Oppure, se hai preparato il tuo ambiente come descritto in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], puoi compilare questo codice con:
cmakekde

Quindi lancialo con:
./tutorial1

== Continua ==

Ora puoi continuare verso [[Development/Tutorials/Using_KXmlGuiWindow|usare KXmlGuiWindow]].

[[Category:C++]]

Development/Tutorials/First program (it)

2008-11-28T11:35:33Z

Fresbeeplayer: Traduzione completa

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

== Prefazione ==

Il tuo primo programma dovrebbe salutare il mondo con un amichevole "Ciao Mondo", giusto? Per farlo, useremo un {{class|KMessageBox}} personalizzando uno dei pulsanti.
[[image:Ciaomondo_tutorial1.png|frame|center]]

{{tip|Per avere più informazioni su qualunque classe che incontri, Konqueror offre una veloce scorciatoia. Per cercare informazioni circa KMessageBox, basta digitare "kde:kmessagebox" in Konqueror e sarai portato alla documentazione.}}

{{tip|Vorresti poter usare KDevelop per i tuoi progetti, il quale fa molte cose carine come il completamento del codice, facile accesso alla documentazione delle API, supporto per il debugging.
Leggi [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|questo tutorial]] per configurare KDevelop correttamente. Puoi controllare se il setup è andato a buon fine aprendo un'applicazione KDE4 esistente con KDevelop.
Tuttavia hai ancora bisogno di editare a mano i files di CMake.}}

== Il Codice ==

Tutto il codice di cui abbiamo bisogno starà in un file, <tt>main.cpp</tt>. Crealo con il codice qua sotto:

<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// Il nome del programma, usato internamente.
"tutorial1",
// Il nome nel catalogo messaggi.
// Se nullo, verrà usato il nome del programma.
0,
// Una stringa con il nome del programma visualizzabile.
ki18n("Tutorial 1"),
// La stringa con la versione del programma.
"1.0",
// Piccola descrizione su cosa fa il programma.
ki18n("Visualizza una finestra KMessageBox."),
// La licenza sotto la quale questo codice è rilasciato.
KAboutData::License_GPL,
// Copyright
ki18n("(c) 2007"),
// Testo opzionale mostrato nella finestra "Informazioni su".
// Può contenere qualunque informazione desiderata.
ki18n("Un po' di testo..."),
// La stringa con la homepage del programma.
"http://tutorial.com/",
// L'indirizzo email per la segnalazione di bug.
"submit@bugs.kde.org");

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Ciao" ), QString(),
i18n( "Questo è un tooltip" ),
i18n( "Questo è un testo di aiuto CheCose'." ) );
KMessageBox::questionYesNo( 0, i18n( "Ciao Mondo" ),
i18n( "Ciao" ), yesButton );
return app.exec();
}
</code>

Il primo codice specifico di KDE che incontriamo in questo programma è {{class|KAboutData}}. Questa è la classe utilizzata per immagazzinare le informazioni sul programma, come ad esempio una piccola descrizione, gli autori, o le informazioni sulla licenza. Praticamente ogni applicazione KDE dovrebbe usare questa classe.

Poi arriviamo a {{class|KCmdLineArgs}}. Questa è la classe che si usa quando si vogliono specificare istruzioni da riga di comando per, ad esempio, aprire il programma con uno specifico file. Comunque, in questo tutorial, semplicemente lo inizializziamo con l'oggetto {{class|KAboutData}} che abbiamo appena creato, in modo da poter usare le opzioni <tt>--version</tt> o <tt>--author</tt>

Quindi adiamo a creare l'oggetto {{class|KApplication}}. Ciò bisogna farlo esattamente una volta in ogni programma, visto che è necessario per cose come l'[[Development/Tutorials/Localization/i18n|i18n]].

Ora che abbiamo finito con le operazioni indispensabili di KDE, possiamo cominciare a fare cose interessanti con la nostra applicazione. Creeremo una finestra pop-up, ma personalizzeremo uno dei pulsanti. Per la personalizzazione avremo bisogno di un oggetto {{class|KGuiItem}}. Il primo argomento del costruttore di {{class|KGuiItem}} è il testo che apparirà sull'oggetto (nel nostro caso, un pulsante). Quindi ci sarà un opzione per inserire un'icona, ma non ne vogliamo una così gli mettiamo <tt>QString</tt>. Impostiamo quindi il tooltip (quello che appare quando fermi il puntatore su un elemento) ed infine il testo "Che Cos'è?" (accessibile tramite click col tasto destro, con Shift-F1 oppure cliccando su "?" nella barra del titolo e poi sul pulsante "Ciao").

Ora che abbiamo il nostro pulsante, possiamo creare il nostro pop-up. Chiamiamo la funzione <tt>{{class|KMessageBox}}::questionYesNo()</tt> la quale, in modo predefinito, crea una finestra con due pulsanti "Si" e "No". Il secondo argomento compone il testo mostrato nella finestra sopra i due pulsanti. Il terzo è l'intestazione della finestra; e infine impostiamo il KGuiItem di (quello che normalmente è) il pulsante "Si" con il nostro <tt>KGuiItem yesButton</tt> appena creato.

Notare come tutto il testo visibile all'utente passa attraverso la funzione i18n(); questo è necessario per permettere la traduzione della UI. Più informazioni sulla localizzazione possono essere trovate nel [[Development/Tutorials/Localization/i18n|tutorial sulla localizzazione]].

Abbiamo finito per quanto riguarda il codice. Ora la compilazione e la prova.

== Compilazione ==

Vorrai usare [[Development/Tutorials/CMake|CMake]] come ambiente di compilazione. Devi fornire un file chiamato CMakeLists.txt, cmake usa questo file per generare tutti i Makefiles.

=== CMakeLists.txt ===

Crea un file di nome CMakeLists.txt nella stessa cartella di main.cpp con questo contenuto:

<code>
project (tutorial1)
find_package(KDE4 REQUIRED)
include (KDE4Defaults)
include_directories(${KDE4_INCLUDES})
set(tutorial1_SRCS main.cpp)
kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>

La funzione <tt>find_package()</tt> trova tutti i pacchetti che hai richiesto (in questo caso KDE4) ed imposta alcune variabili che descrivono la posizione degli header e delle librerie del pacchetto. In questo caso useremo la variabile <tt>KDE4_INCLUDES</tt> contenente il percorso ai files header di KDE4.

Per permettere al compilatore di trovare questi files, passiamo quella variabile alla funzione <tt>include_directories()</tt> la quale aggiunge gli header di KDE4 al percorso di ricerca degli headr.

Poi creiamo una variabile chiamata <tt>tutorial1_SRCS</tt> con la funzione <tt>set()</tt>. In questo caso la impostiamo con il nome del nostro unico file sorgente.

Quindi usiamo <tt>kde4_add_executable()</tt> per creare un eseguibile chiamato <tt>tutorial1</tt> dai sorgenti elencati nella nostra variabile <tt>tutorial1_SRCS</tt>. In seguito, facciamo il link del nostro eseguibile alle librerie kdeui di KDE4 con <tt>target_link_libraries()</tt> e la variabile <tt>KDE4_KDEUI_LIBS</tt> precedentemente riempita dalla funzione <tt>find_package()</tt>. La riga che comincia con <tt>install</tt> scrive un target di default "install" dentro al Makefile.

=== Make ed Esecuzione ===

Puoi invocare CMake e make manualmente:

mkdir build && cd build
cmake .. # Nota questi due punti - non è una mancanza, ma sta per "cartella superiore".
make

Oppure, se hai preparato il tuo ambiente come descritto in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], puoi compilare questo codice con:
cmakekde

Quindi lancialo con:
./tutorial1

== Continuare ==

Now you can move on to [[Development/Tutorials/Using_KXmlGuiWindow|using KXmlGuiWindow]].

Ora puoi continuare verso [[Development/Tutorials/Using_KXmlGuiWindow|usare KXmlGuiWindow]].

[[Category:C++]]

Development/Tutorials/First program (it)

2008-11-28T10:23:22Z

Fresbeeplayer: Prefazione + Immagine

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Tutorial per Principianti|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

== Prefazione ==

Il tuo primo programma dovrebbe salutare il mondo con un amichevole "Ciao Mondo", giusto? Per farlo, useremo un {{class|KMessageBox}} personalizzando uno dei pulsanti.
[[image:Ciaomondo_tutorial1.png|frame|center]]

{{tip|To get more information about any class you come across, Konqueror offers a quick shortcut. So to look for information about KMessageBox, just type "kde:kmessagebox" into Konqueror and you'll be taken to the documentation.}}

{{tip|
You might want to use KDevelop for your projects, which does many nice things like code completion, easy access to API documentation or debugging support.

Read [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|this tutorial]] to set up KDevelop correctly for this task. You probably want to check if the setup is working by testing opening an existing KDE 4 application with KDevelop first.

You still need to edit the CMake files by hand though.
}}

==The Code==
All the code we need will be in one file, <tt>main.cpp</tt>. Create that file with the code below:
<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// The program name used internally.
"tutorial1",
// The message catalog name
// If null, program name is used instead.
0,
// A displayable program name string.
ki18n("Tutorial 1"),
// The program version string.
"1.0",
// Short description of what the app does.
ki18n("Displays a KMessageBox popup"),
// The license this code is released under
KAboutData::License_GPL,
// Copyright Statement
ki18n("(c) 2007"),
// Optional text shown in the About box.
// Can contain any information desired.
ki18n("Some text..."),
// The program homepage string.
"http://tutorial.com/",
// The bug report email address
"submit@bugs.kde.org");

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Hello" ), QString(),
i18n( "This is a tooltip" ),
i18n( "This is a WhatsThis help text." ) );
KMessageBox::questionYesNo( 0, i18n( "Hello World" ),
i18n( "Hello" ), yesButton );
return app.exec();
}
</code>
The first KDE specific code we come across in this program is {{class|KAboutData}}. This is the class used to store information about the program such as a short description, authors or license information. Pretty much every KDE application should use this class.

Then we come to {{class|KCmdLineArgs}}. This is the class one would use to specify command line switches to, for example, open the program with a specific file. However, in this tutorial, we simply initialise it with the {{class|KAboutData}} object we created so we can use the <tt>--version</tt> or <tt>--author</tt> switches.

Then we create a {{class|KApplication}} object. This needs to be done exactly once in each program since it is needed for things such as [[Development/Tutorials/Localization/i18n|i18n]].

Now we've done all the necessary KDE setup, we can move on to doing interesting things with our application. We're going to create a popup box but we're going to customise one of the buttons. To do this customisation, we need to use a {{class|KGuiItem}} object. The first argument in the {{class|KGuiItem}} constructor is the text that will appear on the item (in our case, a button). Then we have an option of setting an icon for the button but we don't want one so we just give it <tt>QString()</tt>. We then set the tooltip (what appears when you hover over an item) and finally the "What's This?" (accessed through right-clicking or Shift-F1) text.

Now we have our item, we can create our popup. We call the <tt>{{class|KMessageBox}}::questionYesNo()</tt> function which, by default, creates a message box with a "Yes" and a "No" button. The second argument is the text that will appear in the message box above the buttons. The third is the caption the window will have and finally we set the KGuiItem for (what would normally be) the "Yes" button to the <tt>KGuiItem guiItem</tt> we created.

Note that all user-visible text is passed through the i18n() function; this is necessary for the UI to be translatable. More information on localization can be found in the [[Development/Tutorials/Localization/i18n|localization tutorial]].

We're all done as far as the code is concerned. Now to build it and try it out.

== Build ==
You want to [[Development/Tutorials/CMake|use CMake]] for your build environment. You provide a file CMakeLists.txt, cmake uses this file to generate all Makefiles out of it.

=== CMakeLists.txt ===
Create a file named CMakeLists.txt in the same directory as main.cpp with this content:
<code>
project (tutorial1)
find_package(KDE4 REQUIRED)
include (KDE4Defaults)
include_directories(${KDE4_INCLUDES})
set(tutorial1_SRCS main.cpp)
kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>
The <tt>find_package()</tt> function locates the package that you ask it for (in this case KDE4) and sets some variables describing the location of the package's headers and libraries. In this case we will use the <tt>KDE4_INCLUDES</tt> variable which contains the path to the KDE4 header files.

In order to allow the compiler to find these files, we pass that variable to the <tt>include_directories()</tt> function which adds the KDE4 headers to the header search path.

Next we create a variable called <tt>tutorial1_SRCS</tt> using the <tt>set()</tt> function. In this case we simply set it to the name of our only source file.

Then we use <tt>kde4_add_executable()</tt> to create an executable called <tt>tutorial1</tt> from the source files listed in our <tt>tutorial1_SRCS</tt> variable. Afterwards, we link our executable to the KDE4 kdeui library using <tt>target_link_libraries()</tt> and the <tt>KDE4_KDEUI_LIBS</tt> variable which was set by the <tt>find_package()</tt> function. The line starting with <tt>install</tt> writes a default "install" target into the Makefile.

=== Make And Run ===
You can invoke CMake and make manually:

mkdir build && cd build
cmake .. # Note the two dots - this is no ellipsis, but "parent directory".
make

Or, if you set up your environment as described in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], you can compile this code with:
cmakekde

And launch it with:
./tutorial1

==Moving On==
Now you can move on to [[Development/Tutorials/Using_KXmlGuiWindow|using KXmlGuiWindow]].

[[Category:C++]]

File:Ciaomondo tutorial1.png

2008-11-28T10:22:03Z

Fresbeeplayer:

Development/Tutorials/First program (it)

2008-11-28T10:02:26Z

Fresbeeplayer: Inizio -> creazione + tutorial browser in italiano

{{Template:I18n/Language Navigation Bar|Development/Tutorials/First_program}}
{{TutorialBrowser_(it)|

series=Beginner Tutorial|

name=Hello World|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt], [[Getting_Started/Build/KDE4|KDE4 development environment]]|

next=[[Development/Tutorials/Using_KXmlGuiWindow|Tutorial 2 - KXmlGuiWindow]]|

reading=[[Development/Tutorials/CMake|CMake]]
}}

==Abstract==
Your first program shall greet the world with a friendly "Hello World", what else? For that, we will use a {{class|KMessageBox}} and customise one of the buttons.
[[image:introtokdetutorial1.png|frame|center]]

{{tip|To get more information about any class you come across, Konqueror offers a quick shortcut. So to look for information about KMessageBox, just type "kde:kmessagebox" into Konqueror and you'll be taken to the documentation.}}

{{tip|
You might want to use KDevelop for your projects, which does many nice things like code completion, easy access to API documentation or debugging support.

Read [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|this tutorial]] to set up KDevelop correctly for this task. You probably want to check if the setup is working by testing opening an existing KDE 4 application with KDevelop first.

You still need to edit the CMake files by hand though.
}}

==The Code==
All the code we need will be in one file, <tt>main.cpp</tt>. Create that file with the code below:
<code cppqt>
#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>
#include <KMessageBox>

int main (int argc, char *argv[])
{
KAboutData aboutData(
// The program name used internally.
"tutorial1",
// The message catalog name
// If null, program name is used instead.
0,
// A displayable program name string.
ki18n("Tutorial 1"),
// The program version string.
"1.0",
// Short description of what the app does.
ki18n("Displays a KMessageBox popup"),
// The license this code is released under
KAboutData::License_GPL,
// Copyright Statement
ki18n("(c) 2007"),
// Optional text shown in the About box.
// Can contain any information desired.
ki18n("Some text..."),
// The program homepage string.
"http://tutorial.com/",
// The bug report email address
"submit@bugs.kde.org");

KCmdLineArgs::init( argc, argv, &aboutData );
KApplication app;
KGuiItem yesButton( i18n( "Hello" ), QString(),
i18n( "This is a tooltip" ),
i18n( "This is a WhatsThis help text." ) );
KMessageBox::questionYesNo( 0, i18n( "Hello World" ),
i18n( "Hello" ), yesButton );
return app.exec();
}
</code>
The first KDE specific code we come across in this program is {{class|KAboutData}}. This is the class used to store information about the program such as a short description, authors or license information. Pretty much every KDE application should use this class.

Then we come to {{class|KCmdLineArgs}}. This is the class one would use to specify command line switches to, for example, open the program with a specific file. However, in this tutorial, we simply initialise it with the {{class|KAboutData}} object we created so we can use the <tt>--version</tt> or <tt>--author</tt> switches.

Then we create a {{class|KApplication}} object. This needs to be done exactly once in each program since it is needed for things such as [[Development/Tutorials/Localization/i18n|i18n]].

Now we've done all the necessary KDE setup, we can move on to doing interesting things with our application. We're going to create a popup box but we're going to customise one of the buttons. To do this customisation, we need to use a {{class|KGuiItem}} object. The first argument in the {{class|KGuiItem}} constructor is the text that will appear on the item (in our case, a button). Then we have an option of setting an icon for the button but we don't want one so we just give it <tt>QString()</tt>. We then set the tooltip (what appears when you hover over an item) and finally the "What's This?" (accessed through right-clicking or Shift-F1) text.

Now we have our item, we can create our popup. We call the <tt>{{class|KMessageBox}}::questionYesNo()</tt> function which, by default, creates a message box with a "Yes" and a "No" button. The second argument is the text that will appear in the message box above the buttons. The third is the caption the window will have and finally we set the KGuiItem for (what would normally be) the "Yes" button to the <tt>KGuiItem guiItem</tt> we created.

Note that all user-visible text is passed through the i18n() function; this is necessary for the UI to be translatable. More information on localization can be found in the [[Development/Tutorials/Localization/i18n|localization tutorial]].

We're all done as far as the code is concerned. Now to build it and try it out.

== Build ==
You want to [[Development/Tutorials/CMake|use CMake]] for your build environment. You provide a file CMakeLists.txt, cmake uses this file to generate all Makefiles out of it.

=== CMakeLists.txt ===
Create a file named CMakeLists.txt in the same directory as main.cpp with this content:
<code>
project (tutorial1)
find_package(KDE4 REQUIRED)
include (KDE4Defaults)
include_directories(${KDE4_INCLUDES})
set(tutorial1_SRCS main.cpp)
kde4_add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
</code>
The <tt>find_package()</tt> function locates the package that you ask it for (in this case KDE4) and sets some variables describing the location of the package's headers and libraries. In this case we will use the <tt>KDE4_INCLUDES</tt> variable which contains the path to the KDE4 header files.

In order to allow the compiler to find these files, we pass that variable to the <tt>include_directories()</tt> function which adds the KDE4 headers to the header search path.

Next we create a variable called <tt>tutorial1_SRCS</tt> using the <tt>set()</tt> function. In this case we simply set it to the name of our only source file.

Then we use <tt>kde4_add_executable()</tt> to create an executable called <tt>tutorial1</tt> from the source files listed in our <tt>tutorial1_SRCS</tt> variable. Afterwards, we link our executable to the KDE4 kdeui library using <tt>target_link_libraries()</tt> and the <tt>KDE4_KDEUI_LIBS</tt> variable which was set by the <tt>find_package()</tt> function. The line starting with <tt>install</tt> writes a default "install" target into the Makefile.

=== Make And Run ===
You can invoke CMake and make manually:

mkdir build && cd build
cmake .. # Note the two dots - this is no ellipsis, but "parent directory".
make

Or, if you set up your environment as described in [[Getting_Started/Build/KDE4|Getting Started/Build/KDE4]], you can compile this code with:
cmakekde

And launch it with:
./tutorial1

==Moving On==
Now you can move on to [[Development/Tutorials/Using_KXmlGuiWindow|using KXmlGuiWindow]].

[[Category:C++]]

User:Fresbeeplayer

2008-11-28T10:01:16Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

* [[Template:TutorialBrowser_(it)]]

== Work in Progress ==

* [[Development/Tutorials/First_program | Tutorial Hello World]]

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/Using_KXmlGuiWindow | Using KXmlGuiWindow]]

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T23:02:57Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser_(it)|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QValueList<QualcheClasse> container;

// codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code>

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/view/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passaggio di tipi non POD ===

I tipi di dato diversi da POD ([http://en.wikipedia.org/wiki/Plain_old_data "Plain Old Data"], dati semplici senza la logica di controllo) dovrebbero essere passati sempre per riferimento costante. Questo include qualunque cosa tranne i tipi base come <tt>char</tt> e <tt>int</tt>.

Prendi, per esempio, {{qt|QString}}. Dovrebbero sempre essere passati ai metodi come <tt>const {{qt|QString}}&</tt>. Anche se {{qt|QString}} è implicitamente condiviso è comunque più efficiente (e sicuro) passarlo per referenza costante piuttosto che come oggetto per valore.

Quindi la dichiarazione canonica di un metodo che prende QString come argomento è:

<code cppqt>
void mioMetodo( const QString & x, const QString & y );
</code>

=== QObject ===

Se avrai mai bisogno di eliminare una classe derivata da QObject dall'interno di uno dei suoi metodi, non farlo mai in questo modo:

<code cppqt>
delete this;
</code>

Prima o poi ciò causerà un crash perché un metodo di quell'oggetto potrebbe essere invocato dal ciclo eventi delle Qt via slots/signals dopo che tu l'hai eliminato.

Invece usa sempre <tt>{{QtMethod|QObject|deleteLater}}</tt> il quale cerca di fare la stessa cosa di <tt>delete this</tt> ma in modo più sicuro.

=== QStrings vuote ===

Si è soliti voler verificare se un {{qt|QString}} è vuoto. Di seguito ci sono tre modi per farlo, dei quali i primi due sono corretti:

<code cppqt>
// Corretto
if ( miaStringa.isEmpty() ) {
}

// Corretto
if ( miaStringa == QString() ) {
}

// Sbagliato! ""
if ( miaStringa == "" ) {
}
</code>

Mentre c'è distinzione tra {{qt|QString}} nulle e vuote, ciò è puramente un artefatto storico e per il nuovo codice se ne scoraggia l'uso.

=== QString e lettura da file ===

Se stai leggendo un file, è più veloce convertirlo dalla codifica locale a Unicode ({{qt|QString}}) tutto in una volta, piuttosto che riga per riga. Questo vuol dire che metodi come <tt>{{qt|QIODevice}}::readAll()</tt> sono spesso una buona soluzione, seguiti da una singola istanza di {{qt|QString}}.

Per file molto grandi, considera la possibilità di leggere un blocco di righe e quindi eseguire la conversione. In questo modo hai l'opportunità di aggiornare la GUI. Ciò può essere fatto rientrando normalmente nel ciclo eventi, contemporaneamente utilizzando un timer per leggere i blocchi in background, oppure creando un ciclo eventi locale.

Anche se si potrebbe usare anche <tt>qApp->processEvents()</tt>, è scoraggiato siccome porta facilmente a subdoli problemi fatali.

=== Leggere QString da un KProcess ===

{{class|KProcess}} emette il segnale <tt>readyReadStandard{Output|Error}</tt> appena arrivano dei dati.
Un errore comune sta nel leggere tutti i dati disponibili nello slot connesso e convertirli in un {{qt|QString}} così come sono: i dati arrivano arbitrariamente segmentati, così caratteri multi-byte potrebbero essere tagliati in pezzi e perciò invalidati. Esistono molti approcci al problema:

* Hai veramente bisogno di processare i dati che arrivano? Se no, basta utilizzare <tt>readAllStandard{Output|Error}</tt> dopo che il processo è uscito. Diversamente da KDE3, KProcess è ora capace di accumulare i dati per te.
* Racchiudi il processo in un {{qt|QTextStream}} e leggi intere righe. Questo dovrebbe funzionare a partire dalle Qt 4.4
* Accumula i pezzi di dati negli slots e processali ogni volta che arriva una riga e dopo un certo timeout. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Codice di esempio]

=== QString e QByteArray ===

Mentre {{qt|QString}} è lo strumento scelto per molte situazioni che richiedono la gestione di stringhe, ce n'è una dove è particolarmente inefficiente. Se stai lavorando con dati in un {{qt|QByteArray}}, fai attenzione a non passarlo a metodi che prendono parametri di tipo {{qt|QString}}, e che ne tirano fuori un QByteArrays di nuovo.

Per esempio:

<code cppqt>
QByteArray mieiDati;
QString mieiNuoviDati = maciullaDati( mieiDati );

QString maciullaDati( const QString& dati ) {
QByteArray str = dati.toLatin1();
// maciulla
return QString(str);
}
</code>

L'operazione dispendiosa che si verifica è la conversione in {{qt|QString}}, la quale internamente fa conversioni a Unicode. Ciò è inutile perché la prima cosa che il metodo fa è riconvertirla di nuovo con <tt>toLatin1()</tt>. Quindi, se sei sicuro che la conversione a Unicode non è necessaria, cerca di evitare di usare inavvertitamente QString.

L'esempio di cui sopra dovrebbe invece essere scritto come:

<code cppqt>
QByteArray mieiDati;
QByteArray mieiNuoviDati = maciullaDati( mieiDati );

QByteArray maciullaDati( const QByteArray& dati )
</code>

=== QDomElement ===

Quando si deve fare il paring di documenti XML, si ha bisogno di iterare su tutti gli elementi. Potresti essere tentato di usare il seguente codice:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

Ebbene non è corretto: questo ciclo si fermerà prematuramente non appena incontra un {{qt|QDomNode}} che è qualcosa di diverso da un elemento, come un commento.

Il ciclo corretto è qualcosa di simile:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

Development/Tutorials/Common Programming Mistakes

2008-11-27T23:02:16Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Common Programming Mistakes|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Abstract ==

This tutorial aims to combine the experience of KDE developers regarding Qt and KDE frameworks dos and don'ts. Besides actual mistakes, it also covers things which are not necessarily "bugs" but which make the code either slower or less readable.

== General C++ ==

This section guides you through some of the more dusty corners of C++ which either tend to be misused or which people often simply get wrong.

=== Anonymous namespaces vs statics ===

If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely.

Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments.

So for now instead of using anonymous namespaces use static if you do not want a symbol to be exported.

=== NULL pointer issues ===

First and foremost: it is fine to delete a null pointer. So constructs like this that check for null before deleting are simply redundant:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Note however, that '''a null check ''is'' required when you delete an array''' - that's because a relatively recent compiler on Solaris does not handle it properly otherwise.

When you delete a pointer, make sure you also set it to 0 so that future attempts to delete that object will not fail in a double delete. So the complete and proper idiom is:

<code cppqt>
delete ptr;
ptr = 0;
</code>

You may notice that null pointers are marked variously in one of three ways: 0, 0L and NULL. In C, NULL is defined as a null void pointer. However, in C++, this is not possible due to stricter type checking. Therefore, modern C++ implementations define it to a "magic" null pointer constant which can be assigned to any pointer. Older C++ implementations, OTOH, simply defined it to 0L or 0, which provides no additional type safety - one could assign it to an integer variable, which is obviously wrong.

In pointer context, the integer constant zero means "null pointer" - irrespective of the actual binary representation of a null pointer. This means that the choice between 0, 0L and NULL is a question of personal style and getting used to something rather than a technical one - as far as the code in KDE's SVN goes you will see 0 used more commonly than NULL.

Note, however, that if you want to pass a null pointer constant to a function in a variable argument list, you *must* explicitly cast it to a pointer - the compiler assumes integer context by default, which might or might not match the binary representation of a pointer. Again, it does not matter whether you cast 0, 0L or NULL, but the shorter representation is generally preferred.

=== Member variables ===

You will encounter four major styles of marking class member variables in KDE:

* '''m_variable''' lowercase m, underscore and the name of the variable starting with a lowercase letter. This is the most common style and one prefered for code in kdelibs.
* '''mVariable''' lowercase m and the name of variable starting with a uppercase letter
* '''variable_''' variable name starting with a lowercase letter and then an underscore
* '''_variable''' underscore and the name of variable starting with a lowercase letter. This style is actually usually frowned upon as this notation is also used in some code for function parameters instead.

As it often happens there is not one correct way of doing it, so remember to always follow the syntax used by the application/library to which you are committing.

=== Static variables ===

Try to limit the number of static variables used in your code, especially when committing to a library. Construction and initialization of large number of static variables really hurts the startup times.

Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction.

Instead, use a static pointer, together with <tt>K_GLOBAL_STATIC</tt> which is defined in <tt>kglobal.h</tt> and is used like this:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globalA)

void doSomething()
{
A *a = globalA;
...
}

void doSomethingElse()
{
if (globalA.isDestroyed()) {
return;
}
A *a = globalA;
...
}

void installPostRoutine()
{
qAddPostRoutine(globalA.destroy);
}
</code>

See the [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 API documentation] for <tt>K_GLOBAL_STATIC</tt> for more information.

=== Constant data ===

If you need some constant data of simple data types in several places, you do good by defining it once at a central place, to avoid a mistype in one of the instances. If the data changes there is also only one place you need to edit.

Even if there is only one instance you do good by defining it elsewhere, to avoid so-called "magic numbers" in the code which are unexplained (cmp. 42). Usually this is done at the top of a file to avoid searching for it.

Define the constant data using the language constructs of C++, not the preprocessor instructions, like you may be used to from plain C. This way the compiler can help you to find mistakes by doing type checking.

<code cppqt>
// Correct!
static const int AnswerToAllQuestions = 42;
// Wrong!
#define AnswerToAllQuestions 42
</code>

If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read.

<code cppqt>
// Correct!
static const char SomeString[] = "Example";
// Wrong!
static const char* SomeString = "Example";
// Wrong!
#define SomeString "Example"
</code>

=== Forward Declarations ===

You will reduce compile times by forward declaring classes when possible instead of including their respective headers. For example:

<code cppqt>
#include <QWidget> // slow
#include <QStringList> // slow
#include <QString> // slow
class SomeInterface
{
public:
virtual void widgetAction( QWidget *widget ) =0;
virtual void stringAction( const QString& str ) =0;
virtual void stringListAction( const QStringList& strList ) =0;
};
</code>

The above should instead be written like this:

<code cppqt>
class QWidget; // fast
class QStringList; // fast
class QString; // fast
class SomeInterface
{
public:
virtual void widgetAction( QWidget *widget ) =0;
virtual void stringAction( const QString& str ) =0;
virtual void stringListAction( const QStringList& strList ) =0;
};
</code>

=== Iterators ===

==== Prefer const iterators and cache end() ====
Prefer to use <tt>const_iterators</tt> over normal iterators when possible. Containers, which are being implicitly shared often detach when a call to a non-const <tt>begin()</tt> or <tt>end()</tt> methods is made ({{qt|QList}} is an example of such a container). When using a const_iterator also watch out that you are really calling the const version of <tt>begin()</tt> and <tt>end()</tt>. Unless your container is actually const itself this probably will not be the case, possibly causing an unnecessary detach of your container. So basically whenever you use const_iterator initialize them using <tt>constBegin()</tt>/<tt>constEnd()</tt> instead, to be on the safe side.

Cache the return of the <tt>end()</tt> (or <tt>constEnd()</tt>) method call before doing iteration over large containers. For example:

<code cppqt>
QValueList<SomeClass> container;

//code which inserts a large number of elements to the container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

This avoids the unnecessary creation of the temporary <tt>end()</tt> (or <tt>constEnd()</tt>) return object on each loop iteration, largely speeding it up.

Prefer to use pre-increment over post-increment operators on iterators as this avoids creating an unnecessary temporary object in the process.

====Take care when erasing elements inside a loop====

When you want to erase some elements from the list, you maybe would use code similar to this:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

This code will potentially crash because it is a dangling iterator after the call to erase().
You have to rewrite the code this way:
<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>
This problem is also discussed in the [http://doc.trolltech.com/4.3/qmap-iterator.html#details Qt documentation for QMap::iterator] but applies to '''all''' Qt iterators

=== memory leaks ===

A very "popular" programming mistake is to do a <tt>new</tt> without a <tt>delete</tt> like in this program:

'''mem_gourmet.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void pollute()
{
t* polluter = new t();
}

int main()
{
while (true) pollute();
}
</code>

You see, ''pollute()'' instanciates a new object ''polluter'' of the class ''t''. Then, the variable ''polluter'' is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:
* keep the variable on the stack instead of the heap:
<code cppqt>
t* polluter = new t();
</code>
would become
<code cppqt>
t polluter();
</code>
* delete polluter using the complementing function to new:
<code cppqt>
delete polluter;
</code>

A tool to detect memory leaks like this is [[Development/Tools/Valgrind|Valgrind]].
=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:

* Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.
* Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.
* Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T22:53:20Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser_(it)|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QValueList<QualcheClasse> container;

// codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code>

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

posticipata?
Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/view/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passaggio di tipi non POD ===

I tipi di dato diversi da POD ([http://en.wikipedia.org/wiki/Plain_old_data "Plain Old Data"], dati semplici senza la logica di controllo) dovrebbero essere passati sempre per riferimento costante. Questo include qualunque cosa tranne i tipi base come <tt>char</tt> e <tt>int</tt>.

Prendi, per esempio, {{qt|QString}}. Dovrebbero sempre essere passati ai metodi come <tt>const {{qt|QString}}&</tt>. Anche se {{qt|QString}} è implicitamente condiviso è comunque più efficiente (e sicuro) passarlo per referenza costante piuttosto che come oggetto per valore.

Quindi la dichiarazione canonica di un metodo che prende QString come argomento è:

<code cppqt>
void mioMetodo( const QString & x, const QString & y );
</code>

=== QObject ===

Se avrai mai bisogno di eliminare una classe derivata da QObject dall'interno di uno dei suoi metodi, non farlo mai in questo modo:

<code cppqt>
delete this;
</code>

Prima o poi ciò causerà un crash perché un metodo di quell'oggetto potrebbe essere invocato dal ciclo eventi delle Qt via slots/signals dopo che tu l'hai eliminato.

Invece usa sempre <tt>{{QtMethod|QObject|deleteLater}}</tt> il quale cerca di fare la stessa cosa di <tt>delete this</tt> ma in modo più sicuro.

=== QStrings vuote ===

Si è soliti voler verificare se un {{qt|QString}} è vuoto. Di seguito ci sono tre modi per farlo, dei quali i primi due sono corretti:

<code cppqt>
// Corretto
if ( miaStringa.isEmpty() ) {
}

// Corretto
if ( miaStringa == QString() ) {
}

// Sbagliato! ""
if ( miaStringa == "" ) {
}
</code>

Mentre c'è distinzione tra {{qt|QString}} nulle e vuote, ciò è puramente un artefatto storico e per il nuovo codice se ne scoraggia l'uso.

=== QString e lettura da file ===

Se stai leggendo un file, è più veloce convertirlo dalla codifica locale a Unicode ({{qt|QString}}) tutto in una volta, piuttosto che riga per riga. Questo vuol dire che metodi come <tt>{{qt|QIODevice}}::readAll()</tt> sono spesso una buona soluzione, seguiti da una singola istanza di {{qt|QString}}.

Per file molto grandi, considera la possibilità di leggere un blocco di righe e quindi eseguire la conversione. In questo modo hai l'opportunità di aggiornare la GUI. Ciò può essere fatto rientrando normalmente nel ciclo eventi, contemporaneamente utilizzando un timer per leggere i blocchi in background, oppure creando un ciclo eventi locale.

Anche se si potrebbe usare anche <tt>qApp->processEvents()</tt>, è scoraggiato siccome porta facilmente a subdoli problemi fatali.

=== Leggere QString da un KProcess ===

{{class|KProcess}} emette il segnale <tt>readyReadStandard{Output|Error}</tt> appena arrivano dei dati.
Un errore comune sta nel leggere tutti i dati disponibili nello slot connesso e convertirli in un {{qt|QString}} così come sono: i dati arrivano arbitrariamente segmentati, così caratteri multi-byte potrebbero essere tagliati in pezzi e perciò invalidati. Esistono molti approcci al problema:

* Hai veramente bisogno di processare i dati che arrivano? Se no, basta utilizzare <tt>readAllStandard{Output|Error}</tt> dopo che il processo è uscito. Diversamente da KDE3, KProcess è ora capace di accumulare i dati per te.
* Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.
* Racchiudi il processo in un {{qt|QTextStream}} e leggi intere righe. Questo dovrebbe funzionare a partire dalle Qt 4.4
* Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]
* Accumula i pezzi di dati negli slots e processali ogni volta che arriva una riga e dopo un certo timeout. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Codice di esempio]

=== QString e QByteArray ===

Mentre {{qt|QString}} è lo strumento scelto per molte situazioni che richiedono la gestione di stringhe, ce n'è una dove è particolarmente inefficiente. Se stai lavorando con dati in un {{qt|QByteArray}}, fai attenzione a non passarlo a metodi che prendono parametri di tipo {{qt|QString}}, e che ne tirano fuori un QByteArrays di nuovo.

Per esempio:

<code cppqt>
QByteArray mieiDati;
QString mieiNuoviDati = maciullaDati( mieiDati );

QString maciullaDati( const QString& dati ) {
QByteArray str = dati.toLatin1();
// maciulla
return QString(str);
}
</code>

L'operazione dispendiosa che si verifica è la conversione in {{qt|QString}}, la quale internamente fa conversioni a Unicode. Ciò è inutile perché la prima cosa che il metodo fa è riconvertirla di nuovo con <tt>toLatin1()</tt>. Quindi, se sei sicuro che la conversione a Unicode non è necessaria, cerca di evitare di usare inavvertitamente QString.

L'esempio di cui sopra dovrebbe invece essere scritto come:

<code cppqt>
QByteArray mieiDati;
QByteArray mieiNuoviDati = maciullaDati( mieiDati );

QByteArray maciullaDati( const QByteArray& dati )
</code>

=== QDomElement ===

Quando si deve fare il paring di documenti XML, si ha bisogno di iterare su tutti gli elementi. Potresti essere tentato di usare il seguente codice:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

Ebbene non è corretto: questo ciclo si fermerà prematuramente non appena incontra un {{qt|QDomNode}} che è qualcosa di diverso da un elemento, come un commento.

Il ciclo corretto è qualcosa di simile:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer

2008-11-27T22:52:16Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

* [[Template:TutorialBrowser_(it)]]

== Work in Progress ==

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/First_program | Tutorial Hello World]]

Template:TutorialBrowser (it)

2008-11-27T22:51:20Z

Fresbeeplayer: User:Fresbeeplayer/Template:TutorialBrowser (it) moved to Template:TutorialBrowser (it): Traduzione completa e funzionante

<div class="rbroundbox" style="width:100%;">
<div class="rbtopwrap">
<div class="rbtop"><div></div></div>{{{name}}}</div>
<div class="rbcontent">
{|style="width:100%; background:#dadde0;"
|-
| width=10% align=right valign=top | '''Collezione di Tutorial'''  
| {{{series|n/a}}}
|-
| align=right valign=top | '''Prerequisiti'''  
| {{{pre|Nessuno}}}
|-
| align=right valign=top | '''A  Seguire'''  
| {{{next|n/a}}}
|-
| align=right valign=top | '''Ulteriori Letture'''  
|{{{reading|n/a}}}
|}
</div>
<div class="rbbot"><div></div></div>
</div>
[[Category:Tutorial]]<noinclude>

== Uso Raccomandato ==

Per tenere un qualche genere di consistenza nel nostro wiki: se userai questo template, mettilo in cima alla pagina, sopra qualunque ==testata== (ciò lo posizionerà sopra la sezione dei contenuti della pagina) così i lettori potranno trovare le informazioni il più velocemente possibile.

Nota anche che questo template aggiungerà automaticamente la pagina alla [[:Category:Tutorial|categoria tutorial]] in modo che non debba farlo tu stesso.

== Parametri ==

{| class="wikitable"
|-
! Parametro !! Funzione
|-
| '''series''' || Il nome della serie di tutorial a cui appartiene
|-
| '''name''' || Nome lungo di questo tutorial. Una specie di prefazione super corta.
|-
| '''pre''' || Qualsiasi prerequisito per questo tutorial (cerca di ordinarli in modo appropriato e assicurati che siano collegati!).
|-
| '''next''' || Un tutorial o due che seguono logicamente questo (nella stessa serie). Oppure un tutorial o due in cui ha senso proseguire.
|-
| '''reading''' || Ulteriori letture riguardo la materia di studio trattata in questo tutorial.
|-
|}

[[Category:Template]]
</noinclude>

User:Fresbeeplayer/Template:TutorialBrowser (it)

2008-11-27T22:51:20Z

Fresbeeplayer: User:Fresbeeplayer/Template:TutorialBrowser (it) moved to Template:TutorialBrowser (it): Traduzione completa e funzionante

#REDIRECT [[Template:TutorialBrowser (it)]]

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T22:49:52Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{User:Fresbeeplayer/Template:TutorialBrowser_(it)|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QValueList<QualcheClasse> container;

// codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code>

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

posticipata?
Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/view/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passaggio di tipi non POD ===

I tipi di dato diversi da POD ([http://en.wikipedia.org/wiki/Plain_old_data "Plain Old Data"], dati semplici senza la logica di controllo) dovrebbero essere passati sempre per riferimento costante. Questo include qualunque cosa tranne i tipi base come <tt>char</tt> e <tt>int</tt>.

Prendi, per esempio, {{qt|QString}}. Dovrebbero sempre essere passati ai metodi come <tt>const {{qt|QString}}&</tt>. Anche se {{qt|QString}} è implicitamente condiviso è comunque più efficiente (e sicuro) passarlo per referenza costante piuttosto che come oggetto per valore.

Quindi la dichiarazione canonica di un metodo che prende QString come argomento è:

<code cppqt>
void mioMetodo( const QString & x, const QString & y );
</code>

=== QObject ===

Se avrai mai bisogno di eliminare una classe derivata da QObject dall'interno di uno dei suoi metodi, non farlo mai in questo modo:

<code cppqt>
delete this;
</code>

Prima o poi ciò causerà un crash perché un metodo di quell'oggetto potrebbe essere invocato dal ciclo eventi delle Qt via slots/signals dopo che tu l'hai eliminato.

Invece usa sempre <tt>{{QtMethod|QObject|deleteLater}}</tt> il quale cerca di fare la stessa cosa di <tt>delete this</tt> ma in modo più sicuro.

=== QStrings vuote ===

Si è soliti voler verificare se un {{qt|QString}} è vuoto. Di seguito ci sono tre modi per farlo, dei quali i primi due sono corretti:

<code cppqt>
// Corretto
if ( miaStringa.isEmpty() ) {
}

// Corretto
if ( miaStringa == QString() ) {
}

// Sbagliato! ""
if ( miaStringa == "" ) {
}
</code>

Mentre c'è distinzione tra {{qt|QString}} nulle e vuote, ciò è puramente un artefatto storico e per il nuovo codice se ne scoraggia l'uso.

=== QString e lettura da file ===

Se stai leggendo un file, è più veloce convertirlo dalla codifica locale a Unicode ({{qt|QString}}) tutto in una volta, piuttosto che riga per riga. Questo vuol dire che metodi come <tt>{{qt|QIODevice}}::readAll()</tt> sono spesso una buona soluzione, seguiti da una singola istanza di {{qt|QString}}.

Per file molto grandi, considera la possibilità di leggere un blocco di righe e quindi eseguire la conversione. In questo modo hai l'opportunità di aggiornare la GUI. Ciò può essere fatto rientrando normalmente nel ciclo eventi, contemporaneamente utilizzando un timer per leggere i blocchi in background, oppure creando un ciclo eventi locale.

Anche se si potrebbe usare anche <tt>qApp->processEvents()</tt>, è scoraggiato siccome porta facilmente a subdoli problemi fatali.

=== Leggere QString da un KProcess ===

{{class|KProcess}} emette il segnale <tt>readyReadStandard{Output|Error}</tt> appena arrivano dei dati.
Un errore comune sta nel leggere tutti i dati disponibili nello slot connesso e convertirli in un {{qt|QString}} così come sono: i dati arrivano arbitrariamente segmentati, così caratteri multi-byte potrebbero essere tagliati in pezzi e perciò invalidati. Esistono molti approcci al problema:

* Hai veramente bisogno di processare i dati che arrivano? Se no, basta utilizzare <tt>readAllStandard{Output|Error}</tt> dopo che il processo è uscito. Diversamente da KDE3, KProcess è ora capace di accumulare i dati per te.
* Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.
* Racchiudi il processo in un {{qt|QTextStream}} e leggi intere righe. Questo dovrebbe funzionare a partire dalle Qt 4.4
* Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]
* Accumula i pezzi di dati negli slots e processali ogni volta che arriva una riga e dopo un certo timeout. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Codice di esempio]

=== QString e QByteArray ===

Mentre {{qt|QString}} è lo strumento scelto per molte situazioni che richiedono la gestione di stringhe, ce n'è una dove è particolarmente inefficiente. Se stai lavorando con dati in un {{qt|QByteArray}}, fai attenzione a non passarlo a metodi che prendono parametri di tipo {{qt|QString}}, e che ne tirano fuori un QByteArrays di nuovo.

Per esempio:

<code cppqt>
QByteArray mieiDati;
QString mieiNuoviDati = maciullaDati( mieiDati );

QString maciullaDati( const QString& dati ) {
QByteArray str = dati.toLatin1();
// maciulla
return QString(str);
}
</code>

L'operazione dispendiosa che si verifica è la conversione in {{qt|QString}}, la quale internamente fa conversioni a Unicode. Ciò è inutile perché la prima cosa che il metodo fa è riconvertirla di nuovo con <tt>toLatin1()</tt>. Quindi, se sei sicuro che la conversione a Unicode non è necessaria, cerca di evitare di usare inavvertitamente QString.

L'esempio di cui sopra dovrebbe invece essere scritto come:

<code cppqt>
QByteArray mieiDati;
QByteArray mieiNuoviDati = maciullaDati( mieiDati );

QByteArray maciullaDati( const QByteArray& dati )
</code>

=== QDomElement ===

Quando si deve fare il paring di documenti XML, si ha bisogno di iterare su tutti gli elementi. Potresti essere tentato di usare il seguente codice:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

Ebbene non è corretto: questo ciclo si fermerà prematuramente non appena incontra un {{qt|QDomNode}} che è qualcosa di diverso da un elemento, come un commento.

Il ciclo corretto è qualcosa di simile:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer

2008-11-27T22:46:30Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

== Work in Progress ==

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]
* [[User:Fresbeeplayer/Template:TutorialBrowser_(it) | Template:TutorialBrowser_(it)]]

== Who's Next ==

* [[Development/Tutorials/First_program | Tutorial Hello World]]

Template:TutorialBrowser (it)

2008-11-27T22:44:43Z

Fresbeeplayer: New page: <div class="rbroundbox" style="width:100%;"> <div class="rbtopwrap"> <div class="rbtop"><div></div></div>{{{name}}}</div> <div class="rbcontent"> {|style="width:100%; background:#dadde...

User:Fresbeeplayer

2008-11-27T22:13:43Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Done ==

== Work in Progress ==

=== to recheck ===

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/First_program | Tutorial Hello World]]

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T22:10:51Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QValueList<QualcheClasse> container;

// codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code>

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

posticipata?
Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/view/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passaggio di tipi non POD ===

I tipi di dato diversi da POD ([http://en.wikipedia.org/wiki/Plain_old_data "Plain Old Data"], dati semplici senza la logica di controllo) dovrebbero essere passati sempre per riferimento costante. Questo include qualunque cosa tranne i tipi base come <tt>char</tt> e <tt>int</tt>.

Prendi, per esempio, {{qt|QString}}. Dovrebbero sempre essere passati ai metodi come <tt>const {{qt|QString}}&</tt>. Anche se {{qt|QString}} è implicitamente condiviso è comunque più efficiente (e sicuro) passarlo per referenza costante piuttosto che come oggetto per valore.

Quindi la dichiarazione canonica di un metodo che prende QString come argomento è:

<code cppqt>
void mioMetodo( const QString & x, const QString & y );
</code>

=== QObject ===

Se avrai mai bisogno di eliminare una classe derivata da QObject dall'interno di uno dei suoi metodi, non farlo mai in questo modo:

<code cppqt>
delete this;
</code>

Prima o poi ciò causerà un crash perché un metodo di quell'oggetto potrebbe essere invocato dal ciclo eventi delle Qt via slots/signals dopo che tu l'hai eliminato.

Invece usa sempre <tt>{{QtMethod|QObject|deleteLater}}</tt> il quale cerca di fare la stessa cosa di <tt>delete this</tt> ma in modo più sicuro.

=== QStrings vuote ===

Si è soliti voler verificare se un {{qt|QString}} è vuoto. Di seguito ci sono tre modi per farlo, dei quali i primi due sono corretti:

<code cppqt>
// Corretto
if ( miaStringa.isEmpty() ) {
}

// Corretto
if ( miaStringa == QString() ) {
}

// Sbagliato! ""
if ( miaStringa == "" ) {
}
</code>

Mentre c'è distinzione tra {{qt|QString}} nulle e vuote, ciò è puramente un artefatto storico e per il nuovo codice se ne scoraggia l'uso.

=== QString e lettura da file ===

Se stai leggendo un file, è più veloce convertirlo dalla codifica locale a Unicode ({{qt|QString}}) tutto in una volta, piuttosto che riga per riga. Questo vuol dire che metodi come <tt>{{qt|QIODevice}}::readAll()</tt> sono spesso una buona soluzione, seguiti da una singola istanza di {{qt|QString}}.

Per file molto grandi, considera la possibilità di leggere un blocco di righe e quindi eseguire la conversione. In questo modo hai l'opportunità di aggiornare la GUI. Ciò può essere fatto rientrando normalmente nel ciclo eventi, contemporaneamente utilizzando un timer per leggere i blocchi in background, oppure creando un ciclo eventi locale.

Anche se si potrebbe usare anche <tt>qApp->processEvents()</tt>, è scoraggiato siccome porta facilmente a subdoli problemi fatali.

=== Leggere QString da un KProcess ===

{{class|KProcess}} emette il segnale <tt>readyReadStandard{Output|Error}</tt> appena arrivano dei dati.
Un errore comune sta nel leggere tutti i dati disponibili nello slot connesso e convertirli in un {{qt|QString}} così come sono: i dati arrivano arbitrariamente segmentati, così caratteri multi-byte potrebbero essere tagliati in pezzi e perciò invalidati. Esistono molti approcci al problema:

* Hai veramente bisogno di processare i dati che arrivano? Se no, basta utilizzare <tt>readAllStandard{Output|Error}</tt> dopo che il processo è uscito. Diversamente da KDE3, KProcess è ora capace di accumulare i dati per te.
* Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.
* Racchiudi il processo in un {{qt|QTextStream}} e leggi intere righe. Questo dovrebbe funzionare a partire dalle Qt 4.4
* Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]
* Accumula i pezzi di dati negli slots e processali ogni volta che arriva una riga e dopo un certo timeout. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Codice di esempio]

=== QString e QByteArray ===

Mentre {{qt|QString}} è lo strumento scelto per molte situazioni che richiedono la gestione di stringhe, ce n'è una dove è particolarmente inefficiente. Se stai lavorando con dati in un {{qt|QByteArray}}, fai attenzione a non passarlo a metodi che prendono parametri di tipo {{qt|QString}}, e che ne tirano fuori un QByteArrays di nuovo.

Per esempio:

<code cppqt>
QByteArray mieiDati;
QString mieiNuoviDati = maciullaDati( mieiDati );

QString maciullaDati( const QString& dati ) {
QByteArray str = dati.toLatin1();
// maciulla
return QString(str);
}
</code>

L'operazione dispendiosa che si verifica è la conversione in {{qt|QString}}, la quale internamente fa conversioni a Unicode. Ciò è inutile perché la prima cosa che il metodo fa è riconvertirla di nuovo con <tt>toLatin1()</tt>. Quindi, se sei sicuro che la conversione a Unicode non è necessaria, cerca di evitare di usare inavvertitamente QString.

L'esempio di cui sopra dovrebbe invece essere scritto come:

<code cppqt>
QByteArray mieiDati;
QByteArray mieiNuoviDati = maciullaDati( mieiDati );

QByteArray maciullaDati( const QByteArray& dati )
</code>

=== QDomElement ===

Quando si deve fare il paring di documenti XML, si ha bisogno di iterare su tutti gli elementi. Potresti essere tentato di usare il seguente codice:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

Ebbene non è corretto: questo ciclo si fermerà prematuramente non appena incontra un {{qt|QDomNode}} che è qualcosa di diverso da un elemento, come un commento.

Il ciclo corretto è qualcosa di simile:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T22:05:17Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QValueList<QualcheClasse> container;

// codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code>

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

posticipata?
Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/view/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passaggio di tipi non POD ===

I tipi di dato diversi da POD ([http://en.wikipedia.org/wiki/Plain_old_data "Plain Old Data"], dati semplici senza la logica di controllo) dovrebbero essere passati sempre per riferimento costante. Questo include qualunque cosa tranne i tipi base come <tt>char</tt> e <tt>int</tt>.

Prendi, per esempio, {{qt|QString}}. Dovrebbero sempre essere passati ai metodi come <tt>const {{qt|QString}}&</tt>. Anche se {{qt|QString}} è implicitamente condiviso è comunque più efficiente (e sicuro) passarlo per referenza costante piuttosto che come oggetto per valore.

Quindi la dichiarazione canonica di un metodo che prende QString come argomento è:

<code cppqt>
void mioMetodo( const QString & x, const QString & y );
</code>

=== QObject ===

Se avrai mai bisogno di eliminare una classe derivata da QObject dall'interno di uno dei suoi metodi, non farlo mai in questo modo:

<code cppqt>
delete this;
</code>

Prima o poi ciò causerà un crash perché un metodo di quell'oggetto potrebbe essere invocato dal ciclo eventi delle Qt via slots/signals dopo che tu l'hai eliminato.

Invece usa sempre <tt>{{QtMethod|QObject|deleteLater}}</tt> il quale cerca di fare la stessa cosa di <tt>delete this</tt> ma in modo più sicuro.

=== QStrings vuote ===

Si è soliti voler verificare se un {{qt|QString}} è vuoto. Di seguito ci sono tre modi per farlo, dei quali i primi due sono corretti:

<code cppqt>
// Corretto
if ( miaStringa.isEmpty() ) {
}

// Corretto
if ( miaStringa == QString() ) {
}

// Sbagliato! ""
if ( miaStringa == "" ) {
}
</code>

Mentre c'è distinzione tra {{qt|QString}} nulle e vuote, ciò è puramente un artefatto storico e per il nuovo codice se ne scoraggia l'uso.

=== QString e lettura da file ===

Se stai leggendo un file, è più veloce convertirlo dalla codifica locale a Unicode ({{qt|QString}}) tutto in una volta, piuttosto che riga per riga. Questo vuol dire che metodi come <tt>{{qt|QIODevice}}::readAll()</tt> sono spesso una buona soluzione, seguiti da una singola istanza di {{qt|QString}}.

Per file molto grandi, considera la possibilità di leggere un blocco di righe e quindi eseguire la conversione. In questo modo hai l'opportunità di aggiornare la GUI. Ciò può essere fatto rientrando normalmente nel ciclo eventi, contemporaneamente utilizzando un timer per leggere i blocchi in background, oppure creando un ciclo eventi locale.

Anche se si potrebbe usare anche <tt>qApp->processEvents()</tt>, è scoraggiato siccome porta facilmente a subdoli problemi fatali.

=== Leggere QString da un KProcess ===

{{class|KProcess}} emette il segnale <tt>readyReadStandard{Output|Error}</tt> appena arrivano dei dati.
Un errore comune sta nel leggere tutti i dati disponibili nello slot connesso e convertirli in un {{qt|QString}} così come sono: i dati arrivano arbitrariamente segmentati, così caratteri multi-byte potrebbero essere tagliati in pezzi e perciò invalidati. Esistono molti approcci al problema:

<ul>
<li>Hai veramente bisogno di processare i dati che arrivano? Se no, basta utilizzare <tt>readAllStandard{Output|Error}</tt> dopo che il processo è uscito. Diversamente da KDE3, KProcess è ora capace di accumulare i dati per te.</li>

<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Racchiudi il processo in un {{qt|QTextStream}} e leggi intere righe. Questo dovrebbe funzionare a partire dalle Qt 4.4</li>

<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>

<li>Accumula i pezzi di dati negli slots e processali ogni volta che arriva una riga e dopo un certo timeout. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Codice di esempio]</li>
</ul>

=== QString e QByteArray ===

Mentre {{qt|QString}} è lo strumento scelto per molte situazioni che richiedono la gestione di stringhe, ce n'è una dove è particolarmente inefficiente. Se stai lavorando con dati in un {{qt|QByteArray}}, fai attenzione a non passarlo a metodi che prendono parametri di tipo {{qt|QString}}, e che ne tirano fuori un QByteArrays di nuovo.

Per esempio:

<code cppqt>
QByteArray mieiDati;
QString mieiNuoviDati = maciullaDati( mieiDati );

QString maciullaDati( const QString& dati ) {
QByteArray str = dati.toLatin1();
// maciulla
return QString(str);
}
</code>

L'operazione dispendiosa che si verifica è la conversione in {{qt|QString}}, la quale internamente fa conversioni a Unicode. Ciò è inutile perché la prima cosa che il metodo fa è riconvertirla di nuovo con <tt>toLatin1()</tt>. Quindi, se sei sicuro che la conversione a Unicode non è necessaria, cerca di evitare di usare inavvertitamente QString.

L'esempio di cui sopra dovrebbe invece essere scritto come:

<code cppqt>
QByteArray mieiDati;
QByteArray mieiNuoviDati = maciullaDati( mieiDati );

QByteArray maciullaDati( const QByteArray& dati )
</code>

=== QDomElement ===

Quando si deve fare il paring di documenti XML, si ha bisogno di iterare su tutti gli elementi. Potresti essere tentato di usare il seguente codice:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

Ebbene non è corretto: questo ciclo si fermerà prematuramente non appena incontra un {{qt|QDomNode}} che è qualcosa di diverso da un elemento, come un commento.

Il ciclo corretto è qualcosa di simile:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T20:52:21Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QValueList<QualcheClasse> container;

// codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code>

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

posticipata?
Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/view/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passaggio di tipi non POD ===

I tipi di dato diversi da POD ([http://en.wikipedia.org/wiki/Plain_old_data | "Plain Old Data"], dati semplici senza la logica di controllo) dovrebbero essere passati sempre per riferimento costante. Questo include qualunque cosa tranne i tipi base come <tt>char</tt> e <tt>int</tt>.

Prendi, per esempio, {{qt|QString}}. Dovrebbero sempre essere passati ai metodi come <tt>const {{qt|QString}}&</tt>. Anche se {{qt|QString}} è implicitamente condiviso è comunque più efficiente (e sicuro) passarlo per referenza costante piuttosto che come oggetto per valore.

Quindi la dichiarazione canonica di un metodo che prende QString come argomento è:

<code cppqt>
void mioMetodo( const QString & x, const QString & y );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T18:46:30Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferisci l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator assicurati di stare chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>; altrimenti, a meno che il tuo container sia esso stesso costante, potrebbero esserci detach non necessari del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QValueList<QualcheClasse> container;

//codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<! -- approfondire timer e job -->

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
// Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code> -->

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

Puoi fare un dynamic_cast al tipo T dal tipo T2 tali che:

<! -- ricontrollare e approfondire
* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported -->
* T è definito in una libreria a cui fai il link (avrai un errore dal linker se non è così, dal momento che non troverà le informazioni vtable e RTTI)
* T è "ben-ancorato" in quella libreria. Con "ben-ancorato" intendo che vtable non è un simbolo COMUNE soggetto a fusioni a run-time da parte del linker dinamico. In altre parole, il primo membro virtuale nella definizione della classe deve esistere e non essere inline: deve essere in un file .cpp.
* T e T2 sono esportati.

Per esempio, noi abbiamo incontrato qualche problema difficile da individuare nel codice C++ non KDE (NMM credo) a cui stavamo facendo il link:
* libphonon carica il plugin NMM
* il plugin NMM fa il link a NMM
* NMM carica i suoi plugins
* i plugins propri di NMM, fanno il link a NMM

Qualche classe nella libreria di NMM non aveva vtables ben-ancorate, così il dynamic_casting falliva dentro al plugin NMM di Phonon per gli oggetti creatii nei plugins di NMM

== Progettazione delle applicazioni ==

In questa sezione copriremo un po' di problemi comuni relativi alla progettazione di applicazioni Qt/KDE.

=== Inizializzazione ritardata ===

posticipata?
Sebbene il design di moderne applicazioni C++ può essere molto complesso, un problema ricorrente, generalmente facile da sistemare, è il non usare la tecnica dell'[http://www.kdedevelopers.org/node/view/509 inizializzazione ritardata].

Per prima cosa, diamo un'occhiata al modo standard di inizializzare un'applicazione KDE:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Nota che <tt>window</tt> viene creata prima di <tt>a.exec()</tt> il quale fa partire il ciclo degli eventi. Ciò implica che vogliamo evitare di fare cose non banali nella parte alta del costruttore, visto che verranno eseguite prima ancora che la finestra venga mostrata.

La soluzione è semplice: abbiamo bisogno di ritardare la costruzione di qualunque cosa oltre alla GUI fino a che il ciclo degli eventi sia partito. Qui di seguito è mostrato come il costruttore della classe MainWindow dovrebbe essere per ottenere questo risultato:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Costruisci i tuoi widget qui. Nota che non devono
* richiedere una complessa inizializzazione,
* o verrà meno lo scopo di questa tecnica.
* Tutto ciò che vorresti fare è creare i tuoi oggetti
* della GUI ed usare QObject::connect per connettere
* i segnali agli slots appropriati.
*/
}

void MainWindow::initObject()
{
/* Questo slot sarà chiamato non appena parte il ciclo eventi.
* Metti tutto il resto che deve essere fatto, compresi
* assegnazione di valori, lettura files, ristebilire sessioni, etc...
* Tutto ciò prenderà lo stesso del tempo, ma almeno la tua
* finestra sarà visibile a schermo, facendo apparire
* attiva l'applicazione.
*/
}
</code>

Usare questa tecnica potrebbe non far risparmiare del tempo in più, ma farà ''sembrare'' più veloce l'applicazione agli utenti che la eseguono. Questa percezione di reattività incrementata è rassicurante per l'utente il quale riceve un rapido feedback per il riuscito avvio dell'applicazione.

Quando (e solo in questo caso) l'avvio non può essere reso ragionevolmente abbastanza veloce, considera l'uso di {{class|KSplashScreen}}.

== Strutture Dati ==

In questa sezione spazieremo su alcune delle nostre più comuni persecuzioni che affliggono le più comuni strutture dati viste nelle applicazioni Qt/KDE.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T15:10:50Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Prefazione ==

Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.

== C++ in generale ==

Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere mal utilizzati o dei quali la gente si sbaglia.

=== Namespace anonimi contro static ===

<! -- controllare il passaggio file-static
If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely. -->

Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.

<! -- un namespace anonimo non ha linkage interno?
Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments. -->

Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.

A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.

=== Problemi di puntatore Nullo ===

Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.

Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>

Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.

Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.

Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Variabili membro ===

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.

Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.

=== Variabili statiche ===

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.

<! -- ricontrollare
Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction. -->

Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.

Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>

Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.

=== Dati costanti ===

Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.

Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.

Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.

<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>

<! -- ricontrollare
If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read. -->

Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile con qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.

<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>

=== Dichiarazioni anticipate ===

Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:

<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

Dovrebbe invece essere scritto in questo modo:

<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>

=== Iteratori ===

==== Preferire iteratori costanti e conservare end() ====
Preferire l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator viene controllato anche che stai veramente chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>. A meno che il tuo container è esso stesso costante non sarà questo il caso, probabilmente causando un detach non necessario del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.

Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:

<code cppqt>
QValueList<QualcheClasse> container;

//codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.

Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.

==== Fai attenzione quando cancelli elementi dentro un ciclo ====

Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>

Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== Falle nella memoria ===

Un errore di programmazione molto "popolare" consiste nel fare un <tt>new</tt> senza un <tt>delete</tt> come in questo programma:

'''mem_buongustaio.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void inquina()
{
t* inquinatore = new t();
}

int main()
{
while (true) inquina();
}
</code>

Come puoi vedere, ''inquina()'' istanzia un nuovo oggetto ''inquinatore'' di tipo ''t''. Quindi, la variabile ''inquinatore'' viene persa dato che è locale, ma il contenuto (l'oggetto) rimane nello heap. Posso usare questo programma per rendere il mio computer inutilizzabile in 10 secondi.

Per risolvere, ci sono i seguenti approcci:
* tieni la variabile nello stack invece che nello heap:
<code cppqt>
t* inquinatore = new t();
</code>
diventerà
<code cppqt>
t inquinatore();
</code>
* cancella l'inquinatore usando la funzione complementare a new:
<code cppqt>
delete inquinatore;
</code> -->

Uno strumento per individuare le falle di memoria come queste è [[Development/Tools/Valgrind|Valgrind]].

=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T14:34:05Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}


== Prefazione ==



Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.


== C++ in generale ==



Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere usati male o dei quali la gente si sbaglia.


=== Namespace anonimi contro static ===



Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.



Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.



A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.


=== Problemi di puntatore Nullo ===



Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>



Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.



Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>



Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.



Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.



Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.


=== Variabili membro ===



Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.



Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.


=== Variabili statiche ===



Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.



Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.



Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:



<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>



Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.


=== Dati costanti ===



Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.



Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.



Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.



<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>



Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile che punta a qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.



<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>


=== Dichiarazioni anticipate ===



Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:



<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


Dovrebbe invece essere scritto in questo modo:



<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


=== Iteratori ===



==== Preferire iteratori costanti e conservare end() ====
Preferire l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator viene controllato anche che stai veramente chiamando la versione costante di <tt>begin()</tt> e <tt>end()</tt>. A meno che il tuo container è esso stesso costante non sarà questo il caso, probabilmente causando un detach non necessario del tuo container. Fondamentalmente ogni qual volta usi const_iterator inizializzalo usando <tt>constBegin()</tt>/<tt>constEnd()</tt>, per stare sul sicuro.



Conserva il valore di ritorno del metodo <tt>end()</tt> (o <tt>constEnd()</tt>) prima di iterare su un grande container. Per esempio:



<code cppqt>
QValueList<QualcheClasse> container;

//codice che inserisce un grande numero di elementi nel container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>



Questo evita la creazione non necessaria di un oggetto temporaneo ritornato da <tt>end()</tt> (o <tt>constEnd()</tt>) ad ogni iterazione del ciclo, velocizzandolo ampiamente.



Preferire l'uso degli incrementi prefissi piuttosto di quelli postfissi negli iteratori così da evitare inutili creazioni di oggetti temporanei nel processo.


==== Fai attenzione quando cancelli elementi dentro un ciclo ====



Quando vuoi cancellare qualche elemento dalla lista, vorresti usare codice simile a questo:



<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//Trovato un timer per questo job. Fermiamolo.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>



Questo codice può potenzialmente andare in crash a causa dell'iteratore pendente dopo la chiamata a erase().
Devi riscrivere il codice in questo modo:



<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//Trovato un timer per questo job. Fermiamolo.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>



Questo problema è anche discusso nella [http://doc.trolltech.com/4.3/qmap-iterator.html#details documentazione Qt di QMap::iterator] ma si applica a '''tutti''' gli iteratori delle Qt.

=== memory leaks ===

A very "popular" programming mistake is to do a <tt>new</tt> without a <tt>delete</tt> like in this program:

'''mem_gourmet.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void pollute()
{
t* polluter = new t();
}

int main()
{
while (true) pollute();
}
</code>

You see, ''pollute()'' instanciates a new object ''polluter'' of the class ''t''. Then, the variable ''polluter'' is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:
* keep the variable on the stack instead of the heap:
<code cppqt>
t* polluter = new t();
</code>
would become
<code cppqt>
t polluter();
</code>
* delete polluter using the complementing function to new:
<code cppqt>
delete polluter;
</code>

A tool to detect memory leaks like this is [[Development/Tools/Valgrind|Valgrind]].
=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

KDE TechBase:Contributors

2008-11-27T14:02:15Z

Fresbeeplayer: I've added myself to italian team

Welcome to the contributors page.

'''This site contains a list of ''active'' contributors. It should help to build teams which maintain KDE TechBase's content. If you have questions about KDE TechBase you can ask/email the corresponding person.'''

Please add yourself to the list where appropriate. If you are inactive, please remove yourself again.

== Administrators ==

This is a list of KDE TechBase administrators.

* [[User:Danimo|Danimo]]
* [[User:Dhaumann|Dhaumann]], <dhaumann at kde dot org>

== Reviewers and Article Writers ==

If you are continuously reviewing KDE TechBase changes or writing articles add yourself to the list.

* [[User:Dhaumann|Dhaumann]], <dhaumann at kde dot org>
* [[User:Milliams|Milliams]]
* name, <email>

== Translation Teams ==

KDE TechBase is [[Help:Wiki Translation|translated]] into many languages. If you translate pages please add yourself to the right translation team.

=== Chinese(simplified) Team ===
* [[User:Liangqi|Liangqi]], cavendish.qi at gmail dot com
* name, <email>

=== Spanish Team ===
* [[User:Martin J. Ponce|Martin J. Ponce]], mjp dot ttc at gmail dot com
* [[User:edumardo| Eduardo Delgado Díaz (edumardo)]], aesalemolo at gmail dot com
* name, <email>

=== German Team ===
* [[User:DrSlowDecay|DrSlowDecay]], kde at metalhorde dot de
* [[User:Rememberme|rememberme]] redict dot info at gmx dot net
* [[User:sschloenvoigt|Steffen Schloenvoigt]], steffen at schloenvoigt dot de
* name, <email>

=== Italian Team ===
* [[User:Thunder Teaser|Thunder Teaser]], totokid at gmail dot com
* [[User:Panda84|Panda84]], panda84 at inwind dot it
* [[User:Fresbeeplayer|Fresbeeplayer]], fresbeeplayer at gmail dot com
* name, <email>

=== Tamil Team ===
* [[User:Shriramadhas|Shriramadhas]], shriramadhas at gmail dot com
* name, <email>

=== ... Team ===
* name, <email>

User:Fresbeeplayer

2008-11-27T13:56:30Z

Fresbeeplayer:

In order to learn how to develop cool KDE application I've start from the beginning: I aim to translate all the tutorial that I'm facing with.

== Work in Progress ==

* [[User:Fresbeeplayer/Development/Tutorials/Common_Programming_Mistakes_(it) | Development/Tutorials/Common_Programming_Mistakes_(it)]]

== Who's Next ==

* [[Development/Tutorials/First_program | Tutorial Hello World]]

User:Fresbeeplayer/Translate ErroriProgrammazioneComuni

2008-11-27T13:10:52Z

Fresbeeplayer: Removing all content from page

User:Fresbeeplayer/Development/Tutorials/Common Programming Mistakes (it)

2008-11-27T13:10:33Z

Fresbeeplayer: New page: {{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}} {{TutorialBrowser| series=Getting Started| name=Errori di Programmazione Comuni| reading=[[P...

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}


== Prefazione ==



Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.


== C++ in generale ==



Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere usati male o dei quali la gente si sbaglia.


=== Namespace anonimi contro static ===



Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.



Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.



A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.


=== Problemi di puntatore Nullo ===



Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>



Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.



Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>



Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.



Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.



Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.


=== Variabili membro ===



Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.



Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.


=== Variabili statiche ===



Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.



Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.



Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:



<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>



Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.


=== Dati costanti ===



Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.



Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.



Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.



<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>



Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile che punta a qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.



<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>


=== Dichiarazioni anticipate ===



Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:



<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


Dovrebbe invece essere scritto in questo modo:



<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


=== Iteratori ===



==== Preferire iteratori costanti e conservare end() ====
Preferire l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso eseguono un detach() (vedi [http://doc.trolltech.com/4.4/shared.html#shared-classes] per più informazioni, n.d.t.) quando viene fatta una chiamata ad un metodo <tt>begin()</tt> o <tt>end()</tt> non costanti ({{qt|QList}} è un esempio di tale container). Usando i const_iterator viene controllato anche che stai veramente chiamando la versione costante di <tt>begin()</tt> <tt>end()</tt>.

Cache the return of the <tt>end()</tt> (or <tt>constEnd()</tt>) method call before doing iteration over large containers. For example:

<code cppqt>
QValueList<SomeClass> container;

//code which inserts a large number of elements to the container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

This avoids the unnecessary creation of the temporary <tt>end()</tt> (or <tt>constEnd()</tt>) return object on each loop iteration, largely speeding it up.

Prefer to use pre-increment over post-increment operators on iterators as this avoids creating an unnecessary temporary object in the process.

====Take care when erasing elements inside a loop====

When you want to erase some elements from the list, you maybe would use code similar to this:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

This code will potentially crash because it is a dangling iterator after the call to erase().
You have to rewrite the code this way:
<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>
This problem is also discussed in the [http://doc.trolltech.com/4.3/qmap-iterator.html#details Qt documentation for QMap::iterator] but applies to '''all''' Qt iterators

=== memory leaks ===

A very "popular" programming mistake is to do a <tt>new</tt> without a <tt>delete</tt> like in this program:

'''mem_gourmet.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void pollute()
{
t* polluter = new t();
}

int main()
{
while (true) pollute();
}
</code>

You see, ''pollute()'' instanciates a new object ''polluter'' of the class ''t''. Then, the variable ''polluter'' is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:
* keep the variable on the stack instead of the heap:
<code cppqt>
t* polluter = new t();
</code>
would become
<code cppqt>
t polluter();
</code>
* delete polluter using the complementing function to new:
<code cppqt>
delete polluter;
</code>

A tool to detect memory leaks like this is [[Development/Tools/Valgrind|Valgrind]].
=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Translate ErroriProgrammazioneComuni

2008-11-27T11:32:54Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}


== Prefazione ==



Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.


== C++ in generale ==



Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere usati male o dei quali la gente si sbaglia.


=== Namespace anonimi contro static ===



Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.



Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.



A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.


=== Problemi di puntatore Nullo ===



Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>



Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.



Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>



Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.



Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.



Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.


=== Variabili membro ===



Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.



Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.


=== Variabili statiche ===



Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.



Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.



Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:



<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>



Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.


=== Dati costanti ===



Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.



Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.



Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.



<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>



Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile che punta a qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.



<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>


=== Dichiarazioni anticipate ===



Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:



<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


Dovrebbe invece essere scritto in questo modo:



<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


=== Iteratori ===


<! --Prefer to use <tt>const_iterators</tt> over normal iterators when possible. Containers, which are being implicitly shared often detach when a call to a non-const <tt>begin()</tt> or <tt>end()</tt> methods is made ({{qt|QList}} is an example of such a container). When using a const_iterator also watch out that you are really calling the const version of <tt>begin()</tt> and <tt>end()</tt>. Unless your container is actually const itself this probably will not be the case, possibly causing an unnecessary detach of your container. So basically whenever you use const_iterator initialize them using <tt>constBegin()</tt>/<tt>constEnd()</tt> instead, to be on the safe side. -->

==== Preferire iteratori costanti e conservare end() ====
Preferire l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso

Cache the return of the <tt>end()</tt> (or <tt>constEnd()</tt>) method call before doing iteration over large containers. For example:

<code cppqt>
QValueList<SomeClass> container;

//code which inserts a large number of elements to the container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

This avoids the unnecessary creation of the temporary <tt>end()</tt> (or <tt>constEnd()</tt>) return object on each loop iteration, largely speeding it up.

Prefer to use pre-increment over post-increment operators on iterators as this avoids creating an unnecessary temporary object in the process.

====Take care when erasing elements inside a loop====

When you want to erase some elements from the list, you maybe would use code similar to this:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

This code will potentially crash because it is a dangling iterator after the call to erase().
You have to rewrite the code this way:
<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>
This problem is also discussed in the [http://doc.trolltech.com/4.3/qmap-iterator.html#details Qt documentation for QMap::iterator] but applies to '''all''' Qt iterators

=== memory leaks ===

A very "popular" programming mistake is to do a <tt>new</tt> without a <tt>delete</tt> like in this program:

'''mem_gourmet.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void pollute()
{
t* polluter = new t();
}

int main()
{
while (true) pollute();
}
</code>

You see, ''pollute()'' instanciates a new object ''polluter'' of the class ''t''. Then, the variable ''polluter'' is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:
* keep the variable on the stack instead of the heap:
<code cppqt>
t* polluter = new t();
</code>
would become
<code cppqt>
t polluter();
</code>
* delete polluter using the complementing function to new:
<code cppqt>
delete polluter;
</code>

A tool to detect memory leaks like this is [[Development/Tools/Valgrind|Valgrind]].
=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Translate ErroriProgrammazioneComuni

2008-11-27T11:31:37Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}


== Prefazione ==



Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.


== C++ in generale ==



Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere usati male o dei quali la gente si sbaglia.


=== Namespace anonimi contro static ===



Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.



Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.



A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.


=== Problemi di puntatore Nullo ===



Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>



Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.



Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>



Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.



Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.



Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.


=== Variabili membro ===



Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.



Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.


=== Variabili statiche ===



Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.



Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.



Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:



<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>



Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.


=== Dati costanti ===



Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.



Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.



Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.



<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>



Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile che punta a qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.



<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>


=== Dichiarazioni anticipate ===



Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:



<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


Dovrebbe invece essere scritto in questo modo:



<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


=== Iteratori ===



==== Preferire iteratori costanti e conservare end() ====
Preferire l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso

Cache the return of the <tt>end()</tt> (or <tt>constEnd()</tt>) method call before doing iteration over large containers. For example:

<code cppqt>
QValueList<SomeClass> container;

//code which inserts a large number of elements to the container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

This avoids the unnecessary creation of the temporary <tt>end()</tt> (or <tt>constEnd()</tt>) return object on each loop iteration, largely speeding it up.

Prefer to use pre-increment over post-increment operators on iterators as this avoids creating an unnecessary temporary object in the process.

====Take care when erasing elements inside a loop====

When you want to erase some elements from the list, you maybe would use code similar to this:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

This code will potentially crash because it is a dangling iterator after the call to erase().
You have to rewrite the code this way:
<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>
This problem is also discussed in the [http://doc.trolltech.com/4.3/qmap-iterator.html#details Qt documentation for QMap::iterator] but applies to '''all''' Qt iterators

=== memory leaks ===

A very "popular" programming mistake is to do a <tt>new</tt> without a <tt>delete</tt> like in this program:

'''mem_gourmet.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void pollute()
{
t* polluter = new t();
}

int main()
{
while (true) pollute();
}
</code>

You see, ''pollute()'' instanciates a new object ''polluter'' of the class ''t''. Then, the variable ''polluter'' is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:
* keep the variable on the stack instead of the heap:
<code cppqt>
t* polluter = new t();
</code>
would become
<code cppqt>
t polluter();
</code>
* delete polluter using the complementing function to new:
<code cppqt>
delete polluter;
</code>

A tool to detect memory leaks like this is [[Development/Tools/Valgrind|Valgrind]].
=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Translate ErroriProgrammazioneComuni

2008-11-27T11:30:14Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}


== Prefazione ==



Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle librerie Qt e KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bachi" ma che rendono il codice più lento e di difficile lettura.


== C++ in generale ==



Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere usati male o dei quali la gente si sbaglia.


=== Namespace anonimi contro static ===



Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.



Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.



A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.


=== Problemi di puntatore Nullo ===



Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>



Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.



Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>



Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.



Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.



Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.


=== Variabili membro ===

<! --You will encounter four major styles of marking class member variables in KDE:

* '''m_variable''' lowercase m, underscore and the name of the variable starting with a lowercase letter. This is the most common style and one prefered for code in kdelibs.
* '''mVariable''' lowercase m and the name of variable starting with a uppercase letter
* '''variable_''' variable name starting with a lowercase letter and then an underscore
* '''_variable''' underscore and the name of variable starting with a lowercase letter. This style is actually usually frowned upon as this notation is also used in some code for function parameters instead. -->

Incontrerai quattro maggiori stili per segnare le variabili membre delle classi in KDE:

* '''m_variabile''' m minuscola, underscore ed il nome della variabile che comincia con una lettera minuscola. Questo è lo stile più comune ed uno dei preferiti nel codice delle kdelibs.
* '''mVariabile''' m minuscola ed il nome della variabile che comincia con una lettera maiuscola.
* '''variabile_''' il nome della variabile comincia con la lettera minuscola ed alla fine un underscore.
* '''_variabile''' un underscore e poi il nome della variabile con la lettera iniziale minuscola. Questa notazione di solito è sconsigliata siccome è anche utilizzata in qualche codice per i parametri delle funzioni.



Come accade spesso non c'è un modo corretto per farlo, perciò ricorda sempre di rispettare la sintassi utilizzata dall'applicazione/libreria alla quale stai facendo commit.


=== Variabili statiche ===

<! --Try to limit the number of static variables used in your code, especially when committing to a library. Construction and initialization of large number of static variables really hurts the startup times. -->

Cerca di limitare il numero di variabili statiche nel tuo codice, specialmente quando fate il commit per una libreria. Costruzione ed inizializzazione di un grande numero di variabili statiche fa veramente male ai tempi di avvio.



Non usare variabili class-static, in particolare non nelle librerie e nei moduli sebbene sia anche scoraggiato nelle applicazioni. Oggetti statici portano ad un sacco di problemi tra cui difficoltà di debug dei crash dovuto ad un ordine indefinito di costruttore/distruttore.



Invece, usa un puntatore statico insieme a <tt>K_GLOBAL_STATIC</tt> definito in <tt>kglobal.h</tt> ed usato in questo modo:



<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globaleA)

void faQualcosa()
{
A *a = globaleA;
...
}

void faQualcosAltro()
{
if (globaleA.isDestroyed()) {
return;
}
A *a = globaleA;
...
}

void installaPostRoutine()
{
qAddPostRoutine(globaleA.destroy);
}
</code>



Vedi la [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 documentazione delle API] per più informazioni su <tt>K_GLOBAL_STATIC</tt>.


=== Dati costanti ===



Se hai bisogno di qualche dato costante per semplici tipi di dato in molti punti, fai bene a definirli una volta sola in un posto centrale, onde evitare errori di digitazione in una delle istanze. Se i dati cambiano hai bisogno di editare solo in un punto.



Anche se usati una sola volta è meglio definirli da un'altra parte, per evitare inspiegabili "numeri magici" nel codice (cmp. 42). Di solito ciò viene fatto in cima al file per non doverli ricercare.



Definisci i dati costanti usando i costrutti del C++, non le istruzioni del preprocessore, come potresti essere abituato a fare dal C. In questo modo il compilatore può aiutarti a trovare errori facendo il controllo di tipo.



<code cppqt>
// Corretto!
static const int LaRispostaATutteLeDomande = 42;
// Sbagliato!
#define LaRispostaATutteLeDomande 42
</code>



Se stai definendo un array costante non usare un puntatore come tipo di dato. Invece usa il suo tipo ed appendi il simbolo dell'array di indefinita lunghezza, <tt>[]</tt>, dopo il nome. Altrimenti definirai anche una variabile che punta a qualche dato costante. La variabile potrebbe per sbaglio essere assegnata ad un altro puntatore, senza che il compilatore se ne lamenti. E l'accesso all'array sarebbe indiretto, perché per primo deve essere letto il valore della variabile.



<code cppqt>
// Corretto!
static const char UnaStringa[] = "Esempio";
// Sbagliato!
static const char* UnaStringa = "Esempio";
// Sbagliato!
#define UnaStringa "Esempio"
</code>


=== Dichiarazioni anticipate ===



Ridurrai i tempi di compilazione dichiarando anticipatamente le classi quando possibile invece di includere i rispettivi headers. Per esempio:



<code cppqt>
#include <QWidget> // lento
#include <QStringList> // lento
#include <QString> // lento
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


Dovrebbe invece essere scritto in questo modo:



<code cppqt>
class QWidget; // veloce
class QStringList; // veloce
class QString; // veloce
class QualcheInterfaccia
{
public:
virtual void azioneWidget( QWidget *widget ) =0;
virtual void azioneStringa( const QString& str ) =0;
virtual void azioniListaStringhe( const QStringList& strLista ) =0;
};
</code>


=== Iteratori ===



==== Preferire iteratori costanti e conservare end() ====
Preferire l'uso dei <tt>const_iterators</tt> rispetto ai normali iteratori quando possibile. I containers, implicitamente condivisi, spesso

Cache the return of the <tt>end()</tt> (or <tt>constEnd()</tt>) method call before doing iteration over large containers. For example:

<code cppqt>
QValueList<SomeClass> container;

//code which inserts a large number of elements to the container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

This avoids the unnecessary creation of the temporary <tt>end()</tt> (or <tt>constEnd()</tt>) return object on each loop iteration, largely speeding it up.

Prefer to use pre-increment over post-increment operators on iterators as this avoids creating an unnecessary temporary object in the process.

====Take care when erasing elements inside a loop====

When you want to erase some elements from the list, you maybe would use code similar to this:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

This code will potentially crash because it is a dangling iterator after the call to erase().
You have to rewrite the code this way:
<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>
This problem is also discussed in the [http://doc.trolltech.com/4.3/qmap-iterator.html#details Qt documentation for QMap::iterator] but applies to '''all''' Qt iterators

=== memory leaks ===

A very "popular" programming mistake is to do a <tt>new</tt> without a <tt>delete</tt> like in this program:

'''mem_gourmet.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void pollute()
{
t* polluter = new t();
}

int main()
{
while (true) pollute();
}
</code>

You see, ''pollute()'' instanciates a new object ''polluter'' of the class ''t''. Then, the variable ''polluter'' is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:
* keep the variable on the stack instead of the heap:
<code cppqt>
t* polluter = new t();
</code>
would become
<code cppqt>
t polluter();
</code>
* delete polluter using the complementing function to new:
<code cppqt>
delete polluter;
</code>

A tool to detect memory leaks like this is [[Development/Tools/Valgrind|Valgrind]].
=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer/Translate ErroriProgrammazioneComuni

2008-11-27T00:10:14Z

Fresbeeplayer:

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Errori di Programmazione Comuni|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}


== Prefazione ==



Questo tutorial mira a combinare le esperienze degli sviluppatori KDE su cosa fare e cosa non fare in merito alle Qt ed al framework KDE. Oltre agli errori, vengono coperte anche cose che non sono necessariamente "bugs" ma che rendono il codice più lento e di difficile lettura.


== C++ in generale ==



Questa sezione ti guida attraverso alcuni degli angoli più remoti del C++ che tendono ad essere usati male o dei quali la gente si sbaglia.


=== Namespace anonimi contro static ===



Se hai un metodo in una classe che non accede ad alcun membro e quindi non ha bisogno di un oggetto per funzionare, rendilo statico. Se in più è una funzione di supporto privata che non viene utilizzata all'esterno del file, rendila file-static. In questo modo essa viene nascosta completamente.



Le entità definite in un namespace anonimo in C++ non hanno linkage interni. I namespace anonimi offrono soltanto un nome unico per quella translation unit e basta; non cambiano in nessun modo il linkage dell'identificatore. Il linkage non viene cambiato perché la seconda delle due fasi di ricerca dei nomi ignora le funzioni con linkage interno. Per di più, le entità con linkage interno non possono essere usate come argomento di un template.



A questo punto invece di usare namespace anonimi usa la parola chiave static se non vuoi che un simbolo venga esportato.


=== Problemi di puntatore Nullo ===



Prima di tutto: va bene eliminare un puntatore nullo. Quindi costruttori come il seguente che controllano che il valore sia nullo prima di eliminarlo sono semplicemente ridondanti:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>



Da notare comunque, che '''un controllo per valore nullo ''è'' richiesto quando cancelli un array''' - questo perché altrimenti un compilatore relativamente recente per Solaris non lo gestisce opportunamente.



Quando elimini un puntatore, assicurati anche di settarlo a 0 in modo che futuri tentativi di cancellazione non falliscano in una doppia eliminazione. Per cui il modo completo e corretto di procedere è:

<code cppqt>
delete ptr;
ptr = 0;
</code>



Potresti notare che i puntatori nulli sono variamente indicati in uno di questi tre modi: 0, 0L e NULL. In C, NULL è definito come un puntatore nullo di tipo void. Ma in C++ ciò non è possibile a causa di un controllo di tipo più stretto. Perciò, moderne implementazioni del C++ lo rendono come un "magico" puntatore nullo costante il quale può essere assegnato a qualunque altro puntatore. D'altra parte le implementazioni più vecchie di C++ semplicemente lo associano a 0 o 0L, il quale non tiene conto di alcuna sicurezza di tipo - si potrebbe assegnarlo ad una variabile intera, ovviamente sbagliando.



Nel contesto dei puntatori, la costante intera zero significa "puntatore nullo" - irrispettoso della rappresentazione binaria di un puntatore nullo. Ciò significa che la scelta tra 0, 0L e NULL è una questione di stile personale e abitudine piuttosto che tecnica - fintantoché nel codice SVN di KDE vedrai 0 usato più comunemente di NULL.



Notare, comunque, che se vuoi passare un puntatore nullo costante ad una funzione nella lista delle variabili degli argomenti, *devi* esplicitamente farne il cast in un puntatore - il compilatore assume di default il contesto degli interi, il quale può o non può coincidere con la rappresentazione binaria di un puntatore. Di nuovo, non ha importanza il fatto che fai il cast a 0, 0L o NULL, ma la rappresentazione più corta è generalmente preferita.

=== Member variables ===

You will encounter four major styles of marking class member variables in KDE:

* '''m_variable''' lowercase m, underscore and the name of the variable starting with a lowercase letter. This is the most common style and one prefered for code in kdelibs.
* '''mVariable''' lowercase m and the name of variable starting with a uppercase letter
* '''variable_''' variable name starting with a lowercase letter and then an underscore
* '''_variable''' underscore and the name of variable starting with a lowercase letter. This style is actually usually frowned upon as this notation is also used in some code for function parameters instead.

As it often happens there is not one correct way of doing it, so remember to always follow the syntax used by the application/library to which you are committing.

=== Static variables ===

Try to limit the number of static variables used in your code, especially when committing to a library. Construction and initialization of large number of static variables really hurts the startup times.

Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction.

Instead, use a static pointer, together with <tt>K_GLOBAL_STATIC</tt> which is defined in <tt>kglobal.h</tt> and is used like this:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globalA)

void doSomething()
{
A *a = globalA;
...
}

void doSomethingElse()
{
if (globalA.isDestroyed()) {
return;
}
A *a = globalA;
...
}

void installPostRoutine()
{
qAddPostRoutine(globalA.destroy);
}
</code>

See the [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 API documentation] for <tt>K_GLOBAL_STATIC</tt> for more information.

=== Constant data ===

If you need some constant data of simple data types in several places, you do good by defining it once at a central place, to avoid a mistype in one of the instances. If the data changes there is also only one place you need to edit.

Even if there is only one instance you do good by defining it elsewhere, to avoid so-called "magic numbers" in the code which are unexplained (cmp. 42). Usually this is done at the top of a file to avoid searching for it.

Define the constant data using the language constructs of C++, not the preprocessor instructions, like you may be used to from plain C. This way the compiler can help you to find mistakes by doing type checking.

<code cppqt>
// Correct!
static const int AnswerToAllQuestions = 42;
// Wrong!
#define AnswerToAllQuestions 42
</code>

If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read.

<code cppqt>
// Correct!
static const char SomeString[] = "Example";
// Wrong!
static const char* SomeString = "Example";
// Wrong!
#define SomeString "Example"
</code>

=== Forward Declarations ===

You will reduce compile times by forward declaring classes when possible instead of including their respective headers. For example:

<code cppqt>
#include <QWidget> // slow
#include <QStringList> // slow
#include <QString> // slow
class SomeInterface
{
public:
virtual void widgetAction( QWidget *widget ) =0;
virtual void stringAction( const QString& str ) =0;
virtual void stringListAction( const QStringList& strList ) =0;
};
</code>

The above should instead be written like this:

<code cppqt>
class QWidget; // fast
class QStringList; // fast
class QString; // fast
class SomeInterface
{
public:
virtual void widgetAction( QWidget *widget ) =0;
virtual void stringAction( const QString& str ) =0;
virtual void stringListAction( const QStringList& strList ) =0;
};
</code>

=== Iterators ===

==== Prefer const iterators and cache end() ====
Prefer to use <tt>const_iterators</tt> over normal iterators when possible. Containers, which are being implicitly shared often detach when a call to a non-const <tt>begin()</tt> or <tt>end()</tt> methods is made ({{qt|QList}} is an example of such a container). When using a const_iterator also watch out that you are really calling the const version of <tt>begin()</tt> and <tt>end()</tt>. Unless your container is actually const itself this probably will not be the case, possibly causing an unnecessary detach of your container. So basically whenever you use const_iterator initialize them using <tt>constBegin()</tt>/<tt>constEnd()</tt> instead, to be on the safe side.

Cache the return of the <tt>end()</tt> (or <tt>constEnd()</tt>) method call before doing iteration over large containers. For example:

<code cppqt>
QValueList<SomeClass> container;

//code which inserts a large number of elements to the container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

This avoids the unnecessary creation of the temporary <tt>end()</tt> (or <tt>constEnd()</tt>) return object on each loop iteration, largely speeding it up.

Prefer to use pre-increment over post-increment operators on iterators as this avoids creating an unnecessary temporary object in the process.

====Take care when erasing elements inside a loop====

When you want to erase some elements from the list, you maybe would use code similar to this:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

This code will potentially crash because it is a dangling iterator after the call to erase().
You have to rewrite the code this way:
<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>
This problem is also discussed in the [http://doc.trolltech.com/4.3/qmap-iterator.html#details Qt documentation for QMap::iterator] but applies to '''all''' Qt iterators

=== memory leaks ===

A very "popular" programming mistake is to do a <tt>new</tt> without a <tt>delete</tt> like in this program:

'''mem_gourmet.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void pollute()
{
t* polluter = new t();
}

int main()
{
while (true) pollute();
}
</code>

You see, ''pollute()'' instanciates a new object ''polluter'' of the class ''t''. Then, the variable ''polluter'' is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:
* keep the variable on the stack instead of the heap:
<code cppqt>
t* polluter = new t();
</code>
would become
<code cppqt>
t polluter();
</code>
* delete polluter using the complementing function to new:
<code cppqt>
delete polluter;
</code>

A tool to detect memory leaks like this is [[Development/Tools/Valgrind|Valgrind]].
=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>

User:Fresbeeplayer

2008-11-26T21:46:50Z

Fresbeeplayer:

Tutorial translating: English -> Italian

Working in progress: 
[[User:Fresbeeplayer/Translate_ErroriProgrammazioneComuni]]

Help:Contribute (it)

2008-11-26T21:20:33Z

Fresbeeplayer: cambiato il link a wikipedia in modo che punti alla sezione di editing in lingua italiana

{{Template:I18n/Language Navigation Bar|Help:Contribute}}

Il tuo contributo al wiki di KDE TechBase è ben accetto. Per ottenere contenuti e articoli di alta qualità ci sono un po' di linee guida che devi rispettare. Questa è una breve introduzione a come modificare e contribuire al wiki.

== I contenuti di KDE TechBase ==

Il wiki di KDE TechBase è pensato per contenere informazioni tecniche relative a KDE, ad esempio:
* informazioni per gli sviluppatori (ad esempio [[Development/Tutorials_(it)|tutorial]])
* [[KDE System Administration|amministrazione di sistema con KDE]]
* regole e piani di lavoro
* eccetera

Ulteriori dettagli possono essere trovati nell'articolo sulla [[Help:Wiki Structure|struttura del wiki]].

[http://docs.kde.org Documentazione per l'utente] o [http://api.kde.org documentazione delle API] ''non'' vanno aggiunte qui. Per questioni non tecniche usare [http://wiki.kde.org il wiki di KDE].

=== Dove inserire i nuovi articoli ===

Il wiki di KDE TechBase usa sottopagine. Dai una rapida occhiata all'articolo riguardo la [[Help:Wiki Structure|struttura del wiki]]. Per farla breve: non aggiungere a caso pagine nel livello più alto.

È possibile tradurre articoli di KDE TechBase in altre lingue. Leggi l'articolo riguardo la [[Help:Wiki Translation_(it)|traduzione del wiki]] per ulteriori dettagli.

=== La procedura ===

Vuoi aggiungere nuovo contenuto. Per mantenere alto lo standard di qualità per favore prima crea la pagina dell'articolo nella tua pagina personale (ad esempio User:foo/My Article). Una volta che è pronta, discuti l'articolo con altri sviluppatori e ricontrollala. Quando hai trovato il posto adatto dove inserirla sposta la pagina.

== Le basi della modifica ==

Nel wiki di KDE TechBase tutti gli utenti registrati possono modificare il contenuto e la struttura.

=== Regole di revisione e convenzioni ===

Assicurati che l'informazione che aggiungi sia rilevante al proposito specifico del wiki, in caso contrario i tuoi contenuti potrebbero essere rimossi. Puoi sempre usare le [[Help:Talk page|pagine di ''Discussione'' o ''Talk'']] per fare domande o assicurarti che la tua idea venga accettata. Per favore assicurati anche che i tuoi contributi non violino alcuna licenza.

=== Cominciare a modificare ===

Per cominciare a modificare una pagina di [[Main Page|KDE TechBase]] clicca su '''Modifica''' nella parte superiore del wiki. Verrai portato alla pagina di modifica: qui avrai a disposizione un'area di testo contenente il ''wikitext'' ovvero il codice modificabile da cui il server produce poi la pagina finale visibile all'utente. ''Se vuoi solo fare esperimenti puoi esercitarti nella [[Sandbox|sandbox]], non farlo qui''.

=== Inserire le modifiche ===

Per cominciare è sufficiente inserire il proprio testo. Per migliorare l'aspetto e l'ordine è necessario usare gli appositi comandi wiki, ad esempio per creare dei link o dare un'impaginazione migliore. Per favore usa lo stile utilizzato anche negli altri articoli del wiki. Se segui queste semplici regole i tuoi contributi saranno più utili in quanto non richiederanno successive ripuliture.

=== Riassumere le modifiche ===

Scrivi un breve riassunto nel piccolo campo sotto l'area di testo, ad esempio "Corretto un errore di ortografia."

=== Anteprima prima di salvare ===

Quando hai finito clicca su '''Visualizza anteprima''' per vedere come si presenteranno le tue modifiche '''prima''' di renderle permanenti. Ripeti il processo di modifica e anteprima finchè non sei soddisfatto, poi clicca su '''Salva la pagina''' e le tue modifiche saranno immediatamente applicate all'articolo.

== Pagina dei comandi Wiki ==

La wikipedia fornisce una rapida introduzione alla principale sintassi mediawiki. Per favore leggi l'apposita [http://it.wikipedia.org/wiki/Aiuto:Markup pagina di aiuto].

User:Fresbeeplayer

2008-11-26T21:11:15Z

Fresbeeplayer: New page: Tutorial translating: English -> Italian Working in progress: User:Fresbeeplayer/Translate_ErroriProgrammazioneComuni

Tutorial translating: English -> Italian

Working in progress:
[[User:Fresbeeplayer/Translate_ErroriProgrammazioneComuni]]

User:Fresbeeplayer/Translate ErroriProgrammazioneComuni

2008-11-26T20:33:39Z

Fresbeeplayer: Translate in progress...

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Common Programming Mistakes}}

{{TutorialBrowser|

series=Getting Started|

name=Common Programming Mistakes|

reading=[[Policies/API_to_Avoid|APIs to avoid]]

}}

== Abstract ==

This tutorial aims to combine the experience of KDE developers regarding Qt and KDE frameworks dos and don'ts. Besides actual mistakes, it also covers things which are not necessarily "bugs" but which make the code either slower or less readable.

== General C++ ==

This section guides you through some of the more dusty corners of C++ which either tend to be misused or which people often simply get wrong.

=== Anonymous namespaces vs statics ===

If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely.

Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments.

So for now instead of using anonymous namespaces use static if you do not want a symbol to be exported.

=== NULL pointer issues ===

First and foremost: it is fine to delete a null pointer. So constructs like this that check for null before deleting are simply redundant:

<code cppqt>
if ( ptr ) {
delete ptr;
}
</code>

Note however, that '''a null check ''is'' required when you delete an array''' - that's because a relatively recent compiler on Solaris does not handle it properly otherwise.

When you delete a pointer, make sure you also set it to 0 so that future attempts to delete that object will not fail in a double delete. So the complete and proper idiom is:

<code cppqt>
delete ptr;
ptr = 0;
</code>

You may notice that null pointers are marked variously in one of three ways: 0, 0L and NULL. In C, NULL is defined as a null void pointer. However, in C++, this is not possible due to stricter type checking. Therefore, modern C++ implementations define it to a "magic" null pointer constant which can be assigned to any pointer. Older C++ implementations, OTOH, simply defined it to 0L or 0, which provides no additional type safety - one could assign it to an integer variable, which is obviously wrong.

In pointer context, the integer constant zero means "null pointer" - irrespective of the actual binary representation of a null pointer. This means that the choice between 0, 0L and NULL is a question of personal style and getting used to something rather than a technical one - as far as the code in KDE's SVN goes you will see 0 used more commonly than NULL.

Note, however, that if you want to pass a null pointer constant to a function in a variable argument list, you *must* explicitly cast it to a pointer - the compiler assumes integer context by default, which might or might not match the binary representation of a pointer. Again, it does not matter whether you cast 0, 0L or NULL, but the shorter representation is generally preferred.

=== Member variables ===

You will encounter four major styles of marking class member variables in KDE:

* '''m_variable''' lowercase m, underscore and the name of the variable starting with a lowercase letter. This is the most common style and one prefered for code in kdelibs.
* '''mVariable''' lowercase m and the name of variable starting with a uppercase letter
* '''variable_''' variable name starting with a lowercase letter and then an underscore
* '''_variable''' underscore and the name of variable starting with a lowercase letter. This style is actually usually frowned upon as this notation is also used in some code for function parameters instead.

As it often happens there is not one correct way of doing it, so remember to always follow the syntax used by the application/library to which you are committing.

=== Static variables ===

Try to limit the number of static variables used in your code, especially when committing to a library. Construction and initialization of large number of static variables really hurts the startup times.

Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction.

Instead, use a static pointer, together with <tt>K_GLOBAL_STATIC</tt> which is defined in <tt>kglobal.h</tt> and is used like this:

<code cppqt>
class A { ... };

K_GLOBAL_STATIC(A, globalA)

void doSomething()
{
A *a = globalA;
...
}

void doSomethingElse()
{
if (globalA.isDestroyed()) {
return;
}
A *a = globalA;
...
}

void installPostRoutine()
{
qAddPostRoutine(globalA.destroy);
}
</code>

See the [http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdecore/html/kglobal_8h.html#75ca0c60b03dc5e4f9427263bf4043c7 API documentation] for <tt>K_GLOBAL_STATIC</tt> for more information.

=== Constant data ===

If you need some constant data of simple data types in several places, you do good by defining it once at a central place, to avoid a mistype in one of the instances. If the data changes there is also only one place you need to edit.

Even if there is only one instance you do good by defining it elsewhere, to avoid so-called "magic numbers" in the code which are unexplained (cmp. 42). Usually this is done at the top of a file to avoid searching for it.

Define the constant data using the language constructs of C++, not the preprocessor instructions, like you may be used to from plain C. This way the compiler can help you to find mistakes by doing type checking.

<code cppqt>
// Correct!
static const int AnswerToAllQuestions = 42;
// Wrong!
#define AnswerToAllQuestions 42
</code>

If defining a constant array do not use a pointer as data type. Instead use the data type and append the array symbol with undefined length, <tt>[]</tt>, behind the name. Otherwise you also define a variable to some const data. That variable could mistakenly be assigned a new pointer to, without the compiler complaining about. And accessing the array would have one indirection, because first the value of the variable needs to be read.

<code cppqt>
// Correct!
static const char SomeString[] = "Example";
// Wrong!
static const char* SomeString = "Example";
// Wrong!
#define SomeString "Example"
</code>

=== Forward Declarations ===

You will reduce compile times by forward declaring classes when possible instead of including their respective headers. For example:

<code cppqt>
#include <QWidget> // slow
#include <QStringList> // slow
#include <QString> // slow
class SomeInterface
{
public:
virtual void widgetAction( QWidget *widget ) =0;
virtual void stringAction( const QString& str ) =0;
virtual void stringListAction( const QStringList& strList ) =0;
};
</code>

The above should instead be written like this:

<code cppqt>
class QWidget; // fast
class QStringList; // fast
class QString; // fast
class SomeInterface
{
public:
virtual void widgetAction( QWidget *widget ) =0;
virtual void stringAction( const QString& str ) =0;
virtual void stringListAction( const QStringList& strList ) =0;
};
</code>

=== Iterators ===

==== Prefer const iterators and cache end() ====
Prefer to use <tt>const_iterators</tt> over normal iterators when possible. Containers, which are being implicitly shared often detach when a call to a non-const <tt>begin()</tt> or <tt>end()</tt> methods is made ({{qt|QList}} is an example of such a container). When using a const_iterator also watch out that you are really calling the const version of <tt>begin()</tt> and <tt>end()</tt>. Unless your container is actually const itself this probably will not be the case, possibly causing an unnecessary detach of your container. So basically whenever you use const_iterator initialize them using <tt>constBegin()</tt>/<tt>constEnd()</tt> instead, to be on the safe side.

Cache the return of the <tt>end()</tt> (or <tt>constEnd()</tt>) method call before doing iteration over large containers. For example:

<code cppqt>
QValueList<SomeClass> container;

//code which inserts a large number of elements to the container

QValueListConstIterator end( container.constEnd() );

for ( QValueListConstIterator itr( container.constBegin() );
itr != end; ++itr ) {
}
</code>

This avoids the unnecessary creation of the temporary <tt>end()</tt> (or <tt>constEnd()</tt>) return object on each loop iteration, largely speeding it up.

Prefer to use pre-increment over post-increment operators on iterators as this avoids creating an unnecessary temporary object in the process.

====Take care when erasing elements inside a loop====

When you want to erase some elements from the list, you maybe would use code similar to this:

<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
if(it.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(it.key());
m_activeTimers.erase(it);
}
}
</code>

This code will potentially crash because it is a dangling iterator after the call to erase().
You have to rewrite the code this way:
<code cppqt>
QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
QMap<int, Job *>::iterator prev = it;
++it;
if(prev.value() == job)
{
//A timer for this job has been found. Let's stop it.
killTimer(prev.key());
m_activeTimers.erase(prev);
}
}
</code>
This problem is also discussed in the [http://doc.trolltech.com/4.3/qmap-iterator.html#details Qt documentation for QMap::iterator] but applies to '''all''' Qt iterators

=== memory leaks ===

A very "popular" programming mistake is to do a <tt>new</tt> without a <tt>delete</tt> like in this program:

'''mem_gourmet.cpp'''
<code cppqt>
class t
{
public:
t() {}
};

void pollute()
{
t* polluter = new t();
}

int main()
{
while (true) pollute();
}
</code>

You see, ''pollute()'' instanciates a new object ''polluter'' of the class ''t''. Then, the variable ''polluter'' is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:
* keep the variable on the stack instead of the heap:
<code cppqt>
t* polluter = new t();
</code>
would become
<code cppqt>
t polluter();
</code>
* delete polluter using the complementing function to new:
<code cppqt>
delete polluter;
</code>

A tool to detect memory leaks like this is [[Development/Tools/Valgrind|Valgrind]].
=== dynamic_cast ===

You can only dynamic_cast to type T from type T2 provided
that:

* T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find
the vtable or RTTI info)
* T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.
* T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:
* libphonon loads the NMM plugin
* NMM plugin links to NMM
* NMM loads its own plugins
* NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

== Program Design ==

In this section we will go over some common problems related to the design of Qt/KDE applications.

=== Delayed Initialization ===

Although the design of modern C++ applications can be very complex, one recurring problem, which is generally easy to fix, is not using the technique of [http://www.kdedevelopers.org/node/view/509 delayed initialization].

First, let us look at the standard way of initializing a KDE application:

<code cppqt>
int main( int argc, char **argv )
{
....
KApplication a;

KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

MainWindow *window = new MainWindow( args );

a.setMainWidget( window );
window->show();

return a.exec();
}
</code>

Notice that <tt>window</tt> is created before the <tt>a.exec()</tt> call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

<code cppqt>
MainWindow::MainWindow()
{
initGUI();
QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
/* Construct your widgets here. Note that the widgets you
* construct here shouldn't require complex initialization
* either, or you've defeated the purpose.
* All you want to do is create your GUI objects and
* QObject::connect
* the appropriate signals to their slots.
*/
}

void MainWindow::initObject()
{
/* This slot will be called as soon as the event loop starts.
* Put everything else that needs to be done, including
* restoring values, reading files, session restoring, etc here.
* It will still take time, but at least your window will be
* on the screen, making your app look active.
*/
}
</code>

Using this technique may not buy you any overall time, but it makes your app ''seem'' quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a {{class|KSplashScreen}}.

== Data Structures ==

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

=== Passing non-POD types ===

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as <tt>char</tt> and <tt>int</tt>.

Take, for instance, {{qt|QString}}. They should always be passed into methods as <tt>const {{qt|QString}}&</tt>. Even though {{qt|QString}} is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

<code cppqt>
void myMethod( const QString & foo, const QString & bar );
</code>

=== QObject ===

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

<code cppqt>
delete this;
</code>

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use <tt>{{QtMethod|QObject|deleteLater}}</tt> which tries to do the same thing as <tt>delete this</tt> but in a safer way.

=== Empty QStrings ===

It is common to want to see if a {{qt|QString}} is empty. Here are three ways of doing it, the first two of which are correct:

<code cppqt>
// Correct
if ( mystring.isEmpty() ) {
}

// Correct
if ( mystring == QString() ) {
}

// Wrong! ""
if ( mystring == "" ) {
}
</code>

While there is a distinction between "null" {{qt|QString}}s and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

=== QString and reading files ===

If you are reading in a file, it is faster to convert it from the local encoding to Unicode ({{qt|QString}}) in one go, rather than line by line. This means that methods like <tt>{{qt|QIODevice}}::readAll()</tt> are often a good solution, followed by a single {{qt|QString}} instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use <tt>qApp->processEvents()</tt>, it is discouraged as it easily leads to subtle yet often fatal problems.

=== Reading QString from a KProcess ===

{{class|KProcess}} emits the signals <tt>readyReadStandard{Output|Error}</tt> as data comes in.
A common mistake is reading all available data in the connected slot and converting it to {{qt|QString}} right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:
<ul>
<li>Do you really need to process the data as it comes in? If not, just use <tt>readAllStandard{Output|Error}</tt> after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.</li>
<li>Wrap the process into a {{qt|QTextStream}} and read line-wise. This should work starting with Qt 4.4.</li>
<li>Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. [http://websvn.kde.org/trunk/KDE/kdevplatform/util/processlinemaker.cpp?view=markup Example code]</li>
</ul>

=== QString and QByteArray ===

While {{qt|QString}} is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in {{qt|QByteArray}}s, take care not to pass it through methods which take {{qt|QString}} parameters; then make QByteArrays from them again.

For example:

<code cppqt>
QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
QByteArray str = data.toLatin1();
// mangle
return QString(str);
}
</code>

The expensive thing happening here is the conversion to {{qt|QString}}, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using <tt>toLatin1()</tt>. So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

<code cppqt>
QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )
</code>

=== QDomElement ===

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

<code cppqt>
for ( QDomElement e = baseElement.firstChild().toElement();
!e.isNull();
e = e.nextSibling().toElement() ) {
...
}
</code>

That is not correct though: the above loop will stop prematurely when it encounters a {{qt|QDomNode}} that is something other than an element such as a comment.

The correct loop looks like:

<code cppqt>
for ( QDomNode n = baseElement.firstChild(); !n.isNull();
n = n.nextSibling() ) {
QDomElement e = n.toElement();
if ( e.isNull() ) {
continue;
}
...
}
</code>