Newsgroup: it.comp.lang.c
Titolo: Posizione degli header files.

Ciao a tutti.
Stavo notando che sul mio sistema (Linux Ubuntu Gutsy) esistono diversi 
file con nome wait.h, salvati in diverse directory.
In particolare, essi sono:
/usr/include/wait.h	
/usr/include/sys/wait.h	
/usr/include/linux/wait.h	
Inoltre, ho visto che il primo include il secondo.
Vorrei capire se è così in tutti i sistemi oppure se è una particolarità 
della mia distribuzione di Linux.
Il problema che mi pongo è, in realtà, più generale, e cioè: se in un 
programma C inserisco l'istruzione
#include <wait.h> /*ma il discorso si può estendere ad altri header 
files */
vado incontro a potenziali problemi di portabilità?
Il dubbio mi è sorto perchè, in alcuni esempi sulla programmazione di 
sistema scritti dai miei docenti universitari, trofo sempre 
l'istruzione:
#include <sys/wait.h> /*ed è così anche per types.h ed altri header 
files*/
Un saluto e grazie mille.
Bizio.

 files*/
Neanche types.h  fa parte delle librerie standard.
Giorgio


Dove trovare gli header files è una funzione lasciata al compilatore 
in quanto non esiste alcun standard.  Le directories /usr/include e 
/usr/include/sys sono quelle usate dai primi compilatori in Unix per 
gli header files (rispettivamente quelli generici e quelli specifici 
al sistema.  /usr/include/linux/ è la directory usata per la 
compilazione del kernel o di certi programmi di sistema che usano 
valori o strutture definite dal kernel ed in pratica sostituisce (od 
integra) il contenuto della /usr/include/sys.
In linux se guardi le man pages di wait() troverai che viene suggerito:
#include <sys/types.h>
#include <sys/wait.h>
in quanto le strutture ed i valori ritornati sono specifici del 
sistema.  Che qualche file in /usr/include includa il file con lo 
stesso nome dalla directory /usr/include/sys è IMO una scelta di chi 
ha predisposto il pacchetto per facilitare la portabilità.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 
LOL  e quali sarebbero le librerie standard?


 LOL  e quali sarebbero le librerie standard?
Capitolo 7  dello standard ISO/IEC 9899:1999 (che, per chi non lo 
sapesse, sarebbe lo standard C  in vigore :-) )
Ti  riporto,  per tua acculturazione,  la  lista degli headers standard 
  (7.1.2 intitolato Standard headers):
The standard headers are
<assert.h>
<complex.h>
<ctype.h>
<errno.h>
<fenv.h>
<float.h>
<inttypes.h>
<iso646.h>
<limits.h>
<locale.h>
<math.h>
<setjmp.h>
<signal.h>
<stdarg.h>
<stdbool.h>
<stddef.h>
<stdint.h>
<stdio.h>
<stdlib.h>
<string.h>
<tgmath.h>
<time.h>
<wchar.h>
<wctype.h>
Ciao
Giorgio

  (7.1.2 intitolato Standard headers):
LOL
Non metto in dubbio che quelli che riporti sono gli header files dello 
standard ISO/IEC 9899:1999 ma il C non è limitato solo a quelli. Gli 
header files *standard* di un compilatore sono quelli necessari per 
descrivere le interfacce alle librerie che il compilatore usa.
Devi essere allievo di Andrea Laforgia :-(


 Devi essere allievo di Andrea Laforgia :-(
Non credo proprio.  Se cerchi troverai che ho polemizzato con A.L. più 
di una volta per la sua rigidità. E  non mi piace il suo stile di 
partecipazione al NG. Ma ti consiglierei di rileggere questo thread e 
vedere se veramente i tuoi interventi ( LOL fuori luogo inclusi ) erano 
centrati rispetto a qello che ho scritto io. Se poi vuoi polemizzare con 
A.L. fallo direttamente.  Non con me.
Giorgio

 Devi essere allievo di Andrea Laforgia :-(
Purtroppo i LOL abbondano sulla bocca degli stolti e tu dimostri d'essere,
oltre che il solito "stolto" (per essere gentili), anche il solito
incompetente.
Ora risparmiaci l'ennesima arrampicata sugli specchi basata sulla tua
personalissima interpretazione di "standard".
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 descrivere le interfacce alle librerie che il compilatore usa.
Questa definizione di 'standard' è abbastanza debole. Tipicamente hai
dato una definizione di standard dipendente dal compilatore, che è
piuttosto controintuitivo visto l'usuale utilizzo del termine standard.
Nota che ci sono *diversi* standard. Giorgio Pastore ti ha elencato gli
header standard dello standard C99. Si possono anche elencare gli header
standard di un sistema Posix, per dire.
Tornando all'esempio di Fabrizio Marini, l'header sys/wait.h è parte
dello standard Posix. Se il nostro applicativo ha come target un sistema
posix, possiamo assumere che con #include <sys/wait.h> troviamo
qualcosa. 
Poi *ovviamente* in C puoi chiamare un mucchio di librerie diverse e
dovrai includere i corrispondenti headers. Tuttavia questi headers (e
pure le librerie che linki) potrebbero trovarsi in linea generale
ovunque. Non è un caso che chi ha fatto tools come gli autotools per
esempio abbia previsto diversi meccanismi per specificare (tramite
opzioni di configure) dove stanno ste benedette librerie.
Tipicamente semplicemente buttare dentro un (per dirne una)
#include <gmp.h>
non da grosse garanzie: se gmp è installata in modo tale che i suoi
header siano nelle include dirs di default del compilatore, tutto bene.
Se per esempio uno le ha altrove (io le ho in /opt/local/include, per
dire) non verranno trovate. E non c'è scritto da nessuna parte che gmp
debba stare da qualche parte: potrebbe pure stare nella mia home,
potrebbero starcene 4 versioni diverse e posso volere scegliere di volta
in volta quale includere (e di conseguenza linkerò la lib di quella
versione).
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 personalissima interpretazione di "standard".
Ti risparmio, se vuoi, ogni altra considerazione ma non un ennesima 
risata.  Con un integralista talebano come te non c'è alcuna 
considerazione che possa spiegare che lo standard ISO non è la bibbia 
a cui devi credere ciecamente e, guarda caso, ogni compilatore 
stabilisce uno standard di fatto basato in genere sull'ambiente di 
lavoro.  Se non hai mai codificato non puoi capire un simile concetto.
Rimango in attesa del tuo prossimo proclama per farmi una bella sana 
risata.


Se non hai mai codificato non puoi capire un simile concetto.
Ma smettila di dire cagate senza fine! sei un babbuino arroccato sulla
propria montagnetta di codiciuzzo che somiglia tanto a una palla di sterco
e accusi gli altri di non aver mai scritto codice. Io non discuto la mia
competenza e il numero di linee di codice che ho scritto con un troll
della peggiore specie.


On 12/31/07 02:43, Andrea Laforgia wrote:
  -----   CUT ----
Alla faccia della polemica !!!  Siccome ti vanti di aver capito 
l'argomento del thread fammi il favore di rileggerti i post 
precedenti.  Si parlava di header standard, ma solo uno che come te 
ragiona col paraocchi associa standard alle specifiche ISO.
Che poi per te non esistano gli header come standard del compilatore 
dimostra solo quanto TU sei presuntuoso e che non avendo alcun 
argomento sei solo capace di offebdere.


 Neanche types.h  fa parte delle librerie standard.
Dove trovi che si parli dello standard ISO?  Solo perché si parla di 
portabilità e siamo su i.c.l.c.?
Semplicemente si nega che "sys/wait.h" e "sys/types.h" siano header 
standard perché (IMO erroneamente) si ritiene che "standard" sia 
automaticamente sinonimo di "standard ISO".
Potrai anche non essere d'accordo ma di solito ogni compilatore 
realizza il linguaggio come definito dalle specifiche ISO e fornisce 
un supporto basato sulle librerie per lavorare nell'ambiente su cui è 
basato.  Non è, come dice qualcuno, una mia definizione ma quello che 
ho trovato riportato nei manuali di molti compilatori.  Ho trovato 
spesso in questa documentazione il riferimento agli header files e 
alle librerie standard che sono quei files che vengono installati 
assieme al compilatore (e che naturalmente non vanno bene per altri).


 assieme al compilatore (e che naturalmente non vanno bene per altri).
Gli header *standard* sono più universalmente intesi come:
1. gli header prescritti dallo standard ISO C*
2. gli header prescritti da un qualche standard riconosciuto che sia
possibile evincere dal contesto.
Per esempio se stiamo parlando di programmazione di socket bsd e
parliamo di header standard probabilmente non c'è bisogno di specificare
che stiamo parlando dello standard Posix. Ma in se e per se parlando
solo di 'standard' si intende quello 'più standard': lo standard C iso
(anzi, siamo pure imprecisi, visto che non stiamo specificando quale, il
più diffuso C89 o il più recente C99).
Tuttavia su it.comp.lang.c mi pare abbastanza ovvio che quando si parla
di standard e basta si intendano gli standard ISO del C. 


  - I sistemi di sviluppo.


 mi riferivo agli headers standard del compilatore.
Ma non ha molto senso parlare di 'header standard del compilatore'. E'
un po' come parlare della 'dimensione standard degli int'. Un
compilatore è un *implementazione*. Uno standard è un'*interfaccia*. Non
capisco come si possano confondere a questo modo i due concetti.
Poi se proprio vogliamo dirla tutta, un compilatore è un *programma* e
strettamente parlando la libreria (di cui fanno parte gli header) può
essere una cosa a parte. Posso usare il compilatore GNU con altre libc.
Come? Esatto. Gnu offre un *compilatore* C e una *libreria* standard C.
Niente mi vieta di usare il compilatore gcc con una diversa libreria C:
e se ricordo bene e tu tratti sistemi embedded dovresti pure saperlo
meglio di me. 
Io per esempio su OS X ho proprio il gcc, ma *non* ho la glibc. Ho
invece la libreria C usata nei BSD. Non è che non la uso e basta: non la
ho proprio installata. 
Penso di averti dimostrato oltre ogni ragionevole dubbio che il
compilatore e la libreria standard sono in se due concetti separati,
sebbene lo standard imponga che ci sia installata una libreria standard.
Possono venire da due vendor separati, e chi implementa un compilatore
può anche non implementare una libreria standard e viceversa. Da questo
parlare di 'header del compilatore' è un po' come parlare di 'zampe del
carretto', visto e considerato che i carretti sono tirati da persone o
animali che hanno gambe o zampe.
Pensa addirittura che parlando di 'header del compilatore' io immagino
proprio gli header del compilatore inteso come sorgente di un programma
tipicamente C. Quelli in cui vengono definite le strutture dati e
dichiarate le funzioni che sono usate per realizzare un compilatore C.
Ma a questo punto non vedo bene che senso abbia chiamarle 'standard'. 


 parlando di farfalle.
Da questo punto in avanti ogni ulteriore discussione è del tutto
inutile.  Vedo che hai le tue convinzioni che naturalmente non
coincidono con le mie.  E continuo a mantenerle, confortato
dall'esperienza di venti anni di uso del C e di qualche decina di
ambienti di sviluppo.
Ti ringrazio solo di non essere passato alle offese cercando invece di
controbattere civilmente ma ritengo che sia inutile continuare una
polemica che non porta ad alcun risultato.
Ciao
Giovanni


 polemica che non porta ad alcun risultato.
La mia non è polemica e non è mio costume insultare. Io porto avanti
esclusivamente argomentazioni tecniche (e non supposizioni sul mio
interlocutore, le quali lasciano *sempre* il tempo che trovano). Ho
postato fatti e argomentazioni tecniche. 
Sono abbastanza convinto che se io avessi torto, avresti potuto
facilmente controbattere le mie affermazioni sfruttando la tua
esperienza. Mi chiedo per quale motivo pensi di avere ragione se non
puoi esprimere quel motivo per iscritto. Tutto qui. 


 [...]
Manlio Perillo

 puoi esprimere quel motivo per iscritto. Tutto qui. 
Da  
http://en.wikipedia.org/wiki/C_standard_library
The name and characteristic of each function are in a computer file 
called a header file but the actual implementation of functions are 
separated into a library file. The naming and scope of headers have 
become common but the organization of libraries still remains diverse. 
The standard library is usually shipped along with a compiler. Since C 
compilers often provide extra functionalities that are not specified 
in ANSI C, a standard library with a particular compiler is mostly 
incompatible with standard libraries of other compilers.
Both Unix and C were created at AT&T's Bell Laboratories in the late 
1960s and early 1970s. During the 1970s the C programming language 
became increasingly popular. Many universities and organizations began 
creating their own variations of the language for their own projects. 
By the beginning of the 1980s compatibility problems between the 
various C implementations became apparent. In 1983 the American 
National Standards Institute (ANSI) formed a committee to establish a 
standard specification of C known as "ANSI C". This work culminated in 
the creation of the so-called C89 standard in 1989. Part of the 
resulting standard was a set of software libraries called the ANSI C 
standard library.


 standard library.
Ma è chiaro che hai quotato un pezzo di roba che ti da *precisamente*
torto? :)
Non costringermi ad indicare quali punti contraddicono la tua propria
posizione. 


 POSIX non saprei, ma la Single Unix Specification è aggiornata a C 99
TY. In teoria gli sforzi dei due gruppi di standardizzazione non sono
stati uniti?


 standard library.
Guarda che a meno di fortissime incomprensioni di quello che hai scritto
in precedenza, questo articolo che riporti ti darebbe torto.


 
Si ci sono evidentemente da parte tue fortissime incomprensioni 
dell'inglese.  Come traduci le frasi "Since C compilers often provide 
extra functionalities that are not specified in ANSI C, a standard 
library with a particular compiler is mostly incompatible with 
standard libraries of other compilers" e "a set of software libraries 
called the ANSI C standard library"?
E se hai la pazienza di rileggere la documentazione di qualche 
compilatore vedrai che sempre si parla delle librerie standard del 
compilatore senza MAI sottintendere ANSI.


Giovanni ha scritto:

non voglio entrare nel merito della questione dato che è stata esposta 
nei minimi particolari evidenziando il fatto che ci sono più di una 
forma mentis relativamente allo standard..vorrei solo dire a Giovanni 
che wikipedia non può essere certo apposto coem principio di auctoritas...

 Che poi per te non esistano gli header come standard del compilatore 
L'espressione "standard del compilatore" è un non-sense.


 compilatore senza MAI sottintendere ANSI.
Ognuno, nel suo piccolo, può riferirsi ai propri standard e il discorso,
nel caso, è specifico e limitato al contesto. Nel contesto generale,
invece, quando si parla di "standard", laddove non altrimenti specificato,
si parla di standard ISO C. E' il modo naturale di intendere le cose;
naturale per tutti, meno per certi Falzoni che amano nuotare
controcorrente e vogliono a tutti i costi alimentare polemiche inutili.
Chiudo qui.


 controbattere civilmente
I tuoi "LOL" erano un modo di farlo, immagino.
Con gente come te non si puņ "controbattere civilmente".


 
Che cazzo vuoi non stavo discutendo con te!


 non si può "controbattere civilmente".
ROTFL (se non ti va bene LOL) !


 compilatore senza MAI sottintendere ANSI.
Se poi vai dall'oste e lui ti parla di vino pensa, intenderà proprio il
suo.
Dopo di che c'è una cosa che si chiama *standard* che definisce degli
header *standard*. Se poi tu ti vuoi ostinare a chiamare standard tutti
gli header dati con ogni dato compilatore, stai definendo il concetto
'header standard' allo stesso modo di 'header'.
La definizione classica e universalmente riconosciuta è invece molto più
utile: un header standard è un header che ovunque tu compili (lasciando
stare le eccezioni di piattaforme non conformi) lo trovi e puoi usare le
funzioni ivi dichiarate. Questo è un concetto utile. Ed è un concetto
che ti porta verso un concetto di *portabilità*.
Questo non vuole dire che bisogna usare *solo* la roba standard,
beninteso. Ma distinguere quello che è parte di uno standard, di un
altro o una mera estensione del compilatore è completamente necessario e
rilevante. Questo è rilevante *sia* per le questioni di libreria sia per
le questioni di linguaggio, beninteso.


 stati uniti?
http://www.opengroup.org/austin/papers/single_unix_faq.html
New for this version of the Single UNIX Specification is the 
incorporation of IEEE Std 1003.1 (POSIX) and ISO/IEC 9945 into the 
document set; The Open Group Base Specifications, Issue 6, ISO/IEC 9945 
and IEEE Std 1003.1, 2004 Edition are technically identical. The base 
document for the joint revision of the documents was The Open Group's 
Base volumes of its Single UNIX Specification, Version 2. These were 
selected since they were a superset of the existing POSIX.1 and POSIX.2 
specifications and had some organizational aspects that would benefit the 
audience for the new revision.
Comoda anche la lista completa delle interfacce:
http://www.unix.org/version3/inttables.pdf
Peccato che non ci sia (almeno non l'ho trovato) un documento con tutte 
le modifiche alle funzione C99 fatte dalla SUSv3 (ma nelle man pages 
online queste differenze sono ben marcate).
Saluti e buon 2008  Manlio Perillo

 Che cazzo vuoi non stavo discutendo con te!
Me ne frega poco. C'č gente che legge i tuoi messaggi e corre il pericolo
di crederti. Se vuoi polemizzare direttamente con qualcuno, esiste la
posta elettronica. Finquando sei in un gruppo, ti becchi i messaggi di
tutti.
Che ti piaccia o meno.


 Neanche types.h fa parte delle librerie standard.
mi può capitare di richiamare con un LOL simili affermazioni sia
pensando a quando anche io incominciavo ad usare il C, sia al fatto
che in molte occasioni sono proclamate con arroganza e presunzione da
un certo personaggio che posta su questo NG.
Scusa se l'ho tirata in lungo, ma anche oggi è vacanza ed i nipoti se 
ne sono partiti lasciando libero il computer :-)
Ciao
Giovanni
[*]  -----
Il newsgroup tratterà del linguaggio C, ideato da Brian W. Kernighan e
Dennis M. Ritchie.
Il newsgroup tratterà di qualsiasi dialetto del linguaggio C, in modo
particolare del vecchio K&R e di quello specificato dall'istituto
americano ANSI come standard "ANSI X3.159-1989" e ratificato
dall'istituto internazionale ISO come standard "ISO/IEC 9899:1990".
Argomenti compresi:
  - Il linguaggio in generale;
  - Gli algoritmi;
  - Le ottimizzazioni;
  - La portabilità;
  - I sistemi di sviluppo.
-----
[**] definizioni della voce standard.
standard - 
http://www.demauroparavia.it/114332
 (DeMauro)
modello, norma, criterio assunto come termine di riferimento
prestabilito a cui uniformarsi.
standard - 
http://www.m-w.com/dictionary/standard
 (Webster)
a structure built for or serving as a base or support.


 tutti.
Allora impara ad essere educato.


 un certo personaggio che posta su questo NG.
Quelle affermazioni non meritano i tuoi stupidissimi LOL perché sono la
pura, sacrosanta verità. La vera arroganza e presunzione è quella di
ignoranti, incompetenti come te, che si "arrogano" appunto il diritto di
criticare verità giustissime con penosi arrampicamenti sugli specchi come
quello che stai facendo da un bel po' di messaggi a questa parte.
Taci e farai un favore, oltre che agli sventurati lettori dei tuoi post,
anche alla tua poverissima persona.


Non dico altro perché credo di aver spiegato tutto.  Deve essere 
brutto vivere coi paraocchi, ma del resto visto che non hai mai 
progettato fa poca differenza.  Mi dispiace proprio per i tuoi allievi 
costretti a convivere con un insegnante come te.
Ciao
Giovanni


 progettato fa poca differenza.
Quello che io ho progettato tu non lo conosci, non conosci le persone che
ho diretto, né io perderò tempo a discutere con un imbecille come te la
mia competenza.


Ora hai rotto i coglioni. Uno come te non meriterebbe ulteriore 
attenzione ma siccome non sai fare altro che offendere prenditi un bel 
vaffanculo.
PLONK

Ciao,

so che non centro nulla e che non dovrei intromettermi ma mi sento di
dire che secondo il mio modesto parere la posizione di Andrea mi pare 
del tutto corretta anche perché le motivazioni sono sicuramente corrette.
Se si desidera un luogo di discussione del linguaggio 'c' calato sullo 
specifico compilatore / ambiente / standard "proprietari" forse non
si tratta del NG adatto, la domanda iniziale, giusto per fare un poco
di ordine, è stata :
 >Ciao a tutti.
 >Stavo notando che sul mio sistema (Linux Ubuntu Gutsy) esistono diversi
 >file con nome wait.h, salvati in diverse directory.
 >In particolare, essi sono:
 >/usr/include/wait.h	
 >/usr/include/sys/wait.h	
 >/usr/include/linux/wait.h	
 >
 >Inoltre, ho visto che il primo include il secondo.
 >Vorrei capire se è così in tutti i sistemi oppure se è una >particolarità
 >della mia distribuzione di Linux.
 >Il problema che mi pongo è, in realtà, più generale, e cioè: se in un
 >programma C inserisco l'istruzione
 >#include <wait.h> /*ma il discorso si può estendere ad altri header
 >files */
 >vado incontro a potenziali problemi di portabilità?
 >Il dubbio mi è sorto perchè, in alcuni esempi sulla programmazione di
 >sistema scritti dai miei docenti universitari, trofo sempre
 >l'istruzione:
 >#include <sys/wait.h> /*ed è così anche per types.h ed altri header
 >files*/
 >
 >Un saluto e grazie mille.
 >
 >Bizio.
 >
Credo che il fatto di dire che non esiste nessuna certezza rispetto al 
file wait.h, visto che non è contemplato dallo standard ma è un 
estensione, non mi pare una emerita castroneria ma una risposta alla 
domanda principale.
"posso trovare problemi nell'includere questo .h nei miei sorgenti?"
la risposta è stata si in quanto quelle include non sono certe in
tutti gli ambienti di sviluppo.
 >Certamente, non trattandosi di headers standard.
 >
 >>...così anche per types.h ed altri header
 >> files*/
 >
 >Neanche types.h  fa parte delle librerie standard.
 >
 >Giorgio
Non mi pare una ca...ta anzi..............
Se poi vogliamo dire che sviluppando su sistemi "normali" queste include
ci sono è un'altra cosa ma non si può dire che siano standard.
Luca

 
A parte che ti pregherei di leggere la mia risposta al post originale
http://tinyurl.com/ywfk3m
 ho espresso un mio concetto su cui si può 
essere o meno d'accordo.  Lo standard ANSI/ISO è una bella cosa ma 
bisogna convivere con la realtà e quando si scrive un programma devi 
attenerti a quella.  A qualcuno non piace.  Fortunato chi può lavorare 
in un ambiente ideale come lo vede lo *standard*.
Ma anche a me non piace una risposta come ha dato Giorgio (e che ti 
ribadisci), come non piace l'atteggiamento di altri frequentatori 
(sic!) dove si insiste che standard è automaticamente sinonimo di 
"standard ANSI/ISO". Il NG non riguarda solo quello ed ogni dialetto 
dovrebbe essere accettato.
Non credo di diffondere idee stravaganti (come qualcuno vuol far 
credere), ma semplicemente credo di raccontare una realtà con cui ci 
si scontra quando si lavora.  Non so se hai già vissuto l'esperienza 
di inserirti in un ambiente di lavoro, ma ti posso assicurare che 
tutti quelli che iniziano con radicate le idee del *professore* si 
devono presto abituare ad un ambiente diverso.
Non piace l'affermazione che compilatore/librerie/headers costituisca 
uno standard di fatto per l'ambiente di sviluppo. Va bene accetto le 
contestazioni ma non le offese perché non sono quelle che possono 
farmi cambiare idea.


 farmi cambiare idea.
Vabbé, qui ognuno la pensa come vuole. Francamente, per quanto mi riguarda,
in un newsgroup tecnico la (mancanza di) gentilezza/educazione mi lascia
abbastanza indifferente. Non vengo qui per cercare degli amichetti. Se poi
dichiaro che chi non la pensa come me ha i paraocchi, troverò qualcuno che
mi dà dell'imbecille. E' un fatto fisiologico, direi.
Max

Ognuno coltiva le proprie opinioni, specialmente se maturate con 
l'esperienza sul lavoro :-)


 uno standard di fatto per l'ambiente di sviluppo.
Ma è piuttosto insolita questa frase: ci sono *standard-de-facto*.
Questo è indubbio. Su Windows la piattaforma di sviluppo Microsoft. Su
Linux quella GNU. Ma uno standard de facto è una cosa tendenzialmente
diversa: un conto è constatare che in un dato ambito una piattaforma è
diffusissima (ed eventualmente scegliere di perdere portabilità e
scrivere per quella). Un altro è affermare che quella cosa sia uno
standard tout court. E questo è indimostrabile: lo standard è stato
ratificato ed è un'altra cosa: gestisce *alcuni* aspetti e ha un ruolo
sostanzialmente differente.
Al post lunghissimo sto pure rispondendo, ma ci vuole tempo.


 uno standard di fatto per l'ambiente di sviluppo.
Ma è piuttosto insolita questa frase: ci sono *standard-de-facto*.
Questo è indubbio. Su Windows la piattaforma di sviluppo Microsoft. Su
Linux quella GNU. Ma uno standard de facto è una cosa tendenzialmente
diversa: un conto è constatare che in un dato ambito una piattaforma è
diffusissima (ed eventualmente scegliere di perdere portabilità e
scrivere per quella). Un altro è affermare che quella cosa sia uno
standard tout court. E questo è indimostrabile: lo standard è stato
ratificato ed è un'altra cosa: gestisce *alcuni* aspetti e ha un ruolo
sostanzialmente differente.
Al post lunghissimo sto pure rispondendo, ma ci vuole tempo.


 sostanzialmente differente.
E qui proprio non ci capiamo perché tu interpreti "standard" come 
"standard ANSI/ISO" mentre ripeto per me diventa lo standard secondo 
cui devo scrivere il codice, sia che siamo qui a discutere su iclc che 
siamo a discutere in ufficio o al bar.
Inoltre standard di fatto non lo intendo come lo intendi tu.  Ripeto 
che io ritengo che *ogni* pacchetto di sviluppo in un certo ambiente 
impone un modello che devo rispettare per scrivere un programma.
Poi possiamo discutere sul significato della parola standard ma dato 
che ad un certo punto è una questione linguistica mi sembra che 
fondamentalmente sia qui dove l'interpretazione discorda.


 fondamentalmente sia qui dove l'interpretazione discorda.
Esatto.
