Moderadores: andre_luis, 51, guest2003, Renie
unsigned char loop_do_Mor_al(void*args){
}
// lá no local em que você gostaria de chamar o código
...
while(!loop_do_Mor_al());
...
for (;;)
{
while (chave_fechada && sensor_superior_ativado) // Quando chave acionada, espera o sensor superior indicar nível baixo
{
if (sensor_inferior_ativado) // Espera nível chegar no sensor inferior
ligar_bomba();
}
desligar_bomba(); // Desliga a bomba quando o nível atingir sensor superior ou abrir a chave
}
cfreund escreveu:Não tenha medo do Goto. Esse povo que "torce o nariz" para uma ferramenta, nem deveria ser chamado de programador. Tanto que uma vez compilado, dificilmente um programa não terá um "goto". É uma ferramenta extremamente útil e ajuda bastante na otimização do código.
Enfim, neste caso eu faria da seguinte forma:
- Código: Selecionar todos
for (;;)
{
while (chave_fechada && sensor_superior_ativado) // Quando chave acionada, espera o sensor superior indicar nível baixo
{
if (sensor_inferior_ativado) // Espera nível chegar no sensor inferior
ligar_bomba();
}
desligar_bomba(); // Desliga a bomba quando o nível atingir sensor superior ou abrir a chave
}
xultz escreveu:Uma vez eu peguei o código fonte do kernel linux e fiz um grep -R goto * e fiquei impressionado a quantidade de vezes que o goto é utilizado.
Em situações apertadas, onde se precisa de velocidade, código enxuto ou ambos, o goto pode ser a melhor solução. Se o Linus Torvalds não xingou a pessoa e aceitou o código usando goto, então usar goto talvez não seja pecado.
cfreund escreveu:5 - Remover o while do código proposto.
mastk escreveu:Não gosto de GOTO.....
While(1) e for(;;) são equivalentes, até aonde eu sei, o que muda é menos texto, até aonde eu sei, lembro do conceito de código como risco, quanto menos, melhor.
OK!
Moral, tabela de verdade teria de vir antes do pseudo código, eu penso assim:
Normalmente eu costumo usar um fluxograma. Parto de blocos genéricos com rotinas em um bloco, que abrangeriam muitas linhas de código. Para mim é mais fácil começar assim. É um modo de ver quase que o programa todo em apenas uma página. Aos poucos vou detalhando cada bloco em tantos quantos forem necessários. Tudo em pseudo código, porém direcionado para a linguagem que eu decidi usar. Com o tempo, se eu observar que o fluxograma fica muito complexo. Então eu tento observar as variáveis, tentando fazer a tabela verdade, junto com um diagrama de estados. Dá um pouco de trabalho, mas no fim fica bem mais fácil.
Como exemplo vai em anexo o causador desse tópico. No final fiz uma tabela verdade, que usava 6 sensores em 3 caixas d'águas e 2 bombas controlando o nível das caixas. Foram 64 linhas de tabela verdade.
Se fosse seguir apenas a tabela verdade, eu já teria uma substancial redução do fluxograma e, consequentemente, do programa. Ocorre, que observando a tabela verdade, notei que algumas linhas eram redundantes e outras eram impossíveis de existirem. Algo como o sensor superior da caixa d'água informar que a água chegou nele e o sensor inferior informando que não havia água nele. Fiz apenas dois mapas de Karnaugh (2x2)e tudo se simplificou.
Conclusão só seria necessário testar 4 situações, para ligar ou desligar cada uma das duas bombas.
-Texto com o objetivo do código.
-Rascunho de lógica e estruturas. (Tabela de verdade, desenhos, propostas e conceitos).
-Pseudo código.
-Código.
Máquina de estados é uma técnica que pode ser trabalhosa, tem que ver se vale a pena no seu problema.
Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante