PC Toledo

o xHarbour não é totalmente compativel com o clipper, seria até pedir de mais neh !!! hehehe...fazer o que alguma coisa tem que ser alterada mesmo !!! um dia chega lah !!!

Em clipper, as variáveis com os tipos Array, Objeto, CodeBlock são ignoradas pelas instruções Save/Restore from .MEM conforme esperado, ou seja, nada ocorre com elas antes ou depois das instruções Save / Restore from, o mesmo deveria ocorrer em xHarbour, porém ele esta destruindo as variáveis, causando um enorme problema no sistema.

Eu não uso MEM nem a pau, mas pelo que lembro, o RESTORE apaga todas as variáveis públicas e privadas, a menos que se use a cláusula ADDITIVE.

Não sei qual o comportamento no Clipper, mas mesmo sem ADDITIVE, ele não deveria apagar uma variável local em outra função. O RESTORE apenas repõe (ou adiciona) variáveis no memory pool do sistema. Ele não mexe na pilha, onde as variáveis locais são armazenas (por valor ou referência). Sem dúvida, é um bug. Tão escabroso que provavelmente já deve ter um bug report registrado.

o xHarbour não é totalmente compativel com o clipper, seria até pedir de mais neh !!!

Não é. No que pese o princípio da retro-compatibilidade de *quase* 100%, isso é um bug bem feio. Deveria ser tratado com prioridade.

Maligno escreveu:

o xHarbour não é totalmente compativel com o clipper, seria até pedir de mais neh !!!

Não é. No que pese o princípio da retro-compatibilidade de *quase* 100%, isso é um bug bem feio. Deveria ser tratado com prioridade.

Concordo.

É melhor reportar esse bug na lista de bugs.
http://www.xharbour.com/support/bugrepo ... p?page=add

Ou no news:
http://groups.google.com.br/group/comp. ... s?hl=pt-BR

Se é que é um bug mesmo.

Saudações
Itamar M. Lins Jr.

Se é que é um bug mesmo.

Não testei, mas pelo comentário do Éric, só pode ser. Um RESTORE não pode destruir uma variável local que reside em outra função. Observe: a variável GetList, de escopo local, não está na função onde RESTORE é executado. Ainda assim, GetList é destruída. Uma ação fora de escopo.

É bug mesmo, só pode ser.
Não é que ele destroi variaveis, o comando "save to ... " simplesmente não salva o conteudo da variavel no .mem.
Já fiz uma rotinazinha boba aqui só para testar isso e não funciona.
Ele até cria o arquivo, mas o conteudo não !

Não. O comando SAVE (do Clipper) não salva variáveis locais, mesmo que se queira. Está no NG. Por isso, o que ocorre é a destruição mesmo, pelo uso do comando RESTORE. Esse comando apenas e tão somente cria variáveis PRIVATE com o conteúdo do arquivo MEM gerado. Ele não deveria alterar em nada qualquer variável local. Ainda mais fora do escopo da função onde o comando é executado.

O interessante é que depois de tanto tempo, só agora entrou esse bug report? Será que ninguém, em lugar algum, passou pelo mesmo problema?

ericmagaldi escreveu:O exemplo abaixo é com GetList, mas acontecerá com todas as outras variáveis públicas/privadas do tipo citado.

Não me ative atentamente ao seu código, Éric. Por isso, acho que me precipitei. No seu código de teste a variável GetList é local para Main(). Ao ser executada a função ArqMem(), GetList fica invisível, claro. Então nesta função, GetList não é destruída. Ou é? Mas você não testou se em Main() a GetList ainda existe, testou? Nota: não uso xHarbour e por isso não testei e nem vou testar.

A sua preocupação quanto a destruição das variáveis públicas e privadas não procede, já que este é o comportamento normal de RESTORE. No Clipper, pelo menos. A não ser que se use a cláusula ADDITIVE, que você não usou no seu código de teste.

O que eu disse antes foi com relação ao que você descreveu como a destruição da GetList local por uma outra função, fora do escopo da variável. Isso sim seria anormal. Mas hoje, dando uma passeada no fórum, vi seu link para o bug report e percebi que você tinha errado na descrição que está como "Restore from .mem, destroy all variables public type Array", que é uma descrição diferente da que o Culik usou. Acabei olhando melhor seu código e percebi que talvez tenhamos analisado incorretamente o caso.

O X da questão é Getlist como uma variável local, que não deveria ser destruída. Veja que a GetList usada em TesteGet1() tem de ser destruída mesmo, já que ela não é local. Note que temos duas GetList neste caso. A local, de Main() e a de TesteGet1(). Portanto, teste apenas se a GetList local de Main() está mesmo sendo destruída. Se não estiver, ótimo. Não há bug nisso. Seria então só o caso de testar as variáveis públicas e privadas (incluindo a GetList de TesteGet1()) mas com o uso da cláusula ADDITIVE. Se ainda assim, estiverem sendo destruídas, é bug mesmo. Caso contrário, foi só uma mera distração. Isso pelo menos explicaria o fato de um bug tão grosseiro nunca ter sido reportado antes.

Acredite: entendi qual é sua reclamação. Mas, uma vez que o RESTORE do XHarbour também dispõe da cláusula ADDITIVE e você não a incluiu no seu código de teste, ficou a dúvida: com ADDITIVE a GetList não-local é destruída assim mesmo? E outra pergunta: a GetList local (a de Main() - lembre-se: há duas) é destruída em qualquer caso? Se a resposta a qualquer uma das perguntas for sim, aí concordo, existe um bug. Se para ambas a resposta for não, então o comportamento que se tem é exatamente o esperado, conforme os helps do Clipper e do XHarbour.

Sugiro-lhe que aguarde mais um pouco, até obtivermos alguma novidade sobre o assunto.

Sem problema.