On 6 Nov 2002 at 22:16, Davide Bolcioni wrote:
> Ivan Sergio Borgonovo wrote:
> > On 5 Nov 2002 at 23:22, Davide Bolcioni wrote:
>
> > Io dovevo contare i duplicati in una lista... superato l'empass di
> > cercare di compilare C++ con gcc... in 1 minuto ho scritto un
> > programma in C++ che è venuto 20K e in 2 minuti ho scritto
> > l'equivalente in C 5.5K. Se chiedevo in lista se c'era un tool per
> > fare la stessa cosa imparavo meno e ci impiegavo di più.
>
> cat lista | uniq -d | wc -l
No, mi sono spiegato male... ti do il C così evito di ucciderti con un
italiano rocambolesco.
#include <stdio.h>
#define LINELENGHT 255
int main(int argc, char* argv[]){
unsigned int lines=0;
char linea[LINELENGHT]="";
char lineatmp[LINELENGHT]="\n";
if (fgets(linea,LINELENGHT,stdin)) {
memccpy(lineatmp,linea,0,LINELENGHT);
lines++;
while (fgets(linea,LINELENGHT,stdin)) {
if (0!=strcmp(linea,lineatmp)) {
printf("%04x%s%s",lines,"\t",lineatmp);
lines=0;
memccpy(lineatmp,linea,0,LINELENGHT);
}
lines++;
}
}
else {
return 1;
}
printf("%04x%s%s",lines,"\t",lineatmp);
return 0;
}
Lo so dovrei aggiungere più controlli sull'overflow di lines per
esempio... ma pazienza... così gira più veloce ;)
Oggettivamente mettere un long long int mi faceva un po' ridere ;)
Lo so tra 3 anni potrei pentirmene.
> Secondo me, la questione non è se sia più bello o no. Cercando qualcosa
> fatto da altri, si impara un approccio diverso. Comunque, tutti passano
> per la fase in cui vogliono riscrivere glibc.
No, sono troppo pigro.
Comunque se si passa la vita a leggere la roba d'altri non si fa mai
nulla. Certo si incorre in qualche ripetizione, qualche bruttura,
qualche errore... ma ci vuole un sano bilancio altrimenti non si impara
anche se si studia. E poi c'è sempre il rischio recondito <g> di fare
veramente qualche cosa di nuovo.
> Vale la pena. Comunque lo standard è del 1998, non occorre essere
> aggiornatissimi ormai. Il prossimo è per il 2008. Consiglio anche
Adesso mi informo presso le mie talpe per vedere se è in progetto
un'edizione nuova a breve.
> "The Standard C++ Library" di N. Josuttis, che sarebbe persino più
> importante (la libreria C++ è molto più importante del linguaggio)
Concordo _quasi_ completamente ;) Anzi... ogni tanto butto l'occhio per
vedere se c'è qualche libro che mi attizza particolarmente sia per le
SL che le STL e per quello non aspetterei... ma non mi sono mai
convinto ci fosse un _bel_ libro in proposito.
> capito niente). Consiglio anche www.boost.org, librerie eccezionali
> (alcune molto bleeding edge).
Si... intrigante... più tardi però...
> > Interessante. Spero che non sia così doloroso come mi suona adesso.
> Può esserlo, e gcc/g++ è uno dei principali colpevoli. Avere più
> versioni di gcc che coesistono bene si può fare, ma non è mai facile.
NON ci penso neanche, la vita è breve. Ho un esercito di macchine
qua... terro il 2.95.2 su una, il 3.2 della SuSE che probabilmente
acquistero su un altra e poi Gentoo con l'ultima super uptodate.
Quello che mi annoiava un po' era scrivere codice e pensare che il
disinstallarlo potesse richiedere dolorosa pianificazione.
> Io conosco Visual Studio, disabilitavo l'auto completion perchè mi
> mandava in crash l'IDE e l'help in linea non sarebbe male salvo che è
Sinceramente l'ultimo C++ (pre .NET 6 credo) della MS lo ho usato
poco... ma qua funzionava.
> spesso inesatto, p. es. c'è una pagina sui costruttori che possono
> perdere memoria in caso di eccezioni che ha depistato innumerevoli
> programmatori spingendoli a creare classi con un costruttore nulla
Bhe però è comodo avere un sistema di docs online e oggettivamente di
doc seccata o imprecisa in giro ce n'è, in questo caso non è esclusiva
MS. Quando ti vogliono far sapere qualche cosa danno sfoggio di ampia
disponibilità di mezzi per essere sicuri che la trovi.
> facente e dotate di un metodo .Init() in barba alle più basilari norme
lo so è brutto... ma con MS questo tipo di cose ti trovi a farle da
mane a sera per prevaricare alcune delle loro scelte invasive.
> di programmazione C++. Non ho usato MASM e ho vaghe reminiscenze di
> Turbo Pascal.
MASM era veramente carino... anche se era più cool usare tasm
all'epoca...
> Comunque, l'ambiente di programmazione non è l'IDE: al centro di tutto
> c'è il Makefile. Mi spiego meglio:
>
> - i tags servono per saltare da un riferimento, p.es. a una funzione,
> alla sua definizione o prototipo (certi IDE fanno ciò scandendo il
> codice, in Unix questo viene fatto nel Makefile);
mmm... appena provo ti dico se mi piace... oggettivamente preferisco
che cazzabubbole di questo tipo se le sbatta il più possibile la
macchina.
> - autoconf serve per generare automaticamente il comodissimo script
> ./configure ormai standard in tanti pacchetti distribuiti via .tar.gz
> e usato anche da RPM e DEB, in modo che non sia necessario compilare
> su N piattaforme per essere portabile su N piattaforme (poi qualcosa
> scappa, ma è il volume che conta);
piacc
> - automake serve per generare i Makefile con i target giusti sia sulla
> piattaforma dove si sviluppa che sulla piattaforma dove qualcuno
> compila il .tar.gz;
piacc
> - libtool è uno sviluppo recente, serve a costruire .so in modo
> portabile tra piattaforme diverse (e a imbroccare la costruzione
> della .so sulla piattaforma in cui sviluppi);
mmm più tardi
> Gli automatismi servono per fare in modo efficiente lo unit testing,
> ovvero *prima* di scrivere il codice che fa qualcosa scrivo il codice
> che fa il test. Anche questo è un discorso lungo.
ho presente la filosofia... spesso è presentata in maniera un po'
troppo integralista... questo non vuol dire che se si decide di
intraprendere un approccio del genere si possa farlo da buffoni.
Tuttavia è comodo a seconda delle circostanze procedere in entrambe le
maniere. E' come il giusto bilancio tra il fare i propri errori e
pensare di non farli continuando a rimandare perchè si stanno studiando
gli errori già affrontati dagli altri ;)
> Suggerimento: comincia con RCS e con un file solo. Passa a file multipli
> nella stessa directory, sempre con RCS. Poi passa a file organizzati in
> più subdirectory. Noterai che il make GNU riconosce RCS e lo usa
> autonomamente, tra l'altro. Quando hai un pò di familiarità con RCS il
> passo a CVS è facile.
mmm sono tentato a provare l'approccio duro e passare di diretto al CVS
ASAP...
Adesso devo trovare qualche progetto che mi intrighi per scrivere
C/C++. Quando sarà abbastanza grasso da rendere necessario qualche
aiuto, scommetto che a usare il CVS imparo infretta.
Pensavo di portare oltre il sistema di catalogazione dello spam per
generare filtri... qualche cosa che mi permettesse di analizzare gli
header, la parte Received etc... ma devo prima farmi un'idea di quante
cose un umano riuscirebbe a estrapolare da un email per catalogarla
come spam e decidere cosa bannare... lo so suona come riscrivere le
glibc ;)
> > E poi promuovi vim eh!
> Non mi sono spiegato bene: vi è uno strumento importante per il
> sysadmin. Chi si trova bene con vi e fa anche il programmatore
no... ti sei spiegato bene. Effettivamente sei un "caca spilli" (giusta
la citazione?) ma sei chiaro. Sfottevo.
> diversi. Chi fa solo lo sviluppatore ha tutti i titoli per non
Si... abbiamo un sacco di titoli Tanno!
> ritenersi interessato a vi o a vim, anche se Tann direbbe "a suo
> proprio danno", e scegliere KDevelop o Emacs secondo le proprie
Ma poverino... capiscilo... sempre attaccato a una console, vive
un'esistenza triste. Lui lo dice con benevolenza ma non sa che non
tutti sono destinati alla sua vita grama ;)
Dopo aver visto quel sorriso rassegnato nella foto ho capito tante
cose.
> inclinazioni. Come ho spiegato in altro thread, secondo me il cuore
> dello sviluppo non è l'editor, è il Makefile.
Ma reference in linea e qualche automatismo comodo aumentano la
produttività e non ti obbligano a tener occupato il cervello con cose
meno essenziali. Poi ci sono gli stoici (detti per brevità SM)... ma
sono cavoli loro.
--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
uniq life || sleep 24h
|