¿Cómo es el Websocket? - página 8

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

No, no lo borres, ¡todavía podemos usarlo!

(¡Muy bien!) A la espera de más instrucciones ))
 
Алексей Барбашин:

¿Puedo preguntar, como adepto a los agudos? ¿Qué sentido tiene utilizar código gestionado en lugar de código no gestionado? Aquí, por ejemplo. Dejando de lado cosas como la sintaxis y centrándonos en los beneficios en principio.

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

Bueno, poca gente escribe en lenguaje "puro", y tú utilizas las librerías de Sharp, en los profesionales de forma similar. Bueno no insisto en ellos, hay un go compilable, por ejemplo. Realmente no entiendo la necesidad de este relleno en forma de máquina virtual. Veo las desventajas, los beneficios no se observan de alguna manera. E incluso la descendencia de los pequeños fabricantes, habría ido por java mejor.

 
terminado, todo ensamblado sin errores
 
Todo funciona
 
Алексей Барбашин:

No funciona así. El material especificado utiliza una tecnología diferente para integrar c# y mql. La tecnología anterior implementa una biblioteca directamente en la dll que crea una "capa" entre el código administrado y el no administrado, de lo contrario sharp no podría comunicarse con sql. Pero los desarrolladores hicieron un gran trabajo y ahora las bibliotecas sharp pueden integrarse en mql de forma nativa, ni siquiera es necesario declarar la exportación de procedimientos, todo "encaja" como nativo, como Fedor y yo hemos demostrado. En cuanto a las estructuras, hay que ocuparse de ellas. De acuerdo con lo que Fedor quiere hacer, necesitaremos devolver las estructuras de datos de la dll. Por supuesto, se nos puede fastidiar el mapeo, pero espero de verdad que todo se solucione sin ningún problema adicional.

Me ofrecí a comprobar el ejemplo - no funcionó, MQL5 no ve los tipos personalizados

No se trata de tecnología. MQL5 empezó a soportar .Net "out of the box" en la segunda mitad del año pasado - todo el mundo lo sabe ;)

Victoreo:

Realmente no entiendo la necesidad de este relleno en forma de máquina virtual. Veo las desventajas, no veo los beneficios de alguna manera. Y lo que es más, la idea de smallmacs, prefiero ir por java.

hay un montón de bibliotecas ya hechas.... algunas bibliotecas utilizan bibliotecas en el lado positivo - .Net le permite envolver un .dll en C++ en un solo archivo ejecutable

Hago pruebas de rendimiento, y leo, C# suele estar cerca de la velocidad de C++ (alrededor de un 5-10% de ganancia), así que no es el doble que C++

Además, C# es un lenguaje muy simple, aunque hasta cierto nivel - el nivel en el que se tomó un paquete ya hecho y se le adjuntó la interfaz de usuario - literalmente, en 2 clics, pero para afinar las bibliotecas ya hechas, para conectarlas con otras bibliotecas - eso es una carga completa)))

la facilidad de uso y la velocidad de escritura son un gran punto a favor, en mi opinión

SZZ: Añadiré Wolfram a C# la semana que viene - por experiencia sé que en una semana obtendré el resultado que quiero.

 
Igor Makanu:

He hecho pruebas de rendimiento y he leído que C# suele rondar la velocidad de C++ (alrededor de un 5-10% de ganancia), es decir, no estamos hablando de una superioridad doble de C++

Bueno, depende de cómo se cuente. Por ejemplo, si medimos la velocidad de ejecución de algún algoritmo con un hilo, obtendremos casi las mismas cifras. Pero aquí no mencionamos que N-número de núcleos se dedicaron a la compilación sobre la marcha, no decimos nada sobre el tiempo de lanzamiento y el consumo de memoria. Es como con Elbrus, mientras un núcleo está ejecutando instrucciones, otro núcleo está ocupado con la traducción.

C# es un lenguaje muy sencillo, pero hasta cierto nivel - hasta el nivel de tomar un paquete ya hecho y añadirle una interfaz de usuario, literalmente en 2 clics,

Bueno, si escribes un gui en winapi puro, tal vez. Pero podría ser más sencillo, ¿no es difícil hacer una ventana con un botón y un manejador (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();
}
 

¡Genial! ¿Viene el xml a nosotros?


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

Víctor, no hay problema. Cada uno tiene su propia religión. Pero intenta implementar el ejemplo que estamos creando ahora en C++ como ejemplo. ¿Cuánto más fácil sería crearlo en C++? La implementación del propio websocket en C++ es un auténtico desastre.

Esto puede parecer mucho, pero hay una biblioteca libwebsockets por ahí.

Tengo la sensación, de que a menudo la opinión sobre las ventajas se forma así - la persona no sabe cómo conectar las bibliotecas ya hechas, vio el ejemplo clásico de la ventana de C++ en winapi puro, entonces ve Sharp con std-biblioteca para todas las ocasiones (que es malo en mi opinión) y obtiene el orgasmo de ella. Y las ventajas, en su opinión, siguen siendo algo muy antiguo y que requiere mucho tiempo.

 
Poner
123456789101112131415...27
Nuevo comentario