<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-01-22 11:20 GMT+00:00 Vincenzo Campanella <span dir="ltr"><<a href="mailto:vinz65@gmail.com" target="_blank">vinz65@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Il 22.01.2015 11:39, enrico franchi ha scritto:<span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Dopo di che... non parlerei di codice "scritto in Visual C++". Semplicemente se scrivi codice C++ *standard* che fa uso di una libreria non presente su una certa piattaforma, beh, quel codice non potrai compilarlo su quella piattaforma finche' non trovi quella piattaforma.<br>
</blockquote>
<br></span>
Sarò limitato io, ma non ho mai conosciuto sviluppatori che utilizzassero VC++ e scrivessero codice standard e cross platform; ho conosciuto sviluppatori che scrivono codice cross platform in C e C++, ma nessuno di loro usa VC++, che anzi aborriscono in quanto il codice che genera di default non è esattamente pulito (eufemismo), salvo quando devono scrivere del codice che sicuramente girerà solo su macchine Windows.<br>
Da qui la mia affermazione.<br></blockquote><div><br></div><div>Che appunto e' strana, perche' mette insieme cose che non sono necessariamente correlate. </div><div><br></div><div>Per esempio qui "aborrono VC++ in quanto il codice che genera non e' pulito." Che voglio dire... e' un bel po' che si sa che usare wizard che *generano* codice e' un approccio con enormi problemi e limiti (ma non e' questione di VC++ e' proprio questione dell'approccio). Quindi stiamo parlando dell'IDE. Ma prima usavi il termine per riferirti al linguaggio... e nota bene, puoi scrivere software che compili con cl.exe che usa o non usa tutto l'ambaradan di MFC o altra roba windows only usando o non usando l'IDE. </div><div><br></div><div>Quindi capisci la confusione...</div><div><br></div><div>eravamo ancora ad:</div><div><br></div><div>"""</div><div><span style="font-size:13px">Intendo nel senso che il codice scritto in C/C++ può essere compilato, e quindi eseguito, su qualsiasi sistema operativo abbia un compilatore per quei linguaggi (parlo della totalità o quasi); naturalmente, da questo discorso va escluso codice scritto in Visual C++.</span></div><div>""""</div><div><br></div><div>Ovviamente il problema non e' Visual C++ (inteso come IDE? adesso non vorremo sostenere che sia il programma con cui scrivi a determinare la portabilita' / inteso come "linguaggio"? come dicevo, non ha senso) sono semplicemente le librerie su cui linki. Cioe' se linko ad inotify probabilmente girero' solo su linux. E grazie (oh, poi magari hanno fatto anche qualche port, non ho voglia di controllare ora, sostituire con una qualunque libreria linux only)<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Io comunque VC++ non l'ho mai utilizzato (ho iniziato con C su CodeWarrior, bei tempi che furono...), per cui riferisco per sentito dire (cose cui comunque credo data la storica tendenza di M$ a cercare di creare e imporre degli standard tutti suoi, vedi per esempio la fu macchina virtuale Java di M$ o Internet Exploder per quanto concerne le pagine web).</blockquote><div><br></div><div>Ma no... alla fine solo in tempi recentissimi anche il mondo degli IDE ha cominciato a capire che dovevano staccare l'IDE dalla maggior parte delle cose (per esempio dal build system). Ma sono anni recenti. Ora, io non ho Windows e non saprei dirti, ma in questo caso non tirerei in ballo cospirazioni microsoft... si sono scritti le librerie per il loro OS e se vuoi programmare per quello puoi usare quella roba e fine della storia.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Ma non vedo assolutamente perche'. Questa distinzione e' tutta tua. Ci sarebbe prima di tutto da aprire una piccola parentesi su quanto sia scorretta la pratica comune di parlare di "linguaggi compilati" e "linguaggi interpretati"; per il resto "cross-platform" non e' in relazione con compilazione vs. valutazione. Prova a rifletterci: salta fuori che niente sarebbe cross-platform se fosse come dici e tutto lo sarebbe solo in potenza.<br>
</blockquote>
<br></span>
Guarda che io non ho detto che c'è una correlazione fra l'essere interpretato o compilato e l'essere cross platform.<br></blockquote><div><br></div><div>""""</div><div><div><span style="font-size:13px">Chiaramente però in questo caso parliamo di potenzialità cross-platform, dato che C e C++ sono linguaggi compilati e non interpretati; poi, il fatto che scrivere nativamente un programma cross-platform in C/C++ sia un casino della miseria rispetto a ciò che va fatto in Python o Java, soprattutto per quanto concerne l'interfacciamento ai servizi e alle librerie del sistema operativo su cui deve girare, lo sappiamo tutti... ;-)</span><br style="font-size:13px"></div></div><div><span style="font-size:13px">""""</span></div><div><br></div><div>Allora non capisco come si legge la tua frase sopra che riporto.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Io ho solo detto che C e C++ sono compilati (e su questo non ci piove), </blockquote><div><br></div><div>E come dicevo nella postilla... il concetto di *linguaggio* compilato e' una fallacia diffusa, ma pur sempre una fallacia. Ogni linguaggio puo' essere indifferentemente compilato o interpretato. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">per cui fra la scrittura del codice e la sua esecuzione sul computer (indipendentemente dal sistema operativo) c'è un passo in più rispetto a quello che c'è in Java o Python, fra l'altro non un passo di poco conto. </blockquote><div><br></div><div>Che per inciso sono altri due linguaggi le cui principali implementazioni *compilano* su bytecode (in un caso in modo trasparente, nell'altro no). </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">E su questo penso si possa essere d'accordo.</blockquote><div><br></div><div>Non so quale sia il punto, ma sulle affermazioni, no, non sono molto d'accordo.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Anche qui, ovviamente dipende. Sempre dicendo cose note a tutti: Java e' notoriamente un casino maggiore per quanto concerne l'interfacciamento ai servizi e alle librerie del sistema operativo in tutti i casi in cui suddetti servizi e librerie non sono state ficcate nella JVM o nello standard di Java (o almeno fornite come estensione). Cioe' e' proprio un casino: tra l'altro e' tipicamente anche il caso in cui si rompe di brutto la decantata portabilita' di Java. E chi gliene fa una colpa eh....<br>
<br>
Python ovviamente e' una cosa a simile/dissimile. Da un lato interfacciare Python a servizi e librerie del sistema operativo e' parecchio piu' facile che farlo per Java, se non altro usando CPython (vuoi che scrivere moduli Python in C e' piu' facile che usare JNI) o addirittura grazie a ctypes.<br>
</blockquote>
<br></span>
Qui casca l'asino: in linea di massima la portatilità di Python e Java è sì più immediata rispetto a C/C++, però la loro portatilità è limitata da quanto la macchina virtuale è in grado di fare e ti consente di fare, mentre su C/C++ questo problema non esiste (tant'è che il workaround si basa su C e C++); quindi il tutto dipende sempre da che software devi creare.<br></blockquote><div><br></div><div>Guarda, il problema e' che "portabilita'" e' una parolona e ognuno la usa a modo suo. Non a caso quello che tu sembravi legare al concetto di portabilita' (ovvero interfacciarsi a servizi dell'OS) e' tipicamente quasi l'opposto di quello che normalmente si intende.</div><div><br></div><div> Nota, la questione non e' di lana caprina... e' proprio importante capire cosa si intende. Per esempio Java da garanzie molto piu' forti su un grosso numero di aspetti di basso livello (Python si limita a dire che si appoggia alla libreria C sottostante per molte questioni). Poi ci sono parti della libreria standard di Python che non sono disponibili su tutte le piattaforme.<br></div><div><br></div><div>La stessa questione in C non e' rilevante: la libreria standard e' minimale (e poi ci sarebbe tutto il discorso hosted vs. freestanding), ci sono un sacco di dettagli in piu' e altri in meno. E ci sono standard aggiuntivi (vedi POSIX). </div><div><br></div><div>Sono tutti modelli diversi, bisogna capire cosa si intende.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Comunque, sempre per quanto ne so, comunque, anche in Java è possibile includere moduli scritti in C/C++.</blockquote><div><br></div><div>Si appunto... JNI, gia' menzionato.</div><div><br></div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>