Tempo para converter bibliotecas para MQL5 - página 6

 
victorg:

Na verdade, não há nada de errado com o acesso directo aos dados.

Vá lá, contador de histórias. A segurança é primordial. Mais ainda quando o terminal com EAs e indicadores funciona 24 horas por dia, e tudo está "pendurado" com dinheiro real e acesso. Neste caso, o programador não deve ter medo de utilizar uma dll de terceiros, e aquele que "insidiosamente" utiliza tais dlls - "hara-kiri".
 

Precisamos de separar as áreas em que "exagerar é melhor do que subestimar" é realmente aplicável e útil.

Na minha opinião, o princípio "A Segurança Vem Primeiro" só deveria ser aplicável ao Mercado e à Nuvem. O comprador está a pagar por um produto que é naturalmente seguro e, portanto, fechado, e não há forma de verificar a segurança do produto. Por conseguinte, o mercado deve dar ao comprador uma garantia de 100% da segurança de todos os produtos. E no caso da nuvem, todos os computadores em nuvem devem ser 100% protegidos contra malware.

E em todos os outros casos, não relativos à distribuição de produtos de software através do mercado e à sua aquisição através deste serviço, bem como à utilização da nuvem, toda a responsabilidade pela utilização da dll não comprovada é do utilizador.

Com esta abordagem, pode evitar muitos dos actuais problemas de degradação do desempenho e funcionalidade da linguagem MQL5 devido à "Segurança em primeiro lugar".

 
joo:

Por conseguinte, o mercado é obrigado a dar ao cliente uma garantia de 100% da segurança de todos os produtos.

Como imagina isto? Como vendedor, aluga um mercado à MK e exige que o senhorio seja 100% responsável pela segurança do seu produto, ao mesmo tempo que fecha parte do código na dll. Absurdo.
 
abolk:
Como o prevê? Como vendedor, está a alugar um mercado à MK e a exigir que o senhorio seja 100% responsável pela segurança do seu produto. Absurdo.

O mercado já dá uma garantia de segurança do produto, porque proíbe a utilização de dlls externos pelos produtos. E os próprios programas MQL5 funcionam na caixa de areia interna segura do terminal.

Não tinha conhecimento disto?

 
victorg:

Presumo que terá de mudar muitas coisas.

E basta experimentá-lo.

As DLLs razoáveis são originalmente escritas para integração com outros sistemas e, portanto, têm interfaces externas simples sob a forma de funções em bruto. Os seus ficheiros de cabeçalho são simples.


Na verdade, não há nada de errado com o acesso directo aos dados. Afinal, o próprio MetaTrader está provavelmente escrito em C/C++, e nada. Além disso, os ligadores normalmente até permitem inserções de montadores, e isso também não faz mal. Lembre-se que o MetaTrader a correr sob Windows directa ou indirectamente utiliza muitas dlls de sistema, e também não há nada de errado com ele.

Receio que não esteja na conversa de segurança e não faça a menor ideia do que estamos a falar.


Penso que não se pode privar o utilizador do direito de escolha. Gostaria muito de ter a opção onde poderia, por exemplo, levar o ALGLIB-dll e o(s) seu(s) ficheiro(s) de cabeçalho nativo(s) e utilizar uma biblioteca fiável sem "sujar as minhas mãos", mas apenas apontando para o compilador MQL que este ficheiro de cabeçalho é C++ e não MQL.

Pegar na biblioteca e utilizar funções exportadas de cabeçalhos com pequenas modificações (se necessário).

Pensar que se pode tirar qualquer ficheiro *.H de uma língua C/C++ insegura e utilizá-lo noutra língua (ainda mais segura) é um completo mal-entendido de línguas. Pode-se sonhar, mas não se pode exigir.

A biblioteca ALGLIB já está a ser portada para MQL5 e estará disponível no código fonte.


A questão pode surgir - e se esta biblioteca for maliciosa e perigosa? Mas eu próprio decidi usá-la.

Fazer esta pergunta alguns milhões de vezes para compreender o número de utilizadores finais do MetaTrader, e avaliar a qualidade da ponderação e responsabilidade desses milhões de inquiridos.

É por isso que nos preocupamos com a segurança original do ambiente.


Por outras palavras - o MQL deve ser tão seguro quanto se queira, mas se eu ousar usar algo externo, então é o meu próprio problema pessoal.

Utilizar a DLL - sem problemas para uso pessoal.
 
Renat:

Pensar que se pode pegar em qualquer ficheiro *.H de uma língua C/C++ não segura e utilizá-lo noutra língua (e ainda mais segura) é um completo mal-entendido de línguas. É possível sonhar, mas é impossível de exigir.

A biblioteca ALGLIB já foi portada para MQL5 e estará disponível no código fonte.

Talvez tenha expressado a minha opinião em vão (a propósito, não exigi nada). E quanto à falta de compreensão das línguas, tem toda a razão. Quanto mais leio e compreendo, menos compreendo. Não percebo porque é que se reescrever o ALGLIB para mql5, e depois compilá-lo com compilador externo(visualc) em DLL, então a biblioteca estará mais segura a partir disto do que em caso de compilação directa do código fonte original da biblioteca em DLL de uma só vez?

Está bem. Que assim seja.

 
victorg:

Não percebo porquê se reescrever ALGLIB para mql5 e depois compilar com um compilador externo(visualc) para uma DLL,

Percebeu um pouco mal. A reescrita na MQL5 foi concebida não para utilizar DLL, mas para incluir todos os pacotes matemáticos necessários directamente no código fonte da MQL5.
 
Renat:
Fizemos um enorme trabalho de afinação do compilador MQL5 para facilitar a conversão das bibliotecas existentes escritas noutras línguas.

E o desenvolvimento da linguagem MQL5 continua. Espera-se que surjam em breve novas funcionalidades, incluindo um poderoso profiler de código.

Temos agora duas tarefas a cumprir:
1) para seleccionar bibliotecas úteis de terceiros para conversão
2) reunir voluntários para implementar projectos de conversão (financiá-lo-emos).

Gostaríamos de começar com uma lista de potenciais projectos. Ajuda com links e pequenas descrições, por favor.

Uma vez que a ALGLIB já está a ser portada aparentemente, a principal questão sobre o tema é"o que outras bibliotecas de código aberto gostariam de ver?"

 
Urain:
Uma vez que a ALGLIB já está a ser portada aparentemente, a questão principal do tópico é "que outras bibliotecas de código aberto gostariam os utilizadores de ver?

Sim, deixei isso claro no meu primeiro posto:

Estamos agora confrontados com dois desafios:
1) para escolher bibliotecas de código aberto úteis para conversão

 
Rosh:
Percebeu um pouco mal. A reescrita na MQL5 foi concebida para incluir todos os pacotes matemáticos necessários directamente no código fonte da MQL5 em vez de usar DLL.

Desculpe, realmente confuso com a prometida capacidade de compilar o código C/C++ num dll directamente do metaeditor.

Mas para mim ainda não está claro, porquê portar, quando (biblioteca) já está pronta para ser usada como DLL? Acontece que - comprei um livro numa loja e antes de o ler, transcrevi-o primeiro para um caderno.

Devo ter-me enganado novamente. Não vou escrever mais.

Razão: