Perché C# e VB.NET implicano in modo implicito il char * in modo diverso?

Question

Così ho una funzione, scritto in C++, che assomiglia a questo ...

extern "C" __declspec(dllexport) int __stdcall SomeFunction(char *theData) 
{ 
    // stuff 
} 

... e sto usando nel mio progetto attuale (scritto in C#). Ci sono altri progetti che utilizzano questa funzione scritta in VB, guardando in questo modo:

Public Declare Function SomeFunction Lib "MyDLL.dll" _ 
    Alias "_SomeFunction@4" (ByVal theData As String) As Integer 

Così ho provato a scrivere un equivalente in C#, ma ha trovato che utilizzando il tipo di stringa in realtà non funziona per me - la stringa sarebbe torna con gli stessi dati con cui l'ho passato. Ho provato a utilizzare "ref string" invece di passare la stringa per riferimento e ho ricevuto una violazione di accesso alla memoria.

Dopo aver fatto qualche scavo, ho scoperto che questo era la corretta applicazione in C#:

[DllImport("MyDLL.dll", EntryPoint = "_SomeFunction@4")] 
public static extern int SomeFunction(StringBuilder theData); 

Ora so che VB.NET e C# sono molto diverse, ma suppongo che ho sempre dato per scontato che le stringhe sono stringhe . Se una lingua può eseguire il marshalling char* a String implicitamente, perché l'altro non può richiedere una classe diversa del tutto?

(a cura del titolo per chiarezza)

Answer 1

Ora so che VB.NET e C# sono molto diverse, ma suppongo che ho sempre dato per scontato che le stringhe sono stringhe

stringhe sono immutable in .NET. Chiediti perché è possibile che il passaggio di un tipo di dati immutabile ByVal possa modificare il valore. Ciò non accade per le normali funzioni, solo per Declare.

Suppongo che tutto ciò abbia a che fare con il mantenimento della compatibilità con le versioni precedenti di Declare dal classico VB6 che sono state eseguite in questo modo. A mio parere, la pecora nera qui è il codice VB.net piuttosto che il codice C#.

Answer 2

Perché sono diverse lingue. VB.NET può fare moltissime cose che C# non può per molte ragioni. Non vedo il problema ad essere onesto.

Vorrei aggiungere che avresti potuto semplicemente fare ref char [] e avrebbe funzionato. Un problema che vedo è che le convenzioni di chiamata non corrispondono.

Quindi è anche probabile che si sia verificato un errore di eccezione di memoria.

Answer 3

Poiché la stringa è immutabile per cominciare, suppongo che VB in qualche modo esegua la chiamata per consentire al buffer di essere modificato dalla funzione. Forse internamente anche VB sta passando un StringBuilder.

Non sarei sorpreso se si trattasse di una chiamata di progettazione da parte del team VB per rendere le chiamate API più simili a VB6.