Maligno

Quem disse que o caractere ASCII não é o número normal do teclado? É sim. Note: nem tudo é o que aparenta ser em computação. A linguagem não vai fazer tudo pra você. É você quem deve converter os valores. Mas é coisa simples. Se observar na tabela ASCII, o "zero" é representado pelo valor 48. Logo, você só precisa subtrair os seus resultados por 48 para ter os números "humanos". :)

#include <stdio.h> int main() { char Frase[] = "Estude mais!"; char Letra = 'E'; if (Letra == Frase[0]) printf("Sim, preciso estudar mais.\n"); else printf("Que nada! já to craque! :)\n"); return 0; }

Talvez o Schildt não comente no livro, mas há alguns outros aspectos importantes a considerar. C++, como OOP, possui um recurso chamado de overloading; sobrecarga de funções, onde uma mesma função pode aceitar argumentos diferentes e manter o mesmo nome. Mas se duas funções compartilham do mesmo nome, como o compilador sabe qual função usar? A própria parametrização é um recurso que o compilador usa. Mas não é só isso. Há também o que se chama de name mangling, que é uma técnica que cria para a função um nome diferente do "real", o que constitui uma "assinatura" para cada função. C não tem isso, até porque nem precisa. Mas quando você faz uso de uma função C (uma LIB especial, por exemplo) em código C++, você precisa avisar o compilador que para aquela função C não deverá ser utilizado name mangling. Daí a necessidade do "extern "C" .... Sem isso o compilador vai mandar o linker procurar por um nome de símbolo que não existe. É erro na certa. Note também que uma função C, nessas condições, não pode ser sobrecarregada, já que para este recurso o uso do name mangling é mandatório. Aliás, repare que devido ao fato do name mangling produzir um objeto com nome de símbolo bem diferente do nome "real" da função, fica torna impossível um código C usar código C++ de uma biblioteca de funções. A não ser, claro, que algum compilador tenha algum switch especial que permita ao programador desligar o name mangling ao criar uma biblioteca para uso externo. Não conheço nenhum que tenha, e duvido que exista. Estou só "aventando" uma possibilidade. :) PS: Mais detalhes sobre name mangling podem ser obtidas pelo Google. Mas é coisa simples e fácil de entender.

Explicitamente você não precisa (nem pode) executar o destrutor da classe. Ele será chamado automaticamente pelo compilador em duas situações distintas: se para o objeto foi alocada memória pelo comando new, você deve liberar a memória depois do uso, pela execução do comando delete. Isso chamará o destrutor. A segunda situação é quando o objeto é uma variável local. Aí é mais fácil ainda: o destrutor será chamado automaticamente quando o escopo do objeto morrer, esteja ele dentro do bloco da função ou dentro de um bloco mais interno ao bloco principal.

Atenha-se sempre às normas da linguagem. A norma de C diz que você pode ter break no seu default. Isso é regra e ponto final. Agora, se no final der pau nisso, é bug do compilador. Você até pode mudar o código para sanar o problema, mas não se esqueça de algo MUITO importante: quem está contrariando a regra é o compilador e não você. Mas isso é fichinha. Você não tem idéia dos bugs esquisitos que já peguei no GCC. Aliás, o GCC eu nunca uso pra produção. Apenas pra teste. E olha lá. Sempre de olhos bem abertos. Vou contar um caso escabroso. Resumidamente: eu tinha a função A() que chamaba B(). Em A() havia uma malha com um iterador i. O escopo dessa variável, claro, era local à A(). Na função B(), nada demais. Era código comum. Mas, por alguma estranha razão, ela ferrava com aquela variável iteradora i de A(); completamente fora do escopo de B(). Após o retorno de B() a função A() dava pau porque i passava a ter um valor absurdo. Solução: modifiquei o código de B(), fazendo um monte de lingüiça de rosca, só pra mudar a forma do código. Operacionalmente ficou a mesma coisa. E parou de dar o erro. Passados alguns meses, com o programa já modificado várias vezes (ele mudou de forma, digamos assim), voltei a função B() ao que era quando dava esse erro. Sem mudar a versão do GCC, recompilei e parou de dar erro. Tudo funciona até hoje. Moral da história: não dá pra confiar muito em alguns compiladores. É bom ficar de olhos bem abertos, até porque o pior erro é aquele que você não vê. Por isso a etapa de testes é muito importante. Tem de ser a mais abrangente possível.

Explique para o seu professor (ele não deve saber) que o comando de quebra break após um default só faz sentido quando após esse default existir algum outro case. Uma situação dessas parece esquisita. E é mesmo, além de ser uma grosseria. Ninguém em sã consciência faz isso. Mas mesmo sendo esquisita, é um arranjo perfeitamente válido, que não dá erro. Mas só nessa situação um break faria sentido. Veja um exemplo simples: char vlr = 1; switch(vlr) { case 0 : vlr = 10; break; default : vlr = 12; break; case 2 : vlr = 11; break; } No final vlr conterá 12. Mas aí o último case não será considerado? Será sim. O compilador sabe que há mais um teste a ser feito após o default. Se você trocar o último teste para case 1, no final vlr conterá 11. E o default não será utilizado. Não se preocupe. O compilador não vai se perder. Finalizando: default, observando-se as regras da boa programação, deve ser sempre o último comando no switch, até por uma questão de legibilidade. Portanto, um break seguinte ao default, nessas condições, não interrompe piçiroca nenhuma. É peso morto. :)

Neste caso basta copiar a cópia modificada para o original. Dá no mesmo. Perceba que um objeto nada mais é que um aglomerado de dados. Nada mais que isso.

Você pode querer alterar o objeto de forma temporária. O melhor então é criar uma cópia e alterá-lo, preservando o original.

Mais fácil que tirar doce de criança. Tenho certeza que se você se dedicar vai conseguir sozinho. Poste apenas suas dúvidas, conforme o programa for progredindo.

Infelizmente eu não posso dizer muito mais sem conhecer o manual. E nem tenho tempo pra isso. De qualquer forma, tente conhecer melhor as classes da biblioteca. Certamente há métodos que vão resolver seu problema.

O Visual Studio eu nunca utilizei, a não ser um VS mais antigo não-RAD. Já ouvi dizer que a versão mais nova é, digamos, meio RAD. Não posso afirmar com certeza. RAD de verdade e fácil de usar, e que eu uso, é o C++ Builder. Mas se o ML é para o VS, então você tem que usar o VS mesmo. Não tem jeito. Mas certamente ele deve ter algum recurso de configuração de propriedades e eventos. Isso é bem básico numa IDE. O VS deve ter também. Em tempo: o pessoal do suporte da ML não poderia te ajudar?

Pelo que entendi sua mensagem, você precisa configuar o evento do clique do botão. Não conheço essa biblioteca, mas certamente deve ter alguma coisa no Google. Tente encontrar exemplos de uso.

Modificar a organização interna da estrutura não vai adiantar nada, se é o que você fez. O que vai mudar alguma coisa é a forma de declarar e inicializar as estruturas.

Então vá tentando algumas alterações. Tente, por exemplo, colocar os typedef junto às estruturas.

Não vejo nada de errado nesse código. Deveria compilar normalmente. Tente trocar a inclusão do cabeçalho para #include "Estruturas.h" (com aspas).

Melhor seria se você tivesse postado o código ao invés dessa imagem, que não ajuda nada. Aliás, nem precisava se dar ao trabalho de recortar sua tela. Era só ter dito que a mensagem é "redefinition of struct". Mas, de qualquer forma, sem o fonte,...

Qual é exatamente a sua dificuldade?

Veja o help da função padrão sqrt(<n>). O valor n precisa ser um valor em ponto flutuante não-negativo. O retorno é um double e o header é "math.h".

Nunca precisei de algo parecido, mas há duas formas de mudar a cor: 1) instalando o terminal gráfico do console ANSI.SYS (instalado pelo CONFIG.SYS) para utilizar comandos ESCAPE (veja na net - tem bastante coisa a respeito). 2) acessando o buffer de vídeo diretamente para alterar o atritubo de cor de cada caractere impresso. Neste último caso, a biblioteca padrão da linguagem não tem função própria pra isso. Mas talvez você possa encontrar algo pronto.

A função system() permite executar qualquer comando de linha.

Experimente trocar o segundo getchar() por getch(). Aliás, aproveita e apague o break seguinte ao default, pois ele é totalmente inócuo.

Variáveis não é bem o termo correto. Tipo nativo de dado booleano, como há em outras linguagens, a linguagem C realmente não tem. Mas ela tem algo bem melhor, que é forma de avaliar os valores numéricos, conforme comentei acima. Assim é muito mais prático e flexível. Agora, com ou sem um tipo booleano nativo, toda e qualquer linguagem SEMPRE terá que contar com algum meio de teste booleano, evidentemente. Logo, isso é apenas um mero detalhe. :)

Mas é claro que existem. O zero é sempre falso e qualquer valor diferente disso é verdadeiro.

Note que antes você utilizava a MessageBox() função de biblioteca, mas depois passou a usar a MessageBox() método da classe TApplication. As duas têm protótipos diferentes. Leia o help de ambas com atenção e você vai perceber. Usando o método de TApplication, as strings são do tipo const char. Então você não pode pura e simplesmente somar as strings como fez. Uma solução simples é somar tudo como AnsiString e no final incluir o método c_str(), obtendo o char. Exemplo: AnsiString("ERRO AO ABRIR: "+ ExtractFilePath(Application->ExeName) + "Configurações\\inf_Funcionario.txt.").c_str()

O diretório do projeto está (ou deveria estar) na busca default do compilador. Ele é esperto o suficiente pra saber isso. Realmente. Em linha de comando garanto que não dá esse problema. Talvez a IDE (que não uso muito) pode não ter essa "esperteza" toda e, como o compilador é invocado indiretamente, ela pode não estar passando pra ele o diretório do fonte para uma busca pelo header do projeto. Se ela fizer isso, vai usar o switch que indiquei na minha mensagem anterior. Alguns headers já são incluídos por outros headers e por isso não precisam ser explicitamente incluídos no seu fonte. Taí o "mistério". :) Não que seja comum a todo compilador, mas todo compilador vai aceitar. O ideal é não informar path de header no seu fonte. Se os arquivos mudarem de lugar e você tiver dezenas de fontes, já viu o trabalho que vai dar pra atualizar tudo. Se puder, apenas informe o compilador qual diretório ele deve procurar.