Newsgroup: it.comp.lang.c++
Titolo: int *a=new int[10];

se ho un array
int a[10];
contiene dei valori arbitrari che non sono 0
se invece scrivo int a[10]={1,2};
contiene 1 2 0 0 0 0 0 0 0 0
vorrei sapere
se allocando mem dinamicamente
int *a=new int[10];
e possibile inizializzare a con la scrittura di prima a parentesi graffe
in pratica assegnando 0 al primo elemento si potrebbe evitare un ciclo
for(inti=0;i<10;i++)
    a[i]=0;

 e possibile inizializzare a con la scrittura di prima a parentesi graffe
No, non a norma di standard.
Avrete le vostre ragioni per accanirvi ad usare gli array invece
di std::vector, ragazzi, ma sta proprio diventando ridicolo... uno
std::vector, al resize, inizializza tutti gli elementi al default (per
int, il default in questione e` 0).  PERCHE` array...?!
Alex

 PERCHE` array...?!
Suppongo per pigrizia... tutt'al piu` l'unica ragione
valida potrebbe essere quella di dover lavorare su
un compilatore non standard.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

Alex Martelli wrote:

Credo che bisognerebbe dare merito al C di avere qualche motivo per aver
scelto di avere array built-in invece che inclusa con un header; e di avere
una politica
di header files e librerie standard invece di avere tutto incluso (come il
buon
vecchio q-basic...).
Per esempio, io uso un pentiumIII 500 e ho comunque tempi di ricompilazione in
visual C++ 6.0 molto maggiori da quando ho introdotto l'uso dei vector.
Suppongo (non ho verificato) che anche l'eseguibile sia piu' grosso.
Credo che l'idea originaria che sta dietro gli header file di libreria
standard sia quello di
"pagare per quello che si usa": se il programma non usa la libreria
matematica, la libreria matematica non e' inclusa nel programma...Allo stesso
modo, se non si ha interesse ad usare le feature di <vector> non lo si
dovrebbe usare.
Insomma, non mi sembra che lo standard dica: l'uso di int a[8] e' deprecato...
Credo anche pero' che considerazioni di dimensione del programma e di
efficienza di compilazione siano oggi un po' anacronistiche; e molto piu'
attuali considerazioni di standard, di protezione da errori, di design.
Si dunque a spingere le persone ad usare <vector> invece di built-in arrays:
ma addirittura ridere di loro, forse e' un po' esagerato.
Guido
P.S. La singola, tragica controindicazione all'uso non solo di <vector> ma
pure dell'intera libreria standard nella sua parte STL e' compiler-dependent:
il Visual C++ non supporta nel debugger nomi piu' lunghi di 256 caratteri, il
che rende praticamente inusabile il debugger con le STL! Per me e' un dramma!
Basta questo per sconsigliarne l'acquisto...

 int, il default in questione e` 0).  PERCHE` array...?!
Perchè i professori universitari di fondamenti I e II non ti permettono di
usarli perchè spesso lo scopo del corso è capire e dunque progettare delle
strutture dati!
Poi è logico che chi deve imparare da zero parte dalle cose base!
--
| /
| \Byte - Andrea Briganti
E-Mail 
kbyt...@freemail.it
ICQ 40872731

 Poi è logico che chi deve imparare da zero parte dalle cose base!
Sarebbe come dire che non ti lasciano usare le moltiplicazioni
(operator*, per intenderci) perche` devi imparare che una
moltiplicazione e` internamente realizzata con shift-and-add,
e quindi ogni volta che vorresti scrivere "a*b" devi invece
scrivere un ciclo di shift-and-add.
Il modo giusto di imparare e` iniziare dal SEMPLICE (nulla di
piu` semplice di std::vector) e passare solo dopo, e se mai
occorrera`, al COMPLICATO (la _implementazione_ di quelle
strutture di alto livello che, "da fuori", sono cosi` "semplici";
la loro "realta` interiore", per cosi` dire).
Tutti devono sapere usare la moltiplicazione (tutti coloro che
vogliono chiamarsi programmatori C++ devono essere del
tutto familiari con std::vector).  Pochissimi hanno veramente
bisogno di sapere come una moltiplicazione sia realizzata
internamente con shift e add (pochissimi hanno veramente
bisogno di sapere come std::vector possa essere realizzato
internamente con array &c), anche se capisco che a livello
universitario si voglia comunque dare anche questa "base
culturale" di bassissimo livello -- ma DOPO che le cose
semplici e veramente utili sono state presentate.  Proprio
come, ad esempio, l'aritmetica (l'uso concreto dei numeri)
si insegna PRIMA della sua assiomatizzazione (base formale
e profonda), tipo assiomi di Peano, filtri di Cauchy o altra
assiomatizzazione dei reali, eccetera.
Alex

 Basta questo per sconsigliarne l'acquisto...
Sarebbe certamente ora che il debugger di VC++ imparasse a usare
sinonimi abbreviati per certi nomi di tipi, sopratuttto quelli
esageratamente
lunghi che altrimenti risultano dall'espansione di template qualsivoglia
(sia che vengano dalla libreria standard, sia che no).
Occasionali scomodita` nel debugging non sono certo una valida
controindicazione all'uso di una delle feature piu` importanti del
C++, cioe` la genericita` (i template), in ogni sua forma.
Alex

 ma addirittura ridere di loro, forse e' un po' esagerato.
Penso che il discorso fosse più che altro tra puntatori ed array
allocati dinamicamente vs. std::vector che non tra quest'ultimo e array
built-in.
EMG

assiomatizzazione dei reali, eccetera.
Qui entrano in gioco altri fattori... dubito che un bambino di 7
anni possa affrontare un approccio rigoroso e formale
(cosa invece che ci si puo` aspettare da un universitario).


 tutto familiari con std::vector).
Vedi, i vari corsi usano si il C++ o il Pascal (FO I), ma l'intento è quello
di dare una preparazione tale da permettere allo studente di avere un
bagaglio di tecniche di programmazione, algoritmi base, modo di ragionare
per algoritmi e basi dati; questo per permettergli di mettere mano su
qualsiasi linguaggio agevolmente rispolverando solo la sintassi del
linguaggio.


 avere studiato nulla di anatomia e delle problematiche fisiche di un
cuore.
Analogia fallace, poiche` il cardiochirurgo interviene direttamente
su detta anatomia: non vi sono livelli superiori di astrazione che
siano appropriati al suo lavoro.
Vi sono invece tanti livelli inferiori di astrazione, come i dettagli
della biochimica molecolare, su cui puo` (euristicamente) fargli
comodo una "infarinatura", ma NON sono rilevanti relativamente
a come deve muovere il bisturi (possono, se mai e ad un qualche
livello, essere appropriati per un DIVERSO specialista, tipo un
anestesiologo).
[continua]
Alex

 linguaggio.
I linguaggi non differiscono solo per sintassi (anzi, e` il meno) ma
anzitutto per semantica.  Pensare che "rispolverare la sintassi" sia
la cosa piu` importante mostra una totale mancanza di comprensione
delle realta` fondamentali dell'informatica.
Considera ad esempio questi frammenti:
Java:
int pluto(Pippo a, Pippo b)
{
     a.plup(b);
     return a.klop();
}
C++:
int pluto(Pippo a, Pippo b)
{
     a.plup(b);
     return a.klop();
}
Visual Basic:
Declare Function pluto(a as Pippo, b as Pippo) as Integer
    call a.plup b
    pluto = a.klop
End
Lo stolto che pensa che la sintassi sia la cosa importante si
illude che il frammento Java e quello C++ facciano la stessa
cosa, quello superficialmente tanto diverso in VB invece ne
faccia un'altra; e non capisce che sono invece i frammenti
Java e VB ad essere identici ed equivalenti, mentre quello
C++ differisce per un aspetto DAVVERO fondamentale, in
quanto semantico.
Le simiglianze sintattiche ingannano, proprio come, nel
problema dei "falsi amici" nell'apprendimento delle lingue
naturali, ingannano le simiglianze lessicali.
Alex

 (cosa invece che ci si puo` aspettare da un universitario).
Ma quando (anche all'universitario, se non e` gia Dottore in
Matematica o giu` di li`) insegni un'assiomatizzazione astratta
di qualcosa _di cui non ha nessun modello di riferimento_,
_nessuna prassi d'uso_, tendi a perderlo per strada.
PRIMA la "prassi d'uso"; ad esempio, la formalizzazione (ad
es. di Peano) dell'aritmetica naturale.
POI l'assiomatizzazione rigorosa: l'algebra astratta, almeno
sino a semigruppi, gruppi, gruppi abeliani...
Se no e` come insegnare una lingua *partendo* dalla
grammatica, come si faceva una volta, ai brutti tempi in
cui la didattica delle lingue era all'abisso.  Oggi si parte
dalla pratica viva, POI gradualmente si introduce l'assieme
di approssimative "regole" che definiamo grammatica, DOPO
che lo studente inizia ad avere una prassi d'uso della lingua.
(Non necessariamente si fa cosi` nelle scuole... appunto
per questo, "conoscenza della lingua X a livello
scolastico" significa "poco o nulla" -- i livelli di conoscenza
sono appunto "nessuno", "scolastico", "scarso", "discreto",
"buono", "ottimo", "madrelingua"...:-).
Alex

fruttuosamente.
sicuramente, ma lo si apprezza di piu` sapendo che farne a
meno significa complicarsi la vita... non credi?


 faccia un'altra;
Si, però sai anche che così come una persona che ha un certo bagaglio
generale è capace di apprendere rapidamente la nuova sintassi, fa una cosa
simile con le differenze di semantica.
Prova invece a far emigrare una persona che conosce quasi escusivamente le
stl e un livello di astrazzione elevato e non quello a più basso livello a
farlo emigrare al VB, Java (già qui ci sono mille analogie con il C++).


 programmatore senza capire niente di fisica quantistica?
Si, ma cosa c'entra con la programmazione a basso livello?
Spesso e volentieri vedo gente che conoscendo giusto l'essenziale si reputa
un super esperto, quando però devono cercare determinati risultati dove non
bastano solo le conoscenze "facili".
Un programmatore che esce da una laurea in ingegneria informatica dovrebbe
essere capace di programmare dalle applicazioni gestionali (e li le
astrazioni ci sono eccome proprio per agevolarsi la vita) a un driver di
periferica (anche qui l'astrazione è alta, basta pensare al kernel di linux,
ma senza il basso livello per crearle...)
Ci sono casi dove devi creare tu stesso una astrazione per terzi che però
gestiscono cose a basso livello o ottimizzate meglio mediante il basso
livello.
Vero, l'astrazione è una cosa fondamentale, come tu stesso hai scritto nel
subject, senza di essa programmeremmo ancora in linguaggio macchina, ma non
negerai che in alcune situazioni è meglio usare delle procedure in assembler
per svolgere alcuni (rari) compiti.


 per svolgere alcuni (rari) compiti.
Senza dubbio qualche caso ci sara`, anche se dubito che le "procedure"
in questione siano ottimalmente scritte da esseri umani.  Ancora pochi
anni fa traevo beneficio dall'uso dell'assembler (praticamente l'unico a
scrivere, rarissimamente, in assembler, per le esigenze di decine di
colleghi); al giorno d'oggi abbiamo eliminato i residui di assembler.
Ma gia`, noi facciamo CAD 3D, senza dubbio qualche altra area di
applicazione, piu` esigente sulle prestazioni, dovra` pur esistere:-).
La conoscenza dell'architettura di macchina continua ad essere utile
(diciamo mezza giornata ogni mese) per capire casi particolarmente
incasinati (considera che in questo ruolo di "il guru dei bassi livelli"
supporto ormai centinaia di colleghi -- siamo cresciuti, e non certo
per l'abbondanza di assembler ed altre robe di basso livello... -- se
fosse solo per le esigenze del software che progetto e sviluppo io,
saremmo sotto la mezz'oretta all'anno, penso:-).
In confronto, la comprensione di new[] e soci risulta molto meno
utile.  *Ogni volta* che ho visto usare questo costrutto, ho
suggerito di cambiarlo in std::vector<>, e ho ricevuto obiezioni,
approfondendo le cose e` emerso che le obiezioni erano prive
di fondamento, e il passaggio a std::vector<> si e` rivelato un
sostanziale miglioramento.  (Esclusa sempre la manutenzione
di codice-legacy, scritto prima della nascita del C++ Standard).
Se gli esseri umani disponessero di tempo ed energia infiniti,
senza dubbio, UN dannato caso prima o poi si troverebbe.
Visto che cosi` non e`, ritengo un assurdo spreco di risorse
limitate quello di profondere cosi` tanta energia in aspetti
di basso livello e marginale utilita`, quando esistono infinite
splendide opportunita` di "investimento" di queste risorse in
compiti MOLTO piu` produttivi, redditizi, e gratificanti.
Nonche`, sia detto per inciso, molto piu` concretamente
formativi per la professionalita` individuale.
Alex

 formativi per la professionalita` individuale.
Si, ma non per qualsiasi linguaggio! Esistono ancora linguaggi procedurali
che non offrono strutture dati equivalenti, e si rischia di imparare al
semplice studente solo quelle col rischio di non permettergli di operare
agilmente dove le cose sono diverse.


 agilmente dove le cose sono diverse.
I linguaggi piu` importanti sono la propria lingua madre (chi, ad
esempio, confonde i verbi "imparare" ed "insegnare", se e` di
madrelingua italiana, ha dei problemi:-) e l'inglese.
Quanto ai linguaggi procedurali, che cale che uno sappia usare
new[] con tutti i suoi casini tipici solo del C++ (necessita` di
default ctor, uso di delete[] e non delete, ecc ecc) per passare,
che so, a Cobol, o all'antico Pascal?  Li` le cose sono comunque
in termini del tutto diversi!
Alex