Erros, bugs, perguntas - página 2718
![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
ArrayResize aplicado a diferentes matrizes.
Ou quer uma matriz com uma sequência de valores a: 1, 2, 3, 4, 5, 6, 7, 8,... ?
Uma matriz. A partir da vossa variante vi a possibilidade de ArrayResize sequencial.
Uma matriz. A partir da vossa variante vi a possibilidade de ArrayResize sequencial.
Também se pode incrementar o default_a no construtor, zerando-o para o valor desejado antes do ArrayResize.
Pode também aumentar o valor por defeito_a no construtor, redefinindo-o para o valor requerido antes do ArrayResize.
Para uma tarefa geral, não se pode, porque não é um valor sequencial.
É uma pena que tenhamos de arrastar uma variável estática, e pública também. Parece crocante.
Como criar um conjunto de estruturas onde um dos campos é constante?
Em alternativa:
Como opção:
Obrigado. Depois de preencher a matriz, poderia fazer ArrayFree(::sdefs).
Como criar um conjunto de estruturas onde um dos campos é constante?
O que se quer é estranho. Imho - as estruturas são entidades C, devemos tratá-las como objectos POD, passivos, sem construtores e sem outros açúcares. Pode fazer uma classe com setter que contenha estrutura, setter não permitirá a reatribuição. Penso que isto é mais correcto do ponto de vista do design.
O que se quer é estranho. Imho - as estruturas são entidades C, devemos tratá-las como objectos POD, passivos, sem construtores e sem outros açúcares. Pode fazer uma classe com um setter que contenha uma estrutura, o setter não permitirá a reatribuição. Penso que isto é mais correcto do ponto de vista do design.
Na minha opinião, os campos que nunca (e nunca devem) ser alterados após a criação são logicamente prescritos constantes.
Na minha opinião, campos que nunca (e nunca devem) ser alterados após a criação, é lógico escrever const.
Bem, também tem um construtor. Depende de si, claro, mas as estruturas são entidades C e o modelo é diferente - entidades passivas com lógica externa (funções).
Bem, eles também o prenderam com o construtor. Cabe a si decidir, claro, mas as estruturas são entidades C e o modelo é diferente - entidades passivas com lógica externa (funções).
Construtor apenas porque não se pode rubricar um campo constante sem ele. Estrutura ou classe - não faz qualquer diferença. O principal é ter um objecto.