[quote=Luiz Niedermier Custodio]Bom, acho que finalmente, me decidi a ficar com o Deitel, pois acredito, que se ficar trocando de livro sem ter uma boa base, posso ficar meio perdido, confuso. Mas só gostaria de tirar uma última dúvida. Qual a diferença da 3ª para a 5ª Edição?
Também vi dizerem, que se o livro for de 1999 pra cá não faz diferença, pois a ultima “versão” do C++ é de 1998, é verdade?[/quote]
Não…
Como o amigo respondeu: “Desde 2001 até hoje, o C++ passou por 2 padronizações, uma em 2003 e outra em 2009.”
E tem modificações sempre…
Mas essas modificações que ocorreram nestes últimos anos, alteram muita coisa na forma de programar?
Na linguagem básica, não. Ou seja, pode estudar com Deitel tranquilo.
Na forma de programar, sim. Mas isso vc só vai aprender em livros um pouco mais avançados, quando estudar os smart pointers, templates, raii e coisas do gênero.
E novamente repetindo, provavelmente a ultima pergunta referente aos livros, qual a diferença da 3ª para a 5ª Edição do Deitel?
Sou meio indeciso no começo, mas geralmente, depois que tenho um maior conhecimento no assunto, me “solto” bem mais.
[quote=Luiz Niedermier Custodio]Bom, acho que finalmente, me decidi a ficar com o Deitel, pois acredito, que se ficar trocando de livro sem ter uma boa base, posso ficar meio perdido, confuso. Mas só gostaria de tirar uma última dúvida. Qual a diferença da 3ª para a 5ª Edição?
Também vi dizerem, que se o livro for de 1999 pra cá não faz diferença, pois a ultima “versão” do C++ é de 1998, é verdade?[/quote]
Sim a última padronização significativa foi de 1998 e estão para lançar o famoso padrão C++0X que fazem 10 anos que estão prevendo… mas agora deve ser C++XX…
Se não me engano, se for a versão do livro do Deitel a melhor é a da Terceira… pois deve ser a tradução da BookMan… agora se for comprar o livro em inglês, compre a última…
Lembre-se que a linguagem C++ é o de menos… e o que vale são os FrameWorks e bibliotecas e tecnologias atreladas… aí vem uma sopinha de letrinha… ATL/MFC/QT/STL/Boost/Posix/APIWin32/Corba/Pro*C/DCom/OCCI/VisualC++/gcc/g++/gdb/Motif/lint/yacc/OTL/Berkeley DB/C++ Builder/Dynamic Libraries/essas são as que eu me lembrei vagamente… mas com certeza é muito mais… e ainda isso são só as mais conhecidas… em toda empresa tem coisa nova(nova no sentido de alguém pegar uma biblioteca na Internet e resolver usar ou até mesmo fazer do zero, o mais comum)…
C++ é igual Java… a linguagem é o mais fácil… o difícil é escolher as N opções… só que em C/C++ essas N opções são multiplicadas por várias vezes em C/C++… pois como se sabe, C/C++ todo mundo gosta de reinventar as coisas, não documentar nada, e deixar o código com a cara do programador… Em Java pelo menos as coisas são bem mais padronizadas/documentadas/testadas…
Ah, esqueci dos famosos Makefiles também… :lol: :lol: :lol:
Deixaram o programador para fazer na mão a linkedição e compilação dos seus arquivos, mas na prática a preguiça mata e quando se compila algo, é melhor compilar tudo mesmo… :lol: :lol: :lol:… a não ser que você tenha uma IDE como o Visual C++…
Cara, eu comprei a terceira edição e achei ela bem completa. Não acho que vale a pena pagar a mais o preço de outro livro só para ter a edição mais nova. Eu não sei todas as diferenças entre elas, mas sei que na quinta edição ele começa em capítulos mais cedo a falar de orientação ao objeto, dá um estudo de caso diferente. Mas para tirar as dúvidas mesmo, olhe o conteúdo pelo índice e veja se há tantas diferenças assim e faça a sua escolha.
Abraços
Não acho o C++ muito diferente do Java nesse sentido. Você tem os bons frameworks (boost, Qt, havoc, STL, etc) que são extremamente bem documentados e mantidos por empresas. E você tem frameworks de amadores, ou de profissionais com boa intenção, onde a documentação é realmente péssima e a qualidade do código pode ser duvidosa.
Agora, pegue a documentação das libs padrão e da boost, por exemplo, e você vai ver que ela dá de 10 a 0 na documentação do Java da própria Sun.
Nas indústrias que eu trabalhei, o código C++ era limpo e bem documentado. A única vantagem do Java é que a Sun, logo que iniciou a linguagem, impôs uma code convention (que foi baseada, inclusive, numa das convenções mais comuns no C++).
Voltando a dúvida do autor do tópico, a quinta edição teve uma das maiores revisões dos livros. Acho o texto da quinta menos prolixo e mais coeso. Se fosse comprar, compraria definitivamente após a quinta edição (o livro está na sétima). Ele também é um pouco mais atualizado com algumas técnicas modernas de programação em C++ usando a STL.
Na verdade boost, stl não seria um framework… por isso que em C/C++ cada um inventa seu próprio framework… Um Framework seria o QT, o próprio C++ Builder que embute um framework… a MFC… e etc… até o arquiteto da Microsoft inventou um framework padronizado(talvez umas das primeiras coisas que usaram OOP… com conceitos de Encapsulamento e Objetos… no caso o termo Handle seria um ponteiro para um objeto)… a famosa API Win32… que precisa de umas 50 linhas de código para se escrever um HelloWorld… e isso motivou cada um inventar o seu framework… MFC/QT/Borland/Etc…
No caso do Java sempre existe o framework padrão… nos diversos frameworks(para Web, Desktop, Embed, etc) para Java o EJB2 não ficou bom e resolveram praticamente fazer outra especificação… o EJB3…
No caso do C++… não existe um Framework padrão… por isso que cada um gosta de inventar a sua idéia… veja que em qualquer fórum de C/C++ cada um acha melhor de um jeito… e no final ninguém chega a nenhuma conclusão… pois existe tantas opções, que no final fica aquela guerra de… o meu jeito é melhor porque é assim assim assado, aí chega outro e fala… o meu é melhor porque assim assim assado… e fica em loop infinito…
O C/C++ deixa aberto até o tamanho de um simples inteiro… pois sabe que forçar algo vai prejudicar o desempenho… até um simples caractere no C/C++ é motivo de confusão… pois existem milhares de classes string por exemplo… e no Java já resolveram deixar o overhead de 2 bytes(no C/C++ seria 1 byte se não usar unicode) por caracter na String e já implementaram tudo na classe String… fica lento mas pelo menos todo mundo sabe usar e é padrão…
O pior é que se procurar no Google por C++ string… até o Google coloca em primeiro um site não oficial da STL… até o Google já percebeu como C++ é diversificado… :lol: :lol: :lol:… no Java tudo aponta para o site da Sun… :lol: agora tenta procurar um simples ltrim/rtrim/trim no C++ padrão… :lol: :lol: :lol: agora imagine quantos ltrim ou rtrim existem por aí… agora imagine isso multiplicado por cada coisinha que você precise… :lol:
No Java já tem tudo pronto… por isso que gosto de Java… reinvenção de roda é duro…
Ah… no C/C++ eles nem especificam o tamanho do unicode… não sei se no Java também… mas isso não tem a mínima importância em Java… já no C/C++ tem e muita… talvez seja por isso que ninguém usa unicode…
Ah não? E o que são então?
A STL é um framework. E é padrão da linguagem. Na verdade, ele é tão padrão que é regulamentado pelo mesmo comitê, e normatizado pela ISO, por isso tanta demora entre duas versões de C++. Vem com qualquer compilador C++, inclusive o da Microsoft. STL é a sigla de “Standard Template Library”.
A boost não é exatamente padrão, mas é feita pelo mesmo comitê. A diferença é que ela é mais como a lib da sun, possui um board menos rigoroso que uma ISO da vida, e então permite adição de conteúdo mais rapidamente que o padrão rigoroso do C++ exige. E claro, coisas boas da boost vão sendo gradualmente incorporadas ao padrão oficial, como o caso dos smarts pointers da boost, que já fazem parte da tr1.
Os frameworks possuem classes para diversas funcionalidades como listas, sockets, threads, comunicação entre processos, etc.
O java também tem diversos frameworks, mesmo para a mesma coisa. Por exemplo, para interface gráfica temos a AWT e o Swing (só na própria Sun), além do SWT. No caso de frameworks 3D, temos o Java 3D, JOGL, LWJGL. Se incluirmos engines, JMonkeyEngine, Xyth3D. Mobile? A google recentemente reinventou a roda com o Android, sendo que já existia o framework padrão. Todos fazem a mesma coisa. API de persistência temos o Hibernate, o JPA e o Toplink, etc, etc, etc…
Variedade de frameworks é um ponto positivo, na minha opinião. Pois cada fabricante de framework oferecerá um conjunto novo de vantagens. Mas claro, como o C++ existe ha muito mais tempo, e tem muito mais empresas grandes dando suporte, haverá mais opções disponíveis no mercado.
A classe String do Java é mais “ajeitada” porque o Java veio depois do C++. A maior parte das bibliotecas (incluindo a MFC) estão abandonando suas próprias classes string em prol da std::string e a std::wstring. Ambas são a implementação da classe string na API padrão do C++, a STL. O C++ te dá a escolha de suportar ou não unicode, por isso a existência de duas classes. Claro que dá mais confusão caso você decida interoperar as duas coisas, mas enfim, é o que se paga por ter escolha.
Se procurar por C++ string, o google coloca em primeiro lugar o site http://www.cplusplus.com/reference/string/string/, que traz uma documentação sobre a STL oficial. A documentação desse site é tirada do doxygen da própria STL e o site é considerado uma das principais referências da linguagem (assim como uma das principais referências sobre Java é o site da IBM).
[quote=“Felipe kan”]Ah, esqueci dos famosos Makefiles também…
Deixaram o programador para fazer na mão a linkedição e compilação dos seus arquivos, mas na prática a preguiça mata e quando se compila algo, é melhor compilar tudo mesmo… … a não ser que você tenha uma IDE como o Visual C++… [/quote]
Já tentou compilar na mão um programa com libs no Java? É tão complicado quanto escrever um makefile. E que tal escrever manifest para .jars ou aqueles arquivos .xml para o JNLP?
Framework é bem diferente de Library… :lol: :lol:
E C/C++ nunca foi e está muito longe de ser compatível… quem tem bastante experiência com C/C++ sabe que existem várias incompatibilidades de compiladores… até úm dos criadores do STL o Herb Sutter sempre dedica páginas e páginas falando de problemas de compatibilidade… ou seja, funciona em um compilador e não funciona em outro… e o criador do C/C++ sempre tem 2 ou 3 máquinas com sistemas diferentes para ficar testando código em plataformas distintas…
Até hoje em dia o padrão de C++ de 1998 ainda tem problemas de compatibilidade… a Microsoft nos últimos compiladores até criou uma opção para forçar o código padrão… mas aposto que ninguém habilita essa opção… assim como no g++ quase ninguém compila com ANSI e sim sempre com -03…
Qual é a diferença de framework e library para você?
Alguns autores defendem que é porque framework é baseado em extensão, enquanto library não. No caso, a STL começou com muito uso e pouca extensão, mas hoje já não é assim. Você pode estender iterators, collections, etc. A boost é um framework, indiscutivelmente.
Na verdade, existe incompatibilidade de compiladores porque no C++ você pode escolher entre vários compiladores, enquanto no caso do Java o compilador da Sun é praticamente monopolista. O que também significa que se a Oracle resolver abandonar a construção desse compilador, o java estará em maus lençóis. Obviamente, alguns fabricantes de compiladores C++, na pressa de inserir recursos mais avançados, não são tão fiéis a especificação assim. Atualmente, entretanto, o compilador da MS tem ficado cada vez mais fiel ao standard, e alguns compiladores são famosos por serem bastante fieis como o GNU.
No Java, também temos alguns problemas de compatibilidade com compiladores fora dos da Sun. Ou problemas de execução em VMs diferentes da padrão: eu mesmo tive alguns problemas com a VM da IBM, que simplesmente não retornava os tipos de classes via reflexão - sem falar é claro na guerra que ocorreu entre a Sun e a Microsoft por causa da MSVM não ser lá tão padrão.
Todas as últimas aplicações que fiz compilavam perfeitamente bem em diversos compiladores. O código da boost mesmo é homologado em diversas versões, assim como o da STL. Mas já enfrentei sim alguns problemas de compatibilidade, geralmente corrigíveis. Agora, nunca fiz um código de uma lib, em que fosse necessário compilar em dezenas de compiladores diferentes e não sei o quanto complexo é essa tarefa.
Mas claro, no C++ é um pouco mais complexo porque a linguagem não é multi-plataforma. Os compiladores geram código para um SO específico e não para uma VM padrão. Isso, entretanto, é uma característica da linguagem, não necessariamente uma desvantagem. Até porque código específico também tem vantagens, como o aproveitamento de instruções específicas, menor consumo de memória, não ser necessário instalar uma VM, entre outras coisas.
[quote=ViniGodoy]Qual é a diferença de framework e library para você?
…
[/quote]
FrameWork seria um Struts por exemplo… e um strcpy uma biblioteca padrão… apesa de preferir um strncpy…
O boost foi feito para ser algo para resolver um propósito genérico… e não um específico… como no caso do Struts…
[quote=Felipe Kan]Framework é bem diferente de Library… :lol: :lol:
E C/C++ nunca foi e está muito longe de ser compatível… quem tem bastante experiência com C/C++ sabe que existem várias incompatibilidades de compiladores… até úm dos criadores do STL o Herb Sutter sempre dedica páginas e páginas falando de problemas de compatibilidade… ou seja, funciona em um compilador e não funciona em outro… e o criador do C/C++ sempre tem 2 ou 3 máquinas com sistemas diferentes para ficar testando código em plataformas distintas…
Até hoje em dia o padrão de C++ de 1998 ainda tem problemas de compatibilidade… a Microsoft nos últimos compiladores até criou uma opção para forçar o código padrão… mas aposto que ninguém habilita essa opção… assim como no g++ quase ninguém compila com ANSI e sim sempre com -03…
[/quote]
O único compilador de c++ que não segue iso no mercado é o da MS. Todos o outros compiladores são 100% compatíveis, senão não existiriam frameworks como
wxwidgets, gtk e o qt, que são multiplataformas. Isso falando de c++.
O formato de executáveis muda entre o borland c++ e o msc++ também, sendo o primeiro a usar omf e o segundo coff. No mundo, o único problema de incompatibilidade existia por causa da briga dessas empresas.
http://www.metagraphics.com/metawindow/faq/mwfaq030.htm
Não sei onde você tirou o “funciona em um compilador e não funciona em outro”. Existem centenas de compiladores que implementam perfeitamente o padrão iso.
[quote=Felipe Kan][quote=ViniGodoy]Qual é a diferença de framework e library para você?
…
[/quote]
FrameWork seria um Struts por exemplo… e um strcpy uma biblioteca padrão… apesa de preferir um strncpy…
O boost foi feito para ser algo para resolver um propósito genérico… e não um específico… como no caso do Struts…[/quote]
Não existe diferença entre biblioteca padrão e framework. Diz-se biblioteca padrão porque simplesmente foi adotada a especificação, assim como em breve, a boost será padrão também.
O borland c++ já usa a boost como padrão a muito tempo. É uma questão de tempo a iso engolir ela também.
Bom, eu acabei por comprar a 3ª edição do Livro do Deitel usado, do usuário Schuenemann aqui do fórum.
Depositei ontem o valor combinado, acho que ele já deve ter despachado, e deve chegar quarta ou quinta da semana que vem aqui.
Portanto, por mim, pode fechar o tópico (não sei se os moderadores aqui costumam fazer isso).
[quote=juliocbq] Todos o outros compiladores são 100% compatíveis, senão não existiriam frameworks como
wxwidgets, gtk e o qt, que são multiplataformas.
[/quote]
Hum… isso é porque você não usou aqueles compiladores C/C++ de sistemas não-Unix (ou mesmo de sistemas Unix mais antigos). 100% de compatibilidade é um mito.
De qualquer maneira, nada que um monte de #ifdefs (e o famoso script “configure”) não possam fazer por você. Só dá um bocadinho de trabalho, e obviamente o “write once, test anywhere” que é um lema do Java* mas é mais ainda para o C++.
*OK, o lema na verdade é “write once, run anywhere”, mas é claro que isso é também um mito. Na realidade você precisa é testar em todos os ambientes em que você quer que o tal programa rode.
[quote=entanglement][quote=juliocbq] Todos o outros compiladores são 100% compatíveis, senão não existiriam frameworks como
wxwidgets, gtk e o qt, que são multiplataformas.
[/quote]
Hum… isso é porque você não usou aqueles compiladores C/C++ de sistemas não-Unix (ou mesmo de sistemas Unix mais antigos). 100% de compatibilidade é um mito.
De qualquer maneira, nada que um monte de #ifdefs (e o famoso script “configure”) não possam fazer por você. Só dá um bocadinho de trabalho, e obviamente o “write once, test anywhere” que é um lema do Java* mas é mais ainda para o C++.
*OK, o lema na verdade é “write once, run anywhere”, mas é claro que isso é também um mito. Na realidade você precisa é testar em todos os ambientes em que você quer que o tal programa rode. [/quote]
Pelo menos os que eu usei, o ms, o intel, o borland, o gnu, e o digitalmars hoje seguem perfeitamente iso. Somente tive problemas para compilar com o msc++ 6, a 5 anos.
Até hoje nenhum me deu problema(no quesito linguagem), Formato de executável é outra história(COFF OMF).