Newsgroup: it.comp.lang.c++
Titolo: Non sarebbe male avere le idee chiare!

Ciao a tutti, probabilmente mi direte che sono OT ma credo che in realtà
quello che sto per dire possa interessare tutti i NG che  trattano di
programmazione. Cercherò si sintetizzare i miei dubbi in poche domande
rivolte agli esperti:
Considerando che non tutti coloro i quali si avvicinano ai linguaggi di
programmazione sono 17 enni superdotati ma spesso 30 enni che esultano
quando l'esecutivo di "Hello World" funziona e lo memorizzano per custodirlo
gelosamente e farlo vedere agli amici, mi chiedo il perchè di alcune cose:
Perchè per imparare il C++ viene consigliato uno studio accurato del C? Cosa
si consiglia quindi a chi si avvicinerà al C#?
Per realizzare applicazioni che funzioneranno con Windows, perchè
converrebbe studiare C/C++ e non Visual Basic (linguaggio per persone
stupide, o come ritengo linguaggio Intelligentemente semplice)? Non mi dite
che il problema sono le librerie da portarsi dietro perchè, a parte che
succede in alcuni casi anche con C/C++, in VB l'nstallazione dei file
esterni viene automatizzata nel setup, quindi l'unico inconveniente è un
maggiore spreco di spazio.
Quale è la differenza tra le applicazioni realizzate con Borland Builder C++
e Visual C++? Perchè con l'uno e non con l'altro?
La tendenza in tutti i campi è inevitabilmente quella di rendere le cose più
semplici ed accessibili, questo accade con non poca invidia da parte di chi
ha investito anni del suo tempo in metodologie superate, accade con la
realizzazione dei siti web, con le strutture hardware ed anche con la
programmazione. Se riesco ad ottenere lo stesso risultato con meno lavoro,
non è perchè sono meno capace ma perchè mi sono trovato in un periodo più
favorevole. Ritengo quindi che non sia onesto con se stesso chi alla domanda
"Vorrei cominciare a programmare, da dove mi conviene iniziare?" risponde
"Pascal, COBOL, C, C++ nell'ordine e possibilmente su testi in Inglese".
Bisogna dare delle motivazioni valide. Anche il discorso della portatilità è
relativo in quanto la tendenza è quella di uniformare le varie piattaforme o
di renderle compatibili. Se è tutto sbagliato quello che dico fate finta di
non aver letto il messaggio. Grazie per l'attenzione

 ha scritto nel messaggio
news:h1Dy6.814$5Y1....@news1.tin.it...


 oggetti nel C++, tutta l'altra parte è equivalente per i due linguaggi!!
Niente affatto. Sei fuori strada. E' assolutamente vero che il C rappresenta
ad oggi un sottoinsieme del C ma la differenza tra i due linguaggi non sta
solo
nelle feature da te indicate. Prima sostanziale *enorme* differenza, quasi
mai
compresa e studiata a fondo da chi proviene dal C è il *diverso* paradigma
di
programmazione. Il C++ supporta e predilige il paradigma ad oggetti.
Inoltre la libreria del C++ *deve* essere preferita a quella del C, anche
quando
offre funzionalità simili a quelle della libreria C. E non mi dovrei fermare
ancora perchè
in realtà dopo lo standard del 98 e con le modifiche che verranno è molto
probabile
che C e C++ divergano ancora, pur rimanendo sempre un'alta compatibilità tra
i due.
E stato dimostrato con studi che per un *novizio* è molto più facile
imparare da zero il C++
partendo con il *paradigma* giusto, che dover fare poi il salto dal
paradigma strutturato a quello
ad oggetti.
Siccome questa può essere considerata una domanda frequente, quasi da FAQ,
invece
di consigliare cose sconsiderate, leggetevi prima i post per qualche
mesetto.
Poi acquistate il libro di S.B.Lippman, C++ Corso di Programmazione, 3a
ediz., Addison-Wesley.
Cordialmente.
--
----------
Lello Mele
c/o VTM VideoTecnica Mele
Via San Sebastiano, 22
84036 Sala Consilina (SA)
Cell.:0347/643.35.25
HOMEPAGE:
http://www.lellomele.supereva.it
eMAIL:
v...@libero.it
me...@programmazione.it
-------------
"Esistono due modi per elaborare il progetto di un software.
 Il primo consiste nel renderlo semplice al punto tale che non
 manifesti lacune evidenti. Il secondo consiste nel renderlo
 complicato al punto tale che non manifesti lacune evidenti.
 Il primo metodo e' di gran lunga piu' difficile." [C.A.R. Hoare]

se non sai programmare
ti conviene iniziare da it.comp.programmare
comunque ............ a grandi linee
assembler
         per bios e tutto ciò che hardware dipendente
         per programmare microcontrollori e RT
c
         per i driver e kernel di os
        (garantisce un alto grado di  portabilità...programmatore
permettendo)
c++
         per gui,(windows per intenderci anche se con il 3.11 si programmava
in c)
         tools di sviluppo,linguaggi object oriented(come visual basic e
access ;-) ),server SQL
MS visual basic/MS access
         applicazioni generiche che non richiedono molta portabilità
         contabilità/fatturazzione/magazzino ;-)
java,perl,php
       programmazione web internet
grosso modo lo specchietto è questo
il linguaggi si dividono basso e alto livello
difficile implementare un OS (programmazione basso livello) in visual basic
come improponibile (a livello di costi ....troppo tempo) una contabilità
(programmazione alto livello) in c o in assembler

> non aver letto il messaggio. Grazie per l'attenzione
Non c'é nulla di sbagliato. È che salti da un argomento all'altro ed è
difficile rispondere a domande cosí generiche.

 ad oggetti.
Eccola! Come impari il paradigma? E ancora: come fai esercizi con quel paradigma
se non conosci il linguaggio? Risposta ovvia: con un altro linguaggio che
supporta il paradigma ma e' molto piu' semplice. Esempio Eiffel o Smalltalk.
Il problema allora si sposta: puoi imparare Eiffel o Smalltalk come primissimo
approggio alla programmazione? Se parti da zero, ma proprio zero, io dico di no.
Prima devi capire almeno i concetti base base. Si puo' farlo in C? Si, ma il C
e' troppo complesso. Non dimentichiamo che per anni il C era considerato un
linguaggio difficilissimo e conosciuto solo da esperti. Oggi sembra essere visto
come il linguaggio piu' semplice del mondo, ma in realta' e' solo perche' il C++
e' terribilmente piu' complesso! Ecco perche' serve come primo linguaggio un
linguaggio che sia semplice, ti impedisca di fare grosse stronzare (anche se
vuoi), e nello stesso tempo ti permetta di fare esercizio sui concetti di base
(non sul paradigma).
Per il resto ... vedi mio altro post. Stesso thread.
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

          per gui,(windows per intenderci anche se con il 3.11 si programmava
Prego? Stai scherzando o cosa?


 Bisogna dare delle motivazioni valide.
Azz. Non lo avevo letto. Posso ritiraro quanto detto? No? Ok. Allora provo a
darti (ma *MOLTO* stringatamente) le mie motivazioni.
Partiamo da zero. Prima devi imparare a *pensare* da programmatore. Poi puoi
imparare a programmare nel senso di sviluppare codice "reale".
Lo scibile informatico, oggi, non e' piu' contenibile in una pentalogia di libri
(anche se poi ne scrivi solo tre, Knuth docet). Pertanto non puoi umanamente
pretendere di imparare tutto in un colpo solo o in tempi brevi. Ergo diamo un
ordine alle cose. La prima cosa da capire ono i concetti base: funzione,
variabile, vettore, puntatore, memoria, file etc. etc. E magari qualche
algoritmo "base": i vari sort, la ricerca binaria etc. etc. E qualche struttura
fondamentale: stack, coda etc. In altre parole il contenuto della trilogia di
Knuth. Quale linguaggio ti da la possibilità di fare esercizio su questo senza
dover introdurre elementi di analisi e design (indipendentemente dal paradigma)?
L'ideale e' uno pseudocodice. Ma dato che non esiste un tale compilatore ...
Pascal. Che poi e' quello che usa(va) Knuth.
Il passaggio successivo consta nell'aprire la mente. Hai imparato a "pensare" in
maniera logica e ad un livello di astrazione relativamente basso. Ora cominciamo
ad approcciare il problema "at large". Questo significa soffermarsi sul
paradigma. E capire le questioni relative a reuse, qualita' del codice,
astrazioni etc. Quale e' il paradigma piu' potente attualmente conosciuto. In
generale quello OO. Ma andrebbe comunque arricchito con quelli funzionale,
relazionale (per i dati) e inferenziale. Non puoi fare tutto. Ergo consiglio
come secondo passo un linguaggio che almeno permetta di "ragionare" in senso OO.
Esempio Smalltalk, Eiffel, Ada. Fra questi Smalltalk ha il vantaggio di essere
diffuso e di permetterti di arrivare a sviluppare applicazioni "moderne". Idem
per Ada, ma con caratteristiche meno "fast development" e meno "total OO" ma
piu' "proof of correctness". Ottimo anche Eiffel, se non altro perche' e'
abbastanza didattico e affianca il supporto diretto al "contract programming"
all'OO. In questa fase lo scopo e' comunque quello di assimilare la visione "at
large". Se con il Pascal, piu' che sviluppare un applicativo, mi aspetto che
l'aspirante programmatore sviluppi "piccole routine" stile esercizi (il piccole
e' tutto da definire, in realtà!). In questa fase non mi aspetto che si arrivi a
sviluppare un intero applicativo. Mi aspetto che vengano preparati dei prototipi
architetturali, dei mock up, delle prove di fattibilita' etc per problemi
"grossi".
Finita questa fase si tratta di definire in che direzione vuoi andare. Che tipo
di prodotti dovrai sviluppare. Quale/i linguaggi conoscere "bene". Ovvero ti
prepari a raffinare le capacità fino ad arrivare ad essere un vero
programmatore.
La direzione dipende dal tuo scopo.
Se ti interessa approfondire le problematiche di "number crunching" studia
fortran e leggi "Numerical Recipes".
Se ti interessa il web development: Java, VBScript e C#.
Se ti interessano sistemi megacomplessi e megacritici (avionica, militari,
satelliti etc) Ada.
Se vuoi scendere di livello, nel senso di avvicinarti all'HW: C e assembler.
Se vuoi allargare ulterirmente la mente, dai un'occhiata a Prolog e Lisp.
Etc.
Il posto del C++? Fai conto che e' a basso livello come il C (poco sopra
all'assembler) ma nello stesso tempo supporta il paradigma OO. Ma lo fa in una
maniera per cui e' facile fare castronerie e farcire il codice di bachi: a tuo
rischio (vedi altro thread corrente). Inoltre ricorda che e' certamente il
linguaggio piu' complesso che esista al momento (salvo che dal punto di vista di
leggibilità, o meglio illeggibilità, Perl lo batte!).
Ottimo linguaggio. Lo adoro. E' possibile sviluppare codice efficientissimo. E'
possibile srutturare l'applicazione in maniera OO. Ma occhio: e' facilissimo
fare un casino che neppure te lo sogni in altri linguaggi. E non per problemi di
logica e di algoritmi (questo dipende comunque da te). Proprio perche' devi
tenere conto di un sacco di cose che non hanno a che vedere con il tuo problema
ma piuttosto con l'implementazione e l'environment. Certo, sempre meglio
dell'assembler.
Primo linguaggio significa il linguaggio su cui apprendi le basi. Io sconsiglio
il C++.
Se la domanda e': "C prima di C++, si o no?" la mia risposta e': meglio di no.
Se hai le basi della programmazione (Pascal+Knuth) e maneggi bene il paradigma
OO, evita il C e vai direttamente al C++. Ma non usare il C++ per imparare
quelle basi. Ci sono troppi dettagli, nel C++, di cui devi tenere conto e che
possono impedirti di "cogliere" le basi.


 lo deduci?
Secondo te cosa rappresenta la "novita" (negli ultimi anni) nel mondo
dell'informatica?
Io dico: Java (e il circondario stile JScript, JSP, Beans etc.), C# e .NET
Che tendenza ne dedurresti?


 di renderle compatibili.
Anche qui vale il discorso relativo a eliminare i problemi o
nasconderli: in alcuni casi anche la tanto vantata portabilita' di Java
si e' rivelata meno effettiva di quanto si potesse pensare. Certamente
nessun progetto serio in Java viene portato da una piattaforma ad
un'altra senza essere testato estensivamente.
Ciao,
Nicola

 un'altra senza essere testato estensivamente.
non sono per niente d'accordo!! Il Java č portabile nel senso che i
programmi non dovrebbero essere modificati da una piattaforma all'altra, per
via dell'interprete bytecode! Se ci sono problemi sono dovuti alle VM mal
implementate!

 implementate!
Quindi e' portabile in teoria, ma in pratica no. QED.
Ciao,
Nicola

 vedi? Fuorviante ...
Solo che non funziona.
MLO@mlinux 6 $ cat hello.cxx
#include <iostream>
int main() { cout << "Hello, world!" << endl; }
MLO@mlinux 7 $ g++ -ansi -Wall -o hello hello.cxx
hello.cxx: In function `int main()':
hello.cxx:3: `cout' undeclared (first use this function)
hello.cxx:3: (Each undeclared identifier is reported only once for each 
   function it appears in.)
hello.cxx:3: `endl' undeclared (first use this function)
MLO@mlinux 8 $ g++ -v
Reading specs from /usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/3.0/specs
Configured with: ../gcc-20010402/configure --prefix=/usr/local/gcc --enable-libstdcxx-v3
gcc version 3.0 20010402 (prerelease)
MLO@mlinux 9 $ KCC -o hello hello.cxx
"hello.cxx", line 3: error: identifier "cout" is undefined
  int main() { cout << "Hello, world!" << endl; }
               ^
"hello.cxx", line 3: error: identifier "endl" is undefined
  int main() { cout << "Hello, world!" << endl; }
                                          ^
2 errors detected in the compilation of "hello.cxx".
KCC: Compilation failed.
MLO@mlinux 10 $
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it
The instructions said to use Windows 98 or better - so I installed FreeBSD.

 Quindi e' portabile in teoria, ma in pratica no. QED.
Continuo a non essere d'accordo!!! Il problema sta sempre in chi crea la VM
e non nel linguaggio ... se certe cose non vengono messe a disposizione da
parte della VM, c'é poco da fare ... chi l'ha fatto non si rende conto che
il suo prodotto non funziona come dovrebbe no? E' come dire .... prendere il
C++  e un compilatore che non ti permette di fare  cout <<  "ciao a tutti";
eppure e' possibile su qualsiasi sistema. In fin dei conti le macchine sono
tutte uguali ... quel che non va č il sistema operativo o la VM.Perché
appunto con DOS non sono possibili certe cose che si fanno con Windows?
Semplicemente perché alcune cose sono difficili da fare. Prova tu a farmi
una connessione con un socket in C su DOS ...!!

 vedi? Fuorviante ...
Semplice e ... sconsigliato. Tanto e' vero che cosi' come lo hai scritto non
funziona perche' hai dimenticato di specificare gli using.


non funziona perché manca #include <iostream.h>!!! STo parlando del C++
standard ... non quello che comunemente usate per windows o altri sistemi!!
Provate a riscriverlo con l'include su DOS o Linux o Unix o che vi pare!!!
"Andrea Ferro" <And...@UrkaDVD.it> ha scritto nel messaggio
news:9ahhgg$lu1$1...@serv1.iunet.it...


Provate a riscriverlo con l'include su DOS o Linux o Unix o che vi pare!!!
Guarda che l'include standard e' iostream senza .h!
E tutta la libreria standard viene definita nel namespace std::
E tutto questo non c'entra una beata (valeria) mazza con un
compilatore per windows (che tra l'altro, se si programma in GUI non
sa neanche cosa sia o standar input/output/error) o per linux o dos o
che ti pare.
-- 
 (o-  | Un OS per domarli, Un OS per trovarli,
 //\  | Un OS per ghermirli e nel buio incatenarli
 V_/_ | Nella terra di Redmond, ove l'ombra cupa scende...
Tessera 99ers 204           raffaele punto salmaso presso libero punto it

 ha scritto nel messaggio
news:5tmoctgkium8lb99o...@4ax.com...


 Provate a riscriverlo con l'include su DOS o Linux o Unix o che vi pare!!!
Non funziona perche' manca la direttiva per l'utilizzo del namespace:
  using namespace std;
Bye,
 Emmanuele.
-- 
Emmanuele Bassi         |             [ 
http://digilander.iol.it/ebassi/
 ]
emmanue...@iol.it
  |
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4


Ciao Pluto,
tu stai parlando del C++ quando ancora non era standard,
come ti e´stato detto, ora esistono i file header senza estensione .h, i
namespaces e compagnia bella.
Per cui il semplice programma che ti scrive Hello World con cout senza uso
di namespace std, in un compilatore standard non viene compilato.
Abbi fede, speranza e carita´ .
Scaricati dalla rete e gratis "Thinking in C++" di Bruce Eckel ed usa
compilatori aggiornati che ti daranno errori per il tuo codice postato prima
MaurusAP

Provate a riscriverlo con l'include su DOS o Linux o Unix o che vi pare!!!
Non serve, abbiamo giá il primo esempio di Andrea che funziona, perché
farne un altro (che non funziona)? :-)))) 

 il suo prodotto non funziona come dovrebbe no?
Il punto e' che la portabilita' e' un problema pratico, non una
proprieta' teorica. Java in parte riduce il problema, in parte lo
sposta, ma non lo elimina del tutto.
Ciao,
Nicola

oggetti nel C++, tutta l'altra parte è equivalente per i due linguaggi!!
dipende dai punti di vista; io vedrei meglio un frase del tipo
"l'unica sostanziale identità è la sintassi dei costrutti base, tutta
l'altra parte è estremamente diversa e molto più complessa,versatile e
potente in C++"
Anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

 Provate a riscriverlo con l'include su DOS o Linux o Unix o che vi pare!!!
Nel C++ standard NON ESISTE un header chiamato iostream.h
Semmai esiste un header chiamato iostream e basta, senza estensione.
E in questo header gli stream sono nel namespace std.


 prenderti il DJGPP  e vedi mò che fa!
Se compila quello che hai scritto tu senza errori allora fa una sola cosa:
schifo come compilatore standard!
Perche' non provi tu a prenderti lo standard e leggerti cosa dice.





 tolta? Non faceva male a nessuno!!!


 ha scritto nel messaggio
news:rmy9tea...@mlinux.pd.infn.it...


supporta il paradigma ma e' molto piu' semplice. Esempio Eiffel o Smalltalk.
non sta scritto da nessuna parte che chi usa il C++ deve programmare
OO; visto che questo linguaggio è multiparadigma, non vedo la
difficoltà di imparare la programmazione strutturata direttamente in
C++, avvalendosi dei vari aiuti che esso offre rispetto al C (primo
fra tutti la libreria standard): non dimentichiamoci che il C++,
sebbene più complesso, è anche più "facile" del C; una volta che si
conoscono prog strutturata e C++ si può imparare il paradigma ad
oggetti.
Cmq, se io dovessi consigliare a qualcuno da dove iniziare gli
consiglierei il Pascal, visto che è ancora più rigoroso del C++.
IMHO, Anto


 C++ e Visual C++? Perchè con l'uno e non con l'altro?
La libreria, ed il fatto che il builder sembra essere piu' conforme allo 
standard..

 schifo come compilatore standard!
Beh' questa mi sembra una presa di posizione peggiore di chi non usa il 
namespace std.

 tolta? Non faceva male a nessuno!!!
L'hanno tolta una marea di anni fa (ad occhio direi almeno 5 o 6). Sapevo anche
il motivo, ma non me lo ricordo piu'.


 spiegato i template ma nient'altro in merito!
A quanto pare la vecchia teoria secondo la quale gli insegnanti universitari non
conoscono il C++ non e' del tutto campata in aria.
Uno dei pochi che sembra conoscerlo ... insegna fisica :-)


 conosce e "basta" :))
Io invece credo che praticamente non esista un progetto che non beneficierebbe
da uno sviluppo misto (ovvero con l'uso di due o piu' linguaggi).
--


 IMHO, Anto
Also IMO.


tu gia' non lo sappia, ma a questo punto hai negato il presupposto!
già, ma se il punto di arrivo è il C++ non vedo molto sensato imparare
la OO pura se poi non la si può applicare; in linea teorica non
sarebbe male neppure imparare l'assembler, così si riesce a capire
anche quello che succede sotto, ma, soprattutto un autodidatta, deve
imparare a focalizzarsi bene su ciò che vuole impare, senza
disperdersi: e deve imparare una cosa per volta, ma impararla bene;
seguendo il percorso (affascinante) che hai tracciato tu, dopo quanti
anni si riuscirà ad arrivare al punto di arrivo?


 anni si riuscirà ad arrivare al punto di arrivo?
Dipende dal punto di arrivo, non solo dal percorso. Se il punto di arrivo e'
conoscere la sintassi del C++ e basta, allora ovviamente parti dal C++. Ma se
dopo aver imparato questo vuoi approfondire ... ti trovi a fare piu' fatica e
impiegare piu' tempo.
Se invece il punto di arrivo comprende altro, la strada piu' veloce e' proprio
quella di affrontare la scalata a partire dalle basi. E ogni volta che introduci
un nuovo argomento il modo piu' veloce e' quello di, per dirlo con le tue
parole, "focalizzarsi bene su ciò che vuole impare, senza disperdersi: e
imparare una cosa per volta, ma impararla bene". Il modo migliore di farlo e'
quello di utilizzare un ambiente che ti permetta di fare esercizio su cio' che
stai studiando senza dover imparare altri dettagli legati ad argomenti diversi.
Questi dettagli ti distraggono tremendamente durante lo studio e per di piu'
rischiano di creare un mindset "deviato" che rallenta l'apprendimento in fasi
successive.
Un esempio (terribilmente parziale) e' l'uso delle stringhe o degli array. Se
stai focalizzandoti su algoritmi di sort e cose simili (prime basi) o sui
concetti OO (passo successivo) ha senso poter scrivere programmini che sparano a
schermo messaggetti vari. Ergo ti serve poter manipolare le stringhe. E l'array
e' una struttura troppo fondamentale per essere ignorata. Questo praticamente
esclude il C come linguaggio di partenza (e avrei qualche dubbio persino sul
pascal!). Mi dirai che in C++ esistono std::string e std::vector. Ma se affronti
il C++ direttamente non puoi limitarti a questo. Ti trovi comunque ad
incasinarti con i puntatori, gli array (non vector) multidimensionali e cose
simili. Basta vedere i messaggi che passano periodicamente sul NG!
Ma non solo, se impari una tecnica, finisci con il continuare ad usarla. Prova a
proporre questo problema ad un programmatore C++ (o peggio ancora ad uno che
viene dal C ed e' passato al C++:
dato un array di stringhe, creare un secondo array di stringhe contenente le
singole parole (eventualmente ripetute) contenute nelle stringhe iniziali,
eliminando tutti gli spazi. Per esempio dato:
"abc def"
"fgh ijk lm"
"cde fgh ijk"
produrre in uscita
"abc"
"def"
"fgh"
"ijk"
"lm"
"cde"
"fgh"
"ijk"
La magior parte dei progrmmatori che vengono dall'imperativo leggendo la
specifica del problema avrà gia' in testa qualche cosa del genere:
for i from 0 to length(array_in)
    start = 0
    do
        end = find_space( array_in[i], start )
        substr = extract( array_in[i], start, end )
        add( array_out, substr )
        start = end+1;
    while ( start < length( array_in[i] )
Poi a seconda della loro formazione potranno pensare in maniera prefissa o
postfissa, ovvero length(array_in) piuttosto che array_in.length() e add(
array_out, substr ) piuttosto che array_out.add( substr ). Inoltre alcuni
avranno gia' automatismi quali l'ottimizzazione delle chiamate all'accesso
dell'array inserendo in_str = array_in[i] all'inizio (ovviamente come reference
e non come copia!) e altre cose simili. Qualcuno addirittura potrebbe pensare di
essere "molto piu' OO" ragionando in termini di iteratori invece che di indice
(o in c di puntatori all'elemento invece che interi).
Come vedi ci sono tantissimi dettagli. E nessuno di questi correlato al
problema. Ma soprattutto non e' evidente la "visione OO" del problema. Tanto e'
vero che qualunque sia l'implementazione che ne deriva, difficilmente
rispecchierà una visione ad oggetti ma piuttosto una visione algoritmica. La
visione ad oggetti e' qualche cosa del tipo:
array_in for_each:
 [ item |
     item tokenize_on: ' ' to: array_out
 ]
Nota come nella visione ad oggetti il ragionamento rispecchia direttamente il
problema e come la tokenizzazione venga vista come un tool separato. E se questo
tool non esiste, no problem: basta aggiungere un metodo alla classe stringa. Ma
questo e' un problema separato. Cosa che chi ragiona in maniera imperativa
spesso non coglie (con conseguente ripetizione di codice). Il metodo puo'
essere:
String>>tokenize_on: aChar to: aCollection
  | spcPos |
  spcPos := self find: aChar
  aCollection append: (self left: spcPos)
  (self right: spcPos+1) tokenize_on: aChar to: aCollection
Ovviamente questa e' una visione e anche se la sintassi e' simile a quella di
smalltalk non e' smalltak. Cosi' come quella di prima non era C (o C++).
Semplicemente ho inventato una sintassi imperativa non formale e una sintassi OO
non formale.
Nota anche come in entrambe i casi mancano tantissimi dettagli (per esempio cosa
succede per i doppi spazi che vanno eliminati etc. etc. Ma quello che volevo
illustrare non e' il programma completo ma piuttosto lo schema mentale immediato
che nasce nella testa del programmatore (o meglio del designer, dato che stiamo
ancora a livello di design).
Un programmatore OO puo' sempre decidere di implementare in C++ il problema
usando un design algoritmico-imperativo. Ma per lo meno prende in considerazione
l'ipotesi di definire la cosa in maniera OO. E se decide di implementarla in
questa maniera si scontrera' con l'impossibiità di estendere la classe stringa e
ribalterà il problema creando una classe funzionale (un tokenizer) simile a
questa:
template <class C, class OutputIterator>
class Tokenizer {
    C c;
public:
    typedef std::basic_string<T,std::char_traits<T>,std::allocator<T> >
string_t;
    Tokenize(C c_);
    Tokenizer(const Tokenizer<C,T> &r);
    Tokenizer<C,T>& operator=(const Tokenizer<C,T> &r);
    void operator()( const string_t &s, OutputIterator i);
};
Quindi farà qualche cosa del tipo:
for_each(
   array_in.begin(),
   array_in.end(),
   bind2nd(Tokenizer(' '),back_inserter(array_out)));
Il codice l'ho buttato giu' a memoria e probabilmente mancano parecchi
particolari (oltre ovviamente ai vari std::). Ma credo di aver reso l'idea.
Dall'esempio mi sembra chiaro che il C++ supporta si l'OO, ma in maniera
alquanto arzigogolata. O meglio: arzigogolata per chi sta cercando di usare il
C++ per imparare a pensare OO.
Se non sei convinto provo a sviluppare codice compilabile e commentato per il
problema in esame in C, C++ imperativo, C++ OO e Smalltalk. Poi te li posto e
vedrai da te la differenza!
Andrea Ferro
P.S.: con questo non voglio dire che tu non debba avere l'ultima parola ;-P


anni si riuscirà ad arrivare al punto di arrivo?
Io condivido l'affermazione che il C++ non dovrebbe essere il primo
linguaggio di programmazione appreso. E' di gran lunga troppo
complesso nelle sue basi e troppo pieno di dettagli comunque
importanti per non risultare distraente da chi deve assimilare il
concetto di variabile, di funzione, di algoritmo o di struttura
dati. Da questo punto di vista anche il C mi sembra poco adatto (per
la sua sintesi e potenza che peraltro personalmente apprezzo molto)
e credo che un linguaggio preferibile sarebbe il Pascal e addirittura
(forse) per i primi rudimenti anche cose come il BASIC (tutto
piatto, solo variabili e istruzioni, con sottoprogrammi GOSUB).
Quando si sa programmare allora si puo' passare ad un linguaggio
serio come il C e, quando si conoscono bene cose come il C, si
possono comprendere seriamente i fondamenti della programmazione OO.
Per comprendere la teoria forse anche linguaggi OO "puri" possono
aiutare (per definire bene il problema) e a questo punto io
vedrei l'apprendimento del C++ con una implementazione imperfetta
(ma tremendamente concreta ed efficiente) del paradigma OO.
Io credo che questo (lungo) percorso sia inevitabile per ottenere
una conoscenza *profonda* del C++. Come ho gia' detto in passato
la mia opinione e' che:
 - Una conoscenza *superficiale* del C rappresenta un impedimento
   per un apprendimento *superficiale* del C++.
 - Una conoscenza *profonda* dal C rappresenta un aiuto notevole
   per un apprendimento *approfondito* del C++ (anzi un
   prerequisito ovviamente necessario e' la conoscenza profonda
   del sottoinsieme C del C++).
La mia opinione e' che non si possano capire realmente i metodi
virtuali se non si capiscono i puntatori a funzione, o che non
si possano comprendere realmente i vector e gli altri container
senza capire a fondo puntatori e stutture dati complesse basate
su puntatori.
Certamente la comprensione di questi retroscena non e'
fondamentale per iniziare a "giocare" con il C++. Ma il C++ e'
un linguaggio pericoloso da questo punto di vista (per scelta,
non per insufficienza) e ad usare strumenti pericolosi senza
aver capito bene come funzionano ci si fa malissimo.
Ad esempio il C++ fa un sacco di cose in automatico per
il programmatore... e tornano utili; ma sono secondo me utili
solo se il programmatore e' *consapevole* di tutto quanto fa
il compilatore, del come e del perche'.
Forse questo e' meno vero in altri linguaggi piu' "astratti".
Ci vuole un sacco di tempo per imparare a programmare ? Io
credo di si. Sono necessari milioni di linee di codice.
Anzi. Credo che non si finisca *mai* di imparare.
Sono anche convinto che il nostro apprendimento (se e' vero
apprendimento e non "mandare a memoria") deve essere
costruito dal basso verso l'alto, dal concreto all'astratto
(prima si impara a contare, poi a risolvere le equazioni
differenziali).
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 differenziali).
Vero in parte. Vero nel senso che bisogna quando possibile partire dalle basi e
costruire sul conosciuto per imparare il nuovo. Ma e' falso in quanto non per
tutti i problemi e' necessario conoscere il funzionamento a basso livello. Un
esempio matematico e': per lavorare con jpeg e mpeg non e' necessario conoscere
nei dettagli la matematica che sta alla base delle trasformate e delle
antitrasformate di Fourier. Se hai un implementazione (magari HW o in libreria)
della FFT coseno e della sua inversa ti basta capire come quella trasformazione
ti porti dal dominio del tempo a quello delle frequenze e che "segnali" di
origine "naturale" presentano coefficienti molto bassi per le alte frequenze,
ergo la possibilità di compressione "lossy" per quantizzazione dei coefficienti.
Il concetto non e' semplicissimo. Ma non richiede un corso avanzato di analisi.
Allo stesso modo non e' affatto necessario capire cosa ci sta alle basi di molti
meccanismi. Tranne in C++ dove se non lo capisci rischi di farti male. Prendi
per esempio Smalltalk.  Lavora in una virtual machine e ogni messaggio spedito
(metodo chiamato) richiede (in teoria) una serie di lookup tabellari. E questi
lookup sono a loro volta implementati in pcode. Ergo se ne dovrebbe dedurre che
le prestazioni sono terribili. Il che e' anche stato vero per parecchio tempo.
Ma sono arrivati altri linguaggi derivati e ancora piu' semplici e potenti (come
per esempio Self e Cecil) che causa della loro stessa semplicità rendevano i
tempi di esecuzione ancora piu' proibitivi. Ergo una serie di progetti di
ricerca che hanno dato come risultato l'ottimizzazione dei meccanismi di
binding. E del risultato ha beneficiato Smalltalk stesso che ad oggi e' in
alcuni casi in grado di superare, nel meccanismo di binding dinamico dei
messaggi, l'efficienza delle virtual table usate in C++.
Infatti l'apparente lentezza di alcuni comandi tipici degli environment
Smalltalk non e' dovuta all'inefficienza del linguaggio ma alla scelta dei
programmatori di accontentarsi delle prestazini ottenute con la "soluzione piu'
ovvia". Esempio: molto spesso un programmatore Smalltalk, dovendo ordinare
alfabeticamente una sequenza di stringhe, non si preoccupa di avere un algoritmo
di sort. Semplicemente sa che esiste un container che tiene direttamente
ordinati i suoi elementi e lo usa ome sorter. Ovvero come se in C++ invece che
fare (codice non controllato, giusto per rendere l'idea):
std::vector<std::string> *pStringhe=0;
// istanzia il container e leggi le stringhe
std::sort(pStringhe->begin(), pStringhe->end());
un programmatore facesse:
std::vector<std::string> *pStringhe=0;
// istanzia il container e leggi le stringhe
pStringhe=new std::multiset<std::string>(pStringhe->begin(), pStringhe->end());
con pero' due problemi: primo che pStringhe non puo' essere associato al
multiset e che non esiste nessuna calsse base che comprende sia il vettore che
il multiset (si potrebbe rifare tutto con i template, ma c'e' un limite oltre al
quale il template non puo' essere usato altrimenti tutta la tua applicazione e'
un unico template!). Secondo che, ovviamente, il C++ non ha la garbage
collection e il vecchio vettore non e' stato deallocato.
Ma quello che volevo dire e' che la scelta di operare in questo modo e' una
scelta filosofica. In prima battuta (salvo il fatto che in C++ non puoi proprio
farlo) la cosa si puo' fare e rende chiaro (ad una analisi OO) cosa e' ordinato
e cosa no (pensate alla possibilità di testare se il container e' ordinato
semplicmente testando che ... sia un multiset invece che un vector!). Solo in
alcuni casi (per grossi insiemi) la tecnica non risulta valida. Ma questo e' un
dettaglio che NON devi analizzare nelle prime fasi. Solo dopo aver realizzato il
programma e MISURATO che i tempi di esecuzione non sono sufficientemente buoni
correggerai il tiro.


correggerai il tiro.
Verissimo. Anzi vero. Sicuramente investire tempo ad
ottimizzare senza aver misurato e' inutile.
Scrivere codice orrendo in prima battuta e' pero'
stupido (specie se il codice decente richiede la
stessa fatica). 


 Forse questo e' vero per altri linguaggi, ma non per il C++.
Ricorda che c'e' un trade-off fra il tempo di sviluppo e il tempo di esecuzione.
E nella realta' ridurre il tempo di sviluppo del 75% al costo di un tempo di
esecuzione aumentato del 40% e' di solito molto ma molto conveniente. Cosa che
spesso chi programma in C++ dimentica. Non tutte le applicazioni devono essere
realtime.


P.S.: con questo non voglio dire che tu non debba avere l'ultima parola ;-P
^___^


 direzione": non so se lo continuerò ad affermare tra 20 anni.
Eccomi, 22 anni dopo (ne ho 40, cavolo come passa il tempo!). No, non è
affatto facile (quasi impossibile?) cambiare strada quando l'ultimo
bivio te lo sei lasciato dietro tanto tempo prima. E non è solo una
questione di scelte ma anche di mentalità ormai forgiata da anni e anni
di utilizzo di determinati paradigmi e tecniche. Comunque penso anche
che ogni programmatore sia un caso a se.
EMG

 sinceramente non ci vedo tutta questa utilità nel risolvere algoritmi.
Amen, fratello! Se devi risolvere un algoritmetto in maniera "usa e getta" fai
meglio a usare la programmazione strutturata. Se deve essere superottimizzato
per un uso specialistico C/C++/Assembler a seconda di cosa di offre la
piattaforma. Se l'algoritmetto e' "fortemente matematico" meglio Fortran (se
possibile). Se e' esprimibile con espressioni regolari, Perl.
Pero' se lavori con un progetto grosso, MOLTO meglio usare l'OO. E se lavori su
decine e centinaia di progetti piccoli, con l'OO ottieni il "reuse". Ovvero dopo
qualche decina di progetti ti ritrovi che per sviluppare quelli successivi devi
scrivere al massimo una decina di righe.
Andrea Ferro


 wrote in message
news:3AD493DC...@flashnet.it...

Io ne ho "solo" 34, ma sono d'accordo. E' risaputo che da giovani e' piu' facile
imparare. Ed e' risaputo che da meno giovani e' piu' facile imparare se nel
passato si sono affrontati argomenti diversi da punti di vista diversi.
Esempio: Per un 50/60 enne che lavora da 30+ anni solo ed esclusivamente in
Basic o Pascal (quelli originali) e' estremamente difficile imparare Java
(lasciando perdere C++). Se poi viene dal Cobol ...
Una persona della stessa età che pero' ha imparato: negli anni 70 il basic, il
cobol e il pascal originali, e l'assembler 6502; negli anni 80 il C lo Smalltalk
e Ada e gli assembler Z80 e 8080, dando anche una piccola occhiata a Lisp e
Prolog; negli anni 90 l'Object Pascal, il C++, Perl e gli assembler 80x86;
sicuramente sarà in grado di imparare Java senza troppi problemi.
E' come imparare una lingua: a 1 anno puoi imparare anche 3 o 4 lingue
contemporaneamente e svilupparne una conoscenza perfetta. A 10 ne puoi studiare
una o due contemporaneamente e arrivare ad imparale bene. A 18 meglio una per
volta. Ma se arrivi a 25 parlando solo la tua ... sei messo male. Dall'altro
lato se arrivi a 25 anni conoscendo bene 4 o 5 lingue diverse, puoi continuare a
impararne altre ancora. E superata la dozzina di lingue praticamente puoi
imparare a esprimerti in qualunque idioma nel giro di due mesi anche se sei
negli anta.
--
Andrea Ferro


assumere che l'implementazione di std::string sia COW
scusa, cosa vuol dire COW?


Pensando un po' agli algoritmetti che hai *pensato* tu ... perché Linus
Torval avrebbe creato Linux con il C, piuttosto che con il C++? In fin dei
conti nessuno ci vieta di implementare un S.O. con il C++ no? Ok ... alcune
cose si potrebbero velocizzare con l'ASM, ma ... per il resto nono ci
dovrebbero essere problemi! Sai qual'é stata la risposta di Linus? Ha detto
che scrivere Linux in C++ o qualsiasi altro linguaggio ad oggetti, avrebbe
portato a meccanismi che lui stesso ha definito come *loschi*, a una perdita
di controllo del codice che aveva generato. Eppure, gli algoritmi di di un
S.O sono algoritmi di pura matematica che non sono neppure poi così
semplici. E poi a mio parere un Reuse si può fare anche sulla programmazione
strutturata stando un po' attenti alla progettazione della libreria di
funzioni che viene messa a disposizione. L'unica cose è stare attenti e fare
le cose x bene. In fin dei conti la programmazione strutturata non è altro
che la trasposizione meccanica di ogni singola azione che deve essere
effettuata.
"Andrea Ferro" <And...@UrkaDVD.it> ha scritto nel messaggio
news:9b3s2b$7us$1...@serv1.iunet.it...


passato si sono affrontati argomenti diversi da punti di vista diversi.
bene, allora è meglio che mi sbrighi ad imparare più cose possibili
nei pochi anni che mi restano prima di entrare a far parte dei
"vecchietti" :-D (senza offesa, naturalmente ;-)


scrivere al massimo una decina di righe.
ok, mi fido della tua esperienza


scusa, cosa vuol dire COW?
Copy-On-Write. Alcune implementazioni di std::string evitano
di duplicare il contenuto della stringa al momento
dell'assegnazione ma posticipano la duplicazione a quando si
cerca di modificare il contenuto. In questo modo passare le
stringhe per valore pesa molto meno se queste stringhe non
vengono modificate...
  std::string a="Hello, world";
  std::string b(a); 
Se l'implementazione e' COW allora la copia creata in b
usa gli stessi caratteri di quella contenuta in a e non richiede
una allocazione dinamica separata. Al primo tentativo di
modificare il contenuto di b la stringa viene duplicata (se
a punta ancora allo stesso contenuto) e quindi a e b diventano
differenti.
Le implementazioni COW non sono sempre migliori rispetto
a quelle non COW (che duplicano il contenuto); dipende dal
contesto di uso. Ci sono anche problemi legati a stringhe
COW e multithreading (e alcune implementazioni della libreria
standard evitano le stringhe COW proprio per questo motivo).


 funzioni che viene messa a disposizione.
La cosa e' MOLTO piu' parziale. Altrimenti non esisterebbe l'OO. Inoltre, in
genere, un OS non viene sviluppato tenendo conto del reuse in quanto e'
difficile che una società che sviluppa un OS finisca con lo sviluppare decine di
OS diversi nel tempo (eccezione: MS, la quale infatti sta cominciando ad avere
un sacco di codice OO nei suoi OS).
--


 "vecchietti" :-D (senza offesa, naturalmente ;-)
None taken, sbarbato ;-)


A quanto si dice su c.l.c++.m ormai la maggior parte delle
implementazioni della libreria standard ha abbandonato le stringhe
copy-on-write.
Ciao,
Nicola

 di controllo del codice che aveva generato.
Mi sembra l'affermazione di uno che non conosce affatto il C++ dato che
è possibile programmare in C++ esattamente come si programma in C, senza
avere alcuna "perdita di controllo del codice". Solo utilizzando
meccanismi come template e metodi virtuali si introducono degli
automatismi che però normalmente valgono la candela.
EMG

prenderti il DJGPP  e vedi mò che fa!
Nient' affatto invece. Il DJGPP si comporta in modo correttissimo, e
rispetta perfettamente lo standard mantenendo ovviamente la
compatibilità all'indietro come fanno tanti altri compilatori.
E' chiaro quindi che include<iostream.h> viene accettato, se invece
non viene accettato include<iostream> é probabilmente perché non é
stata abilitata l'opzione di usare la libreria standard(solitamente
gli headers vengono messi su c:/djgpp/lang/cxx, ed il percorso deve
essere indicato). Bye!!!
Il Ghenio
WINWORD.EXE - ERRORE DI APPLICAZIONE
l'istruzione a "0x3017ff27"ha fatto riferimento alla
memoria a "0x02a3143c".La memoria non poteva essere 'read'.

consiglierei il Pascal, visto che è ancora più rigoroso del C++.
Io prima di passare al C++ usavo proprio il Pascal. Cosa intendi dire
per "più rigoroso"?
Buona pasqua!!!!


convenientemente con uno piuttosto che con quell'altro)
Probabilmente qualsiasi cosa che richieda delle prestazioni decenti e
che debba essere affidabile(l'affidabilità del VB infatti scema man
mano che la complessità del programma aumenta). Il Visual C++(almeno
nella versione 6)comunque per me rimane uno dei peggiori compilatori
c++ in circolazione.


per "più rigoroso"?
Che in Pascal è difficile sgarrare; è vero che anche li si possono
fare acrobazie con cast e simili, ma non sono necessari: è possibile
inziare a programmare concentrandosi sugli algoritmi invece che sui
dettagli a basso livello come in C.
Inoltre, IMHO, secondo me l'uso di begin end invece di { } è
propedeutico per i principianti, perchè consente di vedere chiaramente
e distintamente quali sono i blocchi e come si suddividono.
Senza contare che le operazioni di I/O sono decisamente più facili.


 ha scritto nel messaggio
news:3AD81AE4...@flashnet.it...

Certo ... ma prova tu a fare il debug di un codice di un S.O. in C++!! Ad un
certo punto inizi a non capirci + nulla con tutti i sotterfugi che il C++
mette a disposizione!

 mette a disposizione!
Non sono certo peggio di quelli che mette a disposizione il C, anzi. A
mio avviso il C++ si presta benissimo a realizzare sistemi operativi, e
credo che BeOS sia scritto nel nostro linguaggio preferito. Per quanto
riguarda Linux penso ci fossero diversi problemi:
- Scarsa maturita' di g++ ai tempi;
- Mancanza di uno standard;
- Maggior difficolta' a recuperare l'esperienza ed il codice disponibile
  di Unix;
- Necessita' di definire un ABI che tenesse conto delle classi,
  o esplicitamente o tramite mangling predefinito.
Nota che ad esempio il meccanismo di gestione dei driver di I/O di tutti
gli Unix e' sostanzialmente una gerarchia di classi con polimorfismo e
funzioni virtuali implementata in C. Non sarebbe stato meglio poterla
scrivere direttamente in C++?
Ciao,
Nicola

 mette a disposizione!
Quali sotterfugi? Ripeto: il C++ può essere utilizzato praticamente come
fosse C e quindi il problema non sussiste.
EMG

 ha scritto nel messaggio
news:3ADC0858...@flashnet.it...



Per fare un esempio HURB è dichiarato essere un OS OO. Eppure viene
sviluppato in C.
Saluti  Manlio Perillo

x Pluto:
ti avevo giů avvisato via e-mail, ma o il tuo indirizzo č sbagliato,
oppure non mi hai dato ascolto.
Puoi per favore correggere i fastidiosissimi bug di Outlook? Mi
riferisco al reply fatto con "R:" invece di "Re:" e dei messaggi
quotati in coda anzichč in testa. Tanto piů che se non hai ancora
applicato la patch per il "R:" credo che ci siano anche dei problemi
di sicurezza.


 un miscuglio!!!
Però in questo modo non hai tutte le migliorie che il C++ ha introdotto
proprio basandosi sull'esperienza del C.
EMG

scrivere direttamente in C++?
Io ho scritto per anni codice OO in C e ti posso assicurare che
scrivere pensando al polimorfismo in C non costa molto. In C++ hai
un buon aiuto dal compilatore che pero' puo' essere sostituito
da un po' di autodisciplina. Usando puntatori a funzione nelle
classi (invece di una VMT) il codice di chiamata di un metodo
passa dal C++ "m.f(x,y,z);" al C "m->f(m,x,y,z);" che sono sicuro
concorderai non essere paurosamente piu' complicato o meno leggibile.
Anche l'ereditarieta' semplice si riesce ad ottenere facilmente
usando una struttura in cui si mette come primo campo un oggetto
base (e quindi un puntatore al derivato diventa sostituibile nei
quando e' richiesto un puntatore al base).
Il vantaggio del C e' secondo me che esiste una separazione piu'
netta fra "core" e librerie (separazione molto utile in alcuni
contesti) e che c'e' un maggior dominio e un minor fardello minimo:
teoricamente nel C++ la filosofia era "se non ti serve non lo paghi"
ma in certi punti questo non e' affatto vero (vedi exceptions o
libreria di I/O).
Se poi tirassimo in ballo la portabilita' del C++ rispetto a quella
del C o la stabilita' di librerie e compilatori...
Esiste se non sbaglio una proposta di standard C++ per sistemi
embedded in cui si vuole introdurre una versione "lite" del C++
che non obblighi (o faciliti per distrazione) a carichi pesanti
e non necessari in contesti low-level. Quella versione sarebbe
forse piu' adatta (se sufficientemente portabile).


fosse C e quindi il problema non sussiste.
Questo e' barare :)
Se tu scrivi un programma C in cui usi solo variabili globali e
nessuna struct/union, solo funzioni senza parametri e goto
invece della programmazione strutturata non stai scrivendo
un programma in "C" ... stai scrivendo un programma in "BASIC" ...
anche se legalmente e' definibile "C" ;)


 ha scritto nel messaggio
news:3ADC753C...@flashnet.it...

Domanda: Che migliorie? Non per cattiveria, ma se devi programmare un
sistema operativo, un' istruzione del tipo:
int *x = new int[DIM];
non la puoi fare perché il gestore della memoria te lo devi fare da te!! Non
puoi usare gli  stream di I/O, ti devi implementare a mano tutti gli
algoritmi per la schedulazione della CPU, del DISCO, della RAM. Quel che ti
è concesso usare sono solo puntatori ad indirizzi!! Prova  a guardare
l'implementazione di una semplice malloc ... e poi dimmi che migliorie ci
sarebbero! Programmare ad oggetti su un progetto che ti non ti permette
nemmeno di usare tutto lo standar del C non ha senso. Se mi dici che in C++
si può programmare benissimo come in C, allora stai programmando in C,
questo è solo un ragionamento logico. Non è detto che se stai utilizzando un
compilatore C++ per compilare il sottoinsieme C del C++ tu stai programmando
in C++, ma stai programmando in C e basta!

 Questo e' barare :)
Quindi tu reputi sbagliato utilizzare il C++ solamente come C migliore?
Beh, io no. E poi se mi servono features aggiuntive ce l'ho a
disposizione (e in quel caso, ovviamente, pago).
EMG

 in C++, ma stai programmando in C e basta!
Questo non è vero. Il fatto che il C++ comprenda anche il C non
significa che tu debba evitare di utilizzare quel sottoinsieme, se è
proprio quello che ti serve. Ed inoltre hai a disposizione altre
features che dovessero tornarti utili.
EMG

 EMG
Nello sviluppo di S.O, non esistono feature ... che intendi?

 forse piu' adatta (se sufficientemente portabile).
Se parli di Embedded C++ ho letto da qualche parte che e'
sostanzialmente morto.
Ciao,
Nicola

 ha scritto nel messaggio
news:9bjfgk$21fo$1...@stargate1.inet.it...

Il C++ non è solo libreria Standard.
Ci sono i namespace che aiutano ad organizzare il codice.
Inoltre i concetti OO supportati dal C++ ti aiuterebbero a gestire
il proggetto di un SO nel suo *insieme*.
Saluti   Manlio Perillo

 Nello sviluppo di S.O, non esistono feature ... che intendi?
penso intenda overloading, ereditarieta', template...

 Nello sviluppo di S.O, non esistono feature ... che intendi?
Beh, che so, in fin dei conti le std::string sono praticamente come gli
array di char ma molto molto piů comode, no?
EMG

Questo e' barare :)
non sono d'accordo; una delle cose che mi piace di piů del C++ č il
fatto di essere multiparadigma; quindi IMHO č "leale" usare il C++
anche senza l'OO: sappiamo tutti che l'OO non č certo la salvezza da
tutti i mali, quindi possiamo benissimo non usarla quando č piů di
impiccio che altro.


array di char ma molto molto più comode, no?
std::string e' sicuramente moooooolto meglio di un array di char
nel 99% dei casi in cui si stanno scrivendo programmi "normali".
Da un punto di vista "sistemistico" pero' le std::string sono
decisamente dei mostri orribili... per farti qualche esempio
  - std::string non e' portabile come rappresentazione
    fra diversi compilatori C++. Inoltre non e' ragionevole
    pensare di usare std::string da linguaggi diversi da C++.
    Se le system call fossero scritta basandosi su std::string
    significherebbe *come minimo* che tutti i programmi devono
    essere scritti in C++ (con il compilatore XYZ)
  - Un oggetto std::string non puo' essere scambiato fra
    diversi programmi C++ anche se compilati con lo stesso
    compilatore/versione. Per avere un esempio di quanto ci
    si possa fare male basta provare a passare oggetti della
    libreria standard fra un eseguibile e una DLL scritti
    entrambi con VC++.
    Il motivo e' che std::string non e' "autocontenuto"...
    non esiste qualcosa di preciso e standard che tu possa
    passare (ad esempio in un'area di shared memory) e
    sperare di non aver lasciato qualche pezzo in giro.
    Un oggetto std::string potrebbe essere (spesso e') legato
    *indissolubilmente* alla singola istanza del gestore di
    memoria che l'ha creato: solo il creatore (intendendo
    l'istanza dell'eseguibile che ha creato l'oggetto) puo'
    distruggere in modo safe un oggetto std::string... ma
    (e questo e' un punto importante) quale sia il creatore
    non e' una informazione contenuta nell'istanza.
  - Nel caso di oggetti piu' complessi (es std::map con VC++)
    non si riesce nemmeno ad accedere in *lettura* da una
    istanza diversa da quella che ha creato l'oggetto. Il
    motivo e' che l'implementazione di std::map di VC++ si
    basa anche su oggetti "sentinella" che vengono istanziati
    tramite template e che sono distinti fra le varie istanze
    di programmi/DLL C++ in esecuzione.
    Non credo che nulla vieti il fatto che esistano limiti
    simili anche per std::string in qualche implementazione.
  - Gli oggetti std::string rendono molto meno evidente i
    punti in cui sono possibili allocazioni/deallocazioni
    di memoria. Quando si scrive un SO ci sono diversi
    allocatori che devono essere usati nei diversi contesti
    e in diversi momenti (magari di "malloc" ce ne sono 4
    diverse e devono essere usate ciascuna al posto giusto
    pena il fracassare tutto... ad esempio in alcuni momenti
    e parti di codice si usa memoria virtuale, in altre no...)
    se si usasse std::string bisognerebbe mettere come minimo
    un commento su quale sia la versione del gestore usata
    prima di ogni singola operazione sulle stringhe che
    potrebbe allocare o deallocare memoria.
Vuoi mettere tutte queste grane rispetto ad una sequenza di
caratteri terminata da '\0' ? :)
Normalmente le chiamate di sistema risolvono il problema
di come allocare memoria perche' chiedono sempre al *chiamante*
di fornire la memoria in cui scrivere le stringhe...
Fornendo solamente raw memory il problema si risolve; lo stesso
non si puo' fare con std::string perche' anche chiamando il
placement constructor non e' garantito che non venga usata
altra memoria (anzi... e' praticamente certo che questa venga
usata - e nemmeno e' detto che sia allocata con operator new,
vedi gcc e sue malloc interne alla libreria standard).


disposizione (e in quel caso, ovviamente, pago).
Au contrarie... io ritengo che il C++ usato come "C migliore"
con classi e poco piu' sia un ottimo strumento in certi contesti
in cui e' necessario mantenere un controllo piu' fine.
Credevo che il discorso fosse pero' sullo scrivere un SO in C++
usandolo come C++ ... non come "better C".
Sull'usare il C++ con questa accezzione personalmente credo che
l'unico problema sia la portabilita' del codice (che pero' se
si sta alla larga dalle zone buie ora e' diventata decente).


sostanzialmente morto.
Esatto... EC++... peccato...
Io per lavoro mi occupo anche di SW embedded e in qualche
frangente il C++ sarebbe tornato comodo (non *TUTTO* il
C++ pero'... quella e' decisamente troppa roba)


impiccio che altro.
Pensavo che il discorso fosse un altro... ovvero lo scrivere un SO
in C++ usando iostream, std::map, back_inserter e amici vari.
Inoltre ci sono cose che in C++ standard non si possono non
pagare anche se non si voglio usare come le exceptions (alcuni
compilatori pero' permettono di disabilitarle con opzioni di
compilazione specifiche).


 ha scritto nel messaggio
news:3ade8038.
3102674
@news.interbusiness.it...

Il fatto è che gli iostream del C++, così come le fopen e tutte le funzioni
relative del C, nello sviluppo di un sistema operativo, non posso essere
utilizzate. Questo perché le implementazioni fornite dai compilatori, e dico
tutti i  compilatori, per essere STANDARD e portabili su tutte le
piattaforme, a livello di linguaggio macchina non fanno altro che chiedere
un servizio di apertura, lettura e scrittura al sistema operativo che ospita
il programma. Quindi, se stiamo progettando un S.O, completo, dall'inizio
alla fine, ci viene proprio a mancare chi ci fornisce il servizio. Siamo noi
quindi a doverci creare il nostro servizio di I/O nonché nuovamente tutte le
funzioni di I/O basate su quel gestore che noi stessi abbiamo scritto. NOn è
nemmeno possibile utilizzare  una *printf* per poter scrivere il messaggio a
video. L'inconveniente sarebbe risolto assegnando ad una variabile puntatore
lìindirizzo della memoria video e utilizzare la variabile come un array:
int *screen = 0xB800;
Per cui ... non mi sarebbe per niente vantaggioso utilizzare il C++, anzi
... impossibile. Qualcuno qui ha detto che sarebbe + semplice usare le
std::string! Ok ... vantaggioso, ma come? Non le possiamo usare perché la
loro implementazione usa un gestore della memoria che ci viene a mancare ...
e se ci viene a mancare quello, non ci è possibile usare nessuna funzione od
oggetto che sia che utilizza anche il + semplice gestore della memoria,
perché questo effettivamente...non esiste + e verrà sostituito da uno nuovo,
creato da noi!!
Il problema è effettivamente che non tutti i linguaggi sono stati creati per
fare la stessa cosa! Un LISP non sarà mai usato per creare un S.O.! Certo
esistono macchine con S.O. scritto proprio in LISP, ma quelle macchine sono
capaci di leggere direttamente li codice LISP, anziché il codice macchina
dei normalissimi calcolatori di casa ... sono LISP-Machine, ma il LISP, per
in nostri calcolatori, non può essere usato per quello scopo! Così come il
C++ è + adatto, secondo me, allo sviluppo di software commerciale e no ...
ma sempre applicativo! Il C è stato creato per lo sviluppo di S.O e il Java
per poter scrivere programmi portabili senza alcuna dipendenza da S.O e
macchine varie!! Per cui ... ad ogni linguaggio il loro compito!!

 macchine varie!! Per cui ... ad ogni linguaggio il loro compito!!
il kernel di beos e' scritto in C++ e assembly

 ha scritto nel messaggio
news:10398475....@tin.it...

SEi proprio sicuro? A me pare che fosse scritto in C, cmq il fatto resta che
ti devi creare cmq tutto il sistema di I/O e di gestione della mem!

 C++ pero'... quella e' decisamente troppa roba)
Mah, da quel poco che ho letto non mi pareva una cosa eclatante. Diverse
funzionalita' sembravano rimosse un po' a casaccio.
Ciao,
Nicola

     potrebbe allocare o deallocare memoria.
Perche'? Puoi fare in modo che le stringhe allocate coi diversi gestori
siano tipi diversi, specializzando basic_string in funzione
dell'allocatore. A quel punto e' il compilatore che ti segnala se stai
usando il gestore giusto. E questo vale per tutta la libreria standard.
Ciao,
Nicola

 compilazione specifiche).
A meno che tu non costruisca un'implementazione delle eccezioni tale da
poter essere usata come meccanismo generale. Se stai scrivendo un S.O.
nessuno te lo vieta (salvo forse il tuo compilatore :-)
Ciao,
Nicola

 macchine varie!! Per cui ... ad ogni linguaggio il loro compito!!
Sul fatto che linguaggi diversi si prestino meglio a risolvere problemi
diversi sono d'accordo, ma continuo a pensare che il C++ sia adatto a
realizzare S.O. .
Tra l'altro finora le tue obiezioni si sono centrate sulla libreria, che
come tu stesso hai detto non e' utilizzabile cosi' com'e' (e anche su
questo ci sarebbe da discutere).
Quello che conta pero' sono i costrutti di base del linguaggio, come
classi e template.
Ciao,
Nicola

 ti devi creare cmq tutto il sistema di I/O e di gestione della mem!
No, e' proprio scritto in C++, cosi' come OS/400, il sistema operativo
dell'AS/400, almeno a quanto dice Grady Booch.
Ciao,
Nicola

 questo ci sarebbe da discutere).
Non dico tutta, ma la parte di I/O e della mamoria!

 Resta cmq il fatto che il gestore te lo devi rifare!
Tanto quanto in C. Salvo che in C++ molti elementi della libreria
possono poi utilizzare il tuo, mentre questo in C non e' vero.
 
Ciao,
Nicola

 decisamente dei mostri orribili... per farti qualche esempio
Però un sistema operativo non è fatto solamente di kernel. Ci sono tante
parti di più alto livello che potrebbero essere scritte utilizzando le
comodità aggiuntive del C++ o no? E per le parti più critiche nessuno mi
vieta di utilizzare il subset C del C++.
EMG

 usandolo come C++ ... non come "better C".
Secondo me i contendenti sono: da una parte l'ASM per le parti più
critiche, affiancato dal C per tutto il resto, e dall'altra l'ASM per le
parti più critiche, affiancato dal subset C del C++ per il resto del
kernel, e ancora affiancato dal C++ per tutto il resto. La visione sarà
un po' semplicistica ma secondo me rende l'idea.
EMG

 compilazione specifiche).
Questo salverebbe la situazione ma non penso sia richiesta dallo
standard questa feature di disabilitazione. O si?
EMG

 ma sempre applicativo!
Mah, questo, secondo me, è tutto da dimostrare. Io non sono neanche
convinto che il C++ sia adatto a scrivere software applicativo
commerciale...
EMG

questo è solo un ragionamento logico. 
Il problema che non hai ancora capito e' che il sottoinsieme C del C++
NON E' EQUIVALENTE al linguaggio C.
C e C++ seguono due strade diverse da molto tempo e cio' che SEMBRA C
nel C++ in realta' e' distinto da cio' che e' LINGUAGGIO C.

 un po' semplicistica ma secondo me rende l'idea.
A me pare che anche per la realizzazione di kernel l'unico elemento
controverso del linguaggio base del C++ standard (ovvero tutto cio' che
non riguarda la libreria) siano le eccezioni. Tutto il resto mi pare
utile e tendenzialmente vantaggioso rispetto al C.
Per quanto riguarda invece la libreria tutto cio' che avvolge
direttamente chiamate di sistema non e' utilizzabile. Il C++ ha il
vantaggio che questi elementi sono esplicitamente incapsulati, ad
esempio negli stream buffer o negli allocatori, ma il loro uso e'
relativamente complesso. Tutto il resto della libreria e' utilizzabile
anche nel kernel. Ad esempio tutti gli algoritmi.
Ciao,
Nicola

 Nicola
Sicuro? Sinceramente se dispongo di tanti sorgenti che mi sono utili, che
utilizzano una malloc, mi basterebbe definire un gestore con lo stesso nome
e basta! Cmq, il problema non sussiste, perché il kernel in se stesso, non
deve gestire strighe, non deve gestire liste e tante altre cose!! Che ne
dite se progettiamo tutti assieme un Kernel e poi vediamo che succede? Cosa
ci è utile, cosa no, e tutte le considerazioni che si possono fare su tale
proggetto?

 printf č possibilissimo tramite lo stesso C!
A maggior ragione nel C++ che mette a disposizione modi ben piů potenti
di personalizzazione della libreria standard.
EMG

il kernel di beos e' scritto in C++ e assembly
Casualmente ho installato BEOS5 qualche giorno fa e mi sono
messo a leggere i file di include. Non ho visto molti "std" :)
Io direi che il kernel BEOS e' scritto in "better C", e ci sono
riusciti visto che hanno anche predefinito una serie di altre
cose (ad es. quali sono i compilatori da usare).
Sto cercando anche info su come usarlo... (intendendo sviluppo)
faro' qualche esperimento con la cosa. Il primo esperimento
e' stato terribile... su
   #include <iostream>
   int main()
   {
     std::cout << "Hello, world." << std::endl;
     return 0;
   }
mi sono beccato degli "internal compiler error" ... ho pero'
provato BeIDE senza prima leggere nulla sulla cosa.
Sono poi riuscito a compilare programmi C++ che avevo scritto
precedentemente (in cui non ho pero' usato iostream) usando
g++ da una shell.


 e' stato terribile... su
gia' provato su 
free.be.com
? e il be developer group?
c'e' anche il beos user group italiano (benuke)

 c'e' anche il beos user group italiano (benuke)
dove sta questo 'benuke'?
l'ho cercato con altavista e su 
be.com
,ma non ho trovato niente :(
tnx
ciao
xaero

 dove sta questo 'benuke'?
www.bugit.org
 e' il sito principale
benuke.bugit.org
 e' il benuke
(e google lo trova subito :)

 proggetto?
Non e' cosi' semplice. Ai tempi della nascita di linux si potevano fare delle
assunzioni sull'HW che oggi non si possono piu' fare. In altre parole la
documentazione degli HW principali (HD IDE standard, VGA, seriale, parallela,
tastiera e mouse) erano facilmente reperibili e quasi tutti i PC erano
equipaggiati in questa maniera.
Oggi le cose sono piu' complesse. Sei obbligato a gestire come minimo il bus
PCI, i principali controller SCSI, e altre cosucce non cosi' semplici.
In ogni caso, se dovessi cominciare a pensare ad un OS nuovo che sia basato su
concetti OO (e che sarebbe quindi molto diverso sia da Windoes che da Unix nella
struttura) partirei con il separare orizzontalmente i layer. Ergo la prima fase
del lavoro e' quella di creare un HAL con interfacciamento OO.
Potrebbe essere interessante!
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 Potrebbe essere interessante!
Ok, la cosa sarebbe complicata perché effettivamente in rete si trova poco o
niente, i manuali praticamente non li fanno +, ma ceh dite di iniziare a
fare una cosa semplice tutti assieme per vedere i primi problemi e non
appena ci riusciamo, poi complichiamo la cosa, per vare un S.O. che sia di
gran lunga migliore di Windows?

gran lunga migliore di Windows?
Ma sei impazzito!!! Vuoi fare un S.O. (anche solo lo 'scheletro') via
NG????
Ma non avete nient'altro da fare???
^_________^
Luc.

"Luc" <TOGL...@katamail.com-TOGLI> ha scritto nel messaggio
news:8ra0et4sij1om9gn8...@4ax.com...

Certo ... o anche per E-MAIL tanto per non invadere i thread del NG!!! E
cmq, basterebbe il Kernel, di piccole dimensioni ... così poi il resto del
S.O. lo si fa per conto proprio. Non sarebbe male la cosa no? Così ci
rendiamo effettivamente conto di come le cose si semplificano e si
complicano!! Io butto la sfida ... poi se l'accettate tanto meglio. Potebbe
farci crescere un po' tutti, a mio parere!

S.O. lo si fa per conto proprio.
Ma scusa, tu sai cos'č un Sistema Operativo????????
Luc.

 dai!!!!
scusate se mi intrometto, ma secondo me non ha senso.
c'è tanto bello linux che ha un kernel molto solido, è supportatissimmo (non direttamente dai produttori hardware, ma semre
supportato)
secondo me sarebbe più utile scrivere un window manager tutto OO
finora non sono riuscito a vedere niente di buono spulciando i sorgenti di varie applicazioni GUI.
anzi, forse BeOS si, lui è il migliore... ho visto qualche sorgente, soloche BeOS è ancora un bambino e ha un futuro incerto...
boh.. io ho detto la mia
ciaotutti
xaero

 ha scritto nel messaggio
news:9bpg9b$a9r36$1...@ID-51253.news.dfncis.de...

certo che non ha senso, ma ci serve per capire effettivamente se la cosa è
fattibile al 100% e come può essere fatta!! CErto che poi nessuno
sicuramente lo userà!!!

 E cmq, basterebbe il Kernel, di piccole dimensioni ... 
ce ne sono gia' a bizzeffe, di kernel, dal topsy svizzero, a linux, a 
open bsd, e milioni di SO (vedi su sourceforge.net...) uno in piu' 
avrebbe poco senso, vederne qualcuno gia' funzionante e ragionarci 
sopra e' piu' istruttivo... (cosa che tra l'altro si fa nel corso di 
Sistemi Operativi, almeno ai mie tempi)

 ha scritto nel messaggio
news:1891350.G...@tin.it...

Di sistemi in C++, non se ne trovano poi tanti ... e cmq a noi che ci costa
provare? Ripeto ... a scopo didattico e istruttivo!

Potebbe farci crescere un po' tutti, a mio parere!
Fine pausa pranzo !
Torniamo a lavorare, per cortesia...

 NG????
Non sarebbe la prima volta che un OS viene sviluppato per NG e E-Mail da un
gruppo di volontari!


 gruppo di volontari!
grazie mille!! In fin dei conti Linux come è stato coordinato se gli
sviluppatori erano dispersi un po' x tutto il mondo?

gruppo di volontari!
Appunto, ne vogliamo fare un altro ancora????????
Luc.

"Luc" <TOGL...@katamail.com-TOGLI> ha scritto nel messaggio
news:cuk7etk8ak786g9jl...@4ax.com...

Rifaccio la domanda ... ti costa tanto? Ignoraci!! A te non va di dare una
mano? Fai a meno ... non sei obbligato. E poi cosa comporterebbe a te?
niente ... non vedo dove sta il problema!

niente ... non vedo dove sta il problema!
Ok, tanto io so come va a finire... 8) Non è la prima ne la seconda
volta 8-PPP
Ciao!
Luc.

"Luc" <TOGL...@katamail.com-TOGLI> ha scritto nel messaggio
news:6vm7etsoak5tiaat6...@4ax.com...

Che intendi?

Che intendi?
Che è già capitato che qualcuno volesse 'progettare' qualcosa di molto
interessante e spinto dalla novità abbia iniziato alla grande... ma
dopo poco tempo si arenava e perdeva la voglia... è normale se non lo
fai per professione!
Luc.

"Luc" <TOGL...@katamail.com-TOGLI> wrote in message
news:ijq7et00cvqarlopt...@4ax.com...

Soprattutto se hai anche altro da fare, per professione :-)


"Andrea Ferro" <And...@UrkaDVD.it> ha scritto nel messaggio
news:9c0q5v$r4t$1...@serv1.iunet.it...

Era solo una proposta a tempo perso ... senza nessun obbligo e che altro!!

Era solo una proposta a tempo perso ... senza nessun obbligo e che altro!!
Qundi tu volevi fare un S.O. a tempo perso... OK, hai capito tutto
della programmazione 'seria'... senza offesa!
Luc.

"Luc" <TOGL...@katamail.com-TOGLI> ha scritto nel messaggio
news:oiu7et8ufee0c74l2...@4ax.com...

E'  un'offesa perché sinceramente ho di meglio da fare nei miei progetti, ma
visto che la disputa era sulla capacità di realizzare un S.O. in C++ e delle
sue care prestazioni rispetto a quelle del C, allora avevo intenzione di
capire come stanno le cose. Un esercizio a mio parere, fa espandere la mente
anche a chi si ostina a seguire la programmazione su di un binario, senza
capire che oltre alla OO c'é ben altro! *a tempo perso* indicava ...
appunto di non prendere la cosa come troppo seria, fino a che magari le cose
non sono *ben fatte* ma se tutti partiamo col dire ... "no perché in passato
nessuno aveva volgia", "no perché abbiamo altro da fare", "no perché bla bla
bla" ... allora i poco seri siete voi che un semplice progetto, come ve lo
proponevo io (e ripeto ... in versione semplice da complicare in futuro se
le cose vanno bene), tirate il sederino indietro!! Peccato!

compilazione specifiche).
su questo hai perfettamente ragione
Anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

 le cose vanno bene), tirate il sederino indietro!! Peccato!
questo significa che non se ne fa niente? che peccato, io sono una
mezza calzetta, ma mi sarebbe piaciuto darvi una mano o anche solo
osservarvi.. sigh :(

capire che oltre alla OO c'é ben altro! *a tempo perso* indicava ...
Senti, vedi di darci un taglio.
Sei evidentemente convinto, anche dagli ultimi trascorsi su
it.comp.lang.c, che la programmazione in C conduca a risultati +
efficienti di quella in C++, non pretendere pero' che tutti siano
interessati ad approfondire l'argomento, specia quando lo si farebbe
scrivendo un sistema operativo ! 

 ha scritto nel messaggio
news:3ae702b5...@news.libero.it...

Evidentemente allora non hai capito il senso del discorso. Spiacente, ma
visto che sei un'autorità all'interno dei NG, probabilmente ti senti
superiore a certe metodologie che vanno avanti da un bel pezzo ... per
niente si continua a sviluppare Linux in C quando ormai il C++ è diventato
standard, quando convertire il codice lo si potrebbe fare vista la
diffusione dei gruppi di sviluppo. E cmq ripeto, su certi progetti il codice
C è + efficente di quello C++, su certi altri, lo è quello del C++ ... tutto
dipende dal progetto. Per niente avevo lanciato la sfida per vedere
effettivamente, da che parte sta il progetto di un S.O. Se nessuno vuole
cimentarsi in tale sfida, nessuno avrà ragione, e ognuno resta sulle proprie
idee, convinto fino all'osso che quel che sta dicendo è vero, quando magari
è solo una baggianata. Per cui ... chiesi io ... mettiamoci in discussione
... e nessuno l'ha voluto fare! Perchè? Qualcuno ha paura che quel che ha
detto può essere sbagliato e non ha intenzione di rischiare di far brutta
figura diffronte all'intero pubblico di questi NG?
E gente di questo tipo che attualmente lavora su Windows. Gente che continua
a stare dalla sua parte senza aprire l'orizzonte ad altre metodologie. Io mi
sono proposto di farlo ... poi stava solo a voi dire si o no ... non ho
obbligato nessuno e tantomeno minacciato. Bastava dire "no guarda ... non
abbiamo tempo" o una cosa simile e la discussione sarebbe finita a breve
termine.
Spiacente per chi voleva osservare dall'esterno la cosa!

E gente di questo tipo che attualmente lavora su Windows.
Ma tu, in questo momento, stai lavorando o hai tempo per cazzeggiare?
Luc.

"Luc" <TOGL...@katamail.com-TOGLI> ha scritto nel messaggio
news:bgofet8dpfuharivq...@4ax.com...

Io lavoro per 8 ore di fila ... per una societą che fa software per le
autoritą portuali del veneto e non cazzeggio!

 dipende dal progetto. Per niente avevo lanciato la sfida per vedere
Esistono solo due casi in cui il C e' piu' efficiente del C++. E non dipende dal
progetto ma dal compilatore.
Ovvero che tu abbia un compilatore C migliore del compilatore C++ ovvero che il
tuo compilatore C++ non ti permetta di disabilitare la gestione delle eccezioni.


autoritą portuali del veneto e non cazzeggio!
Ok, lavori come gli altri... e quando avresti il tempo di progettare
un S.O.? Scusa se sono curioso...
Luc.

 Luc.
Quando? Beh ... scendendo un po' a patti con il mio tempo libero, come sto
facendo con altri 2 progetti! Siamo in tanti no? Per cui non penso che 1
sola persona si sobbarcherebbe di questo gran casino, ma ognuno potrebbe
svilupparsi una sua parte!! Io sono abituato a pensare contemporaneamente a
5 o 6 cose! Lo stesso lavoro mi mette in condizioni di pensare a 5 o 6 cose!
Invece di perdere tempo con queste discussioni inutili ... lo stesso tempo
lo si potrebbe impiegare in tutt'altro! Insomma quando si ha tempo e non si
sa che fare ... tanto tempi di scadenza non ne abbiamo e come ripeto, ci può
servire per metterci in discussione tutto qui.... ma... a quanto pare
nessuno ne ha voglia e io sinceramente sarei un po' stanco di sentire e fare
critiche senza arrivare a nessuna conclusione. Per cui se nessuno ha
l'intenzione di discutere su qualcosa di serio senza insultarci a vicenda,
ma preferisce fare tutt'altro e perdere tempo in questo modo ... amen, chi
si è "sentito" si è "sentito" e ognuno sempre dritto per la sua strada.
Mi raccomando continuate così che siete forti, sempre a criticare senza
fornire qualcosa di concreto. Io almeno ho tentato di mettermi in
discussione!
Un saluto a tutti!!

[...]
Ciao
Marco Barisione (ICQ 84277092)

 ha scritto nel messaggio
news:3ae7f9f8...@news.inwind.it...

Cmq resta il fatto che continuano a farlo così...penso che se il codice
fosse + efficente, allora avrebbero inziato a fare anche la versione in C++,
risparmiando tempo e denaro! Cmq le scelte sono scelte ...

termine.
La decenza di una persona porta a non proporre neanche un'idea del
genere a gente che, presumibilmente, dovendo lavorare, non ha il
benche' minimo tempo da dedicare a un progetto del genere.
Comincia a pensare + seriamente alla programmazione.

 ha scritto nel messaggio
news:3ae815ec...@news.libero.it...

Si da il caso che programmo per tutto il giorno su progetti di portata non
da poco, tanto da impiegare 2 o 3 anni di fila con un gruppo di persone che
sta li a ragionare alla soluzione + veloce, + semplice e + efficiente, e
oltretutto con metodologie che spaziano dall'OOP alla programmazione ad
eventi. Non ho proposto a nessuno di gareggiare, non ho proposto il progetto
a chi non lo voleva fare e soprattutto a chi non ha tempo! Io l'ho solo
proposto e basta! Nessuno lo vuole fare? Ok ... amen ... basta finita li ...
chiuso il discorso! A me non pareva di aver proposto questo gran sistema
operativo che potesse competere con Linux, windows, beos, e nemmeno DOS ...
ma un semplicissimo Kernel, di piccole dimensioni, proprio la cosa + piccola
e semplice ... ma poi qualcuno ha preso la cosa troppo alla grande, pensando
di dover fare chissà che immensità ...
E cmq la scarsa efficienza ...deriva cmq dal compilatore ... e quindi dal
linguaggio, fintanto ché, non esisterà un compilatore decente. In quel caso
allora la scarsa efficienza non sarà + imputata al linguaggio!
Fine del discorso ... dedicate pure l'attenzione a qualcos'altro e lasciate
perdere tutto il resto!

perdere tutto il resto!
Grazie!!!!!!!!!!!!!!!!!!!
Luc.

di dover fare chissà che immensità ...
Non hai le idee abbastanza chiare su cosa significhi sviluppare il
kernel (per quanto semplicissimo, per quanto di piccole dimensioni) di
un sistema operativo.  Ti consiglio la lettura di "Sistemi Operativi"
di Tanenbaum-Woodhull, V edizione.
E con questo concludo questo noiosissimo thread.

 gareggiare.
C'e' sempre comp.programming.contests


 allora la scarsa efficienza non sarà + imputata al linguaggio!
Quale scarsa efficienza? Quale compilatore? VC7 non e' 100% compliant ma e' un
ottimo compilatore dal punto di vista dell'efficienza (ovvero ottimizzazione).


 eventi.
Forse sbaglio, ma non vedo la programmazione ad eventi allo stesso
livello della OOP, generica, etc.
EMG

Senza contare che le operazioni di I/O sono decisamente più facili.
Questione di gusti. Sinceramente i BEGIN END erano una delle cose che
mi stavano più antipatiche nel Pascal.
Il Ghenio
WINWORD.EXE - ERRORE DI APPLICAZIONE
l'istruzione a "0x3017ff27"ha fatto riferimento alla
memoria a "0x02a3143c".La memoria non poteva essere 'read'.

modi per "farsi del male".
anche in VB ti puoi fare del male (basta eseguirlo, ad esempio ;-) se
è per questo. Però stavamo parlando di persone che non sanno ancora
cosa sono una variabile, una stringa ed un ciclo. Con il Pascal
possono impararli abbastanza tranquillamente, con il C no.


possono impararli abbastanza tranquillamente, con il C no.
Secondo me neanche con il C++. Sono convinto che sia un linguaggio
con troppe asimmetrie e una complessita' troppo alta per iniziare.
E' pero' a mio parere uno strumento ottimo una volta che non si
hanno le idee confuse sui fondamenti.
Secondo me il C++ permette di astrarre molto bene... ma solo a
chi capisce cosa succede dietro; in altri casi credo sia preferibile
qualcosa di piu' pulitino, simmetrico e astratto (anche se meno
versatile).
JMO
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 possono impararli abbastanza tranquillamente, con il C no.
Scusa, ti spiegheresti meglio ?
Massimo

Scusa, ti spiegheresti meglio ?
Secondo me, quando uno deve imparare a programmare, non deve scendere
troppo a basso livello.
Deve imparare prima di tutto a pensare da programmatore, in seguito
deve imparare un linguaggio.
Ora, in Pascal è possibile capire ed utilizzare gli array senza troppo
sforzo. In C bisogna capire anche cosa sono i puntatori, che in
quest'ottica sono distraenti.
E in quest'ottica vanno intese anche, ad esempio, le stringhe.
Quindi io consiglio ad un principiante assoluto di partire dal Pascal


buono e giusto e cosa equivale ad un suicidio).
su questo non c'è dubbio. Però il discorso era diverso: stavamo
parlando di persone che devono imparare i concetti base; devono
imparare a fare cose del tipo "scrivere una funzione che somma due
numeri", "scrivere un algoritmo che calcola la media" e, aumentanto in
complessità, "scrivere la funzione che calcola il fattoriale".
Non hanno importanza le prestazioni. L'importante è imparare a
programmare, non imparare il C++.
Non vedo molto diversi questi due listati:
var 
  i:integer;
  a:array[1..10] of real;
  somma:real;
begin
  somma:=0;
  for i:=1 to 10 do
    somma:=somma+a[i];
  writeln('la media è ',somma/10);
end.
#include <iostream>
#include <vector>
using namespace std;
int main() {
  vector<double> a(10);
  double somma=0;
  int i;
  for(i=0; i<10; i++)
    somma+=a[i];
  cout << "la media è " << somma/10;
}
Cmq, come ho già detto più volte, continuo a preferire il Pascal per
un principiante; ma anche il C++ *potrebbe* essere preso in
considerazione.


 scendere anche sui costrutti a basso livello, quindi puntatori,
Sembra sempre che il programmatore migliore sia quello che scrive il codice piu'
veloce. Guardate che non e' affatto cosi'. E' estremamente raro che un dato
pezzo di codice debba essere reso "il piu' veloce possibile" (praticamente solo
quando partecipi ad una gara per decidere chi e' capace di scrivere il codice
piu' veloce!!!). Normalmente e' probabile che un dato codice debba eseguire "al
massimo in tot".


 wrote in message
news:9ccfls$6p8$1...@news.mclink.it...

cos'e' un tentativo di ricorsione?
Rileggiti i post iniziali del thread (che risalgono ad un mesetto fa),
altrimenti ricominciamo da capo!!


quest'ottica sono distraenti.
Non esageriamo.
Gli array esistono anche in C e si puo' benissimo studiarli ed
utilizzarli inizialmente senza sapere cosa siano i puntatori.

 considerazione.
Sai come la penso!


 wrote in message
news:3aeaf28b...@news.libero.it...

Prova a passare un array ad una funzione senza sapere come funzionano i
puntatori.
Rispondi (senza parlare di puntatori) a questa domanda:
Posso passare un intero per reference con "f(int &i)" o per valore con "f(int
i)", se provo a passare un array per reference con "f(int &i[3])" mi dice che
non puo' creare degli array di reference, pero' funziona con "f(int (&i)[3])",
anche se io pensavo che "i[3]" fosse un vettore. Comunque se provo a passare un
array per valore con "f(int i[3])" il compilatore sembra passarlo sempre per
reference. Allora non ho capito quale e' la differenza fra "f(int (&i)[3])" e
"f(int i[3])". E poi non ho capito come faccio a passare un array per valore e
perche' non posso creare array di reference.
Tutte domande che difficilmente un principiante si pone se lavora in pascal. E'
chiaro dalla sintassi e dagli eventuali errori del compilatore cosa si puo' fare
e come farlo.
Se sto insegnando i fondamentali ad un principiante NON VOLGIO che domande come
queste (relative al linguaggio e non agli array) possano persino venirgli in
mente!


puntatori.
Penso fosse chiaro che mi sto riferendo ad un principiante come uno
che sta imparando ad usare il linguaggio.  E' chiaro che prima o poi
dovra' cimentarsi coi puntatori, se sta imparando il C, ma lo si puo'
evitare per i primi tempi.

Tutto abbastanza intuibile. (sei sicuro che ci vada il ; dopo la writeln?)
si può sia omettere che inserire.


e sconfinamenti.
Mi permetto di aggiungere alla lista anche il PHP,pur avendo una
sintassi molto simile al C é decisamente hi-level.
