const é um controlo adicional. Caso contrário, poderíamos ter evitado introduzir completamente esta directiva na língua.
Um campo público constante é bom na medida em que é passível de LEITURA (pode ser passado por referência). Mas está excluída a sua alteração por engano.
const ajuda-me muito quando escrevo programas. Esta é a primeira vez que surge um problema.
HH Também ajuda a usar isto e :: onde não podem ser escritas.
Tornar a variável privada. Use uma função de leitura. Não há necessidade de passar const const int por referência.
Experimentei, em geral, qualquer solução será "defeituosa", independentemente da forma como se olhe para ela
Se estamos a falar de velocidade de execução e controlo de acesso ao campo da estrutura, pode escrever uma solução feia, mas ela irá resolver o problema
Desistiria completamente dos métodos estáticos na estrutura - não há sentido neles, o código continuará a ser confuso e não lógico
é o que parece:
int tmp[] = {1,2,3,99};
struct A
{
private:
staticint count;
public:
constint a;
A():a(tmp[count++]) {}
};
staticint A::count = 0;
//+------------------------------------------------------------------+voidOnStart()
{
A a[ArraySize(tmp)];
for(int i=0;i<ArraySize(a);i++) Print(a[i].a);
}
....da e o contador de contagem também não é necessário, é necessário, de facto, embrulhar A[ArraySize(tmp)]; numa macro substituição que criará um conjunto de estruturas e apagará um tmp de matriz temporária
Há dois programas a trabalhar no mesmo ficheiro ao mesmo tempo. A que escreve utiliza as bandeirasFILE_READ|FILE_WRITE|FILE_BIN|FILE_SHARE_READ. A que diz - FILE_READ|FILE_BIN|FILE_SHARE_WRITE|FILE_SHARE_READ. Embora o primeiro programa salve periodicamente o ficheiro usando FileFlush, o segundo programa só vê o comprimento do ficheiro quando este é aberto. Tentei fazer FileSeek para a frente e para trás - não ajuda.
Pergunta: como faço para que o programa que lê o ficheiro apanhe os dados a serem sobregravados?
Esperava que houvesse algum mecanismo para rubricar este caso, mas não há lá nada
ZS: aqui o compilador vê
Em princípio não deveria existir tal caso - a questão já deveria ter sido resolvida ao nível do compilador (como em C++). E aqui é meio possível e como consequência, uma discussão para várias páginas
Não faz sentido. Se não o vai mudar, não significa que tenha de fazer const. É suficiente tornar a variável privada.
Seria lógico se conseguisse alguma coisa com isso, mas só criou um problema para si próprio.const é um controlo adicional. Caso contrário, não teria de introduzir esta directiva na língua em questão.
O que é bom num campo público constante é que é acessível por LEITURA (pode ser passado por referência). Mas está excluída a sua alteração por engano.
const ajuda-me muito quando escrevo programas. Esta é a primeira vez que surge um problema.
Também ajuda a utilizar isto e :: onde não podem ser escritas.
const é um controlo adicional. Caso contrário, poderíamos ter evitado introduzir completamente esta directiva na língua.
Um campo público constante é bom na medida em que é passível de LEITURA (pode ser passado por referência). Mas está excluída a sua alteração por engano.
const ajuda-me muito quando escrevo programas. Esta é a primeira vez que surge um problema.
HH Também ajuda a usar isto e :: onde não podem ser escritas.
Tornar a variável privada. Use uma função de leitura. Não há necessidade de passar const const int por referência.
Tornar a variável privada. Use uma função para a ler. Não há necessidade de passar const const int por referência.
Propõe simplesmente ignorar const.
Está a sugerir que a const é simplesmente ignorada.
Não. Mas não é necessário neste caso particular.
Experimentei, em geral, qualquer solução será "defeituosa", independentemente da forma como se olhe para ela
Se estamos a falar de velocidade de execução e controlo de acesso ao campo da estrutura, pode escrever uma solução feia, mas ela irá resolver o problema
Desistiria completamente dos métodos estáticos na estrutura - não há sentido neles, o código continuará a ser confuso e não lógico
é o que parece:
....da e o contador de contagem também não é necessário, é necessário, de facto, embrulhar A[ArraySize(tmp)]; numa macro substituição que criará um conjunto de estruturas e apagará um tmp de matriz temporária
Há dois programas a trabalhar no mesmo ficheiro ao mesmo tempo. A que escreve utiliza as bandeirasFILE_READ|FILE_WRITE|FILE_BIN|FILE_SHARE_READ. A que diz - FILE_READ|FILE_BIN|FILE_SHARE_WRITE|FILE_SHARE_READ. Embora o primeiro programa salve periodicamente o ficheiro usando FileFlush, o segundo programa só vê o comprimento do ficheiro quando este é aberto. Tentei fazer FileSeek para a frente e para trás - não ajuda.
Pergunta: como faço para que o programa que lê o ficheiro apanhe os dados a serem sobregravados?
Vou resumir:
Qual é a diferença entre 1 e 2 ?
Vou resumir:
Qual é a diferença entre 1 e 2 ?
Esperava que houvesse algum mecanismo para rubricar este caso, mas não há lá nada
ZS: aqui o compilador vê
Esperava que houvesse algum mecanismo para rubricar este caso, mas não há lá nada
ZS: aqui o compilador vê
Em princípio não deveria existir tal caso - a questão já deveria ter sido resolvida ao nível do compilador (como em C++). E aqui é meio possível e como consequência, uma discussão para várias páginas