Feeds:
Posts
Comments

Posts Tagged ‘C++’

Ebbene sì: il titolo che vedete non è per nulla inventato. Ma andiamo con ordine.

Esiste un sistema operativo: TinyOS. E’ pensato per reti di sensori, le quali sono costituite da devices che si interfacciano con i computer tramite porta seriale (travestita da USB, ma poco importa in questo contesto). Di conseguenza, tale OS viene distribuito con un set di librerie in alcuni linguaggi per leggere e deserializzare il più comodamente possibile i messaggi trattati all’interno del sistema stesso, così da poter ricevere i dati ed elaborarli in qualche modo. La struttura standard di una WSN, infatti, prevede che uno dei devices funga da sink e riceva le comunicazioni dell’intera rete, per poi trasferire queste informazioni in un computer (che le salverà in qualche formato). I linguaggi di questo piccolo SDK sono C, C++, Java e Python.

Per poter interfacciare un device di una WSN con un computer a bassa potenza come una Carambola, è necessario utilizzare le versioni C o C++, dato che sia Python che Java non sono tendenzialmente supportati su quel tipo di schede. Ora, mentre sfogliate i sorgenti che leggono le porte seriali, potreste imbattervi nella seguente riga:

#include “../../java/net/tinyos/packet/BaudRate.java”

Tah-da! Un file sorgente C include un file Java al suo interno! Vi lascio qualche momento per rabbrividire adeguatamente della cosa…

Ok, l’idea di fondo è la seguente: esiste una lista riempita in un file Java strutturata come segue:

package net.tinyos.packet;

class BaudRate {
static void init() throws Exception {
Platform.add(Platform.x, “mica”, 19200);
Platform.add(Platform.x, “mica2”, 57600);

}
}

Il problema è che tale lista è necessaria anche nella versione C (che deduco essere arrivata dopo quella Java), e anzichè replicare le informazioni, gli sviluppatori hanno deciso di includere il file Java dentro quello C.

La sintassi è adeguatamente simile, e per far funzionare il giochino (come spiegano alcuni commenti del file C) è necessario:

  1. definire alcune define (perdonate il gioco di parole), affinchè la dichiarazione di package, di classe e di metodo non interferiscano in alcun modo con il codice C; tali definizioni si trovano in fondo al file C, dato che (mi è stato fatto notare) probabilmente scrivere qualcosa come “#define void” e ridefinire parole chiave che esistono in C creerebbe troppi problemi in altri punti del codice (ma non sono certo di questo)
  2. definire alcune struct con puntatori a tipi e funzioni, così che le chiamate del tipo “Platform.add” vengano interpretate correttamente e, come conseguenza, la variabile “args” alla fine contenga esattamente il secondo e terzo parametro della linea corretta tra le varie “add” (il secondo parametro è riempito dai sorgenti, tutto questo sistema serve per fare una sorta di lookup tra le linee “add” e ricavare il numero che indica il baudrate da utilizzare nella comunicazione con la seriale).

Chiaro, no? Non sono sicuro di riuscire a scendere ulteriormente nel dettaglio delle struct stesse, dato che sono un tantino convolute ed io non scrivo codice C da un po’, ma sono certo che un’occhiata ai sorgenti permetterà ai nerdoni tra voi di capire al volo come funziona il meccanismo!

Advertisements

Read Full Post »

ImageCopier 1.3.1.7

ImageCopier 1.3.1.7

Dopo mesi, per non dire anni, in cui non mi ero più dedicato al mio piccolo programmino in C#, ecco un aggiornamento di ImageCopier, che tocca la versione 1.3.1.7.

ImageCopier è una piccola utility che permette la copia di file da un percorso ramificato ad un percorso unico: vi è mai capitato di tornare dalle vacanze e voler mettere insieme tutte le foto che avete, e che tendenzialmente avrete posto in diverse sottocartelle (una per ciascuna scheda di memoria)? Ebbene, da ImageCopier è sufficiente che selezioniate la cartella padre delle sottocartelle di cui sopra come input, una cartella vuota come output, ed il programma copierà i file dalla prima alla seconda, in ordine strettamente alfabetico e numerando correttamente in sequenza i file ivi contenuti.

Ok, ovviamente se usate (come me) un programma di gestione di foto, non ve ne fate assolutamente niente; ma se ordinate voi a mano le vostre immagini sull’hard disk, potrebbe tornarvi utile.

Di fatto, tutta questa spiegazione è stata una scusa per poter giocare un po’ con C#, che potrei definire il primo linguaggio di programmazione serio di cui io abbia mai avuto un libro (e parliamo del 2003, e non vogliamo certo considerare Pascal e BASIC come seri, no?), e con il quale non avevo mai avuto occasione di sperimentare. Il programma naturalmente è rigorosamente cross-platform, e solo una riga di codice deve essere modificata affinchè l’esecuzione sotto Mono avvenga senza problemi (ed aggiungo: solo perchè non ho ancora capito come far andare quella riga sotto Mono senza che lanci una runtime exception). In ogni caso, ecco l’installer per Windows, creato con Nullsoft Installer, ed il consueto archivio di sorgenti per Linux: per il primo, le dipendenze (ovvero il runtime di .NET >= 2.0) vengono installate automaticamente, per il secondo dovete assicurarvi di avere installato il compilatore e le librerie base di Mono.

Rispetto alla versione precedente, ho reso l’utility vagamente più furba, ovvero ora la parte di copia viene eseguita in un thread in background, con il progresso visualizzato correttamente nell’UI; c’è anche un’altra modifica che vorrei fare prossimamente, vale a dire l’ordinamento dei file secondo la data riportata dai metadati EXIF, invece che secondo l’ordine alfabetico; vedremo se ce ne sarà il tempo nei prossimi giorni.

Tra parentesi: avete notato che ora i file .exe di Mono possono essere eseguiti da console direttamente, senza dover specificare l’interprete mono?

Read Full Post »

KDevelop

KDevelop

Penso sia l’IDE più colorato che si sia mai visto…

Read Full Post »

Ho pensato per un po’ se far uscire questo post anche su PlanetKDE, però poi ho optato per l’italiano e per la stretta cerchia di lettori “nostrani”, ed è perciò a questo pubblico che rivolgo i miei 2 cents sul dibattito Mono.

Premessa doverosa: non intendo soffermarmi sulla questione etica, che è stata sicuramente mitigata dagli ultimi accordi di licenza by Microsoft, e che comunque non mi trova del tutto d’accordo con RMS (che, ripeto, per me continua ad essere troppo estremista, il mondo non è bianco o nero).

Da un punto di vista di sviluppatore, mi infilo alla grande nel dibattito Banshee vs. Rhythmbox, ripreso anche su Pollycoke, forse uno degli eventi maggiormente scatenanti le polemiche: in pratica, Canonical vuole sostituire al secondo il primo nella prossima edizione di Ubuntu, sostanzialmente droppando lo storico riproduttore di Gnome ed aumentando perciò la propria dipendenza da Mono, questo quando altre distribuzioni invece cercano di liberarsene.

Ora, io non sono mai stato un utilizzatore di nessuno dei due, dato che mi piace Amarok e lo uso a prescindere dal Desktop Environment che ho attivo in quel momento; sottolineo che entrambi i programmi hanno due interfacce estremamente simili, quindi un utente dell’uno non credo possa essere completamente spaesato nell’altro, e sono comunque convinto che chi utilizza Rhythmbox continuerà ad usarlo a prescindere da che programma sarà di default, anche perchè si potrà installare quest’ultimo giusto con i soliti due click. Mi è anche difficile sparare su Mono, dato che uso ormai da 3 anni Tomboy, e non lo cambio neppure ora che sono fisso su KDE, più che altro perchè ho ormai più di 300 note, e voglia zero di dover creare uno script apposito che mi trasferisca tutta la history in un altro framework analogo.

Da un punto di vista di sviluppatore, bè non posso che approvare la scelta: sono ormai un paio di mesi che sviluppo in C++ per il GSoC, ed intendiamoci, questa non è certo una critica (o uno sputare nel piatto dove sto mangiando quest’estate), ma rimango comunque alquanto interdetto dal fatto che siamo costretti ancora ad usare C/C++ per produrre non dico programmi dalla grafica 3D spinta, o dalla gestione di dati sconfinati, ma per produrre un’interfaccia grafica standard e funzionalità direi “normali”.

Per un programma di riproduzione multimediale, obiettivamente, uno sviluppatore non può dover trattare ancora con la gestione della memoria, non nel 2009, per il semplice motivo che è assurdo dover stare attenti a dove eseguire i delete o le free per evitare dangling pointers, o utilizzare compilatori sostanzialmente lenti (Banshee lato C# si compila in 2 minuti, serve quasi quasi di più per i wrapper in C verso le librerie multimediali) e che producono errori non certo sempre comprensibili.

Ammetto, ad esempio, che la mia esperienza con C++ non è così vasta, e che giorno dopo giorno imparo dai miei errori ed evito di combinare guai con le mie librerie, certo è che ho perso tre ore per un’istruzione non funzionante in una classe (quando in un’altra classe sostanzialmente identica non dava problemi), per poi scoprire che mancava un’include, e naturalmente l’errore non faceva certo percepire che il problema potesse vagamente essere questo; oppure la possibilità di passare i parametri per riferimento in due modi diversi, che naturalmente devono essere gestiti in modo diverso, o la quantità di combinazioni della parola chiave “const” che si possono utilizzare…

Quando il mio progettino sarà finito, inoltre, dovrò dare un giro di Valgrind, per verificare di non lasciare memoria occupata per niente, quando in linguaggi come Python, Java, C# questa è una cosa assolutamente inutile, dato che non dipende più da me.

Insomma: i framework Qt e GTK sicuramente aiutano e tolgono parte del peso dalle spalle dei programmatori, ma secondo me dovrebbe esserci sempre più la nascita e lo spostamento di sforzo di sviluppo dai linguaggi usati oggi a quelli che potremmo considerare sostanzialmente moderni, dato che il livello di prestazioni è sostanzialmente identico e la manutezione e lo sviluppo discretamente semplificati.

Read Full Post »

Maledetto C++

Alla fin fine non chiedo molto: mi basterebbe avere un compilatore che restituisca errori comprensibili dall’uomo…

Read Full Post »