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
E se eu não apenas alterar os dados internos do objeto, mas também não acessá-los, eu imediatamente escrevo o método como estático. Para mim, o uso de constante e estático aumenta muito a legibilidade/entendimento de meu próprio código. E isso muitas vezes me permite pegar bugs ou falhas em minha própria arquitetura nos estágios iniciais de implementação.
Escrevo tudo apenas para mim mesmo. E parece que eu não vou mudar alguns dados que de qualquer forma não deveria. Mas o desejo de me proteger de minha própria estupidez me faz rebitear a arquitetura OOP de tal forma, que somente o que deve ser acessível para mudar. O resto não é. E aqui os tipos const + inheritance são de grande ajuda. Eu o recomendo.
Talvez esta seja uma parte que é dada pelos criadores aos usuários comuns. Como a função de início nas variáveis EA e Bid and Ask. Quando você faz tudo sozinho, não faz sentido se preocupar com todos os tipos de constantes.
Tenho notado uma tendência interessante - na grande maioria dos casos, aqueles que não sabem nada sobre isso falam sobre a monstruosidade dos prós. Principalmente afiados, isso é típico.
Sim, é claro, Sharpe é melhor e mais conveniente quando você precisa fazer algo tão reto quanto um bastão).
Não é um caso incomum quando uso tais construções de forma intencional:
Se eu não alterar os dados do objeto interno e não me aplicar a ele, eu especifico o método como estático. Para mim, o uso de constante e estático aumenta muito a legibilidade/entendimento de meu próprio código. E muitas vezes permite que você pegue bugs ou falhas em sua própria arquitetura em um estágio inicial de implementação.
...
Oh, pessoal. Tenha piedade da MetaQuotes. Um dos principais mandamentos de um programador: nunca usar estática. Segundo mandamento: se você quiser usar estática, veja o primeiro ponto:)
Se os dados estáticos são alterados por um fio enquanto outro os lê, tais maravilhas da programação multithreading aparecem, que se pode lembrar desta estática como um pesadelo.
Mas bom para usuários em MQL: sem multithreading e, conseqüentemente, nenhum método mudará os dados estáticos antes que um thread do usuário termine de lê-los.
Um dos primeiros mandamentos de um programador: nunca usar estática. Segundo mandamento: se você quiser usar estática, veja o primeiro ponto:)
Se os dados estáticos são alterados por um fio enquanto outro os lê, tais maravilhas da programação multithreading aparecem, que se pode lembrar desta estática como um pesadelo.
Tenho notado uma tendência interessante - na grande maioria dos casos, aqueles que não sabem nada sobre isso falam sobre a monstruosidade dos prós. Na maioria das vezes, afiados, o que é típico.
Sim, é claro, Sharp é melhor e mais conveniente quando você precisa fazer algo tão reto quanto um bastão).
Clássico masa b pluses: "Você não gosta de gatos? Você simplesmente não sabe como cozinhá-los".
Não, eu não nego, C++ como nenhuma outra linguagem pode ser ajustada aos padrões de desenvolvimento. Mas até que você chegue a estes padrões, você pode ser morto em um ancinho tal que ou você se torna um programador C++ realmente bom ou desiste e vai para 1C para fazer os adesivos do ERP.
Máscara clássica B-plus-people: "Você não gosta de gatos? Você simplesmente não sabe como cozinhá-los".
É assim que as coisas são).
Não tenho nada contra a Sharp, estou escrevendo bots com ela, é conveniente, rápido.
Eu simplesmente não gosto quando as pessoas jogam lama sobre algo que não merece e, além disso, algo que ninguém é necessariamente obrigado a usar.
Isso vale tanto para os contras quanto para os prós em geral.
É assim que as coisas são).
Não tenho nada contra a Sharp, estou escrevendo bots nele agora, é conveniente, rápido.
Eu simplesmente não gosto quando as pessoas jogam lama em algo que não merece e, além disso, algo que ninguém é forçado a usar obrigatoriamente.
Isto se aplica tanto a constantes como a profissionais em geral.
Ok, o mundo. É que a discussão sobre C++ sempre desce a um hullabaloo.
Z.U. Se alguém me explicasse qual é o problema com const, eu agradeceria. Eu realmente não entendo.
Alexey escreveu o exemplo. Um método constante não pode mudar seus membros de classe.
Talvez esteja me faltando algo, mas... aqui. Alexey escreveu que a barra de método constante muda o objeto de sua objeção de classe. Qual é o problema?
Sim, a obj é passada por referência, mas o método ainda não se tornou constante...
Talvez esteja me faltando algo, mas... aqui. Alexey escreveu que a barra de método constante muda o objeto de sua objeção de classe. Qual é o problema?
Sim, a obj é passada por referência, mas o método ainda permanece constante.