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
Referência técnica. Um exemplo de um "mecanismo de embrulho" quando se trabalha com aulas (para não ter de o procurar):
https://www.mql5.com/ru/forum/3555/page3#comment_57315
Pergunta. O novo operador. O Manual de Referência afirma que o novo é um operador; no entanto, nos exemplos, é frequentemente feita uma verificação após a utilização deste operador para o tornar igual ao NULL. Por exemplo:
Diz-se também que"NULL pode ser comparado a apontadores para objectos criados utilizando o novo operador".
Então, acontece que o novo operador nem sempre cria um novo objecto? Ou a verificação da igualdade de um objecto criado à NULL é uma peculiaridade do estilo de um criador e não é obrigatória?
Pergunta. O novo operador. O Manual de Referência afirma que o novo é um operador; no entanto, nos exemplos, é frequentemente feita uma verificação após a utilização deste operador para garantir que é igual ao NULL. Por exemplo:
Diz-se também que"NULL pode ser comparado a apontadores para objectos criados utilizando o novo operador".
Então, acontece que o novo operador nem sempre cria um novo objecto? Ou a verificação da igualdade de um objecto criado à NULL é uma peculiaridade do estilo de um criador e não é obrigatória?
Se criar um objecto dinâmico num lugar num programa, é lógico que o destrua noutro lugar, e não é certo que tudo isto esteja dentro de uma função, por isso uma regra simples é verificar se ele existe antes de utilizar um ponteiro.
Isto é correcto. Mas nos exemplos do Manual de Referência, a verificação é feita imediatamente após a criação do objecto, ou seja, num lugar do programa e dentro de uma função. E a regra aqui dada não é bem a questão. Porque é que a verificação deve ser efectuada logo após a criação de um objecto?Então, acontece que o novo operador nem sempre cria um novo objecto? =(Repito)=
Aqui está mais um exemplo entre muitos:
Isto é correcto. Mas nos exemplos do Manual de Referência, a verificação é feita imediatamente após a criação do objecto, ou seja, num lugar do programa e dentro de uma função. E a regra acima não é aplicável aqui. Porque deve a verificação ser efectuada logo após a criação do objecto?Então, acontece que o novo operador nem sempre cria um novo objecto (repito isto)?
Aqui está mais um exemplo entre muitos:
Essa possibilidade existe. Na referência, o primeiro parágrafo.
OK. Acontece que o comportamento do operador é o de uma função. Pode ou não ser criado.
Por exemplo, não havia memória suficiente para um objecto.
Pergunta. Uma vez declarada uma função virtual com um conjunto específico de parâmetros e tipos numa classe parental, o número e os tipos de parâmetros das funções virtuais correspondentes podem ser alterados nas classes infantis?
Por um lado, o Manual de Referência afirma que "uma função virtual pode ser substituída numa classe derivada ". A escolha da definição da função a chamar para a função virtual é feita de forma dinâmica (em tempo de execução). Um caso típico é quando uma classe base contém e as classes derivadas têm as suas próprias versões dessa função". Por outro lado, os exemplos dados no Manual de Referência referem-se a casos em que as funções virtuais têm corpos de definição de funções diferentes em vez de cabeçalhos de definição de funções.
Pergunta. Após declarar uma função virtual com um determinado conjunto de parâmetros e os seus tipos numa classe parental, é possível alterar o número e os tipos de parâmetros das funções virtuais correspondentes nas classes infantis?