Websocket como? - página 8

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

Não, não o apague, ainda vamos precisar dele!

(Muito bem!) Esperando por mais instruções ))
 
Алексей Барбашин:

Posso perguntar, como um adepto de afiações? Qual é a vantagem de usar código administrado sobre código não administrado? Aqui, por exemplo. Deixando de lado coisas como a sintaxe e concentrando-se nos benefícios em princípio.

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

Bem, poucas pessoas escrevem em linguagem "pura", e você usa as libras da Sharp, nos profissionais de forma semelhante. Bem, eu não insisto neles, há uma compilação, por exemplo. Eu realmente não entendo a necessidade deste acolchoamento na forma de uma máquina virtual. Vejo as desvantagens, os benefícios de alguma forma não são observados. E mesmo a criação dos pequenos fabricantes, eu teria optado melhor pela java.

 
terminado, tudo montado sem erros
 
Tudo funciona
 
Алексей Барбашин:

Não funciona dessa forma. O material especificado utiliza uma tecnologia diferente para integrar c# e mql. A tecnologia acima implementa uma biblioteca diretamente na dll que cria uma "camada" entre código administrado e não administrado, caso contrário, o sql não conseguiria se comunicar com o sql. Mas os desenvolvedores fizeram um ótimo trabalho e agora bibliotecas afiadas podem se integrar no mql nativamente, você nem precisa declarar o procedimento de exportação, tudo "encaixa" como nativo, como Fedor e eu demonstramos. Quanto às estruturas, elas precisam ser tratadas. De acordo com o que o Fedor quer fazer, precisaremos devolver as estruturas de dados da dll. É claro que podemos ser estragados pelo mapeamento, mas eu realmente espero que tudo funcione sem nenhum incômodo extra.

Eu me ofereci para verificar o exemplo - não funcionou, a MQL5 não vê tipos personalizados

Não se trata de tecnologia. A MQL5 começou a suportar .Net "fora da caixa" no segundo semestre do ano passado - todos sabem disso ;)

Vitória:

Eu realmente não entendo a necessidade deste acolchoamento na forma de uma máquina virtual. Eu vejo as desvantagens, não vejo os benefícios de alguma forma. E, além disso, a criação dos pequenos, eu preferiria a java.

há muitas bibliotecas prontas.... algumas bibliotecas usam bibliotecas no lado positivo - .Net permite embrulhar um .dll em C++ em um único arquivo executável

Eu faço testes de desempenho, e eu leio, C# está frequentemente próximo da velocidade C++ (cerca de 5-10% de ganho), então não é o dobro do C++

Além disso, o C# é uma linguagem muito simples, embora até certo nível - o nível onde você pegou um pacote pronto e anexou uma interface de usuário - literalmente, em 2 cliques, mas para sintonizar bibliotecas prontas, para conectá-las com outras bibliotecas - isso é uma carga completa)))

usabilidade geral e velocidade de escrita é uma grande vantagem, imho

SZZ: Eu acrescentarei a Wolfram ao C# em uma semana - por experiência sei que dentro de uma semana eu conseguirei um resultado, eu olhei através da Wolfram C# - tudo é padrão, como em outros lugares com pacotes C#

 
Igor Makanu:

Já fiz testes de desempenho e li que o C# está frequentemente em torno da velocidade C++ (cerca de 5-10% de ganho), ou seja, não estamos falando de uma dupla superioridade de C++

Bem, depende de como você conta. Por exemplo, se medirmos a velocidade de execução de algum algoritmo com um fio, obtemos quase os mesmos números. Mas aqui não mencionamos que N-número de núcleos estavam envolvidos na compilação on-the-fly, não dizemos nada sobre tempo de lançamento e consumo de memória. É como com a Elbrus, enquanto um núcleo executa instruções, outro núcleo está ocupado com a tradução.

C# é uma linguagem muito simples, mas até um certo nível - até o nível de pegar um pacote pronto e adicionar uma interface de usuário a ele, literalmente em 2 cliques,

Bem, se você escrever um engano em winapi puro, talvez. Mas poderia ser mais simples, não é difícil fazer uma janela com um botão e um manipulador (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();
}
 

Legal! O xml está chegando até nós?


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

Victor, sem problemas. Cada um tem sua própria religião. Mas você tenta implementar o exemplo que estamos criando agora em C++ como um exemplo. Quanto mais fácil seria criá-lo em C++? A implementação do próprio websocket em C++ é uma verdadeira confusão.

Isto pode parecer muito, mas existe uma biblioteca de libwebsockets por aí.

Tenho a sensação de que muitas vezes a opinião sobre as vantagens é formada assim - a pessoa não sabe como conectar bibliotecas prontas, viu o exemplo clássico da janela C++ em winapi puro, depois vê Sharp com std-library para todas as ocasiões (o que é ruim na minha opinião) e obtém o orgasmo com isso. E as vantagens, em sua opinião, continuam sendo algo muito antigo e demorado.