[OT] VB6: linguaggio interpretato o compilato?

[XWolverineX]

Ragazzi io sapevo che il Vb6 era un linguaggio compilato.
Arriva uno dice no ti sbagli è interpretato ne sono sicuro al 100 %
Ma come può essere? Coi pacchetti di installazione non mi pare installi un framework o altro, quindi non credo.
Chiedo comunque agli esperti...

[oregon]

Con VB6 puoi effettuare due tipi di compilazione:

1) P-CODE, per cui il codice e' "interpretato" da una virtual machine

2) Codice nativo, per cui il codice e' assembler con chiamate alle librerie di sistema

Chi ti ha informato, non ti ha detto cose precise

[Genius7115]

beh in effetti non è pro puro al 100%. si basa anche sulla vbrun che è una libreria che occorre per far funzionare il programma che a sua volta però è un vero eseguibile.

[oregon]

Il fatto che si basi su librerie non ha alcuna importanza.

Un programma in C, quando esegue una printf, secondo te, cosa fa?

[XWolverineX]

E come mai è disponibile anche il P-CODE? E' piu' veloce? E' piu' facile risalire alle sue sorgenti?

No il mio amico diceva che è sempre e solo interpretato. Io gli ho detto che era impossibile, perchè che interprete utilizza? Con Win98 e XP non è incluso...ma lui ha continuato con le sue ragioni...

[oregon]

Il tuo amico, scusa, non capisce molto di VB.

[alka]

Originariamente inviato da XWolverineX
E come mai è disponibile anche il P-CODE? E' piu' veloce? E' piu' facile risalire alle sue sorgenti?

Presumo che il P-CODE sia disponibile in parte per compatibilità all'indietro, ma anche per dare la possibilità di creare eseguibili di dimensioni ridotte e compatte. Sulla velocità di esecuzione, credo che non si possa definire in modo netto e assoluto se il PCODE sia più rapido o più lento: dipende dalle istruzioni e dalle situazioni, a mio avviso.

Passando all'altro argomento, per quanto ne so, la compilazione nativa genera, come dice il termine, codice "nativo", cioè codice direttamente eseguibile dalla macchina sottostante; poi, che ciò avvenga interfacciandosi con il codice di una DLL di runtime è ininfluente, nel senso che tutt'al più si può sostenere che l'eseguibile non sia autosufficiente per il sistema operativo e che abbia quindi bisogno della libreria di runtime che, comunque, viene sempre richiamata tramite codice nativo.

Forse, a volte, si mescolano questi due fattori generando confusione.

Per fare un esempio parallelo, Delphi produce eseguibili nativi con la possibilità di includere nel file .exe risultante il codice della VCL di supporto creando un eseguibile "standalone", oppure creare un eseguibile che includa le chiamate ai package BPL (una sorta di DLL) che contengono il codice della libreria VCL, ottenendo quindi un eseguibile che non è standalone, poichè necessita di queste librerie, ma è sempre e comunque nativo, come lo è analogamente il file prodotto da VB6 nonostante esso abbia comunque bisogno di colloquiare con la libreria di runtime.

Ciao!

[alka]

Originariamente inviato da oregon
Il tuo amico, scusa, non capisce molto di VB.

Ho questa impressione anche io.

Scherzi a parte, comunque, in questi casi credo basti richiedere una semplice prova tecnica di quanto si afferma, o un riferimento ad un documento online che attesti quanto si dice; in caso contrario, per le argomentazioni simili a quelle del fantomatico amico esiste un solo termine: "congetture".

[oregon]

Condivido quanto detto da alka.

E aggiungo che un programma scritto in C++ che usa le librerie MFC, dovrebbe essere considerato "interpretato" a quanto si dice ...

Giusto ... "congetture" con la B maiuscola ...

[XWolverineX]

Ho spiegato le vostre ragioni e ha detto "Hai ragione, mea culpa"
Grazie!