No. "C" não retorna nada por registrador ou stack ou o que quer que seja. Isso depende da implementação, isto é, do compilador. Aliás o normal é você definir um padrão de retorno na própria pilha. C *define* o valor de retorno sendo "uma única coisa" porque, originalmente, a ideia é que a função retornasse um código de erro ou ok (portanto um simples int). A ideia era fazer um tratamento de erros simplificado. Quando C foi criada não existia a ideia de objetos (até existia, mas era simplesmente impraticável a época e não dava para ter coisas como exceptions ou traps). O retorno propriamente falando das funções seria via "parâmetros de saída", ou seja, via parâmetros por referência (via apontadores). Mas isso foi rapidamente evoluído. Dá pra retornar structs. Com structs e um conjunto de macros você retorna o que quiser hoje, até mesmo tuplas. O rapaz do vídeo me parece bem bacana e tenta falar de forma simplificada. Mas aí é que pega. C não é nem simples, nem baixo nível como a galera vende. Os níveis de abstração de C são altos (e dá pra desenvolver outro ainda mais altos). O que C não tem, *por desenho* é um monte de bibliotecas e algoritmos prontos, justamente porque a linguagem foi concebida para ser compilada para uma plataforma Von Neuman genérica e que não tivesse "nada", nem SO, nenhum tipo de runtime, "nada" mesmo. Aliás, C foi concebida para se desenvolver o Unix, isto é, um SO. (EDITADA para consertar errinhos ortográficos)
@@gabrielrosapaz3069 Também não. A arquitetura x86 foi concebida somente em 1978, para equipar os processadores 8088 e 8086, que equiparam os primeiros PCs de 1980 em diante. A linguagem C foi concebida, a partir da B, em 1968, sendo a sua primeira "versão" efetiva a de 1972, a de K&R. Em 1980 já havia a versão "padrão" de C, a versão ANSI. C foi concebida para implementar o Unix, mas ser uma linguagem de alto nível. Portanto a visão dos projetistas era de sistemas tipo main ou mid frames, não PCs, que viriam a se tornar populares uns 10 anos depois. Portanto, C tem pouco ou nada a ver com a arquitetura x86. A própria teoria dos compiladores modernos foi desenvolvida somente no final da década de 70 e início da década 80, notadamente graças aos esforços da Universidade de Illinois (Campus de Urbana) que resultou no LLVM e, posteriormente, no CLang. Todas as demais linguagens já se beneficiaram desses esforços. Aliás, já foram construídas já se pensando em se ter um compilador tipo LLVM em mente (ex.: C++). Com C (puro) não!, se bem que a LLVM foi pensada principalmente para otimizar o C para as arquiteturas de hardware mais modernas. Caraca, tô ficando velho, porque cheguei a ver o nascimento de C++ e a participar da evolução do C ainda na década de 80!
Não depende da implementação exatamente. Como o autor mostrou, mais no final, depende muito mais da ABI. Claro, se você estiver escrevendo um compilador que vai ser chamado pela sua própria libc ou pro seu próprio sistema operacional, você pode fazer como quiser. Caso contrário, quem gera código tem que seguir a ABI.
Opa, curti bastante o vídeo. Parabéns! Uma indicação de material introdutório pra quem quiser é o livro Programação em Baixo Nível do Igor Zhirkov. Ele trata sobre assembly pra arq. x86-64, um basicão sobre arquitetura de computadores, processos realizados entre o C e assembly e um pouco mais. Logo no início você percebe o pq de não existir mais de um retorno pra funções em C.
Fico feliz que curtiu o vídeo, Gustavo! E mt massa recomendação, vou procurar e baixar aqui pra ler. Essa área de baixo nível acho super interessante, o que mais vi foi de CPU, mas quero tmb dar uma estudada mais a fundo em como as GPUs funcionam. Inclusive devo fazer um vídeo sobre modelo de programação em GPU e ir aprofundando o tema
C atua mais diretamente com a memória, portanto esse "um valor" pode ser um PONTEIRO (endereço de memória) que aponta para uma estrutura de informação mais complexa. Quando vc retorna um objeto em linguagens mais novas, no final das contas vc está retornando uma "ponteiro" para aquela instância.
Importante que essa estrutura tem que ser criada na stack acima ou no heap, caso contrário vai ser destruída ao final da função e vamos ficar com um ponteiro inválido. Inclusive é assim que se retorna structs, na função é injetado como primeiro parâmetro um ponteiro pra struct, essa struct é criada na função acima, e então a função chamada modifica o valor apontado, assim "retornando" a struct.
Conteúdo do vídeo tá bem legal, não sabia que o retorno é feito por registradores. Mas uma crítica construtiva: acho que dá pra tu melhorar um pouco a apresentação e ser mais direto
isso, o único jeito de fazer o retorno de multiplos valores seria vocês mesmo implementando uma tupla por meio de struct (igual python, js, e outras linguas com gc fazem), ou passa todos os paramentros como referência e escreve pra eles os valores de retorno e quando forem ler eles na função acima eles vão ter os valores modificados.
Tudo isso é ponteiro ou um único registrador. Única exceção é struct, que C implicitamente coloca um primeiro parâmetro de entrada como ponteiro pra struct e na função e seta o valor desse ponteiro. Então todos esses exemplos continuam retornando apenas um valor
Engraçado que só pelo nível de conhecimento e os assuntos tocados eu já desconfiava que tu cursou eng em computação, ai eu fui entrar no teu site e acertei kkkkkkkkkkkkkkkkkk
Em C, uma função por padrão não pode retornar mais de um valor diretamente. No entanto, existem algumas técnicas que você pode usar para obter um efeito semelhante. Aqui estão duas abordagens comuns: 1. **Usar Ponteiros**: Você pode passar argumentos para a função por referência usando ponteiros. A função pode então modificar os valores nos endereços apontados pelos ponteiros. #include void retornaDoisValores(int *a, int *b) { *a = 5; // Define o primeiro valor *b = 10; // Define o segundo valor } int main() { int valor1, valor2; retornaDoisValores(&valor1, &valor2); printf("Valor1: %d Valor2: %d ", valor1, valor2); return 0; } 2. **Usar Estruturas**: Você pode definir uma estrutura para armazenar vários valores e retornar uma instância dessa estrutura. #include typedef struct { int valor1; int valor2; } ValoresRetorno; ValoresRetorno retornaDoisValores() { ValoresRetorno valores; valores.valor1 = 5; valores.valor2 = 10; return valores; } int main() { ValoresRetorno resultado = retornaDoisValores(); printf("Valor1: %d Valor2: %d ", resultado.valor1, resultado.valor2); return 0; } Ambas as abordagens permitem que você "retorne" mais de um valor de uma função em C. A escolha entre usar ponteiros ou estruturas depende do contexto específico e das necessidades do problema a ser resolvido.
Boa pergunta, não conheço não. Talvez FPGAs ou coprocessadores especializados. Mas o conceito de stackframe é mt poderoso pra rodar e fazer programas, nem se imagino como seria programar sem isso
Mas acredito que as linguagens de alto nivel tb voltam apenas um valor no retorno de suas funções, isso por baixo dos panos. Baseado na orquestraçào das mudanças dos contextos. Por exemplo: Em C# quando retornamos instâncias de objetos complexos (classes, listas, arrays etc), é retornado apenas o endereço da instância do objeto, ou seja apenas um valor. Esse aprimoramento que C não cuida, bem como vc disse, devido ao seu legado histórico.
po, no meu jeito de ver, na verdade, eu acho que linguagens de alto nível resolvem esse problema na verdade retornando uma lista de elementos, ou seja, um estrutura de lista com cada elemento que eu queria retornar é criada, e a função a nível de assembly guarda o endereço no registrador de retorno, e depois quem recebe esses valores, a linguagem sabe recuperar o endereço dessa lista e manipular ela de forma a resgatar cada endereço para guardar em cada variável, a nível de assembly a função continua retornando somente uma coisa, mas essa coisa é um endereço de memoria, e em C "não conseguimos" retornar mais de uma coisa por que a linguagem C por si só bota mais coisas na mão do programador para ser feito, claro, se assim ele quiser né, retornar mais de um dado por uma função só corrigindo uma formalismo técnico, C também é alto nível, quando usei "linguagens de alto nivel", quis referenciar a linguagens que tem mais abstrações como nao precisar manipular memoria diretamente, oferecer métodos padrões ja implementados em todos os objetos que podem somente ser usados (sobrescrita de metodo de OOP), etc
Se a linguagem tem GC, reference count, ou gerenciamento automático, pode retornar de qualquer modo os valores, alocando até no heap mesmo (como consigo retornar um vetor de uma função? Só usando heap). Também as estruturas de retorno não são limitadas por um valor por design da linguagem, aí como cada linguagem faz vai depender de cada uma. Você pode inclusive nem retornar nada, só mexer em valores na "stack" interna da linguagem, adicionando ou removendo valores, etc. ou pode fazer como você disse, retornar uma lista de valores. Mas aí fica a pergunta: por que só uma lista? Por que não um dicionário? Por que não um set? Por que não um objeto genérico da linguagem? etc. Pra linguagens que precisam de um gereciamento manual de memória, é feita alguma magia por baixo dos panos pra fazer isso, que é passar uma referência como parâmetro pra função para que então seja utilizada internamente na função (esse post explica sobre isso stackoverflow.com/questions/39068492/c-c-returning-struct-by-value-under-the-hood) Então esse problema só é relevante em C/C++/semelhantes com relação a memória e essa limitação. Pra linguagens tipo Go, Java, Python, JavaScript, é só criar um novo objeto e retornar a referência que depois o GC cuida dele, além de terem uma estrutura/sintaxe de retorno que não é limitada por um valor, como é em C. A parte de assembly já fica bem distante dessas linguagens, é até difícil comparar.
Motivo: porque C não esconde a existência de ponteiros. Você pode retornar um ponteiro pra uma struct qualquer e se bobear até um void* e depois tratar esse cara como algo mais dinâmico
Que massa que curtiu, Wesley! Eu compartilho bastante no Instagram umas fontes, mas também vou começar a fazer por aqui esse tipo de conteúdo, além de estruturar uns guias de estudo pra esses temas, desde base de estrutura de dados até arquitetura e programação em GPU
se vc parar para pensar essas outras linguagens tb não retornam mais de um valor, elas retornam tipos, por exemplo o python quando retorna mais de um valor ele usa o tipo tupla que traduzindo para o C seria um void pointer
Parabéns pelo canal e pelo video!! Nem uma linguagem ganha do C em desempenho principalmente se tratando de micro-controladores, quando vc esta escovando bits. Muitas vezes o seu desempenho chega a ser similar ao do assembly. Algumas vezes uso o assembly pelo motivo de clareza, como fazer a declaração da tabela de vetores de interrupção do ARM Cortex onde, fica mais claro fazer em assembly do que no próprio C. Algumas coisinhas escritas em C: Kernel do Linux, os principais RTOS do mercado, drivers do linux e windows e até mesmo banco de dados como o Firebird (primeiras versões) o Firebird tina uma velocidade assustadora!
Mt obrigado! Eu usei assembly do ARM pra mesma coisa, famoso NVIC kkkkkk rotinas de busy wait também lembro de serem em assembly. Acho mt interessante as otimizações que o ARM faz pra diminuir o número de clocks em algumas chamadas. Qnd tem várias interrupções aninhadas, pra diminuir o tempo de troca de contexto entre elas é mt interessante. Quem sabe não faço vídeo sobre isso hahahaha
Retorno de struct é feito implicitamente por ponteiro, é adicionado um parâmetro na função como ponteiro pra struct e esse ponteiro é modificado pela função, funcionando como "retorno"
Eu não entendi sua questão, pq a função no c consegue retornar multiplos valores na forma de listas. Não conheço nenhuma linguagem que tenha uma função que capaz de retormar multiplos valores sem ser dentro de uma estrutura. Mesmo a matemática ou modelos computacionais, que são mais abstratas esse tipo de prática não acontece. Portanto a pergunta que eu faço a você é, oque significa (ou em que sentido) você usa "multiplos valores"?
@@Ziviani é isso aí mesmo. De qualquer maneira, é só um artifício pra mostrar como C replica a estrutura de retorno de boa parte dos assemblies, que tmb tem essa limitação.
Isso é uma meia verdade. É possível sim a linguagem C retornar mais de um valor. Basta encapsular o que se quer retornar em uma struct. As structs, por definição podem encapsular mais de um tipo de dado, incluindo outras strucs. Então, sim, é possível retornar diversos valores. Basta encaixotar em uma struct. Inclusive se faz isso toda hora!
Retorno de struct em C é na verdade um "sintatic sugar" pra passar como primeiro parâmetro da função um ponteiro pra struct e a função modificar a struct desse ponteiro. Ou seja, a função não retorna struct de fato, mas modifica um parâmetro passado pra ela como ponteiro.
@@edkallenn entendi hahahaha que bom que os compiladores escondem essas coisas da gnt msm, só descobre esse tipo de coisa depois que vamos ver como funciona de C pra assembly. E valeu pelos parabéns, cara! Ver esse tipo de comentário motiva mt a continuar produzindo
Eu ouvi q linguagens q permitem retorno múltiplo, o compilador vai tentar otimizar, aí como seria q elas fazem? Ela colocaria para alocar memória da heap e retornar o ponteiro com os valores? Nesse caso acho q seria menos performático porque vai ter que acessar a memória RAM ou os cache da vida. Aí quando essas outras linguagens retornam um valor só, a conversão vai para a versão pelo registrador igual ao C, causando ganha de performance, mas acho q retornar um valor do registrador ou um ponteiro do registrador não é a parte q dá diferença, mas sim quando for acessado o conteúdo, onde um está num registrador e outro está em outra memória. Algm já ouviu algo a respeito?
Essa questão de linguagem é muito específico não só da linguagem, mas também do compilador/runtime dela e da arquitetura utilizada. Mesmo pra C, em x86 o retorno e passagem de argumentos é feito por pilha, já em ARM é feito em registradores por padrão. Então tem que pegar cada caso específico e ver como fazer
Quase, é que internamente o compilador coloca um ponteiro pra struct como primeiro parâmetro e daí na função de cima cria espaço pra essa struct e passa o ponteiro dela pra função. Aí na verdade a função não retorna nada, só modifica o ponteiro pra struct que foi injetado ali
@@waine_jr Foi uma pergunta retórica. Sou professor de Compiladores da UERJ e UFRJ. Se retornar a struct "por valor", os seus atributos são passados via pilha, como múltiplas variáveis.
Java não da para retornar mais de um valor, o que se faz é retornar um objeto ou um array. As decisões de C são só denostram as limitações da época mas também o quanto ele pode render em desempenho ! Usar registradores é muito mais rapido que fazer operações de RAM.
Irmão, o C retorna struct. Q viagem é essa? A decisão de onde vai armazenar os valores do retorno da função é a nível de compilador e não de linguagem.
Eu sou muito critico de linguagens que querem ter o máximo de features possíveis, gosto de minimalismo e acredito que isso melhora o workflow. Depois de 2 anos numa empresa usando C++ eu ainda hoje prefiro fazer projetos pessoais todos em C, mesmo quando eu sei que posso usar C++.
Aí depende. Numa empresa, em geral, o custo maior é no desenvolvimento. Ter uma plataforma de desenvolvimento (a qual não é somente uma linguagem, mas um conjunto de ferramentas e bibliotecas de apoio ao desenvolvimento) minimiza o tempo e os esforços em programação, portanto, vale muito a pena. Pra projetos pessoais pequenos, notadamente não faz muita diferença.
@@andredcavalcante Baseado não só na minha experiência, mas pesquisas e até em livros de engenharia de software como o do Ian Summerville, o maior custo financeiro e de tempo dos desenvolvedores sempre vai ser na manutenção do software e não no desenvolvimento. Onde eu trabalho agente tem muitas ferramentas para gerenciar, testar, debugar e manter o código. Existem muitas features novas, mas ao mesmo tempo existe tanto quanto bugs e melhorias tanto das features quanto das ferramentas de trabalho em si. Isso aconteceu em todas as empresas que passei. As vezes você leva duas semanas para configurar um CI de test automatizado e mais algumas outras semanas para implementar os testes e fazer rodar no CI, enquanto que feature nova costuma levar bem menos tempo. Na verdade o que consome o tempo da feature nova é o processo de integrar ela no projeto já existente. E eu realmente acredito que uma linguagem mais complicada faz com que agente tenha uma carga de debug e teste que talvez nem fosse necessário.
cara muito massa esse conteúdo! Gostei demais e me inscrevi gostaria de saber onde posso assistir outros canais que falam desse assunto grosso da Ciência da Computção... sei que tem e recomendo muito o @Computerphile fica a dica pra quem tbm ta procurando algo
Que massa que curtiu mano! No BR não conheço mts canais sobre baixo nível, conheço o Augusto Galego e o Pedro Pessoa, o Akita imagino que tenha alguns vídeos sobre. Fora tem o Low Level Learning que fala sobre baixo nível voltado pra segurança, Ben Eater fala mt sobre protocolos e área de embarcados (que é baixo nível por definição), LaurieWired fala sobre segurança e entra na questão de baixo nível tmb, Molly Rocket fala de tudo um pouco, recomendo demais, Simon Dev fala de computação gráfica e as vezes traz relações com baixo nível. Mas o pessoal de baixo nível é mt em fórum e canal de discord pelo que vejo
No. "C" não retorna nada por registrador ou stack ou o que quer que seja. Isso depende da implementação, isto é, do compilador. Aliás o normal é você definir um padrão de retorno na própria pilha.
C *define* o valor de retorno sendo "uma única coisa" porque, originalmente, a ideia é que a função retornasse um código de erro ou ok (portanto um simples int). A ideia era fazer um tratamento de erros simplificado. Quando C foi criada não existia a ideia de objetos (até existia, mas era simplesmente impraticável a época e não dava para ter coisas como exceptions ou traps). O retorno propriamente falando das funções seria via "parâmetros de saída", ou seja, via parâmetros por referência (via apontadores).
Mas isso foi rapidamente evoluído. Dá pra retornar structs. Com structs e um conjunto de macros você retorna o que quiser hoje, até mesmo tuplas.
O rapaz do vídeo me parece bem bacana e tenta falar de forma simplificada. Mas aí é que pega. C não é nem simples, nem baixo nível como a galera vende. Os níveis de abstração de C são altos (e dá pra desenvolver outro ainda mais altos). O que C não tem, *por desenho* é um monte de bibliotecas e algoritmos prontos, justamente porque a linguagem foi concebida para ser compilada para uma plataforma Von Neuman genérica e que não tivesse "nada", nem SO, nenhum tipo de runtime, "nada" mesmo. Aliás, C foi concebida para se desenvolver o Unix, isto é, um SO.
(EDITADA para consertar errinhos ortográficos)
Exatamente, além disso quando C foi concebido a base das arquiteturas de era X86, que não trabalha com registradores da maneira apontada no vídeo.
@@gabrielrosapaz3069 Também não. A arquitetura x86 foi concebida somente em 1978, para equipar os processadores 8088 e 8086, que equiparam os primeiros PCs de 1980 em diante. A linguagem C foi concebida, a partir da B, em 1968, sendo a sua primeira "versão" efetiva a de 1972, a de K&R. Em 1980 já havia a versão "padrão" de C, a versão ANSI. C foi concebida para implementar o Unix, mas ser uma linguagem de alto nível. Portanto a visão dos projetistas era de sistemas tipo main ou mid frames, não PCs, que viriam a se tornar populares uns 10 anos depois. Portanto, C tem pouco ou nada a ver com a arquitetura x86. A própria teoria dos compiladores modernos foi desenvolvida somente no final da década de 70 e início da década 80, notadamente graças aos esforços da Universidade de Illinois (Campus de Urbana) que resultou no LLVM e, posteriormente, no CLang. Todas as demais linguagens já se beneficiaram desses esforços. Aliás, já foram construídas já se pensando em se ter um compilador tipo LLVM em mente (ex.: C++). Com C (puro) não!, se bem que a LLVM foi pensada principalmente para otimizar o C para as arquiteturas de hardware mais modernas. Caraca, tô ficando velho, porque cheguei a ver o nascimento de C++ e a participar da evolução do C ainda na década de 80!
@@gabrielrosapaz3069 o 8080 que é anterior aos x86 já tinha 6 registradores e 1 acumulador (q não deixa de ser um registrador)
@@andredcavalcante Obrigado pelas informações, uma verdadeira aula, show!
Não depende da implementação exatamente. Como o autor mostrou, mais no final, depende muito mais da ABI. Claro, se você estiver escrevendo um compilador que vai ser chamado pela sua própria libc ou pro seu próprio sistema operacional, você pode fazer como quiser. Caso contrário, quem gera código tem que seguir a ABI.
Bem legal ter alguém falando sobre baixo nível em português, continua com os vídeos!
Opa, curti bastante o vídeo. Parabéns!
Uma indicação de material introdutório pra quem quiser é o livro Programação em Baixo Nível do Igor Zhirkov. Ele trata sobre assembly pra arq. x86-64, um basicão sobre arquitetura de computadores, processos realizados entre o C e assembly e um pouco mais. Logo no início você percebe o pq de não existir mais de um retorno pra funções em C.
Fico feliz que curtiu o vídeo, Gustavo! E mt massa recomendação, vou procurar e baixar aqui pra ler. Essa área de baixo nível acho super interessante, o que mais vi foi de CPU, mas quero tmb dar uma estudada mais a fundo em como as GPUs funcionam. Inclusive devo fazer um vídeo sobre modelo de programação em GPU e ir aprofundando o tema
Vim pelo insta! Canal mt promissor!
excelente vídeo!
4:30 A cara de quem percebeu o que desenhou. Lá ele
Muito bom o vídeo, mais um inscrito!
kkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkk na hora eu vi tbm da n
Man do céu, ainda bem que não foi só eu! kkkkkkkkkk
C atua mais diretamente com a memória, portanto esse "um valor" pode ser um PONTEIRO (endereço de memória) que aponta para uma estrutura de informação mais complexa. Quando vc retorna um objeto em linguagens mais novas, no final das contas vc está retornando uma "ponteiro" para aquela instância.
Importante que essa estrutura tem que ser criada na stack acima ou no heap, caso contrário vai ser destruída ao final da função e vamos ficar com um ponteiro inválido. Inclusive é assim que se retorna structs, na função é injetado como primeiro parâmetro um ponteiro pra struct, essa struct é criada na função acima, e então a função chamada modifica o valor apontado, assim "retornando" a struct.
Conteúdo do vídeo tá bem legal, não sabia que o retorno é feito por registradores. Mas uma crítica construtiva: acho que dá pra tu melhorar um pouco a apresentação e ser mais direto
Da para voce retornar varias coisas como arrays, ponteiros, numeros, structs ou ate mesmo funções
isso, o único jeito de fazer o retorno de multiplos valores seria vocês mesmo implementando uma tupla por meio de struct (igual python, js, e outras linguas com gc fazem), ou passa todos os paramentros como referência e escreve pra eles os valores de retorno e quando forem ler eles na função acima eles vão ter os valores modificados.
Tudo isso é ponteiro ou um único registrador. Única exceção é struct, que C implicitamente coloca um primeiro parâmetro de entrada como ponteiro pra struct e na função e seta o valor desse ponteiro. Então todos esses exemplos continuam retornando apenas um valor
Motivo:pq c é bom.
php tbm
bom ate algum fdp definir false = true usando macros KKKKKKKK
Hahahah php? @@glxckada
Mestre demais 🔥
Quem me dera hahahaha
Engraçado que só pelo nível de conhecimento e os assuntos tocados eu já desconfiava que tu cursou eng em computação, ai eu fui entrar no teu site e acertei kkkkkkkkkkkkkkkkkk
Em C, uma função por padrão não pode retornar mais de um valor diretamente. No entanto, existem algumas técnicas que você pode usar para obter um efeito semelhante. Aqui estão duas abordagens comuns:
1. **Usar Ponteiros**: Você pode passar argumentos para a função por referência usando ponteiros. A função pode então modificar os valores nos endereços apontados pelos ponteiros.
#include
void retornaDoisValores(int *a, int *b) {
*a = 5; // Define o primeiro valor
*b = 10; // Define o segundo valor
}
int main() {
int valor1, valor2;
retornaDoisValores(&valor1, &valor2);
printf("Valor1: %d
Valor2: %d
", valor1, valor2);
return 0;
}
2. **Usar Estruturas**: Você pode definir uma estrutura para armazenar vários valores e retornar uma instância dessa estrutura.
#include
typedef struct {
int valor1;
int valor2;
} ValoresRetorno;
ValoresRetorno retornaDoisValores() {
ValoresRetorno valores;
valores.valor1 = 5;
valores.valor2 = 10;
return valores;
}
int main() {
ValoresRetorno resultado = retornaDoisValores();
printf("Valor1: %d
Valor2: %d
", resultado.valor1, resultado.valor2);
return 0;
}
Ambas as abordagens permitem que você "retorne" mais de um valor de uma função em C. A escolha entre usar ponteiros ou estruturas depende do contexto específico e das necessidades do problema a ser resolvido.
Também pode retornar um endereço de memória ou seja um ponteiro
No fim das contas o próprio endereço de memória caba sendo um número inteiro...
Obrigado pelo conteúdo, parabéns.
será que existe alguma arquitetura que dispensa stackframes ? seria interessantíssimo, evitando ataques como heap e buffer overflow
Boa pergunta, não conheço não. Talvez FPGAs ou coprocessadores especializados. Mas o conceito de stackframe é mt poderoso pra rodar e fazer programas, nem se imagino como seria programar sem isso
Mas acredito que as linguagens de alto nivel tb voltam apenas um valor no retorno de suas funções, isso por baixo dos panos. Baseado na orquestraçào das mudanças dos contextos. Por exemplo: Em C# quando retornamos instâncias de objetos complexos (classes, listas, arrays etc), é retornado apenas o endereço da instância do objeto, ou seja apenas um valor. Esse aprimoramento que C não cuida, bem como vc disse, devido ao seu legado histórico.
po, no meu jeito de ver, na verdade, eu acho que linguagens de alto nível resolvem esse problema na verdade retornando uma lista de elementos, ou seja, um estrutura de lista com cada elemento que eu queria retornar é criada, e a função a nível de assembly guarda o endereço no registrador de retorno, e depois quem recebe esses valores, a linguagem sabe recuperar o endereço dessa lista e manipular ela de forma a resgatar cada endereço para guardar em cada variável, a nível de assembly a função continua retornando somente uma coisa, mas essa coisa é um endereço de memoria, e em C "não conseguimos" retornar mais de uma coisa por que a linguagem C por si só bota mais coisas na mão do programador para ser feito, claro, se assim ele quiser né, retornar mais de um dado por uma função
só corrigindo uma formalismo técnico, C também é alto nível, quando usei "linguagens de alto nivel", quis referenciar a linguagens que tem mais abstrações como nao precisar manipular memoria diretamente, oferecer métodos padrões ja implementados em todos os objetos que podem somente ser usados (sobrescrita de metodo de OOP), etc
Se a linguagem tem GC, reference count, ou gerenciamento automático, pode retornar de qualquer modo os valores, alocando até no heap mesmo (como consigo retornar um vetor de uma função? Só usando heap). Também as estruturas de retorno não são limitadas por um valor por design da linguagem, aí como cada linguagem faz vai depender de cada uma. Você pode inclusive nem retornar nada, só mexer em valores na "stack" interna da linguagem, adicionando ou removendo valores, etc. ou pode fazer como você disse, retornar uma lista de valores. Mas aí fica a pergunta: por que só uma lista? Por que não um dicionário? Por que não um set? Por que não um objeto genérico da linguagem? etc.
Pra linguagens que precisam de um gereciamento manual de memória, é feita alguma magia por baixo dos panos pra fazer isso, que é passar uma referência como parâmetro pra função para que então seja utilizada internamente na função (esse post explica sobre isso stackoverflow.com/questions/39068492/c-c-returning-struct-by-value-under-the-hood)
Então esse problema só é relevante em C/C++/semelhantes com relação a memória e essa limitação. Pra linguagens tipo Go, Java, Python, JavaScript, é só criar um novo objeto e retornar a referência que depois o GC cuida dele, além de terem uma estrutura/sintaxe de retorno que não é limitada por um valor, como é em C. A parte de assembly já fica bem distante dessas linguagens, é até difícil comparar.
Se você usar void você retorna ponteiros. Você retorna até um universo dessa forma. Mas aloca antes para ver se tem espaço. 😂
Tecnicamente, todas as linguagens só podem retornar um valor.
Tecnicamente, todas linguagens são uma máquina de Turing redutíveis uma a outra
parabens irmao q tenha muito sucesso pela frente baita canal
Muito obrigado mano! Esse ano quero trazer mt conteúdo pra vcs
Vídeo bolado cara, você é brabo
Parabéns pelo conteúdo, sempre dei falta de baixo nivel em BR.
Motivo: porque C não esconde a existência de ponteiros.
Você pode retornar um ponteiro pra uma struct qualquer e se bobear até um void* e depois tratar esse cara como algo mais dinâmico
Exatamente.
Muito bom o vídeo. Gostaria de saber sobre materiais para aprofundamento, até suas fontes de estudo, por exemplo.
Que massa que curtiu, Wesley! Eu compartilho bastante no Instagram umas fontes, mas também vou começar a fazer por aqui esse tipo de conteúdo, além de estruturar uns guias de estudo pra esses temas, desde base de estrutura de dados até arquitetura e programação em GPU
se vc parar para pensar essas outras linguagens tb não retornam mais de um valor, elas retornam tipos, por exemplo o python quando retorna mais de um valor ele usa o tipo tupla que traduzindo para o C seria um void pointer
9:42. Cara, somos loucos então.
Parabéns pelo canal e pelo video!! Nem uma linguagem ganha do C em desempenho principalmente se tratando de micro-controladores, quando vc esta escovando bits. Muitas vezes o seu desempenho chega a ser similar ao do assembly. Algumas vezes uso o assembly pelo motivo de clareza, como fazer a declaração da tabela de vetores de interrupção do ARM Cortex onde, fica mais claro fazer em assembly do que no próprio C. Algumas coisinhas escritas em C: Kernel do Linux, os principais RTOS do mercado, drivers do linux e windows e até mesmo banco de dados como o Firebird (primeiras versões) o Firebird tina uma velocidade assustadora!
Mt obrigado! Eu usei assembly do ARM pra mesma coisa, famoso NVIC kkkkkk rotinas de busy wait também lembro de serem em assembly. Acho mt interessante as otimizações que o ARM faz pra diminuir o número de clocks em algumas chamadas. Qnd tem várias interrupções aninhadas, pra diminuir o tempo de troca de contexto entre elas é mt interessante. Quem sabe não faço vídeo sobre isso hahahaha
Conteúdo bom de mais!
Você pode retornar uma estrutura... Ou melhor! Você pode retornar um ponteiro vazio! *void 🤩
em c eu so trabalho com ponteiros em funções. Ai da pra "retornar" varias coisas
Retorno de struct é feito implicitamente por ponteiro, é adicionado um parâmetro na função como ponteiro pra struct e esse ponteiro é modificado pela função, funcionando como "retorno"
Eu não entendi sua questão, pq a função no c consegue retornar multiplos valores na forma de listas.
Não conheço nenhuma linguagem que tenha uma função que capaz de retormar multiplos valores sem ser dentro de uma estrutura. Mesmo a matemática ou modelos computacionais, que são mais abstratas esse tipo de prática não acontece.
Portanto a pergunta que eu faço a você é, oque significa (ou em que sentido) você usa "multiplos valores"?
Pelo que entendi, é no sentido da falta de uma estrutura como hash maps ou tuples em C.
@@Ziviani é isso aí mesmo. De qualquer maneira, é só um artifício pra mostrar como C replica a estrutura de retorno de boa parte dos assemblies, que tmb tem essa limitação.
Isso é uma meia verdade. É possível sim a linguagem C retornar mais de um valor. Basta encapsular o que se quer retornar em uma struct. As structs, por definição podem encapsular mais de um tipo de dado, incluindo outras strucs. Então, sim, é possível retornar diversos valores. Basta encaixotar em uma struct. Inclusive se faz isso toda hora!
Retorno de struct em C é na verdade um "sintatic sugar" pra passar como primeiro parâmetro da função um ponteiro pra struct e a função modificar a struct desse ponteiro. Ou seja, a função não retorna struct de fato, mas modifica um parâmetro passado pra ela como ponteiro.
@@waine_jr Sim, você tem razão. Mas minha resposta é mais na "solução" do problema, entende?
@@waine_jr By the way, PARABÉNS pelo vídeo.
Eu sei como deve dar trabalho fazer um vídeo desses!
@@edkallenn entendi hahahaha que bom que os compiladores escondem essas coisas da gnt msm, só descobre esse tipo de coisa depois que vamos ver como funciona de C pra assembly. E valeu pelos parabéns, cara! Ver esse tipo de comentário motiva mt a continuar produzindo
Eu ouvi q linguagens q permitem retorno múltiplo, o compilador vai tentar otimizar, aí como seria q elas fazem? Ela colocaria para alocar memória da heap e retornar o ponteiro com os valores? Nesse caso acho q seria menos performático porque vai ter que acessar a memória RAM ou os cache da vida. Aí quando essas outras linguagens retornam um valor só, a conversão vai para a versão pelo registrador igual ao C, causando ganha de performance, mas acho q retornar um valor do registrador ou um ponteiro do registrador não é a parte q dá diferença, mas sim quando for acessado o conteúdo, onde um está num registrador e outro está em outra memória. Algm já ouviu algo a respeito?
Essa questão de linguagem é muito específico não só da linguagem, mas também do compilador/runtime dela e da arquitetura utilizada. Mesmo pra C, em x86 o retorno e passagem de argumentos é feito por pilha, já em ARM é feito em registradores por padrão. Então tem que pegar cada caso específico e ver como fazer
Pode retornar uma struct, isso seria "só um valor"?!
Quase, é que internamente o compilador coloca um ponteiro pra struct como primeiro parâmetro e daí na função de cima cria espaço pra essa struct e passa o ponteiro dela pra função. Aí na verdade a função não retorna nada, só modifica o ponteiro pra struct que foi injetado ali
@@waine_jr Foi uma pergunta retórica. Sou professor de Compiladores da UERJ e UFRJ. Se retornar a struct "por valor", os seus atributos são passados via pilha, como múltiplas variáveis.
Java não da para retornar mais de um valor, o que se faz é retornar um objeto ou um array. As decisões de C são só denostram as limitações da época mas também o quanto ele pode render em desempenho ! Usar registradores é muito mais rapido que fazer operações de RAM.
Novo inscrito, belo vídeo
Ótimo vídeo, gostei muit
Muito obrigado!
Ótimo vídeo
0:02 Por que pode retornar um ponteiro pra uma estrutura com todo um outro universo dentro dela, se for necessário.
Ponteiro do ponteiro do ponteiro do ponteiro. 😂
Kkkkkkkkkkkk fundamentos de programação é tipo isso os exercícios
@@waine_jr Eu já vi na natureza até três *.
Ué, mas não é só retornar um array com n valores? Se os valores tiverem que ser diferentes, é só implementar um array dinâmico. 😦
Ponteiro
Irmão, o C retorna struct. Q viagem é essa? A decisão de onde vai armazenar os valores do retorno da função é a nível de compilador e não de linguagem.
Em c++ dá pra retornar mais de um valor ???😮
tem o std::pair e std::tuple por exemplo, imagino que ele esteja falando disso.
"Salvar tudo lá trás..." Lá ele programador... 11:57
Kkkkkkkkkkkkkkkkk
Waine, qual faculdade tu fez?
Fiz eng comp na utfpr-CT
canal top!
Valeu meu mano! Essa semana n sei se vou conseguir postar, mas semana que vem volto 100%
Na verdade é de nível intermediário.
Eu sou muito critico de linguagens que querem ter o máximo de features possíveis, gosto de minimalismo e acredito que isso melhora o workflow. Depois de 2 anos numa empresa usando C++ eu ainda hoje prefiro fazer projetos pessoais todos em C, mesmo quando eu sei que posso usar C++.
Aí depende. Numa empresa, em geral, o custo maior é no desenvolvimento. Ter uma plataforma de desenvolvimento (a qual não é somente uma linguagem, mas um conjunto de ferramentas e bibliotecas de apoio ao desenvolvimento) minimiza o tempo e os esforços em programação, portanto, vale muito a pena. Pra projetos pessoais pequenos, notadamente não faz muita diferença.
@@andredcavalcante Baseado não só na minha experiência, mas pesquisas e até em livros de engenharia de software como o do Ian Summerville, o maior custo financeiro e de tempo dos desenvolvedores sempre vai ser na manutenção do software e não no desenvolvimento. Onde eu trabalho agente tem muitas ferramentas para gerenciar, testar, debugar e manter o código. Existem muitas features novas, mas ao mesmo tempo existe tanto quanto bugs e melhorias tanto das features quanto das ferramentas de trabalho em si. Isso aconteceu em todas as empresas que passei. As vezes você leva duas semanas para configurar um CI de test automatizado e mais algumas outras semanas para implementar os testes e fazer rodar no CI, enquanto que feature nova costuma levar bem menos tempo. Na verdade o que consome o tempo da feature nova é o processo de integrar ela no projeto já existente. E eu realmente acredito que uma linguagem mais complicada faz com que agente tenha uma carga de debug e teste que talvez nem fosse necessário.
Vixi esta um maio breu
cara muito massa esse conteúdo! Gostei demais e me inscrevi
gostaria de saber onde posso assistir outros canais que falam desse assunto grosso da Ciência da Computção... sei que tem e recomendo muito o @Computerphile fica a dica pra quem tbm ta procurando algo
Que massa que curtiu mano! No BR não conheço mts canais sobre baixo nível, conheço o Augusto Galego e o Pedro Pessoa, o Akita imagino que tenha alguns vídeos sobre. Fora tem o Low Level Learning que fala sobre baixo nível voltado pra segurança, Ben Eater fala mt sobre protocolos e área de embarcados (que é baixo nível por definição), LaurieWired fala sobre segurança e entra na questão de baixo nível tmb, Molly Rocket fala de tudo um pouco, recomendo demais, Simon Dev fala de computação gráfica e as vezes traz relações com baixo nível.
Mas o pessoal de baixo nível é mt em fórum e canal de discord pelo que vejo