Undolog.com

Quando non si lavora più da soli per tutti gli sviluppatori arriva il momento di trovare delle linee guida nella scrittura del codice. Protocolli e standard che permettano di “leggere” facilmente ed intervenire (sempre facilmente) nel codice altrui.
Quando su un progetto ci lavorano più programmatori, spesso su linguaggi diversi, è obbligatorio trovare una forma comune di scrittura, di standard nella documentazione interna ed esterna al codice. Nel mio lavoro mi trovo normalmente ad interagire con:

• Objetive-C, C/C++
• PHP
• HTML
• Javascript
• Actionscript
• CSS

Continua...

Ho pensato che potrebbe essere utile a chi si è avvicinato da poco allo sviluppo di applicazioni per Apple iPhone, confrontare Adobe Actionscript – il linguaggio utilizzato in Adobe Flash e Adobe Flex, più diffuso tra i neo-programmatori – e Objective-C, il linguaggio utilizzato da Apple per sviluppare le sue applicazioni. Objective-C è a tutti gli effetti un linguaggio ad oggetti nel senso puro, non che Actionscript non lo sia, ma Objective-C ha sicuramente una marcia in più in quanto è un’estensione dell’ANSI C e la sua sintassi è un mix tra C/C++ e Smalltalk; è un vero OO (Object-oriented language).

Continua...

Da oggi inauguro una nuova sezione (categoria per essere corretti) dedicata allo sviluppo di applicazioni su Apple iPhone! Premetto da subito che molti degli articoli che pubblicherò avranno un “taglio” in linea con lo spirito di questo blog, cioè saranno in maggioranza per utenti avanzati. Tuttavia, come ho già fatto per altri argomenti, cercherò di essere il più chiaro possibile e, dove necessario, inserire qualche “concetto base” utile ad un pubblico più ampio.

Continua...

Chi sviluppa sa bene che una delle caratteristiche delle funzioni (function () ) è quella di avere o meno degli argomenti di input. Può capitare, a volte, di dover scrivere una funzione che, in base ai parametri di input, si comporta in modo differente (in programmazione OO troviamo questo comportamento indicato come poliformismo). I parametri variabili (varargs), introdotti già all’epoca del C e presenti di default nella classica dichiarazione del main:

Continua...

Ho “riesumato” questo mio articolo scritto un po’ di anni fa. L’ho leggermente rivisto, aggiornando qualcosina qua e là, tuttavia credo sia ancora attuale ed interessante.

INTRODUZIONE

Che cos’è un linguaggio di sviluppo? Un elaboratore elettronico, alias PC (Personal Computer), ha un suo linguaggio personale. Questo linguaggio viene chiamato codice macchina, per intendere che ogni macchina, quindi ogni elaboratore (PC Compatibili, Apple, Unix, ecc…), ne ha uno esclusivo e proprietario. I programmi che vediamo “girare” sul nostro PC vengono principalmente eseguiti da quel misterioso oggetto chiamato microprocessore. Questo rappresenta il cuore, l’unità intelligente, di ogni elaboratore elettronico. In realtà una applicazione non viene eseguita solo dal microprocessore ma si appoggia, per così dire, a quello che viene chiamato sistema operativo: uno strato software fornito dal produttore della macchina (si veda, ad esempio, i Macintosh della Apple).

Continua...

Sembra ovvio, ma ad alcuni sfugge la sottile differenza tra costanti e variabili in un linguaggio di programmazione. Le costanti, dal nome stesso, non cambiano il loro valore durante il ciclo di un programma, mentre le variabili possono farlo! Tuttavia, spesso, capita di usare variabili al posto di costanti senza rendersene conto, anche perchè questo non impatta la logica di una applicazione. Nonostante questo, la differenza tra costanti e variabili c’è ed emerge tutta nel momento della compilazione, dove la costante gioca un ruole sicuramente più performante.

Chi viene dalla programmazione Assembly o C conosce bene la differenza tra costanti e variabili, soprattutto perchè, sia in Assembly che in C, le costanti rivestono un ruolo più da MACRO. Per MACRO indendo una “parte di codice” che viene etichettata e sostituita all’interno del codice nel momento della compilazione. Il compilatore, per farla breve, esegue una sorta di find..replace (trova e sostituitsci) nel codice ogni volta che incontra una costante.

Immaginiamo di scrivere in C la seguente semplice porzione di codice:

Sia a che b sono indicate come variabili in questo caso. In C, infatti, le costanti si definiscono con la keyword #define. Notiamo subito che sia a che b sono state definite come int. Già qui si può operare una prima ottimizzazione. Se sappiamo che la nostra variabile a non supererà mai un determinato valore, è bene dichiararla in modo appropriato e non usare tipi dati a caso. Alcuni sviluppatori non si preoccupano affatto di dichiarare correttamente i tipi, pensando che questo non influisca sulle performace! Sbagliato! In alternativa è accettabile che la prima stesura del codice non implichi questo livello di dettaglio. È comunque buona regola, durante il processo di sviluppo, rivedere il codice e verificare i tipi dati.
Comunque sia, in un Assembly della famiglia Motorola, ad esempio, come il mitico 68000, il nostro codice verebbe compilato (senza ottimizzazioni) in una specie di:

oppure:

Il compilatore, per quanto intelligente, fatica nelle ottimizzazioni, quindi scrivere il codice con le giuste keyword può solo aiutarlo a migliorare l’output compilato. Nel nostro caso se il valore 5 è una costante non è conveniente usare una variabile intera, in quanto il compilatore, giustamente, considerando la variabile variabile, appunto, predisponde un intero per contenere il semplice valore di 5; che in binario è 101, cioè occupa 3 semplici bit (caso mai int è un 32bit o peggio un 53bit a doppia precisione a virgola mobile!!). Se avessimo scritto il codice in questo modo:

Il compilatore avrebbe saputo sin dall’inizio che MIA_COSTANTE, essendo costante, non muterà valore e quindi posso riservare meno spazio per trattarla. Nella pratica il codice Assembly diverebbe:

Quest’ultimo codice è estremamente più rapido e occupa meno byte. Quello che bisogna tenere a mente è che quando si dichiara una variabile l’ambiente si predispone per trattarla come tale, anche se i compilatori di oggi riescono a fare miracoli, eseguendo una serie di passaggi nel codice prima di compilare (alcuni compilatori, addirittura, eseguono una specie di simulazione del programma per ottimizzare al massimo la compilazione in codice macchina).

Una buona regola, quindi, è quella di dichiarare il giusto tipo per le nostre variabili, se tali sono. In alternativa usare le costanti, soprattutto se il linguaggio di programmazione che stiamo usando le prevede (come nel caso del nuovo Flash CS3).

Continua...