Ir para conteúdo
Fórum Script Brasil

Maligno

Membros
  • Total de itens

    214
  • Registro em

  • Última visita

Posts postados por Maligno

  1. Você não disse em que ferramenta está programando. Mas não importa tanto. O fato é que é simples assim. Você instanciou a classe, criando o objeto dinamicamente. Isso não quer dizer nada. Se usa uma IDE, pode arrastar o objeto para o formulário e mantê-lo invisível até o momento em que for necessário. Se prefere criar o objeto dinamicamente, pode colocá-lo onde desejar. Não faz diferença. Acho que não entendi qual é exatamente o problema.

  2. o fim da string não é '0', é ''

    Ou pode ser simplesmente o número zero. Mas o comum é remover a comparação. Ao invés de:

    for (letra=0; string[letra] !='0'; letra=letra+1)
    usa-se apenas
    for (letra=0; string[letra]; letra++)

    já "melhorando" o incremento do iterador.

  3. O objeto do botão é uma instância da classe Button (ou seja lá o nome que tenha). Essa classe tem eventos que podem ser programados. O que você precisa fazer é apenas programar a reação ao evento "OnClick" (ou seja lá o nome que tenha) do botão.

    Eu não conheço o Visual Studio. Eu uso o C++ Builder e nele essa parte também é visual. No caso eu só precisaria clicar duas vezes no próprio botão que o código seria automaticamente incluído e mostrado no editor de código.

  4. A memória alocada e cujo endereço reside num ponteiro deve ser liberada sempre que se tornar desnecessária, manualmente ou não. Se foi utilizada a pilha, a morte do escopo do ponteiro já libera a memória alocada. Se a memória foi alocada explicitamente (new em C++ ou malloc() em C), ela deve ser liberada por delete se em C++ ou free() se em C.

    Apenas tome cuidado com o escopo do ponteiro. Se ele foi criado e teve memória alocada manualmente dentro de um bloco de código, ele deve ser liberado dentro deste mesmo bloco. Porque depois de sair do bloco o seu escopo estará perdido e a variável ponteiro não será mais conhecida. Assim, qualquer posterior referência a essa variável resultará em erro. Neste caso, claro, será impossível liberar a memória porque a variável deixou de existir. Mas se a memória foi alocada automaticamente (pilha), sair do bloco de código que a criou já fará a liberação da memória também de forma automática.

  5. Olá, Florzinha.

    Seja bem-vinda ao fórum. :)

    O problema do seu código não está na análise, mas na entrada dos dados. Sua chamada scanf("%s",&frase) faz com que a entrada de dados seja considerada apenas até que se encontre o primeiro espaço. Mesmo que você continue digitando.

    Para corrigir, basta trocar por scanf("[^\n]",&frase). Esse argumento fará com que a função considere todas as letras até o ENTER que faz a função retornar. Experimente. Deve dar certo.

  6. o que isto significa?

    Significa um erro de compilação, com certeza. É fácil de explicar. Você tem nesse caso uma matriz multidimensional sem as dimensões que o compilador precisa. Você só pode omitir a dimensão mais à esquerda. Todas as demais precisam ser informadas. Senão, como poderá o compilador endereçar os elementos?

  7. Estamos falando de C ou C++?

    Se for C++, fica muito mais fácil, embora mais trabalhoso para montar a classe. Nesse caso o cliente apenas instancia o objeto que por sua vez trata de alocar a memória. Essa função, ao finalizar ou mesmo após o objeto perder escopo dentro dela, automaticamente disparará a execução do método destrutor; local apropriado para a liberação da memória.

    Agora se for C, não haveria como. Até porque, a função teste() precisa retornar o ponteiro de lista. O cliente da função é que terá de liberar a memória manualmente. Se bem que isso é um procedimento absolutamente normal, de uso comum.

  8. Entendi, então um simples free(testeList) não libera tudo.
    Veja que, num programa rodando num sistema com muita memória, você pode até nem desalocar coisa alguma. Dificilmente você terá problema. Mas o método "canônico" é liberar tudo o que foi alocado. Quando você aloca memória, o gerenciador de memória (existe um) alocará o valor pretendido e devolverá um ponteiro. Então, mesmo que o ponteiro PTR esteja numa área de memória alocada por "lista", ao desalocar "lista", PTR continuará ocupando memória. Logo, você precisa desalocar tudo manualmente, do mesmo modo como fez para alocar. Um ponteiro não tem nada a ver com a memória apontada por outro ponteiro.

    Porque desalocar de "revestrés"? Simples: se desalocasse primeiro "lista", você teria liberado uma área que, num sistema multithread (como o Windows) poderia ser ocupada rapidamente por outro programa (ou mesmo numa thread no mesmo programa), e antes que tivesse chance de desalocar os PTR. Mais uma vez: é muito difícil isso acontecer. Mas como "shit happens", usa-se o método canônico: antes de perder o ponteiro de "lista", desaloque os PTR. Assim, inclusive, seu programa se tornará mais thread-safe.

    Deve liberar primeiro os PTR da coluna e depois o testeList? Como faz isso?

    Use a mesma malha que você fez para alocar. Navegue por cada ítem "coluna" e libere seu PTR. Ao final, libere o ponteiro que sobrou. Ou seja, "lista".

  9. Sim, pois ele terá acesso aos ponteiros. Mas uma lembrança: o cliente terá de desalocar de dentro pra fora. Ou seja, primeiros os ponteiros das colunas (PTR) e só no final o de lista.

    Uma dúvida: porque o argumento é um ponteiro de ponteiro? É uma matriz de ponteiros?

  10. No C++ Builder você precisa apenas definir duas propriedades para que a imagem fique com fundo transparente: transparent como true e o valor da cor de fundo que será transparente, na propriedade transparentColor. Normalmente se usa uma cor berrante, como rosa, por exemplo.

    Aliás, em tempo: tome o cuidado de nunca usar uma cor que faça parte da imagem. Senão, onde ela aparecer ficará transparente.

  11. erro de " invalid lvalue in assignment " e não sei o que pode ser.

    "assignment" é o mesmo que atribuição. O compilador entendeu que você quis atribuir zero à dois. Um erro comum é o programador querer comparar uma variável com uma constante; algo do tipo if(x=0). Aí o compilador (se for bom) não vai apontar erro, pois não está errado. Mas vai disparar um warning †, apontando para um "possível" erro. Para evitar isso, muitos programadores utilizam a comparação invertida: if(0 == x), pois se errarem e usarem o operador de atribuição, aí sim, dá erro e o processo pára na hora.

    Warnings desse tipo podem ser desligados (eu desligo). Se isso for feito, a compilação prossegue normalmente, mas o erro permanece. Isso pode gerar comportamentos estranhos e o erro pode ser de difícil detecção. Aí entra o "truque" de inverter os operandos da comparação. Se a distração ocorrer, o compilador soltará o mesmo erro que você viu em seu programa.

  12. Mas você é muito abusado, hein? Pede consultoria grátis no final de semana, quando o povo quer mais é descansar, se divertir, aproveitar a família, etc... E ainda tem a cara-de-pau de achar ruim porque não foi imediatamente atendido. Isso é pior que os caras-de-pau que não fazem o trabalho de faculdade e vêm aqui pedir tudo pronto e funcionando.

  13. Use a função SHGetSpecialFolderPath() da API do Windows. Mas se precisar usar em sistemas não-NT, terá de utilizar a função obsoleta SHGetFolderPath(). Para cada uma dessas funções há uma variante que utiliza uma struct. Veja o MSDN para mais detalhes.

  14. Não há problema nenhum em incluir o mesmo header em vários fontes, desde que se faça o controle pelo símbolo do header, como normalmente se faz em qualquer header:

    #ifndef READH
    #define READH
    
    
    // o conteúdo aqui...
    
    
    #endif

    Sem esse artifício, praticamento todos os header da biblioteca padrão gerariam erro por duplicidade de símbolos. Mesmo que não precise, acostume-se a fazer isso.

    PS: O símbolo pode ser um texto qualquer de sua escolha. Não precisa fazer referência ao nome do header.

  15. Apenas um comentário adicional sobre declaração de funções. Qualquer função pode estar localizada em qualquer ponto do fonte. Não há problema algum nisso. O único cuidado a tomar é que o compilador, ao "varrer" o fonte e ao encontrar uma chamada de função, já deverá ter à sua disposição (tabela interna) o protótipo desta. Logo, não adianta muito colocar main() na última posição do fonte, se uma função A, acima, chamar uma outra função B, que está abaixo. Se o compilador ainda não sabe da existência de B, é erro na certa. Por isso, pra evitar esse tipo de problema, o procedimento mais comum é destacar os protótipos de todas as funções utilizadas logo no início do fonte, com exceção de main(), claro. Isso resolve sempre. Mas em projetos pequenos. Em projetos grandes, o ideal é inserir esses protótipos num arquivo header e informar esse arquivo num #include no topo do fonte. Lembrete: um header pode ser informado em qualquer lugar do fonte, e há ocasiões em que o topo do fonte não é o ideal, principalmente quando existem comandos de um segundo header anulam comandos o primeiro. Depende da situação, claro. Isso se explica porque o header nada mais é que uma inclusão de informações. Ou seja, onde há um #include <file> o processador encara da mesmíssima forma como se você tivesse digitado todo o conteúdo do header naquele ponto. Aliás, e finalizando: a extensão .H (ou .HPP em C++), que é a mais comumente utilizada, sequer é exigida. Tanto faz. Pode-se usar até (num exemplo exagerado e não aconselhável) TXT, EXE, COM, etc. O que importa é o conteúdo.

  16. Isso não é fatorar. Isso é cálculo de fatorial. Nada a ver. Tome mais cuidado ao redigir uma pergunta. Muitas vezes a qualidade da resposta depende da qualidade da pergunta.

    Use uma malha FOR pra obter os números de X a X+n e multiplique cada um, armazenando o resultado na variável de retorno. Exemplo (não testado), onde n é o fatorial desejado:

    for(i=1,fat=1; i<=n; fat *= i++);

    Ou algo do tipo.

  17. Agora , você sabe... como eu faço para mostrar o conteúdo da memoria liberada?

    Ver o conteúdo de uma área de memória que já foi liberada é uma prática temerária. Uma vez que houve a liberação, o gerenciador de memória já pode ter utilizado o espaço para outra alocação. Logo, o ponteiro que você tinha para esse bloco, já está na condição de "selvagem". Qualquer coisa feita com ele após a liberação, e em relação aos dados anteriores, é altamente suscetível a erro. Por esse motivo, muitos programadores tornam o ponteiro NULL, após a liberação de memória.

    Se quiser ver o conteúdo da memória, faça isso antes da liberação, uma vez que este ponteiro ainda será seu.

×
×
  • Criar Novo...