C++ O que são essas coisas estranhas no C++? Discussão semântica

sandrofabres · 1 de setembro de 2019

Bom gente, sou uma pessoa burra mas sempre procuro estudar c e c++ , acontece que eu vou lá, estudo e de repente, quando eu quero fazer um programa interessante e pesquiso por aí sempre surgem códigos estranhos que estupram o meu mental, tenho a impressão dos gringos que estudam a nossa língua e de repente se deparam com gírias.

por exemplo

1) Uma vez eu tava olhando um código e me deparei com essa coisa *****:

[STATHread]
void Main()

{
   /* bla bla bla*/
   return 1;

}

Afinal de contas, a minha vida toda eu aprendi que coisas entre coxetes eram vetores/arrays de repente me surge esse [STATHRead] sem nem menos ter uma váriável
antes e um valor depois, se fosse pelo menos meuVetor[STATHRead]=0; eu poderia até entender, mas não, aqui está lá solto, qual afinal o nome daquilo e o que ele faz?

2) Pra aparecem variáveis com expoentes como parâmetros de funções que deixam o código parecido código binário solto na tela, tipo:
Banana( projec^) ou Laranja(array<String^>^ urg) , que raios é isso? Eu aprendi que esses acentos eram pra dizer que quando você por exemplo queria fazer x ao quadrado você fazia assim no excel x^2 e pronto. Agora aparece <String^>^ , mas o que que é issoooooooo? Um emoji ? Qual o nome disso e pra que serve? Quem costuma ter esses montes de
sinais escrotinhos zoando toda sintaxe tradicional é o Objective C da Apple que parece hieroglifos , urg! Eu não estou estudando objetive C mas sim C++ e C!

3) depois me surge um tal Cebolinha(%form) , eu a vida inteira aprendi que porcentagem era sinal para mostrar para à função printf o tipo que ela iria imprimir em uma posição dentro de uma string, tipo printf("O nome dos alienígenas é %s ", et); aí me surge esse %form sozinho, por acaso %form representa um tipo como %i, %s, %d , mesmo se presentar, por que ele está lá sozinho?

4) Outra coisa que eu acho estranho nos códigos por aí: usar uma função com sendo precedida por duas palavras ou mais, isso pra mim é coisa de java, em java quando se cria um método geralmente vem 300 coisas antes do nome da função public static String protect bla bla NomeDoMetodo() { ... , em C e C++ pra mim, antes do nome da função vinha apenas o tipo que ela era, mas aí me aparece um diacho disso: int WINAPI WinMain(){ ... } , afinal, que desgrama é esse WINAPI é um tipo do tipo? Essa misera retorna dois tipos por acaso pra ser precedida por duas coisas? Como? Qual o nome disso? Vejam essa outra pérola: LRESULT CALLBACK Repetiliana(HWND, UINT, CHROMA, ENERGY);
A função reptiliana por acaso tem dois tipos? ela retorna LRESULT E CALLBACK , tipo return(lresult, callback); por acaso? ESTOU FICANDO LOUCOOOOOOOOO!

5) Outra coisa, por que os inventores de C++ e C têm verdadeiro fetiche para usar ponteiros mesmo quando não se precisa usá-los? É por causa de limitações de hardware antigo?
Tipo, pra você mexer num arquivo você começa assim:
FILE *arquivo;
arquivo = fopen("pagefile.sys","r");

Por acaso é necessário o programador saber a posição do arquivo nas trilhas e setores do HD ou na RAM pra poder mexer nele? por que não inventam uma palavra de instrução tipo frommemof(var) e putinmemory(var) para acabar com essa palhaçada de endereço de memória, o programador nem precisa cuidar desses detalhes na maioria dos casos, as outras linguagens não usam isso e ninguém morreu por conta disso, eu heim. Qual a vantagem de usar ponteiros por exemplo pra fazer x = (b+c); ? eu heim!

KXSY · 1 de setembro de 2019

59 minutos atrás, Ric R disse:

Bom gente, sou uma pessoa burra mas sempre procuro estudar c e c++

O seu erro foi começar a estudar C e C++, C não e C++ e o mesmo vale para o contrario.

C++ usa o subconjunto de palavras reservadas do C para trabalhar com objetos, hoje em dia e tido como certeza que um programa em C não e mais compatível com o C++, porque as duas linguagens tomaram rumos diferentes.

1 hora atrás, Ric R disse:

Afinal de contas, a minha vida toda eu aprendi que coisas entre coxetes eram vetores/arrays de repente me surge esse [STATHRead] sem nem menos ter uma váriável
antes e um valor depois, se fosse pelo menos meuVetor[STATHRead]=0; eu poderia até entender, mas não, aqui está lá solto, qual afinal o nome daquilo e o que ele faz?

Isso e coisa velha lá de meados de 1993 do compilador microsoft visual C++ que tornava possível acessar objetos activeX (coisa que ninguém mais usa (a não ser que você queira fazer malwares ;) ))

1 hora atrás, Ric R disse:

2) Pra aparecem variáveis com expoentes como parâmetros de funções que deixam o código parecido código binário solto na tela, tipo:
Banana( projec^) ou Laranja(array<String^>^ urg) , que raios é isso?

O nome disso e Xor (ou exclusivo) e um operador bit a bit ( lembra de proposição na matemática e basicamente isso).

1 hora atrás, Ric R disse:

Banana( projec^)

Isso eu não sei o que faz.

1 hora atrás, Ric R disse:

3) depois me surge um tal Cebolinha(%form) , eu a vida inteira aprendi que porcentagem era sinal para mostrar para à função printf o tipo que ela iria imprimir em uma posição dentro de uma string, tipo printf("O nome dos alienígenas é %s ", et); aí me surge esse %form sozinho, por acaso %form representa um tipo como %i, %s, %d , mesmo se presentar, por que ele está lá sozinho?

Depois dessa, Eu digo poste o código inteiro.

por que o % também e usado para pegar o resto da divisão.

1 hora atrás, Ric R disse:

4) Outra coisa que eu acho estranho nos códigos por aí: usar uma função com sendo precedida por duas palavras ou mais, isso pra mim é coisa de java, em java quando se cria um método geralmente vem 300 coisas antes do nome da função public static String protect bla bla NomeDoMetodo() { ... , em C e C++ pra mim, antes do nome da função vinha apenas o tipo que ela era, mas aí me aparece um diacho disso: int WINAPI WinMain(){ ... } , afinal, que desgrama é esse WINAPI é um tipo do tipo? Essa misera retorna dois tipos por acaso pra ser precedida por duas coisas? Como? Qual o nome disso? Vejam essa outra pérola: LRESULT CALLBACK Repetiliana(HWND, UINT, CHROMA, ENERGY);
A função reptiliana por acaso tem dois tipos? ela retorna LRESULT E CALLBACK , tipo return(lresult, callback); por acaso? ESTOU FICANDO LOUCOOOOOOOOO!

São mais coisas do windows esqueça isso!

1 hora atrás, Ric R disse:

5) Outra coisa, por que os inventores de C++ e C têm verdadeiro fetiche para usar ponteiros mesmo quando não se precisa usá-los? É por causa de limitações de hardware antigo?
Tipo, pra você mexer num arquivo você começa assim:
FILE *arquivo;
arquivo = fopen("pagefile.sys","r");

Por acaso é necessário o programador saber a posição do arquivo nas trilhas e setores do HD ou na RAM pra poder mexer nele? por que não inventam uma palavra de instrução tipo frommemof(var) e putinmemory(var) para acabar com essa palhaçada de endereço de memória, o programador nem precisa cuidar desses detalhes na maioria dos casos, as outras linguagens não usam isso e ninguém morreu por conta disso, eu heim. Qual a vantagem de usar ponteiros por exemplo pra fazer x = (b+c); ? eu heim!

A linguagem foi criada em 1972 e naquela época só havia duas maneiras de programar um computador que era assembly ou hexadecimal então ponteiros não eram uma má ideia naquela época, fora que quando você está em uma maquina com 16 kilobytes rodando a 3.5 Mhz economizar um byte já faz diferença muita diferença.

E todas as linguagens de programação tratam arquivos como ponteiro, mesmo se você não consegue ver ainda sim são ponteiros (exemplo disso e java que esconde tudo do programador (android pagou caro essa brincadeira ai)).

vangodp · 1 de setembro de 2019

vou responder a ultima... as outras deixo pros expert hehe

FILE é algo como isso aqui:

#ifndef _FILE_DEFINED
struct _iobuf {
        char *_ptr;
        int   _cnt;
        char *_base;
        int   _flag;
        int   _file;
        int   _charbuf;
        int   _bufsiz;
        char *_tmpfname;
        };
typedef struct _iobuf FILE;
#define _FILE_DEFINED
#endif

e ta no arquivo wchar.h

A função fopen realiza certas operações e preenche uma variável file INTERNA com certas informações, posição do inicio do arquivo entre outras coisas menos relevantes e retorna ela pro main. Qual o problema? você ja tentou retornar uma variável criada em outra função pro main? Certamente sim não é? A resposta é N$AO!!! quando você fizer algo tipo
int foo(){int a; return a;}
e no main fizer algo como
int main(){
int var = foo();
}

var vai receber uma copia... e justo depois a variável "a" dentro de foo vai ser destruída!!! Tá mas qual o problema, eu tenho ela no main? Sim...!!!! mas se tiver que passar var para outra função desde main vai ter que criar um ponteiro certo? porque se passar por cópia vai ter vários clones de var e vai ser um problema alterar 1 só delas, se fosse um ponteiro isso tudo se simplificaria.

Resumindo... Desde quando fopen for chamada, e conseguir abrir com êxito o tal arquivo, será criado uma variável dinamicamente do tipo FILE, na qual pode ser manipulada desde qualquer lugar no seu programa(qualquer outra função), porque é um ponteiro. TENDEU? então.....

1 hora atrás, Ric R disse:

Por acaso é necessário o programador saber a posição do arquivo nas trilhas e setores do HD ou na RAM pra poder mexer nele?

SIM!!!! É necessário porque você ta mexendo com um ponteiro que indica em que posição do arquivo você está.

Não sei se deu para entender... mas faça a prova no seu pc. Passe variáveis desde uma função a outra e tente manipular uma só instância delas, ou seja, quando tiver uma struct, que somente uma delas esteja manipulada.

arfneto · 2 de setembro de 2019

Olá!

Não entendi bem a razão de sua revolta, mas talvez posa encontrar uma linguagem que se adapte mais ao seu estilo e esquecer C, C++ ou Java.

Qualificadores estão presentes em C desde sempre, coisas como unsigned, int, const e static. Em C++ tem mais uma leva deles. E fazem sentido, afinal são isso: qualificadores. Como faria sem diferenciar um int de um static int numa função? Pode viver sem isso? Claro. Mas em certas situações faz falta.

Em relação aos ponteiros, C e C++ você pode considerar que os programas em geral acabam usando funções do sistema operacional e áreas de memória, que é oferecida em ... páginas. E essas tem endereços. Serviços do sistema em geral funcionam assim, associados a uma área de memória ou a uma função...

Veja o que são callbacks em java: a mesma coisa que em C. Você passa o endereço de uma função que o sistema chama quando por exemplo uma mensagem chegar.

15 horas atrás, KXSY disse:

A linguagem foi criada em 1972 e naquela época só havia duas maneiras de programar um computador que era assembly ou hexadecimal então ponteiros não eram uma má ideia naquela época

Em 1972 havia muitas maneiras de se programar um computador. Note que hexadecimal é só uma base de numeração e não programa nada. Talvez se refiram à possibilidade de digitar códigos direto no painel de controle dos computadores, quando em muitos casos era preciso digitar o código de boot inicial a partir do painel de controle, em hexadecimal ou octal --- comum no caso das máquinas da Digital. Mas isso era só para o boot loader. Os mainframes IBM também tinham algo assim, como os /360.

Em 1972 o mais comum era usar COBOL e FORTRAN para programar computadores. Mas havia Algol e Pascal e PL/I e muitas outras linguagens... Lembro que FORTRAN vem desde '58 e COBOL pouco depois.

E sim, se usava assembler como se usa hoje em dia, com objetivos bem específicos para otimizar trechos de programa.

arfneto · 2 de setembro de 2019

18 horas atrás, Ric R disse:

quando eu quero fazer um programa interessante

Em geral são os programas "interessantes" que precisam dessas coisas estranhas...

Veja a declaração de signal() por exemplo

void (*signal(int sig, void (*func)(int)))(int)

Esse tipo de uso é muito comum em C e é como um callback em javascript: você passa o endereço de uma função que retorna um int e trata... um sinal, nesse caso, como o control-c...

sandrofabres · 3 de setembro de 2019

Em 01/09/2019 às 20:49, vangodp disse:

vou responder a ultima... as outras deixo pros expert hehe

FILE é algo como isso aqui:


#ifndef _FILE_DEFINED
struct _iobuf {
        char *_ptr;
        int   _cnt;
        char *_base;
        int   _flag;
        int   _file;
        int   _charbuf;
        int   _bufsiz;
        char *_tmpfname;
        };
typedef struct _iobuf FILE;
#define _FILE_DEFINED
#endif

e ta no arquivo wchar.h

Olá Vangodb !
A minha dúvida não é sobre como abrir o arquivo, falei do fopen apenas para exemplificar.

Em 01/09/2019 às 20:49, vangodp disse:

Qual o problema? você ja tentou retornar uma variável criada em outra função pro main?

Sim, eu uso uma variável de escopo global ou eu faço uma função retornar para a outra, até hoje eu não morri por isso.

rs.

Em 01/09/2019 às 20:49, vangodp disse:

Em 01/09/2019 às 19:07, Ric R disse:

Por acaso é necessário o programador saber a posição do arquivo nas trilhas e setores do HD ou na RAM pra poder mexer nele?

SIM!!!! É necessário porque você ta mexendo com um ponteiro que indica em que posição do arquivo você está.

Ah, pára! Sem ser programação de baixo nível eu nunca vi alguém, mesmo experiente em C/C++ precisar saber trilha, setor, cabeça do HD e inodes para para escrever num arquivo XML simples usando fopen e cia. Ter a possibilidade de ter essas informações é bom, mas obrigar a pessoa mexer com isso pra escrever "oieee" num .txt é crueldade.

até echo > "oieee">file.txt faz isso.

sandrofabres · 3 de setembro de 2019

Em 01/09/2019 às 20:43, KXSY disse:

O nome disso e Xor (ou exclusivo) e um operador bit a bit ( lembra de proposição na matemática e basicamente isso).

Nossa! É mesmo, tinha me esquecido, mas no caso de Laranja(array<String^>^ urg) alem de deixar o código feio, eu não sei o que ele faz. Obrigado pelas outras respostas.

adicionado 51 minutos depois

12 horas atrás, arfneto disse:

Em relação aos ponteiros, C e C++ você pode considerar que os programas em geral acabam usando funções do sistema operacional e áreas de memória, que é oferecida em ... páginas. E essas tem endereços. Serviços do sistema em geral funcionam assim, associados a uma área de memória ou a uma função...

Olha Arfneto, não só paginas (npv) , como segmentos e tudo mais num sistema operacional usa endereços, mudança de contexto e mudança de registradores porém isso não é argumento para se justificar o uso de ponteiros como C/C++ usa, afinal isso tudo costuma ser transparente ao usuário e se a pessoa não está programando em baixo nível, o compilador e o sistema operacional deveriam tratar dessas questões deixando o programador livre desenvolver o que realmente interessa.

Agora se o programador quisesse mexer com endereçamento, anel de proteção do modo protegido, escalonadores, algorítimos de gerecimento de memória best-fit, variáveis mutex e semáforos, aí sim, deveria ter métodos prontos em bibliotecas que desse esse poder a ele. Sabe, na maioria do tempo eu não preciso saber o endereço no bus da minha placa de vídeo e nem qual a interrupção que ela usa em meu processador pra fazer um printf("oi");
Veja no caso do Java, eu posso mexer no gerenciamento de memória dele para limpá-la, porém isso é pouco eficiente e o Java Garbage Collection dá conta do recado.

Eu mesmo, adoro ficar vendo por curiosidade o endereço das variáveis usando &var e depois mudar o conteúdo delas
com um ponteiro, confesso, é engraçadinho mas sei lá, não perderia meu tempo em usar isso se tivesse a oportunidade de usar variáveis globais e retornos de função em um projeto sério. Alias, um ponteiro tem potencial para fazer um estrago imenso que uma variável global não tem. Vide as telas azul do Windows kkkkkkkkkkkkkkkkkkkkkk.

Mas enfim, eu estou criticando isso para que no final, alguém um dia crie uma linguagem C mais moderna, pode ser dizer que o Java é isso mas o Java é limitado à sua portabilidade que o prende a um maldito interpretador, ou seja, não serve para escrever aplicações de verdade. Java é pra quem quer brincar de web e tem paciência para esperar coisas carregarem.
Ah, só mais um adendo, quando eu usava VB no ano 2000 , eu fazia chamadas às APIs do windows e não me lembro de precisar ficar pensando em endereços de memória para fazer isso. Ok, você vai dizer que por trás dos panos isso acontece, claro! da mesma forma que ao usar o paint a alocação de memória também acontece sem com isso ter que se obrigar o usuário a entender o que é segmentação e offset para desenhar uma bola. kkkkkkkkkkk. embora fosse ideal que ele soubesse. Da mesma forma é com um carro, o usuário quer dirigir mas não quer saber se o pistão onde é feita a explosão do combustível está em nível baixo ou alto no milissegundo da combustão. Isso é pouco produtivo na >>maioria<< dos casos.

adicionado 57 minutos depois

11 horas atrás, arfneto disse:
Veja a declaração de signal() por exemplo
void (*signal(int sig, void (*func)(int)))(int)
Esse tipo de uso é muito comum em C e é como um callback em javascript: você passa o endereço de uma função que retorna um int e trata... um sinal, nesse caso, como o control-c...

Isso me lembra o casting e é bem feio mas é familiar, é bem melhor
que isso abaixo:

[ZombaThread]

int xuxu(array <String^>^){

Deidei::Run(%form);

Sandorba(@"Hello, Quiba!");

LRESULT CALLBACK Repetiliana(HWND, UINT^, WPARAM, LPARAM)

}

arfneto · 3 de setembro de 2019

1 hora atrás, sandrofabres disse:

Ah, só mais um adendo, quando eu usava VB no ano 2000 , eu fazia chamadas às APIs do windows e não me lembro de precisar ficar pensando em endereços de memória para fazer isso. Ok, você vai dizer que por trás dos panos isso acontece, claro! da mesma forma que ao usar o paint a alocação de memória também acontece sem com isso ter que se obrigar o usuário a entender o que é segmentação e offset para desenhar uma bola

Esse é um exemplo curioso.

Você parece estar confundindo o usuário do Paint ao desenhar uma bola com o usuário da linguagem de programação, o autor do programa Paint. É bem possível que o autor de um programa de desenho como o Paint precise entender que alocação, regiões de memória, buffers de vídeo e textura, acesso a janelas e coisas assim....

Abaixo tem um trecho de um programa meu em C++, mas pode imaginar C, para apenas abrir a janela inicial para mostrar um gráfico, usando a biblioteca SDL, muito comum e uma alternativa a usar diretamente OpenGL ou DirectX

quem ver o gráfico não precisa saber essas coisas, mas as chamadas às funções em geral devolvem ponteiros para tudo, janelas, renders, texturas, qualquer coisa. Então quem programa o gráfico precisa saber e declarar essas coisas.

    bool Tela::init()
    {
        if (SDL_Init(SDL_INIT_VIDEO) < 0)
        {
            std::cout << "Erro: " << SDL_GetError() << std::endl;
            return false;
        }
        else
        {
            std::cout << "SDL OK!!" << std::endl;
        }

        m_window = SDL_CreateWindow(
            "Janela Principal",
            SDL_WINDOWPOS_UNDEFINED,
            SDL_WINDOWPOS_UNDEFINED,
            SCREEN_WIDTH,
            SCREEN_HEIGHT,
            SDL_WINDOW_SHOWN
        );
        if (m_window == NULL)
        {
            SDL_Quit();
            return false;
        }
        else
        {
            std::cout << "Janela Principal Criada" << std::endl;
        }

        m_renderer =
            SDL_CreateRenderer(m_window, -1, SDL_RENDERER_PRESENTVSYNC);
        if (m_renderer == NULL)
        {
            std::cout << "Erro ao criar renderer" << std::endl;
            SDL_DestroyWindow(m_window);
            SDL_Quit();
            return false;
        }
        else
        {
            std::cout << "renderer pronto" << std::endl;
        }    // end if

        m_texture =
            SDL_CreateTexture(
                m_renderer,
                SDL_PIXELFORMAT_RGBA8888,
                SDL_TEXTUREACCESS_STATIC,
                SCREEN_WIDTH,
                SCREEN_HEIGHT
            );
        if (m_texture == NULL)
        {
            std::cout << "Erro ao criar textura" << std::endl;
            SDL_DestroyRenderer(m_renderer);
            SDL_DestroyWindow(m_window);
            SDL_Quit();
            return false;
        }
        else
        {
            std::cout << "textura pronta" << std::endl;
        }    // end if

        SDL_UpdateTexture(m_texture, NULL, m_buffer1, SCREEN_WIDTH * sizeof(Uint32));
        SDL_RenderClear(m_renderer);
        SDL_RenderCopy(m_renderer, m_texture, NULL, NULL);
        SDL_RenderPresent(m_renderer);
        bool quit = false;

Escrever em Visual Basic podia tornar mais limpinho o programa, e demorar 12x mais, ficando inviável. Assim é. Use Visual Basic, crie a interface no designer, acerte o layout e siga em frente. Mas quando precisar de performance, mesmo que seja só para acessar as API do Windows, logo vai perceber que C++ ou C com muitos ponteiros estarão no seu caminho. E para sua sorte, ou não vai conseguir performance. Android por exemplo permite usar Java quase sempre, mas quando a performance é essencial se usa... C++. Até onde eu sei, Android foi escrito em C++...

Seu exemplo

Em 01/09/2019 às 19:07, sandrofabres disse:

Qual a vantagem de usar ponteiros por exemplo pra fazer x = (b+c);

também pode ser uma grande simplificação da realidade. Nem sempre x, b e c são assim poéticos int para você somar.

Em C++ x,b e c podem ser objetos, classes, complexas representando qualquer coisa. O operador '+' pode ser instruído --- sobrecarregado, overloaded --- para se adaptar a cada classe. Muitas vezes não é uma opção e sim um requisito: a soma de dois objetos tem que ser programada com cuidado. Imagine uma classe de vagões de trem por exemplo, e você pode usar o '+' para acoplar os vagões e montar a representação virtual de uma composição, e pode ter que alocar memória, acrescentar detalhes ao acoplamento, sinalizar o aumento de carga para redimensionar os motores das locomotivas de tração, implementados em outras classes, coisas assim.

Um game simples em C++ para crianças de 3 anos arrastarem blocos na tela pode exigir muitos e muitos ponteiros para a equipe que escreveu... buffers de tela, handles para janelas, ponteiros para fontes e texturas, sprites a serem carregados, um banco de dados tipo SQLite para manter os scores e contexto...

Use a ferramenta certa para o problema certo. Se quer usar certas linguagens e evitar certos recursos, como parece ser o caso, escolha os problemas de acordo.

.net é escrito em C++, OpenGL em C, SDL em C, Asterisk em C, Windows em C e C++, jogos são escritos em C++, muitos programas de CAD em C++, o kernel do linux é escrito em C.

Nem todo mundo precisa escrever esses programas ou escrever para essas plataformas. Você pode escrever em Python ou Ruby, bem legível e usar alguma interface --- binding --- para as bibliotecas em C. Até precisar de performance.

sandrofabres · 3 de setembro de 2019

1 hora atrás, arfneto disse:

Você parece estar confundindo o usuário do Paint ao desenhar uma bola com o usuário da linguagem de programação, o autor do programa Paint. É bem possível que o autor de um programa de desenho como o Paint precise entender que alocação, regiões de memória, buffers de vídeo e textura, acesso a janelas e coisas assim....

Posso estar exagerando mas não confundindo, para você pode ser um absurdo hoje, mas veja, na época do MS-DOS ou nas primeiras versões do Windows, o Windows 3.11 por exemplo, não só o autor de programas como o Paint(pbrush) como os seus usuários desses programas precisavam pensar em gerenciamento de memória sim(himem.sys, xms, ems umb, hma, DOS=HIGH), dependendo do tipo e do tamanho de bola que queriam fazer, tinham que ir nos config.sys da vida, colocar linhas sobre gerenciamento de memória alta, dar orientações sobre isso nos autoexec.bat da vida, reiniciar para depois o programa que desenha a bola poder funcionar, hoje em dia todo mundo faz coisa muito pior sem nem saber o que é um overlay ou uma memória RAM, acredite! As coisas em info evoluem exponencialmente de tal forma que hoje em dia, para se fazer um software como paint, usa-se uma biblioteca CANVAS e até em HTML pode ser feito o que ele faz sem com isso a pessoa precisar perder tempo e produtividade para brincar de pipes, dutes e física quântica(partículas entrelaçadas) com a memória( o que eu enfio ali, aparece 'magicamente' acolá ) para concebe-lo. Creio que o compilador deveria dar a opção de se usar isso mas não deveria tornar o seu uso obrigatório, mas enfim, desconfio que isso aconteça devido a rasões de compatibilidade com os anos onde a linguagem nasceu.
Veja,não estou criticando você por defender os ponteiros mas sim a linguagem.

adicionado 27 minutos depois

1 hora atrás, arfneto disse:

também pode ser uma grande simplificação da realidade. Nem sempre x, b e c são assim poéticos int para você somar.

Em C++ x,b e c podem ser objetos, classes, complexas representando qualquer coisa. O operador '+' pode ser instruído --- sobrecarregado, overloaded --- para se adaptar a cada classe. Muitas vezes não é uma opção e sim um requisito

Concordo, mas nós usamos computadores justamente porque queremos descomplicar as coisas, se não, trocaríamos planilhas por pedrinhas para fazer cálculos. Mas C/C++ parecem querer que você faça

isso:
int *x;

int *y;

int w=1;

int u=2;

x = &w;

y = &u;

printf("Soma: %i", *x + *y);

ao invés disso:

int x=1;

int y=2;
printf("Soma: %i", x+y);

E digo mais, vocês programadores nem têm culpa disso pois muitas vezes as funções das bibliotecas padrão do C/C++ exigem isso por capricho ou compatibilidade com os anos guaraná com rolha.
Como eu disse, por que o 'dono' do C não cria as funções getaddressmemory(varCoisa) e putmemory(endereco, value) a língua se moderniza todos ficam felizes? Você e ninguém aqui me respondeu, mas eu tenho quase que certeza que é por conta da retro compatibilidade e da trabalheira que daria para mudar isso nos headers de 19XX kkkkkkkkkkk, fala a verdade se não é isso????? Não tem outro motivo. Ixi, eu acho que eu mesmo questionei e eu mesmo me dei a resposta ahahahahahahaha.
Sem falar que pra criar um erro inesperado que ninguém consiga achar, fazendo aquilo chamamos em programação de 'espaguete' não tem coisa melhor do que usar ponteiros. É ór concur para se criar erros de lógica bizarros. kkkkkkk

1 hora atrás, arfneto disse:

Um game simples em C++ para crianças de 3 anos arrastarem blocos na tela pode exigir muitos e muitos ponteiros para a equipe que escreveu... buffers de tela, handles para janelas, ponteiros para fontes e texturas, sprites a serem carregados, um banco de dados tipo SQLite para manter os scores e contexto...

Fazendo uma brincadeirinha contigo : eu fico imaginando o quão trágico seria ter ponteiros apontando pra qualquer coisa numa query SQL de update e insert. Já imaginou? Uma tabela com 6 milhões de clientes, o ponteiro maroto vai lá, aponta pra um endereço achando que é outro e subscreve 4 milhões de registros de uma vez só e só depois é que se descobre, é de dar até um arrepio na alma. Ainda bem que isso não existe lá. Brincadeirinha kkkkkkkkkkkkkkk!

1 hora atrás, arfneto disse:

.net é escrito em C++, OpenGL em C, SDL em C, Asterisk em C, Windows em C e C++, jogos são escritos em C++, muitos programas de CAD em C++, o kernel do linux é escrito em C.

Sim, carros são feitos de metais, aviões são feitos de metais, mas eu não preciso ser metalúrgico ou engenheiro químico para manuseá-los, embora fosse lindo se eu tivesse conhecimento das duas coisas.
Hoje em dia, se eu quiser fazer um carro simples ou um avião, eu posso comprar as partes prontas sem precisar pensar em ir em Carajas garimpar metal , juntá-lo, criar um forno, derrete-lo, modelá-lo para depois montar o que eu quero, porém eu sei perfeitamente que se eu puder dominar todas as etapas eu terei um carro mais otimizado e talvez melhor.

É inquestionável o poder de C/C++ mas isso não impede de discutirmos melhorias, afinal, ao ficarmos maduros e com novas tecnologias disponíveis, temos novas necessidades de adaptação e espaço para melhorias, não acha?

adicionado 37 minutos depois

1 hora atrás, arfneto disse:

Então quem programa o gráfico precisa saber e declarar essas coisas.


    bool Tela::init()
    {
        if (SDL_Init(SDL_INIT_VIDEO) < 0)
        {
            std::cout << "Erro: " << SDL_GetError() << std::endl;
            return false;
        }
        else
        {
            std::cout << "SDL OK!!" << std::endl;
        }

        m_window = SDL_CreateWindow(
            "Janela Principal",
            SDL_WINDOWPOS_UNDEFINED,
            SDL_WINDOWPOS_UNDEFINED,
            SCREEN_WIDTH,
            SCREEN_HEIGHT,
            SDL_WINDOW_SHOWN
        );
        if (m_window == NULL)
        {
            SDL_Quit();
            return false;
        }
        else
        {
            std::cout << "Janela Principal Criada" << std::endl;
        }

        m_renderer =
            SDL_CreateRenderer(m_window, -1, SDL_RENDERER_PRESENTVSYNC);
        if (m_renderer == NULL)
        {
            std::cout << "Erro ao criar renderer" << std::endl;
            SDL_DestroyWindow(m_window);
            SDL_Quit();
            return false;
        }
        else
        {
            std::cout << "renderer pronto" << std::endl;
        }    // end if

        m_texture =
            SDL_CreateTexture(
                m_renderer,
                SDL_PIXELFORMAT_RGBA8888,
                SDL_TEXTUREACCESS_STATIC,
                SCREEN_WIDTH,
                SCREEN_HEIGHT
            );
        if (m_texture == NULL)
        {
            std::cout << "Erro ao criar textura" << std::endl;
            SDL_DestroyRenderer(m_renderer);
            SDL_DestroyWindow(m_window);
            SDL_Quit();
            return false;
        }
        else
        {
            std::cout << "textura pronta" << std::endl;
        }    // end if

        SDL_UpdateTexture(m_texture, NULL, m_buffer1, SCREEN_WIDTH * sizeof(Uint32));
        SDL_RenderClear(m_renderer);
        SDL_RenderCopy(m_renderer, m_texture, NULL, NULL);
        SDL_RenderPresent(m_renderer);
        bool quit = false;

O seu código exemplo me parece limpo e com sintaxe bem tradicional , é bonito e fácil de estudá-lo, os inventores podem fazer coisa mais direta ? Podem! Mas mesmo assim, não tenho muito o que me espantar com ele. Ele é bem mais familiar do que os exemplos que eu postei aqui antes. Basicamente são implementação de classes, chamada de métodos de classes , namespaces , métodos, argumentos, constantes , variáveis e instruções condicionais, nada que eu já não conheça. A única coisa que me deixou inseguro foi isso:
SCREEN_WIDTH * sizeof(UInt32) , não sei se isso é um ponteiro ou uma multiplicação,

como você pode ver, até nisso C/C++ precisa melhorar, o mesmo operador que serve pra multiplicar é usado pra fazer algo completamente diferente que é o ponteiro. Eu acho isso uma promiscuidade. Odeio promiscuidade em programação, por isso que eu sou a favor de criar getaddressmemory(varCoisa) e putaddressmemory(address, value) kkkkkkkkkkkkkk

arfneto · 3 de setembro de 2019

8 horas atrás, sandrofabres disse:

A única coisa que me deixou inseguro foi isso:
SCREEN_WIDTH * sizeof(UInt32)

Pois é. Esse código é o preâmbulo clássico para abrir uma janela na tela. Se achou familiar, entenda que todas essas funções SDL_ retornam... ponteiros e atuam em ponteiros m_renderer, m_windows, m_texture, buffer, todos são ponteiros. E se não alocar na ordem certa ou liberar na ordem certa, lá se vai uma área perdida de memória, ou vem um crash...

sizeof() é um operador. Apenas você precisa fazer as contas operando em relação ao tamanho da tela que vai usar...

8 horas atrás, sandrofabres disse:

Fazendo uma brincadeirinha contigo : eu fico imaginando o quão trágico seria ter ponteiros apontando pra qualquer coisa numa query SQL de update e insert

Em muitos casos é exatamente assim que funciona. Usando Oracle por exemplo, no modo mais versátil de operação, você aloca uma área de memória onde vai armazenar o comando SQL, chama uma função para preparar o comando e ele fica meio que compilado, esperando os parâmetros efetivos de cada Query, como um formulário. Então quando o programa coletou os dados chama uma outra função para executar a Query, define o que chama eu acho um cursor, e manda executar a Query para esse conjunto de dados, passando um ponteiro para a query preparada e um ponteiro para o buffer onde vão retornar os resultados. E aí se usa um iterador para "navegar" pelos resultados

Quando você usa uma linguagem de "mais alto nível" pra fazer algo parecido é porque alguém provavelmente já usou C ou C++ para escrever o que se chama em geral de language bindings. E vai se pagar algo em termos de performance claro.

8 horas atrás, sandrofabres disse:

É inquestionável o poder de C/C++ mas isso não impede de discutirmos melhorias, afinal, ao ficarmos maduros e com novas tecnologias disponíveis, temos novas necessidades de adaptação e espaço para melhorias, não acha?

Pois é: são exatamente ferramentas como essas que permitem a criação dessas novas tecnologias

Hoje você pode usar Unity, UnReal, SDL ou vários outros mecanismos para escrever games e ter uma vida mais fácil sem começar do zero toda vez.

Claro que essas coisas todas foram escritas em C++

Você pode escrever programas sofisticados para desktop usando no windows a plataforma .net.

Em C eu postei por exemplo aqui dias atrás um código até complicado para ajudar um usuário em um problema de encontrar nomes duplicados em um arquivo de 45000 linhas. De uma lida no código e você vai odiar. Em C, uma lista duplamente ligada. De ponteiros Se fosse em C++ usando a biblioteca padrão eu poderia declarar direto as estruturas como listas ligadas... ou árvores. ou hash ou sei lá. Tecnologias "novas".

Se eu usasse SQL poderia rapidamente colocar tudo num banco de dados totalmente contido em um arquivo. OK, teria uns ponteiros mas menos.

De todo modo esse é um forum para dúvidas de programação em C ou C++, então discutir essas coisas fica meio off-topic a menos que tenha uma dúvida na jogada. Bem, a dúvida pode ser: dá pra viver sem ponteiros em C ou C++?

vangodp · 4 de setembro de 2019

uma coisa é certa... eu n estou aqui para lhe convencer usar c++. Talvez para você seja mais avançado usar o java, ou portugol. Lá não tem ponteiros... ou sim?

Referente a ponteiros e trilhas, e sei lá que mais coisas você falou... você é livre de usar qualquer coisa que bem entender nos seus programas, globais, retorno de valores e etc, só n sei se vai fazer muita graça a quem lhe financie.

Se achar que ponteiros é muito hard deixe eles de lado ou volte a estudalos. Sobre todas essas coisas de ^ laranjas e cebolas nem ligue se você programar de forma padrão. Por outro lado se você tiver que usar visual c++, então melhor buscar uma boa guia.

Ansi C · 4 de setembro de 2019

Acredito que Frente as alternativas que existem C é claramente uma linguagem para quem deseja usar ponteiros com médio nível de manipulação de propósito geral.

Quem de fato compreende sua aritmética (de padaria) percebe que entorna seus objetos e nada se pode fazer a respeito disso (ninguém quer desde os anos 80).

É um padrão poderoso com mais de 3 décadas de aceitação.

18 horas atrás, vangodp disse:

Se achar que ponteiros é muito hard deixe eles de lado ou volte a estudalos.

sandrofabres · 5 de setembro de 2019

Em 03/09/2019 às 11:29, arfneto disse:

Pois é. Esse código é o preâmbulo clássico para abrir uma janela na tela. Se achou familiar, entenda que todas essas funções SDL_ retornam... ponteiros e atuam em ponteiros m_renderer, m_windows, m_texture, buffer, todos são ponteiros. E se não alocar na ordem certa ou liberar na ordem certa, lá se vai uma área perdida de memória, ou vem um crash...

Pois é Arfneto eu não questionei se a função X , Y e W usam ponteiros, Questionei? Em C/C++ o uso deles é tão trivial como se beber café no Brasil. Isso é indiscutível. O que eu fiz foi criticar a linguagem por não usar instruções como putinmemory(...) / getmemoryaddress(...) ao invés de operadores lógicos já usados para outras finalidades(promiscuidade) numa operação potencialmente perigosa. Se várias bibliotecas e programas adotam o uso de ponteiros é por motivo de herança da linguagem e falta de coisa melhor. Aviões voam queimando quilos e mais quilos de combustível por décadas, mas isso não quer dizer que a queima de combustível é algo legal, bonito e desejado, se alguém desenvolvesse um sistema antigravitacional para voar, o fato de todos os aviões do mundo ainda usarem combustível para isso, não tornaria a prática mais desejável só porque a maioria deles usa.

Em 03/09/2019 às 11:29, arfneto disse:

Pois é: são exatamente ferramentas como essas que permitem a criação dessas novas tecnologias

Sim, graças à pedra lascada desenvolvemos a roda, nem por isso eu vou ficar preconizando o uso de pedras como roda
só porque a primeira roda provavelmente foi baseada em uma.

Em 03/09/2019 às 21:44, vangodp disse:

uma coisa é certa... eu n estou aqui para lhe convencer usar c++. Talvez para você seja mais avançado usar o java, ou portugol. Lá não tem ponteiros... ou sim?

Amigo, quando a discussão vai pro lado do "eu não vou tentar te convencer disso ou daquilo" a coisa vai pro lado do emocional e foge à lógica, não tem logica alguma você me comunicar sobre uma coisa que não irá fazer. Se você não vai fazer, não precisa comunicar. Simples. Quando você faz isso está apenas gastando recursos computacionais pra nada.
O default é nada, se você não se manifesta, entendemos que você não fez nada até que se prove o contrário.

arfneto · 5 de setembro de 2019

2 horas atrás, sandrofabres disse:

Se várias bibliotecas e programas adotam o uso de ponteiros é por motivo de herança da linguagem e falta de coisa melhor

Talvez seja essa uma afirmação um tanto exagerada. Acho que leu aqui várias razões para isso ser feito, acessar ponteiros e endereços. Não é provavelmente incompetência ou preguiça ou inércia, ou herança de civilizações passadas. Em COBOL não havia ponteiros, em FORTRAN não havia ponteiros. E ainda não há. Isso não importa. Em java não há ponteiros, ou em javascript. Isso não importa.

Acho que entende que a memória do micro é endereçada por ponteiros, a execução de programas, o acesso a dados, os protocolos de rede... Suas funções objeto de desejo seriam escritas usando ponteiros para criar uma camada de abstração, como se faz em todas as linguagens que não tem isso. E essas camadas de abstração não são geradas por movimentos de fé e esperança mas sim por linguagens que permitem esse acesso. C, C++.

E alguém tem que programar essas coisas. Não será você, imagino, mas alguém vai escrever essas camadas de abstração , bem como os enormes frameworks tipo Unity, Unreal, .NET, OpenGL, DirectX...

Se você tivesse que controlar um satélite em órbita, um game em 4K, uma renderização de um modelo 3D numa máquina que você aluga por minuto, uma tabela de um firewall com tráfego de milhares de mensagens por segundo não estaria conjecturando sobre essas coisas.

Se alguém te paga para escrever software de alta performance, sistemas de controle em tempo real, automação de fábrica, coisas assim, não vai sequer deixar você começar a falar sobre essa "falta de coisa melhor" porque o melhor se mede em nanosegundos e qualquer abstração, qualquer camada intermediária, sai muito cara.

Existem problemas que podem muito bem serem resolvidos com outras ferramentas ou mesmo em C ou C++ sem usar ponteiros, e você muito bem ter uma carreira sólida escrevendo soluções para esses problemas.

Uma óbvia exceção seria o próprio desenvolvimento dessas ferramentas.

Taxar essas linguagens de alta performance como antiquadas ou produto de inércia talvez seja um pouco ingênuo ou arrogante., ou os dois. Muita gente dizia tempos atrás que programar em Assembler era um atraso e era obsoleto porque a manutenção era cara e a portabilidade era nula e tal. Nunca fez diferença e rotinas de alta performance são assim programadas. Mais ainda: hoje em dia montanhas de dinheiro são investidas em FPGA, chips de muito alta performance programáveis em campo. Acredita que alguém está procurando nova linguagens supermodernas sem ponteiros e pessoas que saibam usá-las para programar esses chips? Não, não estão não:

sandrofabres · 5 de setembro de 2019

4 horas atrás, arfneto disse:

Talvez seja essa uma afirmação um tanto exagerada. Acho que leu aqui várias razões para isso ser feito, acessar ponteiros e endereços. Não é provavelmente incompetência ou preguiça ou inércia, ou herança de civilizações passadas. Em COBOL não havia ponteiros, em FORTRAN não havia ponteiros. E ainda não há. Isso não importa. Em java não há ponteiros, ou em javascript. Isso não importa.

Bibliotecas do C/C++ ou arquivos de cabeçalho dessas linguagens realmente não precisam manter compatibilidade com Cobol e Fortran porque são linguagens distintas. Quando eu disse sobre a herança me referi ao tempo que C existe, uma linguagem que foi concebida lá pelo fim dos anos 60 e que vem gerando programas e programadores até os dias hoje não pode se dar ao luxo de mudar os seus paradigmas do dia para a noite, cria-se então um legado. Em informática isso é muito comum: coisas modernas mantendo sistemas de compatibilidade com legados.
Veja, até Cobol que é mais velho que C implementa ponteiro de forma mais elegante, até parece que você está montando uma sentença em inglês, você tem a sensação que está montando uma frase e não programando.

4 horas atrás, arfneto disse:

Acho que entende que a memória do micro é endereçada por ponteiros, a execução de programas, o acesso a dados, os protocolos de rede...

A memória do computador é endereçada pelo processador e alocada pelo sistema operacional e não é usado variáveis definidas por usuários com & e * em seus nomes, mas sim registradores específicos que não mudam o nome como os ponteiros de C fazem. Existem regiões de memória que viram 'tabelas' como PCB a NVP a mando do SO para se localizar processos mas elas são tabelas que são traduzidas ou que contêm referencias para outras posições na memória, elas são apenas endereços interpretados por outros processos que procuram outros endereços, é parecido com o ponteiro do C mas não é o ponteiro do C. Já os registradores como o SP e BP (começo e fim da pilha) levam o nome de ponteiro mas não são ponteiros da linguagem C, eles apontam apenas para lugares específicos que se espera que eles apontem, eles não têm nome variável , ao contrário de C que possuem nomes variáveis, apontam pra qualquer tipo de lixo e podem ser usados quando não se precisa usá-los.
Ou seja , se na sua concepção uma coisa fazer referência a outra é um ponteiro igual ao do C, temos ponteiros do C até na vida real: o meu espelho é um ponteiro C , o meu repetidor é um ponteiro C, os meus telefones celulares e comuns são ponteiros do C e até mesmo o emaranhamento quântico é um ponteiro C.
E por tudo isso, tudo que não é ponteiro C, mesmo que não precise, deveria também ser um ponteiro C só porque um monte de coisa funciona de forma análoga.

adicionado 15 minutos depois

4 horas atrás, arfneto disse:

E essas camadas de abstração não são geradas por movimentos de fé e esperança mas sim por linguagens que permitem esse acesso. C, C++.

Amigo, eu não estou criticando o fato de uma linguagem dar acesso ao desenvolvedor à memória mas sim o fato da linguagem forçar o desenvolvedor a usar o mesmo caminho que faria para fazer acesso à memória, para coisas fúteis. Veja, no meu sistema operacional eu posso gerenciar coisas na memória até com um script de texto simples sem precisar compilar nada, mas ele não me obriga, para eu mexer o cursor do mouse , ficar passando códigos bit a bit para o endereço de memória que represente isso no vídeo, embora isso fosse possível! Ok, aí você vai me falar:
-- "Ah, mas por trás dos panos ele faz isso!"
Claro! A função do sistema operacional é essa, gerenciar o hardware para atender as necessidades do usuário! É obvio que 'qualquer coisa' que eu faça num computador, vai ter uma estrutura de processos complexa envolvendo memória por trás, mas eu não sou forçado a ficar usando os mesmos caminhos desses processos para realizar uma ação besta como mover um cursor. O importante é que o sistema me permita fazer isso quando eu quiser e não quando ele impõe.

sandrofabres · 5 de setembro de 2019

3 horas atrás, arfneto disse:

Se você tivesse que controlar um satélite em órbita, um game em 4K, uma renderização de um modelo 3D numa máquina que você aluga por minuto, uma tabela de um firewall com tráfego de milhares de mensagens por segundo não estaria conjecturando sobre essas coisas.

Como eu já lhe disse e você parece fazer um esforço monumental em não entender: eu não estou criticando C por dar acesso à memória ao desenvolvedor, estou criticando C por obrigar a fazer isso as vezes quando não se precisa fazer e ainda por cima usando operadores que são usados para outras coisas muito diferentes. Veja que COBOL faz isso de uma forma muito mais elegante e qualquer 'criador de linguagens' como C poderia fazer isso melhor, ou você não acredita em melhorias?

3 horas atrás, arfneto disse:

Se alguém te paga para escrever software de alta performance, sistemas de controle em tempo real, automação de fábrica, coisas assim, não vai sequer deixar você começar a falar sobre essa "falta de coisa melhor" porque o melhor se mede em nanosegundos e qualquer abstração, qualquer camada intermediária, sai muito cara.

Bom, eu creio que você conheça de práticas ITIL e PMBOK para projetos, sendo assim, você deve saber que uma empresa que quisesse um projeto de informática para um sistema em tempo real faria um projeto de tudo com uma EAP e uma lista de gestão de custos antes disso chegar nas mãos de um desenvolvedor justamente para se evitar a "falta de coisa melhor" entrar no projeto. Isso é norma em empresas que tenham visão estratégica dos negócios e que não funcionam apenas "a toque de caixa" como uma pastelaria.

3 horas atrás, arfneto disse:

Taxar essas linguagens de alta performance como antiquadas ou produto de inércia talvez seja um pouco ingênuo ou arrogante.,

Em muitas coisas é antiquada mesmo, ou você não acredita em evolução/melhoria , ainda mais em uma área como TI???????? C nem orientação a objeto usa, para que você acha que surgiu C++? Por arrogância? kkkkkkkkkk
Pela forma que você apregoa todo mundo deveria então largar mão até mesmo de C para fazer tudo em Assembly só porque ela gera códigos bem mais enxutos. Ótimo, vamos propor que se acabe com C/C++ e vamos fazer só aplicações grandiosas em Assemply, imagine como seria produtivo e vantajoso escrever o FinalCut Pro todo em Assembly via terminal usando o vi ou o nano! kkkkkkkkkkkkkkk
O problema na sua defesa ao C/C++ e ponteiros está aí: achar que nada pode ser melhorado e que tudo deve ficar como está como se todo mundo só quisesse escrever código para arduino mesmo quando quisesse usar um simples printf. Isso sim que me parece mais com arrogância. Sabe aquele código que você me mostrou acima então, você deveria preferir apresentá-lo em Assembly e quando quisesse usar coisas apontando para outras, usar um jmp tipo
o espaguete GOTO do BASIC kkkkkkkkkk. Por que você não faz isso se a prioridade é apenas performance ? Não entendi.

adicionado 14 minutos depois

4 horas atrás, arfneto disse:

Acredita que alguém está procurando nova linguagens supermodernas sem ponteiros e pessoas que saibam usá-las para programar esses chips? Não, não estão não:

E você acredita que todo mundo só quer usar C/C++ para programar chips?
Nem toda pessoa que usa tesoura é cabeleireira ...
Nem todo mundo que usa estilete é trombadinha ...
Nem todo mundo que mexe com fogo é cozinheiro ...
Uma boa ferramenta pode ser empregada para várias tarefas e profissionais diferentes.

adicionado 22 minutos depois

13 horas atrás, MB_ disse:

É um padrão poderoso com mais de 3 décadas de aceitação.

Isso não quer dizer que não possa ser melhorado, não é?

Ansi C · 5 de setembro de 2019

14 horas atrás, sandrofabres disse:

Isso não quer dizer que não possa ser melhorado, não é?

Para essas melhorias deram até um nome (~1950) POO. Programação Orientada a Objetos é o paradigma que muito se distância do apelo matemático (~1960), muito recorrente na programação de ponteiros no C (~1970), dizem que é mais produtiva e de fácil utilização e reutilização de programas (~2000).

Paradigma Funcional (~1930) é uma revira volta na mesa, de uma lado há POO e do outro PP/I então PF está no meio do caminho para PP/I retomando a fervo matemático na ciência da computação que de certa "é só uma ramo da matemática" (~2016).

Você não erra em continuar querendo implementações para o C, só está um pouco "atrasadinho". Pois o significativo já está aí.

vangodp · 5 de setembro de 2019

Amiguinho... Pra começar, fopen faz parte de C, em c++ se usa streams e n ponteiros, você parece ser "um crack" em praticamente tudo o que faz, um ser superior, divino de luz, inclusive mais inteligente que o criador da linguagem, e de tudo entende, deveria saber disso e não usar exemplos desnecessários e fazer a todos os usuários perder tempo. Eu vejo utilidade no caso do fopen, outra coisa é que você não consiga ver. Se tiver mais consultas escreva, ou mais casos de mal uso de ponteiros, bota ai, ou não nos faça perder mais tempo.

sinceramente acredito que este tema n leva a parte alguma e já ta tardando em ser moderado.

adicionado 2 minutos depois

8 horas atrás, sandrofabres disse:

E você acredita que todo mundo só quer usar C/C++ para programar chips?

não... o faremos em java que é muito melhor. >_<

isrnick · 5 de setembro de 2019

Sobre o motivo da linguagem C usar * para indireção/desreferenciamento, se deve ao fato de que a linguagem B já o usava assim, e o C apenas copiou do B.

Agora o motivo por que o B escolheu usar esses caracteres que já tinham outras funções, ao invés de escolher outros caracteres, isso ocorreu pois o teclado usado no computador no qual a linguagem B foi desenvolvida tinha uma quantidade limitada de caracteres, e após certo ponto se tornou necessário reutilizar caracteres.

https://softwareengineering.stackexchange.com/questions/252023/why-does-c-use-the-asterisk-for-pointers

Sim, mudar o caractere para algum sem uso, ou menos usado, melhoria a legibilidade do código.

Mas a proposta do C é ser uma linguagem de sistema minimalista, no sentido de que a quantidade de recursos fundamentais e da biblioteca padrão sejam os mínimos necessários para facilitar a implementação de um compilador para qualquer nova arquitetura ou plataforma que surja, tornando mais fácil compilar códigos C para a nova plataforma.

Existe uma quantidade grande de codebases fundamentais em C, incluindo kernels, SOs, compiladores de outras linguagens, e bibliotecas para uma infinidade de recursos, que são mantidos a décadas (as vezes quase inalterados), então mudanças no C devem ser uma adição ao invés de uma alteração, a menos que não haja opção, para não quebrar a compatibilidade códigos legados.

Então, permitir maneiras alternativas de fazer a mesma coisa implicaria ter 2 modos de fazer a mesma coisa, o que aumentaria a complexidade da linguagem, indo contra sua proposta. Isso não quer dizer que o comitê não aceita adicionar mais nenhuma alteração ao padrão do C, mas deve ser algo que adicione funcionalidade não apenas altere uma existente, e tem que ser uma funcionalidade absolutamente necessária, caso contrário a funcionalidade deverá ser obtida através de bibliotecas de terceiros ou implementada pelo programador.

Logo, as chances de fazerem esse tipo de alteração por motivo de legibilidade, praticidade ou conveniência é perto de zero.

Agora quanto ao problema da falta de segurança dos ponteiros, sim o C é uma linguagem muito insegura, colocando a responsabilidade no programador de fazer verificações e checagens tal que garanta o uso seguro da memória, e sim isso é consequência do histórico da linguagem, e provavelmente não vai ser modificado pelos mesmos motivos acima.

Mas se você quer uma alternativa com ponteiros seguros, pelo menos agora existe a opção de usar a linguagem RUST, porém a notação nele foi herdada do C então você não vai escapar do * e & para ponteiros e endereços. Mas talvez você tenha mais sucesso sugerindo esse tipo de mudança para o RUST, visto que é uma linguagem nova e teoricamente ainda dá tempo de fazer esse tipo de alteração, a questão é conseguir convencer a comunidade de que essa é uma alteração necessária, visto que para bem ou mal essa notação já é muito aceita.

arfneto · 5 de setembro de 2019

14 horas atrás, sandrofabres disse:

Como eu já lhe disse e você parece fazer um esforço monumental em não entender: eu não estou criticando C por dar acesso à memória ao desenvolvedor, estou criticando C por obrigar a fazer isso as vezes quando não se precisa fazer e ainda por cima usando operadores que são usados para outras coisas muito diferentes. Veja que COBOL faz isso de uma forma muito mais elegante e qualquer 'criador de linguagens' como C poderia fazer isso melhor, ou você não acredita em melhorias?

Não fiz muito esforço não. Mas tenho tentado, como outros, te explicar que essa eventual "obrigação" em C de usar ponteiros "quando não se precisa" é mínima, se restringindo a declarar um ponteiro para acesso a arquivos e no uso comum de funções que manipulam strings, que afinal são isso, um ponteiro no caso C

Não sei se de fato já escreveu ou mesmo leu um programa COBOL, mas COBOL não tem de fato esses mecanismos, elegantes ou não. Uma seção, WORKING-STORAGE SECTION define as variáveis e os formatos. Em outra seção, FILE SECTION, registros definem o formato de cada "registro" do arquivo. Existem outros lugares onde se pode definir registros, como a REPORT SECTION e a DECLARATIVES SECTION para os poucos que ainda souberem como usar isso.

Curiosamente alguns mecanismos de conexão entre COBOL e bancos de dados e terminais de mainframe usavam --- usam --- ponteiros para áreas de memória. Mundo pequeno

14 horas atrás, sandrofabres disse:

Bom, eu creio que você conheça de práticas ITIL e PMBOK para projetos, sendo assim, você deve saber que uma empresa que quisesse um projeto de informática para um sistema em tempo real faria um projeto de tudo com uma EAP e uma lista de gestão de custos antes disso chegar nas mãos de um desenvolvedor justamente para se evitar a "falta de coisa melhor" entrar no projeto. Isso é norma em empresas que tenham visão estratégica dos negócios e que não funcionam apenas "a toque de caixa" como uma pastelaria

Não entendi o que quer dizer com isso. Talvez tenha confundido o que são sistemas em tempo real ou --- mais provável --- eu tenha me explicado mal. Sistemas em tempo real são sistemas em que o tempo de reação é fundamental. Coisas como automação e controle de fábrica, controle de mensagens como um protocolo ou um firewall. Eu tentava mais uma vez dizer que em aplicações desse tipo a velocidade é obtida através de ponteiros e acesso direto à memória. Exemplo: muitos sensores funcionam assim. São antiquados você diria: quando tem uma leitura ele gera um sinal num certo endereço e disponibiliza a leitura em um buffer e você tem milissegundos para ler

14 horas atrás, sandrofabres disse:

Pela forma que você apregoa todo mundo deveria então largar mão até mesmo de C para fazer tudo em Assembly só porque ela gera códigos bem mais enxutos. Ótimo, vamos propor que se acabe com C/C++ e vamos fazer só aplicações grandiosas em Assemply, imagine como seria produtivo e vantajoso escrever o FinalCut Pro todo em Assembly via terminal usando o vi ou o nano!

Não sei de onde conclui o que eu estou apregoando. Talvez não tenha lido com atenção o que eu escrevi. Vou repetir: há objetiva razão para usar assembler ou C ou C++ em muitos casos. Em especial quando se precisa de performance.

FinalCut Pro é um bom exemplo: esses programas se valem fortemente da capacidade de processamento das placas de vídeo e as possibilidades de cálculo em paralelo que essas placas oferecem. Tudo isso é acessado via ponterios e buffers de memória. E escrito em C++ e Assembler.

15 horas atrás, sandrofabres disse:

Sabe aquele código que você me mostrou acima então, você deveria preferir apresentá-lo em Assembly e quando quisesse usar coisas apontando para outras, usar um jmp tipo
o espaguete GOTO do BASIC

JMP não aponta para coisas. Talvez você estivesse pensando em instruções tipo LOAD ou ADD ou CALL que apontam para endereços de memória ou registradores. Eu só tentei te dar um exemplo usando SDL de que os ponteiros são caminho curto e simples.

15 horas atrás, sandrofabres disse:

E você acredita que todo mundo só quer usar C/C++ para programar chips?

C e C++ tem condição de atender muitos usos. Sem ponteiros ou com ponteiros. Destrutores, construtores com parâmetros, construtores de cópia, qualificadores como const e private, a enorme biblioteca padrão com as estruturas de dados que exigiam um número ridículo de ponteiros para programar em C, como listas, hash, filas, pilhas e árvores.

Mas os programas em geral rodam em sistemas e os sistemas rodam com memória, barramento e mensagens. Tudo isso pode ser abstraído mas a abstração tem um custo e requer uma ferramenta para escreve-la

Desculpe mesmo se pareci arrogante em alguma parte do que escrevi.

sandrofabres · 7 de setembro de 2019

Em 05/09/2019 às 09:28, MB_ disse:

Você não erra em continuar querendo implementações para o C, só está um pouco "atrasadinho". Pois o significativo já está aí.

Eu não estou 'atrasadinho' pois as implementações que eu imaginei para a linguagem ainda não ocorreram.

adicionado 14 minutos depois

Em 05/09/2019 às 20:02, arfneto disse:

Não sei se de fato já escreveu ou mesmo leu um programa COBOL, mas COBOL não tem de fato esses mecanismos, elegantes ou não. Uma seção, WORKING-STORAGE SECTION define as variáveis e os formatos. Em outra seção, FILE SECTION, registros definem o formato de cada "registro" do arquivo. Existem outros lugares onde se pode definir registros, como a REPORT SECTION e a DECLARATIVES SECTION para os poucos que ainda souberem como usar isso.

Olha, esse texto COBOL que você mostrou totalmente desconexo sem contexto nem trata sobre o assunto que estamos discutindo. O ponto é: ponteiro é mais elegante em COBOL sim, as outras instruções eu deixo para falarmos em outro momento.

Repare que no caso abaixo, você tem a impressão que está montando uma sentença em inglês:

'SET ponteiro TO ADDRESS OF casaDeNoca'

É claro que o estilo não tem nada com C , mas é bem mais limpo do que ficar se usando coisas com dupla função
para se fazer operações potencialmente perigosas.
Só da pessoa ler a sentença acima, por mais leiga que ela seja, ela tem ideia do que está se fazendo. Você vai negar isso?

adicionado 22 minutos depois

Em 05/09/2019 às 20:02, arfneto disse:

Não entendi o que quer dizer com isso. Talvez tenha confundido o que são sistemas em tempo real ou --- mais provável --- eu tenha me explicado mal.

É... Vemos que no seu caso, uma empresa vai desenvolver sistemas de tempo real sem fazer nenhum projeto atendendo
as recomendações ITIL e PMBOK , bom, eu estou rindo muito pensando nessa situação, mas não quero discutir aqui sobre gestão de projetos para não fugir muito do ponto discutido. Espero que reflita mais sobre o que eu quis dizer.

adicionado 39 minutos depois

Em 05/09/2019 às 20:02, arfneto disse:

Não sei de onde conclui o que eu estou apregoando. Talvez não tenha lido com atenção o que eu escrevi. Vou repetir: há objetiva razão para usar assembler ou C ou C++ em muitos casos. Em especial quando se precisa de performance.

É verdade... Mas o que adiantaria termos um programa com alta performance que demora 20 anos para ser escrito?

Sim, Quando eu lhe indaguei sobre fazer o Final Cut Pro em Assembly , não me referi só aqueles códigos marotos para se explorar núcleos cuda de uma placa de vídeo mas sim da interface do usuário até a sua renderização. Faça toda essa tarefa na unha usando Assembly e depois vamos falar de performance... Performance em lhe manter no emprego, isso sim... kkkkkkkkkk
Ah, outra coisa, quando se quer performance hoje em dia, não se fala só em acesso à memória mas sim no emprego threads
que até em Python é muito simples de se chamar.

adicionado 46 minutos depois

Em 05/09/2019 às 20:02, arfneto disse:

C e C++ tem condição de atender muitos usos. Sem ponteiros ou com ponteiros. Destrutores, construtores com parâmetros, construtores de cópia, qualificadores como const e private, a enorme biblioteca padrão com as estruturas de dados que exigiam um número ridículo de ponteiros para programar em C, como listas, hash, filas, pilhas e árvores.

Fico feliz em finalmente você perceber que C/C++ pode ter vários usos, inclusive para quem não necessariamente quer saber com riqueza de detalhes sobre funcionamento do hardware.

sandrofabres · 8 de setembro de 2019

Em 05/09/2019 às 20:02, arfneto disse:

JMP não aponta para coisas. Talvez você estivesse pensando em instruções tipo LOAD ou ADD ou CALL que apontam para endereços de memória ou registradores. Eu só tentei te dar um exemplo usando SDL de que os ponteiros são caminho curto e simples.

JMP, é um mnemônico de jump que em português quer dizer 'salto' e quem salta, salta para um lugar, principalmente em programação e como você bem gosta de lembrar que por trás dos panos existe ponteiros de memória, é correto se afirmar
que uma instrução GOTO, uma function ou mesmo um JMP é uma instrução que faz o registrador SP apontar para um local na memória para se continuar algo, não é usual se afirmar, mas podemos falar que isso também é um tipo ponteiro rudimentar.

Ansi C · 8 de setembro de 2019

15 horas atrás, sandrofabres disse:

as implementações que eu imaginei para a linguagem ainda não ocorreram.

Isso dos ponteiros? É uma dificuldade pessoal. Foi essa a observação que já fiz.

vangodp · 8 de setembro de 2019

20 horas atrás, sandrofabres disse:

Em 05/09/2019 às 14:28, MB_ disse:

Você não erra em continuar querendo implementações para o C, só está um pouco "atrasadinho". Pois o significativo já está aí.

Eu não estou 'atrasadinho' pois as implementações que eu imaginei para a linguagem ainda não ocorreram.

Nem vão ocorrer shuehsuhseh

adicionado 7 minutos depois

20 horas atrás, sandrofabres disse:

Em 06/09/2019 às 01:02, arfneto disse:

Não sei de onde conclui o que eu estou apregoando. Talvez não tenha lido com atenção o que eu escrevi. Vou repetir: há objetiva razão para usar assembler ou C ou C++ em muitos casos. Em especial quando se precisa de performance.

É verdade... Mas o que adiantaria termos um programa com alta performance que demora 20 anos para ser escrito?

Não exagere, para controladores todo mundo sabe que C é "perfeito", por isso nunca vão ocorrer "implementações" nem mudanças.