Maligno

O operador = é utilizado para apenas para atribuir valores a variáveis. No IF você deveria ter utilizado o operador relacional == para comparar o valor. Daí o erro.

Agora que vi o resto do código. E tem erros. 1) bool reposta="YES"or"NO"; Isso nunca vai compilar mesmo. Não existe comando or em C/C++. Você deve ter confundido com outra linguagem. 2) printf "YES"; printf é uma função. E dessa forma nunca vai passar pelo compilador. 3) switch(reposta="NO"); A forma de uso do comando switch é diferente, apesar de que isso até poderia compilar, se estivesse numa forma correta. C e C++ não perdoam o menor erro de sintaxe. Pior fica se houver erro de lógica. Dependendo do que for, ele pode se tornar seu pior pesadelo. Mais cuidado.

Você usa os operadores de atribuição e relacional da mesma forma, mas em C/C++ faz toda a diferença: enquanto = atribui um valor, == faz o teste relacional. Logo, ... if (reposta == "YES") { } ...é a forma correta.

Use o par ternário de comparação ?:. Exemplo: a expressão (a<b? b: a) retornar o maior valor entre a e b. Se bem que, se retornar a, esta variável pode também ser igual a b.

Pelo que comentou o OP, as duas condições devem ser verdadeiras em cada expressão. Logo, o operador relacional utilizado é && (AND) e não || (OR).

O "L" serve apenas para informar ao compilador que o número deve ser tratado como Long.

Falta listar os erros que obteve na compilação.

Teste de mesa nada mais é que montar uma tabela simples com uma coluna para cada objeto envolvido, anotando seu estado a cada iteração. Imagine que você tem o seguinte: a=1 b=2 c=a+b No teste de mesa você terá uma coluna para cada variável. E a cada passo deve anotar o estado de cada uma: passo a b c 1 1 2 1 2 3 1 2 3 Para algoritmos muito simples não faz muito sentido. Você só percebe a utilidade do método em algoritmos mais complexos. Eu usei muito em Assembly, para monitorar o estado dos registradores. Aí faz diferença. Só não sabia que isso também se chamava "teste chines". :)

Da primeira mensagem, as palavras do OP: "porém gostaria de que na hora q executasse o programa, ele fizesse alguma pergunta, como "Salvar arquivo com qual nome?", e eu colocasse o nome que gostaria" :)

Não se culpe. Ponteiros são o carma de 99% dos programadores. É difícil de entender no começo. Mas é bom entendê-los, pois eles farão parte da sua vida até o seu último suspiro. :))) Só pra constar: memória alocada estaticamente é aquela memória dedicada à uma variável em tempo de execução: uma matriz de inteiros, por exemplo: int x[10] já aloca espaço. Ele é fixo, imutável. Morre aí. Se a alocação for dinâmica você só precisa de um ponteiro. Em tempo de execução você aloca memória para conter os seus dados. Se for necessário, essa área poderá ser expandida ou contraída, formando assim, um contâiner de dados. Exige mais código, mas oferece mais flexibilidade. Minha dica: leia bastante sobre ponteiros e faça muitos exercícios práticos utilizando-os. Mas não em programas como o seu. Me refiro àqueles programinhas bestas de exemplificação, que normalmente ninguém dá valor. Eles são focados apenas nisso. Só têm ponteiros, mas em situações das mais diversas. Fica mais fácil aprender assim. Leia esses códigos, analise-os, modifique-os e aprenda como as coisas acontecem. Com o tempo e a prática você aprenderá a conviver pacificamente com ponteiros. :)

Veja que não é o caso de renomear, pois o arquivo pode nem existir. O colega quer perguntar ao usuário qual nome usar no arquivo alvo. Daí é como eu disse: há uma série de críticas a fazer. Se for mantido o nome ou não, o arquivo pode existir. Vai sobreescrever? Se sim, a gravação pode falhar se ele já estiver aberto em modo exclusivo. Mas se o alvo ainda não existe, e se o usuário trocar o nome default, há de se analisar o nome informado em busca de caracteres proibidos. Sem falar que há também o problema do diretório destino, se foi informado, se existe ou se existe apenas parte do caminho, etc. Isso tudo parece coisa simples. Os usuários nem dão muito valor. Mas bote isso num fluxograma pra ver como a coisa pode se extender bastante. Isso que é uma tarefa pequena: salvar dados num arquivo. Mas existem coisas extremamente mais complicadas e trabalhosas. Decididamente, programação não é uma boa àrea pra ganhar dinheiro fácil. Claro que, para efeito didático, numa tarefa escolar, algumas etapas poderão ser puladas. Mas na vida real a coisa é trabalhosa mesmo. Aí o importante é se antecipar e tratar os erros que eventualmente podem aparecer. E acho que o ideal, mesmo numa tarefa escolar, é não queimar etapa alguma. É melhor ir se acostumando, pois no trabalho do dia-a-dia não se pode pular coisa alguma. Senão, a qualidade vai pro brejo.

Não. A questão do OP está bem clara. Ele quer dar ao usuário a oportunidade de salvar o arquivo com o nome que quiser. Pra isso é fácil: perguntar qual nome, já informando o nome default. Se o usuário alterar o nome ou não, é só salvar com o nome que ali estiver. Mas o OP terá de criticar esse nome de arquivo, já que há sempre a possibilidade do usuário utilizar caracteres proibidos.

Não diria que está complicado. Veja bem: trabalhar com variáveis globais em programas pequenos não acarreta tanto problema. Agora, se o programa tem algumas milhares de linhas, variável global deixa de ser interessante, até porque é memória estática. Aí entra o ponteiro. Você poderia, por exemplo, manter essa estrutura na função principal, alocar memória dinamicamente para ela e passar esse ponteiro para a função que for manipular o cadastro, fazendo deleções, inserções, carga, descarga, etc mais facilmente. Isso pode simplificar as coisas, principalmente no quesito manutenção. Numa instância superior, temos a orientação a objetos, mas isso para manipulação de dados altamente complexos, em que se tem estruturas em vários níveis de aninhamento. Mas isso é outra história. :)

Você duplicou o tópico. Já respondi no primeiro: http://scriptbrasil.com.br/forum/index.php?showtopic=156341

Nas funções que precisam manipular essas estruturas você só precisa passar o ponteiro para a estrutura que tiver de ser manipulada. Não é coisa complicada. Na chamada desta função, o argumento é o nome da estrutura. Na função chamada, o protótipo deve conter o tipo da strutura. Exemplo simples: typedef struct { char nome[10] ; int telefone ; char apelido[30]; int celular ; int ind ; } pessoa; bool procurarNome(pessoa *cadPessoa, char nome[]) { // ... // if (stricmp(cadPessoa->nome,... // return true; } int main() { pessoa cad; // aqui pessoa já é um tipo novo de dado // // preenche cad com dados quaisquer // if (procurarNome(cad,"Maria")) { // // Encontrou! // } }

Tenha em mente que senha nunca será números (int, float, etc) . Seja qual for, sempre será string, mesmo que dela façam parte apenas caracteres numéricos. Logo, é como string que deverá ser manipulada. Informação adicional (não sei porque, nunca comentam isso): senha nunca deve ser armazenada, a não ser que precise ser repassada para outro objeto (um log-in de site, servidor, etc). Fora isso, armazena-se apenas o hash (CRC32, MD5, SHA1, etc) da senha.

Simples. Para cada for coloque a inicialização da variável fora do while, o teste entre os parênteses e o incremento desta variável dentro do bloco que ele contém.

Por lista você se refere à classe StringList? Se for, terá de estudar os métodos da classe, para carga de arquivo ou inserção das strings manualmente. Dá pra fazer de várias formas. Você precisa ser mais específico. Se for no Builder, posso ajudar mais.

Ocupar memória à toa? Seria para atender uma necessidade e seria muito pouca memória, dada a função executada. Logo, não seria à toa. Não tem com o que se preocupar. Além do que, esse tipo de "truque" é muito comum. O "RunOnce" é uma chave do registro do Windows. Uma vez que lá seja declarado um programa, ao reiniciar a máquina, ele será automaticamente executado. Mas apenas uma vez. A chave será apagada pelo Windows. Veja no registro do Windows: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" A chave deve ter nome, tipo e valor, e é declarada da mesma forma que na chave "Run". Se precisar, copie o esquema de lá.

Usando a classe String (padrão de C++), apenas troque as posições das letras do texto, duas a cada vez, com a quantidade de iterações igual à metade do tamanho da string. Mais ou menos: char c; int s = text.Length(); for(int i=1; i<=s/2; i++) { c = text[i]; text[i] = text[s-i+1]; text[s-i+1] = c; } Não testei, mas é por aí. Isso se for utilizar a mesma string original. Se usar outra, auxiliar, fica mais fácil ainda. É só copiar.

Não por ele mesmo. Mas o truque é executar um programa auxiliar, muito simples, que fecha o primeiro e o abre novamente, para se auto-finalizar em seguida. Mas se precisar de boot antes disso, o método convencional é usar a chave "RunOnce" do registro do Windows.

Aliás, você fecha a alça da segunda abertura do arquivo, mas o da primeira abertura permanece aberto. Não se pode dizer que é um erro, até porque a primeira alça, não fechada, se fecha na morte do programa. Pelo que sei o SO cuida para que o fechamento seja feito. Mas realmente não é uma boa prática. Se abrir o arquivo, feche-o quando não for mais necessário.

Lei de Murphy: se facilita de um lado, pode apostar que do outro lado complica. Mas esse impasse é simples de resolver. Se a natureza dos dados é char, mantenha como char. RG, CPG, CNPJ, PIS, etc. Todos os números de documentos que contém DV podem ser convertidos para o cálculo. Mesmo assim, continuarão sendo informações de texto. Devem sempre ser mantidos como strings comuns. No cálculo devem ser convertidos para o tipo mais apropriado.

Porque você abre o mesmo arquivo duas vezes? Na primeira só faz a busca, na segunda grava. Não há porque fazer assim. Abra só uma vez. E está no manual da função fopen(): o switch "wb" (na segunda abertura) destrói o conteúdo. Por isso os dados somem. Abra o arquivo uma vez só, mas com o switch "r+b". Assim você poderá calcular o fseek() para gravar exatamente sobre o ponto da alteração. Mais: considere o uso da função fprintf(), que facilitará a gravação no arquivo.

O valor do incremento é 0x30 mesmo (48 dec). Mas o ideal mesmo é usar string, se for C++. Aliás, um cadastro desse tipo, se for o que estou pensando, em C só se for exercício/tarefa de curso. Profissionalmente nem pensar. Só C++.