C++ é dificil de aprender. ?

[Thiago Adams]

Eu sempre defendo C++ e  vou continuar defendendo.

No entanto, uma das coisas que não nego é que é uma linguagem difícil de aprender e cheia de detalhes.

Vou colocar um exemplo aqui que não compila, eu sei o motivo, mas vou colocar apenas como exemplo das dificuldades que um iniciante passa.

#include <memory>
#include <vector>

class Shape
{
public:
  virtual void draw() = 0;
}; 

class Box : public Shape
{
  virtual void draw() {}
};

class Circle : public Shape
{
  virtual void draw() {}
};

 

int main()
{

  std::vector<std::unique_ptr<Shape>> v;
  v.push_back(std::make_unique<Box>());
  v.push_back(std::make_unique<Circle>());

  for (auto i : v)  {
    i->draw();
  }
  return 0;
}

[Thiago Adams]

Outro exemplo bom é trocar de unique_ptr para shared_ptr.

[Francisco Lopes]

short fix: for(auto &&i : v)

IMO, o range loop que faz copia não funcionar é bom sinal não é? Mesmo para iniciantes. Em qualquer linguagem

(é o tipo de coisa que acontece em Rust também), se ele quer usar unique-ownership, ele tem que arcar com isso

e entender as conseqüências.

Uma proposta de syntatic-sugar que vem ao caso é N3853: Range-Based For-Loops: The Next Generation—Stephan T. Lavavej,

onde for (i : v) já implica auto && pra i.

    i->draw();
  }
  return 0;
}

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~------------------------------
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~------------

[Rodrigo Delduca]

Um assunto semelhante a este foi levantando na lista Python-Brasil
quando defendi que C++ estava ficando parecido com Python.

1 - https://groups.google.com/d/msg/python-brasil/u2a1zjaCrfU/L6aagsQYSAwJ


--
http://www.nullonerror.org/
@skhaz

On Thu, Dec 11, 2014 at 2:38 PM, Thiago Adams <thiago...@gmail.com> wrote:
> Outro exemplo bom é trocar de unique_ptr para shared_ptr.
>

[rafae...@gmail.com]

C++ é difícil, só que não.

https://www.youtube.com/watch?v=jK1_3RbEwLE&list=PL09Ke5-ligfmlkBZRHA3HbEQSU2LanWti

Viver nos cantos obscuros do C++ e fazendo designs ruins, isso deve ser difícil pra baralho mesmo.

Att,
Rafael Soares.

[angelo]

Tive um professor de fisica, nos tempos de escola, que costumava dizer que    "dificil nao existe, dificil é o desconhecido..."

[Francisco Lopes]

On Dec 11, 2014, at 15:36, angelo <angelo...@gmail.com> wrote:

Tive um professor de fisica, nos tempos de escola, que costumava dizer que    "dificil nao existe, dificil é o desconhecido..."

Hm… essa lição aprendi no Chapolin.

[Thiago Adams]

Você começa explicando um for loop e vai parar em move semantics  && etc etc...

É tão complicado que você tem que dizer "faça assim por enquanto que um dia isso vai fazer sentido"

Apesar do C ser difícil de programar, o conjunto de regras é bem menor. (agora entrando um pouco na discussão C x C++ ) 

[angelo]

Tá aí..  isso é um ótimo assunto pra entrar na pauta da galera discutir, numa confraternização de fim de ano, tomando um choppinho

Vc sabia que não conheço ninguém em um raio de 100 km (sério) que ganhe algum $ com alguma coisa diretamente mexendo com C/C++ ?  Isso porque estou na capital do RJ.

Pior, as pessoas (por desconhecimento imagino) ou tem medo da linguagem, ou ainda acham que acabou. Ou guardam lembranças ruins ( bicho papão, coisa dificil, reprova geral [no caso de um curso, uma faculdade]).. ou seja, é só pra quem persiste e insiste.. 

O mundo ultimamente anda muito ocupado nas linguagens que se derivaram desta ou nem tanto.  Por n motivos.. ja bem discutidos aqui né?

E aí acaba que, quem resolve encarar de frente, ou ganha a vida num nicho ou fica igual cidade pequena, que todo mundo se conhece.

--

[Francisco Lopes]

Acho que a premissa está errada. For-loop é uma coisa, unique_ptr é outra, unique_ptr está totalmente atrelado

à move-semantics, ambos inexpressíveis em C. Situação que me lembra o que já ouvi falar palavra saudade quando

a ser expressada em outro idioma. Ambos, C e C++, inglês e português, são capazes de obter o mesmo resultado.

Nesse ponto vale ponderar quanto owneship semantics à la c++/rust, e outras features/convenções/paradigmas/etc,

valem o uso e aprendizado de outras linguagens.

[Thiago Adams]

Eu ganho a vida com C++. :D

E a empresa que trabalho tem dificuldade de achar gente para C/C++.

E ultimamente tenho percebido como é difícil ensinar C++. Quando dá um erro de template, mesmo que o iniciante só queria usar a STL e não fazer o seu próprio template, se não tiver uma pessoa experiente do lado simplesmente vai ficar trancado vários minutos/horas.

E tem coisas, que um assunto puxa o outro, que simplesmente e mais fácil dizer para seguir uma receita. Para qualquer pergunta, a resposta do C++ é sempre depente , pois sempre tem um modo especifico para cada caso. Isso é muito bom por um lado. Já o C, as regras são minimalistas.

--

www.thradams.com

[Thiago Adams]

Acho que a premissa está errada. For-loop é uma coisa, unique_ptr é outra, unique_ptr está totalmente atrelado

à move-semantics, ambos inexpressíveis em C

O move está presente no C sem que haja um conceito novo na linguagem. No container vector pro exemplo do C que estou fazendo, posso ter um vector de ponteiros e vou ter lá um move_back(& p ) significando que o ownership vai ser passado adiante. Mas o interessante é que os conceitos da linguagem não precisam mudar.

--

www.thradams.com

[Francisco Lopes]

On Dec 11, 2014, at 16:14, Thiago Adams <thiago...@gmail.com> wrote:

Acho que a premissa está errada. For-loop é uma coisa, unique_ptr é outra, unique_ptr está totalmente atrelado

à move-semantics, ambos inexpressíveis em C

O move está presente no C sem que haja um conceito novo na linguagem. No container vector pro exemplo do C que estou fazendo, posso ter um vector de ponteiros e vou ter lá um move_back(& p ) significando que o ownership vai ser passado adiante. Mas o interessante é que os conceitos da linguagem não precisam mudar.

Inexpressíveis da forma que são suportados em c++. É expressível, assim como "saudade" pode ser representado por "missing someone”

e padrões GoF em uma linguagem não tem implementação necessária em outras. De qualquer forma, se o alvo é move semantics,

o conceito terá que ser apreendido, seja em C++, Rust, ou C + STL rip-off.

[Canellas]

Thiago,

Mas vc trabalha na capital do Rio +- 100 km? 8)

    Rodrigo Canellas

    -----------
    Programador C++
    Fotógrafo amador
 

[Francisco Lopes]

On Dec 11, 2014, at 16:38, Francisco Lopes <obl...@gmail.com> wrote:

On Dec 11, 2014, at 16:14, Thiago Adams <thiago...@gmail.com> wrote:

Acho que a premissa está errada. For-loop é uma coisa, unique_ptr é outra, unique_ptr está totalmente atrelado

à move-semantics, ambos inexpressíveis em C

O move está presente no C sem que haja um conceito novo na linguagem. No container vector pro exemplo do C que estou fazendo, posso ter um vector de ponteiros e vou ter lá um move_back(& p ) significando que o ownership vai ser passado adiante. Mas o interessante é que os conceitos da linguagem não precisam mudar.

Inexpressíveis da forma que são suportados em c++. É expressível, assim como "saudade" pode ser representado por "missing someone”

e padrões GoF em uma linguagem não tem implementação necessária em outras. De qualquer forma, se o alvo é move semantics,

o conceito terá que ser apreendido, seja em C++, Rust, ou C + STL rip-off.

Dois pontos que acho interessante são:

- Dificuldade em corromper a proposta de ownership durante o uso. Neste ponto parece que Rust > C++ > C + C-STL.

        - Facilidade no uso. Sem opinião formada.

[Thiago Adams]

2014-12-11 17:05 GMT-02:00 Francisco Lopes <obl...@gmail.com>:

On Dec 11, 2014, at 16:38, Francisco Lopes <obl...@gmail.com> wrote:

On Dec 11, 2014, at 16:14, Thiago Adams <thiago...@gmail.com> wrote:

Acho que a premissa está errada. For-loop é uma coisa, unique_ptr é outra, unique_ptr está totalmente atrelado

à move-semantics, ambos inexpressíveis em C

O move está presente no C sem que haja um conceito novo na linguagem. No container vector pro exemplo do C que estou fazendo, posso ter um vector de ponteiros e vou ter lá um move_back(& p ) significando que o ownership vai ser passado adiante. Mas o interessante é que os conceitos da linguagem não precisam mudar.

Inexpressíveis da forma que são suportados em c++. É expressível, assim como "saudade" pode ser representado por "missing someone”

e padrões GoF em uma linguagem não tem implementação necessária em outras. De qualquer forma, se o alvo é move semantics,

o conceito terá que ser apreendido, seja em C++, Rust, ou C + STL rip-off.

Dois pontos que acho interessante são:

- Dificuldade em corromper a proposta de ownership durante o uso. Neste ponto parece que Rust > C++ > C + C-STL.

        - Facilidade no uso. Sem opinião formada.

Sobre a insegurança do C, de corromper as coisas. Depois de vários anos de C++, eu me pergunto quanto eu ganhei com detalhes do tipo protected/privated?

Isso em C, agora eu faria do seguinte modo.

Ou é uma struct opaca e este problema não existe, pois de certa forma e' tudo  private. ou ela é não opaca to tipo  "nao mexa aqui" ou é não opoca do tipo isso faz parte da interface mas é readonly. 

Isso pode parecer estranho no começo pois "quem garante?"

Em um projeto uniforme em um confeito quem garante é a rotina/padroes do programador. Quem garante que nós vamos olhar para os dois lados antes de atravessar a rua? O fato é que não tem um checklist gigante cada vez que vou atravessar a rua. É perigoso sim, mas é um conceito simples e um checkup simples também. 

[Francisco Lopes]

Sinceramente, pra mim C acabar sendo mais fácil/melhor/whatever que C++ é tão nebuloso quanto deve ser pra você. Por um lado, tem

o C++ com seu farol que te ajuda a atravessar a rua, mas que pode dar pane, ser mal usado, ignorado, etc, ou seja, suas soluções também

criam problemas, por outro tem o C que “so basta” olhar pros dois lados da rua pra atravessar, menos regras, mais responsabilidade

implícita, tanto do lado do motorista, quanto do pedestre. O fato é que, C++ mesmo com faróis, pode ter ruas com e sem faróis, e uma

desordem total disso quando não há profissionalismo, C só vai ter o problema da falta de faróis mesmo, e não há como escapar disso. Enquanto isto tem linguagens buscando um mundo onde estes soluções/problemas não existem, e você pode atravessar a rua em

segurança.

 

[rafae...@gmail.com]

Thiago,

Nossa educação no Brasil é pífia, lide com isso, não desconte no C++.

No .Net também se faz muita merda, é que o garbage colector ajuda a limpar.

Att,
Rafael Soares.

[Felipe Tonello]

Chico,

Faz alguns anos que só uso C no meu dia a dia. Vou ser sincero, estou
bem feliz assim. Reconheço que as vezes sinto falta de ter OOP
implementada na linguagem e meta programação mais completa (não apenas
pre-processing), mas de resto estou muito satisfeito. Eu ainda gosto
bastante de C++, mas sinceramente muitas vezes eu coisas acho overly
complicated para coisas que se o programador for ruim, vai cagar do
mesmo jeito.

Felipe

[Felipe Tonello]

E vou ser sincero, esse é um dos motivos que até gosto de Objective-C.
Justamente por não ir muito além do C, alias, acaba sendo tudo
compilado para C.

[Gianni]

Se me permitem atear fogo agora....

 

Eu acho que a dificuldade de se aprender C++ só reflete a dificuldade de se criar softwares complexos. Tínhamos que ter um CREA/CRM/OAP sim... e tínhamos que exigir que TODOS profissionais tivessem conceitos de ownership, thread-safety, ponteiros, cache-locality, round-trips e etc.... Não precisa usar sempre. Mas sabendo o que são, pode-se ter uma discussão sensata sobre que ferramenta usar e quando.

 

Ao invés de se criar "agora sim, uma linguagem fácil de programar que todos vão adorar e vc cria seu sistema na cloud com duas linhas e três cliques..."; deveriamos exigir que TODOS soubessem C, C++, SQL, leitura de ASM e uma, SÓ UMA, linguagem mais dinâmica média.. (Python?) e outra beeem leve (JS? Lua).... enfim, ter só um número limitado de linguagens 'aprovadas' pelo CREA...etc...

 

Resolver preguiça de programador de fazer/aprender direito com uma linguagem/framework/ferramenta nova é resolver o problema errado...

 

C++ é dificíl de aprender? OK, as inscrições p/ o curso de moda são naquela fila, ó....

 

C++ é complexo demais p/ fazer um sisteminha de cadastro na web?? Sim! Óbvio... faça em Python... não invente uma nova linguagem para fazer essa merda que python já faz fácil o suficiente...

 

 

ps: Python/Perl/Ruby/tantufas... escolha UMA.

 

[Francisco Lopes]

Bom, o importante é ser feliz né.

Na minha privacidade, com relação a C e C++, não imponho limites a não ser

nos abusos. Estou revendo OpenGL 4 e enquanto acompanho o livro feito

por um puritano C, rescrevo tudo mas pesco do C++ aquilo que me facilita

a vida de forma mais imediata (type-deduction, lambdas, libs  que tornam o código

mais breve e conciso), tudo confluindo com o uso da API OpenGL C mesmo, o que

traz pra mim algo bem mais legível que uma caralhada de protótipo e código

boilerplate, ou uma caralhada de código taxonômico típico de masturbação OOP.

Depois espero conseguir rever utilizando outra linguagem mais nada a ver, tipo elm

ou haskell…

Von Neumann fez muita coisa, bastava o binário, assembly era uma perda de tempo,

melhor exemplo que este pra demonstrar que não é preciso X ou Y pra chegar

ao produto final? É a tese básica de Church e Turing, que por sinal usaram linguagens

diferentes pra provar como linguagens diferentes são capazes de realizar as mesmas

coisas. Mas particularmente, eu prefiro que se fomente a evolução pra realização destas

coisas de forma mais segura/clara/performática, do que se estagne.

[Thiago R Adams]

Algo que sempre me trouxe conforto no c++ era pensar que no pior caso escrevo c e compilo no c++.ou seja para que c?
Agora fico um pouco preocupado com o abandono do c pela ms por ex e acho que o padrão. C++ deveria mais conectado ao c.

---

From: Francisco Lopes
Sent: ‎11/‎12/‎2014 22:00
To: ccppb...@googlegroups.com
Subject: Re: [ccppbrasil] C++ é dificil de aprender. ?

[Rodrigo Delduca]

Concordo com o Gianni.


--
http://www.nullonerror.org/
@skhaz

2014-12-11 22:14 GMT-02:00 Thiago R Adams <thiago...@gmail.com>:
> Algo que sempre me trouxe conforto no c++ era pensar que no pior caso
> escrevo c e compilo no c++.ou seja para que c?
> Agora fico um pouco preocupado com o abandono do c pela ms por ex e acho que
> o padrão. C++ deveria mais conectado ao c.
> ________________________________
> From: Francisco Lopes

> Sent: 11/12/2014 22:00

> To: ccppb...@googlegroups.com
> Subject: Re: [ccppbrasil] C++ é dificil de aprender. ?
>
> Bom, o importante é ser feliz né.
>
> Na minha privacidade, com relação a C e C++, não imponho limites a não ser
> nos abusos. Estou revendo OpenGL 4 e enquanto acompanho o livro feito
> por um puritano C, rescrevo tudo mas pesco do C++ aquilo que me facilita
> a vida de forma mais imediata (type-deduction, lambdas, libs que tornam o
> código
> mais breve e conciso), tudo confluindo com o uso da API OpenGL C mesmo, o
> que
> traz pra mim algo bem mais legível que uma caralhada de protótipo e código
> boilerplate, ou uma caralhada de código taxonômico típico de masturbação
> OOP.
> Depois espero conseguir rever utilizando outra linguagem mais nada a ver,
> tipo elm

> ou haskell...

[Francisco Lopes]

On Dec 11, 2014, at 22:14, Thiago R Adams <thiago...@gmail.com> wrote:

Algo que sempre me trouxe conforto no c++ era pensar que no pior caso escrevo c e compilo no c++.ou seja para que c?
Agora fico um pouco preocupado com o abandono do c pela ms por ex e acho que o padrão. C++ deveria mais conectado ao c.

Acho que os comitês não se batem em personalidade. A vantagem dos padrões separados é que o tempo não pára, e C também

evolui, a passos e mudanças menos drásticas que C++, mas segue mesmo assim. Vai saber o que C vai se tornar, ou pára no tempo

e provavelmente se torna obsoleto (ou pelo menos com a maioria pensando "por que não morre logo”) ou evolui adquirindo features

interessantes e um ponto de vista diferente do C++. O quê a MSFT adota ou não é apenas um ponto de vista de conveniência, não

algo que realmente importe, o tema transcende o nascimento e a morte da MSFT. É uma pena para os desenvolvedores Windows, mas

que estes saibam que há outros sistemas, outros compiladores, etc.

[Francisco Lopes]

On Dec 11, 2014, at 22:34, Francisco Lopes <obl...@gmail.com> wrote:

On Dec 11, 2014, at 22:14, Thiago R Adams <thiago...@gmail.com> wrote:

Algo que sempre me trouxe conforto no c++ era pensar que no pior caso escrevo c e compilo no c++.ou seja para que c?
Agora fico um pouco preocupado com o abandono do c pela ms por ex e acho que o padrão. C++ deveria mais conectado ao c.

Acho que os comitês não se batem em personalidade. A vantagem dos padrões separados é que o tempo não pára, e C também

evolui, a passos e mudanças menos drásticas que C++, mas segue mesmo assim. Vai saber o que C vai se tornar, ou pára no tempo

e provavelmente se torna obsoleto (ou pelo menos com a maioria pensando "por que não morre logo”) ou evolui adquirindo features

interessantes e um ponto de vista diferente do C++. O quê a MSFT adota ou não é apenas um ponto de vista de conveniência, não

algo que realmente importe, o tema transcende o nascimento e a morte da MSFT. É uma pena para os desenvolvedores Windows, mas

que estes saibam que há outros sistemas, outros compiladores, etc.

A MSFT uma hora ou outra vai dando o braço a torcer em relação a isto. É o que ela vem fazendo, meia boca, mas faz.

[Thiago R Adams]

Um dos sintomas que percebi que estava indo pro lado do C,é que eu estava dando preferencia por usar libs feitas em C do que c++.
Isso pq libs em c são  mais diretas e não querem impor um framework.
Geralmente com uma lib c vc faz wrappers em c++ mas o contrario não eh tão fácil.

Muitas libs em c são bem sucedidas como openssl, sqllite...
Agora em c++, a própria iostream parece ter como única vantagem ser padrão e muitas acabam não vingando.

---

From: Francisco Lopes
Sent: ‎11/‎12/‎2014 22:34

[Rodrigo Delduca]

> Geralmente com uma lib c vc faz wrappers em c++ mas o contrario não eh tão
> fácil.

Acho que 'e mais facil criar um wrapper de lib C++ para C do que C
para C++, vide a biblioteca zeromq para C

[Thiago R Adams]

Sobre oop, minha visão e que ela funciona como uma cola para  juntar tijolos.
Funciona, mas deve  usada de forma superficial e vai tudo fora de projeto para outro

---

From: Rodrigo Delduca
Sent: ‎11/‎12/‎2014 23:26

To: ccppb...@googlegroups.com
Subject: Re: [ccppbrasil] C++ é dificil de aprender. ?

[Francisco Lopes]

Em qualquer dos sentidos o principal é ABI => FFI => falar com outras linguagens,
algo que já é claro não ser o forte de C++ e outras, e um ponto forte do C.

[Francisco Lopes]

Eu não acho nada legal esta idéia, ainda mais na nossa cultura. E os motivos são

N.

 - Registro pra quê? Mais um sistema a ser pervertido pelo sistema.

 - Até quando este esquema seria pertinente, acompanharia a evolução, ou ficaria estagnado

   conforme o mundo anda, ainda mais na área de computação. Quem confia na ótima

   capacidade de escolha daqueles que escolheriam por nós (linguagens e ciências)?

 - Me parece que o ser humano é uma máquina de resolver as coisas com um nível a mais

   de indireção e acaba mascarando o problema, ou dando como resolvido.

Essa questão não se resolve com uma boa educação e um bom processo seletivo?

Sei lá, talvez os selecionadores é que não são competentes já que tem tanto conhecimento

em computação, mas não aplicam pra divulgar e selecionar/filtrar/ordenar/rankear seus candidatos

de forma prática e que mais agregaria à empresa. Candidato este que pode não ser o perfil de

outra empresa (me lembrei do Carmack que outro dia tweetou que sente mal do pouco que sabe

de RDBMS. Pense o Carmack nem chegando a Id, nem fazendo existir o Doom, por causa de

não ter passado no teste de SQL…).

Que criemos os sistemas eficientes de seleção nós mesmos, e não deixemos isto pra um

órgão do governo.

Uma pequena correção é que no caso do Thiago não é a adoção de algo novo (framework, linguagem, etc)

pra resolver algo de forma mais fácil, mas a situação contrária, buscar manter o antigo e gerenciar as coisas

com isto pois basta e cabe na cabeça de qualquer um, em tese.

[Lucas Klassmann]

Exatamente Francisco.

Eu comecei a escrever e parei para não inflamar a lista, eheheh, mas vamos lá :P

Eu acho que não precisamos regulamentar nada, o mercado escolhe os profissionais, as vezes mal, mas é o mercado.

Outra, eu por exemplo, participo da lista, leio e aprendo um monte com vocês, mas não trabalho diretamente com C++, 

gostaria muito, mas não é minha realidade, estudo C++ por admirar e ser a primeira linguagem que tive contato.

Ainda quero aplicar C++ em games, venho estudando especialmente para isso. E as vezes aplico com SDL.

Hoje trabalho na minha empresa com projetos de sistemas com Python e Django a noite. E durante o dia trabalho fora com C# e .NET/ASP.NET.

Eu tenho conhecimento diversificado, mas se eu precisasse tirar um "CREA" e saber C++ de cabo a rabo pra trabalhar como programador, acho que não teria lógica(:P)

Como diria as sábias palavras do Shrek, nossa área é como uma cebola, "fede?", não, é CAMADAS.

Exigir conhecimento baixo nivel pra quem desenvolve sistemas web, amigáveis e que não precisam se preocupar com altissima performance( apesar de sempre ser importante),

porque as vezes não é o que dá lucro, a performance deixa pro uWSGI e pro Nginx(que foram feitos em C e C++), mas não precisei trabalhar diretamente, estudo aos poucos para poder

me aprimorar.

Eu quando conheci C++, há uns 10 anos atrás( ta bom nunca aprendi tanto, nunca foquei, me julguem, UAhauhau) eu lia e me preocupava com baixo nivel também, lia muito sobre Assembly, C, C++. Sou apaixonado até hoje.

Tinha até preconceito com os programadores Delphi e PHP na época, AUhauHAUAH

Achava que arrastar componentes e desenvolver Web era fácil, até passar por Delphi, PHP, Java, (fui chicoteado e escravizado 1 ano no FoxPro, AUhauh), iniciei há uns 5 anos no Python(Django) e

hoje até manjo legal de frontend e fazer aquelas interfaces UX.

Depois de passar por várias fases, digo, nada é fácil, C++ é complicado?, não!, é complexo, mas desenvolver frontend meus amigos, é buxa, prefiro escovar bits :P

Resumindo, somo camadas, acho que todos deveriam passar por C++(ter um pouco de vontade, porque a juventude ta muito preguiçosa, concordo nesse ponto!), mas temos que considerar

que cada profissional tem seu valor, sabendo ou não C++, sabendo ler ASM ou não :)

Att.

--

Lucas Klassmann
Desenvolvedor de Software

Email: lucaskl...@gmail.com
Web site: http://www.lucasklassmann.com

[Alysson Bruno]

Se o Brasil criar um CREA só vai ser motivo de piada no mundo e não vai mudar o "mercado de TI", só vai dar mais emprego pra Indiano.

paz e amor (love and peace),

Alysson Bruno

===============================================
Palmas(TO)
Brasil

Blog: http://abruno.com

Twitter: http://twitter.com/alyssonbruno

Facebook: http://www.facebook.com/ProfessorAlyssonBruno

=================================================================

Meu alterego Escritor:

Leia alguns contos que escrevo, não esqueça de me dar sua opinião: http://goo.gl/Wjn4p

=================================================================

[angelo]

Não pretendo botar fogo na conversa não.. 

mas vou abrir meu e-mail com um quote que acho que tem bem a ver com a falta de esforço de muitos por achar que tem muito calculo, ou muito dificil, ou que nao tem nada a ver...

"Não se deve ir atrás de objetivos fáceis. É preciso buscar o que só pode ser alcançado por meio dos maiores esforços.” 

(Albert Einstein)

Se foi do Einstein mesmo, nao sei, nem vem ao caso.

Mas o fato é que, opinando agora, Pensei nisso também, Se o Carmack la do Dooom nao tivesse sido contrato, por nao saber sql, certamente as coisas seriam diferentes, talvez o jogo tivesse existido. Faz um sentido violento isso..

Além do sql que faz falta, quantas seleções nao fazem procurando detalhes mais gerais do tipo, se o cara se relaciona bem, sabe sorrir, planta plantinha, ser sociavel, um monte de caracteristicas pra encher linguiça que não estão ligadas a finalidade para o qual vai ser contratado. Talvez isso funcione bem na area comercial, mas area tecnica, muitos sao quietos mesmo. É perfil.

E ai quando contratam mal, e os problemas começam a surgir, e a pessoa se revela de incompetência tamanha que não tem jeito, acaba nao passando dos 90 dias... e pronto, começa tudo de novo.

Aqui do lado, numa empresa vizinha, tenho um "Carmack" de exemplo..depois se quiser, te conto essa história.  Mas seria justamente essa situação: se esse "Carmack" daqui, não fosse o dono e tivesse que procurar um emprego no mercado, para fazer o que faz hoje, certamente nao conseguiria, porque a formação dele nem na área é.. mas faz muito bem o trabalho dele, tanto que é uma empresa bem conhecida no mercado. 

 

Então assim, não importa a origem, vontade de aprender, se desenvolver, nao falo só de programar nao, tem que partir de dentro, claro.

Na cultura imediatista que temos no país hoje em dia, correr atrás, de verdade, ter iniciativa, parece estar perdendo cada vez mais espaço, o pacote pronto tem feito mais sucesso.

2014-12-12 2:28 GMT-02:00 Francisco Lopes <obl...@gmail.com>:

[Marcelo Zimbres]

Parece razoável a idéia do Gianni de exigir uma comprovação qualquer
do cara. Mas não é exatamente assim hoje? Em toda vaga pedem diploma,
certificado etc. É assim no mundo inteiro, isso isenta o recrutador de
ter que fazer todos os testes para cada candidato. Imagine quantos
testes seriam necessários para cobrir uma pequena parte de um curso de
CS por exemplo: ordenação, buscas, estruturas de dados, matemática
discreta, cálculo, arquitetura de computador etc. Seria impossível
recrutar, imaginem quantos currículos chegam para cada vaga anunciada
na stackoverflow.

Marcelo

[rafae...@gmail.com]

Bixo, no grupo de .Net o cara não sabe o que é Ajax.

Gianni tem razão em muitos pontos.

Não dá, e nisso o salário só cai e quem estudou só se ferra.

Att,
Rafael Soares.

[José]

Bixo, no grupo de .Net o cara não sabe o que é Ajax.

Eu ficaria surpreso se ele fosse programador JavaScript e não soubesse Ajax. :)

É curioso mas hoje eu programo Python e não tenho 1 linha web (instalador de sistema operacional) e anos atrás eu programei web em C. Não dá pra ditar o que a pessoa deve saber baseado na linguagem que ela usa. Claro, algumas terminologias são importantes mas não fundamentais.

Mas sobre regulamentação eu não concordo, eu acredito num processo seletivo de qualidade para os dois lados. Por exemplo: eu não mais aceito uma oferta de emprego se eu achar o processo seletivo fácil, tem que ser tecnicamente desafiador. Isso me dá alguma idéia de que encontrarei pessoas que poderão me ensinar, assim como me forçar a ser interessante para elas também.

[rafae...@gmail.com]

Então José, mas ele estava usando o “ajax” síncrono, até aí tudo bem, existem problemas com o Ajax da M$ se não puxar os arquivos certos.

Mas não saber que Ajax e síncrono não ficam na mesma frase é de matar.

Falta muito conceito, reescreve-se muito a roda, concordo com o Giovanni até a página 2, não é um problema de linguagens, é um problema de conceito.

As faculdades são fracas, e as pessoas ficam sempre com a 1º página do Google.

CREA é necessário, nosso software vive pouco, não passam de 4 anos e estou sendo bonzinho aqui. É impossível ao trocar de analista dar continuidade no sistema, pois como a maioria aqui já deve ter passado, porque está tudo errado, engessado.

Curiosamente, quando houve queda na venda de livros de programação geral, as vendas de livros de C++ cresceram.

Quanto mais se estuda, mais se quer retornar ao C++, problema que no Brasil o mercado é medíocre.

E respondendo aqueles que criticam sempre, infelizmente o comitê erra de vez em quando, mas ele acerta mais do que erra. C++14/17 trarão coisas muito boas. Errar é natural, ficar retornando ao C é andar pra trás, sem sentido!

Att,
Rafael Soares.

[Reinaldo Moreira]

Legal o tópico Thiago. Vou aproveitar o ensejo pra escrever bastante já que mencionaram CREA ali...

Sou novo no grupo. Eu sou engenheiro civil, tenho crea para exercer a profissão, mas isso não previne que haja profissionais mais baratos e menos competentes por aí fazendo muitas besteiras nas construções e projetos país afora. Discordo de quem defendeu a criação de uma entidade ou registro para programadores! Não é necessário. Basta que os empregadores parem de contratar os "mais baratos". O que quase nunca ocorre. Registros, diplomas, cursos e certificações nunca comprovarão muita coisa do mundo real.

Eu programo sozinho no meu dia a dia. Estudo/Uso c++ para projetos pessoais que não costumam sair do meu dropbox e as vezes nem da minha cabeça (tem muita coisa que rabisco e não implemento). Para automações no meu trabalho como engenheiro eu costumo lançar mão de C# e de VBA. Geralmente as facilidades disponíveis suplantam o tempo adicional que o código ficará rodando nos ambientes gerenciados. Muitas vezes levei dois ou tres dias para implementar e testar algo que resolveu meu trabalho e dos colegas rapidamente e que foi reutilizado diversas vezes. Caso fosse (tentar) fazer em c++ levaria muito mais tempo e ninguém utilizaria uma ferramenta externa ao pacote office. Se eu fosse (tentar) utilizar Win32, COM e ATL levaria muito mais tempo e talvez frustraria o plano. Não sou fluente em c++.  O conhecimento do comitê inserido na STL e na propria linguagem são muito profundos e as vezes me perco lendo os headers e indo consultar os livros para aprender mais. Tomo isso mais como uma atividade prazerosa do que como estudo ou trabalho. HOJE não me importo de ficar alguns minutos fuçando e esmiuçando certas coisas para entender melhor e experimentar. Mas isso pode frustrar um iniciante que não tenha um background anterior em informática. Eu teria me frustrado se tivesse tentado C++ antes de estudar outras coisas. É isto que afasta o c++ do mainstream.

De qualquer forma, o fato é que eu já programava muito tempo antes de ingressar na faculdade de engenharia, sempre em linguagens ditas mais fáceis (pascal, php, java, vb6, por exemplo), exatamente porque temia a dificuldade que diziam haver em asm, c e c++. Comecei com pascal, aos 9 ou 10 anos. É obvio que não sabia nada das teorias de ciencias da computação e engenharia de software e basicamente produzia códigos que apenas eu entendia (espaguete mesmo).

Desse jeito eu passei muitos anos na ignorância e na arrogância naturais de muitos dos "iniciantes". A diferença é que, antigamente (~98, 99), para aprender a programar, mesmo que mal, era necessário muito esforço e tempo (a internet era bem escassa para quem não sabia inglês, como era o meu caso, e eu tambem nao tinha dinheiro para comprar livros).

Hoje em dia existem sites em que o curioso pode programar arrastando coisas e copiando snippets de tutoriais que piscam e mostram balõezinhos (para começar é bom, tudo bem). Nada contra, mas é obvio que aparecerão mais profissionais baratos e que investiram menos no conhecimento e vão aceitar qualquer proposta ou tentar criar coisas de qualquer jeito. Quantos videos de youtube feitos por sei-la-quem para ensinar sei-la-o-que são assistidos diariamente por geek tech-wannabes que acabaram de assistir mais um episodio de big bang theory e se auto-proclamam nerds por isso?

O fato é que essa "programação mágica" e "transformadora" veiculada pela mídia e por boa parte do mercado hoje em dia está, para a maioria das aplicações corriqueiras que as pessoas irão fazer, diversas camadas acima de qualquer necessidade de conhecimento real de computabilidade, arquiteturas de computadores, complexidades de algoritmo etc. Basicamente é possivel que alguem produza código durante meses, participe de projetos sem ao menos saber a diferença entre um shellsort e um quicksort. Sem saber o que é big endian e little endian. Sem saber o que é nfa, dfa, parsing tree, lexer etc. Muitos vão programar sem saber o que é word, dword, qword, fpu.
É esse o "sentido" do Data Hiding e do Encapsulamento!

Pra existir este tipo de gente, existe todo um ecosistema de programadores mais esclarecidos produzindo ferramentas, bibliotecas, livros, cursos, ou mesmo melhorando as linguagens. A economia é assim. A maior parte da demanda por softwares corriqueiros (pequenas empresas e equipes) não requerem o poder de um código nativo escrito por um programador competente. A maior parte dos pequenos consumidores de software não irão reclamar se o programa demorar um pouco mais para processar alguns comandos ou se o site da empresa demorar um pouquinho para processar.

Não acho que uma entidade de classe resolveria qualquer problema dos códigos ruins e falta de informação das pessoas no meio técnico da informática. As pessoas passam anos utilizando Windows, Word, Excel, Outlook, AutoCAD das formas menos produtivas possíveis e não costumam se importar com isso. Quantos já viram alguém criar estilos de formatação no Word ou mesmo inserir quebras de página adequadamente? (eu nunca vi, nem meus professores de faculdade o.O) E cabeçalhos/rodapés no Excel? Cansei de ver pessoas inserindo espaços para afastar o texto da margem ou apertando a tecla enter repetidamente para jogar o texto para a outra pagina, sendo que bastava inserir uma quebra.

Infelizmente além de a educação no Brasil ser muito ruim, muitas pessoas são culturalmente desinteressadas em aprender! só querem as coisas prontas, pensar pouco, gastar o mínimo de energia etc.

Acredito que o C++ é considerado difícil porque a maioria das pessoas tentam programar sem conhecer os caminhos que a programação tomou desde os cartões perfurados de fortran até os dias atuais. Desconhecem o funcionamento do hardware e do software sobre o qual se está trabalhando. Obviamente se frustrarão quando tentarem utilizar uma ferramenta tão poderosa quanto o C++. Outro problema é que mesmo nas universidades preferem ensinar java do que c++, e nas que ensinam c++ conseguem na realidade fazer os alunos odiarem a experiência e nunca mais quererem utilizar a linguagem.


Abraços,


On Thursday, December 11, 2014 1:56:49 PM UTC-2, Thiago Adams wrote:

Eu sempre defendo C++ e  vou continuar defendendo.

No entanto, uma das coisas que não nego é que é uma linguagem difícil de aprender e cheia de detalhes.

Vou colocar um exemplo aqui que não compila, eu sei o motivo, mas vou colocar apenas como exemplo das dificuldades que um iniciante passa.

#include <memory>
#include <vector>

class Shape
{
public:
  virtual void draw() = 0;
}; 

class Box : public Shape
{
  virtual void draw() {}
};

class Circle : public Shape
{
  virtual void draw() {}
};

 

int main()
{

  std::vector<std::unique_ptr<Shape>> v;
  v.push_back(std::make_unique<Box>());
  v.push_back(std::make_unique<Circle>());

  for (auto i : v)  {
    i->draw();
  }
  return 0;
}

[angelo]

Rapaz.. eu escuto cada sandice aqui na sala... caras formados, pós graduados, etc etc...mas o besteirol de vez em quando impera.. eles nao tem culpa, na verdade nao viram ou não se dedicaram

eu nem falo nada, pra não criar polêmica. A verdade é que hoje tem muita faculdade com curriculo mal feito mesmo.. daí as sandices do dia dia.

Nos anos 80, 90 o nivel era mais alto..pelo fatos dos recursos serem mais escassos, a pessoa tinha que se virar mesmo. Eu comecei em 89, e mesmo esquema, na escola, depois n cursinhos, depois escola tecnica, depois faculdade..

que hoje, com a quantidade de informação (e a falta de filtro) somada  a falta de base educacional que vc mesmo comentou tb... o pacote pronto tem feito muito mais sucesso.

mas enfim, moral da história:  A programação ficou em camadas. Por tanta facilidade, ninguém está preocupado em saber qual o papel dos registradores de  um microprocessador, ou quantas paginas de memoria um determinado SO está lidando no momento em que o programa foi compilado entrou em execução.

[rafae...@gmail.com]

Eu sou novato em C++, nunca fiz um projeto, li a mensagem de erro no código do Thiago Adams e coloquei o & no auto.

Por que? Porque eu estudei. O compilador está me avisando que estou tentando invocar um método apagado, eu vi que estou fazendo copia, sei que com cópia é feito o “slice” (logo o compilador pensa que quero usar o Shape), então como o professor Bjarne me ensinou, polimorfismo (LSP) em C++ é feito com referência ou ponteiro.

Por que o vector Shape aceita Box e Circle? link: http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science).

E o auto& funciona baseado no Liskov Substitution Principle.

E nada disso me foi ensinado na faculdade, foi na porrada mesmo lendo muito. E não vão me pagar 1 centavo a mais por isso, e se pá perco a vaga pra um pivete porque ele faz CSS melhor que eu.

Estudar faz muita diferença, a questão é, no Brasil tem muitas faculdades lixo, compre livros.

Linguagem C++ não é difícil.

Difícil é C, difícil é fazer um projeto em C++, pelo amor isso é difícil demais… Compila isso, aquilo, chave X, chave Y, arquitetura XPTO… Assembly, offset, arena memory management!!! E vai embora.

Desculpem a sandice.

Att,
Rafael Soares.

[Marcos Roberto]

Na faculdade em que faço a C++ (na verdade um C com classes bem feijão com arroz) é passado por cima, só como ponto pra POO com Java/C#, e com isso quase todos não acreditam que com C++ da para se fazer algo bonitinho com janelinha. Quando mostrei meu sistema pra matéria de eng. de software que fazia muita interação com banco de dados, janelinhas bonitinhas customizadas com CSS (Qt seja louvado), e gráficos o pessoal ficou pensando: "mas dá para fazer isso com C++?". O simples fato deles saberem que já existe um std::list já lhes causam espanto. 

[Reinaldo Moreira]

nem vou longe, já é bastante desanimador o simples fato de em muitas universidades ainda indicarem o dev c++ (que já foi abandonado) e mingw (o antigo, 32 bits) que tbm já foi "abandonado" e hoje em dia o port de gcc mais atualizado e confiavel pra win32 é o mingw-w64 (que foi um fork do original e hoje é bem mais ativo, por exemplo ver a distro do lavavej no nuwen.net). Não compreendo porque continuam usando compilação em 32bits e não compilam em 64bits desde o começo. As incompatibilidades são apenas em niveis mais avançados de programação... Nenhum iniciante vai ter problemas compilando exemplos e experimentos com std.

Basicamente, uma simples recomendação que já melhoraria um pouco o cenário seria que recomendassem code::blocks com mingw-w64 (preferencialmente do nuwen, porque já vem com git vim e Glew/Glut se o cara se interessar por opengl, e eh só baixar e extrair, nao tem complexidade nenhuma de instalação e não contamina o OS com entradas no registro e servidores COM)... Mas não, os ""doutores"" conseguem passar 1 semestre amassando barro para ensinar mal o que muitos livros fazem muito bem ainda nos primeiros capitulos (para quem se dedique a ler e entender, por exemplo um C++ Primer ou um Programming Principles and Practice using C++). Pra aprender C puro, K&R, nada melhor do que a base: The C Programming Language. Mas as universidades continuam jogando camadas e camadas de baderna na cabeça dos iniciantes. Não usam nem C, nem C++. O iniciante fica perdido, e acaba partindo pros drag-and-drop da vida. OnClick.

Em alguns aspectos parece-me que o Brasil é uma realidade paralela. Uma matrix dentro da matrix.

O impressionante é ver que há professores por aí que continuam "ensinando" C++ à la C, usando char * arr[MAX_BUFF]; etc. Basta uma pesquisa combinando as palavras chave: "c++"+pdf+univesidade para ficar abismado. (to falando sério, façam isso)

muitos destes vão achar que é heresia afirmar que o entrypoint verdadeiro não é main(); :D e por ai vai.

pra quem tiver interesse em se juntar para tentar passar uma mensagem mais fidedigna da programação em c++ com recursos nativos no mundo moderno do c++14, favor entrar em contato, tenho trabalhado em algumas coisas relacionadas.

Viva la revolucion!
Abraço

[José]

Alguns pontos em que discordo completamente - e respeitosamente - dos amigos aqui.

1 - Se todo programador precisasse saber sobre registradores, memória virtual, etc, eu diria que o trabalho dos sistemas operacionais e linguagens de programação, nesta altura do campeonato, teria falhando miseravelmente. Não, não acredito que um engenheiro de front-end seja mais competente que outro por saber isso. Na verdade, muitos programadores de aplicativos também podem ser muito competentes sem.

2 - Uma universidade não tem que formar C++ experts. Tem que formar profissionais capazes de pesquisar e resolver problemas complexos usando as ferramentas certas. Em outras engenharias, as pessoas que usam ferramentas são de nível técnico (técnico em eletrônica, eletricista, mecânico, pedreiro, químico, etc).

3 - O mercado não vai te pagar por saber A, B ou C mas pelo que você faz com o que você sabe.

Regards,

[Thiago Adams]

Acho interessante estas discussões sobre o ensino no brasil. Quando se estuda algo, claro que o assunto se torna mais simples.
Mas o que me preocupa é a complexidade do C++ independente da questão se alguém estudou ou não.  Mesmo aquela questão inicial, se for discutida por experts vai render muita polêmica.

Existe uma diferença entre “fácil de entender e difícil de fazer” e “difícil de entender e fácil de fazer”.

Por exemplo, é fácil de entender que para tocar piano basta apertar as teclas. Porém tocar uma música é difícil.  O C me parece que segue esta linha já que possui um número pequeno de conceitos.  O livro “The C Programming Language” tem 228 páginas apenas.

Já o C++, é fácil de fazer (quando não dá erro de templates) e difícil de entender. A partir do C++11, o C++ se tornou mais fácil de usar e mais difícil de entender. Para quem já sabia C++03, era uma questão de aprender a parte nova (que é o meu caso). Já para quem está iniciando, não consigo nem imaginar como aos poucos aquele “fácil  de fazer” vai ser entendido. E diferentemente das linguagens mais alto nível, se você não souber o que está fazendo em C++ mais cedo ou mais tarde vai ter problemas. Então uma das dificuldades de se ensinar C++ atualmente parece esta, a tal ponto que é melhor dizer “faz assim por enquanto que um dia você vai entender”.

Existe uma linha, que inclusive o Stroustrup defende, que pare ensinar C++ não é preciso ensinar C antes.

Eu penso diferente. Ensina-se C e qualquer dúvida sobre como as coisas funcionam, basta recorrer aquela mais dúzia de conceitos do C. Ao meu ver também o padrão C++ deveria ser fiel ao C deixando o C como uma camada mais baixo nível do C++.

www.thradams.com

[Thiago Adams]

Outro ponto em relação a complexidade do C++ é que pode causar o efeito psicológico de alguém que sabe bem C++ achar que com isso vai estar fazendo um código melhor, somente pelo fato de estar usando templates e coisas modernas ou ter cuidado dezenas de regrinhas na elaboração da classe.

"Meu código é bom pois é moderno. Preciso de um compilador C++14" "Tudo aqui é template, super genérico."

O fato de ser moderno não implica necessariamente ser melhor. 

[José]

Mudando um pouco a questão: as pessoas tem se interessado em aprender C++?

C++ é uma linguagem complexa para dominar mas isso não é problema para quem está motivado. Mas C++ tem motivado?

A minha impressão (reddit) é que apenas o fim motiva, exemplo: quero programar jogos e C++ ainda é a melhor opção pra isso, então vamos lá...fazer o que.  Mas para quem tem opções, C++ não está interessando.

Aí o sujeito cai num trabalho de manutenção de um legado em C++ escrito há 15 anos, usando paradigma de sorvete napolitano: 1/3 OO, 1/3 estruturado, 1/3 do cara que leu Alexandrescu mas não entendeu muito bem.

[Francisco Lopes]

On Dec 23, 2014, at 16:34, José <jrzi...@gmail.com> wrote:

Mudando um pouco a questão: as pessoas tem se interessado em aprender C++?

C++ é uma linguagem complexa para dominar mas isso não é problema para quem está motivado. Mas C++ tem motivado?

A minha impressão (reddit) é que apenas o fim motiva, exemplo: quero programar jogos e C++ ainda é a melhor opção pra isso, então vamos lá...fazer o que.  Mas para quem tem opções, C++ não está interessando.

Aí o sujeito cai num trabalho de manutenção de um legado em C++ escrito há 15 anos, usando paradigma de sorvete napolitano: 1/3 OO, 1/3 estruturado, 1/3 do cara que leu Alexandrescu mas não entendeu muito bem.

Grato pelo novo conceito :-D

On Tuesday, December 23, 2014 11:01:59 AM UTC-2, Thiago Adams wrote:

Outro ponto em relação a complexidade do C++ é que pode causar o efeito psicológico de alguém que sabe bem C++ achar que com isso vai estar fazendo um código melhor, somente pelo fato de estar usando templates e coisas modernas ou ter cuidado dezenas de regrinhas na elaboração da classe.

"Meu código é bom pois é moderno. Preciso de um compilador C++14" "Tudo aqui é template, super genérico."

O fato de ser moderno não implica necessariamente ser melhor. 

[Francisco Lopes]

On Dec 23, 2014, at 16:56, Francisco Lopes <obl...@gmail.com> wrote:

On Dec 23, 2014, at 16:34, José <jrzi...@gmail.com> wrote:

Mudando um pouco a questão: as pessoas tem se interessado em aprender C++?

C++ é uma linguagem complexa para dominar mas isso não é problema para quem está motivado. Mas C++ tem motivado?

A minha impressão (reddit) é que apenas o fim motiva, exemplo: quero programar jogos e C++ ainda é a melhor opção pra isso, então vamos lá...fazer o que.  Mas para quem tem opções, C++ não está interessando.

O julgamento disto é bem controverso, veja por exemplo no GitHub com relação ao interesse nos padrões novos

de linguagens veteranas:

- C++11 no GitHub ordenado por número de estrelas

- C++14 no GitHub ordenado por número de estrelas

- Java 8 no GitHub ordenado por número de estrelas

- Python 3 (que saiu em 2008…) no GitHub ordenado por estrelas

Pelo que parece, nível de interesse normal, pelo menos da parte de desenvolvedores.

Eu creio que notícia velha não é muito a praia de HN e reddit, vejo muito mais burburinho sobre linguagens novas onde alguém

faz uma propaganda de alguma coisa que é muito foda ou fácil no novo sistema, Rust, Go, Nim, Julia, etc.

Prefiro não opinar sobre interesses corporativos/mercado.

Outra é que Reddit, HN, mercado, cultura local, formam tribos onde a forma como uma linguagem X está associada a ela pode

não corresponder a forma como ela está associada a outra, ao interesse público em geral, até mesmo a uma dada nação, etc.

[Francisco Lopes]

On Dec 23, 2014, at 17:42, Francisco Lopes <obl...@gmail.com> wrote:

On Dec 23, 2014, at 16:56, Francisco Lopes <obl...@gmail.com> wrote:

On Dec 23, 2014, at 16:34, José <jrzi...@gmail.com> wrote:

Mudando um pouco a questão: as pessoas tem se interessado em aprender C++?

C++ é uma linguagem complexa para dominar mas isso não é problema para quem está motivado. Mas C++ tem motivado?

A minha impressão (reddit) é que apenas o fim motiva, exemplo: quero programar jogos e C++ ainda é a melhor opção pra isso, então vamos lá...fazer o que.  Mas para quem tem opções, C++ não está interessando.

O julgamento disto é bem controverso, veja por exemplo no GitHub com relação ao interesse nos padrões novos

de linguagens veteranas:

- C++11 no GitHub ordenado por número de estrelas

- C++14 no GitHub ordenado por número de estrelas

Adiciona o ++ na caixa de texto ao clicar...

[adb]

Caro Reinaldo

Também sou engenheiro civil;

Também valorizo o conhecimento!

O engenheiro civil entende bem o que acontece com a simplificação...

com o fazer fácil...

com o simples e barato...

Afinal de contas, o engenheiro estuda 5-10 anos para fazer um projeto, dimensionar estruturas, planejar sistemas, e ao cobrar X por um projeto recebe um "nossa, que caro!".

Daí o cliente prefere fazer um projeto ching-ling com um "profissional" sem crea, mas com "vasta experiência" e que cobra X/5. Também economiza no material...

Tenho muitos amigos, visito muitas pessoas, vejo muitas casas, e, sinceramente, o que mais se vê é LIXO!

Casas mal feitas, mal divididas, com problemas na rede elétrica, na rede hidráulica, umidade, vazamentos, problemas estruturais, ..., e por aí vai!

É o "grande resultado" de tantas obras feitas por "profissionais" que não sabem o que estão fazendo.

Ler livros de cálculo estrutural para que? 

coloca aí 4 ferros de 1/2...

Creio que o mesmo ocorre no universo das ciências da computação.

Mas na engenharia ainda tem crea, responsabilidade civil e criminal, e mensagens de ética que são muito ressaltadas nos cursos (embora nem todos aprendam a colocar em prática...).

Nas ciências da computação as coisas estão meio confusas!

Se olhar as grades dos cursos de Engenharia da Computação, Ciências da Computação, Sistemas de Informação/Informática, vai ver que embora as 3 sejam diferentes conceitualmente, na prática existe muita confusão.

Muitos cursos tiraram disciplinas de cálculo e colocaram "coisas mais simples"...

Me estranha por exemplo, que praticamente todos os equipamentos que usamos tenham vários processadores, mas que conceitos de Processamento Paralelo não sejam vistos nem nos cursos de Ciências da Computação!!!

"É difícil...".

Eu diria que é lamentável! 

Do meu ponto de vista aprender linguagens de alto desempenho como C/C++ e processamento paralelo deveriam ser obrigatórios. Nada contra Java/Python/etc... Mas o programador tem de aprender linguagens de alto desempenho.

Para piorar, o desempenho dos alunos despencou nos últimos anos;

fruto das "aprovações automáticas" e talvez do sistema de cotas.

Muitos professores já não sabem mais o que fazer, e estão "jogando a toalha";

o que significa "simplificar,...,simplificar,....." e até "fazer de conta".

Mas alguns resistem...

--

Com relação a C++ ser difícil eu discordo;

será trabalhoso se o professo querer ensinar todos os conceitos em detalhes;

vai precisar de mais de uma disciplina para completar 90%.

Mas é possível ensinar o básico de Orientação a Objeto e C++ em uma disciplina de 4 créditos.

O requisito - de toda disciplina que envolve lógica -  é que o aluno tenha interesse, queira aprender, sente na frente, faça perguntas, faça os exercícios, estude em casa, leia o(s) livros de referência e se divirta programando!

Só que...

"o facebook é tão mais divertido", "o jogo XXX é tão mais empolgante"...

E está complicado concorrer!

Ao optar por linguagens mais "simples" sobra mais tempo para outras coisas, pois a linguagens já incorpora "soluções prontas". Não interessa o fato de que o programador perde o controle, não sabe exatamente o que esta acontecendo. Vai funcionar....Mesmo que demore 2-50x mais...

Em resumo,

as pessoas - notadamente os Brasileiros,

estão preferindo a casa mal feita e cheia de problemas, mas que seja feita mais rapidamente por um custo inferior. As mobílias e equipamentos também são "de menor curso e qualidade",

do tipo que se troca com frequência. Mas é a preferência nacional...

Não precisa ser gênio para ver que esta mentalidade de buscar a simplicidade e o baixo custo em tudo .... "vai dar merda"!

PS: concordo com a ideia de se ensinar um número menor de linguagens, mas mais a fundo. Aprender tudo de forma superficial não ajuda...

[Gabriel Bassani Ribeiro]

Eu estou no 3p de Sistema de Informação e enfio a cara em livros de C\C++. Ouvir muitas pessoas falarem o quão difícil é aprender C\C++, que o futuro são essas novas linguagens que fazem tudo para o programador. Só deixo as seguintes frases: 

"Não se deve ir atrás de objetivos fáceis. É preciso buscar o que só pode ser alcançado por meio dos maiores esforços.” 

(Albert Einstein)

Se C\C++ é difícil, então é nele que vou buscar conhecimento. Devemos buscar sempre o conhecimento naquilo que nos sustenta, e eu acredito que o C é a umas da linguagens fundamentais, se sua base não for boa, o restante pode desmoronar. As vezes o fácil custa caro.  

[Reinaldo Moreira]

realmente, é vergonhoso constatar que muitos centros de ensino não costumam se esforçar para ensinar conceitos atuais de programação concorrente e paralela. os corajosos que tentam fazê-lo acabam sendo criticados ou apedrejados pelas falácias e praticidades populares: "isso é difícil", "isso não é necessário", "tem um jeito mais fácil que alguem criou para facilitar e abstrair as complexidades", "não precisa compilar" e por aí vai.

nem vou muito longe, esses dias vi uma situação real em que um "centro de pesquisa" (de engenharia civil) gastou alguns milhares de reais em workstations dual xeon e5 com 64gb de ram e os alunos "pesquisadores" engajados orientados por pesquisadores, altamente engajados também, estavam utilizando programas sequenciais sem otimização alguma, inclusive tendo como SO o Windows 7! Nada contra o windows 7, mas para um Dual Xeon e5 com 64gb de ram é meio irônico. A situação ficou pior ao saber que havia mais três irmãos gêmeos desta maquinazinha!

opemmp, mpi, amp, opencl soavam como grego ou obra do capiroto para estes seres. Na oportunidade em que fui exposto a tal situação, me ofereci para, gratuitamente (e obviamente, para meu aprendizado e prazer), montar um cluster com archlinux e criar um dom0 no xen para disponibilizar recursos virtualizados para as pesquisas e também montar uma infra para mpi. As possibilidades eram inúmeras... Todas melhores do que um win7 rodando programas sequenciais compilados provavelmente em modo debug usando um compilador obsoleto.

infelizmente, acredito que o ego e/ou orgulho dos "dotores" pode ter sido ferido pela minha "sugestão" um tanto quanto pretenciosa e arrogante (afinal, estava externo e alheio ao "centro de ensino" para querer ditar como deveriam proceder, alem de eu não ter os titulos de mestre e doutor! ^^ talvez felizmente, né!)

isso já faz alguns meses, acredito que nada fizeram para melhorar o desempenho das pesquisas. capaz que se continua rodando métodos numéricos com técnicas de 1980 (sendo otimista). Com o diferencial de que agora é possivel enxer a boca para dizer: "temos xxx teraflops"

capaz que minha g80 (8800gtx) de 2007 com 575nucleos cuda consiga entregar alguns resultados com maior rapidez. O custo? passar alguns dias ou semanas estudando a sintaxe de Cuda e esforçando para "traduzir" os algoritmos existentes para tirar algum proveito.

Essa é a triste realidade... enquanto isso vou brincando com meu haswell mobile mesmo.

Abraços!

[Erle Carrara]

Com tudo isso só tenho que ficar feliz por ter tido uma disciplina de programação paralela onde aprendemos vários conceitos legais para pensar em algoritmos paralelos, além de poder colocar na prática usando MPI e OpenMP!

Ainda há esperança, tem faculdades boas. O problemas também está no mercado que prefere usar o que já tem pronto e funciona há anos do que tentar novas tecnologias, desenvolver algo novo.

Estou quase concluindo o curso de Análise e Desenvolvimento de Sistemas (falta algumas DP's, mas fico por feliz por ter elas, isso de alguma forma quer dizer que o curso é exigente, de 40 que entram uns 3 se formam no tempo certo).

--

Erle Carrara

[Francisco Lopes]

Gostaria de deixar isto pra leitura, apesar de estar relutante em postar pois este
tópico já mais que deu o que tinha que dar. No geral acaba havendo mais
entusiasmo em discussões de opinião do que os assuntos técnicos.

http://www.cs.utexas.edu/users/EWD/transcriptions/OtherDocs/Haskell.html

[Gianni]

...é que ninguém tem nada técnico p/ falar....

C++ é tão fácil, que ninguém tem dúvida de nada...

[Vinícius dos Santos Oliveira]

Em 20 de julho de 2017 17:35, Christiano <chris...@engineer.com> escreveu:

O fix correto seria:
for(auto &i : v)

Nao existe a possibilidade de haver "move" nesse caso particular, e se houvesse (quando ao inves de usar auto && se usasse o tipo unique_ptr<Shape> &&) seria um erro logico que levaria os dois elementos do vetor a abrigar dois nullptr's(internos aos unique_ptr), tornando qualquer tentativa, posterior ao for, de acesso aos dados-membros (ou funcoes virtuais) de objetos apontados por tais enderecos a um erro de dereferencia de ponteiros nullptr.

E os "virtual"'s em Box e Circle adicionam espaco de memoria desnecessariamente para os respectivos tipos, portanto deveriam ser removidos.

E quanto ao conteudo central da discussao, eu discordo fortemente. Nenhum iniciante nivel "for, while, if" vai usar unique_ptr. E na medida em que o estudante aprende o problema de lidar com vazamento de memoria, ele naturalmente vai reconhecer o sentido do unique_ptr e compreender que ele nao deve ser copiado pois isso levaria a um destruction+delete de uma area de memoria que ja foi destruida e deletada anteriormente (o primeiro destruction+delete iria funcionar, o segundo iria falhar), e que se ele quiser que o unique_ptr seja inteligentemente automatico para corrigir isso ele entendera que isso custara um contador inteiro adicional e que deve usar shared_ptr.

Dizer que o C++ deveria ser mais facil quando a tal complexidade nao e' nada mais do que uma descricao de uma questao fundamental e' tao absurdo quanto dizer que um livro de circuitos analogicos nao deve conter matematica diferencial. Se voce quer resolver um problema complexo voce precisa de ferramentas que representam aquela complexidade, excluir a ferramenta nao resolve o problema, assim como remover matematica diferencial e integral pode ate ajudar os que nao querem aprender matematica diferencial e integral mas nao resolve a realidade dos problemas de circuitos analogicos.

On Thursday, December 11, 2014 at 3:19:49 PM UTC-2, Уθя¡ςκ wrote:

On Dec 11, 2014, at 13:56, Thiago Adams <thiago...@gmail.com> wrote:

Eu sempre defendo C++ e  vou continuar defendendo.

No entanto, uma das coisas que não nego é que é uma linguagem difícil de aprender e cheia de detalhes.

Vou colocar um exemplo aqui que não compila, eu sei o motivo, mas vou colocar apenas como exemplo das dificuldades que um iniciante passa.

#include <memory>
#include <vector>

class Shape
{
public:
  virtual void draw() = 0;
}; 

class Box : public Shape
{
  virtual void draw() {}
};

class Circle : public Shape
{
  virtual void draw() {}
};

 

int main()
{

  std::vector<std::unique_ptr<Shape>> v;
  v.push_back(std::make_unique<Box>());
  v.push_back(std::make_unique<Circle>());

  for (auto i : v)  {

short fix: for(auto &&i : v)

IMO, o range loop que faz copia não funcionar é bom sinal não é? Mesmo para iniciantes. Em qualquer linguagem

(é o tipo de coisa que acontece em Rust também), se ele quer usar unique-ownership, ele tem que arcar com isso

e entender as conseqüências.

Uma proposta de syntatic-sugar que vem ao caso é N3853: Range-Based For-Loops: The Next Generation—Stephan T. Lavavej,

onde for (i : v) já implica auto && pra i.

    i->draw();
  }
  return 0;
}

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~------------------------------
[&] C & C++ Brasil - http://www.ccppbrasil.org/

Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~------------

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~------------------------------
[&] C & C++ Brasil - http://www.ccppbrasil.org/

Para sair dessa lista, envie um e-mail para ccppbrasil-unsubscribe@googlegroups.com

Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~------------

--

Vinícius dos Santos Oliveira

https://vinipsmaker.github.io/

[Francisco Lopes]

Usar referências rvalue não implica a ocorrência de move Cristiano. 

[Basilio_Miranda]

A grande vantagem de C sobre C++ continua sendo a ABI.

Propostas como a de Herb Sutter:

https://isocpp.org/files/papers/n4028.pdf

talvez pudessem servir de inspiração para que formássemos um grupo de trabalho (ou grupo de discussão). Contudo, neste caminho, vejo mais dificuldades do que oportunidades de chegar a um resultado muito cedo. Creio que é um caminho longo, já que C++ permite uma enorme variedade de construções.

Mas o fato é que se quero escrever um Sistema Operacional a resposta ainda é C.

Ou se quero apenas uma biblioteca que seja portável para qualquer compilador de qualquer linguagem (inclusive outros compiladores de C++), preciso criar uma interface em C.

Assim é o COM ou o CORBA por exemplo. 

Onde, o que no fundo é exportado, como interface, é uma estrutura "C" (ou extern "C", caso estejamos trabalhando em C++) cujos membros são ponteiros para funções de idênticas ou diferentes assinaturas. Internamente podemos estar usando C++. Mas é preciso que o C++ seja "escondido" (ou "empacotado") em uma interface C.

Por isso C não é apenas para micro-controladoras onde, muitas vezes, não encontramos um bom (e, se possível, sem custo) compilador C++.

A linguagem C oferece interfaces para que sistemas operacionais e *também* bibliotecas possam ser utilizados e/ou consumidos em diferentes linguagens. E, se o compilador, for capaz de "cross-compiler", melhor ainda (ao menos no caso das bibliotecas).

Por isso a proposta de Thiago Adams de criar uma nova forma de escrever em C (em uma linguagem que acrescente recursos e mecanismos de segurança de código, mas mantendo sua compatibilidade com C, e gerando código em uma ABI totalmente "C"), parece-me uma proposta digna de nota e atenção. 

É muito trabalho, no caso de C++, ter que escrever longas interfaces em "C".  Pois, afinal o que na maioria da vezes estamos programando são bibliotecas para consumo em qualquer parte. E não queremos que as interfaces de tais bibliotecas dependam de uma determinada plataforma (como é o caso do COM). 

Então temos que escrever e manter tais interfaces. Podemos criar um gerador de código para isso. 

Mas seria bem melhor que C++ oferecesse uma interface que pudéssemos consumir em aplicações C++ compiladas em um compilador diferente (mesmo que apenas na mesma plataforma, pois isto depende dos recursos do próprio compilador). Mas também consumíveis em outras linguagens.

Pois, em uma aplicação completa, constituída da integração de diferentes binários, nem sempre a melhor solução é usar uma única linguagem (e/ou um único compilador).

Para quem trabalha mais com UNIX (como é o meu caso, e o da minha equipe), isso nem sempre aparece como um problema. Mas o problema está lá. Porque novas linguagens vão surgindo.

Em Windows é ainda pior.

Pois, atualmente, interoperabilidade é uma palavra chave. Há muitas linguagens. Algumas mais adequadas do que outras para cada família de problemas. Dizer que só iremos usar C++, seja qual for o caso de uso e a área de aplicabilidade, é desconhecer a variedade de situações de sistemas complexos. Posso em certo caso preferir Java, ou Haskell, ou outra -e a cada novo ano, temos mais linguagens especializadas em uma determinada família de problemas.

E é por isso que muitas vezes o que fazemos em C++ tem que ser "empacotado" e exportado em C. 

Mesmo na proposta muito interessante (e importante) de Herb Sutter, há ainda um longo caminho para termos uma ABI uniforme (e exportável) em C++.

Truques de templates, são "jogos florais" muito interessantes. Mas eles não resolvem (e nem foram imaginados para resolver) o problema que aqui estamos tratando.

Por isso um "C" que absorvesse de modo simples certas facilidades de C++ seria muito oportuno (mas sem deixar de ser "C", com a sua ABI universal).

Basilio Miranda.

[Francisco Lopes]

On Thu, Jul 20, 2017 at 10:44:48AM -0700, Christiano wrote:
> Scott meyers classifica essa possibilidade de "&&" significar por vezes
> referencia rvalue e por outras referencia lvalue de "referencia universal".
> Meu ponto e': o caso particular "for(auto &&i : v)" significa a mesma coisa
> que "for(auto &i : v)", ou seja, a referencia universal neste caso se
> comporta como referencia lvalue. Mas os seguintes comentarios deixam a
> entender que o objetivo foi fazer um move:
>
> Você começa explicando um for loop e vai parar em move semantics && etc
> > etc...
> >
>
> For-loop é uma coisa, unique_ptr é outra, unique_ptr está totalmente
> > atreladoà move-semantics, ambos inexpressíveis em C.
>
>
> Se voce tivesse feito isso sem deducao de tipo, ou seja:
> for(unique_ptr<Shape> &&i : v)
>
> Entao isso seria um codigo que talvez funcionasse por algum acaso (uma
> deferencia de ponteiros posterior ao for para classes sem qualquer dado,
> por exemplo) e seria um erro que passaria desapercebido pelo compilador.

Repito, "Usar referências rvalue não implica a ocorrência de move".

for(unique_ptr<Shape> &&i : v)

on v é um lvalue é erro de compilação. O use de auto && em loops é mera
conveniência, por que serve pra varrer tanto rvalues quanto lvalues de
estruturas de dados.

Voltando ao contexto original da questão, cai na mesma crítica que fiz
inicialmente, se, novamente, há um erro de compilação, é bom, pois serve
para que o programador entenda o seu erro de compreensão a respeito de
move semantics.

[]

> On Thursday, July 20, 2017 at 12:58:20 PM UTC-3, Уθя¡ςκ wrote:
> >
> > Usar referências rvalue não implica a ocorrência de move Cristiano.
> >
> > Em 20 de jul de 2017 12:35, "Christiano" <chris...@engineer.com

> > <javascript:>> escreveu:

> >>> <http://isocpp.org/blog/2014/01/n3853>,

> >>> onde for (i : v) já implica auto && pra i.
> >>>
> >>> i->draw();
> >>> }
> >>> return 0;
> >>> }
> >>>
> >>>
> >>>
> >>> --
> >>> Antes de enviar um e-mail para o grupo leia:
> >>> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
> >>> --~--~---------~--~----~------------------------------
> >>> [&] C & C++ Brasil - http://www.ccppbrasil.org/
> >>> Para sair dessa lista, envie um e-mail para
> >>> ccppbrasil-...@googlegroups.com
> >>> Para mais opções, visite http://groups.google.com/group/ccppbrasil
> >>> --~--~---------~--~----~--~-~--~---~----~------------
> >>>
> >>>
> >>> --
> >> Antes de enviar um e-mail para o grupo leia:
> >> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
> >> --~--~---------~--~----~------------------------------
> >> [&] C & C++ Brasil - http://www.ccppbrasil.org/
> >> Para sair dessa lista, envie um e-mail para

> >> ccppbrasil-...@googlegroups.com <javascript:>

[Josuel Teles]

Evite o estilo Dick Vigarista de programar e não terá problemas.

> Para sair dessa lista, envie um e-mail para ccppbrasil-unsubscribe@googlegroups.com

> Para mais opções, visite http://groups.google.com/group/ccppbrasil
> --~--~---------~--~----~--~-~--~---~----~------------

--
Antes de enviar um e-mail para o grupo leia:
                     http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~------------------------------
[&] C & C++ Brasil - http://www.ccppbrasil.org/

Para sair dessa lista, envie um e-mail para ccppbrasil-unsubscribe@googlegroups.com

Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~------------

--

Atenciosamente:
Josuel Teles
Cel - 8123-1582

[Gabriel Silva Moreira]

quando começa a entrar em templates, e unique_ptr eu já bugo.

acabei parando em "C com classes"

http://psilogroup.com

Em 20 de julho de 2017 15:10, Christiano <chris...@engineer.com> escreveu:

for(unique_ptr<Shape> &&i : v)

on v é um lvalue é erro de compilação.

 

Tem razão, eu fiz o teste, nem mesmo compila:

#include <memory>
#include <vector>
#include <iostream>

using namespace std;

class Shape
{
        public:
                virtual void draw() = 0;
};

class Box : public Shape
{

        void draw() {cout << "box" << endl;}
};

class Circle : public Shape
{
        void draw() {cout << "circle" << endl;}
};

int main()
{
        std::vector<std::unique_ptr<Shape>> v;
        v.push_back(std::make_unique<Box>());
        v.push_back(std::make_unique<Circle>());

        for (std::unique_ptr<Shape> &&i : v)  {
                cout << i.get() << endl;
                i->draw();
        }
 
        return 0;
}

$ CC test250.cpp -std=c++14
test250.cpp:29:34: error: rvalue reference to type 'unique_ptr<[2 * ...]>' cannot bind to lvalue of type
      'unique_ptr<[2 * ...]>'
        for (std::unique_ptr<Shape> &&i : v)  {
                                      ^ ~
/usr/include/c++/v1/vector:606:54: note: selected 'begin' function with iterator type 'iterator' (aka
      '__wrap_iter<std::__1::unique_ptr<Shape, std::__1::default_delete<Shape> > *>')
    _LIBCPP_INLINE_VISIBILITY iterator               begin() _NOEXCEPT;
                                                     ^
1 error generated.

Para sair dessa lista, envie um e-mail para ccppbrasil-unsubscribe@googlegroups.com

[Leandro T. C. Melo]

> 2017-07-20 14:54 GMT-03:00 Francisco Lopes <obl...@gmail.com>:
>
> O use de auto && em loops é mera
> conveniência, por que serve pra varrer tanto rvalues quanto lvalues de
> estruturas de dados.

Nem sempre, Francisco. Há casos em que `auto &&' é necessário em um
loop. Exemplo:

void f()
{
std::vector<int> v;
for (auto& e : v)
e = 0;
}

O código acima está correto, sendo que todos elementos de `v' são
modificados. Se você trocar std::vector<int> por std::vector<bool>
(que pode ser especializada, para otimizar espaço), o código nem
sequer compilará. Nesse caso, precisaria usar `auto &&'.

void f()
{
std::vector<bool> v; // bool agora
//for (auto& e : v) // erro!
for (auto&& e: v) // ok
e = 0;
}

Isso acontece por causa do proxy retornado pela de-referenciação de um
elemento de std::vector<bool>, que é um lvalue, o qual não faz binding
com referências lvalue não-const. Por outro lado, `auto&&' permite
esse binding devido ao seu comportamento "universal" (eu não gosto
desse termo, inclusive, em C++17 essas referências são agora
_oficialmente_ chamadas de forwarding references).

Eu usei std::vector<bool> como exemplo, mas a idea é que, sempre que
estiver iterando sobre um template e houver necessidade de
de-referenciação ao elemento em si, `auto &&' deve ser usado ao invés
de `auto &'. Haja vista, que não sabemos, em hipótese, a implementação
que está por baixo.


Leandro
ltcmelo.com

[Leandro T. C. Melo]

Typo:
- que é um lvalue, o qual não faz binding com referências lvalue não-const
>>
- que é um rvalue, ...

Leandro
ltcmelo.com

[Francisco Lopes]

Corretíssimo Leandro, fora a conveniência usual que comentei, ainda tem
mais isto.

[]

[Thiago Adams]

On Sunday, July 23, 2017 at 9:41:30 PM UTC-3, Christiano wrote:

Esse post e' extenso, vou tentar fazer uma sintese, baseado em:
1- Na resposta do Leandro Melo e do Уθя¡ςκ
2- Neste artigo do Scott Meyers
3- Neste artigo do Thomas Becker
4- No final do capitulo 2 do livro do Scott Meyers "Effective Modern c++"

Ao tentar explicar vocês só demontram a complexidade do C++ em 

torno de um exemplo simples.

Lembrando que o conceito de move existe em C e você precisa entender 

o que é um ponteiro.

 

[Francisco Lopes]

Cristiano, admirável o esforço no seu texto.

Abraço!

Em 23 de jul de 2017 21:41, "Christiano" <chris...@engineer.com> escreveu:

Esse post e' extenso, vou tentar fazer uma sintese, baseado em:
1- Na resposta do Leandro Melo e do Уθя¡ςκ
2- Neste artigo do Scott Meyers
3- Neste artigo do Thomas Becker
4- No final do capitulo 2 do livro do Scott Meyers "Effective Modern c++"

Vou separar cada um dos casos tentando explicar porque eles funcionam ou nao, por vezes usando uma nova proposta de tabela de colisoes de referencias.
No meio do post darei um exemplo de uma pequena implementacao de vector<bool> usando "proxy".
Ao final darei uma explicacao do porque que o codigo do  Уθя¡ςκ funcionaria para o problema proposto por Leandro Melo baseado no ISO/IEC 14882:201.

Começo propondo uma nova...

Tabela de regra de colapso de referencias geral:

Na parte 8 do artigo de Thomas Becker ele fornece uma tabela de colisoes de referencia. A tabela que proponho a seguir e' geral:

• 'A&'       becomes A
• 'A&' &          becomes  A&
• 'A&' &&        becomes  A&
  
• 'A'        becomes A
• 'A' &      becomes A&
• 'A' &&     becomes A&&
  

Meio de facilmente decorar a tabela

Do meio ate o final e' simples de decorar. Entao vou focar do inicio ate o meio.
Regra: sempre escolha o menor.
Entre nada e 1&, escolhemos o nada
Entre 1 & e 1 &, escolhemos 1 &
entre 2 & e 1 &, escolhemos 1 &

Caso 1: Codigo do Thiago Adams + auto puro

Os unique_ptr dentro do vector sao lvalue, portanto a primeira regra de colisao e' observada:
'A&'       becomes A
Entao, nesse caso, auto sera unique_ptr<Shape>.
Como unique_ptr nao pode ser copiado, entao o compilador emitira' um erro.

Caso 2: Codigo do Thiago Adams + auto &

Os unique_ptr dentro do vector sao lvalue, portanto a segunda regra de colisao e' observada:
'A&' &          becomes  A&
Entao, nesse caso, auto sera unique_ptr<Shape> &
Nao ha' copia, entao o compilador permitira isso normalmente.

Caso 3: Codigo do Thiago Adams + auto && (do Уθя¡ςκ)

Os unique_ptr dentro do vector sao lvalue, portanto a terceira regra de colisao e' observada:
    'A&' &&        becomes  A&
Entao, nesse caso, auto sera unique_ptr<Shape> &
Nao ha' copia, entao o compilador permitira isso normalmente.

Sobre vector<bool>

Scott Meyers explica em seu livro EMC++ uma coisa chamada proxy class, vou chamar aqui de "classe representante".
O vector<bool> e' diferente dos outros vectors. Um programador menos experiente se surpreenderia (como eu me surpreendi ao ler o Leandro Melo) ao saber que vector<bool> nao aloca dinamicamente e internamente uma serie de bools, como faz com outros tipos. Ao inves disso ele trata os seus bools como bits.
Vamos supor que vector<bool> queira guardar 10 bits. Uma implementacao poderia fazer:

Esse vector<bool> poderia ter uma classe representante semelhante a isso:

struct representante
{
        representante(char *a, int b): p{a}, posicao{b} {}
        char *p;
        int posicao;
        // ...
        representante &operator=(const bool &x);
        operator bool();
};

E essa classe representante poderia conter metodos como operator=, etc.
O char *p guardaria qual dos chars de vector contem o bit em questao, e posicao (tb pode ser chamado de offset) guardaria qual posicao dentro daquele char estaria o bit.
Exemplo: se alguem quisesse se referir ao 10o elemento, teria que lidar com o char 1 e com a posicao 6 (contagem da direita para esquerda a partir de 0).

Eu fiz um teste para implementar isso me baseando estruturalmente em um codigo do Bjarne Stroustrup contido no livro PPP2(Programming: Principles and Practice using c++ 2nd edition) capitulo 19:

#include <iostream>

using namespace std;

class Representante
{
    char *p;
    int offset;
public:
    Representante(char *a, int b) : p{a}, offset{b} {}

    operator bool() const
    {
        return (*p & (0x1<<offset))!=0x0;
    }

    bool operator!=(const Representante &r) const
    {
        if( (p == r.p) && (offset == r.offset) )
            return false;
        else
            return true;
    }

    Representante &operator=(const bool x)
    {
        if(x)
        {
            *p |= (0x1<<offset);
        }
        else
        {
            *p &= ~(0x1<<offset);
        }
        return *this;
    }
    Representante &operator++()
    {
        if(offset)
        {
            offset--;
        }
        else
        {
            p++;
            offset = 7;
        }
        return *this;
    }
    Representante &operator--()
    {
        if(offset!=7)
        {
            offset++;
        }   
        else
        {
            p--;
            offset = 0;
        }
        return *this;
    }

    Representante &operator*()
    {
        return *this;
    }

};


class Vectorbool
{
    int size; // quantos bits
    char *elem; // ponteiro para o vetor de chars que guarda os bits
    int space; // quantos bits alocados ao todo (size diz quantos estao sendo usados de fato)
public:
    Vectorbool(): size{0},  elem{nullptr}, space{0}
    {
        // construtor padrao
    }

    Vectorbool(int n): size{n}, elem{new char[( (size+7)-(size+7)%8 )/8]}, space{( (size+7)-(size+7)%8 )}
    {
        for(int i=0;i<size;i++)
            operator[](i) = false; // operator[] retorna um representante
                        // o qual tem um operator= para atribuir um bool
    }

    ~Vectorbool()
    {
        delete[] elem;
    }

    void reserve(int newalloc) // newalloc deve ser multiplo de 8
    {            // se nao for, o reserve forcara que ele seja
                // arredondando pra cima de qualquer forma
                // newalloc = quantos bits eu quero alocar?
        newalloc = (newalloc+7)-(newalloc+7)%8; // forca que seja multiplo de 8
                            // arredondando pra cima
        if(newalloc <= space) // se ja tem espaco entao nao faz nada
            return;
        char *p1 = new char[newalloc/8]; // aloca a quantidade desejada
        for(int i=0;i<size;++i) // copia os elementos antigos
            p1[i] = elem[i];
        delete[] elem; // desaloca os elementos antigos
        elem = p1; // atribui o novo espaco alocado
        space = newalloc; // atualiza o valor de space
    }

    void resize(int newsize)
    {
        reserve(newsize);
        for(int i=size;i<newsize;i++)
            operator[](i) = false;
        size = newsize;
    }


    void push_back(bool d)
    {
        if(space==0)
            reserve(8);
        else if(size == space)
            reserve(2*space);
        operator[](size) = d;
        size++;
    }

    Representante operator[](int i) const
    {
                   
                return Representante    {
                                        elem?elem+((i)-(i)%8)/8:nullptr,
                                        elem?(-8-i)%8+7:0
                                        };
    }

    Representante begin() const
    {
        return Representante{elem, 7};   
    }

    Representante end() const
    {
        Representante    u{   
                    elem?elem+((size-1)-(size-1)%8)/8:nullptr,
                    elem?(-7-size)%8+7:0
                    };
        ++u;
        return u;
    }
   
    void debug()
    {
        cout << "size: " << size << endl;
        cout << "space: " << space << endl;

        for(Representante a : *this)
        {       
            cout << a << endl;
        }
   
    }

       
};


int main()
{
    Vectorbool x(10);
    x[0] = false;
    x[1] = true;
    x[2] = true;
    x[3] = true;
    x[4] = true;
    x[5] = false;
    x[6] = true;
    x[7] = false;
    x[8] = false;
    x[9] = true;

    x.debug();
   
    return 0;
}

Caso 4: Codigo do Leandro Mello modificado + auto puro + vector<bool> e a recomendacao do Scott meyers

No EMC++, capitulo 2, item 6, Scott Meyers diz:
"Use the explicitly typed initializer idiom when auto deduces undesired types."

Ou seja, peguemos novamente o exemplo proposto por Leandro Melo modificado:

#include <vector>
#include <iostream>

using namespace std;

int main()
{
        vector<bool> vbool;
        vbool.resize(10);

        bool toggle = true;

        for(auto e: vbool)
        {
                e = toggle;
                toggle = !toggle;
        }

        for(auto e: vbool)
        {
                cout << e << endl;
        }

        return 0;
}

O que esta sendo deduzido de auto?
Um desavisado C++ programador diria que e' bool quando na verdade e' vector<bool>::reference (levando em conta o quarto caso da tabela de colisoes), o qual funciona justamente como um "representante" como descrito acima. Se voce rodar esse programa voce observa isso:
1
0
1
0
1
0
1
0
1
0
Se o tipo deduzido de auto fosse realmente bool, voce nao observaria aquela alternancia. Alterando auto para bool, temos o seguinte resultado:
0
0
0
0
0
0
0
0
0
0

No primeiro caso (com auto), temos auto sendo deduzido para vector<bool>::reference e a modificacao (por meio de um operator=) altera de fato o vector, pois o representante contem enderecos do vector.
Ja no segundo caso (com bool), o vector<bool>::reference esta sendo convertido para bool usando operator bool() e atribuido para um tipo bool, e qualquer modificacao nesse bool nao modifica o vector<bool>.

Scott Meyers aconselha Nao usar auto em situacoes onde ele sera deduzido sera um "representante" pois isso pode ficar oculto para quem le o codigo.

A cada iteracao do loop do for e' atribuido um rvalue, infelizmente eu nao consegui repetir isso no meu codigo.

Caso 5: Codigo do Leandro Mello modificado + auto &

Como eu disse no final do ultimo caso, a cada iteracao do loop do for e' atribuido um rvalue. Inclusive eu tentei, sem sucesso, imitar isso, mas nao consegui (se alguem souber modificar meu programa para fazer isso, seria muito interessante).
 Usando o auto &, e sabendo que estamos lidando com um vector<bool>::reference, o qual e' um "representante", e sabendo da quinta regra da tabela:
'A' &      becomes A&
Entao teremos
//...
for(vector<bool>::reference &e: vbool)
//...
Porem nao e' possivel receber para um lvalue reference um rvalue (Exceto nos casos de const lvalure reference), entao isso resultara em erro de compilacao.

E se mudarmos para bool &?
// ...
for(bool &e: vbool)
// ...

Entao teremos outro erro, pois o operator bool() de vector<bool>::reference criara' um rvalue bool que nao pode ser referenciado por um lvalue reference bool.

Por ultimo e mais interessante:
Caso 6: Codigo do Leandro Mello modificado + auto &&

 Usando o auto &&, e sabendo que estamos lidando com um vector<bool>::reference, o qual e' um "representante", e sabendo da sexta regra da tabela:
'A' &&     becomes A&&
entao teremos auto&& se tornando:
//..
for(vector<bool>::reference &&e : vbool)
//...

Mas veja, a inicializacao da referencia "e" para um objeto rvalue parece uma coisa insegura, pois sendo o rvalue temporario, entao o "e" estaria vinculado a um objeto que ja nao existiria na linha abaixo onde ocorre uma atribuicao para ele:
//...

        for(vector<bool>::reference &&e: vbool)
        {
                e = toggle;
                toggle = !toggle;
        }
//...

Porem, o ISO/IEC 14882:2011, na secao 12.2 Temporary objects, item 4 diz:

There are two contexts in which temporaries are destroyed at a different point than the end of the full-
expression.
=
Ha' dois contextos no qual os temporarios sao destruidos em um ponto diferente do que no fim de uma expressao completa.

Ele continua dizendo:
The first context is [...] (o primeiro contexto nao tem relacao com o problema sendo discutido, portanto sera pulado)
The second context is when a reference is bound to a temporary. The temporary to which the reference is
bound or the temporary that is the complete object of a subobject to which the reference is bound persists
for the lifetime of the reference except:
=
O segundo contexto e' quando uma referencia esta vinculada para um temporario. O temporario para o qual a referencia esta vinculada ou o temporario que e' o objeto completo de um subobjeto para o qual a referencia esta vinculada PERSISTE PARA O TEMPO DE VIDA DA REFERENCIA exceto: [...] (as excecoes nao englobam o que esta sendo discutido aqui).

Portanto, em:

//...

        for(vector<bool>::reference &&e: vbool)
        {
                e = toggle;
                toggle = !toggle;
        }
//...

O rvalue para o qual a referencia "e" esta vinculado tem o tempo de vida de sua referencia de forma que e' por isso que o codigo acima funciona e e' por isso que metodo do Уθя¡ςκ (auto &&) funciona para o problema colocado por Leandro Melo.

Rodando o codigo com auto &&:

#include <vector>
#include <iostream>

using namespace std;

int main()
{
        vector<bool> vbool;
        vbool.resize(10);

        bool toggle = true;

        for(auto &&e: vbool)
        {
                e = toggle;
                toggle = !toggle;
        }

        for(auto &&e: vbool)
        {
                cout << e << endl;
        }

        return 0;
}

Resultado:
1
0
1
0
1
0
1
0
1
0
.

E se alterarmos de auto && pra bool &&?

Entao estaremos recebendo um vector<bool>::reference rvalue, sobre o qual havera a aplicacao de operator bool(), e um rvalue bool estara' sendo retornado cujo tempo de vida se igualara a sua referencia "e", como descrito no ISO.
Entao a linha
e = toggle;
nao mudara' o vector<bool> de fato, mas sim o rvalue que teve seu tempo de vida aumentado por causa de sua referencia.
Portanto o resultado sera:
0
0
0
0
0
0
0
0
0
0

Conclusoes

A nova tabela proposta conseguiu antecipar todos os casos e e' simples de decorar.
Foi explicado porque o auto && (inicialmente proposto por Уθя¡ςκ) funciona para o problema do vector<bool> (apresentado por Leandro Melo).
Foi dado um exemplo de implementacao de vector<bool> e proxy (representante).

Alguns problemas

O codigo de implementacao de vectorbool+proxy nao esta retornando rvalue a cada iteracao do loop quando aplicado em um "for range based" (ou seja, o for naquele formato --> for(auto x: y) ). Isso nao e' tanto um problema mas esta diferente do comportamento do vector<bool> padrao.

Corrigindo

Quando eu disse:

Nao existe a possibilidade de haver "move" nesse caso particular, e se houvesse (quando ao inves de usar auto && se usasse o tipo unique_ptr<Shape> &&) seria um erro logico que levaria os dois elementos do vetor a abrigar dois nullptr's(internos aos unique_ptr), tornando qualquer tentativa, posterior ao for, de acesso aos dados-membros (ou funcoes virtuais) de objetos apontados por tais enderecos a um erro de dereferencia de ponteiros nullptr.

Eu estava fazendo uma confusao grave entre referencia rvalue e move semantics, aquele e' um instrumento com o qual se pode realizar este, e nao se assemelham.

--

Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~------------------------------
[&] C & C++ Brasil - http://www.ccppbrasil.org/

Para sair dessa lista, envie um e-mail para ccppbrasil-unsubscribe@googlegroups.com

[Alexsander Lima]

Eu como novato em C++ deixo minha opinião sobre o assunto da discussão:

Eu acredito que um ponto que impacta muito é motivação/propósito. Sentar a bunda e ler 27 capítulos do livro do Bjarne Stroustrup, fazer todos os exercícios e assimilar o conteúdo, e logo depois ler os livros do Scott Meyers... bem não é simples. Eu moro em Brasília e as vagas aqui de c++, além de escassas, são para desenvolvedores pleno/sênior. É extremamente desanimador as oportunidades de c++ por aqui. Aprendi o básico de Python e depois fui até o capítulo 17 do livro do Bjarne no gás, e o que me motivou a aprender c++ e continuava motivando era o fato de poder contribuir com servidores de X jogo em comunidades online. 

Porém o tempo vai passando e você tem que pagar contas. O mercado só cospe para estágiarios/jrs vagas de .Net/Java/Js/etc, mas nada de c++. Meu primeiro estágio em uma empresa foi de PHP, e eu levava o livro de c++ na mochila. Nesse ponto é onde eu fiquei e acredito que muitos novatos também ficam..."Continuar estudando c++, será que vou encontrar uma oportunidade para aplicar e aprender?"

Então, do meu ponto de vista de um novato, aprender c++ corretamente, requer um propósito congruente com a realidade do estudante. Se o mercado não oferece oportunidades para os novatos, dificilmente ele irá se focar em c++, e o rítmo de leitura dos livros irá cair, aproveitando o tempo de estudos para aprender "o que o mercado quer".

Foi basicamente o que aconteceu comigo, meu ritmo de leitura dos livros de c++ caiu drasticamente, e fui aprender Javascript, Python/Django e até tentei me aventurar com Java, mas não gostei de Java.

Hoje em dia, foi me dada uma oportunidade de Jr. para aplicar e aprender meus conhecimentos de C++/C#. O cenário é outro, estou extremamente motivado para terminar os livros de c++ e como sou bastante inclinado para a área de segurança, já estou pretendendo ler um livro de Assembly. É realmente muito gratificante entender como as coisas funcionam por baixo dos panos. 

Do ponto de vista de um novato, é isso ;)

Em quinta-feira, 11 de dezembro de 2014 13:56:49 UTC-2, Thiago Adams escreveu:

Eu sempre defendo C++ e  vou continuar defendendo.

No entanto, uma das coisas que não nego é que é uma linguagem difícil de aprender e cheia de detalhes.

Vou colocar um exemplo aqui que não compila, eu sei o motivo, mas vou colocar apenas como exemplo das dificuldades que um iniciante passa.

#include <memory>
#include <vector>

class Shape
{
public:
  virtual void draw() = 0;
}; 

class Box : public Shape
{
  virtual void draw() {}
};

class Circle : public Shape
{
  virtual void draw() {}
};

 

int main()
{

  std::vector<std::unique_ptr<Shape>> v;
  v.push_back(std::make_unique<Box>());
  v.push_back(std::make_unique<Circle>());

  for (auto i : v)  {
    i->draw();
  }
  return 0;
}

[Ziviani]

On Sunday, July 23, 2017 at 10:59:45 PM UTC-3, Alexsander Lima wrote:

Eu como novato em C++ deixo minha opinião sobre o assunto da discussão:

Eu acredito que um ponto que impacta muito é motivação/propósito. Sentar a bunda e ler 27 capítulos do livro do Bjarne Stroustrup, fazer todos os exercícios e assimilar o conteúdo, e logo depois ler os livros do Scott Meyers... bem não é simples. Eu moro em Brasília e as vagas aqui de c++, além de escassas, são para desenvolvedores pleno/sênior. É extremamente desanimador as oportunidades de c++ por aqui. Aprendi o básico de Python e depois fui até o capítulo 17 do livro do Bjarne no gás, e o que me motivou a aprender c++ e continuava motivando era o fato de poder contribuir com servidores de X jogo em comunidades online. 

Porém o tempo vai passando e você tem que pagar contas. O mercado só cospe para estágiarios/jrs vagas de .Net/Java/Js/etc, mas nada de c++. Meu primeiro estágio em uma empresa foi de PHP, e eu levava o livro de c++ na mochila. Nesse ponto é onde eu fiquei e acredito que muitos novatos também ficam..."Continuar estudando c++, será que vou encontrar uma oportunidade para aplicar e aprender?"

Então, do meu ponto de vista de um novato, aprender c++ corretamente, requer um propósito congruente com a realidade do estudante. Se o mercado não oferece oportunidades para os novatos, dificilmente ele irá se focar em c++, e o rítmo de leitura dos livros irá cair, aproveitando o tempo de estudos para aprender "o que o mercado quer".

Foi basicamente o que aconteceu comigo, meu ritmo de leitura dos livros de c++ caiu drasticamente, e fui aprender Javascript, Python/Django e até tentei me aventurar com Java, mas não gostei de Java.

Hoje em dia, foi me dada uma oportunidade de Jr. para aplicar e aprender meus conhecimentos de C++/C#. O cenário é outro, estou extremamente motivado para terminar os livros de c++ e como sou bastante inclinado para a área de segurança, já estou pretendendo ler um livro de Assembly. É realmente muito gratificante entender como as coisas funcionam por baixo dos panos. 

Do ponto de vista de um novato, é isso ;)

Eu acho que seu ponto de vista não é de novato, é a realidade no Brasil. Vários colegas que querem fazer algo diferente desses "enterprises" e web/apps acabam indo pra fora do Brasil.