Websocket come? - pagina 8

Nuovo commento
 
Алексей Барбашин:

No, non cancellarlo, ne avremo ancora bisogno!

(Bene!) In attesa di altre istruzioni ))
 
Алексей Барбашин:

Posso chiedere, come esperto di sharps? Che senso ha usare il codice gestito rispetto al codice non gestito? Qui, per esempio. Mettendo da parte cose come la sintassi e concentrandosi sui benefici di principio.

 
Алексей Барбашин:

Beh, poche persone scrivono in un linguaggio "puro", e voi usate le libs di Sharp, nei pro allo stesso modo. Beh, io non insisto su di loro, c'è un go compilabile, per esempio. Non capisco proprio la necessità di questa imbottitura sotto forma di macchina virtuale. Vedo gli svantaggi, i benefici non sono in qualche modo osservati. E anche l'idea dei piccoli creatori, sarei andato per java meglio.

 
finito, tutto assemblato senza errori
 
Tutto funziona
 
Алексей Барбашин:

Non funziona così. Il materiale specificato usa una tecnologia diversa per integrare c# e mql. La tecnologia di cui sopra implementa una libreria direttamente nella dll che crea uno "strato" tra il codice gestito e non gestito, altrimenti sharp non potrebbe comunicare con sql. Ma gli sviluppatori hanno fatto un ottimo lavoro e ora le librerie sharp possono integrarsi in mql in modo nativo, non c'è nemmeno bisogno di dichiarare l'esportazione delle procedure, tutto si "adatta" come nativo, come Fedor e io abbiamo dimostrato. Per quanto riguarda le strutture, devono essere affrontate. Secondo quello che Fedor vuole fare, avremo bisogno di restituire le strutture dati dalla DLL. Naturalmente, possiamo essere incasinati dalla mappatura, ma spero davvero che tutto si risolva senza ulteriori problemi.

Mi sono offerto di controllare l'esempio - non ha funzionato, MQL5 non vede i tipi personalizzati

Non si tratta di tecnologia. MQL5 ha iniziato a supportare .Net "out of the box" nella seconda metà dello scorso anno - lo sanno tutti ;)

Vittoria:

Non capisco proprio la necessità di questa imbottitura sotto forma di macchina virtuale. Vedo gli svantaggi, non vedo i benefici in qualche modo. Ed è l'idea di smallmacs, preferisco andare per java.

ci sono un sacco di biblioteche già pronte.... alcune librerie usano librerie sul lato positivo - .Net permette di avvolgere una .dll in C++ in un singolo file eseguibile

Faccio dei test di performance, e ho letto, C# è spesso vicino alla velocità di C++ (circa 5-10% di guadagno), quindi non è il doppio di C++

Inoltre, C# è un linguaggio molto semplice, anche se fino a un certo livello - il livello in cui hai preso un pacchetto già pronto e gli hai attaccato l'interfaccia utente - letteralmente, in 2 clic, ma per mettere a punto librerie già pronte, per collegarle con altre librerie - questo è un full full)))

l'usabilità generale e la velocità di scrittura sono un grande vantaggio, imho

SZZ: aggiungerò Wolfram a C# in una settimana - per esperienza so che entro una settimana avrò un risultato, ho guardato attraverso Wolfram C# - tutto è standard, come altrove con i pacchetti C#

 
Igor Makanu:

Ho fatto dei test di performance e letto, C# è spesso intorno alla velocità del C++ (circa 5-10% di guadagno), cioè non stiamo parlando di una doppia superiorità del C++

Beh, dipende da come si conta. Per esempio, se misuriamo la velocità di esecuzione di qualche algoritmo con un solo thread, otteniamo quasi le stesse cifre. Ma qui non diciamo che N-numero di core sono stati impegnati nella compilazione on-the-fly, non diciamo nulla sul tempo di lancio e sul consumo di memoria. È come con Elbrus, mentre un core sta eseguendo istruzioni, un altro core è impegnato nella traduzione.

C# è un linguaggio molto semplice, ma fino a un certo livello - fino al livello di prendere un pacchetto già pronto e aggiungervi un'interfaccia utente, letteralmente in 2 clic,

Beh, se si scrive una gui in winapi puro, forse. Ma potrebbe essere più semplice, non è difficile fare una finestra con un pulsante e un gestore (fltk)?

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Button.H>
 
void
button_callback(Fl_Widget* o, void*)
{
        Fl_Button* button = (Fl_Button*) o;
        button->label("Уиииии!");
        button->redraw();
}
 
int
main()
{
        Fl_Window window(300, 200, "Тест.");
        window.begin();
                Fl_Button button(10, 150, 100, 30, "Нажми");
        window.end();
        button.callback(button_callback);
        window.show();
        return Fl::run();
}
 

Fico! L'xml viene da noi?


 
Алексей Барбашин:

Victor, nessun problema. Ognuno ha la sua religione. Ma provate ad implementare l'esempio che stiamo creando ora in C++ come esempio. Quanto sarebbe più facile crearlo in C++? L'implementazione del websocket stesso in C++ è un vero casino.

Questo potrebbe sembrare molto, ma c'è una libreria libwebsockets là fuori.

Ho la sensazione che spesso l'opinione sui plus si forma in questo modo - la persona non sa come collegare le librerie pronte, ha visto il classico esempio di finestra C++ su winapi puro, poi vede Sharp con std-library per tutte le occasioni (che è male secondo me) e ottiene un orgasmo da esso. E i plus a suo avviso rimangono qualcosa di molto vecchio e che richiede tempo.

 
Mettere su
123456789101112131415...27
Nuovo commento