View Full Version : The difference between C & C++
Chi me le spiega?
Oltre a sapere le potenzialità, intendo come programmazione, i comandi sono diversi? Quanto diversi?
Se imparo C , ci vorrà molto per imparare ad utilizzare C++, o è meglio che impari prima quest'ultimo? Oppure posso impararli parallelamente senza creare confusione?
^TiGeRShArK^
14-12-2006, 14:59
Chi me le spiega?
Oltre a sapere le potenzialità, intendo come programmazione, i comandi sono diversi? Quanto diversi?
Se imparo C , ci vorrà molto per imparare ad utilizzare C++, o è meglio che impari prima quest'ultimo? Oppure posso impararli parallelamente senza creare confusione?
il c normale (non l'object c) non è ad oggetti il c++ si tnt x citare la prima differenza ke mi viene in mente.
Io direi di iniziare direttametne dal Java :asd:
Altrimenti tra quelli da te proposti direi indubbiamente il C++.
Nel 2006 non ha alcun senso partire con la programmazione procedurale ormai :D
Nel 2006 non ha alcun senso partire con la programmazione procedurale ormai :D
cosaaaaaaaaa?
il C è la base....sopratutto del C++...
partire da 0 con C++ vuol dire farsi del male.
io partirei con un buon libro tipo K&R, per poi passare a vedere le classi.
cosaaaaaaaaa?
il C è la base....sopratutto del C++...
partire da 0 con C++ vuol dire farsi del male.
io partirei con un buon libro tipo K&R, per poi passare a vedere le classi.
Mi dai scrittori e casa editrice del libro consigliato?
^TiGeRShArK^
14-12-2006, 15:48
cosaaaaaaaaa?
il C è la base....sopratutto del C++...
partire da 0 con C++ vuol dire farsi del male.
io partirei con un buon libro tipo K&R, per poi passare a vedere le classi.
:mbe:
e mi spieghi a ke ti serve partire con la programmazione procedurale?
Anke all'università ai tempi eravamo partiti con i costrutti base del C++ (ke sono assolutametne identici al C).
Ma mettersi ad imparare la programmazione procedurale nel 2006 non ha il minimo senso.
Tanto vale iniziare da un linguaggio come Java o Python/Ruby per capire la programmazione ad oggetti fregandosene delle cose + a basso livello.
Ormai la base è saper programare BENE ad oggetti.
Ke poi tu sappia usare un linguaggio oppure un altro non ti cambia assolutamente nulla.
Almeno io non ho alcuna difficoltà a imparare linguaggi ke non conosco.
The C Programming Language, Second Edition
by Brian W. Kernighan and Dennis M. Ritchie.
la "BIBBIA" del C, meglio in lingua originale la traduzione lascia a desiderare.
la versione italiana è di: Gruppo Editoriale Jackson
l'originale credo: Prentice Hall, Inc
il motivo per cui ti consiglio di partire dal C, è perche libri e documentazione di C++ danno per scontato: sintassi, costrutti e problematiche del C!!!!
sfido chiunque sia adigiuno di C a leggere questo libro
http://www.research.att.com/~bs/3rd.html :eek:
e a capirci qualcosa di più dei primi capitoli
The C Programming Language, Second Edition
by Brian W. Kernighan and Dennis M. Ritchie.
la "BIBBIA" del C, meglio in lingua originale la traduzione lascia a desiderare.
la versione italiana è di: Gruppo Editoriale Jackson
l'originale credo: Prentice Hall, Inc
il motivo per cui ti consiglio di partire dal C, è perche libri e documentazione di C++ danno per scontato: sintassi, costrutti e problematiche del C!!!!
Thanks
^TiGeRShArK^
14-12-2006, 16:44
The C Programming Language, Second Edition
by Brian W. Kernighan and Dennis M. Ritchie.
la "BIBBIA" del C, meglio in lingua originale la traduzione lascia a desiderare.
la versione italiana è di: Gruppo Editoriale Jackson
l'originale credo: Prentice Hall, Inc
il motivo per cui ti consiglio di partire dal C, è perche libri e documentazione di C++ danno per scontato: sintassi, costrutti e problematiche del C!!!!
sfido chiunque sia adigiuno di C a leggere questo libro
http://www.research.att.com/~bs/3rd.html :eek:
e a capirci qualcosa di più dei primi capitoli
appunto.
Proprio per quel motivo il mio consiglio è di lasciar perdere completametne il C/C++ e di concentrarsi piuttosto su C#/Java/Python/Ruby.
In questo modo imparerà direttamente la programmazione ad oggetti magari con una buona introduzione sui costrutti di base.
appunto.
Proprio per quel motivo il mio consiglio è di lasciar perdere completametne il C/C++ e di concentrarsi piuttosto su C#/Java/Python/Ruby.
In questo modo imparerà direttamente la programmazione ad oggetti magari con una buona introduzione sui costrutti di base.
Mi spiegi che significa programmare a oggetti.
P.S. Devo cmq partire da C o C++, all'esame che devo conseguire devo portare loro due.
Però non dico che non mi piacerebbe imparare il C# adesso che M$ ha rilasciato il XNA game studios ;)
tiger non vedo le ragioni di questo tuo accanimento verso i linguaggi di basso livello. la programmazione a oggetti è comoda e facile, ma poco efficiente e quindi decisamente inadatta a certe problematiche. inoltre è molto più semplice da capire se si hanno già le basi della programmazione procedurale.
se deve scriversi un driver? un kernel? se deve programmare un microcontrollore? che fai, usi java? tutto dipende dagli usi che uno deve farne... il linguaggio è il mezzo, non il fine...(lo stesso dicasi per il paradigma di programmazione)
Sono d'accordo...ma anche io sarei per partire con un linguaggio OO...
Il problema principale dei corsi che fin'ora ho visto è che spiegano come usare il linguaggio, ma non spiegano ciò che comporta l'uso dei vari costrutti...
Di fatto io preferirei che ci fosse un'introduzione generale alla programmazione OO, spiegando magari le varie entità in gioco (con UML ? Potrebbe essere una strada valida) ed i possibili collegamenti fra le entità...
A quel punto è sicuramente possibile imparare come primo linguaggio un linguaggio OO...
Imparare direttamente il C++ porta spesso ad usarlo come il C ;) Ma ho visto cose fatte in Java dagli studenti anche peggiori...vedi fare l'oggetto che contiene il main con tutti metodi statici...
Quando gli insegnanti capiranno che conoscere un linguaggio non vuol dire solo conoscerne il framework allora sarà possibile...
Tutte le difficoltà che si hanno con il C++ derivano secondo me solo dall'approccio sbagliato... Presentare il C++ come un linguaggio OO e non come un insieme di librerie risolverebbe molti problemi di "mentalità" di chi lo usa...
^TiGeRShArK^
15-12-2006, 10:50
se deve scriversi un driver? un kernel? se deve programmare un microcontrollore? che fai, usi java? tutto dipende dagli usi che uno deve farne... il linguaggio è il mezzo, non il fine...(lo stesso dicasi per il paradigma di programmazione)
bhè..
volendo potrei anke usare java perchè no? ;)
Il punto nodale ke hai beccato sta proprio nell'ultima frase che hai detto: "il linguaggio è il mezzo, non il fine".
E poichè il mezzo deve essere quello che mi dia il risultato migliore, non vedo perchè ad esempio devo masochisticametne mettere a programmare in C su Symbian x il cellulare quando con un decimo del tempo posso fare le stesse cose in Java.
Potenzialmente l'ideale sarebbe programmare TUTTO in linguaggi ad alto livello o addirittura in linguaggi di scripting e solo ed esclusivamente le parti "mission-critical", se necessitano di un'ulteriore ottimizzazione, in linguaggi + a basso livello.
Purtroppo però questo non è sempre possibile x diverse applicazioni, ma cmq in generale è la soluzione migliore.
In questo modo il fine torna ad essere il software da ottenere.
Il mezzo + semplice, e quindi quello da utilizzare, non è quasi mai il C, tranne ke in poki casi particolari km appena detto.
E cmq una volta imparato il paradigma di programmazione ad oggetti gli verrà naturale cambiare da un linguaggio di programmazione all'altro dato ke cambieranno solo la sintassi di base e le API.
Ovviamente se questo gli serve x un corso universitario allora è inutile pensare a kos'è meglio x lui perchè tanto è costretto ad utilizzare uno dei 2 :p
Cmq fosse x me all'università farei prima corsi di Java e solo dopo quelli di C/C++.
Ma si sa.. in italia il masochismo, soprattutto nel mondo del software, è MOLTO ma MOLTO diffuso :D
Da un punto di vista didattico ritengo fondamentale soffermarsi *prima* sugli algoritmi e le strutture dati, senza distrarsi con aspetti OO. Conoscere solo questi ultimi non ti permette comunque di affrontare la stragrande maggioranza dei problemi informatici che si incontrano nella pratica.
Inoltre la programmazione OO non è, imho, lo stato dell'arte.
finger roll
15-12-2006, 13:59
Da un punto di vista didattico ritengo fondamentale soffermarsi *prima* sugli algoritmi e le strutture dati, senza distrarsi con aspetti OO. Conoscere solo questi ultimi non ti permette comunque di affrontare la stragrande maggioranza dei problemi informatici che si incontrano nella pratica.
Inoltre la programmazione OO non è, imho, lo stato dell'arte.
Quoto in pieno!!! La programmazione ad oggetti permette di fare molte rispetto alla procedurale.
Il mio consiglio è partire dalla procedurale, e dallo studio delle varie strutture dati, poi il passaggio alla OO sarà molto semplice.
Iniziare subito con le classi senza passare dalle basi secondo me non va molto bene. Poi se uno vuole imparare solo OO per passione o così, nessuno lo vieta ;)
E' chiaro che le strutture dati siano fondamentali e devono essere fatte. Niente vieta di farle dopo la teoria sulla programmazione ad oggetti e di usare un linguaggio OO per le esercitazioni. Sono cose completamente distinte.
E' chiaro che le strutture dati siano fondamentali e devono essere fatte. Niente vieta di farle dopo la teoria sulla programmazione ad oggetti e di usare un linguaggio OO per le esercitazioni. Sono cose completamente distinte.
:mano:
trallallero
15-12-2006, 14:34
The difference between C & C++: ++ :O
Da un punto di vista didattico ritengo fondamentale soffermarsi *prima* sugli algoritmi e le strutture dati, senza distrarsi con aspetti OO. Conoscere solo questi ultimi non ti permette comunque di affrontare la stragrande maggioranza dei problemi informatici che si incontrano nella pratica.
Inoltre la programmazione OO non è, imho, lo stato dell'arte.
Concordo in pieno, è inutile studiare un linguaggio se prima non si riesce ad entrare nel "meccanisimo mentale" della programmazione, e quindi se non si capiscono per bene gli algoritimi e le famose tre strutture :D.
In ogni caso se ci si diverte a programmare si parte da dove si vuole, se lo si deve fare per lavoro o cmq necessità è bene capire il fine dell'apprendimento quale sia. Cosa devi fare con la programmazione?
Come ho già detto io inizierei a vedermi gli algoritimi, ed inizierei a sbattere la testa su come trasformare vari problemi in algoritmi efficienti, così da avere delle buone basi.
La documentazione che si trova su internet abbonda (e forse è un problema :D). Cerca qualcosa sui fondamenti della programmazione ;).
Io in ogni caso ho iniziato con Java, è quello che mi serve per l'università e anche se ho iniziato a scrivere qualche hello world :D anni fa solo di recente mi ci sto mettendo sotto ;).
Che ci devo fare?
Sicuramente programmi riguardanti l'analisi matematica, e la fisica.
Questo lo devo fare, ma già che ci sono volevo imparare anche a fare anche altro. Chi ha visto i miei primi due programmi in C ha capito che sono proprio prima dell'inizio con la programmazione (anche se qualche anno fà avevo seguito un corso di GWBasic :old: :D )
penso cmq di iniziare a questo punto da C, insomma mi sembrate tutti daccordo sul fatto che sia la base di tutto.
Forse il libro che mi ha consigliato vizzz ce l'ha un mio amico, però la versione inglese, che è anche vero che mi ha detto che è migliore, ma che mazzata tradurlo tutto, secondo voi ne vale la pena andarmelo a comprare e i italiano? Nel senso Con quello in italiano si perde molto di qualità? E' semplice da tradurre quello inglese?
Sicuramente programmi riguardanti l'analisi matematica, e la fisica.
Allora impara Matlab ;)
...
P.S. Devo cmq partire da C o C++, all'esame che devo conseguire devo portare loro due...
Devo impararli tutti e due, poi anche gli altri se mi và, ma per scuola me li devo fare entrambi (insomma non è che mi dispiaccia, del resto meglio questo che studiare il paramecium ,un batterio che abbiamo fatto in biologia).
fidati...all'università, più vai avanti coi corsi, più i libri diventano solo inglese...quindi tanto vale cominciare da subito...soprattutto ricordati che non devi "tradurlo", devi "capirlo"!
Allora me lo traduco...poi vediamo se riesco a capirlo :D
jappilas
15-12-2006, 15:37
se deve scriversi un driver? un kernel? se deve programmare un microcontrollore? che fai, usi java? java forse no ( ma solo perchè interpretato in bytecode da una virtual machine )
ma kernel in C++ e/o embedded C++ esistono, come esistono studi proprio sul metodo seguito per applicare a determinate applicazioni il paradigma OO e uno specifico linguaggio (o, cosa per certi versi anche più interessante, uno specifico subset di un certo linguaggio)
poi se mi parli di applicazioni speciali, allora si può anche dire di quel che fanno in ambito segnalamento ferroviario (programmati secondo SIL4, che include tra l'altro variabili preallocate staticamente, senza allocazione dinamica della memoria)
ma non si può dire che si tratti di situazioni rappresentative della programmazione nel suo complesso, e per le quali un aspirante programmatore debba vivere come se non esistesse altro
Inoltre, è facile dire che un paradigma di programmazione sia intrinsecamente meno efficiente e intrinsecamente inadatto a determinati ambiti, ma non vuol dire nulla se se poi non si va a illustrare nei dettagli a cosa l' inefficienza o inadeguatezza sia dovuta ...
Chi me le spiega?
Oltre a sapere le potenzialità, intendo come programmazione, i comandi sono diversi? Quanto diversi?C++ si può considerare un superset del C, con aggiunta di funzionalità, quindi un linguaggio più che "Object Oriented", "object supportive" (contrariamente ad altri linguaggi effettivamente orientati ed anzi basati sugli oggetti): quello che imparerai sui costrutti sintattici di C sarà riutilizzabile in programmi C++
The difference between C & C++: ++ :Oun incremento sostanzioso :D :
anonymous unions
classes
namespaces
constructors and destructors
exceptions and try/catch blocks
external function linkages
member functions
function overloading
operator overloading
new and delete operators and functions
new reference types
standard template library (STL)
template classes
template functions
Se imparo C, ci vorrà molto per imparare ad utilizzare C++, o è meglio che impari prima quest'ultimo? Oppure posso impararli parallelamente senza creare confusione?se la scelta è sull' ordine in cui imparare questi due linguaggi, la mia netta sensazione è che sia più conveniente partire dal C (per il motivo che dicevo sopra), ma anche - per inciso - che per entrare da *zero* in contatto con la programmazione OO, C++ non sia il linguaggio migliore (ha una complessità commisurata alle sue potenzialità espressive, quindi in certi aspetti elevata)
Sul tempo per "impararlo"... credo che dipenda più che altro dalla facilità con cui prima assimilerai i concetti che supporta e implementa, come incapsulazione, ereditarietà, genericizzazione...
java forse no ( ma solo perchè interpretato in bytecode da una virtual machine )
ma kernel in C++ e/o embedded C++ esistono, come esistono studi proprio sul metodo seguito per applicare a determinate applicazioni il paradigma OO e uno specifico linguaggio (o, cosa per certi versi anche più interessante, uno specifico subset di un certo linguaggio)
poi se mi parli di applicazioni speciali, allora si può anche dire di quel che fanno in ambito segnalamento ferroviario ( microcontrollori, programmati secondo sil4, che include tra l'altro variabili preallocate staticamente, e nessuna allocazione dinamica della memoria)
ma non si può dire che si tratti di situazioni rappresentative della programmazione nel suo complesso, e per le quali un aspirante programmatore debba vivere come se non esistesse altro
Inoltre, dire che un paradigma di programmazione sia intrinsecamente meno efficiente e intrinsecamente inadatto a determinati ambiti è facile, ma non vuol dire nulla se se poi non si va a indagare nei dettagli a cosa l' inefficienza o inadeguatezza sia dovuta ...
C++ si può considerare un superset del C, con aggiunta di funzionalità, quindi un linguaggio più che "Object Oriented", "object supportive" (contrariamente ad altri linguaggi effettivamente orientati ed anzi basati sugli oggetti): quello che imparerai sui costrutti sintattici di C sarà riutilizzabile in programmi C++
un incremento sostanzioso :D :
anonymous unions
classes
namespaces
constructors and destructors
exceptions and try/catch blocks
external function linkages
member functions
function overloading
operator overloading
new and delete operators and functions
new reference types
standard template library (STL)
template classes
template functions
se la scelta è sull' ordine in cui imparare questi due linguaggi, la mia netta sensazione è che sia più conveniente partire dal C (per il motivo che dicevo sopra), ma anche - per inciso - che per entrare da *zero* in contatto con la programmazione OO, C++ non sia il linguaggio migliore (ha una complessità commisurata alle sue potenzialità espressive, quindi in certi aspetti elevata)
Sul tempo per "impararlo"... credo che dipenda più che altro dalla facilità con cui prima assimilerai i concetti che supporta e implementa, come incapsulazione, ereditarietà, genericizzazione...
Anche se ho capito la metà (neanche) di quello che hai detto, ti ringrazio :D . Vada per C allora
jappilas
15-12-2006, 15:46
Anche se ho capito la metà (neanche) di quello che hai detto, ti ringrazio :D no no aspetta... se ho scritto in modo non chiaro e/o hai delle curiosità, tu chiedi e io traduco :)
trallallero
15-12-2006, 15:53
Anche se ho capito la metà (neanche) di quello che hai detto, ti ringrazio :D . Vada per C allora
perché ? in fondo c'é solo un ++ in piú :D
fai bene va. Secondo me il concetto della programmazione ad oggetti é una stronzata da capire perché imita proprio ... gli oggetti in natura.
Ma il C++ é una bestia e senza il C non ci fai niente perché sei obbligato a conoscere il basso livello.
E poi l'elenco che ha postato jappilas parla chiaro: non é solo l'aggiunta delle classi al C ma qualcosina in piú (io stesso non so neanche se mi ricordo ... :rolleyes: )
O passi direttamente al java, ma rischi di rimanere legato a quello senza mai esplorare il mondo basso livello, o inizi dal C e ti fai tutta la gavetta ;)
java forse no ( ma solo perchè interpretato in bytecode da una virtual machine )
ma kernel in C++ e/o embedded C++ esistono, come esistono studi proprio sul metodo seguito per applicare a determinate applicazioni il paradigma OO e uno specifico linguaggio (o, cosa per certi versi anche più interessante, uno specifico subset di un certo linguaggio)
poi se mi parli di applicazioni speciali, allora si può anche dire di quel che fanno in ambito segnalamento ferroviario (programmati secondo SIL4, che include tra l'altro variabili preallocate staticamente, senza allocazione dinamica della memoria)
ma non si può dire che si tratti di situazioni rappresentative della programmazione nel suo complesso, e per le quali un aspirante programmatore debba vivere come se non esistesse altro
Inoltre, è facile dire che un paradigma di programmazione sia intrinsecamente meno efficiente e intrinsecamente inadatto a determinati ambiti, ma non vuol dire nulla se se poi non si va a illustrare nei dettagli a cosa l' inefficienza o inadeguatezza sia dovuta ...
C++ si può considerare un superset del C, con aggiunta di funzionalità, quindi un linguaggio più che "Object Oriented", "object supportive" (contrariamente ad altri linguaggi effettivamente orientati ed anzi basati sugli oggetti): quello che imparerai sui costrutti sintattici di C sarà riutilizzabile in programmi C++
un incremento sostanzioso :D :
anonymous unions
classes
namespaces
constructors and destructors
exceptions and try/catch blocks
external function linkages
member functions
function overloading
operator overloading
new and delete operators and functions
new reference types
standard template library (STL)
template classes
template functions
se la scelta è sull' ordine in cui imparare questi due linguaggi, la mia netta sensazione è che sia più conveniente partire dal C (per il motivo che dicevo sopra), ma anche - per inciso - che per entrare da *zero* in contatto con la programmazione OO, C++ non sia il linguaggio migliore (ha una complessità commisurata alle sue potenzialità espressive, quindi in certi aspetti elevata)
Sul tempo per "impararlo"... credo che dipenda più che altro dalla facilità con cui prima assimilerai i concetti che supporta e implementa, come incapsulazione, ereditarietà, genericizzazione...
I termini che ho evidenziato non so che vogliano dire, non era certo un critica alla tua chiarezza, ma sono termini tecnici che io non so ancora, in ogni caso prima o poi li dovrò imparare pure io :D ;)
giannola
15-12-2006, 15:57
penso cmq di iniziare a questo punto da C, insomma mi sembrate tutti daccordo sul fatto che sia la base di tutto.
concordo con chi come vi(e più zeta) :D ti dice di partire dal c e non dal c++.
Entrambi sono due linguaggi di alto livello, ovvero più vicini alla comprensione del programmatore che non al linguaggio macchina.
Cosa differenzia il c++ dal c ?
Essenzialmente il fatto che il c++ è orientato agli oggetti.
Che significa ?Cosa sono gli oggetti ?
Essenzialmente gli oggetti sono dei moduli di codice di programmazione che contengono un insieme di valori dette proprietà e di funzioni dette metodi.
Questo proprio sinteticamente. ;)
Ecco che torniamo al c, se non si comprende bene come sviluppare delle funzioni, non si riuscirà nemmeno a creare degli oggetti.
Ora poichè il c è un linguaggio basato sulle funzioni è importante partire da quello proprio per approfondire il significato di visibilità delle variabili, di ricorsività ma soprattutto della creazione delle strutture dati che rappresentano concettualmente i progenitori delle classi, inoltre ci si concentra molto di più nella programmazione sull'uso delle liste ovvero delle strutture dati basate sui puntatori (quindi una gestione diretta della ram).
Quest'ultimo è anche il motivo per cui si afferma che il "c è il più basso tra i linguaggi di alto livello" ed è anche il motivo per cui nè java sarà mai buono per programmare un kernel.
Quando ti sarai fatto le ossa sul c allora potrai con facilità passare al c++ che oltre al concetto di classe integrerà il concetto di ereditarietà.
giannola
15-12-2006, 15:59
java forse no ( ma solo perchè interpretato in bytecode da una virtual machine )
:eek:
java non ha i puntatori, questo (più che l'essere interpretato) non lo rende idoneo.
Secondo me il concetto della programmazione ad oggetti é una stronzata da capire perché imita proprio ... gli oggetti in natura.
da capire si, da saper usare è tutto un altro mondo.
:eek:
java non ha i puntatori, questo (più che l'essere interpretato) non lo rende idoneo.
Credo che volesse riferirsi al fatto che il codice java, nato per essere trasformato in bytecode interpretabile da una ben definita macchina virtuale, non può che agire nell'ambito dell'ambiente messogli a disposizione.
Per chi volesse approfondire la tua, comunque giusta, affermazione questo link (http://en.wikipedia.org/wiki/Reference_%28computer_science%29) spiega la differenza tra 'reference' (Java) e 'pointer' (C).
jappilas
15-12-2006, 19:06
subset è letteralmente il sottoinsieme, superset il (scoperto ora l' esistenza del termine italiano :D) superinsieme, quindi rispettivamente gli insiemi contenuto e contenente, rispetto ad un altro più grande, o più piccolo, per cui valga la condizione "gli elementi dell' insieme più piccolo sono anche elementi di quello più grande"
in questo caso, riferito alle funzionalità di linguaggi di programmazione, un linguaggio è un subset di un altro se contiene solo una parte delle sue keyword (comandi, ma anche tipi di dato primitivi ecc ), un superset se riprende l' altro aggiungendo parole chiave e funzioni
SIL4... :D SIL4 sta per software integrity level 4, standard a cui corrispondono delle metodiche (di cui mi parlava un amico che lavora in ansaldo segnalamento ferroviario) tese a rendere il codice della parte SW del "prodotto", deterministico (cosa che semplificando vuol dire caratterizzata da comportamento noto a priori nei suoi dettagli e per ogni possibile input e condizione operativa, quindi tale che ogni "stato" in cui si possa trovare, sia conoscibile o calcolabile, e quindi prevedibile e gestibile in fase di progetto)
ma soprattutto altre tese a garantire e certificare che tutti i componenti lo siano, sia uno per uno individualmente, sia la loro unione operativa sul campo
in questo contesto uno degli accorgimenti che ha dovuto prendere per lavorare su quei sistemi è stata l' eliminazione dell' allocazione dinamica, cioè: il suo codice non può contare sulla possibilità di allocare memoria in fase di funzionamento...la memoria di cui può disporre viene allocata all' avvio, ed è tutta e sola quella dichiarata, quindi tutte le variabili utilizzate vengono allocate e poi solo modificate
Object Oriented : riguardo il paradigma in cui un progetto sw viene concepito come orientato agli oggetti, per contrasto con "procedurale"
object supportive: espressione, coniata non da me (anche se effettivamente non comune), con cui volevo sottolineare il concetto che C++, pur essendo dotato delle keyword dedicate all' implementazione del paradigma Object Oriented, non lo imponga costringendo il programmatore a ragionare in termini di oggetti, classi e dipendenze tra classi ... e quindi, a differenza di altri linguaggi in cui il concetto di "classe" è pervasivo, lo "supporti" (questo tra l'altro fa sì che un compilatore c++ sia anche un compilatore c)
L' incapsulazione (encapsulation) è una caratteristica principale del paradigma di programmazione orientata agli oggetti, e corrisponde a inglobare, per una determinata categoria di entità, quelle che sono proprietà caratterizzanti, e quelle che sono le operazioni che (tutte) le entità appartenenti a quella categoria possono eseguire su richiesta: le prime diventano dati membro , le seconde funzioni membro (o più comunemente metodi) della stessa classe (corrisp alla "categoria"): per inciso un oggetto è un' istanza di una classe, (nè più ne meno che per gli altri tipi di dato, tanto è vero che in genere le classi sono trattate come "tipi di dato definiti dall' utente" - che nel caso di un linguaggio di sviluppo è il programmatore) quindi l' encapsulation alla fine consiste nel risultante raggruppamento dei dati e del codice che li manipola
E' interessante notare che una volta che tutti i dati e le funzioni di manipolazione pertinenti a una stessa categoria di entità sono raggruppate in una stessa classe, può venire logico pensare "proteggerli" applicando delle politiche di accessibilità : e infatti è quello che avviene ed è detto information hiding... tra l'altro la prassi comune prevede di rendere i dati manipolabili solo dai metodi della stessa classe, e di rendere accessibili dal resto del codice, solo questi ultimi
L' ereditarietà (inheritance) è un' altra caratteristica basilare della programmazione object oriented e dei linguaggi che la supportano: al tempo stesso mi sono reso conto delle difficoltà che ho a descriverla a parole in termini generici, quindi farò un paio di esempi concreti
- poniamo di gestire un magazzino di pezzi meccanici ed elettronici: essendo diversi, ognuno avrà delle caratteristiche dipendenti dal suo tipo ...
al tempo stesso ognuno ha nel gestionale, un proprio ID, un valore di costo, un campo disponibilità in pezzi, associati a una voce Articolo
un certo tipo di bullone avrà campi specifici per il passo e la lunghezza, un motorino passo passo avrà il numero di step, la tensione, la coppia di spunto, eccetera
MA al tempo stesso ogni bullone è un articolo, ogni motore è un articolo
Già vedi una classe che riassume capacità e caratteristiche comuni, (e si dirà quindi "classe base") e due classi che riprendono quelle caratteristiche comuni estendendole, pur mantenendo la relazione "è un" (is a) tra ogni loro istanza e la classe base
Si dirà che ereditano dalla classe base: in questo caso entrambe ereditano direttamente dalla base, quindi sono loro figlie e la base è direttamente il loro genitore (parent)... ma non sarebbe impossibile o strano avere "gerarchie" di classi più allungate e l' ereditarità non diretta...
come, sempre considerando le struttura della gerarchia tra classi, è possibile avere o progettare ramificazioni
in questo caso Bullone e Motore, saranno dotate di campi dati specifici quindi ciascuna di metodi per manipolarli, che l' altra non ha...
ma, pensa ad esempio a Mammifero classe base e Cane e Cavallo classi derivate: nelle ultime si potranno avere metodi con lo stesso nome, tra cui un EmettiVerso(), però questa avrà un comportamento specifico a seconda della classe effettiva
che poi è proprio l' altro scopo dell' ereditarietà tra classi: differenziare a livello funzionale o comportamentale oggetti dotati di metodi comuni
la genericizzazione è il termine che hanno usato quando mi hanno insegnato il senso dei template (che forse in effetti sarebbe stato quello più corretto): sostanzialmente, in molti casi è conveniente realizzare delle classi o delle funzioni il cui funzionamento non dipenda dall' effettivo tipo di dato con cui dovranno interagire od operare: risultando così il più generali possibile - caso tipico, le classi dedicate alla gestione delle strutture dati (se devi implementare degli elenchi di motori e bulloni e degli elenchi di cavalli, molto probabilmente una classe unica per la gestione di liste, indipendentemente se bulloni o cavalli , è preferibile a dover scrivere due volte lo stesso codice o quasi )
Questo fa capire anche una cosa: l' ereditarietà e i template sono interessanti mezzi per il riuso del codice ...
scusa il ritardo ;)
:eek:
java non ha i puntatori, questo (più che l'essere interpretato) non lo rende idoneo.mi riferivo al fatto che (logico, non nel task scheduler o nel sottosistema di memory managemement) molti degli elementi di cui è composto un kernel (e logico , non sto pensando a un microkernel, ma a uno modulare sulla scia di NT o Linux) siano tutti gli effetti inquadrati in una logica orientata agli oggetti, e che quindi avrebbero da guadagnare dall' utilizzo di un linguaggio OO supportive che con molta probabilità faciliterebbe la leggibilità e manutenibilità del codice
A questo punto il problema a detta di molti sarebbe l' overhead che l' uso di un linguaggio di più alto livello introdurrebbe, richiedendo un "runtime" completo (e nel caso di Java una virtual machine che al limite si integrerà con il VM manager e magari sarà a sua volta realizzata in linguaggio di più basso livello) e nel caso del C++, avendo certe funzionalità di questo un costo e una complessità inerenti, troppo elevati, che avrebbero reso la OOP a livello di kernel una via in toto non praticabile: ma esiste anche una cosa chiamata Embedded C++ ...
tomminno
15-12-2006, 20:49
Ma mettersi ad imparare la programmazione procedurale nel 2006 non ha il minimo senso.
Se da domani nessuno a questo mondo sapesse programmare in C, potresti scordarti per un bel pò i vari sistemi operativi, gli iPod e ammennicoli vari, i lettori DVD ed in generale tutte le elettroniche più complesse di un televisore.
Sai che avresti più chance di trovare lavoro spacciandoti come programmatore di firmware piuttosto che come programmatore Java?
Tanto vale iniziare da un linguaggio come Java o Python/Ruby per capire la programmazione ad oggetti fregandosene delle cose + a basso livello.
Ormai la base è saper programare BENE ad oggetti.
Questa è una visione molto limitata dell'informatica.
Ke poi tu sappia usare un linguaggio oppure un altro non ti cambia assolutamente nulla.
Almeno io non ho alcuna difficoltà a imparare linguaggi ke non conosco.
Ti ci vorrei vedere alle prese con un sistema che non ha un OS a bordo.
reptile9985
16-12-2006, 10:10
penso cmq di iniziare a questo punto da C, insomma mi sembrate tutti daccordo sul fatto che sia la base di tutto.
sono perplesso sul fatto che nel 2006 uno che vuole imparare a programmare cominci col C...se non devi scrivere un sistema operativo non usarlo, lascialo stare...comincia con c++ procedurale e poi passa agli oggetti ;)
ecco...forse è un po indigesto all'inizio ma è il migliore...magari guardalo quando hai fatto pratica con programmazione procedurale e sai perfettamente cos'è un puntatore e un riferimento:
http://www.odioworks.com/download/TICPP-2nd-ed-Vol-one.zip
sono perplesso sul fatto che nel 2006 uno che vuole imparare a programmare cominci col C...se non devi scrivere un sistema operativo non usarlo, lascialo stare...comincia con c++ procedurale e poi passa agli oggetti ;)
C++ procedurale? in pratica hai detto C (e anche in teoria)
reptile9985
16-12-2006, 10:43
C++ procedurale? in pratica hai detto C (e anche in teoria)
usando le librerie del c++ standard...non è la stessa cosa ;)
comincia con c++ procedurale e poi passa agli oggetti ;)
IMHO è la cosa più sbagliata che si possa fare...secondo me ci si porta dietro una marea di abitudini errate...
reptile9985
16-12-2006, 13:06
IMHO è la cosa più sbagliata che si possa fare...secondo me ci si porta dietro una marea di abitudini errate...
hai visto qualcuno che non ha mai usato un linguaggio di programmazione cominciare con c++ facendo classi non sapendo cosa sia un puntatore?
cosa ci sarebbe di sbagliato nell'imparare le funzioni, cosa sono i puntatori, riferimenti, input-output basilare, strutture base tipo liste e alberi, lavorare con queste e poi passare alla programmazione orientata agli oggetti?
sono curioso :)
trallallero
16-12-2006, 14:07
hai visto qualcuno che non ha mai usato un linguaggio di programmazione cominciare con c++ facendo classi non sapendo cosa sia un puntatore?
cosa ci sarebbe di sbagliato nell'imparare le funzioni, cosa sono i puntatori, riferimenti, input-output basilare, strutture base tipo liste e alberi, lavorare con queste e poi passare alla programmazione orientata agli oggetti?
sono curioso :)
allora si torna al discorso: inizia con C e poi passa al C++ ;)
secondo me avete ragione entrambi, il C++ procedurale è una cagata ma anche programmare in C++ senza conoscere i danni che ti permettono di fare i puntatori incontrollati non è da poco.
Secondo me o passi direttamente al OO alto livello o passi dal C, se qualcuno te lo spiega molto bene, e poi vai dove ti porta il cuore.
Ho conosciuto gente che schifava il C ed idolatrava il VB. Questione di attitudini: a me non poter controllare qualcosa mi fa sentire impotente quindi preferisco il C/C++ :)
Semplice: per conoscere le fondamenta della programmazione OO non servono i puntatori...anzi non serve nemmeno un linguaggio...
reptile9985
16-12-2006, 14:35
Semplice: per conoscere le fondamenta della programmazione OO non servono i puntatori...anzi non serve nemmeno un linguaggio...
questa è un'astrazione giusta e ovvia
sta di fatto che in c++ il polimorfismo è possibile solo grazie ai puntatori
@trallallero: se il c++ procedurale vuoi chiamarlo c allora siamo d'accordo. cmq io distinguo le cose, il c è stato scritto per fare sistemi operativi e penso che nei contesti in cui viene proposto qui sia da non utilizzare...tutto imho :)
questa è un'astrazione giusta e ovvia
sta di fatto che in c++ il polimorfismo è possibile solo grazie ai puntatori
Il fatto che sia possibile solo attraverso i puntatori è comunque una cosa che lo studente non deve sapere fin da subito...anzi... Gli basta conoscere la cosa a livello di astrazione... Dopo quando gli si spiegherà il linguaggio è chiaro che andranno spiegati anche i puntatori...
trallallero
16-12-2006, 14:43
questa è un'astrazione giusta e ovvia
sta di fatto che in c++ il polimorfismo è possibile solo grazie ai puntatori
ma il polimorfismo va prima capito come concetto ... poi in C++ lo applichi coi puntatori
@trallallero: se il c++ procedurale vuoi chiamarlo c allora siamo d'accordo. cmq io distinguo le cose, il c è stato scritto per fare sistemi operativi e penso che nei contesti in cui viene proposto qui sia da non utilizzare...tutto imho :)
pensa ad uno abituato al procedurale, fa una classe e mette tutto il programma dentro il costruttore. Il compilatore non gli dice niente e magari gli va anche male perchè il programma funziona e lui è tutto contento.
reptile9985
16-12-2006, 14:51
Il fatto che sia possibile solo attraverso i puntatori è comunque una cosa che lo studente non deve sapere fin da subito...anzi... Gli basta conoscere la cosa a livello di astrazione... Dopo quando gli si spiegherà il linguaggio è chiaro che andranno spiegati anche i puntatori...
ok chiaro...ma se il linguaggio (c++) non è esclusivamente orientato agli oggetti come java (che guardacaso non fa uso di puntatori), converrai con me che sia cosa buona e giusta far pratica con la parte procedurale (c++ perchè voglio usare le librerie standard e new/delete con strutture basi come liste e alberi) prima di passare alla parte ad oggetti, soprattutto se si è alle prime armi...o no?
poi se uno vuole fare java fa solo orientato agli oggetti ma è un'altro discorso
IMHO è la cosa più sbagliata che si possa fare...secondo me ci si porta dietro una marea di abitudini errate...
o almeno spiegami perchè no...ciao
giannola
16-12-2006, 15:17
Il fatto che sia possibile solo attraverso i puntatori è comunque una cosa che lo studente non deve sapere fin da subito...anzi... Gli basta conoscere la cosa a livello di astrazione... Dopo quando gli si spiegherà il linguaggio è chiaro che andranno spiegati anche i puntatori...
stabiliamo una cosa, visto che qui ognuno è mago della programmazione e l'unico risultato che si ottiene è confondere chi il linguaggio non lo conosce.
Se si vuole realmente imparare cosa significa "programmare" se si vuole acquisire la mentalità del programmatore è dunque, non necessario, ma fondamentale ed obbligatorio passare per il C puro.
Perchè è l'unico linguaggio così rigoroso che non ti consente di sbagliare un punto e virgola. :D
Spesso infatti il compilatore si porta dietro un errore ed è difficile anche scoprire dov'è esattamente.
Anzi addirittura si può dire affrontando la programmazione relativa ai puntatori (e dunque imparando i concetti di queue, stack, alberi binari, ecc.) è possibile anche realizzare programmi sintatticamente corretti che però quando vanno in esecuzione vanno in crash perchè si scrive o si legge in zone della memoria dove non si può fare e non si riceverà alcuna indicazione del tipo di problema.
Solo un lungo apprendistato con tale linguaggio metterà un programmatore nella condizione mentale di essere in grado di risolvere qualunque problema con qualunque linguaggio.
Chiedo il conforto in tal senso di colleghi universitari che si sono trovati di fronte a questo potente ma ostico linguaggio. ;)
In java c'è la referenziazione, ma è una cosa automatica, non esiste in nessun altro linguaggio il controllo dell'allocazione della memoria come in c.
reptile9985
16-12-2006, 15:28
stabiliamo una cosa, visto che qui ognuno è mago della programmazione e l'unico risultato che si ottiene è confondere chi il linguaggio non lo conosce.
Se si vuole realmente imparare cosa significa "programmare" se si vuole acquisire la mentalità del programmatore è dunque, non necessario, ma fondamentale ed obbligatorio passare per il C puro.
Perchè è l'unico linguaggio così rigoroso che non ti consente di sbagliare un punto e virgola. :D
Spesso infatti il compilatore si porta dietro un errore ed è difficile anche scoprire dov'è esattamente.
Anzi addirittura si può dire affrontando la programmazione relativa ai puntatori (e dunque imparando i concetti di queue, stack, alberi binari, ecc.) è possibile anche realizzare programmi sintatticamente corretti che però quando vanno in esecuzione vanno in crash perchè si scrive o si legge in zone della memoria dove non si può fare e non si riceverà alcuna indicazione del tipo di problema.
Solo un lungo apprendistato con tale linguaggio metterà un programmatore nella condizione mentale di essere in grado di risolvere qualunque problema con qualunque linguaggio.
Chiedo il conforto in tal senso di colleghi universitari che si sono trovati di fronte a questo potente ma ostico linguaggio. ;)
In java c'è la referenziazione, ma è una cosa automatica, non esiste in nessun altro linguaggio il controllo dell'allocazione della memoria come in c.
fondamentalmente d'accordo su tutto a parte per il C puro:
non mi stancherò mai di ripetere che il C è buono solo per scrivere sistemi operativi, infatti all'università non ti insegnano C ma C++ (standard) procedurale prima e poi la parte orientata agli oggetti
fondamentalmente d'accordo su tutto a parte per il C puro:
non mi stancherò mai di ripetere che il C è buono solo per scrivere sistemi operativi, infatti all'università non ti insegnano C ma C++ (standard) procedurale prima e poi la parte orientata agli oggetti
Non capisco come mai non mi vuoi far imparare a scrivere OS ?
giannola
16-12-2006, 15:45
fondamentalmente d'accordo su tutto a parte per il C puro:
non mi stancherò mai di ripetere che il C è buono solo per scrivere sistemi operativi, infatti all'università non ti insegnano C ma C++ (standard) procedurale prima e poi la parte orientata agli oggetti
si vede che tu sei stato un universitario fortunato.
Quando ho fatto gli esami io abbiamo utilizzato il c puro per fare liste di liste per leggere e scrivere su file di testo ordinando i dati e facendo delle statistiche.
Un inferno di linee di codice. :muro: :D
reptile9985
16-12-2006, 15:54
Non capisco come mai non mi vuoi far imparare a scrivere OS ?
se il tuo obiettivo è scrivere sistemi operativi impara C ma imparalo bene
se invece il tuo obiettivo è (faccio un esempio) lavorare con le stringhe lo faccio per il tuo bene, non voglio tu faccia questa fine quando in c++ esiste una ricca libreria standard STL (http://www.sgi.com/tech/stl/) :
http://www.hwupgrade.it/forum/showthread.php?t=1357731
:sofico:
e naturalmente il c++ non esclude il c ma il c esclude il c++ :)
Uei, è in corso la rissetta mensile e nessuno m'avverte?!! Ve possino! :D
se il tuo obiettivo è scrivere sistemi operativi impara C ma imparalo bene
se invece il tuo obiettivo è (faccio un esempio) lavorare con le stringhe lo faccio per il tuo bene, non voglio tu faccia questa fine quando in c++ esiste una ricca libreria standard STL (http://www.sgi.com/tech/stl/) :
http://www.hwupgrade.it/forum/showthread.php?t=1357731
:sofico:
e naturalmente il c++ non esclude il c ma il c esclude il c++ :)
Dal link che mi hai dato mi sembra però di capire che quel tizio aveva immischiato C e C++, senza saper fare bene ne l'uno ne l'altro, non riusciva a lavorare con le stringhe. Quindi non è meglio se avesse imparato prima a scrivere in C ?
Parlo ovviamente da ignorante...
reptile9985
16-12-2006, 16:22
Dal link che mi hai dato mi sembra però di capire che quel tizio aveva immischiato C e C++, senza saper fare bene ne l'uno ne l'altro, non riusciva a lavorare con le stringhe. Quindi non è meglio se avesse imparato prima a scrivere in C ?
Parlo ovviamente da ignorante...
quel tizio ha usato C...il problema non è tanto quello che ha scritto quanto che in C++ grazie al tipo string che è standardizzato (insieme ad una marea di altra roba e algoritmi) le cose che vuole fare le fai in un numero di righe di codice molto inferiore ;)
giannola
16-12-2006, 16:49
Uei, è in corso la rissetta mensile e nessuno m'avverte?!! Ve possino! :D
no, nessuna rissetta, solo il periodico raduno dei superprogrammatoridallalgoritmomentalechenemmenobillgates.... :D
Perchè è l'unico linguaggio così rigoroso che non ti consente di sbagliare un punto e virgola. :D
Spesso infatti il compilatore si porta dietro un errore ed è difficile anche scoprire dov'è esattamente.
Anzi addirittura si può dire affrontando la programmazione relativa ai puntatori (e dunque imparando i concetti di queue, stack, alberi binari, ecc.) è possibile anche realizzare programmi sintatticamente corretti che però quando vanno in esecuzione vanno in crash perchè si scrive o si legge in zone della memoria dove non si può fare e non si riceverà alcuna indicazione del tipo di problema.
solo io considero queste cose difetti e non pregi?
perche complicarsi la vita?(se non ce ne bisogno, ovvio. E la maggior parte delle volte non ce nè)
ok chiaro...ma se il linguaggio (c++) non è esclusivamente orientato agli oggetti come java (che guardacaso non fa uso di puntatori), converrai con me che sia cosa buona e giusta far pratica con la parte procedurale (c++ perchè voglio usare le librerie standard e new/delete con strutture basi come liste e alberi) prima di passare alla parte ad oggetti, soprattutto se si è alle prime armi...o no?
E' proprio questo l'errore... Passare prima dalla "parte" procedurale significa confondere solamente le idee... Il C++ imho deve essere approcciato ad oggetti per renderne l'effettiva potenza... Se si passa dall'approccio procedurale si lasceranno "scorie" nella conoscenza di chi lo studia...con il risultato che quando andrà a programmare nella vita reale scriverà programmi che non sono C, ma nemmeno C++. Un miscuglio eterogeneo di programmazione procedurale ed ad oggetti, il che ne fa anche un pessimo programmatore.
Il C++ per essere imparato bene deve essere approcciato come Java (chiaramente sottointendo un corso Java fatto bene)...
Non bisogna far pensare allo studente che C++ è un linguaggio procedurale che ti permette anche la programmazione OO, ma che C++ è un linguaggio OO che eventualmente ti permette anche la programmazione procedurale...cosa che ovviamente non ti è permessa iniziando con la parte procedurale...
se invece il tuo obiettivo è (faccio un esempio) lavorare con le stringhe lo faccio per il tuo bene, non voglio tu faccia questa fine quando in c++ esiste una ricca libreria standard
Ti sembra possibile insegnare la stl senza spiegare la programmazione OO, ma partendo dall'approccio procedurale ?
giannola
16-12-2006, 19:28
solo io considero queste cose difetti e non pregi?
perche complicarsi la vita?(se non ce ne bisogno, ovvio. E la maggior parte delle volte non ce nè)
perchè a voler semplificare tutto c'è il rischio di pretendere che sia il linguaggio a fare tutto, mascherando la propria pigrizia mentale.
D'altronde se un codice è fatto in maniera corretta, con piccole modifiche sarà riutilizzabile anche per altre necessità ;)
trallallero
16-12-2006, 21:19
perchè a voler semplificare tutto c'è il rischio di pretendere che sia il linguaggio a fare tutto, mascherando la propria pigrizia mentale.
D'altronde se un codice è fatto in maniera corretta, con piccole modifiche sarà riutilizzabile anche per altre necessità ;)
:nonsifa: basta parlare bene del C! poi studiano tutti quello e vai con la concorrenza! :muro:
W il Visual Cobol!
son d'accordo con cionci anche se poi dipende dalla persona, dall'età. Cambiare a 15 anni è molto più facile, non si hanno radici storiche ;)
giannola
17-12-2006, 05:59
:nonsifa: basta parlare bene del C! poi studiano tutti quello e vai con la concorrenza! :muro:
W il Visual Cobol!
son d'accordo con cionci anche se poi dipende dalla persona, dall'età. Cambiare a 15 anni è molto più facile, non si hanno radici storiche ;)
:rotfl:
tomminno
17-12-2006, 14:15
si vede che tu sei stato un universitario fortunato.
Quando ho fatto gli esami io abbiamo utilizzato il c puro per fare liste di liste per leggere e scrivere su file di testo ordinando i dati e facendo delle statistiche.
Un inferno di linee di codice. :muro: :D
Se devi imparare come funziona una lista non puoi semplicemente scrivere list<quello_che_ti_pare> lista; troppo semplice non ti pare?
E non capisco perchè mai non si debba studiare cos'è una lista. Chiaro poi che è troppo più comodo usare l'STL del C++ rispetto ad un'implementazione manuale in C.
tomminno
17-12-2006, 14:18
se invece il tuo obiettivo è (faccio un esempio) lavorare con le stringhe lo faccio per il tuo bene, non voglio tu faccia questa fine quando in c++ esiste una ricca libreria standard STL (http://www.sgi.com/tech/stl/) :
http://www.hwupgrade.it/forum/showthread.php?t=1357731
:sofico:
e naturalmente il c++ non esclude il c ma il c esclude il c++ :)
Poi un giorno ti troverai a compilare programmi con un compilatore C++ che non conosce gli stream del C++ e ti troverai ad usare a man bassa sprintf.
tomminno
17-12-2006, 14:21
E' proprio questo l'errore... Passare prima dalla "parte" procedurale significa confondere solamente le idee... Il C++ imho deve essere approcciato ad oggetti per renderne l'effettiva potenza... Se si passa dall'approccio procedurale si lasceranno "scorie" nella conoscenza di chi lo studia...con il risultato che quando andrà a programmare nella vita reale scriverà programmi che non sono C, ma nemmeno C++. Un miscuglio eterogeneo di programmazione procedurale ed ad oggetti, il che ne fa anche un pessimo programmatore.
Fino a che non ti capiterà di scrivere un programma che faccia ricorso alle funzionalità native dell'OS che guarda caso fornisce API C e quindi sarai obbligato a mischiare programmazione procedurale e OO.
reptile9985
17-12-2006, 16:33
Se devi imparare come funziona una lista non puoi semplicemente scrivere list<quello_che_ti_pare> lista; troppo semplice non ti pare?
E non capisco perchè mai non si debba studiare cos'è una lista. Chiaro poi che è troppo più comodo usare l'STL del C++ rispetto ad un'implementazione manuale in C.
io non ho mai usato C in vita mia, solo C++ e di liste (no list dell'stl) posso garantirti che ne ho usate (in procedurale come strutture dati) e uso tutt'ora (più che altro come classi collezione) moltissime...forse lui intendeva che l'allocazione di memoria in c è diversa della semplice new/delete del c++ e merita maggiore attenzione
Poi un giorno ti troverai a compilare programmi con un compilatore C++ che non conosce gli stream del C++ e ti troverai ad usare a man bassa sprintf.
non penso proprio...se devo compilare in c++ uso g++ (che aderisce rigorosamente allo standard), se devo compilare c uso gcc
giannola
17-12-2006, 17:01
Se devi imparare come funziona una lista non puoi semplicemente scrivere list<quello_che_ti_pare> lista; troppo semplice non ti pare?
E non capisco perchè mai non si debba studiare cos'è una lista. Chiaro poi che è troppo più comodo usare l'STL del C++ rispetto ad un'implementazione manuale in C.
ma io sono contento di essermi rotto il :ciapet: col c, perchè mi ha aperto la mente. :D
però ho l'impressione che tu parli di altre cose.
una lista è una struttura dati di puntatori, era quello a cui alludevi pure tu ?
trallallero
17-12-2006, 17:10
ma io sono contento di essermi rotto il :ciapet: col c, perchè mi ha aperto la mente. :D
però ho l'impressione che tu parli di altre cose.
una lista è una struttura dati di puntatori, era quello a cui alludevi pure tu ?
dipende ... prova ad andare nella sezione Storia politica e attualità e parla di liste. Vediamo cosa succede :asd:
Se devi imparare come funziona una lista non puoi semplicemente scrivere list<quello_che_ti_pare> lista; troppo semplice non ti pare?
ma anche no.
Se un giorno avrò necessita di sapere come è fatta, me la studio. Se la devo usare mi basta sapere come si comporta, non come è fatta dentro. Nel come si comporta può essere compreso anche le prestazioni nelle varie operazioni.
ps. so come funziona una lista :asd:
Però ad esempio gli iteratori. Come sono fatti? Non lo so(avevo letto tempo fa la differnza fra iteratori interni ed esterni, ma non ci avevo capito molto e gliel'ho data su...), ma li uso felicemente uguale.
tomminno
17-12-2006, 21:47
non penso proprio...se devo compilare in c++ uso g++ (che aderisce rigorosamente allo standard), se devo compilare c uso gcc
Eh già ma se per lavoro devi sviluppare un programma per WinCE? E se devi integrare degli obrobri di OCX di terze parti che non funzionano con VS? Ti tocca ad usare eVC4 che non supporta gli stream.
tomminno
17-12-2006, 21:50
ma io sono contento di essermi rotto il :ciapet: col c, perchè mi ha aperto la mente. :D
però ho l'impressione che tu parli di altre cose.
una lista è una struttura dati di puntatori, era quello a cui alludevi pure tu ?
Intendevo che con il C realizzi in modo pratico quello che teoricamente rappresenta una lista logica.
tomminno
17-12-2006, 22:01
ma anche no.
Se un giorno avrò necessita di sapere come è fatta, me la studio. Se la devo usare mi basta sapere come si comporta, non come è fatta dentro. Nel come si comporta può essere compreso anche le prestazioni nelle varie operazioni.
Bene e se non sai come è fatta (per dire) come fai a sapere che hai scelto l'entità più adatta? Magari ti serve uno stack, una coda, una tabella hash...
Fino a che non ti capiterà di scrivere un programma che faccia ricorso alle funzionalità native dell'OS che guarda caso fornisce API C e quindi sarai obbligato a mischiare programmazione procedurale e OO.
E invece no...non lo farò, perchè se ho bene in mente cosa significa programmare OO mi faccio una o più classi che incapsulano oculatamente le funzionalità delle API di cui necessito e mi servo di quelle in tutto il programma ;) Semplice, pulito e OO...
giannola
18-12-2006, 07:34
Bene e se non sai come è fatta (per dire) come fai a sapere che hai scelto l'entità più adatta? Magari ti serve uno stack, una coda, una tabella hash...
oppure un albero ordinato. :D
giannola
18-12-2006, 07:34
dipende ... prova ad andare nella sezione Storia politica e attualità e parla di liste. Vediamo cosa succede :asd:
da evitare.
Soprattutto quelle di coscrizione :D
tomminno
18-12-2006, 07:37
E invece no...non lo farò, perchè se ho bene in mente cosa significa programmare OO mi faccio una o più classi che incapsulano oculatamente le funzionalità delle API di cui necessito e mi servo di quelle in tutto il programma ;) Semplice, pulito e OO...
Io non sono ancora riuscito a far digerire i puntatori a metodi alle callback richieste dalle API di Windows (e questo grazie al fatto che i puntatori a metodo hanno dimensione variabile da 4 a 16byte), quindi faccio ricorso a delle normali funzioni che mi richiamano metodi di una classe. In questo modo ho già mischiato programmazione procedurale e OO, oltretutto con la bruttura di dover creare un metodo pubblico, per un qualcosa che dovrebbe in generale essere un metodo privato.
Se sai come fare a scambiare un puntatore a funzione con uno a metodo, magari dalla prossima volta rimedio e faccio tutto secondo il paradigma OO.
trallallero
18-12-2006, 07:39
Eh già ma se per lavoro devi sviluppare un programma per WinCE? E se devi integrare degli obrobri di OCX di terze parti che non funzionano con VS? Ti tocca ad usare eVC4 che non supporta gli stream.
scusa ma stai esagerando, secondo me. Coi se e coi ma a 'sto punto studiamo tutti solo l'assembler e non se ne parla piú ;)
eVC4 (non so cosa sia) mi sembra un compilatore per embedded C++, o sbaglio ? lo deduco dal fatto che non supporta gli stream. Se é cosí ha il suo posto preciso nel mercato e di certo non viene usato per compilare videogiochi o oggetti quindi sará difficile tu abbia a che fare con OCX e doverli compilare con 'sto eVC4.
trallallero
18-12-2006, 07:44
(e questo grazie al fatto che i puntatori a metodo hanno dimensione variabile da 4 a 16byte)
cos'é quest'ultima outtanata di MS ??? :mbe: puntatore a dimensione variabile :wtf: e perché ? da cosa dipende ?
quindi faccio ricorso a delle normali funzioni
piú che ricorso fai causa alla MS :asd:
In questo modo ho già mischiato programmazione procedurale e OO, oltretutto con la bruttura di dover creare un metodo pubblico, per un qualcosa che dovrebbe in generale essere un metodo privato.
E' chiaro che ci sono problemi di questo tipo, ma "nascondi" il tutto nel modulo che la usa e festa finita... Dopo tutto è considerabile come una "funzione di servizio"...quando entrerà in esecuzione andrà a richiamare solo metodi appartenenti al modulo stesso...
E' chiaro che ci sono problemi di questo tipo, ma "nascondi" il tutto nel modulo che la usa e festa finita... Dopo tutto è considerabile come una "funzione di servizio"...quando entrerà in esecuzione andrà a richiamare solo metodi appartenenti al modulo stesso...
Forse non è necessario tutto questo... Mi è venuta in mente una soluzione OO molto bella anche per questo...ma devo verificare se funziona... Quindi oggi pomeriggio...
cos'é quest'ultima outtanata di MS ??? :mbe: puntatore a dimensione variabile :wtf: e perché ? da cosa dipende ? no, è una storia lunga e noiosa, e credo che lui sappia solo quella :asd:
non è una puttanata Microsoft, è una necessità: i puntatori a funzioni sono tranquillamente da 4 bytes, ma quelli a metodi virtuali sono un bel casino. fattela spiegare bene da lui che lo fai felice... :D :D :D
tomminno
18-12-2006, 08:50
cos'é quest'ultima outtanata di MS ??? :mbe: puntatore a dimensione variabile :wtf: e perché ? da cosa dipende ?
Dipende dal tipo di metodo a cui punti, ovvero se punti ad un metodo virtuale (variabile da 4 a 12 bytes), oppure un semplice metodo di una classe non derivata (4 bytes), oppure peggio ancora se punti ad un metodo forward declared (caso pessimo 16 bytes). Per favorire il lavoro ai compilatori alcuni hanno aggiunto parole chiave.
Tutto questo perchè il compilatore deve tenere traccia di cosa rappresenta effettivamente il "this" che si cela dietro i puntatori a metodo.
piú che ricorso fai causa alla MS :asd:
Sarebbe bello ma questa volta è colpa dello standard C++. La dimensione dei puntatori a metodo è comunque differente da compilatore a compilatore.
tomminno
18-12-2006, 09:01
scusa ma stai esagerando, secondo me. Coi se e coi ma a 'sto punto studiamo tutti solo l'assembler e non se ne parla piú ;)
Non tutto il software viene scritto per PC normali.
eVC4 (non so cosa sia) mi sembra un compilatore per embedded C++, o sbaglio ? lo deduco dal fatto che non supporta gli stream.
è il vecchio e antiquato compilatore embedded della M$. Supporta solo parte del C++ e tra le altre cose mal digerisce i puntatori a metodo, a volte dà errore su codice normalissimo e perfettamente compilante con compilatori più recenti e più attinenti allo standard.
Se é cosí ha il suo posto preciso nel mercato e di certo non viene usato per compilare videogiochi o oggetti quindi sará difficile tu abbia a che fare con OCX e doverli compilare con 'sto eVC4.
Pensi davvero che tutto il mondo della programmazione giri intorno ai videogiochi?
Purtroppo io devo usare OCX di terze parti per realizzare un software su WinCE e questi OCX mi obbligano ad usare quel vecchio compilatore, con tutte le relative imprecazioni.
trallallero
18-12-2006, 09:08
Dipende dal tipo di metodo a cui punti, ovvero se punti ad un metodo virtuale (variabile da 4 a 12 bytes), oppure un semplice metodo di una classe non derivata (4 bytes), oppure peggio ancora se punti ad un metodo forward declared (caso pessimo 16 bytes). Per favorire il lavoro ai compilatori alcuni hanno aggiunto parole chiave.
Tutto questo perchè il compilatore deve tenere traccia di cosa rappresenta effettivamente il "this" che si cela dietro i puntatori a metodo.
uhm ... ammetto di essere ignorante in materia perché son rimasto ai puntatori alle funzioni ma non capisco come si possa lavorare con un linguaggio a basso livello con "dimensioni variabili".
Scusa ma a cosa ti servono questi puntatori a metodi ? :wtf:
trallallero
18-12-2006, 09:15
è il vecchio e antiquato compilatore embedded della M$. Supporta solo parte del C++ e tra le altre cose mal digerisce i puntatori a metodo, a volte dà errore su codice normalissimo e perfettamente compilante con compilatori più recenti e più attinenti allo standard.
sará allora il compilatore ad essere obsoleto no ;)
Pensi davvero che tutto il mondo della programmazione giri intorno ai videogiochi?
per dirne una dai. Tu stavi facendo dei discorsi sicuramente giusti sotto un certo punto di vista ma, per esempio, un programmatore di gestionali potrebbe pensarla in modo diverso ed avere ragione perché mai dovrá avere a che fare con compilatori matusa o altre diavolerie. Quindi potrebbe dire: sticazzi del C e del procedurale io programmo ad oggetti e basta.
Purtroppo io devo usare OCX di terze parti per realizzare un software su WinCE e questi OCX mi obbligano ad usare quel vecchio compilatore, con tutte le relative imprecazioni.
ecco, io invece non lo dovró mai fare. Anche se ... mai dire mai :eek:
trallallero
18-12-2006, 09:21
no, è una storia lunga e noiosa, e credo che lui sappia solo quella :asd:
non è una puttanata Microsoft, è una necessità: i puntatori a funzioni sono tranquillamente da 4 bytes, ma quelli a metodi virtuali sono un bel casino. fattela spiegare bene da lui che lo fai felice... :D :D :D
l'ha giá fatto :D
Comunque in effetti alla fine ... a me ... ma che caxxo me ne frega se é di 4 o di 16 bytes?
Io lo uso e poi ci pensa il compilatore a gestirlo. Io pago :O
tomminno
18-12-2006, 09:34
uhm ... ammetto di essere ignorante in materia perché son rimasto ai puntatori alle funzioni ma non capisco come si possa lavorare con un linguaggio a basso livello con "dimensioni variabili".
Scusa ma a cosa ti servono questi puntatori a metodi ? :wtf:
Tanto per cominciare per realizzare le comunicazioni tra classi: i cosiddetti eventi o delegati, se una classe deve comunicare appunto un evento al chiamante, per rispettare la programmazione ad oggetti non devi scrivere
chiamante->Metodo();
Ma qualcosa del tipo:
if (event)
event(parametri_da_passare);
dove event è un puntatore a metodo che il chiamante ha opportunamente impostato (non necessariamente infatti il chiamante è interessato a ricevere notifica di una funzionalità messa a disposizione da un oggetto).
Oltretutto event potrebbe anche essere un vettore di puntatori a metodo, per poter sollevare eventi verso più classi e qui nascono i casini perchè i puntatori possono avere dimensione differente.
Almeno io li uso abbondantemente per questo.
Bene e se non sai come è fatta (per dire) come fai a sapere che hai scelto l'entità più adatta? Magari ti serve uno stack, una coda, una tabella hash...
ho detto che non conosco come sono fatte dentro, non cosa offrono ;)
e cmq vado in java.util.collection, e guardo cosa mi offre.
trallallero
18-12-2006, 10:37
Tanto per cominciare per realizzare le comunicazioni tra classi: i cosiddetti eventi o delegati, se una classe deve comunicare appunto un evento al chiamante, per rispettare la programmazione ad oggetti non devi scrivere
chiamante->Metodo();
Ma qualcosa del tipo:
if (event)
event(parametri_da_passare);
dove event è un puntatore a metodo che il chiamante ha opportunamente impostato (non necessariamente infatti il chiamante è interessato a ricevere notifica di una funzionalità messa a disposizione da un oggetto).
Oltretutto event potrebbe anche essere un vettore di puntatori a metodo, per poter sollevare eventi verso più classi e qui nascono i casini perchè i puntatori possono avere dimensione differente.
Almeno io li uso abbondantemente per questo.
beh si, che pirla, gli eventi :doh:
peró sono scusato, é un bel pó che non tocco la programmazione ad eventi e devo dire che un po mi manca :rolleyes:
quá solo shell, sql, pro*c e burocrazia ... burocrazia ... burocrazia ... burocrazia ... :muro:
Io non sono ancora riuscito a far digerire i puntatori a metodi alle callback richieste dalle API di Windows e mai ci riuscirai furbone :asd: semplicemente perché non ci sono API Win32 che passano this nella chiamata; non si tratta di sottigliezze sintattiche.
l'unica è fare come MFC che si tiene una mappa che associa gli handles ai puntatori dei suoi oggetti; e siccome MFC, furbo, sa che gli handles statisticamente saltano numericamente di 4 in 4, utilizza una mappa con un hash semplicissimo (shift a destra di due posti e modulo, praticamente zero collisioni).
EDIT: sto post l'ho modificato 3000 volte :D
trallallero, te che sei online, se mi stai quotando riquotami, questa è definitiva :D
trallallero
18-12-2006, 13:43
e mai ci riuscirai furbone :asd: semplicemente perché non ci sono API Win32 che passano this nella chiamata; non si tratta di sottigliezze sintattiche.
l'unica è fare come MFC che si tiene una mappa che associa gli handles ai puntatori dei suoi oggetti; e siccome MFC, furbo, sa che gli handles statisticamente saltano numericamente di 4 in 4, utilizza una mappa con un hash semplicissimo (shift a destra di due posti e modulo, praticamente zero collisioni).
EDIT: sto post l'ho modificato 3000 volte :D
trallallero, te che sei online, se mi stai quotando riquotami, questa è definitiva :D
anche se non sono d'accordo su una virgola quoto, ma solo per fare un favore :O
trallallero
18-12-2006, 13:53
certo che é buffo: dove lavoro sono il mago del C perché non ci sono altri all'altezza ma quí (a parte i novelli) sembro uno scolaretto :D
Al lavoro parlo di puntatori a funzione e rimangono cosí :eek:
qua parlate di puntatori a metodi, puntatori a sistemi operativi :eekk:
tomminno
18-12-2006, 15:21
e mai ci riuscirai furbone :asd: semplicemente perché non ci sono API Win32 che passano this nella chiamata; non si tratta di sottigliezze sintattiche.
In effetti era ironica :D
Era Per dire che non si può, in certi casi, non mischiare procedurale e OO.
Come dicevo questa mattina...mi era venuto in mente un metodo per non scendere a compromessi con i callback della API...
In pratica ho realizzato due classi:
- WindowsList che permette di avere la lista delle finestre aperte sotto forma testuale
- WindowsEnumerator che permette di enumerare le finestre ed inserirle nella WindowsList
L'interfaccia pubblica di WindowsList non risente minimamente della callback. Tra l'altro WindowsEnumerator è molto vicino a quello che in Java è una classe annidata privata...infatti non è visibile all'utente finale (e nemmeno a chi include WindowsEnumerator.h).
Risultato: non mi sembra che ci sia alcun miscuglio di programmazione procedurale e programmazione ad oggetti. WindowsEnumerator astrae completamente la callback e tutte le Windows API chiamate.
Non solo, c'è la possibilità di estrarre un'interfaccia dalla WindowsList se ci servissero altre classi che ricevono il nome delle finestre. E non è finita qui perchè in teoria se avessi altre callback con differente chiamata scatenante, ma lo stesso tipo di callback potrei estrarre un'interfaccia Callback da WindowsEnumerator.
Il risultato sarebbe un'interfaccia comune per le callback in cui basterebbe implementare l'API scatenante ed un'interfaccia comune per gli utilizzatori delle callback in cui basterebbe implementare la gestione dei dati ricevuti...
^TiGeRShArK^
18-12-2006, 19:49
perché ? in fondo c'é solo un ++ in piú :D
fai bene va. Secondo me il concetto della programmazione ad oggetti é una stronzata da capire perché imita proprio ... gli oggetti in natura.
Ma il C++ é una bestia e senza il C non ci fai niente perché sei obbligato a conoscere il basso livello.
E poi l'elenco che ha postato jappilas parla chiaro: non é solo l'aggiunta delle classi al C ma qualcosina in piú (io stesso non so neanche se mi ricordo ... :rolleyes: )
O passi direttamente al java, ma rischi di rimanere legato a quello senza mai esplorare il mondo basso livello, o inizi dal C e ti fai tutta la gavetta ;)
Io proporrei di iniziare con l'assembly SPARC x esplorare il mondo a basso livello :O
:asd:
simpatico notare soprattutto km x fare quello ke il motorola 68000 faceva in un'istruzione con l'assembly SPARC molto spesso ne servivano diverse in + :p
Ovviamente lo SPARC però girava a frequenze *lievemente* + elevate del 68000 :asd:
^TiGeRShArK^
18-12-2006, 20:04
Ecco che torniamo al c, se non si comprende bene come sviluppare delle funzioni, non si riuscirà nemmeno a creare degli oggetti.
Ora poichè il c è un linguaggio basato sulle funzioni è importante partire da quello proprio per approfondire il significato di visibilità delle variabili, di ricorsività ma soprattutto della creazione delle strutture dati che rappresentano concettualmente i progenitori delle classi, inoltre ci si concentra molto di più nella programmazione sull'uso delle liste ovvero delle strutture dati basate sui puntatori (quindi una gestione diretta della ram).
Quest'ultimo è anche il motivo per cui si afferma che il "c è il più basso tra i linguaggi di alto livello" ed è anche il motivo per cui nè java sarà mai buono per programmare un kernel.
Quando ti sarai fatto le ossa sul c allora potrai con facilità passare al c++ che oltre al concetto di classe integrerà il concetto di ereditarietà.
nope :p
ti assicuro ke dopo anni passati a programmare in maniera procedurale passare alla programmazione ad oggetti è stato un bagno di sangue :asd:
è proprio la mentalità ke acquisisci ke è diversa...
e non vedo xkè iniziare acquisendo una mentalità ke ormai non ti serve + ;)
(Potevo anke capire se questa domanda fosse stata posta tra la metà degli anni 90 e il 2000...lì ancora c'erano fior di dibattiti sul fatto se convenisse passare direttamente alla programmazione ad oggetti o usare ancora quella procedurale.. ma imho al giorno d'oggi cose del genere non dovrebbero nemmeno essere prese in considerazione ;))
^TiGeRShArK^
18-12-2006, 20:16
Se da domani nessuno a questo mondo sapesse programmare in C, potresti scordarti per un bel pò i vari sistemi operativi, gli iPod e ammennicoli vari, i lettori DVD ed in generale tutte le elettroniche più complesse di un televisore.
bhè....
Io in realtà sogno un mondo senza C... :D
ma mi rendo conto ke allo stato attuale è praticamente impossibile :p
Ci sono ancora degli ambiti ke al giorno d'oggi necessitano del C, e se non cambia il modo di vedere le cose ankora lo necessiteranno x un bel pò.
Ma questo non vuol dire ke il C sia in assoluto lo strumento milgiore x quegli ambiti.
E' un pò come il periodo in cui era necessario scrivere intere parti di codice in assembly x ottimizzare fino all'osso.
Certo...c'era un codice + efficiente...
ma di quanto? e a ke costo?
Ottimizzare comporta sempre un costo molto elevato ke x progetti molto grandi è semplicemente impensabile..
Un esempio su tutti provate ad immaginare un SO interamente scritto in assembly (e non sto parlando solo del kernel). Bhè... da spararsi direi..soprattutto avendo un *lievissimo* rifiuto x l'assembly X86..decisamente orribile se confrontato a quello 680X0 o SPARC.....
Sai che avresti più chance di trovare lavoro spacciandoti come programmatore di firmware piuttosto che come programmatore Java?
bhè..potrebbe anke essere...
Ma onestamente dopo aver provato sulla mia pelle cosa voglia dire programmare a basso livello o in maniera elegante ad oggetti magari applicando tecnike di extreme programming quali il test driven development.. bhè... ti assicuro ke IMHO nn c'è assolutamente paragone :D
Questa è una visione molto limitata dell'informatica.
non penso..
anzi direi tutto l'opposto dato ke in molte aziende stanno scoprendo ke spesso è + semplice utilizzare linguaggi di scripting x fare quello ke gli serve anzikè sbattere la testa con linguaggi di programmazione + di basso livello..
E nel caso servano prestazioni maggiori nessuno vieta di affrontare i critical point scrivendoli anke con un altro linguaggio ;)
"The right tool for the right job"..
Penso sia una frase sempre attuale ;)
Ti ci vorrei vedere alle prese con un sistema che non ha un OS a bordo.
bhè..onestamente senza SO nn c'ho mai sbattuto la testa..
La cosa + a basso livello ke ho fatto è stato ai tempi un emulatore scritto in assembly SPARC x istruzioni assembly del 68000 ;)
^TiGeRShArK^
18-12-2006, 20:33
Se si vuole realmente imparare cosa significa "programmare" se si vuole acquisire la mentalità del programmatore è dunque, non necessario, ma fondamentale ed obbligatorio passare per il C puro.
Perchè è l'unico linguaggio così rigoroso che non ti consente di sbagliare un punto e virgola. :D
Spesso infatti il compilatore si porta dietro un errore ed è difficile anche scoprire dov'è esattamente.
Anzi addirittura si può dire affrontando la programmazione relativa ai puntatori (e dunque imparando i concetti di queue, stack, alberi binari, ecc.) è possibile anche realizzare programmi sintatticamente corretti che però quando vanno in esecuzione vanno in crash perchè si scrive o si legge in zone della memoria dove non si può fare e non si riceverà alcuna indicazione del tipo di problema.
Solo un lungo apprendistato con tale linguaggio metterà un programmatore nella condizione mentale di essere in grado di risolvere qualunque problema con qualunque linguaggio.
Chiedo il conforto in tal senso di colleghi universitari che si sono trovati di fronte a questo potente ma ostico linguaggio. ;)
In java c'è la referenziazione, ma è una cosa automatica, non esiste in nessun altro linguaggio il controllo dell'allocazione della memoria come in c.
bhè..
se x te imparare a programmare vulo dire essere masokisti..
allora xkè nn iniziare direttametne dall'assembly x86? :asd:
potrei fare le tue stesse obiezioni dicendoti ke è l'unico linguaggio ke ti permette di affrontare con piena coscienza le varie problematiche del caching dell'ottimizzazione dei registri, il pre-fetching, l'ottimizzazione manuale delle letture/scritture dalla memoria, la ricerca delle maggiori prestazioni facendo un loop unrolling manuale (ricordo un bellissimo esempio postato da repne scasb ai tempi ke aveva creato un programma assembly ke scriveva un altro programma con tutti i loop unrolled :D).
Bhè...forse obietterai ke è un pò da masokisti visto ke a tutto questo ci pensa il compilatore oggi km oggi ;)
Allo stesso modo xkè sbatterti con la gestione della memoria e i vari memory leak ke SICURAMENTE avrai appena inizierai a fare un programmino un'attimino complesso quando in Java/Python/Ruby/C# tutta la gestione della memoria è molto + semplificata?
Basta capire le basi del funzionamento del Garbage Collector, sapere ke nel caso di strutture dati utilizzate per mantenere una cache in memoria ci si potrebbe imbattere in problemini nella garbage collection stessa e guardarsi quei 2 o 3 casi ke hanno questi problemini CAPENDO la soluzione ben documentata su internet ;)
IMHO molto meglio concentrarsi sul PROBLEMA REALE ke andare giù calando santi su un kazz di memory leak ke nn si sa xkè è lì anke se tutto sembra a posto :D
Ah vabbè..
Pensando ke c'è ancora ki preferisce scriversi il WSDL a mano anzikè utilizzare l'annotation con java 6 @webservice e similari non mi stupisco + di nulla :D
^TiGeRShArK^
18-12-2006, 20:35
solo io considero queste cose difetti e non pregi?
perche complicarsi la vita?(se non ce ne bisogno, ovvio. E la maggior parte delle volte non ce nè)
perfetto ;)
sei riuscito ad esprimere in 2 righe quello ke tento di spiegare in pagine e pagine :D
ah..km mi piace il dono della sintesi di quest'uomo! :D
^TiGeRShArK^
18-12-2006, 20:48
E invece no...non lo farò, perchè se ho bene in mente cosa significa programmare OO mi faccio una o più classi che incapsulano oculatamente le funzionalità delle API di cui necessito e mi servo di quelle in tutto il programma ;) Semplice, pulito e OO...
ed è esattamente quello ke abbiamo fatto in Diamonds wrappando le OpenGL se proproi vogliamo...
Abbiamo avuto accesso a funzioni a basso livello dei driver della skeda video wrappando il tutto in oggetti ;)
Certo ke se l'avessimo finito sarebbe stato anke meglio :muro:
cmq.... io appena mi prendo l'ADSL qui penso di rimettermi al lavoro :p (progetti extra-lavoro permettendo :muro: )
^TiGeRShArK^
18-12-2006, 20:55
Eh già ma se per lavoro devi sviluppare un programma per WinCE? E se devi integrare degli obrobri di OCX di terze parti che non funzionano con VS? Ti tocca ad usare eVC4 che non supporta gli stream.
bhè...
e ke vuol dire..
anke certe parti delle MIDP fanno veramente kakare se conforntate a java 5 o ancora meglio 6 :asd:
mi pare il minimo ke sui dispositivi portatili hai delle limitazioni ;)
Cmq qdo possibile direi ke il Java utilizzato sui telefonini/portatili, se utilizzato correttamente, nn ha assolutamente nulla da invidiare ai programmi nativi.
Classico esempio il browser Opera Mini ke è estremamente + efficiente e leggero del browser nativo del Nokia 6630 scritto x symbian ;)
^TiGeRShArK^
18-12-2006, 21:04
Come dicevo questa mattina...mi era venuto in mente un metodo per non scendere a compromessi con i callback della API...
In pratica ho realizzato due classi:
- WindowsList che permette di avere la lista delle finestre aperte sotto forma testuale
- WindowsEnumerator che permette di enumerare le finestre ed inserirle nella WindowsList
L'interfaccia pubblica di WindowsList non risente minimamente della callback. Tra l'altro WindowsEnumerator è molto vicino a quello che in Java è una classe annidata privata...infatti non è visibile all'utente finale (e nemmeno a chi include WindowsEnumerator.h).
Risultato: non mi sembra che ci sia alcun miscuglio di programmazione procedurale e programmazione ad oggetti. WindowsEnumerator astrae completamente la callback e tutte le Windows API chiamate.
Non solo, c'è la possibilità di estrarre un'interfaccia dalla WindowsList se ci servissero altre classi che ricevono il nome delle finestre. E non è finita qui perchè in teoria se avessi altre callback con differente chiamata scatenante, ma lo stesso tipo di callback potrei estrarre un'interfaccia Callback da WindowsEnumerator.
Il risultato sarebbe un'interfaccia comune per le callback in cui basterebbe implementare l'API scatenante ed un'interfaccia comune per gli utilizzatori delle callback in cui basterebbe implementare la gestione dei dati ricevuti...
ehm..
ammetto di nn averci capito molto viste le 2 birre da 66 e i vari anni senza toccare C/C++.....
(mi ha sorpreso soprattutto: for(vector<string>::iterator it = names.begin(); it != names.end(); it++) :asd: )
ma direi ke ... "smells good!" :sofico:
reptile9985
18-12-2006, 21:19
ehm..
ammetto di nn averci capito molto viste le 2 birre da 66 e i vari anni senza toccare C/C++.....
(mi ha sorpreso soprattutto: for(vector<string>::iterator it = names.begin(); it != names.end(); it++) :asd: )
ma direi ke ... "smells good!" :sofico:
in effetti basta un semplice
for(int i=0;i<names.size();++i)........names[i] :sofico:
Diciamo che è la parte meno interessante del codice...
^TiGeRShArK^
18-12-2006, 22:06
Diciamo che è la parte meno interessante del codice...
lo so :D
ma x me era una novità ke si potesse usare quella notazione anke in c++ :p
il mio smells good infatti era riferito a tutto l'insieme ovviamente ;)
jappilas
18-12-2006, 23:23
Diciamo che è la parte meno interessante del codice...scusa... sarà l' ora ma quivoid WindowsEnumerator::start()
{
EnumWindows(WindowsEnumerator::insertOne, (LPARAM)windowsList);
}mi sfugge EnumWindows come e dove sia definita :stordita:
bello come design pattern comunque ... mi ricorda un po' quello che con un amico facemmo per incapsulare in un progetto C++ le api C di libavcodec (dll di FFMPEG) ... :)
In windows.h... E' appunto la API di Windows necessaria per enumerare gli handle a finestra... API che appunto necessita un callback (insertOne)...
Ah ovviamente WindowsEnumerator si poteva fare anche con una classe con tutti metodi statici e senza costruttore, ma a me non piacciono :)
giannola
19-12-2006, 06:46
nope :p
ti assicuro ke dopo anni passati a programmare in maniera procedurale passare alla programmazione ad oggetti è stato un bagno di sangue :asd:
è proprio la mentalità ke acquisisci ke è diversa...
e non vedo xkè iniziare acquisendo una mentalità ke ormai non ti serve + ;)
(Potevo anke capire se questa domanda fosse stata posta tra la metà degli anni 90 e il 2000...lì ancora c'erano fior di dibattiti sul fatto se convenisse passare direttamente alla programmazione ad oggetti o usare ancora quella procedurale.. ma imho al giorno d'oggi cose del genere non dovrebbero nemmeno essere prese in considerazione ;))
assolutamente falso.
Tu lo sai cosa sono i metodi vero ?
Tu lo sai a cosa assomiglia una classe nel linguaggio C ?
giannola
19-12-2006, 06:49
bhè..
se x te imparare a programmare vulo dire essere masokisti..
allora xkè nn iniziare direttametne dall'assembly x86? :asd:
potrei fare le tue stesse obiezioni dicendoti ke è l'unico linguaggio ke ti permette di affrontare con piena coscienza le varie problematiche del caching dell'ottimizzazione dei registri, il pre-fetching, l'ottimizzazione manuale delle letture/scritture dalla memoria, la ricerca delle maggiori prestazioni facendo un loop unrolling manuale (ricordo un bellissimo esempio postato da repne scasb ai tempi ke aveva creato un programma assembly ke scriveva un altro programma con tutti i loop unrolled :D).
Bhè...forse obietterai ke è un pò da masokisti visto ke a tutto questo ci pensa il compilatore oggi km oggi ;)
Allo stesso modo xkè sbatterti con la gestione della memoria e i vari memory leak ke SICURAMENTE avrai appena inizierai a fare un programmino un'attimino complesso quando in Java/Python/Ruby/C# tutta la gestione della memoria è molto + semplificata?
Basta capire le basi del funzionamento del Garbage Collector, sapere ke nel caso di strutture dati utilizzate per mantenere una cache in memoria ci si potrebbe imbattere in problemini nella garbage collection stessa e guardarsi quei 2 o 3 casi ke hanno questi problemini CAPENDO la soluzione ben documentata su internet ;)
IMHO molto meglio concentrarsi sul PROBLEMA REALE ke andare giù calando santi su un kazz di memory leak ke nn si sa xkè è lì anke se tutto sembra a posto :D
Ah vabbè..
Pensando ke c'è ancora ki preferisce scriversi il WSDL a mano anzikè utilizzare l'annotation con java 6 @webservice e similari non mi stupisco + di nulla :D
non c'entra nulla essere masochisti.
Si tratta del fatto che il C è un linguaggio assolutamente matematico, in pratica per quello che si va a programmare esiste un unico modo corretto nel quale posizionare ogni riga di codice.
Basta mettere una cosa fuori posto che il programma inizia a far cazzate.
E' questo quello che intendo dire, non che mi serve controllare la macchina molto da vicino.
^TiGeRShArK^
19-12-2006, 07:16
assolutamente falso.
Tu lo sai cosa sono i metodi vero ?
Tu lo sai a cosa assomiglia una classe nel linguaggio C ?
:rotfl: no...Tranquillo..Nn ho la minima idea nè delle funzioni membro nè delle struct :asd: ma scusa..Mi pare d aver detto ke sono vari anni ke nn tocco + il c..Nn m pare di aver mai detto di nn conoscerlo :asd:
trallallero
19-12-2006, 07:26
Io proporrei di iniziare con l'assembly SPARC x esplorare il mondo a basso livello :O
:asd:
simpatico notare soprattutto km x fare quello ke il motorola 68000 faceva in un'istruzione con l'assembly SPARC molto spesso ne servivano diverse in + :p
Ovviamente lo SPARC però girava a frequenze *lievemente* + elevate del 68000 :asd:
non mi parlare di SPARC ... qui abbiamo le sparc :muro: della Sun :muro: di 10 anni fa :muro:
^TiGeRShArK^
19-12-2006, 07:57
non c'entra nulla essere masochisti.
Si tratta del fatto che il C è un linguaggio assolutamente matematico, in pratica per quello che si va a programmare esiste un unico modo corretto nel quale posizionare ogni riga di codice.
Basta mettere una cosa fuori posto che il programma inizia a far cazzate.
E' questo quello che intendo dire, non che mi serve controllare la macchina molto da vicino.
:mbe:
e questo non è masokismo? :D
Io preferisco dovermi preoccupare + del problema ke devo risolvere ke del fatto se tra migliaia di puntatori ne ho sbagliati un paio e mi vado a sparare x capire dove kakkio sta l'errore...bhè..
tanto vale fare il fachiro piuttosto ke il programmatore :asd:
E nono parliamo dei classici bug casuali dei programmi multi-threaded ke là è ancora peggio :asd:
Ovviamente la programmazione OO non è la panacea...
Ma ad oggi è il paradigma di programmazione mediamente "migliore".
X la programmazione multi-threaded imho non è molto adatta...
e neanke x modellizzare quello ke accade nel nostro cervello... ma vabbè...
questa è un'altra storia :asd:
non c'entra nulla essere masochisti.
Si tratta del fatto che il C è un linguaggio assolutamente matematico, in pratica per quello che si va a programmare esiste un unico modo corretto nel quale posizionare ogni riga di codice.
Basta mettere una cosa fuori posto che il programma inizia a far cazzate.
E' questo quello che intendo dire, non che mi serve controllare la macchina molto da vicino.
W la manutenibilità del codice :stordita:
ps. l'unico modo corretto nel quale posizionare ogni riga di codice non esiste. Vedasi per esempio i mille modi per fare un helloWord (dall'obfuscated powa 1337 mode, a quello in cui vengono create una classe per ogni lettera della stringa in output :asd: )
trallallero
19-12-2006, 08:23
:mbe:
e questo non è masokismo? :D
Io preferisco dovermi preoccupare + del problema ke devo risolvere ke del fatto se tra migliaia di puntatori ne ho sbagliati un paio e mi vado a sparare x capire dove kakkio sta l'errore...bhè..
tanto vale fare il fachiro piuttosto ke il programmatore :asd:
E nono parliamo dei classici bug casuali dei programmi multi-threaded ke là è ancora peggio :asd:
Ovviamente la programmazione OO non è la panacea...
Ma ad oggi è il paradigma di programmazione mediamente "migliore".
X la programmazione multi-threaded imho non è molto adatta...
e neanke x modellizzare quello ke accade nel nostro cervello... ma vabbè...
questa è un'altra storia :asd:
ci sono ambienti (per esempio dove sto io, banca) dove la programmazione ad oggeti non c'é e non serve.
Si sta pensando ad una revisione totale del sistema informativo migrando verso il java, e sarebbe anche ora, ma per adesso si va avanti a proc, forms, pl/sql ...
Pensa che adesso, per risolvere un problema strano (i peggiori, quelli che ogni tanto ci sono ma di solito va tutto bene) sto facendo un pro*c che si autotrussa, con fork, exec ... :D e mi piace! :asd:
ci sono ambienti (per esempio dove sto io, banca) dove la programmazione ad oggeti non c'é e non serve.
Si sta pensando ad una revisione totale del sistema informativo migrando verso il java, e sarebbe anche ora, ma per adesso si va avanti a proc, forms, pl/sql ...
Pensa che adesso, per risolvere un problema strano (i peggiori, quelli che ogni tanto ci sono ma di solito va tutto bene) sto facendo un pro*c che si autotrussa, con fork, exec ... :D e mi piace! :asd:
ma vabbe in banca si usa ancora il cobol, non vale :mc: :D
trallallero
19-12-2006, 08:45
ma vabbe in banca si usa ancora il cobol, non vale :mc: :D
o maró! sarei giá scappato :ops:
:D
non c'entra nulla essere masochisti.
Si tratta del fatto che il C è un linguaggio assolutamente matematico, in pratica per quello che si va a programmare esiste un unico modo corretto nel quale posizionare ogni riga di codice. ma anche no:
void a() {
int c = 1;
int d = 2;
printf("%d %d\n", c, d);
}
void b() {
int d = 2;
int c = 1;
printf("%d %d\n", c, d);
}
int main() {
a();
b();
return 0;
}
o maró! sarei giá scappato :ops:
:D
attorno a me pieno di persone che usano uno strano mondo nero 72 colonne per 22 righe, con delle strane istruzioni che sembrano appartenere una lingua antica :asd:
io per fortuna sono su java :asd: (anche se con wsad 5.1 ......)
attorno a me pieno di persone che usano uno strano mondo nero 72 colonne per 22 righe, con delle strane istruzioni che sembrano appartenere una lingua antica :asd: HUWAHUWAHWUAHWUAHA bellissima questa :rotfl: :rotfl: :rotfl: :rotfl:
trallallero
19-12-2006, 09:14
attorno a me pieno di persone che usano uno strano mondo nero 72 colonne per 22 righe, con delle strane istruzioni che sembrano appartenere una lingua antica :asd:
io per fortuna sono su java :asd: (anche se con wsad 5.1 ......)
:D
e magari le scritte in lungua antica sono verdi fosforescenti :asd:
comunque tu usi il java ma qualcuno il java l'ha fatto. E non l'ha fatto in java ... :uh:
comunque tu usi il java ma qualcuno il java l'ha fatto. E non l'ha fatto in java ... :uh: l'ha fatto in Cobol :huh:
e ora che l'hanno reso opensource, tutti lo sanno!! scandalo... :D
:D
e magari le scritte in lungua antica sono verdi fosforescenti :asd:
comunque tu usi il java ma qualcuno il java l'ha fatto. E non l'ha fatto in java ... :uh:
cazzi suoi
:asd:
meglio lui che io
:asd:
^TiGeRShArK^
19-12-2006, 10:08
ci sono ambienti (per esempio dove sto io, banca) dove la programmazione ad oggeti non c'é e non serve.
ke nn c'è sono d'accordissimo.
I mainframe utilizzati fanno girare programmi procedurali.
Però a quanto vedo si sta cercando sempre di + di wrappare questi sistemi legacy in modo da poter sviluppare anke applicazioni + umane di quelle procedurali scritte in cobol o in clipper :asd:
Si sta pensando ad una revisione totale del sistema informativo migrando verso il java, e sarebbe anche ora, ma per adesso si va avanti a proc, forms, pl/sql ...
Pensa che adesso, per risolvere un problema strano (i peggiori, quelli che ogni tanto ci sono ma di solito va tutto bene) sto facendo un pro*c che si autotrussa, con fork, exec ... :D e mi piace! :asd:
nn ho capito ke intendi con auto trussa.... :D
x il resto.. quoto x il masokismo :asd:
trallallero
19-12-2006, 10:19
l'ha fatto in Cobol :huh:
e ora che l'hanno reso opensource, tutti lo sanno!! scandalo... :D
:sbonk:
trallallero
19-12-2006, 10:27
ke nn c'è sono d'accordissimo.
I mainframe utilizzati fanno girare programmi procedurali.
Però a quanto vedo si sta cercando sempre di + di wrappare questi sistemi legacy in modo da poter sviluppare anke applicazioni + umane di quelle procedurali scritte in cobol o in clipper :asd:
spero di non esserci quando avranno fatto il porting a java (non per il java ma perché qui non sto imparando 'na mazza) ma per adesso il C con Oracle va benissimo per fare tabulati. Farli in OO col Java secondo me sarebbe peggio e inutile. Sicuramente altri prog come l'acquisizione assegni, visualizzatore firme etc che ho fatto in C++ sarebbero da rifare in Java almeno, come minimo, ci guadagnerebbero in portabilitá ;)
nn ho capito ke intendi con auto trussa.... :D
il problema é che il problema c'é ogni tanto. Il pro*C che ho fatto é istantaneo :cool: e non abbiamo il tempo per trussare il processo agganciandoci. Allora ho modificato il pro*C: genera un figlio che trussa il padre :D
trallallero
19-12-2006, 10:55
definiscici trussa!
:doh: pardon! :D
su Sun é truss, in Linux é trace. Una specie di debug del processo, vedi tutto ció che fa.
jappilas
19-12-2006, 10:56
a naso sembrava voce del verbo irregolare killare, io killo, tu killi, egli trussa... :p :D
PS: su Solaris non si chiamava dtrace? :O
trallallero
19-12-2006, 11:01
a naso sembrava voce del verbo irregolare killare, io killo, tu killi, egli trussa... :p :D
:D
PS: su Solaris non si chiamava dtrace? :O
aripardon ... su Linux é strace
no dtrace mai sentito. E neanche il mio PC:
:dtrace
bash: dtrace: command not found
giannola
19-12-2006, 16:17
:rotfl: no...Tranquillo..Nn ho la minima idea nè delle funzioni membro nè delle struct :asd: ma scusa..Mi pare d aver detto ke sono vari anni ke nn tocco + il c..Nn m pare di aver mai detto di nn conoscerlo :asd:
allora non dire che la mentalità tra c e c++ è diversa. ;)
giannola
19-12-2006, 16:26
:mbe:
e questo non è masokismo? :D
Io preferisco dovermi preoccupare + del problema ke devo risolvere ke del fatto se tra migliaia di puntatori ne ho sbagliati un paio e mi vado a sparare x capire dove kakkio sta l'errore...bhè..
tanto vale fare il fachiro piuttosto ke il programmatore :asd:
E nono parliamo dei classici bug casuali dei programmi multi-threaded ke là è ancora peggio :asd:
Ovviamente la programmazione OO non è la panacea...
Ma ad oggi è il paradigma di programmazione mediamente "migliore".
X la programmazione multi-threaded imho non è molto adatta...
e neanke x modellizzare quello ke accade nel nostro cervello... ma vabbè...
questa è un'altra storia :asd:
no, è un metodo per imparare ad inquadrare i problemi, esattamente come l'analisi matematica.
Si cerca l'approccio migliore, il più pulito, il più semplice.
Diciamoci la verità grazie ai linguaggi oreintati agli oggetti sono spuntati come funghi pseudoprogrammatori, gente che "programmicchia" ma quando c' è veramente da sbattersi la testa comincia a dire "non si può fare".
Me ne accorgo programmando anche in asp.net.
E' bello, è molto potente, però se è vero che con poche righe già risolvi un mucchio di problemi è altrettanto vero che che finisci per utilizzare oggetti precostituiti di cui ignori il funzionamento.
Difatti alcuni, preferiscono farsi degli oggetti propri, da poter manipolare a proprio piacimento.
Dirsi programmatore e rompersi le balle di programmare del codice difficile è un controsenso.
giannola
19-12-2006, 16:29
W la manutenibilità del codice :stordita:
chi programma seriamente in c, ha un codice così leggibile che potrebbe capirlo un bambino.
Si creano funzioni separate e basta copiaincollare.
ps. l'unico modo corretto nel quale posizionare ogni riga di codice non esiste. Vedasi per esempio i mille modi per fare un helloWord (dall'obfuscated powa 1337 mode, a quello in cui vengono create una classe per ogni lettera della stringa in output :asd: )
comincia a progammare in c, e vedrai come il concetto di visibilità delle variabili diventerà il tuo incubo.
giannola
19-12-2006, 16:36
ma anche no:
void a() {
int c = 1;
int d = 2;
printf("%d %d\n", c, d);
}
void b() {
int d = 2;
int c = 1;
printf("%d %d\n", c, d);
}
int main() {
a();
b();
return 0;
}
chiariamo che quando alludo alla linea messa nel posto giusto alludo al giusto posizionamento delle istruzioni nelle iterazioni e alla vsibilità delle variabili.
Perchè sennò finisce che per farvi ragione scrivete la qualunque.
Ad ogni modo su quello che hai scritto tu sarebbe sufficiente anche mettere un printf solo dopo le due funzioni per far si che il programma non faccia quello che tu vuoi, così è chiaro?
chiariamo che quando alludo alla linea messa nel posto giusto alludo al giusto posizionamento delle istruzioni nelle iterazioni e alla vsibilità delle variabili.
int i, j, k;
void a() {
for (i = 0; i < 10; i++) {
j = i;
k = i * 2;
printf("%d %d\n", j, k);
}
}
void b() {
for (i = 0; i < 10; i++) {
k = i * 2;
j = i;
printf("%d %d\n", j, k);
}
}
int main() {
a();
b();
return 0;
}
forza che ci sei quasi, devi solo introdurre il concetto di dipendenza :asd:
Ad ogni modo su quello che hai scritto tu sarebbe sufficiente anche mettere un printf solo dopo le due funzioni per far si che il programma non faccia quello che tu vuoi, così è chiaro? quale delle due printf devo mettere fuori dalla sua funzione...? :Prrr:
giannola
19-12-2006, 17:43
quale delle due printf devo mettere fuori dalla sua funzione...? :Prrr:
ti senti 'sperto ? :mbe:
giannola
19-12-2006, 18:03
quale delle due printf devo mettere fuori dalla sua funzione...? :Prrr:
quello che della funzione a, mettilo dopo entrambe e prima di return (non si sa mai meglio specificare) :ciapet:
quello che della funzione a, non ho capito niente :huh:
mettilo dopo entrambe e prima di return (non si sa mai meglio specificare) :ciapet: cioè così...?
int c, d;
void a() {
c = 1;
d = 2;
}
void b() {
d = 2;
c = 1;
printf("%d %d\n", c, d);
}
int main() {
a();
b();
printf("%d %d\n", c, d);
return 0;
}
^TiGeRShArK^
19-12-2006, 18:41
allora non dire che la mentalità tra c e c++ è diversa. ;)
se usi il C++ come se fosse un linguaggio procedurale è assolutamente identica...mai detto il contrario! :p
Peccato che qui si parlava di utilizzare C++ con la programmazione ad oggetti..... ke ha ben poco da spartire col C procedurale :asd:
^TiGeRShArK^
19-12-2006, 18:50
no, è un metodo per imparare ad inquadrare i problemi, esattamente come l'analisi matematica.
Si cerca l'approccio migliore, il più pulito, il più semplice.
e secondo te l'approccio migliore + pulito e + semplice è quello dato dal C? :stordita:
Lìapproccio migliore, + pulito e + semplice è quello ke ti permette di risolvere il tuo problema concentrandoti SUL PROBLEMA e non su l'enorme quantità di errori ke il linguaggio x come è strutturato ti porta INEVITABILMENTE a fare :p
Tu fai l'errore comunissimo di considerare la soluzione di un problema semplicemente mettendoti a scrivere codice nel linguaggio ke ti garba e usando la tecnologia ke preferisci semplicemente saltando a piè pari l'ANALISI del problema.
L'analisi e il design sono i due passi fondamentali, ke essi siamo rigorosi come nelle classiche tecniche di programmazione o ke siano semplicemente definiti secondo il continous design tipico dell'extreme programming, semplicemente sono imprescindibili dalla risoluzione di un problema.
Il linguaggio utilizzato dovrebbe essere solo lo strumento migliore ke ti porta a concretizzare la tua soluzione.
Peccato ke se inizi ad implementare a manetta in C ti troverai ben presto in un vero e proprio Code Hell non appena il tuo progettino inizia a raggiungere dimensioni già MOLTO ma MOLTO basse.
Diciamoci la verità grazie ai linguaggi oreintati agli oggetti sono spuntati come funghi pseudoprogrammatori, gente che "programmicchia" ma quando c' è veramente da sbattersi la testa comincia a dire "non si può fare".
veramente quelli ci sono sempre stati :mbe:
casomai la loro diffusione è aumentata col fatto ke la tecnologia e i pc si sono diffusi moltissimo ultimamente..
Quando ho iniziato io a programmare ben poki sapevano cosa fosse un processore :asd:
Me ne accorgo programmando anche in asp.net.
E' bello, è molto potente, però se è vero che con poche righe già risolvi un mucchio di problemi è altrettanto vero che che finisci per utilizzare oggetti precostituiti di cui ignori il funzionamento.
e quale sarebbe il problema scusami se questi oggetti svolgono EGREGIAMENTE il loro compito?
stai forse dicendo ke nn dovremmo nemmeno utilizzare i Design Patterns xkè danno soluzioni "preconfezionate"?
:mbe:
A me onestamente pare un'assurdità.
Non vedo un solo motivo x cui reinventare la ruota, soprattutto tenendo conto del tempo ke perderesti per reimplementarla e del fatto ke SICURAMENTE funzionerà molto peggio rispetto a soluzioni STANDARD utilizzate in tutto il mondo.
Difatti alcuni, preferiscono farsi degli oggetti propri, da poter manipolare a proprio piacimento.
Dirsi programmatore e rompersi le balle di programmare del codice difficile è un controsenso.
Veramente un programmatore dovrebbe concentrarsi sulla risoluzione di un problema :D
è pagato x quello, nn certo x far vedere quanto è bravo ad usare il C è il Java o quello ke è ;)
^TiGeRShArK^
19-12-2006, 18:58
chi programma seriamente in c, ha un codice così leggibile che potrebbe capirlo un bambino.
Si creano funzioni separate e basta copiaincollare.
ah ok..
finalmente ho capito il tuo problema :asd:
Mai lavorato con progetti dell'ordine delle diverse centinaia di migliaia di righe di codice? (Commenti e blank esclusi ovviamente)
Ti assicuro ke poi vedresti davvero cosa significa "leggibilità" e capiresti ke col C o con qualsivoglia linguaggio procedurale è umanamente impossibile mantenere il codice con costi non assurdi. ;)
comincia a progammare in c, e vedrai come il concetto di visibilità delle variabili diventerà il tuo incubo.
:mbe:
Ma da come scrivi sembra ke sei convinto ke nessuno di noi abbia mai programmato in c.... :mbe:
71104 da quello ke ricordo *qualcosina* in C l'ha scritta :p
E cmq io avevo già scritto ke ho buttato sangue x passare dalla programmazione procedurale a quella ad oggetti se non erro :asd:
La storia degli pseudoprogrammatori la dissero anche quando si passò dalle schede perforate all'assembly. Se non giravi con il punzone e un pezzo di plastica da bucherellare non eri nessuno. E prima ancora, quando il vero programmatore aveva le tasche piene di valvole agitava un saldatore in faccia a tutti sputando "ignorante" a destra e a manca. Insomma, sotto con l'abaco ragazzi, quello si che insegna a ragionare!
La storia degli pseudoprogrammatori la dissero anche quando si passò dalle schede perforate all'assembly. Se non giravi con il punzone e un pezzo di plastica da bucherellare non eri nessuno. E prima ancora, quando il vero programmatore aveva le tasche piene di valvole agitava un saldatore in faccia a tutti sputando "ignorante" a destra e a manca. Insomma, sotto con l'abaco ragazzi, quello si che insegna a ragionare! QUOTONE!!! il programmatore del futuro parla al computer nel suo linguaggio naturale!!! (non scherzo)
:mbe:
Ma da come scrivi sembra ke sei convinto ke nessuno di noi abbia mai programmato in c.... :mbe:
71104 da quello ke ricordo *qualcosina* in C l'ha scritta :p drivers WDM :asd: :asd: :asd:
magari sono stati proprio loro a farmi convertire alla OOP: il kernel di NT, si sa, è scritto in C ma in un'ottica OO.
^TiGeRShArK^
19-12-2006, 19:57
drivers WDM :asd: :asd: :asd:
magari sono stati proprio loro a farmi convertire alla OOP: il kernel di NT, si sa, è scritto in C ma in un'ottica OO.
e lo so ke il C lo conosci molto ma molto meglio di me :D
ero *lievemente* ironico quando ho scritto qualcosina :asd:
giannola
20-12-2006, 07:10
non ho capito niente :huh:
lo vedi che basta spostare una parola che il tuo compilatore mentale c developed va in tilt
:Prrr: :D
cioè così...?
int c, d;
void a() {
c = 1;
d = 2;
}
void b() {
d = 2;
c = 1;
printf("%d %d\n", c, d);
}
int main() {
a();
b();
printf("%d %d\n", c, d);
return 0;
}
esatto, adesso ti restituirà per le due printf i valori di d e c impostati dalla funzione b (che nel tuo caso sono uguali a quelli della funzione a, ma che in un programma vero sarebbero diversi.) e non da quelli della funzione a.
giannola
20-12-2006, 07:18
ah ok..
finalmente ho capito il tuo problema :asd:
Mai lavorato con progetti dell'ordine delle diverse centinaia di migliaia di righe di codice? (Commenti e blank esclusi ovviamente)
Ti assicuro ke poi vedresti davvero cosa significa "leggibilità" e capiresti ke col C o con qualsivoglia linguaggio procedurale è umanamente impossibile mantenere il codice con costi non assurdi. ;)
so cosa significa leggibilità, e ringrazio MS di aver inventato ASP.NET, perchè le migliaia di righe per pagina si sono ridotte al peggio a qualche centinaio. :asd:
Su questo sono d'accordo, solo per leggere e scrivere su un file ci possono volere anche 5-600 righe di codice col c. :muro: :D
:mbe:
Ma da come scrivi sembra ke sei convinto ke nessuno di noi abbia mai programmato in c.... :mbe:
mai detto :ciapet: nè mi permetterei mai visto che nn vi conosco. ;)
E cmq io avevo già scritto ke ho buttato sangue x passare dalla programmazione procedurale a quella ad oggetti se non erro :asd:
in effetti grazie al mio prof e al c certe volte pensato di buttare dalla finestra il mio portatile con i listati. :D
giannola
20-12-2006, 07:19
La storia degli pseudoprogrammatori la dissero anche quando si passò dalle schede perforate all'assembly. Se non giravi con il punzone e un pezzo di plastica da bucherellare non eri nessuno. E prima ancora, quando il vero programmatore aveva le tasche piene di valvole agitava un saldatore in faccia a tutti sputando "ignorante" a destra e a manca. Insomma, sotto con l'abaco ragazzi, quello si che insegna a ragionare!
io porto i fagioli che sono di più basso livello :asd:
comincia a progammare in c, e vedrai come il concetto di visibilità delle variabili diventerà il tuo incubo.
ci sono gia passato ai tempi dell'uni, e la voglia di riprenderlo in mano è veramente bassa :asd:
i puntatori sono il male :Prrr:
giannola
20-12-2006, 10:09
ci sono gia passato ai tempi dell'uni, e la voglia di riprenderlo in mano è veramente bassa :asd:
i puntatori sono il male :Prrr:
per carità mi hanno fatto veramente impazzire :mad:
no, è un metodo per imparare ad inquadrare i problemi, esattamente come l'analisi matematica.
Si cerca l'approccio migliore, il più pulito, il più semplice.
Rischio di andare OT, ma mi sembra che il C ed in generale i programmi imperativi abbiano poco a che fare con l'analisi matematica: forse la classe dei linguaggi funzionali (http://it.wikipedia.org/wiki/Programmazione_funzionale) è quella che più vi si avvicina.
esatto, adesso ti restituirà per le due printf i valori di d e c impostati dalla funzione b (che nel tuo caso sono uguali a quelli della funzione a, ma che in un programma vero sarebbero diversi.) e non da quelli della funzione a. poche seghe, a me funziona :Prrr:
Rischio di andare OT, ma mi sembra che il C ed in generale i programmi imperativi abbiano poco a che fare con l'analisi matematica: forse la classe dei linguaggi funzionali (http://it.wikipedia.org/wiki/Programmazione_funzionale) è quella che più vi si avvicina. esistono due tipi di informatica: quella dei programmatori che devono semplicemente fare i programmi (possibilmente funzionanti e possibilmente corretti) e quella degli universitari che usano Linux (ma vorrebbero un iBook) e che dicono che l'università non è fatta per sfornare programmatori (e da dove dovrebbero uscire invece non si sa), e che la loro informatica ha tanto a che fare coi computers quanto ne ha l'astronomia con i cannocchiali.
con una sega mentale o con l'altra il secondo tipo di informatica può tranquillamente assumere il ruolo di ramo della matematica ed avvicinarsi, se non proprio inglobare, l'altro ramo che è analisi. tant'è vero che tra i vari esami io ho dovuto dare anche Calcolo Differenziale e Calcolo Integrale.
i puntatori sono il male :Prrr: adesso non esageriamo nell'altro verso: il C e il C++ nei loro rispettivi ambiti servono e sono irrinunciabili.
adesso non esageriamo nell'altro verso: il C e il C++ nei loro rispettivi ambiti servono e sono irrinunciabili.
diciamo che meno si possono usare e meglio è.
Poi in certi ambiti non sè ne può fare a meno, mentre in altri portano vantaggi che con un gc e l'allocazione automatica sono difficili da ottenere(tipo programmazione 3d in cui devi poter liberare memoria quando vuoi, come diceva fek)
esistono due tipi di informatica: quella dei programmatori che devono semplicemente fare i programmi (possibilmente funzionanti e possibilmente corretti) e quella degli universitari che usano Linux (ma vorrebbero un iBook) e che dicono che l'università non è fatta per sfornare programmatori (e da dove dovrebbero uscire invece non si sa), e che la loro informatica ha tanto a che fare coi computers quanto ne ha l'astronomia con i cannocchiali.
con una sega mentale o con l'altra il secondo tipo di informatica può tranquillamente assumere il ruolo di ramo della matematica ed avvicinarsi, se non proprio inglobare, l'altro ramo che è analisi. tant'è vero che tra i vari esami io ho dovuto dare anche Calcolo Differenziale e Calcolo Integrale.
Capisco il tuo sfogo, spero comunque che tu non mi abbia frainteso: ho solo confrontanto linguaggi imperativi, linguaggi funzionali e analisi matematica.
Non parlarmi di università che sono due anni che mi manca solo la tesi... :rolleyes: :muro:
giannola
20-12-2006, 16:28
poche seghe, a me funziona :Prrr:
grazie al caspio! hai fatto due funzioni dove dai gli stessi numeri, quando fai così sembri proprio niubbo altro che driver :ciapet: :D
giannola
20-12-2006, 16:36
esistono due tipi di informatica: quella dei programmatori che devono semplicemente fare i programmi (possibilmente funzionanti e possibilmente corretti) e quella degli universitari che usano Linux (ma vorrebbero un iBook) e che dicono che l'università non è fatta per sfornare programmatori (e da dove dovrebbero uscire invece non si sa), e che la loro informatica ha tanto a che fare coi computers quanto ne ha l'astronomia con i cannocchiali.
con una sega mentale o con l'altra il secondo tipo di informatica può tranquillamente assumere il ruolo di ramo della matematica ed avvicinarsi, se non proprio inglobare, l'altro ramo che è analisi. tant'è vero che tra i vari esami io ho dovuto dare anche Calcolo Differenziale e Calcolo Integrale.
vero.
io prima ho imparato a programmare per lavoro e poi sono andato all'uni, debbo dire che l'impressione è quella.
Mi sono domandato: ma se non sapessi già programmare cosa sarei diventato uscendo da qui ?
Conosco (alcuni) ingengeri che gli cominci a parlare di progettazione di un sw in maniera teorica e si riempiono la bocca di paroloni, poi messi di fronte ad un progetto concreto da realizzare e restano impalati.
Conosco persone che non si sono nemmeno avvicinate ad ingegneria che hanno imparato a fare cose mostruose. :eek:
Devo dire che lo studio univeristario un po di benefici me li ha dati dal punto di vista tecnico-scentifico, ma rappresenta un compendio alla mia professionalità e non l'elemento che dovrebbe formarmi, come invece dovrebbe fare.
grazie al caspio! hai fatto due funzioni dove dai gli stessi numeri, ovvio, le due funzioni contengono le stesse prime due istruzioni scambiate perché volevo farti vedere che in C a volte è possibile cambiare di posto alcune istruzioni senza che il programma smetta di funzionare come desiderato :read:
quando fai così sembri proprio niubbo altro che driver :ciapet: :D io almeno sembro :Prrr:
SlimSh@dy
20-12-2006, 17:09
vero.
io prima ho imparato a programmare per lavoro e poi sono andato all'uni, debbo dire che l'impressione è quella.
Mi sono domandato: ma se non sapessi già programmare cosa sarei diventato uscendo da qui ?
Conosco (alcuni) ingengeri che gli cominci a parlare di progettazione di un sw in maniera teorica e si riempiono la bocca di paroloni, poi messi di fronte ad un progetto concreto da realizzare e restano impalati.
Conosco persone che non si sono nemmeno avvicinate ad ingegneria che hanno imparato a fare cose mostruose. :eek:
Devo dire che lo studio univeristario un po di benefici me li ha dati dal punto di vista tecnico-scentifico, ma rappresenta un compendio alla mia professionalità e non l'elemento che dovrebbe formarmi, come invece dovrebbe fare.
Be mi sembra ovvio che l'università serve a qualcosa...sopratutto se gli esami non si prendono come dei semplici "ostacoli" da superare in qualsiasi modo , tipo cercar di scopiazzare e fare esami a fortuna ma studiare perchè il vero obiettivo è apprendere e non il voto ;) ;) ......
Be mi sembra ovvio che l'università serve a qualcosa...sopratutto se gli esami non si prendono come dei semplici "ostacoli" da superare in qualsiasi modo , tipo cercar di scopiazzare e fare esami a fortuna ma studiare perchè il vero obiettivo è apprendere e non il voto ;) ;) ...... guardate ragazzi, un perbenista da predica domenicale!! :eek: va' che roba... :D
:D Ma non vedere che siete tutti cotti?!!
ANTICHI!
Aspettate che abbia finito di scrivere il mio sistema operativo e altro che C, C++ e palle varie! Gli faccio vedere io gli faccio, a 'sti dottoroni dell'informatica, da che parte gira il pianeta! :D
giannola
20-12-2006, 18:34
ovvio, le due funzioni contengono le stesse prime due istruzioni scambiate perché volevo farti vedere che in C a volte è possibile cambiare di posto alcune istruzioni senza che il programma smetta di funzionare come desiderato :read:
io almeno sembro :Prrr:
'a professò quanto fai ar chilo ? :Prrr:
Magari me spieghi pure come usare i puntatori al posto delle freccette :ciapet: :D
giannola
20-12-2006, 18:34
guardate ragazzi, un perbenista da predica domenicale!! :eek: va' che roba... :D
zei un pericolo pubblico :sofico:
giannola
20-12-2006, 18:35
:D Ma non vedere che siete tutti cotti?!!
ANTICHI!
Aspettate che abbia finito di scrivere il mio sistema operativo e altro che C, C++ e palle varie! Gli faccio vedere io gli faccio, a 'sti dottoroni dell'informatica, da che parte gira il pianeta! :D
mi raccomando fallo girare in senso antiorario e che ci possa giocare con pacman si si :p
E' VIVO, E' VIVO!!!
10110011 00000111 10110100 00000000
11001101 00010110 10110100 00001110
11001101 00010000 11101011 11110110
E non solo, il portatile è anche riuscito a sopravvivere al boot :D
SlimSh@dy
20-12-2006, 23:56
guardate ragazzi, un perbenista da predica domenicale!! :eek: va' che roba... :D
Perchè non ho ragione?? :confused: :confused:
Perchè non ho ragione?? :confused: :confused:
Era una buontemponata, via, siamo gente allegra!
Sull'università si potrebbe instaurare un dibattito filosofico di cent'anni. Anzi, una volta si era anche provato. Finì a ceffoni anche lì, ma questa è un'altra storia :D
esistono due tipi di informatica: quella dei programmatori che devono semplicemente fare i programmi (possibilmente funzionanti e possibilmente corretti) e quella degli universitari che usano Linux (ma vorrebbero un iBook) e che dicono che l'università non è fatta per sfornare programmatori (e da dove dovrebbero uscire invece non si sa), e che la loro informatica ha tanto a che fare coi computers quanto ne ha l'astronomia con i cannocchiali.
con una sega mentale o con l'altra il secondo tipo di informatica può tranquillamente assumere il ruolo di ramo della matematica ed avvicinarsi, se non proprio inglobare, l'altro ramo che è analisi. tant'è vero che tra i vari esami io ho dovuto dare anche Calcolo Differenziale e Calcolo Integrale.
La prima categoria che individui tu tende a confondere informatica con programmazione, il che e' un tantino riduttivo; un buon informatico dovrebbe essere in grado di programmare bene, ma non fermarsi li', perche' sono sempre piu' necessarie conoscenze teoriche (di matematica, fisica, informatica) per lavorare, a meno che la tua aspirazione non sia di scrivere gestionali corretti e funzionanti.
Altro che seghe mentali :p.
trallallero
21-12-2006, 10:51
La prima categoria che individui tu tende a confondere informatica con programmazione, il che e' un tantino riduttivo; un buon informatico dovrebbe essere in grado di programmare bene, ma non fermarsi li', perche' sono sempre piu' necessarie conoscenze teoriche (di matematica, fisica, informatica) per lavorare, a meno che la tua aspirazione non sia di scrivere gestionali corretti e funzionanti.
Altro che seghe mentali :p.
il programmatore é il muratore del software: una bella gettata di codice e costruisci il programma :O
tomminno
21-12-2006, 11:27
vero.
io prima ho imparato a programmare per lavoro e poi sono andato all'uni, debbo dire che l'impressione è quella.
Mi sono domandato: ma se non sapessi già programmare cosa sarei diventato uscendo da qui ?
Conosco (alcuni) ingengeri che gli cominci a parlare di progettazione di un sw in maniera teorica e si riempiono la bocca di paroloni, poi messi di fronte ad un progetto concreto da realizzare e restano impalati.
Conosco persone che non si sono nemmeno avvicinate ad ingegneria che hanno imparato a fare cose mostruose. :eek:
Devo dire che lo studio univeristario un po di benefici me li ha dati dal punto di vista tecnico-scentifico, ma rappresenta un compendio alla mia professionalità e non l'elemento che dovrebbe formarmi, come invece dovrebbe fare.
Evidentemente non ti è chiaro quale sia la figura dell'ingegnere.
L'ingegnere informatico non è un programmatore.
Secondo te un ingegnere edile è un muratore?
Se vuoi fare il programmatore, ingegneria non è il percorso di studi adatto.
dio ci salvi dagli ingegneri :asd:
(e dagli avvocati :asd: )
ps.scherzo, e che sono l'antiingegnere per definizione :)
pps. non è detto che il metodo ingegneristico puro sia adatto all'informatica. O almeno c'è chi sostiene che non lo è, motivando che un programma dall'inizio alla fine subisce spesso(o meglio quasi sempre) delle modifiche sui recquisiti, a differenza ad esempio di una casa, dove una volta fatto il progetto, si segue quello e non ci sono molti spazi per le modifiche.
giannola
21-12-2006, 12:05
Evidentemente non ti è chiaro quale sia la figura dell'ingegnere.
L'ingegnere informatico non è un programmatore.
Secondo te un ingegnere edile è un muratore?
Se vuoi fare il programmatore, ingegneria non è il percorso di studi adatto.
no di grazia dimmelo tu che cos'è un ingegnere informatico. :ciapet:
D'altronde sotto questo aspetto nemmeno un assemblatore hw ha bisogno di fare ingegneria e nemmeno un tecnico di reti.
Si potrebbe concludere che l'ingegnere(informatico) è un factotum, in pratica uno che sa fare tutto e niente. :Prrr:
Vuoi vedere che sto pagando le tasse a vanvera ? :D
Per quanto riguarda l'ingegnere edile, direi che deve conoscere molto meglio del muratore le specifiche dei materiali da utilizzare e le geometrie di quello che si appresta a far costruire, visto che il muratore se lasciato da solo può fare cavolate.
In ogni caso l'unica cosa che l'ingegnere edile (di solito) non fa è impastare calce, eppure conosco ingegneri che l'hanno fatto anche per fare vedere ai muratori come si fa.
Cmq attendo tua spiegazione.
La prima categoria che individui tu tende a confondere informatica con programmazione, il che e' un tantino riduttivo; un buon informatico dovrebbe essere in grado di programmare bene, ma non fermarsi li', perche' sono sempre piu' necessarie conoscenze teoriche (di matematica, fisica, informatica) per lavorare, a meno che la tua aspirazione non sia di scrivere gestionali corretti e funzionanti.
Altro che seghe mentali :p. :rotfl: :rotfl: :rotfl: :rotfl:
usi Linux? :D
o hai già l'iBook? :eek:
PS: sorry, ma non ho intenzione di discutere sull'università: è un argomento che mi ha rotto abbastanza.
SlimSh@dy
21-12-2006, 13:31
Era una buontemponata, via, siamo gente allegra!
Sull'università si potrebbe instaurare un dibattito filosofico di cent'anni. Anzi, una volta si era anche provato. Finì a ceffoni anche lì, ma questa è un'altra storia :D
OK ;) ;) :D :D
:rotfl: :rotfl: :rotfl: :rotfl:
usi Linux? :D
o hai già l'iBook? :eek:
:mbe:
Sbagli bersaglio, sono un matematico (seppur ad indirizzo informatico ).
Se hai scelto una facolta' e ti sei accorto che non e' quello che speravi non dovresti comunque sfogarti sugli altri.
Chiedo comunque scusa e chiudo anche io l'OT.
tomminno
21-12-2006, 14:48
no di grazia dimmelo tu che cos'è un ingegnere informatico. :ciapet:
Scuramente non un programmatore.
Problema da Ingegnere Informatico:
Stabilire come uniformare i sistemi informatici di una multinazionale con sedi sparse per il mondo, strutturare il sistema informatico in modo che vengano mantenute riservate le informazioni sensibili e studiare come conservare i dati per il numero di anni previsto dalla legge (sempre in modo uniforme in tutti gli impianti). Stabilire se il sistema corrisponde alle normative vigenti e in caso non lo sia, pianificare gli interventi atti a rispettare la normativa.
La figura dell'ingegnere è quella del progettista non del realizzatore.
D'altronde sotto questo aspetto nemmeno un assemblatore hw ha bisogno di fare ingegneria e nemmeno un tecnico di reti.
Si potrebbe concludere che l'ingegnere(informatico) è un factotum, in pratica uno che sa fare tutto e niente. :Prrr:
Vuoi vedere che sto pagando le tasse a vanvera ? :D
L'università deve darti l'elasticità mentale per adattarti ai problemi che ti trovi difronte. Pensa un pò dove l'ho fatta io, la programmazione la davano per scontata: a me hanno insegnato solo printf e scanf, il problema è stato poi dover realizzare un analizzatore lessicale, elaborare immagini, elaborare audio, conoscere Java e C++ per illuminazione divina.
Per quanto riguarda l'ingegnere edile, direi che deve conoscere molto meglio del muratore le specifiche dei materiali da utilizzare e le geometrie di quello che si appresta a far costruire, visto che il muratore se lasciato da solo può fare cavolate.
In ogni caso l'unica cosa che l'ingegnere edile (di solito) non fa è impastare calce, eppure conosco ingegneri che l'hanno fatto anche per fare vedere ai muratori come si fa.
Cmq attendo tua spiegazione.
La struttura piramidale nell'informatica dovrebbe essere questa:
L'ingegnere incontra il cliente per cercare di capire le sue problematiche (e questa è la parte che causa sempre tutti i problemi a posteriori perchè il cliente non dice mai tutto, perchè non vengono poste le domange giuste...) e cercare di entrare nella materia (che potrebbe essere gestione flotte camion come la produzione di cioccolatini), individuare i punti critici e le entità coivolte. Il compito dell'ingegnere si esaurisce con i diagrammi UML. Al programmatore il compito di implementarli nel migliore dei modi (con gli strumenti scelti in fase di progettazione).
Così come il compito dell'ingegnere edile termina con il progetto e non con l'impastare la calce, come non è compito dell'ingegnere elettronico saldare i componenti sulle schede, come non è compito di un medico fare l'infermiere.
La struttura piramidale nell'informatica dovrebbe essere questa: [omissis]
Per quelli per cui ho lavorato io era così:
il commerciale incontra il cliente.
il cliente chiede l'esagerato.
il commerciale rilancia con l'impossibile.
il commerciale va dall'ingegnere che guida il team di sviluppo che, dopo aver sentito quello che il commerciale ha venduto, corre dal manager con le mani tra i capelli.
l'ingegnere dice "non ce la facciamo" il manager capisce "quanto ci facciamo" e va in trance con gli occhi a dollaro.
l'ingegnere va dai suoi programmatori e dice "ragazzi siamo nella cacca" e quelli rispondono "stavolta cerchiamo di non fare l'onda".
Più che piramide è una catena di Sant'Antonio :D
trallallero
21-12-2006, 15:34
Per quelli per cui ho lavorato io era così:
il commerciale incontra il cliente.
il cliente chiede l'esagerato.
il commerciale rilancia con l'impossibile.
il commerciale va dall'ingegnere che guida il team di sviluppo che, dopo aver sentito quello che il commerciale ha venduto, corre dal manager con le mani tra i capelli.
l'ingegnere dice "non ce la facciamo" il manager capisce "quanto ci facciamo" e va in trance con gli occhi a dollaro.
l'ingegnere va dai suoi programmatori e dice "ragazzi siamo nella cacca" e quelli rispondono "stavolta cerchiamo di non fare l'onda".
Più che piramide è una catena di Sant'Antonio :D
qui in banca ci sono:
- i super-capi (ragionieri arricchiti) che prendono delle decisioni per fare altri soldi
- i capi area ricevono ordini sui progetti e soprattutto scadenze
- i capi progetto vengono convocati dai capi area per definire il progetto e la scadenza
- i programmatori interni vengono convocati dai capi progetto per ricevere spiegazioni sulle specifiche relative al progetto.
- i consulenti ricevono un foglio di carta con uno schizzetto a matita e realizzano il progetto.
- i consulenti testano il progetto
- i consulenti correggono le minchiate frutto della pessima analisi scovate grazie ai test
- i consulenti ritestano, installano in produzione.
- i consulenti gestiscono/correggono le anomalie del progetto durante l'uso in produzione.
dimenticavo: i consulenti si beccano le cazziate che spettano agli interni :D
giannola
21-12-2006, 17:49
Scuramente non un programmatore.
Problema da Ingegnere Informatico:
Stabilire come uniformare i sistemi informatici di una multinazionale con sedi sparse per il mondo, strutturare il sistema informatico in modo che vengano mantenute riservate le informazioni sensibili e studiare come conservare i dati per il numero di anni previsto dalla legge (sempre in modo uniforme in tutti gli impianti). Stabilire se il sistema corrisponde alle normative vigenti e in caso non lo sia, pianificare gli interventi atti a rispettare la normativa.
La figura dell'ingegnere è quella del progettista non del realizzatore.
L'università deve darti l'elasticità mentale per adattarti ai problemi che ti trovi difronte. Pensa un pò dove l'ho fatta io, la programmazione la davano per scontata: a me hanno insegnato solo printf e scanf, il problema è stato poi dover realizzare un analizzatore lessicale, elaborare immagini, elaborare audio, conoscere Java e C++ per illuminazione divina.
La struttura piramidale nell'informatica dovrebbe essere questa:
L'ingegnere incontra il cliente per cercare di capire le sue problematiche (e questa è la parte che causa sempre tutti i problemi a posteriori perchè il cliente non dice mai tutto, perchè non vengono poste le domange giuste...) e cercare di entrare nella materia (che potrebbe essere gestione flotte camion come la produzione di cioccolatini), individuare i punti critici e le entità coivolte. Il compito dell'ingegnere si esaurisce con i diagrammi UML. Al programmatore il compito di implementarli nel migliore dei modi (con gli strumenti scelti in fase di progettazione).
Così come il compito dell'ingegnere edile termina con il progetto e non con l'impastare la calce, come non è compito dell'ingegnere elettronico saldare i componenti sulle schede, come non è compito di un medico fare l'infermiere.
ecco perchè i neo ingegneri hanno tutti la faccia triste. :ciapet: :D
vorrà dire che userò il mio titolo per eventuali incontinenze :stordita:
Se hai scelto una facolta' e ti sei accorto che non e' quello che speravi non dovresti comunque sfogarti sugli altri. ma io già lo sapevo da prima che quello che cercavo non esiste. e comunque ho smesso di sfogarmi già da un po' ormai :P
trallallero
21-12-2006, 18:13
siete andati un pelino OT per caso ? ;)
dalle differenze (anzi, dalla differenza, se vogliamo essere precisi, visto il titolo) tra il C e il C++ al parlare di ingegneri e sfoghi vari ce ne passa, mi consenta :D
Senza contare che tomminno non ha detto niente sul mio codice ;)
La struttura piramidale nell'informatica dovrebbe essere questa:
L'ingegnere incontra il cliente per cercare di capire le sue problematiche (e questa è la parte che causa sempre tutti i problemi a posteriori perchè il cliente non dice mai tutto, perchè non vengono poste le domange giuste...) e cercare di entrare nella materia (che potrebbe essere gestione flotte camion come la produzione di cioccolatini), individuare i punti critici e le entità coivolte. Il compito dell'ingegnere si esaurisce con i diagrammi UML. Al programmatore il compito di implementarli nel migliore dei modi (con gli strumenti scelti in fase di progettazione).
Così come il compito dell'ingegnere edile termina con il progetto e non con l'impastare la calce, come non è compito dell'ingegnere elettronico saldare i componenti sulle schede, come non è compito di un medico fare l'infermiere.
Ritengo che questo approccio 'gerarchico' stia pian piano diventando obsoleto: funziona bene se calato in un contesto di produzione del software di tipo 'waterfall', ma ormai metodologie alternative stanno prendendo il sopravvento (soprattutto, ahimè, all'estero).
Per quelli per cui ho lavorato io era così:
il commerciale incontra il cliente.
il cliente chiede l'esagerato.
il commerciale rilancia con l'impossibile.
il commerciale va dall'ingegnere che guida il team di sviluppo che, dopo aver sentito quello che il commerciale ha venduto, corre dal manager con le mani tra i capelli.
l'ingegnere dice "non ce la facciamo" il manager capisce "quanto ci facciamo" e va in trance con gli occhi a dollaro.
l'ingegnere va dai suoi programmatori e dice "ragazzi siamo nella cacca" e quelli rispondono "stavolta cerchiamo di non fare l'onda".
Più che piramide è una catena di Sant'Antonio
Rispecchia più da vicino la realtà italiana delle sw-house medio-piccole. Però si tende a dare per scontato che a capo di un team di sviluppo ci sia un ingegnere informatico: ciò accade molto di rado.
Ho avuto a che fare con laureati/diplomati di ogni genere che ricoprono quel ruolo, quindi credo che {'team-leader'/'progettista sw'} non implichi un titolo di studio ben definito.
Piuttosto bisognerebbe dare più voce in capitolo a quelle persone 'esperte' ed 'autodidatte' che spesso devono sottostare a personaggi di dubbia preparazione ma che hanno 'il titolone', coprendone le malefatte facendosi un culo così.
Imho è fondamentale nel nostro campo avere sia un background culturale 'accademico', sia una vasta esperienza sul campo tenendosi sempre aggiornati: un titolo di studio universitario dovrebbe essere solo l'inizio, la base solida su cui poggiare il nostro 'saper fare'.
^TiGeRShArK^
21-12-2006, 19:45
Ritengo che questo approccio 'gerarchico' stia pian piano diventando obsoleto: funziona bene se calato in un contesto di produzione del software di tipo 'waterfall', ma ormai metodologie alternative stanno prendendo il sopravvento (soprattutto, ahimè, all'estero).
</cut>
Imho è fondamentale nel nostro campo avere sia un background culturale 'accademico', sia una vasta esperienza sul campo tenendosi sempre aggiornati: un titolo di studio universitario dovrebbe essere solo l'inizio, la base solida su cui poggiare il nostro 'saper fare'.
:muro:
quoto ovviamente :sob:
è il panorama italiano del software ke, purtroppo, fa oggettivamente SKIFO :Puke:
Il bello ke se vai a fare un colloquio e inizi a parlare di Extreme Programming, metodologie agili, Test Driven Development non hanno la benkè minima idea di quello ke stai dicendo :asd:
E ovviamente preferiscono cmq prendere ki ha esperienze lavorative DOCUMENTATE maggiori delle tue, anke se hai 16 anni di programmazione alle spalle con tutti i + svariati linguaggi.... (Ogni fatto o avvenimento accaduto a persone o cose presenti è puramente casuale :O :angel: )
ekerazha
23-12-2006, 17:55
appunto.
Proprio per quel motivo il mio consiglio è di lasciar perdere completametne il C/C++ e di concentrarsi piuttosto su C#/Java/Python/Ruby.
In questo modo imparerà direttamente la programmazione ad oggetti magari con una buona introduzione sui costrutti di base.
Non penso che per chi vuole imparare a programmare sia molto educativo consigliare linguaggi a tipizzazione prettamente dinamica... diciamo C# o Java ci possono stare, Python e Ruby personalmente non li consiglierei.
Non penso che per chi vuole imparare a programmare sia molto educativo consigliare linguaggi a tipizzazione prettamente dinamica... diciamo C# o Java ci possono stare, Python e Ruby personalmente non li consiglierei.
Perché ? :mbe:
Non vedo particolari controindicazioni, si tratta in ogni caso di linguaggi fortemente tipizzati.
ekerazha
24-12-2006, 13:53
si tratta in ogni caso di linguaggi fortemente tipizzati.
A me Python e Ruby sembra utilizzino tipicamente la tipizzazione dinamica.
sì nessun dubbio a riguardo, infatti ho parlato di tipizzazione forte e non statica, anche se spesso le due vengono (a mio avviso erroneamente confuse). Con "forte" intendo dire che le regole sui tipi vengono fatte rispettare in modo assoluto, senza eccezione. Ad esempio C e C++ sono tipizzati staticamente ma debolmente, quanto ad esempio posso prendere un float e vederlo come un int e viceversa. Python e Ruby sono dinamicamente ma fortemente tipizzati, in quanto non c'è modo di vedere un float come una stringa (a meno di conversioni ovviamente). Il controllo viene fatto a run-time, ma c'è.
Spero di essermi chiarito.
ekerazha
25-12-2006, 02:28
sì nessun dubbio a riguardo, infatti ho parlato di tipizzazione forte e non statica, anche se spesso le due vengono (a mio avviso erroneamente confuse). Con "forte" intendo dire che le regole sui tipi vengono fatte rispettare in modo assoluto, senza eccezione. Ad esempio C e C++ sono tipizzati staticamente ma debolmente, quanto ad esempio posso prendere un float e vederlo come un int e viceversa. Python e Ruby sono dinamicamente ma fortemente tipizzati, in quanto non c'è modo di vedere un float come una stringa (a meno di conversioni ovviamente). Il controllo viene fatto a run-time, ma c'è.
Spero di essermi chiarito.
Certo, ma il punto non è questo. Il punto è che dal mio punto di vista per un programmatore in erba sarebbe bene avere una base solida ed educarlo anche ad un uso corretto della tipizzazione, anzichè illuderlo del fatto che il linguaggio farà sempre tutto da sè.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.