Ubisoft e i tentacoli del DRM

Il sistema di protezione con richiesta di connessione costante per giocare viene definita un successo

Roma – Ubisoft non abbandona la strada vecchia per la nuova, soprattutto se le strade sono quelle di San Francisco: l’ultimo capitolo della saga “Driver” ambientato nella città californiana richiederà , nella versione per PC, agli utenti una connessione Internet costante per giocare e non solo per il multiplayer, ma anche per giocare da soli.

I sistemi DRM che permettono di giocare solo connettendosi e rimanendo collegati ai server del produttore sembravano l’espressione preferita dell’idea di controllo antipirateria dei publisher di videogame, e proprio per questo la caduta di quello Ubisoft sembrava più emblematica: per un guasto ai server erano stati esclusi i legittimi acquirenti dei giochi, ma non i possessori di una versione crackata che avevano potuto continuare tranquillamente a giocare.

Quell’episodio paradossale sembrava essere esemplare sia per la portata dell’insuccesso del sistema di DRM (che di fatto aveva ottenuto l’effetto esattamente contrario a quello perseguito), sia per le conclusioni che a caldo traevano i diretti interessati: Blizzard, per esempio, aveva condannato la richiesta di autenticazione online.

Tuttavia Ubisoft riferisce ora che la pratica dell’impiego del sistema di DRM con connessione mostrerebbe “una significativa diminuzione della pirateria sui nostri titoli e per questo è da considerare un successo”. Non parla, d’altra parte, di aumento di vendite di copie legittime : l’eventuale diminuzione di free rider è dunque da ritenere ancora solo un dato incidentale che non ha modo di essere giustificato.

Nonostante le critiche, insomma, Ubisoft sembra intenzionata con tutte le forze a scoraggiare i suoi clienti paganti: oltre alla connessione costante dovuta, i giocatori non potranno utilizzare le simulazioni di volante eventualmente possedute come periferiche di controllo.

Le decisioni Ubisoft contrastano anche con il mercato dei giochi di seconda mano: ogni copia contiene un codice usa e getta per accedere ai server cui è necessario connettersi per giocare. Per acquistarne uno nuovo occorre spendere 10 dollari, costo che di fatto taglia le gambe a qualsiasi offerta di usato.

Claudio Tamburrino

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Pinco Pallino scrive:
    Re: Uhllalla... ho toccato una setta :)
    - Scritto da: 17ca368053
    vero, come quando si cerca di dimostrare che le
    interfacce e l'eredità multipla non sono la
    stessa
    cosa...In verita' non lo sono.Con l'ereditarieta' multipla posso definire un oggetto "number" in cui il modo "normale" di implementare un + e':{ number res = number(this); res += par; return res;}Poi con qualsiasi classe che definisce in qualche modo un oggetto "numerico" (o che, sensatamente, definisce l'addizione) mi basta definire l'operatore += che lavora in-place (con buona pace di chi si preoccupa dell'overhead di copia se abbiamo una intera matrice); se per un certo tipo voglio fare una ottimizzazione faccio un overload.Se infine nel codice uso un tipo specifico il binding dinamico e l'ottimizzatore toglieranno tutto dal codice oggetto, lasciando il minimo indispensabile per fare quello che e' necessario fare.Se non ho l'ereditarieta' multipla ma solo le interface... in una interface non posso definire una implementazione generica di default. E' solo una limitazione (data dalla struttura con cui e' implementato il linguaggio... chi pensa che "non ti viene conXXXXX perche' e' brutto e pericoloso" mi sa che e' un po' indottrinato...).JMHO.PS: Anni addietro pensavo che template e classi fossero una XXXXX mentale, poi un giorno ho sfidato mister GCC, tra un codice scritto da me in C e in parte in assembler per spremere la CPU come un limone e una implementazione dello stesso algoritmo scritta in C++ "didattico"... ha vinto la seconda di un 20%. Ho cambiato idea, miomalgrado.PPS: Alcune parti dell'ottimizzatore del codice di GCC le ho scritte io, non era una lotta impari, solo che il XXXXXXXX e' piu' veloce di me a considerare tutte le ipotesi.
    • 17ca368053 scrive:
      Re: Uhllalla... ho toccato una setta :)
      - Scritto da: Pinco Pallino
      - Scritto da: 17ca368053

      vero, come quando si cerca di dimostrare che
      le

      interfacce e l'eredità multipla non sono la

      stessa

      cosa...


      In verita' non lo sono.
      ops :$ volevo scrivere il contrario..
  • il signor rossi scrive:
    Re: Uhllalla... ho toccato una setta :)
    Java è un tipico linguaggio a oggetti class based. Smalltalk è altra storia, ma se tu sostieni che Java non è a oggetti perché esistono i tipi di dato primitivi, allora meno che mai lo è C++, mentre ti ricordo che il tuo primo post partiva proprio dal concetto che C++ era molto meglio di Java.Comunque non hai toccato una setta. Io sviluppo in C++ e Java. Sinceramente, sempre più spesso quando torno su Java penso: "finalmente". Perché rispetto a C++ è un linguaggio più moderno, più semplice, più efficiente nella scrittura del codice e nel design dell'architettura.Il che non toglie che C++ sia un bel linguaggio, ma sinceramente non mi pare abbia nulla più di Java, anzi. Se poi mi citi Smalltalk ok, ma Java è sicuramente un compromesso fra OO puro e "quello che serve" nell'utilizzo di tutti i giorni.Che poi vi siano altre cose al giro che magari lo soppianteranno anche una volta che avranno librerie di pari estensione (penso a Ruby, ad esempio) è un altro discorso.E' stupido fare i fanboy di uno o l'altro linguaggio di programmazione, ognuno ha i suoi punti di forza e le sue debolezze, e se si argomenta se ne può anche discutere, ma il tuo primo post non era di questo tenore, era piuttosto del tipo "java è uno schifo, c++ è meglio, java morirà"... :)
    • Pinco Pallino scrive:
      Re: Uhllalla... ho toccato una setta :)
      Mi spiace se il messaggio che ho passato e' stato questo.Ho detto "non mi e' mai piaciuto", non "fa schifo".Non ho detto che non e' a oggeti perche' esistono i tipi primitivi, ho detto che e' meno ad oggetti di altri linguaggi criticati per il non esserlo, e che se proprio vogliamo cercare un vero linguaggio ad oggetti dobbiamo guardare un bel po' indietro.Ho detto "java morira'", e se questo a qualcuno e' suonato come un augurio ha capito ben male, e' la constatazione che l'ultimo punto di forza vero che Java poteva avere (diventare uno standard, che ha una sua nicchia distinta da quella di altri standard come C, PHP, ruby, JavaScript) e' venuta meno.Sun nel bene e nel male ha creduto negli standard e nell'opensource come modello di mercato, Oracle ha ben altra storia.A.
  • Pinco Pallino scrive:
    Re: Uhllalla... ho toccato una setta :)
    - Scritto da: developer
    Piú augurare sventure agli sconosciuti
    ricordare di tanto in tanto che il mondo va
    avanti non farebbe male.Infatti chi ha voluto leggere un malaugurio lo ha fatto in malafede e ha travisato il discorso.Credo che senza lavoro in ambito ICT a lungo termine ci resti solo chi non e' capace di lavorare, chi non ne ha voglia, o chi e' troppo presuntuoso per imparare qualcosa di nuovo.Non sono un programmatore, ma in passato ho avuto l'umilta' di rimettermi a studiare qualcosa di nuovo decine di volte... quindi lungi da me dare per cristallizzate delle opinioni.A.
    • Pinco Pallino scrive:
      Re: Uhllalla... ho toccato una setta :)
      Un'azienda prima di iniziare un progetto importante basato su una tecnologia (e quindi dipendente da essa) dovrebbe farsi tante domande:- Che futuro ha questa tecnologia ?- Chi ne e' "padrone" ?- Mi trovero' incastrato in un vendor lock-in ?- Il padrone di questa tecnologia la usera' come strumento di forza per scalzarmi se la mia nicchia di mercato diventasse importante ?- Sto facendo un investimento su di me o su qualcun altro ?Uscendo dal discorso java per evitare altri flame: qualche anno fa avessi dovuto fare partire un progetto importante come backend SQL avrei scelto MySQL; oggi sceglierei Postgres.Se l'unico o il prevalente criterio di scelta di una tecnologia dovesse essere "quello che fa il mondo" o "quanto facilmente trovo della gente che ci sa lavorare"... lo sviluppo (almeno in ambito business) si farebbe solo, ahime, con .NET.A.-----------------------------------------------------------Modificato dall' autore il 01 agosto 2011 19.04-----------------------------------------------------------
  • FDG scrive:
    Re: Uhllalla... ho toccato una setta :)
    - Scritto da: Pinco Pallino
    Aho,

    credevo sti fenomeni di fanatisco esistessero
    solo tra tifosi di calcio, adepti di Scientology
    o fanatici
    Apple/Microsoft/AntiApple/GNu/etc.Il problema è che tu sei partito da una posizione pregiudiziale nei confronti di uno strumento. Sei tu che hai iniziato una guerra di religione. Chi ti ha risposto ti ha fatto notare quanto invece il linguaggio trovasse campi d'applicazione più che validi. E poi hai fatto un confronto esplicito col C++. Anche questo linguaggio ha limiti e campi d'applicazione. È un discorso generale che tu hai applicato solo per la tua retorica. Quindi, smettila di rigirare la frittata. Hai scritto una provocazione e basta.Riguardo alla capacità di riciclarsi e di offrire professionalità, non credo dipenda dagli strumenti che si usano, più da altri fattori. Ad esempio, io includerei la capacità di esprimere giudizi equilibrati.
  • poiuy scrive:
    Re: Uhllalla... ho toccato una setta :)
    Mi permetto di dissentire su alcune cose."ma se dovessi scrivere una interfaccia utente partendo da zero *OGGI* la scriverei in JavaScript e la fare girare in un browser"Mai sentito parlare di GWT? Scrivi in Java e compili in Javascript. No non è stato fatto per il motivo che pensi tu (incapacità dei programmatori di usare un altro linguaggio). Un codice scritto in Javascript è poco manutenibile e più il progetto si amplia e più le cose peggiorano. Questo costa e tanto.No, se parti "*OGGI*", usi GWT."se dovessi scrivere un *server*.." Mai sentito parlare di JBOSS? Se scrivi in server, lo scrivi in Java per buone ragioni. Se scrivi un serverino che serve solo a te, scrivile con quello che ti pare. In Java fai prima.Tra l'altro sempre Google offre soluzioni in Java (e non solo) che sono scalabili al massimo. In pratica se segui la loro filosofia (e le loro restrizioni) hai un applicativo che può lavorare indifferentemente con 1 persona o con tutta l'umanità. E google probabilmente ne sa più di te.Passiamo alla ridefinizione degli operatori con un esempio banale:A, B e C sono matrici. Senza passare da trasformate di Fourier o quant'altro:se scrivo A = B + C ridefinendo l'operatore + per la classe matrice... il risultato dove lo metto? in A, B o C?Se lo metto in A, ho fatto una new non necessaria che porterebbe il programma a richiedere troppa memora con matrici grandi.Se metto il risultato in B o in C vado ad alterare matrici che non dovrei toccare.E' meglio quindi rinunciare a ridefinire gli operatori (che tra l'altro può essere elegante, ma sicuramente NON NECESSARIO) e usare delle classi e dei metodi con nomi espliciti.Per quanto riguarda il calcolo scientifico mi sembra di ricordare un nome... Matlab... che dimostra che anche in questo caso il liguaggio scelto dipende dalle esigenze e non dall'ambito.Alcuni criticano Java dicendo che non è un linguaggio ad oggetti puro. E' vero, ma affinchè sia una critica ci dovresti spiegare perché dovrebbe esserlo.Infine analizziamo le performance:http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf.htmlhttp://keithlea.com/javabench/Un giorno scoprirete che Java non è interpretato... forse.
    • Pinco Pallino scrive:
      Re: Uhllalla... ho toccato una setta :)
      - Scritto da: poiuy
      A, B e C sono matrici. Senza passare da
      trasformate di Fourier o
      quant'altro:
      se scrivo A = B + C ridefinendo l'operatore + per
      la classe matrice... il risultato dove lo metto?
      in A, B o
      C?L'esempio mi ha fatto ricordare un'altra cosa di java della quale non capisco la ragione: l'assenza della const-correctness esplicita.Forse per questo in molti linguaggi esistono i tipo "const reference".L'operatore "+" non modifica l'lvalue e restituisce una reference a un nuovo oggetto (che viene assegnata atomicamente all'oggetto a), l'operatore "+=" somma in place. Sono due cose diverse.Questa assenza ha conseguenza anche gravi: immagina che un oggetto contenga una lista di stringhe e che un metodo debba ritornare questa lista, in assenza di una esplicita dichiarazione const ho due scelte: copia la lista e ritornarne la copia (evviva l'efficienza!), oppure restituire l'oggetto lista che dovrebbe essere "nascosto" nell'oggetto e non modificabile da fuori (evviva l'incapsulamento).Anche in questo non e' che C++ sia perfetto (devo per forza fare un getter che mi restiuisce una "const std::list <std::string
      &", sintatticamente sarebbe molto piu' pulito, nella mia opinione, avere una dichiarazione di visibilita' decicata che dice "questo attributo e' accessibile dall'interfaccia in read only").Non critico Java per non essere un linguaggio ad oggetti "puro", come ho detto i linguaggi ad oggetti puri hanno probabilmente poca utilita' pratica (l'ultimo che ho visto era appunto SmallTalk).Java fa delle scelte che non lo rendono un puro linguaggio OOP, C++ ne fa altre che hanno lo stesso effetto da questo punto di vista. Le scelte di C++ le capisco perche' giustificate dal voler avere un linguaggio comunque "compilabile" (analoghe furono le scelte fatte da oggetti come Dylan, Ada90, eccetera), quelle di Java non le capisco, that's it.A.
      • poiuy scrive:
        Re: Uhllalla... ho toccato una setta :)
        "Questa assenza ha conseguenza anche gravi: immagina che un oggetto contenga una lista di stringhe e che un metodo debba ritornare questa lista, in assenza di una esplicita dichiarazione const ho due scelte: copia la lista e ritornarne la copia (evviva l'efficienza!), oppure restituire l'oggetto lista che dovrebbe essere "nascosto" nell'oggetto e non modificabile da fuori (evviva l'incapsulamento)."In questo esempio specifico puoi procedere in vari modi:ritorni un iteratore (e quindi non puoi modificare i valori, il remove dell'iteratore può essere inibito).Oppure wrappi la lista e ritorni una lista non modificabile (esistendo l'interfaccia sia List che Collection puoi wrappare senza problemi). Non server crearsi il wrapper, ci sono i metodi di Collections." sintatticamente sarebbe molto piu' pulito, nella mia opinione, avere una dichiarazione di visibilita' decicata che dice "questo attributo e' accessibile dall'interfaccia in read only"In java esiste la parola chiave final che tra le altre cose fa anche questo. Se scrivo "static final String MY_CONSTANT = "PIPPO"" questa è una stringa leggibile da tutti ma non modificabile.Il problema di final è che rende immodificabile il riferimento. Quindi se rendo final una Collection (List se vuoi) in realtà la posso modificare, ma non posso assegnare al riferimento una altra collection.Per quanto riguarda l'esempio delle matrici, quello che ti è sfuggito è che allocare una nuova matrice A solo per fare A = B + C è pericoloso (oserei dire concettualmente scorretto). Le matrici possono essere molto grosse e per fare i calcoli potrei aver bisogno solo di una matrice di appoggio. Per cui è molto meglio qualcosa tipo MatrixOperations.sum(A,B,Result) dove Result può essere utilizzata per tutte le operazioni di cui ho bisogno.Questo caso mostra come la ridefinizione di "+" sembra una buona idea, ma non lo è.Le scelte del C++ sono in linea con la filosofia: posso fare tutto (compreso quello che non dovrei fare). La fiolosofia Java è: non puoi fare alcune cose, perché non devi. Ecco perché volutamente non c'è l'ereditarietà multipla, la ridefinizione degli operatori, la garbage collection e altre cosette. Perché questa è la loro proposta di come si programma.In pratica hanno ritenuto che alcune cose permesse dal C++ portassero a più danni che benefici. La ridefinizione degli operatori porta più danni che benefici. Stessa cosa per l'ereditarietà multipla.
        • Pinco Pallino scrive:
          Re: Uhllalla... ho toccato una setta :)
          - Scritto da: poiuy
          In java esiste la parola chiave final che tra le
          altre cose fa anche questo. Se scrivo "static
          final String MY_CONSTANT = "PIPPO"" questa è una
          stringa leggibile da tutti ma non
          modificabile.On oggetto dichiarato final non lo modifichi nemmeno nella classe stessa, e' un concetto diverso da fare un "cast a const" (che non e' un cast, e' solo "questa e' un'ombra del mio oggetto che e' read only").
          Per quanto riguarda l'esempio delle matrici,
          quello che ti è sfuggito è che allocare una nuova
          matrice A solo per fare A = B + C è pericoloso
          (oserei dire concettualmente scorretto). Se quello che vuoi fare e' la somma di B+C e mettere il risultato in un altro oggetto che e' A non e' ne pericoloso ne scorretto: e' l'unico modo.Se quello che vuoi fare e' fare la somma in place: A += B.
          Questo caso mostra come la ridefinizione di "+"
          sembra una buona idea, ma non lo
          è.No, se rispetti la semantica. Certo se non la rispetti (come con qualsiasi overload, non solo degli operatori).Fatto sta che l'overloadability degli operatori non e' un fatto a se stante, e' semplicemente consistenza OO: un operatore e' un metodo come gli altri.
          Le scelte del C++ sono in linea con la filosofia:
          posso fare tutto (compreso quello che non dovrei
          fare). Questo e' vero solo per chi programma in C usando un compilatore C++.Anche in Java puoi essere cosi' cane da lasciare tutto public, mettere tutti i metodi in una classe e magari la maggior parte delle variabili membro nella classe stessa: otterrai quello che fa chi sta provando la prima volta a scrivere un programma in C o Pascal (lasciando piu' roba possibile nel namespace globale).Nessun linguaggio di programmazione puo' difendere il programmatore da se stesso :)
          La fiolosofia Java è: non puoi fare alcune
          cose, perché non devi. Ecco perché volutamente
          non c'è l'ereditarietà multipla, la ridefinizione
          degli operatori, la garbage collection e altre
          cosette. Perché questa è la loro proposta di come
          si
          programma.Ok, e questione di opinioni.
          In pratica hanno ritenuto che alcune cose
          permesse dal C++ portassero a più danni che
          benefici. La ridefinizione degli operatori porta
          più danni che benefici. Stessa cosa per
          l'ereditarietà
          multipla.De gustibus.... a me continua a non piacere.(Che poi sia chiaro: ci sono cose di Java che mi piacciono tantissimo come i costruttori che possono chiamarsi in cascata, la gestione delle eccezioni che e' sintatticamente pulitissima e altro...).A.
          • poiuy scrive:
            Re: Uhllalla... ho toccato una setta :)
            "No, se rispetti la semantica. Certo se non la rispetti (come con qualsiasi overload, non solo degli operatori).Fatto sta che l'overloadability degli operatori non e' un fatto a se stante, e' semplicemente consistenza OO: un operatore e' un metodo come gli altri."Niente di più sbagliato.Per fare la somma tra A e B non serve assolutamente allocare memoria. Puoi usare un buffer. E di sicuro non vuoi scrivere in A.Ergo A = B + C con overloading dell'operatore '+' può portare a scrivere formule carine e che mangino una marea di memoria.Né l'operatore '+' né l'operatore '+=' portano a scrivere su un buffer il risultato della somma tra A e B. Certo puoi copiare in C (buffer) A e poi fare C += B. A questo punto perché non fare allora dei metodi espliciti che dicono quello che fanno?A questo punto vedo come è facile cadere in tentazione scrivendo C = A + B invece che qualcosa del tipo: MatrixOperations.sum(A,B,C).Con una piccola differenza, che se lo fai con l'ultima versione non allochi alcuna memoria per fare l'operazione di somma.Se hai una sommatoria, con la seconda versione usi solo la memoria già allocata, con l'overloading hai bisogno di una ulteriore matrice ad ogni somma. Se A e B sono matrici grosse, le formule che scriveresti con l'overload rischiano di occupare troppa memoria.
          • Pinco Pallino scrive:
            Re: Uhllalla... ho toccato una setta :)
            - Scritto da: poiuy
            Per fare la somma tra A e B non serve
            assolutamente allocare memoria.Ti garantisco che se vuoi fare una operazione tra due oggetti di un tipo X e il risultato (anche esso di tipo X) non deve sovrascrivere uno dei due oggetti ti serve della memoria per salvare il risultato.Che poi questa memoria sia statica, sia sullo stack o sia nello heap... da qualche parte il risultato lo devi mettere.Se invece credi che gli "oggetti" possano solo essere nello heap, i "buffer" e i tipi nativi solo sullo stack... eccetera... credo che tu dia per scontate delle cose che appartengono solo a Java, non al resto del mondo.#include <complex
            void cippalippa(const complex &a, const complex &b){ complex c = a+b; std::cout << c << std::endl;}... pregasi compilare e cercare nel codice assmebler una chiamata a malloc :)A.
          • poiuy scrive:
            Re: Uhllalla... ho toccato una setta :)
            "Ti garantisco che se vuoi fare una operazione tra due oggetti di un tipo X e il risultato (anche esso di tipo X) non deve sovrascrivere uno dei due oggetti ti serve della memoria per salvare il risultato."Ti garantisco che se vuoi fare 10 operazioni tra 2 oggetti di tipo X, non ti serve allocare 10 volte la memoria per il risultato.Cosa che non puoi fare con l'overloading degli operatori.
          • Pinco Pallino scrive:
            Re: Uhllalla... ho toccato una setta :)
            - Scritto da: poiuy
            Ti garantisco che se vuoi fare 10 operazioni tra
            2 oggetti di tipo X, non ti serve allocare 10
            volte la memoria per il
            risultato.
            Cosa che non puoi fare con l'overloading degli
            operatori.Sono certo che conosci molto bene i compilatori di tutti i linguaggi che consentono l'overload degli operatori per affermarlo.Nel mio deve esserci un bug:#include <complex
            #include <vector
            double cippa2(std::vector <std::complex<double

            &a){std::complex <double
            tmp(0.0, 0.0);for(std::vector <std::complex<double

            ::const_iterator i=a.begin(); i != a.end(); ++i)tmp = tmp + *i;return arg(tmp);}... l'ho chiamata con un vettore di 100000 elementi sotto dtrace e nada de nada... non mi ha fatto nessun malloc().Inutile dire che comunque e' scritta da cane, la forma sensata sarebbe stata tmp += *i; (che e' un altro operatore overloaded).A.
          • poiuy scrive:
            Re: Uhllalla... ho toccato una setta :)
            E quando fai tmp = tmp + *i; cosa pensi che succeda?Chiedi allo stack lo spazio per una ulteriore tmp. Questo non è necessario.E se tmp invece di occupare poca memoria, ne occupa tanta?il comando malloc() non c'entra niente. Quello serve per chiedere memoria all'heap.Non a caso ho parlati di matrici. E più volte ho specificato di grandi dimensioni.
          • poiuy scrive:
            Re: Uhllalla... ho toccato una setta :)
            Ti rispondo più precisamente, altrimenti non ci intendiamo.Se A e B sono matrici di grandi dimensioni, nello stack non ci stanno.Non solo: se A entra di poco nello stack, A + B fallisce perché non c'è abbastanza memoria.Fare C = A + B implica cadere in questa limitazione.Non che sia un grosso problema da risolvere. Rimane dubbia però l'utilità di aver ridefinito il "+" sulle matrici, quando è sconsigliabile usarlo.
          • Pinco Pallino scrive:
            Re: Uhllalla... ho toccato una setta :)
            Non mi metto a scriverti un altro esempio, mi limito a dire una cosa: credimi, conosco GCC e il c++ molto, molto, molto bene.E' facile che una mia affermazione su Java sia sbagliata, e' improbabile che mi sbagli su GCC/c++.a) Puoi usare l'overloading degli operatori anche con l'oggetto risultato nello heap, scrivendo esattamente a=b+c; l'ottimizzatore su c++ puo' fare miracoli (molte cose che sul C, ad esempio, non riesce a fare).b) Se davvero vuoi fare una somma incrementale su una serie di matrici e' abbastanza evidente che saresti un cane a fare una serie di "tmp = X + tmp;", qualsiasi programmatore dignitoso farebbe "tmp += X;".Anche se tu avessi ragione il concetto che "Un costrutto se usato male o in un contesto specifico puo' essere inefficiente" non e' un buon motivo per non avere quel costrutto. Altrimenti dovremmo non avere le strutture dati dinamiche perche' se usate male possono portare al trashing delle memoria; non dovremmo avere i cicli perche' se usati male possono portare a scrivere programmi O(2^n), eccetera.Non sono un programmatore in senso stretto, faccio ricerca e specificamente sviluppo e ottimizzazione di algoritmi decisamente complessi e decisamente "onerosi" dal punto di vista computazionale, ogni tanto mi capita di scrivere qualche decina di migliaia di righe di codice e cose come l'overloading degli operatori alleggeriscono la sintassi un bel po' (se usati correttamente), cose come i template cambiano la vita per quello che riesce a fare l'ottimizzazione del codice, cose come il binding ibrido idem.In se l'overload di un operatore non e' nulla, e' semplicemente syntactic sugar per una funzione. L'operatore "+" e' una funzione che prende due parametri di un certo tipo come "const reference" e restituisce un risultato dello stesso tipo; l'operatore += prende un parametro "reference" (scrivibile) e uno const e restituisce una referenza. No more and no less.Ora se ti impunti su uno specifico operatore che per semantica abituale prende due parametri di un tipo "read only" e restituisce un risultato ti sembra "ritornare un risultato da una funzione" comporti necessariamente l'allocazione di memoria da qualche parte: non stai pero' tenendo conto del fatto che qualsiasi libreria C++ dignitosa e' fatta tutta di template e che il compilatore avra' modo di rimuovere quasi sempre queste allocazioni/deallocazioni; anche se il programmatore e' stato cosi' cane da scivere la funzione come nell'esempio che ti ho postato.C'e una cosa giusta in quello che dici: la "sintassi comoda" puo' portare un programmatore che viene da un mondo diverso a dare per scontate cose che scontate non sono: "Una addizione e' una banale operazione atomica tra tipi primitivi... mica costera' tanto". Invece no, in un mondo a oggetti una addizione e' una chiamata alla funzione "+".Ma di nuovo: nessun linguaggio puo' proteggere un programmatore da se stesso.Ciao,A.-----------------------------------------------------------Modificato dall' autore il 02 agosto 2011 18.16-----------------------------------------------------------
          • poiuy scrive:
            Re: Uhllalla... ho toccato una setta :)
            Ok su questa ultima parte concordiamo.E qui si torna alla filosofia Java: con l'overload degli operatori puoi fare danno. A = B + C nel caso di matrici è un caso naturale. Ciononostante ha volendo delle controindicazioni (facili da superare e come dici tu le librerie sono fatte bene di solito).Ecco qui 2 filosofie che devono esistere entrambe: da una parte Java che dice, non lo puoi fare con me, dall'altra il C che dice, a te la potenza e la responsabilità.Detto questo concordo con ciò che scrivi ed è anche vero che "l'ottimizzatore su c++ puo' fare miracoli" quindi spesso bastano buone regole di programmazione, e si lascia il resto al compilatore.
          • Pinco Pallino scrive:
            Re: Uhllalla... ho toccato una setta :)
            - Scritto da: poiuy
            Ecco qui 2 filosofie che devono esistere
            entrambe: da una parte Java che dice, non lo puoi
            fare con me, dall'altra il C che dice, a te la
            potenza e la
            responsabilità.Solo una nota... C e C++ non hanno praticamente niente a che fare l'uno con l'altro... infatti i peggiori programmatori C++ sono quelli che arrivano dal C (io ci misi anni a disintossicarmi :) ).Picoli dettagli magari, un "++i" invece che un "i++" (il secondo puo' obbligare il compilatore, se non ha visibilita' sull'implementazione dell'operatore ++ per la classe di i a... CREARE UN OGGETTO! :-) ).A:A.
      • poiuy scrive:
        Re: Uhllalla... ho toccato una setta :)
        Anche in questo non e' che C++ sia perfetto (devo per forza fare un getter che mi restiuisce una "const std::list <std::string
        &",Ora non sono sicuro di quello che scriverò, ma penso che il tuo esempio sia fuorviante:se invece di avere string dentro quella lista, ho degli oggetti che al suo interno hanno dei set?Ossia, ma mi potrei sbagliare, li hai dichiarato costante la lista, non ciò che contiene. In pratica non puoi modificare il contenitore, ma puoi alterare il contenuto.
        • Pinco Pallino scrive:
          Re: Uhllalla... ho toccato una setta :)
          - Scritto da: poiuy
          Ossia, ma mi potrei sbagliare, li hai dichiarato
          costante la lista, non ciò che contiene. In
          pratica non puoi modificare il contenitore, ma
          puoi alterare il
          contenuto.No, non puoi, quando dereferenzi in qualsiasi modo un contenitore "const" ottieni referenze const.Se X e' un vector <int
          X[1] e' un "int &", se Y e' un "const vector <int
          " Y[1] e' un "const int&".Vero e' che l'uso corretto della const correctness in C++ e' un po' ostico e questo fa si che molti programmatori se ne freghino e non dichiarino mai niente const, ad esempio se Z e' una "const map <string, string
          " non puoi nemmeno leggere Z["pippo"] perche' il metodo [](string) potrebbe potenzialmente creare l'entry "pippo" se non esiste.Tanto e' per dire che anche C++ e' lungi dall'essere perfetto e per spiegare a chi dovesse pensare che volevo aprire una flame "C++ vs java" non ha capito un pippero di quel che intendevo dire, l'ho usato come esempio solo per spiegare alcune scelte di progetto per le quali Java a me (personalmente) non piace.Similmente il dire che "Java in mano ad Oracle e' morto" non era per augurare a nessuno di morire di fame, anzi: era una triste constatazione. Se il C fosse "di fatto non uno standard aperto" e fosse finito in mano a Oracle (o a Apple, o a Microsoft, o a SAP) avrei detto "Il C e' morto, e con lui tutto quello che su esso e' stato sviluppato, Linux compreso".Ciao,A.
  • Pinco Pallino scrive:
    Non ho mai amato Java...
    Le inefficienze della pseudocompilazioneGli obrobri del linguaggio in se (dov'e' l'ereditarieta' multipla? e i template? e il binding ibrido?)La falsa portabilita' (se un programma non ha bisogno di una GUI lo scrivi in C++ ISO usando solo STL ed e' la cosa piu' portabile del mondo, se ha bisogno di una GUI la *vera* portabilita' te la scordi)Il fatto che non esistano implementazioni veramente openIl fatto che non sia uno standard vendor-independentAdesso che e' in mano a Oracle poi diciamocelo: Java e' morto. Non lo sa e cammina ancora ma e' uno zombie, dategli quattro anni di tempo e si decompone.A.-----------------------------------------------------------Modificato dall' autore il 30 luglio 2011 18.43-----------------------------------------------------------
    • FDG scrive:
      Re: Non ho mai amato Java...
      - Scritto da: Pinco Pallino
      ...Beh, che dire, io non ho mai amato il c++ perché è un finto linguaggio di programmazione ad oggetti; non ha un runtime che si possa dire tale e che di fatto lo rende un linguaggio statico, cosa che ne limita molto le possibilità (prova a fare inspection sugli oggetti C); è abbastanza facile rompere la compatibilità binaria modificando le interfacce delle classi; eredita dal C molte caratteristiche primitive che avevano senso nei primi anni '70.Potrei continuare. Però, ciò che conta è e quello che scegli è uno strumento adatto al lavoro che fai. E questo può esserlo il c++ come Java. E java se java è uno dei linguaggi più usati al mondo (informati meglio la prossima volta) vuol dire che in molti lo hanno preferito.
      • Andreabont scrive:
        Re: Non ho mai amato Java...
        Un linguaggio ha due vite, quella di mercato, dove il Java è più vivo che mai, e quella tecnologica, dove è morto ormai da tempo.Il mercato arriva in ritardo, quindi mi aspetto di sentire parlare del Java ancora per molti anni... ciò non toglie che sia un linguaggio tecnologicamente obsoleto.Le alternative esistono, basta usarle.
        • Stefano L. scrive:
          Re: Non ho mai amato Java...

          Le alternative esistono, basta usarle.Per esempio ?
        • FDG scrive:
          Re: Non ho mai amato Java...
          - Scritto da: Andreabont
          Un linguaggio ha due vite, quella di mercato,
          dove il Java è più vivo che mai, e quella
          tecnologica, dove è morto ormai da tempo.Beh, lo sviluppo del linguaggio è normale che ad un certo punto si stabilizzi. Le idee alla base di Java sono quelle e nessuna evoluzione le può modificare.
          ciò non toglie che sia un linguaggio
          tecnologicamente obsoleto.

          Le alternative esistono, basta usarle.A quali ti riferisci?
    • Javista scrive:
      Re: Non ho mai amato Java...
      Certo Java non é perfetto. Peró se sono riusciti a farci applicazioni potenti e ben strutturate tanto schifo non fa. Se la maggior parte del software che costituisce il backend delle aziende é stato scritto in Java un motivo c'é.Non mi preoccupano i troll che danno Java per morto. Primo perché conosco altri linguaggi di programmazione, secondo perché so quanto sofware e quanto lavoro basato su Java sta andando avanti ancora oggi e terzo perché il COBOL era stato dato per morto all'inizio degli anni ottanta eppure sta ancora in circolazione.Scommetto che non ti interessa sapere che anche Microsoft si é dovuta arrendere. Per attirare clienti nei servizi cloud di Azure ha dovuto migliorare il supporto di Java e ha introdotto Hadoop.Forse veramente Java morirá nei prossimi anni, ma le aziende per sostituirlo stanno considerando Scala, Groovy e altri linguaggi. Non certo C++. Da come parli mi sa che rischi piú te di rimanere senza lavoro in quanto obsoleto che Java di sparire dalla circolazione.http://www.corp-corp.com/it-jobs-trend-2011Q1.aspx
      • jfk scrive:
        Re: Non ho mai amato Java...
        - Scritto da: Javista
        e terzo perché il COBOL era stato
        dato per morto all'inizio degli anni ottanta
        eppure sta ancora in
        circolazione.E rimarra' vivo e vegeto per moltissimo tempo ancora :-)
        • Javista scrive:
          Re: Non ho mai amato Java...


          E rimarra' vivo e vegeto per moltissimo tempo
          ancora
          :-)Non esageriamo. Magari trovi ancora lavoro con il COBOL, ma ti fai due palle grandi come una casa a forza di fare manutenzione.
      • .poz scrive:
        Re: Non ho mai amato Java...
        - Scritto da: Javista
        Certo Java non é perfetto. Peró se sono
        riusciti a farci applicazioni potenti e ben
        strutturate tanto schifo non fa. Lasciamo perdere. E' da anni che mi scontro con applicazioni java sul lavoro. E' da poco che il tipico pc aziendale riesce a far girare queste applicazioni in modo semidecente. E dato che tipicamente il parco macchine di un azienda è costituito da pc con windows non si capisce la necessita di utilizzare un linguaggio multi piattaforma.Java ha senso sui cellulari, java a senso sul web ma un' applicazione di contabilità aziendale in java è una emerita XXXXXXX sia 15 anni fà quando per farla girare semidecentemente serviva un pc super, sia oggi.
        • Javista scrive:
          Re: Non ho mai amato Java...

          Lasciamo perdere. E' da anni che mi scontro con
          applicazioni java sul lavoro. E' da poco che il
          tipico pc aziendale riesce a far girare queste
          applicazioni in modo semidecente. E dato che
          tipicamente il parco macchine di un azienda è
          costituito da pc con windows non si capisce la
          necessita di utilizzare un linguaggio multi
          piattaforma.
          I software SAP funzionano da anni, cosí come eclipse. Se il tuo capo compra le applicazioni dall'azienda pizza e fichi non te la puoi prendere con Java.
          Java ha senso sui cellulari, java a senso sul web
          ma un' applicazione di contabilità aziendale in
          java è una emerita XXXXXXX sia 15 anni fà quando
          per farla girare semidecentemente serviva un pc
          super, sia
          oggi.Anche il pizzicagnolo adesso é capace di mettersi su un server Linux in una rete windows risparmiando parecchio. Se tu non ne sei capace non ti lamentare.
          • Pinco Pallino scrive:
            Re: Non ho mai amato Java...
            - Scritto da: Javista
            I software SAP funzionano da anniUn esempio di usabilita', di friendlyness, di apertura e soprattutto di strategi di difesa dal vendor lock-in :)Gli utenti che usano SAP sono notoriamente molti felici, i CIO lo sono davvero... per i primi 4-5 anni.A.
        • FDG scrive:
          Re: Non ho mai amato Java...
          - Scritto da: .poz
          Java ha senso sui cellulari, java a senso sul web
          ma un' applicazione di contabilità aziendale in
          java è una emerita XXXXXXX sia 15 anni fà quando
          per farla girare semidecentemente serviva un pc
          super, sia oggi.Oggi basta un PC normalissimo. Forse il problema non è lo strumento ma chi lo usa.
      • FDG scrive:
        Re: Non ho mai amato Java...
        - Scritto da: Javista
        Non mi preoccupano i troll che danno Java per
        morto. Primo perché conosco altri linguaggi di
        programmazione, secondo perché so quanto sofware
        e quanto lavoro basato su Java sta andando avanti
        ancora oggi e terzo perché il COBOL era stato
        dato per morto all'inizio degli anni ottanta
        eppure sta ancora in circolazione.Bello che fa i confronti col C++, che è in giro da più tempo di Java :)
        Forse veramente Java morirá nei prossimi
        anni, ma le aziende per sostituirlo stanno
        considerando Scala, Groovy e altri linguaggi. Non
        certo C++.Proprio il C++ avrebbe bisogno di un sostituto ben prima di Java.
    • paoloholzl scrive:
      Re: Non ho mai amato Java...

      Java e' morto. Non lo sa e cammina ancora ma e'
      uno zombie, dategli quattro anni di tempo e si
      decompone.Penso che hai espresso delle considerazioni abbastanza condivisibili.Ma non penso che Java sia morto semplicemente perché molti lo conoscono e lo usano, penso semplicemente che abbia fallito quello che era il suo principale scopo, il 'cross platform'.Perché é fallito? Perché non tutti avevano interesse a renderlo davvero tale sulle proprie piattaforme agevolando l'avversario e quindi mettevano i 'bastoni tra le ruote'. Oggi se davvero vuoi girare ovunque anche in una GUI, php, javascript hanno in pratica risolto i problemi, non usi gli oggetti di sistema ma comunque puoi fare un po tutto un po dappertutto.Chissà cosa succederà con le nuove applicazioni Google...Proprio perché penso che contino più che il linguaggio in se, la capacità di generare i presupposti per la convenienza di farlo girare ovunque.Penso che su questo fronte l'impostazione 'service oriented' di Google abbia delle ottime carte da giocare.Attendere prego ...
      • Javista scrive:
        Re: Non ho mai amato Java...

        Perché dovrebbe essere fallito il cross platform ?
        Ci sono migliaia di applicazioni che puoi
        installare su Unix/Linux o Windows senza
        problemi. Se devi fare dei download diversi é
        solo perché cambia il pacchetto di
        installazione.
        A giá dimenticavo che Java gira anche su
        mainframe.

        Il troll piú sopra si riferiva ad alcune
        estensioni delle swing che non sono cross
        platform. Ma esistono applicazioni swing anche
        complesse che funzionano su diversi sistemi (vedi
        ArgoUML).
        Dimenticavo eclipse e le altre IDE
        • FDG scrive:
          Re: Non ho mai amato Java...
          - Scritto da: Javista
          Dimenticavo eclipse e le altre IDEAzureus/Vuze, JEdit, AptanaStudi, SQLDeveloper, Minecraft...
      • FDG scrive:
        Re: Non ho mai amato Java...
        - Scritto da: paoloholzl
        Perché é fallito? A parte che esistono molte applicazioni desktop fatte in java, nei front-end web e nei back-end lo trovi dovunque. Forse il fallimento di cui si ciancia tanto è nel non esser riuscito a spodestare MS dai desktop. Ma chi se ne frega!
        • Pinco Pallino scrive:
          Re: Non ho mai amato Java...
          - Scritto da: FDG
          A parte che esistono molte applicazioni desktop
          fatte in java, nei front-end web e nei back-end
          lo trovi dovunque. Forse il fallimento di cui si
          ciancia tanto è nel non esser riuscito a
          spodestare MS dai desktop. Ma chi se ne
          frega!No,il fallimento e' nel non aver considerato nell'idea iniziale che un programma e' fatto di due cose: una logica e una interfaccia.Sulla logica la portabilita' la ottieni facilmente, sull'interfaccia avere un linguaggio portabile non serve se non hai consistenza del modello di GUI.Tanto per fare un esempio... SapGUI, client si SAP scritto in java. Gira correttamente su Windows, Linux e OSX.Su tutte e tre le piattaforme e' uan delle cose piu' brutte, meno usabili e piu' antipatiche con cui gli utenti abbiano avuto a che fare.Senza andare dietro ad altre guerricciole, francamente: Se uso un Macintosh voglio un'interfaccia che sia nella grafica, negli oggetti, nel comportamento dei controlli, nella struttura e financo negli shortcut da tastiera quella di una applicazione Mac; IDEM se sono un utente Windows; e idem se uso Linux. Problema: sono diversi tra loro.Se propongo a questi tre utenti la "GUI Java" questi mi sputano in un occhio, e hanno delle ragioni.In questo la "GUI cross platform" vincente, oggi, ... sia chiama Web. Come interfaccia trovo davvero tanto piu' gradevole usare GMail che SapGUI o (tanto per fare altri esempi) l'80% del software scientifico con una GUI scritta in Java. Con la differenza che GMAil non mi chiede di installare la javaVM giusta per partire.Il fallimento di cui si ciancia non e', nella mia opinione, tecnico: e' strategico e fattuale.Strategico perche' si e' voluta garantire la portability dell'interfaccia utente (con quel che ne consegue in termini di impatto), fattual perche' quando metti a un utente un nuovo programma scritto in Java e gli chiedi "che ne pensi dell'interfaccia?" quello qualsiasi piattaforma usi ti dice "e' orribile".A.
    • Giovannino scrive:
      Re: Non ho mai amato Java...
      - Scritto da: Pinco Pallino
      Le inefficienze della pseudocompilazioneChe i linguaggi di recente creazione replicano (bytecode python e bytecode CLR in testa); evidentemente quella che tu chiami pseudo-compilazione nonè esattamente inefficente.
      Gli obrobri del linguaggio in se (dov'e'
      l'ereditarieta' multipla?..Uhm sai a cosa servono le interfacce in java?
      e i template?..Uhm sai a cosa serve la classe Element in java?
      La falsa portabilita' (se un programma non ha
      bisogno di una GUI lo scrivi in C++ ISO usando
      solo STL ed e' la cosa piu' portabile del mondo,
      se ha bisogno di una GUI la *vera* portabilita'
      te la
      scordi)Strano, sai il sistema ERP sviluppato dalla nostra ditta in java funziona (testata), sia la componente server che i client grafici, su Windows, Linux e Solaris.
      Il fatto che non esistano implementazioni
      veramente
      openBeh ... mai sentito parlare di GNU Classpath? e della VM CACAO?
      Il fatto che non sia uno standard
      vendor-independentEd ecco l'unica cosa sensata del tuo discorso!
      Adesso che e' in mano a Oracle poi diciamocelo:
      Java e' morto. Non lo sa e cammina ancora ma e'
      uno zombie, dategli quattro anni di tempo e si
      decompone.Ah le profezie ... mi ricordano quando Bill Gates disse che internet era un fenomeno passeggero....
      • FDG scrive:
        Re: Non ho mai amato Java...
        - Scritto da: Giovannino

        e i template?

        ..Uhm sai a cosa serve la classe Element in java?No, la cosa che in Java ci si avvicina di più ail template C++ sono i generics.
    • il signor rossi scrive:
      Re: Non ho mai amato Java...
      - Scritto da: Pinco Pallino
      Le inefficienze della pseudocompilazione
      Gli obrobri del linguaggio in se (dov'e'
      l'ereditarieta' multipla? e i template? e il
      binding
      ibrido?)l'ereditarietà multipla non serve, è una feature molto bella ma che nel tempo si è dimostrata poco utile, o meglio... crea più problemi di quanti ne risolve e porta a design complicati. Non sono pochi i linguaggi che hanno riunciato a implementarla. In Java, le interfacce vanno benissimo.I template sono effettivamente utili e sono stati introdotti.Binding ibrido? Un'altra delle cose di C++, retaggio del C, di cui è meglio liberarsi. Nei linguaggi object oriented il binding è dinamico, punto. Le inefficienze della pseudocompilazione sono un mito del passato, in quanto a velocità di calcolo pura Java oggi non è così distante dai linguaggi compilati, o comunque sufficientemente veloce per la maggior parte delle esigenze (discorso GUI a parte ovviamente).C++ è un bel linguaggio, ma il suo design ha ormai un bel po' di tempo sulle spalle e ha sempre risentito dell'esigenza della retrocompatibilità col C. Onestamente, se non fosse per le performance, usare C++ è puro masochismo perché è noioso fare anche le cose più elementari come concatenare un paio di stringe perché anche i framework che si trovano in giro sono vecchi e sono ormai passati vent'anni da quando furono progettati.
      La falsa portabilita' (se un programma non ha
      bisogno di una GUI lo scrivi in C++ ISO usando
      solo STL ed e' la cosa piu' portabile del mondo,
      se ha bisogno di una GUI la *vera* portabilita'
      te la scordi)mi chiedo sinceramente che esperienza di sviluppo software tu abbia se pensi di poter scrivere un software usando solo STL! :-) Ok per i progetti di taglia piccola, ma quando inizi a fare qualcosa di più complesso le API di Java toccano praticamente qualunque aspetto dello sviluppo di un software, dalle strutture dati all'elaborazione delle immagini e dell'audio, dalla cifratura dei dati al networking, acXXXXX ai database, programmazione lato server e via dicendo. E sono api per lo più coerenti e basate su pattern noti. Sono proprio le api, più che il linguaggio, ad averne decretato il sucXXXXX. Roba che in c++ oggi sinceramente ti sogni o fai con uno sforzo terribilmente maggiore.
      Il fatto che non esistano implementazioni
      veramente open
      Il fatto che non sia uno standard
      vendor-independentevidentemente è un prodotto molto complesso e diciamocelo, forse non è alla portata della comunità open source perché richede uno sforzo economico consistente.
      Adesso che e' in mano a Oracle poi diciamocelo:
      Java e' morto. Non lo sa e cammina ancora ma e'
      uno zombie, dategli quattro anni di tempo e si
      decompone.Qui bisogna vedere e non ne sarei così sicuro. Ci sono così tante aziende che hanno basato il loro business su Java che qualcuno interessato a mantenerlo, nel caso in cui Oracle si defilasse, si trova.
      • poiuy scrive:
        Re: Non ho mai amato Java...
        Finalmente uno che sa quello che scrive.Aggiungerei che a differenza del C++ java ha la reflection.Per quanto riguarda le prestazioni, quello che sfugge è che dipendono più da come è scritto un programma che dal linguaggio.Infine sopra Java Google ci sta costruendo tantissimo: GWT, Android, App engine.Una domanda: cosa è il binding ibrido?
        • il signor rossi scrive:
          Re: Non ho mai amato Java...
          - Scritto da: poiuy
          Una domanda: cosa è il binding ibrido?Io penso che intendesse la possibilità in c++ di creare oggetti sia sullo stack, per i quali il tipo è sempre quello con il quale sono dichiarati e il binding dei metodi è statico, sia sullo heap (quello creati con la new per intenderci), per i quali il binding dei metodi è dinamico a seconda del tipo runtime.
          • Pinco Pallino scrive:
            Re: Non ho mai amato Java...
            - Scritto da: il signor rossi
            - Scritto da: poiuy


            Una domanda: cosa è il binding ibrido?

            Io penso che intendesse la possibilità in c++ di
            creare oggetti sia sullo stack, per i quali il
            tipo è sempre quello con il quale sono dichiarati
            e il binding dei metodi è statico, sia sullo heap
            (quello creati con la new per intenderci), per i
            quali il binding dei metodi è dinamico a seconda
            del tipo
            runtime.Non esattamente,e' la possibilita' se le informazioni per la risoluzione del dispatch di un metodo sono disponibili a compile time che il dispatch stesso avvenga al momento del link senza che a runtime si debba andare a leggere il tipo di oggetto.In C++ se scrivo:a = b+c;Sto chiamando il metodo operator+(typeof(c)) dell'oggetto b.Se sono tre interi il binding e' statico e di fatto diventa una operazione macchina singola.Se sono tre oggetti di una classe strana in cui l'operatore "+" e' virtuale e il compilatore non puo' sapere a quale delle sottoclassi b apparterra' al momento dell'esecuzione allora il binding e' dinamico (e questo costera' qualche decina di istruzini a runtime).Se sono tre oggetti con tutti gli overload che vogliamo ma il compilatore sa al momento della compilazione qual'e' la classe esatta di b allora funzionera' come nel primo caso: ci sara' una chiamata diretta a un metodo (nessun overload) o piu' probabilmente il metodo verra' espanso inline.Da quel che capisco in Java (correggetemi se sbaglio) esiste una barriera a priori: tipi di dati nativi e operatori fanno solo binding statico; tutto il resto fa binding dinamico (con gestalt a runtime per capire quale metodo chiamare).In realta' il motivo epr cui in Java non puo' essere fatto l'verload degli operatori e' una conseguenza del fatto che il binding sugli oggetti e' sempre dinamico: se si potesse fare l'overload degli operatori anche una semplice addizione tra interi richiederebbe la risoluzione del binding dinamico a runtime.A.
  • iome scrive:
    ma il papa' chi e'?
    quando la mamma si accompagna a molti partner, poi e' sempre difficile dare un cognome al XXXXXXXX...
  • bertuccia scrive:
    don't use Java 7 for anything
    personalmente non mi interessa, comunque lo lascio quihttp://www.lucidimagination.com/blog/2011/07/28/dont-use-java-7-for-anything/
    • vaadin scrive:
      Re: don't use Java 7 for anything
      Non hai aggiunto niente di interessante. Si tratta del bug giá citato nell'articolo. Solr e Lucene vanno in crash perche l'ottimizzazione della VM crea problemi al loro sistema di indicizzazione. Non mi stupisce che una azienda che si basa su quei prodotti dica di non usare Java, spingono perché venga accelerato il lavoro per risolverlo.Gli altri intanto possono benissimo iniziare a provarlo per familiarizzarsi con le nuove funzionalitá
      • FDG scrive:
        Re: don't use Java 7 for anything
        - Scritto da: vaadin
        Gli altri intanto possono benissimo iniziare a
        provarlo per familiarizzarsi con le nuove
        funzionalitáFaccio un paragone: JBoss AS 7: una rivoluzione. Figo! Bello! Ma non mi sognerei mai di proporlo in produzione. M'è bastato poco per accorgermi di un primo bug. Ciò non toglie che continuerò a studiarlo e a sperimentare, in attesa del 7.1.E questo vale per qualsiasi altro strumento software. Se puoi permetterti qualche problema, aggiorna subito. Altrimenti aspetta.
Chiudi i commenti