OT Programmazione - rolling release - chunk 1 2015

[fermat]

bhe allora in teoria va bene con librerie gtk in generale.
quindi, sempre a livello teorico, essendo le gtk multi piattaforma, andrebbe bene anche in altri ambiti.

magari cerco qualche info in più.
grazie!

[Scara95]

Va bene dovunque tu possa usare GObject. Nello specifico sì, è multipiattaforma.

Edit. il fatto che sia una cosa sia multipiattaforma non significa che gode dello stesso supporto in tutte le piattaforme.

[Scara95]

Si sbaglia sempre ciò che si da per scontato.

[MItaly]

Si sbaglia sempre ciò che si da per scontato.

Senz'altro, ma a proposito di cosa nello specifico?

[Scara95]

L'unico errore all'esame non aver allocato lo spazio per il terminatore di stringa. Cosa che mi è capitato di ripetere svariate volte a più persone, molte anche su questo forum.
E' qui che ti dai veramente dell'idiota.

[MItaly]

Pat-pat... se ti consola, tanti anni di C++ e ancora valgrind ogni tanto mi becca problemi su stupidaggini di questo genere, gli off-by-one sono il glitter della programmazione.

(no, non nel senso che sono luccicosi, nel senso che sono uno schifo e finiscono dappertutto )

Related: http://shipyourenemiesglitter.com/

[Scara95]

Pat-pat... se ti consola, tanti anni di C++ e ancora valgrind ogni tanto mi becca problemi su stupidaggini di questo genere, gli off-by-one sono il glitter della programmazione.

(no, non nel senso che sono luccicosi, nel senso che sono uno schifo e finiscono dappertutto )

Ne sono consapevole, ma cavolo se infastidisce.

Related: http://shipyourenemiesglitter.com/

Questa cosa è geniale!

[MItaly]

Questa cosa è geniale!

Pare che dopo tipo due giorni che aveva aperto il sito ha scritto su reddit "piantatela di inviarmi richieste, non riesco a starci dietro".

Neanche ci provo, io comunque preferisco forme di message-passing.

Il message passing è comodo per certe cose, ma per implementare una map-reduce con overhead molto basso non va bene, hai comunque bisogno di locking sulle code degli eventi, event loop e compagnia. In generale, avevo letto un articolo di uno che sosteneva che, con l'aumentare del numero di core, qualunque genere di locking va abolito (per via della Amdahl's law), addirittura compresi gli interi atomici (prefissi LOCK, LFENCE/RFENCE & co.); la sua idea di fondo è che la stessa idea di "correttezza sempre" va abbandonata, a favore della "eventual consistency". Qui ci sono un po' di link interessanti.

[Scara95]

Il message passing è comodo per certe cose, ma per implementare una map-reduce con overhead molto basso non va bene, hai comunque bisogno di locking sulle code degli eventi, event loop e compagnia. In generale, avevo letto un articolo di uno che sosteneva che, con l'aumentare del numero di core, qualunque genere di locking va abolito (per via della Amdahl's law), addirittura compresi gli interi atomici (prefissi LOCK, LFENCE/RFENCE & co.); la sua idea di fondo è che la stessa idea di "correttezza sempre" va abbandonata, a favore della "eventual consistency". Qui ci sono un po' di link interessanti.

Per intanto a mio parere meglio avere un modello semplice con cui ragionare.

[MItaly]

Ah invece se vuoi farti male ma tipo male forte prova a scrivere un qualunque genere di algoritmo lock-free, anche stupidissimo, anche senza cercare di fare cose furbe con fence di memoria asimmetriche o altre sciccherie.
Nella mia implementazione di map-reduce quasi-lockfree (che nasce perché mapped e mappedReduced di QtConcurrent hanno performance tragiche per job piccoli per lock contention), per quanto di base il concetto sia estremamente banale, sono riuscito a farmi del male nelle maniere più strane, con deadlock sulle condizioni di completamento, primo elemento saltato (o reduce mancata) a seconda dell'ordine di avvio dei thread e chi più ne ha più ne metta... i thread sono il male.