Websocket comment ? - page 8

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

Non, ne le supprimez pas, nous en aurons toujours besoin !

(Très bien !) En attendant d'autres instructions ;)
 
Алексей Барбашин:

Puis-je demander, en tant qu'adepte des dièses ? Quel est l'intérêt d'utiliser du code géré plutôt que du code non géré ? Ici, par exemple. Mettre de côté les questions de syntaxe et se concentrer sur les avantages de principe.

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

Eh bien, peu de gens écrivent en langage "pur", et vous utilisez les librairies de Sharp, chez les pros de la même manière. Eh bien je n'insiste pas sur eux, il y a un go compilable, par exemple. Je ne comprends vraiment pas la nécessité de ce rembourrage sous la forme d'une machine virtuelle. Je vois les inconvénients, les avantages ne sont en quelque sorte pas observés. Et même l'idée des petits fabricants, j'aurais opté pour une meilleure java.

 
terminé, tout est assemblé sans erreur
 
Tout fonctionne
 
Алексей Барбашин:

Ça ne marche pas comme ça. Le matériel spécifié utilise une technologie différente pour intégrer c# et mql. La technologie ci-dessus met en œuvre une bibliothèque directement dans la dll qui crée une "couche" entre le code géré et le code non géré, sinon sharp ne pourrait pas communiquer avec sql. Mais les développeurs ont fait un excellent travail et maintenant les bibliothèques pointues peuvent s'intégrer dans mql de manière native, vous n'avez même pas besoin de déclarer l'exportation de procédures, tout "s'adapte" comme natif, comme Fedor et moi l'avons montré. Quant aux structures, il faut s'en occuper. Selon ce que Fedor veut faire, nous devrons retourner les structures de données de la dll. Bien sûr, on peut se faire avoir par la cartographie, mais j'espère vraiment que tout s'arrangera sans tracas supplémentaire.

J'ai proposé de vérifier l'exemple - cela n'a pas fonctionné, MQL5 ne voit pas les types personnalisés.

Il ne s'agit pas d'une question de technologie. MQL5 a commencé à supporter .Net "out of the box" dans la seconde moitié de l'année dernière - tout le monde le sait ;)

Vict :

Je ne comprends vraiment pas la nécessité de ce rembourrage sous la forme d'une machine virtuelle. Je vois les inconvénients, je ne vois pas les avantages en quelque sorte. Et c'est l'idée de Smallmacs, je préfère la Java.

il y a beaucoup de bibliothèques prêtes à l'emploi.... certaines bibliothèques utilisent des bibliothèques - en revanche, .Net vous permet d'envelopper une .dll en C++ dans un seul fichier exécutable.

Je fais des tests de performance, et je lis que le C# est souvent proche de la vitesse du C++ (environ 5-10% de gain), donc ce n'est pas deux fois plus que le C++.

En outre, C# est un langage très simple, bien que jusqu'à un certain niveau - le niveau où vous prenez un paquet prêt à l'emploi et y attachez une interface utilisateur - littéralement, en 2 clics, mais pour mettre au point des bibliothèques prêtes à l'emploi, pour les connecter avec d'autres bibliothèques - c'est une maison complète)))).

la facilité d'utilisation et la rapidité d'écriture sont des atouts majeurs, selon moi.

SZZ : Je vais ajouter Wolfram à C# dans une semaine - par expérience, je sais que dans une semaine j'obtiendrai un résultat, j'ai regardé Wolfram C# - tout est standard, comme partout ailleurs avec les paquets C#.

 
Igor Makanu:

J'ai fait des tests de performance et j'ai lu, C# est souvent autour de la vitesse de C++ (environ 5-10% de gain), c'est-à-dire que nous ne parlons pas d'une double supériorité de C++.

Eh bien, cela dépend de la façon dont vous comptez. Par exemple, si nous mesurons la vitesse d'exécution d'un algorithme avec un seul thread, nous obtenons pratiquement les mêmes chiffres. Mais ici, nous ne mentionnons pas que N-nombre de cœurs ont été engagés dans la compilation à la volée, nous ne disons rien sur le temps de lancement et la consommation de mémoire. C'est comme avec Elbrus, pendant qu'un noyau exécute des instructions, un autre noyau s'occupe de la traduction.

C# est un langage très simple, mais jusqu'à un certain niveau - jusqu'au niveau où l'on peut prendre un paquet prêt à l'emploi et y ajouter une interface utilisateur, littéralement en 2 clics,

Eh bien, si vous écrivez un gui en winapi pur, peut-être. Mais cela pourrait être plus simple, n'est-il pas difficile de faire une fenêtre avec un bouton et un handler (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();
}
 

Cool ! Le xml vient-il à nous ?


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

Victor, pas de problème. Chacun a sa propre religion. Mais vous essayez de mettre en œuvre l'exemple que nous créons maintenant en C++ à titre d'exemple. Il serait beaucoup plus facile de le créer en C++. La mise en œuvre de la websocket elle-même en C++ est un véritable gâchis.

Cela peut sembler être un casse-tête, mais il existe une bibliothèque libwebsockets.

J'ai l'impression que souvent l'opinion sur les plus se forme comme ça - la personne ne sait pas comment connecter des bibliothèques prêtes à l'emploi, a vu l'exemple classique de la fenêtre C++ sur du winapi pur, puis voit Sharp avec std-library pour toutes les occasions (ce qui est mauvais à mon avis) et en tire un orgasme. Et les plus, selon lui, restent quelque chose de très ancien et qui prend du temps.

 
Mettre en place
123456789101112131415...27
Nouveau commentaire