Erros, bugs, perguntas - página 1133

[Artem Temnikov]

A100:

Ele não me diz.

Mais uma vez: tal objecto pode ser criado dentro da própria classe, mas um ponteiro para tal objecto também pode ser criado fora da classe

Assim o fará:

class B {
        B() {}
};
void OnStart()
{
        B *b;
        b=new B;
}

[A100]

Fleder:

Dirá que sim:

Também pode criar um objecto se precisar de

class B {
        B( int ii ) : i( ii ) {}
        int i;
public:
        int g() { return ( i ); }
        static B *f( int ii ) { return ( new B( ii ) ); } 
};
void OnStart()
{
        B *b = B::f( 100 );
        Print( b.g());
}

[Renat Fatkhullin]

Zeleniy:

Não percebo como digitalizar servidores quando me ligo? Anteriormente, introduzi o nome do servidor e a lista apareceu, acrescentei o necessário (imagem 2, há cerca de quinze dias atrás foram acrescentados servidores) Na imagem um já não é digitalizado os servidores necessários, não posso acrescentar. O que é que já não é possível ou como é que o faz você mesmo?

Tem de usar parte do nome da empresa mas não parte do nome do servidor. A pesquisa do nome do servidor já não funciona, uma vez que muitas vezes fornecia listas demasiado grandes de correspondências e não fornecia de todo o que o comerciante queria.

[Renat Fatkhullin]

Lone_Irbis:

Sim, e também é melhor não utilizar forex. Ou o computador, já agora :) Não é de todo saudável.

De qualquer modo, já existe uma solução. Não é muito agradável, mas funciona. A correcção chama-se "Para o inferno com o seu OOP". %) Os erros foram eliminados serrando todas as variáveis estáticas das classes, retirando-lhes o prefixo estático e empilhando-as ordenadamente umas ao lado das outras.

Em geral, não sei o que os criadores não gostaram das variáveis estáticas e porque tiveram de remover o recurso de inicialização automática de variáveis, mas se for necessário, tenho de o fazer. Tenho de usar soluções de trabalho...

É assim que funciona também em C++. As variáveis estáticas devem ser definidas explicitamente.

Não há problemas com isso.

[Artem Temnikov]

A100:

Estou a ver o seu ponto de vista.

Se uma instância de uma classe tentar ser desovada por algum programa externo, o construtor deve estar aberto.

Se a instância "spawns itself" (e passa um ponteiro para si própria para um programa externo), então um construtor fechado está disponível.

[Lone_Irbis]

Renat:

É assim que funciona também em C++. As variáveis estáticas devem ser definidas explicitamente.

Não há problemas com isso.

Bem, a questão não é tanto onde e como funciona e se haverá algum problema com isso. A questão é que funcionava bem antes, sem ser explicitamente especificado.

E, para mudar algo que já está a funcionar, é melhor ter uma razão muito mais importante do que "os vizinhos também o fazem". :)

Mas, vá lá, claro, acho que essa não é a única razão.

[A100]

O objectivo de um único construtor privado é apenas limitar a criação de classes derivadas, Alternativamente, uma classe pode ter vários construtores

class A {
private:
        A( int ) {}
public:
        A( int, int ) {}
};
class B : public A {
        B() : A( 0, 0 ) {}
};

[Artem Temnikov]

Lone_Irbis:

Não é tanto uma questão de onde e como funciona e se vai ser um problema. A questão é que já funcionou bem antes, sem ser explicitamente declarado.

E para mudar algo que já funciona, é aconselhável ter razões mais importantes do que "os vizinhos também o fazem". :)

Mas, vá lá, acho que essa não é a única razão, é claro.

E tenta inicializar as variáveis estáticas na lista de inicialização do construtor.

[Artem Temnikov]

A100:

O objectivo do único construtor privado é apenas o de limitar a criação de classes derivadas. Uma classe também pode ter vários construtores

Afinal de contas, é o seu próprio criador de códigos e há pouco sentido em tais restrições.

[Aleksey]

Será que todos têm a mesma coisa com os botões da janela do MQL-Storage Fix?