Simon Viegas

Complementando: Como sabido, o então e não (com ~) não funcionam no VisualG. Esse acento é colocado aqui no Fórum por causa de um "corretor automático". Basta substituir pela palavra correta. Exemplo: Pressiona "Ctrl-U": E substitui tudo ou vai analisando um a um... O não como só tem um, basta editar manualmente. Sobre: Esta expressão está incompleta. A negação seria da expressão toda, e não só da sentença ao lado. A linha acima seria, tecnicamente, igual a: se ((não (operacao = "S")) OU (operacao = "C") OU (operacao = "T")) então Ajustando poderia ficar com algo assim: se não ((operacao = "S") OU (operacao = "C") OU (operacao = "T")) então Ou seja: "nego o resultado da expressão". ou se (não ((operacao = "S") OU (operacao = "C") OU (operacao = "T"))) então Ou ainda negando a expressão em si no código: se ((operacao <> "S") E (operacao <> "C") E (operacao <> "T")) então Dá na mesma. As 3 expressões são logicamente equivalentes. Adendo: "ah! porque está funcionando? Eu testei tudo e foi de boa". Pelo simples fato do VisualG ser bugado! . Tenho quase certeza que isso não é proposital. Seria uma falha no interpretador da execução.

Pelo visto não teve respostas... e desculpe pela demora... Então, poste o código completo e em forma de texto... Sobre: Está invertido. O vetor de quartos que recebe o nome do hóspede. Só apague essa linha! (Vai usar a outra de baixo.) Sobre: Conforme o item 4, você vai exibir o nome do hóspede, e não "Ocupado". Cada posição do vetor quarto já começa com o texto "LIVRE". Daí, ao atribuir um hóspede, o programa deve jogar o nome do cliente na posição desejada, ou seja, em vez de "Ocupado", use nomes[indiceHospede]. Abaixo detalhes: O vetor quartos vai armazenar ou "LIVRE" ou "<O nome do hóspede>", daí simplesmente vai exibir o que está lá no vetor. Ao iniciar o programa, todos os quartos devem ter o texto "LIVRE". A medida que for cadastrando um hóspede no quarto, esse texto vai ser substituído pelo nome cliente. Lembrar de postar o código completo.

Ok!. Qual dúvida? Seria interessante citar qual parte não está entendendo e postar o código completo. Vamos lá: Segue o que foi implementado: Comece ajustando a nomenclatura da função de exibir os hóspedes. O nome da função seria no plural. Ajuste de: Para funcao exibirHospedes() { Adendo: não confundir o que foi postado lá no outro tópico. Veja: Lá estávamos trabalhando com variáveis simples. Tratando a demanda como se fosse um único cadastro. Veja que não tem vetor ainda! (Analise o contexto do código lá.) Outro detalhe que esquecemos de exibir o índice. É o que está sendo exigido lá na parte 3. Algo como: funcao exibirHospedes() { para (inteiro posicaoVetor = 0; posicaoVetor < i; posicaoVetor++) { escreva("*** DADOS DO HÓSPEDE ***\n") escreva("\n Índice: ", posicaoVetor) escreva("\n Nome: ", nomes[posicaoVetor]) escreva("\n CPF: ", cpfs[posicaoVetor]) escreva("\n Quantidade de Dias: ", qtdDiarias[posicaoVetor], "\n") } } Seguimos com a leitura do índice que consta lá: Índice e nome são coisas distintas. Que tal?: escreva("Índice do Hospede? ") leia(indiceHospede) Daí vai seguindo o que está determinado no enunciado. Deixe essa parte em vermelho para depois. Faça como sempre fosse digitado valores ideais, ou seja, que não validariam esses se. Depois de testar direitinha, para para inserir essas condicionais. Segue esboço: funcao atribuirHospede() { inteiro indiceHospede, numeroQuarto exibirHospedes() escreva("Índice do Hospede? ") leia(indiceHospede) escreva("Número do Quarto? ") leia(numeroQuarto) } } Termine de implementar a função para atribuir o nome do usuário lá no vetor dos quartos. No caso, o nome dele estará na posição correspondente. Algo como: nomes[indiceHospede] Joga lá no vetor de quartos. Tente dar continuidade. Caso tenha dúvidas, poste o código completo e qual dúvida tem.

Talvez ali seja >= 60, pois seria algo como "maior de 60 anos", ou seja, quem tem 60 já teria direito. Na prática, quem tem 60, "têm mais de 60 anos". Após aniversário, passaram 1s, 2s, 1 mês etc.... Saca? Do jeito que está, apenas pessoas com 61 anos teriam gratuidade. (Se esse for o caso, está certo :D) Adendo: A depender da linguagem de programação, pode dar problema essa não separação das instruções do se. Sugeriria algo assim: se ((idade < 5) ou (idade > 60)) { Acho que também fica mais claro... eliminando a ideia de pensar em algo como "5 ou idade". ou assim: se (idade < 5) ou (idade > 60) { Obs.: talvez esse acima não funcione, pois o compilador pode exigir os "()" externos.

Você está utilizando a mesma variável para duas coisas distintas. Poderia utilizar nome1 e nome2, por exemplo.. No caso lá vai perder o nome do usuário. Outro ponto é buscar seguir boa semântica para as nomenclaturas de variáveis. Exemplo: var nome, personagem: caractere Ou melhor ainda: var nomeUsuario, nomePersonagem: caractere Segue um exemplo de base de código: algoritmo "Interação com usuário" var nomeUsuario, nomePersonagem: caractere inicio escrevaL("|----------------------------------------------------|") escrevaL("| Conhecendo personagens bíblicos! |") escrevaL("|----------------------------------------------------|") escrevaL(" ") escreva (" Para começar me diga seu nome, por favor: ") leia(nomeUsuario) escrevaL(" ") escrevaL(" Olá!, ", nomeUsuario, ". Paz do senhor :)") escrevaL(" ") Escreva (" Qual personagem bíblico você gostaria de conhecer? ") leia(nomePersonagem) se (nomePersonagem = "Paulo") então escrevaL(" Historia de Paulo ") senao se ((nomePersonagem = "João") OU (nomePersonagem = "JOÃO") OU (nomePersonagem = "Joao")) então escrevaL(" Historia de João ") senao escrevaL(" Outro personagem") fimSe fimSe fimAlgoritmo Adendo: o VisualG não é case-sensitive para as comparações. Funciona como se o computador sempre comparasse as cadeias de caracteres todos em maiúsculas. Daí tanto faz, por exemplo, Paulo, paULo, paulo etc quando for digitado pelo usuário ou como quiser colocar dentro do se (pois "tudo seria transformado" em PAULO na hora de comparar). Já os acentos são diferenciados. Teria que fazer uma combinação, como no exemplo acima. Adendo do adendo: se ligue que o que precisou ser diferenciado foi apenas o "ã" e o "Ã" (incluir sem acento pois pode ocorrer, aí vai de você querer aceitar ou não apenas a escrita com acentos), o restante da cadeia não importa se está maiúsculo ou não. (Tipo: vai comparar sempre JOAO e depois JOÃO.) Adendo do adendo do adendo: esse "problema" com as letras com acentos ocorre porque o "algoritmo nativo de tornar maiúsculo" não sabe ou não quer cuidar de acentos... Veja: (Na imagem acima, foi utilizada a função Maiusc() para escrever a palavra "João" em maiúsculo na tela. O resultado foi "JOãO". (Em detrimento do que pareceria ser mais lógico: JOÃO.)

@Ramon2023n, sugeriria abrir um tópico novo. Daí posta o que conseguiu fazer e em qual parte está com dúvidas.

Sim. As variáveis são globais, pois elas estão no escopo global. São enxergadas por todo programa, mas o problema é outro. Está relacionado ao fluxo do algoritmo. Resumidamente: para o contexto, essas variáveis precisam ser reinicializadas a cada verificação de primo, pois a cada verificação elas precisam ter determinados valores iniciais (requisito do algoritmo da tal verificação). Veja: Assim, a variável é inicializada apenas uma vez (o algoritmo fica errado)... simplesmente por "está fora do laço de repetição". Se colocar em algum lugar dentro do loop (dentro do repita) e que esteja antes de ser utilizado lá no caso 2, vai funcionar. Exemplo: repita escreval("Menu") escreval("1. Inserir número") escreval("2. Verificar se é primo") contarDivisor <- 0 escreval("3. Sair") escreval("Escolha uma opção:") leia(opcao) contador <- 1 escolha(opcao) caso 1 escreval("Digite o número:") leia(numero) caso 2 se numero <= 1 então escreval(numero, " não é primo.") Ou seja: antes de entrar no caso 2, a cada loop, necessariamente vai inicializar as duas variáveis que preciso lá... o problema de ficarem fora do caso 2 (dentro do repita, mas fora do escopo do caso 2) é que vai ser reinicializar sempre... mesmo que escolha o caso 1. Na prática não vai perceber diferença nenhuma na execução, mas tecnicamente seria um "desperdício de recurso", entende? Para que inicializar se não vai ser utilizada no caso 1? Para avaliação da lógica, seria considerado um erro. Mais correto é ficar dentro do caso 2 mesmo. Deixando dentro do caso 2, vai ser inicializado apenas quando precisa. Ah!, mas se no caso 1 também utilizasse essas mesmas variáveis? Aí poderia inicializar uma vez em cada caso, ou inicializaria antes do escolha. Aqui as duas formas poderiam seriam válidas. Teria que avaliar o que ficaria mais interessante. RESUMINDO: Assimile que o fluxo de execução execução do VisualG é "da esquerda para direita, de cima para baixo". Vai executando linha por linha. Daí, para o algoritmo funcionar corretamente, as instruções precisam está numa sequência válida para o contexto do algoritmo em si. Adendo 1 Segue uma demonstração de porque não funciona se colocar ANTES do repita: O VisualG vai executar linha por linha... quando chega num leia(), o programa para., pois fica aguardando o usuário informar o valor. Nesse momento, as variáveis estão com 0 e 1 respectivamente, pois foram os valores que acabaram de ser atribuído mais acima. Inseri um valor qualquer...: 123. O programa volta para o menu e vou para a opção 2. Verificado se é primo. Após o resultado, o fluxo do programa voltar novamente para próximo linha após o repita... mostra o menu e pede para informar a nova opção. Veja como estão os valores das variáveis!!! Oras, ao informar um novo número (ou tentar verificar novamente o mesmo), essas variáveis, essenciais para a lógica de verificação, estarão com o "lixo" da execução anterior, comprometendo o resultado. Não é pela quantidade de divisores que teu algoritmo verificar se é primo? Dessa forma, sempre que for digitado um valor maior que 1, será executada a linha abaixo: Portanto, contarDivisor será atualizado e o algoritmo parará de funcionar corretamente, pois a variável terá um valor maior que 2 acusando para qualquer outro novo valor, que não é primo! Adendo 2: Na sintaxe do escolha, cada caso não tem esses ":". Basta removê-los. Adendo 3: para entender melhor o fluxo, experimente diminuir a velocidade de execução. Exemplo: inicio timer 300 contarDivisor <- 0 contador <- 1 repita escreval("Menu") escreval("1. Inserir número") escreval("2. Verificar se é primo") Defina a velocidade que quiser... o número ali depois do timer é em milissegundos.

Precisaria do restando do código para analisar melhor.

Basicamente utilizando um laço de repetição. Conceito que já está utilizando. Entenda assim: o VisualG é um interpretador de código, que vai executando linha a linha... daí, como quer "voltar", teríamos duas opções: ou de alguma forma fazer "pular" para a linha anterior desejada (conceito de label), ou deixar o trecho do código dentro de um laço de repetição, dessa forma, ao finalizar um laço dessa repetição, o interpretador entenderia que deveria ir para o início do laço. Na prática, basicamente isso: inicio repita escrevaL(" MENU PRINCIPAL ") escrevaL("------------------------------------------------") escrevaL("1 - LANCHES") escrevaL("2 - ACOMPANHAMENTOS") ... ate (opcao = 0) ... fimAlgoritmo Adendo: você está reutilizando a mesma variável para as opções, o que pode fazer perder informações entre as "telas". Precisa ajustar. Exemplo: algoritmo "Nome ou descrição do programa" var opcao, codItem : inteiro inicio repita escrevaL(" MENU PRINCIPAL ") escrevaL("------------------------------------------------") escrevaL("1 - LANCHES") escrevaL("2 - ACOMPANHAMENTOS") escrevaL("3 - BEBIDAS") escrevaL("0 - PARA SAIR DO SISTEMA") escrevaL("------------------------------------------------") escrevaL("") escrevaL("Insira a opção desejada:") leia(opcao) escreval("") enquanto ((opcao < 0) OU (opcao > 3)) faca escrevaL("Opção inválida, digite novamente:") leia(opcao) fimEnquanto // Segunda tela do cardápio, o Menu de Lanches se (opcao = 1) então repita escrevaL(" LANCHES ") escrevaL("------------------------------------------------") escrevaL("1 - XTUDO------------R$17,00") escrevaL("2 - XBURGUER---------R$15,00") escrevaL("3 - XBACON-----------R$15,00") escrevaL("4 - XSALADA----------R$10,00") escrevaL("5 - XEGG-------------R$10,00") escrevaL("6 - MISTO QUENTE------R$8,00") escrevaL("7 - BIG BAURU--------R$16,00") escrevaL("0 - VOLTAR AO MENU PRINCIPAL") escrevaL("") escrevaL("Insira a opção desejada:") leia(codItem) escrevaL("") ate (codItem = 0) fimSe ate (opcao = 0) fimAlgoritmo Adendo: por uma questão de semântica, utilizei codItem... Nesse caso não teria problema utilizar essa mesma variável para o menu 2, menu 3 etc, percebe? Pois as informações que não podem ser perdidas são as entre "pai e filho", ou seja, entre o item de menu e o menu principal. Daí, se tiver outra opção como "quantidade de item", teria que ser outra variável, como por exemplo: qtdItens. Cada sub-nível dentro do seu próprio mundinho. Adendo 2: veja como fica melhor opcao, codItem e qtdItem etc, em vez de algo como opcao1, opcao2, opcao3 etc.. Fica mais fácil para saber qual variável usar... ficaria estranho utilizar qtdItem lá no menu da escolha do item, saca? Logo, mais prático para se organizar. Adendo 3: o nível de organização vai do enunciado e do que deseja implementar... seguindo uma lógica, se tem "validação de entrada para o menu principal" seria sensato fazer o mesmo para cada sub item de menu lá quando selecionar o lanche. Sugiro ir prezando pera padronização dos conceitos... tende a facilitar.

@DougrasDen, uma dica inicial que dou (lá ele) seria: vá implementando o código aos poucos. Faz um pouco e testa, faz um pouco e testa... Já evitaria esse problema... veja: Vou me basear pela versão 3.0.6.5 do VisualG. Meio que versão padrão. Basicamente não existe o comando fim no VisualG, ou seja, assim que tivesse implementado essa função, já veria que o problema estaria nela. O erro citado ocorre porque o VisuaG não está conseguindo montar a função, daí apresenta problemas tudo! (O VisualG não compila códigos, ele vai interpretando linha por linha... por isso os erros apresentados nem sempre ficam claros.) Só corrigir: funcao lancarDado(): inteiro var face: inteiro inicio face <- aleatorio(1, 6) retorne face fimFuncao Pronto! Resolveria o erro informado. Aí vai vendo os outros pontos... Ah! Ao testar essa função, verás que a sintaxe do aleatorio está em inconformidade. Essa estrutura não vai rodar... aí pararia para entender e corrigir... mais abaixo dou uma solução. OK. Ainda nesse sentido de implementar aos poucos, veja como seria mais fácil identificar que existe outro problema análogo. Ou seja: "ué? Por que não funcionou? Ah! Porque ali é fimAlgoritmo". Após corrigir, veria que rodaria normalmente.... Entende? A medida que vai implementando algo novo, já testa... com o tempo vai pegando as manhas e vai testando menos... Daí precisaria ter a noção que provavelmente os erros que ocorrem seriam a partir que está implementando agora, "pois o que já está no código meio que já estão testados...". Vamos seguir esse exemplo de implementando aos poucos... Opa! Rodou, mas o leia() não funcionou. O código passou direto. Só entender o problema e tentar corrigir. Exemplo: Resumidamente, precisaria usar uma variável qualquer... no VisualG não funciona o leia() puro; (No Pascal funciona.) Observe que a ideia aqui é que não deve fazer sentido um algoritmo ter diversos erros distintos, pois alguns desses erros não eram para deixar evoluir... já vai tentando deixar pelo menos rodando sem erros de sintaxe... Vai implementando e testando.. outro ponto: No VisualG NÃO É possível deixar dois comandos "distintos" na mesma linha. Necessariamente precisa ficar abaixo. (Obs.: no Pascal, pai do VisualG, pode! Aqui não.) Seria: senao se soma = 2 ou soma = 3 ou soma = 12 então escreval("Você perdeu!") Aqui deve surgir outro problema... que seria a "separação das instruções do se". Pode ser que não dê erro (tenho quase certeza que dá). Usaria algo como: se (soma = 2) OU (soma = 3) OU (soma = 12) então escrevaL("Você perdeu!") Eu particularmente deixo meus se com um parêntese principal. Ficaria assim: se ((soma = 2) OU (soma = 3) OU (soma = 12)) então escrevaL("Você perdeu!") Atenção: todo se tem o seu fimSe correspondente. Precisa ter atenção nisso. Sobre o problema lá do aleatório. Poderia fazer algo como: funcao lancarDado(): inteiro var face: inteiro inicio face <- randI(6)+1 retorne face fimFuncao Existem outros probleminhas. Aí tem duas opções: ou refaz o código do zero. Implementando os poucos... vai pegando o que já fez como base, mas recomeçando do zero mesmo. ou vai testando e descobrindo os problemas, e corrigindo aos poucos. Acho que dá mais trabalho. O melhor dos mundo seria fazer as duas coisas. Que aí treinaria bastante. Qualquer dúvida é só postar.

Qual erro? Basicamente seria isso: foque no problema. Entendendo o problema, fica mais fácil achar uma solução. Um detalhe: Faltou o comando inicio após a declaração das variáveis e início da execução principal. Exemplo: algoritmo "Nome do meu programa" var opc, oplanch, opacompanhamento, opbebida, qtd : inteiro vlLanch, vlAcompanhamento, vlBebida : real Lanches, Acompanhamento, Bebidas, Total : real inicio Total <- 0 opc <- 0 Um outro detalhe é que, ao finalizar um item do menu e volta para o menu principal, está informando o "valor do pedido"... o que para mim ficou estranho, já que ainda não finalizou o pedido. Seria "um subtotal dessa categoria"? De um modo geral, seria necessário seguir o que está no enunciado. É ele que define o que se deve fazer. Mesmo que o programa esteja rodando tudo certinho, precisa fazer o que se pede. Posta o enunciado e qual o erro específico que foi relatado. Adendo: Entendo que não existe uma regra de padrão de escrita para o Portugol (do VisualG), ou seja, poderia utilizar o padrão que quiser. O ponto que levantaria seria manter um padrão... deixar uma estrutura mais uniforme e organizada. No VisualG poderia usar camelCase, PascalCase, snake_case etc. Particularmente recomendo o camelCase, mas o uso do snake_case também é bem popular... Só recomendo muito o uso do PascalCase... de um modo geral não fica agradável para mim... Obs.: em algumas linguagens de programação, é meio que obrigatório alguns padrões específicos, caso contrário, o código não compila, ou seja, essa forma de escrita fazendo parte da sintaxe em si.

@juanitokol, comece fazendo os exercício que o próprio professor deve está sugerindo para fazer. De um modo geral, existem três tipos de laços de repetição no VisualG: Repita; Enquanto; Para. Estude um pouco mais sobre um deles. Qual qualquer um. Daí tente fazer exercícios. Caso tenha dúvidas, poste o enunciado, o código completo e em qual parte está com dúvidas. No aguardo.

@Bruno Pz, me parece que ficou tudo certinho! Muito bom! Adendo: apenas o detalhe que dá BO se tiver mais 400 anos ou se nasceu no ano corrente (idade 0). Adendo 2: como observável, a lógica independe da linguagem. O que muda aí é que o C teve estruturas que facilitaram/aprimoraram o algoritmo, por exemplo, com a coleta da "data" atual. Não programo em C, mas vou tentar explicar o que eu entendi da estrutura: O time() retorna o "dados de data atual" em determinado formato. O "localtime() usa a hora apontada pelo timer para preencher a variável tm com os valores que representam a data/hora correspondente passada pelo parâmetro", ou seja, foi declarado a variável tm (o C permite e eventualmente resolveu utilizar a mesma nomenclatura da struct. Poderia ser outra!), que por sua vez é do tipo (struct) tm (algo nativo de alguma biblioteca)... e na mesma linha já definiu que seu valor vai ser igual ao retorno do tal localtime(). Portanto, a variável tm terá em si os dados de data/hora preenchidos, assim posteriormente podendo coletar o ano, mês e dia de forma mais simples (acessando os campos da struct da variável). a struct tm teria essa estrutura: struct tm { int tm_sec; /* seconds, range 0 to 59 */ int tm_min; /* minutes, range 0 to 59 */ int tm_hour; /* hours, range 0 to 23 */ int tm_mday; /* day of the month, range 1 to 31 */ int tm_mon; /* month, range 0 to 11 */ int tm_year; /* The number of years since 1900 */ int tm_wday; /* day of the week, range 0 to 6 */ int tm_yday; /* day in the year, range 0 to 365 */ int tm_isdst; /* daylight saving time */ }; Só para deixar mais claro... segue o exemplo: time_t t = time(NULL); struct tm nome_que_eu_quiser_incluse_tm; nome_que_eu_quiser_incluse_tm = *localtime(&t); printf("Digite o nome completo do aluno(a): "); fgets(nome, 100, stdin); printf("Digite a data de nascimento (dd mm aaaa): "); scanf("%d %d %d", &dia, &mes, &ano); idade = nome_que_eu_quiser_incluse_tm.tm_year + 1900 - ano; if (nome_que_eu_quiser_incluse_tm.tm_mon + 1 < mes || (nome_que_eu_quiser_incluse_tm.tm_mon + 1 == mes && nome_que_eu_quiser_incluse_tm.tm_mday < dia)) { idade--; } Observem que isso: struct tm nome_que_eu_quiser_incluse_tm; nome_que_eu_quiser_incluse_tm = *localtime(&t); foi para exemplificar que é a mesma coisa que isso: struct tm nome_que_eu_quiser_incluse_tm = *localtime(&t); Quem puder me corrigir/complementar em algo, também agradeço. Adendo 3: o Portugol seria apenas uma forma de "pescar" os estudantes... utilizando do nosso idioma como chamariz. Passou um pouquinho do nível iniciante, melhor coisa é partir para algo mais avançado e robusto mesmo! Como observável, tirando a parte da "coleta da data atual", que não é especificamente trivial os detalhes, o restante é basicamente a mesma coisa, só mudando a sintaxe dos comando (de português para inglês e com formas e ordem divergentes). Só isso. Em relação ainda à parte da data, também não tem mistério.. seria só "como pego a data atual do sistema em C?". Daí só "copiar" a estrutura! Ninguém precisaria dominar os detalhes em C ou qualquer outra linguagem para utilizar recursos... o que tentei explicar/comentar acima, seria apenas uma forma de tentar "aprofundar" e entender mais ou menos como funcionaria as coisas... mas se não quisesse entender detalhes, também seria de boa.. apenas precisa entender lá na parte de usar os campos do tm. Tipo: Saber como isso funciona não é tão relevante (mais é interessante): Pois podem-se abstrair e saber que pode fazer isso: idade = tm.tm_year + 1900 - ano; Ou seja: o que "me importa" é que vou ter uma variável que nela tem esses dados de data que preciso. Ah! só para finalizar essa questão da abstração, seria algo como: struct tm tm = *localtime(&t); Esse struct tm seria como se fosse um tipo em si... como se fosse algo assim: int tm = *localtime(&t); Espero que não tenha viajado d+...

@juanitokol, show! Parabéns! Alguns pontos: basicamente no início é vai aprendendo a ter mais atenção aos detalhes. É normal não "enxergar" todos no início. Faz parte da aprendizagem conseguir focar melhor neles. Por exemplo: Veja: n3 é uma variável. Daí você definiu para comparar com outra variável de nomenclatura s. Depois colocou para compara com a variável n. Você nem declarou essas variáveis. Daí, pelo contexto, fica claro que queria comparar com o caractere "s" ou "n"... ou com a cadeia de caracteres "sim" ou "não", correto? Para tanto, usam-se justamente as "aspas duplas". se (n3 = "s") então Pense assim: como o computador iria diferencia s (variável) de s (caractere)? As aspas duplas estão servindo para isso! Como estava sem aspas, o computador pensa que é uma variável ou algum comando da linguagem. Ah! Observe que a segunda expressão (n3 <> "n") não é necessária. Ou se quiser incluir o "sim": se ((n3 = "s") OU (n3 = "sim")) então Desse forma... se informar "s" OU (disjunção) se informar "sim", a expressão vai resultado VERDADEIRO. Quaisquer outros valores resultaram em FALSO. Caso queira o contrário, ou seja, qualquer valor diferente de "n" aceite como verdadeiro, aí só ajustar a expressão: se (n3 <> "n") então Nesse caso, qualquer valor que não seja "n" vai resultar em VERDEDEIRO. O contrário resultará em FALSO. Se incluindo o "não": se ((n3 <> "n") E (n3 <> "não")) então Observe que aqui está utilizando E (conjunção), pois seria para "uma resposta diferente de 'n' E também diferente de 'não'". Segue umas dicas gerais: - utilize nomenclatura de variáveis mais sugestíveis; - sugiro um pouco mais de atenção com o nosso idioma (português). Assim com o Portugol, ela também é uma linguagem com regras... precisam* ser seguidas, sobretudo sobre "acentuação". algoritmo "Meu primeiro programa" var nome, resposta : caractere numero1, numero2, resultado : inteiro anoNascimento, anoAtual, idade : inteiro inicio escreva (" Olá! Qual é seu nome? ") leia(nome) escrevaL(" ", nome, ", como está?") //pergunta retórica! escreva (" Bora brincar de calculadora? [s/n] ") leia(resposta) se (resposta = "s") então escreva (" Primeiro número: ") leia(numero1) escreva (" Segundo número: ") leia(numero2) resultado <- numero1*numero2 escrevaL(" O resultado foi ", resultado:1) senao escrevaL(" Então irei calcular a tua idade ") escreva (" Em que ano você nasceu? ") leia(anoNascimento) escreva (" Em que ano estamos? ") leia(anoAtual) idade <- anoAtual-anoNascimento escrevaL(" Tua idade é ", idade:1) fimSe fimAlgoritmo Qual dúvida é só postar.

São duas coisas distintas. [1] erro de compilação; [2] atender aos requisitos. Vou tentar detalhar cada uma delas. Sobre o erro: qual erro está dando? A partir do erro verificado, tenta entendê-lo: Ou seja, o esperado seria que visse esse erro, tentasse entender e depois tentar solucionar. Caso não, aí citaria o tal erro no fórum. O que quero dizer: é menos didático os colegas pegarem o código, testar, descobrir qual o suposto erro que está enfrentando, e depois dar uma sugestão de solução. Melhor já entender do que se trata e ser específico (tanto para tentar resolver sozinho, tanto para pedir auxílio). O erro fala sobre algo relacionado à inicialização da variável x_ingresso. Como sugerido pelo @devair1010, eventualmente esta variável precisa ter um valor inicial, mas você "não inicializou ou ela pode não ser inicializa no percurso", ou seja, ali na linha 25, essa variável está sendo usada para ser impressa, correto? Mas, tecnicamente, a execução poderia chegar lá sem ter um valor para essa variável... Como assim? O compilador entende algo assim: "vixe, pode ser que o computador tente imprimir uma variável sem que ela tenha tido um valor inicial. Não vou deixar compilar". Variáveis seriam apenas "espaços de memória". Se a variável não for inicializada, ela estaria com o lixo de memória antes do espaço ser reservado, aí podendo bugar o programa. O segredo do problema está nesse trecho: se (lucro > lucro_maximo) { lucro_maximo = lucro x_ingresso = ingresso numero_ingressos_max = numero_ingressos } Observe que a variável x_ingresso estaria para receber um valor, ou seja, seria inicializada (e não daria erro de compilação). Entretanto, o comando está dentro de um se, que por definição é uma estrutura de seleção, logo, podendo ser executado o que está dentro do se ou não. O compilador protege de uma má execução do programa!!! Além disso, esse se está dentro de um para, que tecnicamente pode ser que sequer inicie o loop... Esses são os motivos para o compilador te forçar que a variável x_ingresso tenha algum valor inicial antes de ser utilizada o valor. Adendo: para deixar claro, sempre em algum momento as variáveis precisam primeiro receber um valor qualquer antes de ser usado para cálculo ou exibição. Se ela já recebe durante o fluxo, não precisa "inicializar" na declaração. Veja por exemplo a variável ingresso. Não precisa! RESUMINDO: Em relação à sintaxe, só é preciso inicializar as 3 variáveis que estão sendo impressas: E a variável que está sendo utilizada no cálculo: O restante NÃO precisa. Não precisa nem preocupar quando deve inicializar ou não.. se não compilar, vai lá e inicializa. Isso é bom que vai acostumando com os erros!!! Observe que a variável valor_ingresso é inicializada no para, logo, inicializar na declaração ficou redundante. RESUMO DO RESUMO Se atente ao erro informado. Geralmente é um bom indicativo do que exatamente está ocorrendo. Daí, aplica o sugerido, mesmo que eventualmente não entenda o motivo do erro, mas já saberia que por algum motivo está precisando que inicialize, daí, só inicializar. DICA: Não inicialize as variáveis por inicializar (nada de "vou inicializar logo aqui para evitar erro"). Deixe o compilador dar erro mesmo e tente entender o motivo. Com o tempo se acostuma e aí inicializaria sabendo do que está fazendo. Sobre os requisitos: quais requisitos faltam? Oras! provavelmente, se não estava compilando, você meio que não conseguiu testar muita coisa. Mete mão aí. Testa, tenta entender o que ocorre e daí busca uma solução caso necessário. Mas sempre tente primeiro entender o problema!!! Tendo dificuldades, informa qual é... (tipo, não funcionaria muito bem um só "não consegui resolver" ou algo do tipo, saca?)

@wil0, sugiro que crie uma nova postagem com tua dúvida. Daí posta o enunciando do teu contexto, o que já conseguiu fazer e onde estaria precisando de ajuda.

Se estiver estudando enquanto... pode usar ele mesmo! Um outro princípio do dia a dia seria: se está estudando sobre um determinado tema, tecnicamente os exercícios são para serem aplicados com ele... mesmo que exista algo mais simples, por exemplo. Isso também parece óbvio depois que percebe. Tipo... se rola um plano de estudos, quando "chegar no estudo do para", ficaria ainda mais claro porque o uso dele seria mais "adequado" para algumas situações (como desse exercício)... O para é para contextos mais específicos (basicamente que tem uma quantidade determinada de repetições), ao mesmo tempo, torna ele mais limitado (menos flexível em nível de condições de parada) que o enquanto ou repita. É análogo ao uso do escolha, que para situações mais específicas, pode substituir bem um conjunto de se/senão, mas fica limitado a poucos casos gerais.

Dúvida: O segredo para resolver qualquer problema é saber do que o problema se trata. Enunciado: Em qual momento estaria solicitando "quais"? Entende? Imagine um cliente pedir um cachorro quente simples num restaurante, daí o garçom entrega um delicioso hambúrguer! "Oras! Meu consagrado, eu te pedi um cachorro quente. O que é isso?". A tua dúvida seria apenas um detalhe para finalizar o algoritmo... mais abaixo exemplifico como poderia ficar. Vou aproveitar para citar como sugeriria criar esboços: - como são 6 números inteiros, ou seja, um quantidade fixa de leitura, ficaria mais simples utilizar para, em vez de enquanto. - para simplificar os testes, utilizar uma quantidade menor, como apenas 2. algoritmo "Quantidade de pares e ímpares" //Crie um programa que leia 6 números inteiros e no final mostre quantos deles //são pares e quantos são ímpares. var i, numero : inteiro inicio para i de 1 ate 2 faca //testando com 2, depois muda para 6 leia(numero) fimPara fimAlgoritmo Daí só adicionar a verificação e exibir o resultado: algoritmo "Quantidade de pares e ímpares" //Crie um programa que leia 6 números inteiros e no final mostre quantos deles //são pares e quantos são ímpares. var i, numero : inteiro qtdPares, qtdImpares : inteiro inicio qtdPares <- 0 //[1] qtdImpares <- 0 para i de 1 ate 2 faca //testando com 2, depois muda para 6 leia(numero) se (numero % 2 = 0) então qtdPares <- qtdPares+1 senao //[2] qtdImpares <- qtdImpares+1 fimSe fimPara escrevaL("Quantidade de pares : ", qtdPares:1) escrevaL("Quantidade de ímpares : ", qtdImpares:1) fimAlgoritmo //1. como está funcionando como um contador, precisa* inicializar as variáveis // obs.: o VisualG já zera automaticamente, mas vai acostumando com a boa prática //2. todo número inteiro OU é par, ou é ímpar. É uma dicotomia, logo, se não // for par, será necessariamente ímpar. Não precisa retestar Sobre "dizer quais são os pares e ímpares", uma forma seria simplesmente exibir: algoritmo "Quantidade de pares e ímpares" //Crie um programa que leia 6 números inteiros e no final mostre quantos deles //são pares e quantos são ímpares. var i, numero : inteiro qtdPares, qtdImpares : inteiro inicio qtdPares <- 0 //[1] qtdImpares <- 0 para i de 1 ate 2 faca //testando com 2, depois muda para 6 escrevaL("Digite o número desejado") leia(numero) se (numero % 2 = 0) então qtdPares <- qtdPares+1 escrevaL("O número ", numero:1, " é par") senao //[2] qtdImpares <- qtdImpares+1 escrevaL("O número ", numero:1, " é ímpar") fimSe escrevaL() fimPara escrevaL() escrevaL("Quantidade de pares : ", qtdPares:1) escrevaL("Quantidade de ímpares : ", qtdImpares:1) fimAlgoritmo //1. como está funcionando como um contador, precisa* inicializar as variáveis // obs.: o VisualG já zera automaticamente, mas vai acostumando //2. todo número inteiro OU é para, ou é ÍMPAR. É uma dicotomia, logo, se não // for par, será necessariamente ímpar. Não precisa retestar Após testar direitinho, muda para 6 números e testa. Ah! para facilitar os testes, é possível gerar números aleatórios. Uma forma simples e rápida seria assim: Para parar, só desativar novamente. Aí vai ajustando até ficar da forma que desejar. ADENDO: lembrando que o enunciado NÃO pede quais são pares ou ímpares, portando não devem ficar na versão final. Um outro exemplo:

A pergunta seria: não conseguindo porque? Qual erro está ocorrendo? Se o erro foi lá no caractere (sem o "e"), o fato de ter uma "linha" abaixo das palavras já indica que tem erro... mas é só remover o "e" no final mesmo. Apenas colei o código e teste: Idem: a mensagem aí já diz o que precisa fazer. Sem mistério. cadeia novoNome = "", nome Por fim... por que raios está inicializando i com 1? Segue um código completo: programa { inclua biblioteca Texto --> tx funcao inicio() { cadeia nome, novoNome = "" caractere letra inteiro i = 0 escreva("Digite o nome a ser criptografado: ") leia(nome) faca { letra = Texto.obter_caracter(nome, i) se (letra == 'A' ou letra == 'a') novoNome = novoNome + "1" senao se (letra == 'E' ou letra == 'e') novoNome = novoNome + "2" senao se (letra == 'I' ou letra == 'i') novoNome = novoNome + "3" senao se (letra == 'O' ou letra == 'o') novoNome = novoNome + "4" senao se (letra == 'U' ou letra == 'u') novoNome = novoNome + "5" senao se (letra == ' ') novoNome = novoNome + '#' senao novoNome = novoNome + letra i = 1 + i } enquanto (i < Texto.numero_caracteres(nome)) escreva ("O nome criptografado: ", novoNome) } } Sugestões de melhorias: o que está sendo coletado no obter_caracter(nome, i) não é uma letra, mas sim um caractere, logo, o nome da variável não está semântica. Mude para outra, exemplo: caract ou algo que remeta a "caractere". como a laço de repetição tem um limite determinado, alteraria de faça/enquanto para para; em vez de uma cadeia de se/senao, utilizar escolha/caso. Adendo: o corretor do Fórum está inserindo o "e" no final de caractere, mas no Portugol Studio não tem!

@Jackson Vanutty, você está estudando VisualG ou Portugol Studio? Isso vai apenas influenciar na hora de implementar. Mas a lógica para resolver NÃO DEPENDE DE LINGUAGEM DE PROGRAMAÇÃO. Você precisa pensar em como resolveria isso, por exemplo, no papel. Quais passos que poderiam ser feitos para transformar Maria Santos em M1r31#S1nt5s? Pense numa solução e descreva na sua resposta. Para adiantar, caso já tenha algo em mente em como resolver, é só traduzir para a linguagem escolhida. Um exemplo de esboço para VisualG: Algoritmo "Criptografia de nomes" // Disciplina : // Professor : // Autor(a) : Jackson Vanutty // Data atual : 14/05/2023 // Enunciado : //Faça um programa para criptografar o nome de uma pessoa. O programa deverá //ler o nome e mostrar o novo nome criptografado. A cifração ou encriptação //deverá ocorrer apenas sobre as vogais A, E, I, O, U e sobre o caractere //espaço (em branco), quando houver. As vogais deverão ser substituídas //respectivamente pelos algarismos 1, 2, 3, 4, 5 e o caractere espaço deverá //ser trocado pelo caractere cerquilha (#). //Exemplo: A cifração do nome Maria Santos seria M1r31#S1nt5s //OBS: É vedado o uso de vetor/matriz ou algum outro tipo estruturado de dado. //O Portugol Studio/Visualg possuem funções para manipulação de string (cadeia //de caracteres). Utilize-as para resolver as questões a seguir, caso //necessário. var nomeOriginal, nomeCriptogrado : caractere inicio escrevaL("Informa o nome a ser criptografado") leia(nomeOriginal) //Aqui você implenta um lógica que fará o solicitado no enunciado //Abaixo um exemplo que simplesmente retorna o nome todo em maiúsculo nomeCriptogrado <- Maiusc(nomeOriginal) escrevaL("Nome original : ", nomeOriginal) escrevaL("Nome criptografado: ", nomeCriptogrado) fimAlgoritmo Ou seja: se o enunciado fosse "leia o nome de uma pessoa e retorne o nome todo em maiúsculo", o código acima basicamente já resolveria isso. Pois existe uma função que já faz isso. Para o teu código, você precisa analisar caractere a caractere (já dando o spoiler). 87,36% de uma solução já foi dada: Basicamente pesquise sobre o comando Copia() e Compr() no Visualg. Entendendo como eles funcionam, perceberá como ele pode ser útil para uma lógica que resolva esse problema (atenda ao enunciado).

@Pedro Roth, para não passar em branco, segue algumas dicas: Passagem de parâmetros ou uso direto de variáveis globais Como as variáveis estão como globais, não precisaria passar por parâmetro. Ainda mais que não estão passando valores, pois estes são lidos dentro do procedimento. Alternativa 1: Se quer utilizar as variáveis globais, seria só remover os parâmetros mesmo: procedimento ProcM() Daí ajustar as chamadas do procedimentos. Exemplo: caso 1 ProcM() Alternativa 2: Declarar as variáveis dentro dos procedimento. Acho melhor! Dessa forma, cada procedimento terá tudo que precisa dentro dele mesmo E/OU, se precisasse de um valor externo, usaria o parâmetro (em vez de acessar variáveis globais diretamente). var opcao: inteiro resp : caractere irocedimento ProcM() var mvm, vmc, in, totM, porce, totPorce: real resp : caractere inicio Adendo 1: as variáveis internas e globais são distintas (escopos diferentes), por isso é possível utilizar "resp" tanto fora, quanto dentro. Adendo 2: detalhe é que no VisualG não dá para diferenciar. Aqui só daria para acessar a variável local. ... mas, de qualquer forma, como não devemos utilizar variáveis globais diretamente, acaba não sendo um grande problema... (e para resolver isso, seria simplesmente usar outra nomenclatura ) Exemplo de bom* uso de parâmetros procedimento Menu(var opcao:inteiro) inicio escrevaL("---------------------------------------------------------------") escrevaL(" CALCULADORA DE MILHAS ") escrevaL("---------------------------------------------------------------") escrevaL(" ") escrevaL(" O que você gostaria de calcular?") escrevaL(" [1] Pontos") escrevaL(" [2] Milhas") escrevaL(" [3] Sair") leia(opcao) escrevaL("---------------------------------------------------------------") fimProcedimento inicio repita Menu(opcao) Desta forma, está implícito que o parâmetro foi usado para que o procedimento retorne algo do escopo dele para o global. Ah! Isso é possível devido à palavra reservada var ali no parâmetro. Outra forma seria utilizando funções. funcao Menu() : inteiro var op : inteiro inicio escrevaL("---------------------------------------------------------------") escrevaL(" CALCULADORA DE MILHAS ") escrevaL("---------------------------------------------------------------") escrevaL(" ") escrevaL(" O que você gostaria de calcular?") escrevaL(" [1] Pontos") escrevaL(" [2] Milhas") escrevaL(" [3] Sair") leia(op) retorne op escrevaL("---------------------------------------------------------------") fimFuncao inicio repita opcao <- Menu() escolha (opcao) Perceba que não é obrigado usar a mesma nomenclatura de variável. Mas poderia também. Tanto faz. Simplificação do "programa principal" Basicamente poderia remover o trecho "duplicado". Só ajustar o repita com o que está fora dele. Algo como: inicio repita Menu(opcao) escolha (opcao) caso 1 ProcP() caso 2 ProcM() caso 3 escrevaL(" Encerrando... ") escrevaL("---------------------------------------------------------------") Timer 2000 Timer 0 LimpaTela() fimEscolha ate (opcao = 3) fimAlgoritmo Adendo: Na minha visão NÃO é possível utilizar o fimAlgoritmo para finalizar o programa dessa forma no VisualG. Considero com erro de sintaxe. Resumidamente: um algoritmo só deve ter um fimAlgoritmo, que basicamente é aquele associado ao inicio. Por sinal, no Pascal, o fimAlgoritmo seria equivalente ao "end."... e lá tem o os comandos exit e halt. Estes dois últimos "NÃO EXISTEM" no Visualg. E, mesmo lá no Pascal, não seria uma boa prática "forçar o encerramento" dessa forma, o mais correto seria "deixar o fluxo seguir" até que o programa chegue lá no "verdadeiro" fimAlgoritmo... que fica no fim do código, assim como sugerido mais acima. Sobre perguntar sobre novos cálculos Sugeria deixar ou dentro de cada procedimento ou dentro de cada opção. Em fim... tudo isso são "técnicas de programação". Independe da linguagem. Por sinal, o VisualG sequer é uma linguagem (é uma pseudolinguagem). O Visualg tem 2 pontos fontes para iniciantes: é em Português e tem essa "áreas de variáveis de memória" bem na cara... que ajuda muito... mas por outro lado tem muitas limitações e bugs, incluse desse de usar fimAlgoritmo onde não deve, rs. Se quiser dar continuidade por aqui não tem problema... mesmo que queira também já imergir em outra linguagem mais forte.

@EduGouveia, opa!. Vou tentar desmiuçar para tentar enriquecer o tópico. O problema geral seria esse: Mas daí ainda está com o mesmo problema que citei: Vejam: Já matando a charada: se for informado uma cadeia de caractere iniciado com algoritmo, o processamento fica errado! Já adianto também a raiz do problema: Fonte: https://www.apoioinformatica.inf.br/produtos/item/30-as-funcoes-do-visualg-versão-2-0 A própria definição da função entrega a sua (da função) limitação. Existe soluções. Exemplo: Mas como na época, deixo em aberto para quem quiser tentar. De preferência só postar a tela, não entregar o código ou o método! Adendo 1: imagino que a proposta do @EduGouveia foi justamente propor uma alternativa para o problema. Se eu tivesse dado uma solução, talvez não teríamos essa oportunidade atual. Adendo 2: ainda complementando/enriquecendo o tópico... @EduGouveia, sobre: Deveria utilizar uma disjunção, em vez de conjunção. Só inverteu :). Desse forma aí tem uma Contradição (oposto de Tautologia), pois não existe número que atenda as duas expressões ao mesmo tempo. Essa questão é bem curiosa... abaixo complemento mais sobre essa questão... Para outros visitantes: como achar a faixa de códigos que preciso, ou seja, entre 0 a 9? Exemplo: Eu "sei" que a tabela está em sequência... daí, o dígitos de 0 a 9 vão de 48 a 57. Profissionalmente seria mais sensato testar um a um ou confirmar de alguma forma. Por fim, a condição poderia ficar com algo como: se (x <= 49) OU (x >= 58) então ou de forma que acho mais elegante: se (x < 48) OU (x > 57) então Seria algo como: "se código está abaixo de 0 ou acima de 9 então". Só para exemplificar, poderia ser assim tb: se não ((x >= 48) E (x <= 57)) então Seria algo como "se o código não está acima 0 e abaixo de 9 então". Adendo 3: "Ue? E por que está funcionado com aquele código"? Duas respostas: [1] não, não tá funcionando, apenas em alguns casos o resultado da execução corresponde ao esperado (BUG!!!), como o caso de letras do alfabeto (está relacionado ao 2); (Lembrando que deve funcionar para todos os casos.) E [2], como já citado, a expressão é uma contração, ou seja, para qualquer valor de x, "a expressão necessariamente resultará em falso", ou seja, era para não funcionar sempre! Provavelmente ocorre algum erro de gerenciamento de memória do VisualG. Resumindo: era para nunca entrar no se, mas está entrando para alguns casos.

Vou criar um novo esboço me baseando pelas orientações do PDF (ATIVIDADE 5 - Instruções.pdf). Vamos lá: Observação inicial: toda e qualquer característica do programa precisa está de acordo com o requisitos do enunciado. Em outro momento podemos aprofundar sobre essa questão. Poderia já parar para inserir no teu código. Vai facilitar a implementação e organização. Vou ir demonstrando inicialmente sem o uso de funções e procedimento, daí depois também já exemplifico como é super simples readaptar. OK. Basicamente é um menu como qualquer outro... tendo lá suas especificações. Um exemplo de como eu vou modelando um esboço: programa { funcao inicio() { inteiro opcao faca { escreva("\n Digite \n 1 – Cadastrar Hospedes \n 2 – Exibir Hospedes Cadastrados\n 3 – Exibir Quartos\n 4 – Atribuir Hospede a um quarto\n 5 – Reservar Área de Lazer\n 6 – Calcular Total a Pagar\n 0 – Sair\n ") leia(opcao) escolha (opcao) { caso 1: //Cadastrar Hospedes escreva("\nOPCAO 1") pare caso 2: //Exibir Hospedes Cadastrados escreva("\nOPCAO 2") pare caso 3: //Exibir Quartos escreva("\nOPCAO 3") pare caso 4: //Atribuir Hospede a um quarto escreva("\nOPCAO 4") pare caso 5: //Reservar Área de Lazer escreva("\nOPCAO 5") pare caso 6: //Calcular Total a Pagar escreva("\nOPCAO 6") pare caso 0: //Sair escreva("\nOPCAO 0") pare } //opcao } enquanto (opcao != 0) } } Daí só ir preenchendo. Aqui o enunciado também especifica características: Cadê os vetores? OK! Tudo bem! No teu código utilizou um só... isso é bacana. O importante e meter mão e ao mesmo tempo tentar ir abstraindo formas diferentes para fazer algo parecido (que é diferente de "mesma coisa"). A medida que vai amadurecendo com os conceitos impostos pelo enunciado, vai reajustando. De boa. Continuando.. Creio que a parte inicial seria basicamente isso: Declaração das variáveis: //DADOS DOS HÓSPEDES cadeia nome = "" inteiro cpf = 0, qtdDiarias = 0 real totalDespesas = 0.0 Obs.: apenas para o cadastro não se faz necessário inicializar as variáveis, mas como de qualquer forma tem a parte da exibição, já pode declarar assim. Qualquer coisa teste removendo essas inicializações (a parte do igual e o valor) Implementação do caso 1: Oras! É apenas o que está sendo solicitado no enunciado. Não teria essa questão do cálculo do valor da hospedagem. Meu esboço ficou assim: caso 1: //Cadastrar Hospedes escreva("*** CADASTRO DE HÓSPEDE ***\n\n") escreva(" Nome : ") leia(nome) escreva(" CPF : ") leia(cpf) escreva(" Diárias: ") leia(qtdDiarias) pare No documento tem essa parte também: No caso estamos ignorando o uso de vetores e também podemos pular a parte de confirmação, que não seria importante por hora. (Nossa abstração para simplificar o problema.) Very easy: caso 2: //Exibir Hospedes Cadastrados escreva("*** DADOS DE HÓSPEDE ***\n") escreva("\n Nome : ", nome) escreva("\n CPF : ", cpf) escreva("\n Diárias: ", qtdDiarias) pare Adendo: aqui que faz-se necessário a inicialização das variáveis... caso contrário, acusa erro. (Como citato, testa aí.) Show até aqui? E aí, agora quer entrar no mundo dos vetores ou no mundo das funções e procedimentos? Tanto faz! Vamos para os procedimentos. Veja: "Cada um dos itens do menu que serão criados serão uma função ou um procedimento". (Trecho do documento.) Tenho isso: Crio um procedimento com o nome desejado: programa { inteiro opcao funcao cadastrarHospede() { } Apenas movo o que deveria está no procedimento... programa { funcao cadastrarHospede() { escreva("*** CADASTRO DE HÓSPEDE ***\n\n") escreva(" Nome : ") leia(nome) escreva(" CPF : ") leia(cpf) escreva(" Diárias: ") leia(qtdDiarias) } Simples assim... Ah! Mais as variáveis não estão funcionando. Quando você estudou procedimento e funções, deve ter tido contato com o tal termo "escopo", ou seja, o escopo desse procedimento é divergente do escopo do programa principal. Daí, ou utilizamos variáveis globais, ou passamos por parâmetro (ou alguma outra forma que não sei/não lembro). Vamos pelas globais: programa { inteiro opcao //DADOS DOS HÓSPEDES cadeia nome = "" inteiro cpf = 0, qtdDiarias = 0 real totalDespesas = 0.0 funcao cadastrarHospede() { escreva("*** CADASTRO DE HÓSPEDE ***\n\n") escreva(" Nome : ") leia(nome) escreva(" CPF : ") leia(cpf) escreva(" Diárias: ") leia(qtdDiarias) } funcao inicio() { faca { escreva("\n Digite \n 1 – Cadastrar Hospedes \n 2 – Exibir Hospedes Cadastrados\n 3 – Exibir Quartos\n 4 – Atribuir Hospede a um quarto\n 5 – Reservar Área de Lazer\n 6 – Calcular Total a Pagar\n 0 – Sair\n ") leia(opcao) É file ou não? Vamos dar uma resumida em tudo. Segue meu esboço utilizando procedimentos. programa { inteiro opcao //DADOS DOS HÓSPEDES cadeia nome = "" inteiro cpf = 0, qtdDiarias = 0 real totalDespesas = 0.0 funcao cadastrarHospede() { escreva("*** CADASTRO DE HÓSPEDE ***\n\n") escreva(" Nome : ") leia(nome) escreva(" CPF : ") leia(cpf) escreva(" Diárias: ") leia(qtdDiarias) } funcao exibirHospede() { escreva("*** DADOS DE HÓSPEDE ***\n") escreva("\n Nome : ", nome) escreva("\n CPF : ", cpf) escreva("\n Diárias: ", qtdDiarias) } funcao inicio() { faca { escreva("\n Digite \n 1 – Cadastrar Hospedes \n 2 – Exibir Hospedes Cadastrados\n 3 – Exibir Quartos\n 4 – Atribuir Hospede a um quarto\n 5 – Reservar Área de Lazer\n 6 – Calcular Total a Pagar\n 0 – Sair\n ") leia(opcao) escolha (opcao) { caso 1: cadastrarHospede() pare caso 2: //Exibir Hospedes Cadastrados exibirHospede() pare caso 3: //Exibir Quartos escreva("\nOPCAO 3") pare caso 4: //Atribuir Hospede a um quarto escreva("\nOPCAO 4") pare caso 5: //Reservar Área de Lazer escreva("\nOPCAO 5") pare caso 6: //Calcular Total a Pagar escreva("\nOPCAO 6") pare caso 0: //Sair escreva("\nOPCAO 0") pare } //opcao } enquanto (opcao != 0) } } Agora vamos ajustar para vetores. Seria algo bem padrão mesmo... o uso de vetores é generalizado. programa { inteiro opcao, i = 0 //DADOS DOS HÓSPEDES cadeia nomes[10] inteiro cpfs[10], qtdDiarias[10] real totalDespesas = 0.0 funcao cadastrarHospede() { escreva("*** CADASTRO DE HÓSPEDE ***\n\n") escreva(" Nome : ") leia(nomes[i]) escreva(" CPF : ") leia(cpfs[i]) escreva(" Diárias: ") leia(qtdDiarias[i]) } funcao exibirHospede() { escreva("*** DADOS DE HÓSPEDE ***\n") escreva("\n Nome : ", nomes[i]) escreva("\n CPF : ", cpfs[i]) escreva("\n Diárias: ", qtdDiarias[i]) } funcao inicio() Versão de implementação até aqui: programa { inteiro opcao, i = 0 //DADOS DOS HÓSPEDES cadeia nomes[10] inteiro cpfs[10], qtdDiarias[10] real totalDespesas = 0.0 funcao cadastrarHospede() { escreva("*** CADASTRO DE HÓSPEDE ***\n\n") escreva(" Nome : ") leia(nomes[i]) escreva(" CPF : ") leia(cpfs[i]) escreva(" Diárias: ") leia(qtdDiarias[i]) } funcao exibirHospede() { escreva("*** DADOS DE HÓSPEDE ***\n") escreva("\n Nome : ", nomes[i]) escreva("\n CPF : ", cpfs[i]) escreva("\n Diárias: ", qtdDiarias[i]) } funcao inicio() { faca { escreva("\n Digite \n 1 – Cadastrar Hospedes \n 2 – Exibir Hospedes Cadastrados\n 3 – Exibir Quartos\n 4 – Atribuir Hospede a um quarto\n 5 – Reservar Área de Lazer\n 6 – Calcular Total a Pagar\n 0 – Sair\n ") leia(opcao) escolha (opcao) { caso 1: //Cadastrar Hospedes cadastrarHospede() pare caso 2: //Exibir Hospedes Cadastrados exibirHospede() pare caso 3: //Exibir Quartos escreva("\nOPCAO 3") pare caso 4: //Atribuir Hospede a um quarto escreva("\nOPCAO 4") pare caso 5: //Reservar Área de Lazer escreva("\nOPCAO 5") pare caso 6: //Calcular Total a Pagar escreva("\nOPCAO 6") pare caso 0: //Sair escreva("\nOPCAO 0") pare } //opcao } enquanto (opcao != 0) } } Minhas sugestões daqui em diante - poderia se basear por esse minha implementação e reajustar o teu código. Até deixar tudo rodando lisinho até esses pontos já abordados, ou seja, NÃO copie o meu código! Refaça tudo para assimilar ponto a ponto. Tudo isso que passei acima é "universal". A ideia é passar perrengue em alguns momentos, para posteriormente já pular etapas em novos outros. Tipo: já implementaria com procedimentos e vetores. Mas é necessário passar pelas características de não usar eles antes. - após, releia parte por parte do enunciado e vá reajustando o código. Por exemplo, adicionar o controle dos vetores; adicionar os itens que faltam da PARTE 2, como "ler os dados, pedir confirmação e só depois adicionar ou não ao vetor (observe que eu li direto no vetor, mas a leitura deveria ser separada); Exibir os dados como estão na PARTE 3 etc. Só após... entra em uma nova atividade, como adicionar o item 4. (Que você já fez, mas daí reinsere a partir dos novos ajustes que fez agora.) Qualquer dúvida, comentário, sugestão, é só postar. (ignorem essa imagem acima)

@Pedro Roth, tá top! Sugeriria partir para outra plataforma... você já passou dos limites do VisualG a muito tempo... Escolha qualquer outra... Que tal criar um mobille app?. O principal você já tem que é a lógica e, principalmente, a organização.

Quais bugs?