Variáveis LOCAL ou PRIVATE, compilar com /N e /W

[clodoaldomonteiro]

Conforme dica do Malígno, estou analizando meu sistema quanto as variáveis e estou declarando como LOCAL aquelas que serão vistas somente pela procedure que as criou, e PRIVATE aquelas que serão vistas pela procedure que as criou e pelas demais funções que serão chamas por esta procedure.

Aquelas variáveis que usarei em um get, devo declarar como PRIVATE.

Quando uso :=, para declarar as variáveis, elas serão declaradas automaticamente como LOCAL ou PRIVATE?

Tem uma maneira de obrigar a compilação do clipper travar se uma variável não foi declarada previamente?

Quando a procedure sai da memória, volta para o menu de opções, todas as variáveis criadas dentro dela serão apagadas da memória?

Ao compilar com /W a única ajuda que temos do compilador é o fato dele dizer que falta declarar as variáveis, mas pergunto se o sistema vai funcionar mesmo assim?

E com /N, teriamos que colocar no início dos arquivos .prg a expressão PROC NOME_PROCE, isso tem algun ganho de performance ou é sómente para organização?

[Maligno]

Quando uso :=, para declarar as variáveis, elas serão declaradas automaticamente como LOCAL ou PRIVATE?

Se o qualificador não for especificado, PRIVATE.

Tem uma maneira de obrigar a compilação do clipper travar se uma variável não foi declarada previamente?

Não. XBase é uma linguagem fracamente tipada. Daí um dos motivos para a abundância de erros (principalmente de lógica) que se vê em certos programas.

Quando a procedure sai da memória, volta para o menu de opções, todas as variáveis criadas dentro dela serão apagadas da memória?

Sim.

Ao compilar com /W a única ajuda que temos do compilador é o fato dele dizer que falta declarar as variáveis, mas pergunto se o sistema vai funcionar mesmo assim?

Se a compilação passar sem erros, o funcionamento do programa dependerá apenas da inexistência de erros de lógica.

E com /N, teriamos que colocar no início dos arquivos .prg a expressão PROC NOME_PROCE, isso tem algun ganho de performance ou é sómente para organização?

Esqueça o comando PROCEDURE. Isso nem se usa mais. Use apenas FUNCTION. A razão disso é principalmente operacional. Ao contrário do que ocorre com funções, as procedures não permitem o retorno de valores.

[clodoaldomonteiro]

Malígno!

Eu tenho que usar sempre:

Código: Selecionar todos

MEMVAR VAR1,VAR2,VAR3...
PROC MAIN
   PRIV VAR1,VAR2,VAR3 ...
   VAR1:=SPACE(10)
   VAR2:=0
   VAR3:=0
   ...

... ou poss excluir o comando MENVAR, pois o PRIVATE já resolve tudo?

O que eu num tô entendendo é a necessidade de usar MEMVAR e PRIVATE, e depois ainda tenho que usar := na declaração das variáveis.

Tenho um amigo que disse que depois de usar LOCAL, PUBLIC e PRIVATE o sistema compilado ficou menor e consequentemente mais rápido, essa afirmação seria verdadeira?

[Maligno]

Nunca uso MEMVAR. Dá uma lida no help do comando e você vai ver que este comando é perfeitamente dispensável.

Não existe necessidade de usar MEMVAR e PRIVATE. A coisa é simples: declare sua variável, qualificando-a quanto a forma de armazenamento (LOCAL, PRIVATE ou PUBLIC). Só isso. Aliás, sempre que puder, use LOCAL.

Tenho um amigo que disse que depois de usar LOCAL, PUBLIC e PRIVATE o sistema compilado ficou menor e consequentemente mais rápido, essa afirmação seria verdadeira?

Não sei dizer se é verdade ou não. Nunca percebi qualquer diferença. Até por quê, eu me obrigo a qualificar todas as variáveis já há muito anos. Naquela época tudo era lento mesmo.

[janio]

Colegas,

Se eu não declarar como PUBLIC, LOCAL ou PRIVATE uma variável, apenas criá-la como sendo: xVariavel = 0, essa variável será criada como PRIVATE, correto???

Qual é a utilidade de :=? ou qual a diferença entre = e :=

Jânio

[Adalberto]

A diferença do = com o operador: = é baseado em que: = pode atribuir valores às variáveis dentro das sentenças e de atribuir um mesmo valor mais do que uma variável simultaneamente. Exemplo:

Código: Selecionar todos

nNum1 := nNum2 := nNum3 := 0.00
WHILE  ( nNum1 := INKEY( 0 ) ) # 13
	@ 10,10 SAY nNum1
ENDDO

[Maligno]

Variável sem um especificador de classe de armazenamento será sempre PRIVATE.

O operador = serve tanto para atribuição como para teste de igualdade (dependente de SET EXACT). O operador == apenas testa igualdade exata (não depende de SET EXACT).
O operador := se presta à atribuição apenas, mas com a vantagem de também permitir uma atribuição dentro de expressões complexas.

[clodoaldomonteiro]

Estou tentando compilar com as opções /m/w e tô declarando todas as variáveis do sistema com LOCAL, PRIV e PUBL, mas ainda assim tá mostrando na compilação o aviso C1004.

Como devo proceder nesse caso?

[Maligno]

Eu não uso /W. Dispenso. Mas, se quer usar, não é tão ruim quanto parece. Você só precisa tomar alguns cuidados. O primeiro e mais importante, parece que já está fazendo: declarando um especificador de classe de armazenamento ao definir a variável. Ótimo. Mas, em virtude da forma como o Clipper vê e controla suas variáveis, os campos de um banco de dados têm um comportamente semelhante e precisam ser explicitamente indicados para evitar o desgramado do C1004. A receita é simples: onde houver um campo de DBF, explicite sua locação, seja prefixando-o com a declaração FIELD-> (área default) ou com o nome do alias ao qual ele pertence, usando também o operador flecha. Sacou?

Pessoalmente, eu JAMAIS deixo de usar o operador flecha. Dou apenas um bom motivo pra isso: lendo o código, rapidamente consigo identificar que se trata de um campo e não uma variável.

[clodoaldomonteiro]

É tô gostando de usar o operador ->, no começo foi difícil mudar, mas depois o entendimento do código fonte muda, a visualização dos campos é muito mais rápida mesmo.

E também tô usando o xDev que dá um tratamento de cor diferente para cada dipo de informação na tela, é show.

Malígno, eu tô perguntando muito sobre qual a melhor maneira de programar, porque quero logo logo muda para o xHarbour, num sei se você usa ele, mais eu tenho que evoluir de alguma forma.

Acho que tenho que aprender o máximo possível para não demorar muito.

O xDev já até tem script para harbour, então vai ficar mais fácil.

Hoje tô empacado com a função do getsys 'getpostvalidate()', que faz a validação dos gets, mais como eu alterei o getsys para tratar campos senhas com o PICT '@P', deu pau no valid, é um tal de um code block "oget:postblobk", eu não consigo enchergar o seu conteúdo.

Tem como visualizar o conteúdo desse code block da função getsys?

Desde já agradeço a ajuda.

[Maligno]

É tô gostando de usar o operador ->, no começo foi difícil mudar, mas depois o entendimento do código fonte muda, a visualização dos campos é muito mais rápida mesmo.

Um detalhe que não sei se você sabe, mas que também ajuda: uma função que trate ou utilize campos de um DBF também pode utilizar um alias com o operador flecha. Exemplo: CLIENTES->(AltDados()). Na função você pode usar os nomes dos campos sem definir explicitamente a qual DBF eles pertencem. Isso aumenta bastante a flexibilidade.

Malígno, eu tô perguntando muito sobre qual a melhor maneira de programar, porque quero logo logo muda para o xHarbour, num sei se você usa ele, mais eu tenho que evoluir de alguma forma.

Não uso e nem pretendo usar o [X]Harbour. Mas evoluir desta forma é sempre muito bom. Boas práticas de programação você utiliza em qualquer linguagem.

Tem como visualizar o conteúdo desse code block da função getsys?

Só lendo o fonte.

[Maligno]

Um complemento: dentro daquele exemplo CLIENTES->(AltDados()), o alias se manterá para toda e qualquer função executada por AltDados(), exceto se outra área for explicitamente indicada, seja pela sua seleção ou por meio de um alias.

[clodoaldomonteiro]

O code block que tô falando tá dentro da getsys do clipper, mais precisamente dentro da função getpostvalidate(), a variávei é get:postblock.

Eu num consigo visualizar o conteúdo dessa variável, mas a rotina funciona perfeitamente se não for get de senha ( pict '@P' ).

Sei que o tamanho da array de get é 13, cada elemento tem uma utilidade, mas não achei o conteúdo passado pelo comando VALID.

Você sabe como ver esse parâmetro passado pelo Valid?

[Maligno]

A variável get:PostBlock é um codeblock. Por isso, repito: não tem como saber qual é esse codeblock sem ver o fonte.

[clodoaldomonteiro]

Ta certo,

Eu consegui acrescentar campos senhas no getsys sem precisar ver o conteúdo desse code blobk.

Deu muito trabalho, mas ficou mais gostoso quando consegui.