Newsgroup: it.comp.programmare
Titolo: Iniaziare un programma in C++

Ciao a Tutti,
sono nuovissimo del c++, e volevo porvi una domanda anche se penso sia
ancora troppo presto.
Ho iniziatoi a leggere alcune guide per imparare il linguaggio, ed credo di
aver assimilato se, se ben poche, alcune nozioni.
La mia domanda č questa:
DA DOVE SI INIZIA UN PROGRAMMA???
leggo e leggo ma nn so da dove iniziare, Possiedo Visual c++ 6.5 della
Microsoft, e nn lo conosco ancora molto bene.
Qualcuno mi puň aiutare?
NN ce bisogno che mi inviate manuali sul c++, ne ho in abbondanza, io vorrei
sapere da dove posso iniziare (ammettendo che so gia che programma fare)
Grazie, spero che mi diate una mano
VISUAL C++ č un po complesso :P

 DA DOVE SI INIZIA UN PROGRAMMA???
dalla documentazione: Spec, ADD, DDD, ICD... l'incubo di ogni programmatore!
Ma probabilmente a te serve una sequenza tipo File -> New Project -> 
Standard Executable, o qualcosa del genere (purtroppo non ricordo i nomi 
giusti non usando piu' VC++ da mesi).
Happy coding!
Kelvin
-- 
there is no place like /home

 Microsoft, e nn lo conosco ancora molto bene.
Essendo uno strumento nuovo, ti consiglio di utilizzare il wizard, che fa
tutto lui per te.

 delle classi, od un'insieme di classi, che assolvono a dei compiti, 
questo e` vero solo se hai deciso di programmare seguendo il paradigma 
OO. In C++ puoi programmare efficacemente anche seguendo altri 
paradigmi...
ciao Anto
-- 
Antonio Cuni, 20 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 paradigmi...
Non ha molto senso usare il C++, se non vuoi programmare ad oggetti, tanto
vale usare il buon vecchio C, però ti perdi molte cose che il paradigma OO
ti offre, come l'incpsulamento delle informazioni, tanto per dirne una.
Ciao.

 per dirne una.
com'è che ho sempre sentito dire che anche solo usare il compilatore C++
usando il subset C ne vale la pena?
-- 
Rhymes
rhy...@myself.com
" ride or die "

...


 per dirne una.
e` falso. Ha perfettamente senso utilizzare il C++ con altri paradigmi 
diversi da quello OO. Ci sono molti domini applicativi in cui l'OO non 
e` la scelta migliore e il C++ consente di volta in volta di scegliere.
Se escludiamo alcune situazioni particolari ha anche poco senso 
utilizzare il C al posto del C++; ecco alcuni vantaggi del C++ rispetto 
al C non necessariamente ricollegabili al paradigma OO (i primi che mi 
vengono in mente):
- libreria standard *notevolmente* piu` ampia
- template
- funzioni inline
- maggior controllo sui tipi
- reference
Per la cronaca, ecco una citazione:
"Il C++ e` stato progettato per supportare l'astrazione dei dati, la 
programmazione orientata agli oggetti e la programmazione generica, 
oltre alle tecniche di programmazione C tradizionali sotto questi 
vincoli. Non e` stato pensato invece con l'intento di forzare tutti i 
programmatori a seguire un particolare stile di programmazione."
(Bjarne Stroustrup, 'The C++ Programming Language, 3rd edition')


 - reference
Beh, mi sembra piů corretto dire che alla libreria standard del C, si
aggiunge la Standard Template Library.
Che ti mette a disposizione dei contenitori, che guarda caso "sono classi":
hanno costruttori, distruttori e metodi....
che fanno delle cose, come... non si sa, ma lo fanno: č si č molto contenti
che lo facciano! :-)
Oltretutto, sempre per rimanere in ottica di paradigma OO, se provi ad usare
un vector e poi ti accorgi che questo non va bene: non č vero che lo puoi
sostituire in modo trasparente con una deque?
Non č vero puoi scrivere sia vector<int>pippo, e poi sostituirlo con
deque<int>pippo, in modo trasparente?
Ciao.
Maurizio. ;-)

 Maurizio. ;-)
ciao,
zello
PS: non è una guerra di religione. Per certe cose l'OO va benissimo,
per altre è meglio un filo di programmazione generica, per altre
ancora basta usare il paradigma procedurale... E non è neanche detto
che non si possano mischiare. ATL (che comunque non conosco bene)
dovrebbe essere una buona miscela di templates e gerarchie di classi

 deque<int>pippo, in modo trasparente?
no, non posso sostituire vector e deque in modo trasparente; ecco alcuni 
passi tratti dall'item 2 di Effective STL, by Scott Meyers; l'item si 
intitola eloquentemente "Beware the illusion fo container-indipendent 
code":
The main culprit is the different rules for invalidation of iterators, 
pointers, and references that apply to differenent sequence containers.
[...] The different containers are *different* [...] They are not 
designed to be interchangeable, and there's little you can do to paper 
that over.
Tanto per fare qualche esempio di codice che *non* supporta il 
cambiamento da vector a deque o viceversa:
void foo()
{
        vector<int> v;
        v.reserve(100);
        ...
        if (v.capacity() > v.size()) v.push_back(10);
}
void bar()
{
        deque<int> d;
        d.push_front(10);
        d.pop_front();
}
void pippo(deque<bool>& d)
{
        bool* ptr = &d[0];
}
int pluto(vector<int>& v)
{
        vector<int>::iterator beg = v.begin();
        v.erase( beg+v.size()/2, v.end() );
        return *beg;
}
Motivare il perche` questi pezzi di codice non funzionerebbero in caso di 
cambio di container e` lasciato come esercizio al lettore... :-))


 le metodologie object oriented.
Non capisco il perche'.
Di certo non si puo' affermare che la metodologia OO non e'
adatta alla scrittura di un compilatore.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 PS: non č una guerra di religione.
sono perfettamente d'accordo. E' solo uno scambio di idee...

 un'estensione delle strutture del C.
Rispetto al C, ne sono sicuramente un'estensione, rispetto al C++,
sono esattamente la stessa cosa (a meno dello scope di visibilita' 
predefinito dei membri).


 e` la scelta migliore e il C++ consente di volta in volta di scegliere.
A mio avviso, programmare in C++ senza usarlo a oggetti, e' come
acquistare una costosissima auto sportiva e lasciarla in garage .... ;)
 Raffaello

 adatta alla scrittura di un compilatore.
probabilmente mi sono espresso male. Pero` esiste una tale bibliografia e 
quantita` di tool semi-automatici che un approccio procedurale mi pare 
quanto meno piu` produttivo.
Personalmente non ho mai sentito parlare di compilatori progettati 
secondo l'OO, ma magari mi sbaglio...


 sensazione che sia la deque ad avere delle interfacce in piů)
personalmente ritengo che sarebbe meglio evitare di parlare per 
"sensazioni"; cmq in linea di massima vector e deque hanno la stessa 
interfaccia *sintattica* (ma non sempre una uguale semantica), con le 
seguenti eccezioni:
1) vector dispone dei metodi reserve() e capacity()
2) deque dispone dei metodi push_front() e pop_front()


acquistare una costosissima auto sportiva e lasciarla in garage .... ;)
No è come usare C++ a meno del 50% ma niuno te lo proibisce


 secondo l'OO, ma magari mi sbaglio...
Si`.  PCCTS e ANTLR ad esempio sono diffusissimi framework a
oggetti per lo sviluppo di compilatori -- il primo, basato su
C++, un po' datato e stantio, ANTLR2, basato invece su Java,
e vivissimo nonche` davvero eccellente (si puo` usare anche
con C++, ma questo pare sia poco documentato).
Dai un occhio a 
www.antrl.org
 e resterai estasiato.
Alex

oggetti per lo sviluppo di compilatori --
compilatori noti sviluppati con questi framework?


 compilatori noti sviluppati con questi framework?
Vedi il sito che ho gia` indicato, 
www.antrl.org
.  Comunque, e
non mi pare che sul sito sia indicato, Jython 2.2 usa ANTLR:-).
Alex

non mi pare che sul sito sia indicato, Jython 2.2 usa ANTLR:-).
devo decidermi a provarlo Jython...dato che un pò di Java (con cui ho
imparato i rudimenti dell'OOP) lo mastico ancora... ma non siamo fermi
alla 2.1?


 alla 2.1?
La 2.1 e` l'ultima attualmente rilasciata, la 2.2 in corso di sviluppo.
Alex

 "sensazioni";
su questo, invece non sono d'accordo, quello che scrivi, non è una cosa
asettica, ma viva, e riuscire a sentirla ed a percepire i suoi movimenti, ti
aiuta di molto a controllarla ed a fargli fare quello che vuoi, anziché,
essere te a fare quello che vuole lei.
ciao,
Maurizio.

La 2.1 e` l'ultima attualmente rilasciata, la 2.2 in corso di sviluppo.
Ok tanto vale che aspetti quest'ultima tanto ne ho di cose da
apprendere nel frattempo! :)


 acquistare una costosissima auto sportiva e lasciarla in garage .... ;)
non vedo perche`:
una costosissima auto sportiva e` stata costruita e comprata per andare 
su strada: se la tieni in garage vai contro la sua natura.
Al contrario il C++ e` stato progettato per essere *multiparadigma*: 
utilizzarlo come se fosse monoparadigma va (parzialmente) contro la sua 
natura, mentre utilizzare il C++ senza utilizzare il paradigma OO e` uno 
degli scopi del linguaggio stesso.
Se proprio vuoi restare sul paragone automobilistico, utilizzare il C++ 
solo ed esclusivamente come linguaggio OO equivale a comprare una 
macchina sportiva e non scalare mai tutte le marce.


 100.000 a 3.000.000.
[cut]
il discorso e` che qualsiasi container basato su array soffre degli 
stessi problemi di vector; ovvio, dipende anche dalle condizioni d'uso 
del container: se devi fare molti accessi casuali e pochi inserimenti 
vector puo` essere l'ideale; se l'accesso casuale non ti interessa 
allora list potrebbe essere il container che fa al caso tuo. Nel caso 
devi avere velocita` elevate sia in fase di inserimento che di ricerca 
allora una implementazione ad albero o hash table potrebbe essere 
vantaggiosa - tutto dipende da quel che si vuol fare.
Cmq, tornando al discorso precedente, vector dispone del metodo reserve() 
che serve proprio a prevenire le situazioni da te descritte.


 secondo l'OO, ma magari mi sbaglio...
Personalmente, si', ne ho sentito parlare ;)
Anzi, su comp.compilers si e' discusso spesso di questo e c'e'
un'ampia letteratura a riguardo.  Tieni presente che compilatori come
Delphi (che e' scritto esso stesso in Delphi) seguono questo
approccio.