Saber programar. A questão é que se começares em baixo nível (C), ou tens alguém que sabe e te ensina, ou vais acabar por aprender a programar MAL. Vais aprender a fazer "atrocidades" com apontadores. É difícil (e chato!) programar correctamente com apontadores (coisas relativamente grandes, pelo menos). Sem um método rigoroso, acaba por cair-se em vários pitfalls da linguagem. Um autodidacta raramente segue um método rigoroso.
Então está explicado porque é que eu não consigo avançar sozinho
Memory leaks acontecem quando se deixa memória alocada sem referência. A maneira mais simples provocar uma é com malloc() sem atribuir o valor de retorno a nenhuma variável. Mas geralmente é algo tão inocente como
Onde p é um apontador que apontava para memória alocada dinamicamente (com malloc, por exemplo). Assim essa memória não foi libertada, e agora está completamente inacessível. Não basta certificar que existe um free para cada *alloc. No exemplo anterior, mesmo que tivessemos um free(p) mais à frente, continuavamos com o mesmo problema. Debugar cenas destas pode ser um pesadelo.
O Firefox tem. E montes e montes de software (mesmo comercial). São uma praga. Tudo porquê? C.
Hmm ... percebi. Era o que eu tinha deduzido, com algumas diferenças.
Aí acho que entrava alguma metodologia na forma de mexer nessas variáveis. Penso que qualquer grande projecto tenha de ter preparadas de antemão algumas formas de manipular essas variáveis. Com um bom plano por trás, acho que esses problemas seriam mais difíceis de acontecer; mas isso também sou eu, que só consigo idealizar a situação.
A minha forma de programar envolve criar funções (
Subs e
Functions) para quase tudo, e ir usando-as à medida que são necessárias. Se um espaço é alocado na memória, tem de ter algum objectivo, e para eu alterar o apontador para ele, então ele deve ter deixado de ser necessário. Logo, porque é que não se faz logo o free? E para que é que quererei alterar o apontador, para ele apontar para outra localização?
Não podes culpabilizar uma linguagem por isso. Se existem erros desses, de certeza que é por falhas dos programadores. Para programas complexos, o ideal é terem um plano à altura.
Segmentation faults é exactamente o que referiste. Aceder a memória que não foi alocada ou já foi libertada. Por exemplo:
Código:
p1 = p2;
free(p2);
p1 -> campo
p1 e p2 são apontadores. Este exemplo é bastante simples, mas serve bem para exemplificar.
Aqui era mesmo exactamente o que tinha deduzido
As segmentation faults que vi costumam usar o scanf, precisamente como descreveste mais abaixo no teu post.
Tocaste na ferida. Boas práticas na programação em C. C não foi desenhado com esse objectivo. Já C++... Para lá caminha. Linguagens como Java (há quem diga, eu não) e .NET (C#, VB), sim. Alguém que comece em C, muito dificilmente vai adquirir boas práticas.
É preciso uma linguagem estar desenhada para ter boas práticas para elas existirem? O que eu quis dizer com "boas práticas" é "não reinventar a roda" e saber ter o código bem planeado; não ter código repetido (a menos que seja estritamente necessário)... explicar é difícil, mas no fundo, é um pouco tentar arranjar um ponto em que não escrevemos código confuso, e em que conseguimos fazer código optimizado. Acho que isso é possível fazer em
qualquer linguagem - basta conhecê-la.
scanf e printf. De certeza que já usaste. Mas usas os valores de retorno dessas funções? Ninguém usa (nem eu!). A scanf em particular, é uma das piores. Muitas vezes vêem-se statements como: scanf("%s", x); Problema -> o utilizador pode escrever o que quiser. Com o tamanho que quiser. Se o array x só tem espaço para 10 elementos, a scanf não vai verificar isso. Se o utilizador escrever vinte caracteres, a scanf vai escrever 10 em x (sem \0 a terminar...) e o resto no que quer que esteja para lá de x na memória. Se não "existir" nada, segmentation fault. Se existir... pior ainda. O utilizador acabou de alterar outras variáveis do teu programa.
Buffer overflows. Quando tentei aprendê-los, era o
scanf que se utilizava. Até aqui eu percebi tudo, mas para conseguir saber compreender o resto (
o que é que faz aquele exploit?), tenho de aprender ASM.
VB6 não é nada bom para aprender qualquer coisa. VB6 é bom para quem quer fazer "umas coisas" sem perder muito tempo nem ter de aprender coisas chatas.
E VB6 não é OO! VB6 é, no máximo, orientado a eventos. Em VB6 não existem conceitos fundamentais em OO como inheritance e cenas do género.
Eu comecei a mexer no QBasic aos 7 anos. Nessa altura, tudo o que sabia era-me mostrado pelo poderosíssimo F1 (e alguns conhecimentos de Inglês), e não fazia a menor ideia que havia muito mais para além do BASIC. Bem vistas as coisas, ninguém esperava que eu um dia quisesse fazer daquilo o meu futuro.
Se soubesse mais cedo, também não tinha forma de começar com o C, dada a complexidade da linguagem (e o facto de não ter internet e por ser em MS-DOS), mas com um bom manual, tudo é possível (foi com Bible's que aprendi a programar PHP e Perl)
Depois de conhecer a sintaxe do C, sinceramente, deixei de gostar da sintaxe do VB. É falar muito para fazer o mesmo.
Código:
Dim i as Integer
For i = 1 To 10
print i
Next i
vs
Código:
int i;
for(i=1;i<=10;i++) {
printf("%d\n",i);
}
(acho que é assim que se faz em C)
Acho a segunda sintaxe bem melhor.
Isto resume-se ao mesmo - se quiser fazer um futuro em programação, então saber C é um
must.
Se quiser programar para fazer alguma coisa bonita, então qualquer linguagem de alto nível chega, como o VB.
Programar para a WEB? Eu ia para o PHP, mas dizem que ASP tem mais saída no mercado de trabalho.
Tudo depende daquilo que uma pessoa quer, e não se deve apontar exclusivamente para uma linguagem.
Para o davidoff, que queria programar para a web, com bases de dados e afins, eu apontava mais para PHP ou ASP, mas é precisamente porque ele prefere programar para a web do que executáveis. E nesse aspecto, é bem melhor ele preocupar-se em estudar bem a linguagem que utilizar para evitar possíveis falhas de segurança no planeamento (já vi com cada login em PHP...) como a nível de bases de dados (o belo do SQL Injection). Para ele sim, acho inútil aprender C.
Mas quando me dizem que "querem programar" (para o futuro), invariavelmente respondo C ou Perl (porque gostei da linguagem).
edit -
E quanto a fazer cenas de jeito... Não sei o que queres dizer com isso, mas hoje em dia só aplicações muito específicas é que requerem o uso de linguagens de baixo nível, como drivers ou outras coisas relacionadas com hardware ou SOs. Aplicações com necessidade CRÍTICA de velocidade... C++ consegue igualar C na boa. E é OO.
É óbvio que as linguagens que são compiladas para linguagens intermédias para posterior interpretação (Java, Python) são lentas. A plataforma .NET é ligeiramente diferente: as linguagens de alto nível (C#, VB) são compiladas para MSIL (Microsoft Intermediate Language). Quando o programa corre, cada função (o termo correcto é método) chamada é compilada para linguagem-máquina e é então executada. A primeira chamada a uma função é sempre um pouco mais lenta, mas posteriormente, é muito mais rápida, já que a compilação Just-In-Time (é assim chamada) oferece possibilidades de optimização que não estariam disponíveis em tempo de compilação. E ao contrário de Java, após o pequeno atraso no início, está a correr código nativo e não a ser interpretada outra linguagem.
Para fazer uma distro de Linux não precisas de escrever grande código. Só se quiseres reescrever o kernel ou assim. A maior parte das distros que existem por aí são apenas colecções de pacotes.
Por vezes sigo-me pelo que o meu pai me diz. Na empresa onde ele trabalhava, usavam maioritariamente C++ e Delphi para as aplicações, com o auxílio de VBScript; ASP e MSSQL Server para o lado web. Ele também me contou os problemas que tiveram com o SQL Server da Microsoft, mas aí eu já estaria a fugir ao tópico.
Pelo que eu vi, a necessidade de velocidade e capacidade de resposta é constante em ambientes de produção (isto, lado web).
Quanto ao Linux, o que me referia era: se eu quisesse reinventar o linux (
), teria de saber C e ASM.
