Erros, bugs, perguntas - página 2636
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Não sou um programador, mas vou comentar.
Para uma matriz estática, o compilador tem de atribuir um certo número de bytes na memória em tempo de compilação.
Quanta memória deve o compilador atribuir se a fila e o col são desconhecidos no momento da compilação?
Os valores iniciais só são utilizados se os parâmetros forem omitidos ao chamar. Os parâmetros reais só são conhecidos em tempo de execução.
Assim, sem truques, aprenda a língua.
Isto é um pouco tonguento, mas é mais um apelo para o promotor.
Por isso Zloy, não o leves a peito.
Acontece que as matrizes dinâmicas só podem ser manipuladas através de objectos ou estruturas. Uma outra muleta é criada em geral.
Não existem apontadores para variáveis em mql, pelo que temos de utilizar a abordagem por objectos onde os apontadores estão disponíveis.
Assim, para utilizar matrizes dinâmicas, um utilizador deve conhecer o OOP e trabalhar com apontadores, e além disso, na execução do MQL.
Quantos deles têm este conhecimento? Você mesmo sabe a resposta. Não tenho qualquer dificuldade em compreender a abordagem ao objecto, mas para aqueles que não conhecem o PON
Criam um limiar artificial para a utilização da língua, em particular quando se trata de matrizes dinâmicas.
A meu ver, um programador, pelo contrário, deveria estar interessado em tornar a linguagem mais fácil de usar, em vez de a complicar.
Por outras palavras, devem desenvolver tais funções que são necessárias ao utilizador para um trabalho confortável com a língua.
E ainda mais com matrizes, que são quase a base dos métodos numéricos.
Por esta razão, gostaria de lhe pedir para criar funções semelhantes ao ArrayResize, mas para as matrizes ArrayResizeMx(A, n, m),
e talvez também para as multidimensionais. Por outras palavras, dar a possibilidade de trabalhar com matrizes não como com objectos, mas como com matrizes habituais no estilo C.
Especialmente para a representação visual de matrizes, a função ArrayPrint(A, 0) imprime matrizes a partir de matrizes, não de objectos.
Em 2012, o problema das matrizes multidimensionais dinâmicas foi resolvido com sucesso...
Aqui está um fio relacionado:https://www.mql5.com/ru/forum/6729
O código pode agora ser melhorado através da adição de suporte para os modelos.
Em 2012, o problema das matrizes multidimensionais dinâmicas foi resolvido com sucesso...
Aqui está um fio relacionado:https://www.mql5.com/ru/forum/6729
O código pode agora ser melhorado através da adição de suporte para os modelos.
Leia todo o fio, felizmente é curto.
Portanto, o tópico de partida, e não revelou a sua proeza!
Algum tipo de troça, isca o tema e desapareceu.
E é novamente um mergulho na OLP, não é permitida a entrada a ninguém.
Yuri citou a sua própria solução, ninguém sabe como ela é verdadeira.
Que teremos de modificar e modificar. Quem o fará? Ninguém, uma vez que ainda não o completaram.
É por isso que precisamos de funções que funcionem com matrizes dinâmicas fora da caixa do revelador.
O revelador conhece melhor o assunto e a alocação de memória sem invólucros parece muito melhor e mais rápida.
Pelo menos uma funçãoArrayResizeMx(A, n, m, k) abriria a possibilidade de trabalhar não com objectos mas com arrays em estilo C.
E isto é novamente uma imersão no OOP, não é permitida a entrada a ninguém.
Assim, para utilizar matrizes dinâmicas o utilizador deve conhecer o OOP e trabalhar com apontadores e na execução do MQL também.
Quantos deles têm tais conhecimentos? Você mesmo sabe a resposta. Não tenho qualquer dificuldade em compreender a abordagem ao objecto, mas para aqueles que não conhecem o PON
Criam um limiar artificial para a utilização da língua, em particular quando se trata de matrizes dinâmicas.
Parece-me que o revelador, pelo contrário, deveria estar interessado em tornar a linguagem mais fácil de usar em vez de a complicar.
Posso surpreendê-lo, mas os jovens programadores de hoje consideram que o OOP é mais fácil de programar do que a programação processual.
Está a pensar em termos de 25 anos atrás. Os jovens de hoje absorvem o OOP com o leite da sua mãe. Aprenda OOP se quiser estar na tendência; caso contrário, não fará mais nada senão resmungar.
Posso surpreendê-lo, mas os jovens programadores de hoje consideram que o OOP é mais fácil de programar do que a programação processual.
talvez em comparação com a programação funcional?
Posso surpreendê-lo, mas os jovens programadores de hoje consideram que o OOP é mais fácil de programar do que a programação processual.
Está a pensar em termos de 25 anos atrás. Os jovens de hoje absorvem o OOP com o leite da sua mãe. Aprenda OOP se quiser estar na tendência, caso contrário, não fará mais nada senão resmungar.
Sim, eu compreendo o OOP, não na medida em que gostaria.
Isto não é um resmungo, mas uma proposta construtiva.
Para que o desenvolvedor não tenha de escrever uma função para atribuir dois mallocs, forçam os utilizadores a estudar OOP.
Isto é certamente o progresso, desenvolvimento e popularização da língua. Pode ver o quanto eles adoram e compreendem o OOP aqui.
Sabe, Nikolay, tudo o que está embrulhado é código desnecessário para ser executado - não creio que precisemos de explicar porquê.
Não preciso de vos falar sobre compiladores modernos de optimização - não sabemos que instruções irão aplicar.
Talvez também vos surpreenda que até os programadores americanos prefiram escrever no estilo processual não porque o OOP é mau, mas porque o código é mais simples e mais rápido.
E se não há tarefas objectivas no projecto, porquê utilizar invólucros, que de alguma forma devem ser compreendidos, para os jovens )
Por isso, não concordo consigo que os jovens absorvam com entusiasmo o OOP.
Estou a pensar em C, que é onde a lógica da linguagem mql é construída.
C nasceu em 1972, por isso tem 48 anos ))
Mas de qualquer forma C é uma das línguas mais rápidas. Sabe porquê? Porque não tem invólucros de classe.
talvez em comparação com um funcional?
Proceduralmente funcional :)
Não creio que seja só isso. Há um tópico especial aqui :https://www.mql5.com/ru/forum/40295
Não o examinou até ao fim, especialmente porque é para a MQL4.
Penso que o servidor não deve enviar cotações simbólicas se o mercado estiver fechado.
O meu robô não é realmente afectado por isto porque depois de o mercado "abrir" quando os carrapatos entram nele, analisa a tendência, as suas inversões, e isso leva algum tempo. Durante este tempo, o mercado abre-se.
Mas atrapalha-se se quisermos executar manualmente algumas transacções durante este tempo. Se a execução for orientada pelo mercado, o pedido está pendente até que o mercado abra e é naturalmente executado ao preço actual.
A função directa que recebe o nome do símbolo e retorna verdadeiro/falso (mercado aberto/fechado) está claramente em falta.
Há uma citação e uma sessão de comércio. Pesquisa, já foi explicado 20 vezes.
Por favor, acrescente outro distintivo de algum tipo:
4. Dinheiro
Onde a soma de todos os fundos recebidos para o dia (mercado, freelance, etc.) seria exibida, seria muito conveniente, e agora para isso tem de ir para o perfil, que veria o saldo disponível.
Se entrar tanto e regularmente, pode encomendar um plugin para cromar ;)
Há uma sessão de cotação e uma sessão de negociação. Procure-o, está todo mastigado 20 vezes.
Demorei apenas alguns dias a mudar de VC++ para MQL5. Nunca procurei nada por tanto tempo.
Se receber a mensagem "Mercado fechado" durante a negociação, deve ter uma forma simples de determinar este estado, em vez de escrever "quilómetro-longo" e código complicado.
Não me dê conselhos como esse.