Newsgroup: it.comp.os.linux.development
Titolo: Richiesta consiglio

Ciao a tutti,
come da subject chiedo un consiglio:
vorrei iniziare a programmare con Linux partendo da zero;
potreste consigliarmi qualche buon testo che non mi faccia scoraggiare
sin dall'inizio? :-)
Credo che illinguaggio  C /C++ possa andare bene ....che ne dite?
Grazie dell'attenzione.
Ciao.
-- 
=======================    ~~~~~
enzo sorice====>A Sud      (0>
sor...@tiscalinet.z.it
    / \
sor...@spinazzola.z.net
  / / \
remove .z for mail        \/__/__
========================

Steve Oullaine, Pratical C, O'Reilly (non so se c'e' pure in italiano).
Ciao
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

 Ciao
Le cose si fanno o per bene o per niente.
Programmare in C di kerninkgam e riche (non ricordo come
si scrivono i nomi)ma sono loro che hanno compilato il primo
C quindi...per quanto riguarda la programmazione in shell sh
o bash mi sto leggendo un testo un po vecchio ma valido:
unix di Kerningam e Pike.
d + nin so'.brok!

 Le cose si fanno o per bene o per niente.
Con il libro che ho consigliato le cose si fanno benissimo. Lo hai
letto? in cosa lo trovi non valido? 
Il fatto che il C lo han scritto K&R non vuol dire che sono gli unici
che possono scrivere un buon libro sul C. L'Ouallaine per quel che mi
riguarda e' un ottimo testo per cominciare, ed insegna una serie di
buone abitudini abitudini di programmazione delle quali sul K&R (ma io
ho solo la prima edizione, quindi non sono aggiornato) non ho trovato
traccia.


No, sinceramente non l'ho letto, mi sento solo di dire che il K&R e' 
un'ottimo testo ,magari mi procurero' l'ouallaine se ,come dici , insegna
buone abitudini di programmazione non potra' che essere utile.
resto dell'opinione che nessun altro testo sappia illustrare il C come il 
k&r , che poi non fornisca esempi di programmazione....il bello e' 
inventarseli! Quello che scrivi riguardo a Windows: triste verita'!


inventarseli! Quello che scrivi riguardo a Windows: triste verita'!
Qui dove lavoro esistono 3 scuole di pensiero sull'indentazione dei
listati del C:
Gli accademici:
Sono i neoassunti, quelli che hano imparato il C dal libro di K&R
i loro tipici listati hanno la seguente indentazione:
main() {
   int i;
 
   for (i = 0; i <10; i++)
       printf("hello world\n");
}
Quelli del Realtime (la divisione che si occupa di dispositivi embedded e
real-time)
main()
{
   int i;
   for (i = 0; i < 10; i++)
   {
       printf("hello world\n");
   }
}
Gli windowsiani usano un orrendo ibrido tra K&R e RT
tipo
void FaUnCaz(Void)
{
    int i;
    if (i<0) {
        fa_quello_che_pare();
    }
}
Io ovviamente seguo la seconda scuola , quella del realtime...
-- 
Sidewinder  
---------------------------------------------------------------------
"Elves and Dragons!" I says to him.  "Cabbages and potatoes are better
for you and me."
		-- J. R. R. Tolkien
---------------------------------------------------------------------

Io ovviamente seguo la seconda scuola , quella del realtime...
Ce n'e` anche un'altra, quella dei Linux Coders...
#include <stdio.h>
int main(int argc, char * argv[])
{
        int i;
 
	for (i = 0; i < 10; i++) {
	        printf("Hello World\n");
	}
        return 0;
}
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(per rispondere via email fai un rot13 dell'indirizzo)
(apply a rot13 to reply)

listati del C:
[...]
/usr/src/linux/Documentation/CodingStyle

}
io seguo quella di emacs, (TAB e fa tutto lui)
a che categoria appartengo?

 
che a me pare uguale a quella dei winzozziani :D
Saluti,
Fabio Alemagna

che a me pare uguale a quella dei winzozziani :D
No, c'e` una sottile differenza :-)


 No, c'e` una sottile differenza :-)
Uhmm, forse sto sparando una cazzata, ma siccome a livello di
indentazione sono uguali, l'unica differenza che rilevo è a livello di
contenuti: il winzozziano faiuncaz/faiquellochetipar contro il linuxiano
ciaomondodiecivolte :)
Saluti,
Fabio Alemagna

a che categoria appartengo?
Quella sbagliata ;-)

 Fabio Alemagna
In realta', gli winzozziani fanno tre cose che il caro Linus aborre:
1 - indentano di soli 4 caratteri;
2 - usano nomi di variabili e funzioni con lettere maiuscole & minuscole assieme;
3 - (anche se in questo caso non si nota) usano la cosiddetta "Hungarian notation",
ovvero piazzano delle lettere prima del nome di funzioni e/o variabili per identificarne
il tipo (roba tipo iCounter, fRadius, szName, ecc...).
Infatti, "...no wonder Microsoft makes buggy programs" - Linus Torvalds, from the Linux
Kernel Coding Style.
E se lo dice lui... :-)
Alceste

Kernel Coding Style.
La notazione ungherese lo usano tutti, anche quelli che sviluppano per
ambienti AIX e SOlaris...
-- 
Sidewinder  
---------------------------------------------------------------------
	A man was reading The Canterbury Tales one Saturday morning, when his
wife asked "What have you got there?"  Replied he, "Just my cup and Chaucer."
---------------------------------------------------------------------

Quella che scegli con qualcosa del tipo:
(add-hook 'c-mode-common-hook
          (lambda ()
            (c-set-style "bsd")
            (setq c-basic-offset 4)))


 ambienti AIX e SOlaris...
Si, lo so che la usano in molti, ma ogni motivo e' buono per attaccare la Microshit... :-)
Al di la' di questo, cmq, notazione ungherese e' usata per evitare di confondere il tipo
delle variabili. Ma se questo accade, allora:
a - si stanno usando troppe variabili locali -- la funzione dovrebbe essere riprogettata,
perche' e' sicuramente troppo lunga e fa troppe cose, invece di essere "short, sweet and
to-the-point" (Linus docet)
b - si stanno usando troppe variabili globali -- e questo e' sempre male, tranne in
rarissimi casi in cui e' inevitabile.
Se poi la hungarian viene usata per non sbagliare il tipo delle funzioni... Beh, ma il gcc
non e' li' proprio per riempire lo schermo di "error" e "warning"? :-)
E allora, a che serve la notazione ungherese?
Alceste

/usr/src/linux/Documentation/CodingStyle
si trova in rete anche la "Indian Hill C Style and Coding Standards"
ftp://ftp.cs.washington.edu/pub/cstyle.tar.Z
ftp://ftp.cs.toronto.edu/doc/programming
ftp://ftp.cs.umd.edu/pub/style-guide
(non sono sicuro che siano ancora validi)
il sommo K&R cosi' recita:
            The position of braces is less important,
            although people hold passionate beliefs.
            We have chosen one of several popular styles.
            Pick a style that suits you, then use it
            consistently.
e dalle FAQ di comp.lang.c (come anche il resto peraltro)
If your coding environment (i.e. local custom or company policy) 
does not suggest a style, and you don't feel like inventing your own, 
just copy K&R.
-- 
Andrea Iosio                                            .---.
                                                       < ^ ; ~,
                                                        (_  _,    "Piyo"
                                                         J^^>

i
Per noi: la leggibilita dei listati....
-- 
Sidewinder  
---------------------------------------------------------------------
There is no distinctly native American criminal class except Congress.
		-- Mark Twain
---------------------------------------------------------------------

 ambienti AIX e SOlaris...
Io in questo sono d'accordo con Linus, con i compilatori moderni (gcc
-Wall) la cosa e` inutile; forse aveva un senso con il caro vecchio
fortran: conoscete la famosa 
   "God is real, unless declared integer" 
 
:-)? Comunque molte cose sono questione di gusto. Per esempio, i 4/8
caratteri di indent: io capisco il rationale di Linus, ma gia` tre
livelli di indent con solo 80-24 caratteri sulla linea mi sembrano
pochini, e i 4 blank mi piacciono di piu`; sui nomi delle funzioni 
e/o variabili anch'io preferisco un_nome_lungo a UnNomeLungo, ma
questo e` proprio questione di preferenze personali... 
Una cosa e` certa: bisogna avere uno stile e _non_ cambiarlo, senno'
il programma diventa illegibile. Quindi mi sta benissimo che Linus
imponga il suo stile per il kernel. 
                Romano
-- 
Romano Giannetti --- Linux dai tempi di 0.99pl8 --- e ora...
Linux 
pern.dea.icai.upco.es
 2.2.15pre15
Change - with . and delete .no.spam from my email address!

 questo e` proprio questione di preferenze personali...
Certo, è questione di gusti.
C'è da dire che la questione del TAB è particolarmente controversa, a
mio parere. Anche autori famosi usano il TAB a 4. Il TAB a 8, oltre ad
essere portabile, è importante perchè, se presumiamo le 80 colonne
standard, il TAB "lungo" di fatto induce a programmare funzioni
maneggevoli, logicamente semplici. Altrimenti abbiamo codice che esce
dal monitor o si ripiega, diventando brutto, illeggibile. Quindi un TAB
si riflette addirittura sull'architettura complessiva del codice che si
scrive.
Anche se in generale è meglio scrivere funzioni del genere, e tutti i
programmatori in C lo sanno, ci sono delle eccezioni. Non sempre è una
buona scelta cercare di sfilacciare un algoritmo che per sua natura è
fatto in un certo modo. Voglio dire che ci sono casi, a mio parere
particolarmente nella programmazione di applicativi e non invece in
quella di sistema, dove la natura stessa del problema è ricca di
annidamenti, back-references. Cercare di ridurla a più funzioni
elementari non migliora granchè la leggibilità del codice. In questi
casi meglio allora avere il TAB corto, più spazio per scrivere non solo
il codice, ma anche i commenti.
Sempre IMHO, nella programmazione di sistema ciò invece tenderebbe a non
verificarsi, perchè tali problematiche hanno una natura pià astratta e
formale, ci permettono in un certo senso di crearci dapprima il problema
e poi la soluzione. E quindi di solito sono soluzioni eleganti.
Rimane il fatto che è preferibile scegliersi uno stile e mantenerlo. Io
uso quello dei sorgenti, a parte il fatto che tolgo le { } non
necessarie. Per il TAB preferisco l'8 perchè sono un po' conservatore su
certe cose, ma ho dovuto usare il 4. In progetti separati però... :)
ciao a tutti.
P.S.: non flammatemi con troppa violenza, please...

 a che categoria appartengo?
Dipende dallo stile (c-default-style) che hai scelto: bsd, k&r, gnu,
etc. etc.
Ovviamente quello giusto e' gnu ;-)
-- 
Diego    | Per le repliche elimina dal mio indirizzo le 
Dainese  | `x' e inverti le due parole intorno alla `@'

 1 - indentano di soli 4 caratteri;
Non per contraddire il buon Linus, ma credo che 4 sia una dimensione
molto piu' ragionevole dell'8 da lui proposto (ho letto che secondo
alcuni studi la dimensione piu' ergonomica dovrebbe essere appunto fra
2 e 4).
Ciao,


 2 e 4).
Io prima usavo un TAB di dimensione 2, poi ho scoperto che i miei
listati diventavano più leggibili se passavo a 4. 8, IMHO, è esagerato.
Saluti,
Fabio Alemagna

 writes:
l> 
l> io seguo quella di emacs, (TAB e fa tutto lui)
l> a che categoria appartengo?
probabilmente GNU, lo stile di default
M-x c-set-style
poi sfruttando la completion con TAB vedi gli stili possibili
<flame on>
non penserai che emacs abbia un solo stile, no? :-)
guarda qui:
bsd				   cc-mode
ellemtel			   gnu
java				   k&r
linux				   python
stroustrup			   user
whitesmith
Anche sorgenti già scritti possono essere reindentati a piacere.
<flame off>
Ciao
Marco 
 
-- 
Notizie dai principali quotidiani:
	Mamma picchia il figlio con ferro da stiro: aveva preso una
	brutta piega!

Quella sbagliata ;-)
Invece e' quella giusta: il mio tab e' di 4, e se usa i tab tutte le
indentazioni sono fatte col mio stile, qualunque sia il numero di
spazi che usa.
(Sia lode a Python -e forse anche ad altri linguaggi- in cui c'e'
un'unico tipo di identazone)
--
 (o-  | c:\> win2000patch001.exe
 //\  | This Microsoft(c) patch fix all bugs present. All rigth reserved.
 V_/_ | Insert Linux boot disk to continue ... loading kernel ...
http://pinguin.linuxbox.com
 r.salmaso(at)
flashnet.it

ambienti AIX e SOlaris...
Solo m$ la usa sistematicamente
(e nel modo peggiore, direi: che ca**o me ne faccio di sapere in C++
che count e' un'int -lo dovrei dichiarare icount-? e se poi voglio
usare un long int, che faccio, vado a modificare tutto il sorgente? La
HN era utile quando i compilatori non erano furbi, 1980. Nel 199x
credo proprio che lo siano)


Ovviamente quello giusto e' gnu ;-)
visto che ci siamo mi spieghi i comandi per impostare lo stile,
magari impostarlo come default. una volta li sapevo ma non li ricordo piu.


"Now, some people will claim that having 8-character indentations makes
 the code move too far to the right, and makes it hard to read on a
 80-character terminal screen.  The answer to that is that if you need
 more than 3 levels of indentation, you're screwed anyway, and should fix
 your program.
 In short, 8-char indents make things easier to read, and have the added
 benefit of warning you when you're nesting your functions too deep.
 Heed that warning."


 listati diventavano più leggibili se passavo a 4. 8, IMHO, è esagerato.
Anche io, avendo iniziato a programmare sotto WinDOS 95, usavo gli standard
Microzozz che adesso detesto - e tra questi c'era l'indentazione a 2 o 4
caratteri (ma ho visto anche qualcuno che indenta di 1 - e purtroppo sotto
Linux).
Dopo aver letto il coding style di Linus, pero', mi trovo d'accordo con
lui: indentare di 8 aumenta ancora di piu' la leggibilita', e costringe a
non superare i 4-5 livelli di annidamento, oltre i quali il codice diventa
- almeno secondo me - difficile da capire e ampiamente rivedibile.
E visto che io sono disordinato di natura, questo e' un motivo in piu' per
costringermi a rivedere gli algoritmi che scrivo di getto... :-)
Alceste

Invece e' quella giusta: il mio tab e' di 4, 
Appunto, il tab deve essere di più, a meno che non ti
piaccia incrociarti gli occhi :-))

 Ovviamente quello giusto e' gnu ;-)
Qualche esempio di GNU Coding Standard:
------------------------------------------------------
if (x < foo (y, z))
  haha = bar[4] + 5;
else
  {
    while (z)
      {
        haha += foo (z, z);
        z--;
      }
    return ++x + bar ();
  }
do
  {
    a = foo (a);
  }
while (a > 0);
------------------------------------------------------
Francamente e' la cosa piu' perversa che abbia mai visto... :-)
Fate un confronto con l'equivalente Linus-style:
------------------------------------------------------
if (x < foo(y, z))
        haha = bar[4] + 5;
else {
        while (z) {
                haha += foo (z, z);
                z--;
        }
        return ++x + bar ();
}
do {
        a = foo (a);
} while (a > 0);
------------------------------------------------------
In questo modo lo stesso codice e' piu' leggibile (anche grazie
all'indentazione si 8 spazi) e occupa meno righe (pensate che bello
dover stare a scrollare su e giu' in un terminale ANSI 80x25, per dover
leggere un codice "spalmato" all'inverosimile...).
"...GNU people aren't evil, they're only severely misguided in this
matter" - Linus Torvalds, from the Linux Kernel Coding Style.
Indovinate che stile uso io... ;-)
Alceste



/opt/share/Vernacoliere/alvaro/gif/mavainculo.gif
(seguira' dibattito)
Leonardo ;-)
".signature": bad command or file name

/opt/share/Vernacoliere/alvaro/gif/mavainculo.gif
/a/te/e/il/condominio/tuo :-)

 :-)
Credo che sia un'osservazione un po' superficiale. Non capita raramente
di avere più di 3 livelli di indentazione e non per questo si sta
scrivendo del cattivo codice. Cmq quello che mi da fastidio
dell'indentazione con TAB 8 non è che spinge il codice troppo a destra,
è che la distanza tra l'inizio di una riga e quella successiva con
livello di indentazione superiore è troppo grande.
Ciao,
Fabio Alemagna

 your program.
Se qualcuno mi spiega un modo PULITO di lavorare con iterazioni su
matrici 3D senza fare 5 indentazioni (con la funzione, sono 6) ne'
spedire i due cicli piu' interni dentro una funzione separata (che
[a] rallenta un po', [b] costringe a passare una tonnellata di var
come parametri), abbandono subito i tab da 8 caratteri.
(Poi, comunque, visto che impiego appunto un TAB e non quattro ' '
per indentare, basta che uno apra i miei sorgenti con un TAB da 8,
e tutto gli va a posto da se')
Leonardo


il tipo (roba tipo iCounter, fRadius, szName, ecc...).
Mi scopro con sgomento winzozziano, e spendo due parole per difendere il
mio stile di scrittura.
L'indentazione di 4 caratteri e' utile se
{
	mentre
	{
		si scrive codice
		{
			molto nidificato
			{
				e puo' succedere; le funzioni gia' danno
un primo indent,
				{
					capita di arrivare
					{
						oltre l'ottantesima
colonna
						{
							oppure, arrivati
verso la quarantesima,
							ci si ritrova un
bel "vsprintf(...)" e tanti argomenti.
						}
					}
				}
			}
		}
	}
}
Anche lo spostamento della
{
	graffa alla riga sotto non fa gran che,
}
ma il primo cut & paste che uno si trova a fare, capisce l'utilita'.
Infine, una versione blanda della notazione ungherese di Simonyi assolve
ad un compito importante. E' si' vero che il compilatore se ne fotte, di
come si scrivono le variabili; ma ppsUsers, so che e' un puntatore ad un
puntatore a stringa, e quando vado a fare
	*psTemp = ppsUsers
vedo ad occhio che va bene. Se non vi serve incasinarvi con i puntatori,
lasciate pure perdere questi trucchetti; pero' allora tanto vale valersi
del Visual Basic ;-)
Quanto al numero di righe che aumenta: c'e' qualcosa che non ho visto in
quelle raccomandazioni, e mi dispiace:
	a) USARE I COMMENTI!
	b) USARE I CHECKPOINTS!
Con poco sforzo, io riesco a debuggare il 99% dei miei programmi _SENZA_
usare gdb, e spesso neanche devo farlo io; mi faccio spedire un log.
+++
Suggerisco un'altra lettura: "Writing Secure Code", Steve Maguire. Fara'
ridere pensare che lo pubblica Microsoft Press. Ma niente paura: loro lo
hanno scritto, ma non lo hanno mai letto :-)))
Leonardo "e nel libro a volte vengono pesantemente presi per il gufo"


 come parametri), abbandono subito i tab da 8 caratteri.
Volevi dire da 4, immagino.
Io credo che il coding style del kernel possano andare per il kernel,
appunto. Il volerli applicare a qualunque tipo di programma mi pare
un'idea assai velleitaria.
Comunque l'indentazione e' spesso questione di gusti/abitudine,
personalmente preferisco quella a 4 che mi pare dia una migliore
leggibilita' (con due non distinguo bene i livelli perche' son troppo
vicini e con 8 non li distinguo perche' son troppo distanti), ma se poi
uno ci mette i tab la cosa appunto si risolve per il meglio.


 Invece e' quella giusta: il mio tab e' di 4, 
[root@fokhouse /root]# grep Tabs /usr/src/linux/Documentation/CodingStyle
Tabs are 8 characters, and thus indentations are also 8 characters.
[root@fokhouse /root]#
8)
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

 8)
Solo se devi sviluppare per il kernel.
Quella è l'indentazione che piace a Torwarlds e lì dentro (nel kernel)
detta lui legge :)
Saluti,
Fabio Alemagna

come parametri), abbandono subito i tab da 8 caratteri.
Hai perfettamente ragione, non e' sempre possibile. Se proprio vuoi provare
a farlo, puoi dichiarare la funzione separata come "inline", in modo da non
perdere nulla (o quasi) in velocita'. E' la soluzione che io adotto negli
switch() {}, ma che non e' proprio il massimo per un ciclo for... :-(
Saluti,
    Mardy

Volevi dire da 4, immagino.
Si', infatti ;-)
Leonardo


 magari impostarlo come default. una volta li sapevo ma non li ricordo piu.
C-x c-mode<RET>
C-x customize-variable<RET>c-default-style<RET>



Hmm... Ricorda che "Chi va con lo zoppo impara a zoppicare"... :-)
Comunque, esiste anche il Secure-Programming-HOWTO, che non ho ancora letto, ma che avra'
sicuramente la precedenza su qualsiasi cosa "Made in Redmond"...
Alceste