Migrando de Java para C++

Boa sorte. Mas lembre-se que o C++ faz valer aquela frase famosa:

“Com grandes poderes vem grandes responsabilidades”

Acho hoje, o Java a melhor linguagem de desenvolvimento.
Já tenho uma aplicação em java mas estou esbarrando no problema do consumo de memória.

Infelizmente Java Swing está consumindo mais memória do que deveria, a diferença de consumo de recursos é muito grande.
E para o tipo de aplicação que desenvolvo, cliente acha que tem que rodar em qualquer coisa e com java não é bem assim.

Mas vamos lá, acho que em uns dois meses consigo material de aprendizdo suficente para inciar a migração.

Abraçao.

Já que o seu intuito é baixar o uso de memória, analise bem se vale a pena usar o QT. Em um comparativo que rolou em uma discussão da lista de C++ Brasil do Google, um cara mostrou que com QT a janela dele tinha ~4Mb, e fazendo na mão ficava com menos de 300kb.

Pelo que você relatou tb, vc vai migrar uma big aplicação para C++, e só tem 2 semanas de estudo de C++, ou seja, o risco tá bem alto. Tvz vc o caso de contratar um consultor C++, pois é possível por exemplo usar garbage collector com C++, mas normalmente quem não conhece C++ pensa que isso não existe(não sei se é o seu caso).

Boa sorte e sucesso na migração.

Hhehe, não nao, estou apenas iniciando os estudos… creio que vai uns dois meses para começar a fazer alguma coisa concreta.

Estou pensando no QT, pois sem modificação dá pra compilar no linux e no windows sem modificação além da produtividade na questão de design das telas que é bem simples.

Com certeza, porém creio que a parte da linguagem dá pra ir lendo e estudando, meu conhecimento do OO é bem solido então creio que isso será simples, porém vou precisar de coisas mais avançadas como comunicação com Webservices, Comunicação Serial e nesse caso penso em chamar consultores específicos para ajudar a acelerar o processo.

Também sei que o negócio não será simples, pois é uma aplicação séria, ou seja, não dá pra fazer como trabalho de faculdade, então realmente vou ter que estar bem seguro para poder iniciar a migração.

Abraço

lavh:

Já que o seu intuito é baixar o uso de memória, analise bem se vale a pena usar o QT. Em um comparativo que rolou em uma discussão da lista de C++ Brasil do Google, um cara mostrou que com QT a janela dele tinha ~4Mb, e fazendo na mão ficava com menos de 300kb.

Eu digo que uma aplicação desktop que tiver mais de 1 janela ou 3 controles deve usar algum toolkit.
Ou seja, quase todas.
Os casos de uso em que se necessita codificar tais aplicações na mão são muito poucos e específicos.
E use o Qt; além disso, investigue o Boost. No começo você vai apanhar bastante (aff) mas depois vai ver que é bastante fácil portar algo de Java para C++ / Boost porque os conceitos ficam bem parecidos. Vou dar um exemplo daqui a pouco.

/**
 * @file TesteInstanceOf.cpp
 * @brief Usando herança e limpeza automática de memória com o Boost ( http://www.boost.org )
 * Comentado com Doxygen. Veja: http://www.doxygen.org 
 */
 #include <boost/shared_ptr.hpp>
 #include <boost/make_shared.hpp>
 #include <string>
 #include <iostream>
 
 using namespace std;
 using namespace boost;
 
 /**
  * @brief A superclasse
  */
 class Animal {
 public:
     Animal() { cout << "Animal()" << endl; }
	 virtual string toString() { return "Bzz! "; }
	 virtual ~Animal() { cout << "~Animal" << endl; }
 };
 ostream& operator << (ostream& out, const Animal& animal) {
     out << "Bzz! ";
	 return out;
 }
 /**
  * @brief Uma subclasse
  */
 class Cachorro : public Animal {
 public:
     Cachorro() { cout << "Cachorro()" << endl; }
	 virtual string toString() { return "Au! "; }
	 virtual ~Cachorro() { cout << "~Cachorro" << endl; }
 };
 ostream& operator << (ostream& out, const Cachorro& cachorro) {
     out << "Au! ";
	 return out;
 }
 /**
  * @brief Outra subclasse
  */
 class Gato : public Animal {
 public:
     Gato() { cout << "Gato()" << endl; }
	 virtual string toString() { return "Miau! "; }
 	 virtual ~Gato() { cout << "~Gato" << endl; }
 };
 ostream& operator << (ostream& out, const Gato& gato) {
     out << "Miau! ";
	 return out;
 }
 /**
  * @brief Esta classe não é superclasse de nenhuma das outras.
  */
 class Vegetal {
 public:
     Vegetal() { cout << "Vegetal()" << endl; }
	 virtual string toString() { return "Bla! "; }
	 virtual ~Vegetal() { cout << "~Vegetal" << endl; }
 };
 ostream& operator << (ostream& out, const Vegetal& vegetal) {
     out << "Bla! ";
	 return out;
 }
 
 int main (int argc, char *argv[]) {
     // Java: Animal animal = new Cachorro();
	 // Note que isto chama o construtor de Cachorro, que chama o construtor de Animal. 
     shared_ptr<Animal> animal = make_shared<Cachorro>();
	 // Java: if (animal instanceof Gato && (gato = (Gato) animal) != null) {
	 if (shared_ptr<Gato> gato = dynamic_pointer_cast<Gato>(animal)) {
	     cout << "O animal eh um gato: " << endl;
	 } else {
	     cout << "O animal nao eh um gato" << endl;
	 }
	 // Atenção: a linha a seguir chama operator << (Animal), ou seja, vai imprimir "Bzz!", 
	 // o que não é o esperado por um programador Java.
	 cout << *animal << endl;
	 // Java: System.out.println (animal.toString());
	 cout << animal->toString() << endl; 
	 // Java: System.out.println ("O tipo do animal eh " + animal.getClass().getName());
	 cout << "O tipo do animal eh " << typeid (*animal).name() << endl;
	 // Note que quando a variável "animal" sai do escopo e não há mais variáveis
	 // que apontam para o mesmo objeto Cachorro, o destrutor de Cachorro (que chama o destrutor de Animal)
	 // entra em ação.
 }

A saída esperada é:

Animal()
Cachorro()
O animal nao eh um gato
Bzz!
Au!
O tipo do animal eh class Cachorro
~Cachorro
~Animal

Ouça o entanglement, ele sabe o que diz.

Programar em C++ sem usar a STL, a boost e alguns toolkits é como programar em Java se recusando a usar qualquer coisa fora do pacote “java.lang”. Ou seja, uma idiotice completa!

entanglement:

Eu digo que uma aplicação desktop que tiver mais de 1 janela ou 3 controles deve usar algum toolkit.
Ou seja, quase todas.
Os casos de uso em que se necessita codificar tais aplicações na mão são muito poucos e específicos.
E use o Qt; além disso, investigue o Boost. No começo você vai apanhar bastante (aff) mas depois vai ver que é bastante fácil portar algo de Java para C++ / Boost porque os conceitos ficam bem parecidos. Vou dar um exemplo daqui a pouco.

Vou dar uma pesquisada sobre Boost.
Usar toolkit realmente é o objetivo, tentarei evitar apenas usar itens especificos de uma determinada plataforma e quando eu não tiver saída, partirei para o conceito de plugins, algo como (libserial_linux.so serial_win.dll) desta forma deixar a aplicação o mais robusta possível

black_fire:

entanglement:

Eu digo que uma aplicação desktop que tiver mais de 1 janela ou 3 controles deve usar algum toolkit.
Ou seja, quase todas.
Os casos de uso em que se necessita codificar tais aplicações na mão são muito poucos e específicos.
E use o Qt; além disso, investigue o Boost. No começo você vai apanhar bastante (aff) mas depois vai ver que é bastante fácil portar algo de Java para C++ / Boost porque os conceitos ficam bem parecidos. Vou dar um exemplo daqui a pouco.

Vou dar uma pesquisada sobre Boost.
Usar toolkit realmente é o objetivo, tentarei evitar apenas usar itens especificos de uma determinada plataforma e quando eu não tiver saída, partirei para o conceito de plugins, algo como (libserial_linux.so serial_win.dll) desta forma deixar a aplicação o mais robusta possível

Plugins? Eu aconselharia apenas segregar e encapsular a funcionalidade dependente de sistema operacional em algumas classes, não precisa complicar seu código mais ainda ao carregar plugins dinamicamente. Não é isso que vai deixar sua aplicação “portável”.
Se olhar os fontes do JDK que estão em C++ vai ver que há uma boa parte comum e há algumas partes que são segregadas e diferentes. Baixe os fontes do JDK em:

http://download.java.net/jdk6/source/

entanglement:

Plugins? Eu aconselharia apenas segregar e encapsular a funcionalidade dependente de sistema operacional em algumas classes, não precisa complicar seu código mais ainda ao carregar plugins dinamicamente. Não é isso que vai deixar sua aplicação “portável”.
Se olhar os fontes do JDK que estão em C++ vai ver que há uma boa parte comum e há algumas partes que são segregadas e diferentes. Baixe os fontes do JDK em:
http://download.java.net/jdk6/source/

Em resumo o que vocês está dizendo é ter realmente duas aplicações, algo mais ou menos assim:

• Genérico
  Regras de negócios
  Acesso a banco
  Desenhos de telas
  Tudo que puder ser igual, sem adaptações

• Aplicação Linux
  Adaptações especiais para Linux usando os componentes genéricos

• Aplicação Windows
  Adaptações especiais para Windos usando os componentes genéricos

Seria mais ou menos essa a idéia?
Tirando a parte genérica ter duas aplicações distintas tirando o melhor de cada Sistema Operacional?

Abraço valeu pelas dicas

Novo post incluído no blog,

Instalação Detalhada do QT - Linux e Eclipse

Abraço e obrigado a todos que estão acompanhando e comentando…

Novo post incluído no blog,

Comentários Importantes, Foruns e afins?

Obs: Tomei a liberdade de transcrever alguns comentários para o blog,
caso alguém queria que seu comentário seja removido, favor informar que será
excluído imediatamente.
Todas as transcrições apontam para os posts originais, a intensão foi apenas
centralizar os comentários enviados.

Abraço e obrigado a todos que estão acompanhando e comentando…

Opa!

Blog assinado.

Não tanto pelo fato da migração, mas sim para acompanhar a sua evolução no aprendizado em c++ e quais rumos esta seguindo (sempre surge algo que eu posso pesquisar depois), pois estou em um barco semelhante, estudando c++ a aproximadamente 1 mes, mas no meu caso é pura diversão heheheh.

[]'s

vc só tem 2 semanas de estudo em C++ e quer migrar uma app… meu de boa… esqueça… C++ não é que nem Java, .Net ou outras linguagens… C++ vc tem o poder de manipular o acesso direto a memoria… e até recursos de hardware… porem se este poder não for usado com cautela… terás muita dor de cabeça… além do mais não existe GC… a terefa do GC é vc que faz… em C++ não existe desenvolvedor junior, pleno ou senior… C++ ou vc é mestre ou não é nada…

Uma pequena dúvida, já que você esta desenvolvendo esse tipo de aplicativo: Qual ferramenta utilizará para relatórios ? Acredito que hoje use ireport/jasperreport. Prentende manter a dupla ou existe uma solução do nível e em c++ ?

[]'s

black_fire, você já rodou um profiler na sua aplicação para saber pq ela consome tanta memória?
Por que talvez a migração não compense o esforço extra. Ou talvez você esteja é presenciando um consumo devido à um bug, não ao Swing.

Dado a realidade que ele apresentou, eu acreidto que a execução de um profiler e a correção de qualquer bug/memory leak encontrado, não vai fazer com que uma aplicação java/swing consuma uma quantidade de memória aceitável para determinado perfil de máquina.

Ainda não tive a oportunidade de usar um aplicativo swing que, depois de um certo tempo de uso, não estivesse com uma quantidade de memória exagerada para o tamanho e funcionalidade executada no momento.

E a realidade que se encontra em pdv’s por exemplo e complicada em muitos casos.

[]'s

Onde ele apresentou a situação?

Mas realmente, fazer em C++ irá poupar bastante recursos. Só tem que tomar MUITO cuidado com as plataformas escolhidas, e também seguir direitinho os padrões, ou a aplicação não será portável.

black_fire, você precisa que ela rode em Linux também, ou só Windows?

Achei ali no blog onde ele descreve a situação.

Realmente, nem pelo Swing, mas pelo acesso direto a portas seriais e hardware, eu já desaconselharia o Java. A API javax.comm é praticamente abandonada, ainda na época da Sun (o suporte ao Windows, por exemplo, simplesmente sumiu). E a rxtx é boa, mas ainda deixa muito a desejar.

Usar C++ nesse caso é muito mais indicado. Não só vai te dar um controle maior da aplicação, como vai permitir que você rode em sistemas mais humildes.

Outra coisa, conside a possibilidade de seu PDV se comunicar via socket com um sistema de ponto de venda. Aí, somente o seu PDV fica em C++, enquanto o sistema em si continua em Java. A comunicação pode ser via socket, ou mesmo troca de arquivos (não sei como você faz isso hoje), mas não acho que valha a pena migrar as duas pontas do sistema.

Finalmente, não considero o Eclipse uma boa escolha de IDE. Ele é lento, tem pouca integração com o debugger. Se seu sistema for para Windows, sugiro que use o Visual C++. Se for multiplataforma, procure pelo Qt Creator.

Qt Creator

Fala galera, vamos por parte como diria nosso amigo Jack…ehehehe

A aplicação hoje não possui reports, pois não é permitido (legislação) ter outra impressora que não seja a fiscal (ECF) conectada na estação.
Todos os relatórios são emitidos como texto puro direto na porta serial, então não cheguei a pensar nesse ponto.
Vi em um Livro que estou lendo [C++ GUI Programming with Qt 4] que a interface print é muito simples e exporta para HTML e XML, creio que isso seja o suficiente para relatórios, mesmo os mais complexos.

ViniGodoy:

black_fire, você já rodou um profiler na sua aplicação para saber pq ela consome tanta memória?
Por que talvez a migração não compense o esforço extra. Ou talvez você esteja é presenciando um consumo devido à um bug, não ao Swing.

khaoz:

Dado a realidade que ele apresentou, eu acreidto que a execução de um profiler e a correção de qualquer bug/memory leak encontrado, não vai fazer com que uma aplicação java/swing consuma uma quantidade de memória aceitável para determinado perfil de máquina.
Ainda não tive a oportunidade de usar um aplicativo swing que, depois de um certo tempo de uso, não estivesse com uma quantidade de memória exagerada para o tamanho e funcionalidade executada no momento.
E a realidade que se encontra em pdv’s por exemplo e complicada em muitos casos.
[]'s

ViniGodoy:

Onde ele apresentou a situação?
Mas realmente, fazer em C++ irá poupar bastante recursos. Só tem que tomar MUITO cuidado com as plataformas escolhidas, e também seguir direitinho os padrões, ou a aplicação não será portável.
black_fire, você precisa que ela rode em Linux também, ou só Windows?

ViniGodoy:

Achei ali no blog onde ele descreve a situação.
Realmente, nem pelo Swing, mas pelo acesso direto a portas seriais e hardware, eu já desaconselharia o Java. A API javax.comm é praticamente abandonada, ainda na época da Sun (o suporte ao Windows, por exemplo, simplesmente sumiu). E a rxtx é boa, mas ainda deixa muito a desejar.
Usar C++ nesse caso é muito mais indicado. Não só vai te dar um controle maior da aplicação, como vai permitir que você rode em sistemas mais humildes.
Outra coisa, conside a possibilidade de seu PDV se comunicar via socket com um sistema de ponto de venda. Aí, somente o seu PDV fica em C++, enquanto o sistema em si continua em Java. A comunicação pode ser via socket, ou mesmo troca de arquivos (não sei como você faz isso hoje), mas não acho que valha a pena migrar as duas pontas do sistema.
Finalmente, não considero o Eclipse uma boa escolha de IDE. Ele é lento, tem pouca integração com o debugger. Se seu sistema for para Windows, sugiro que use o Visual C++. Se for multiplataforma, procure pelo Qt Develop.

Pois é, nossa retaguarda hoje é Java Web, e continuará, será apenas o ponto de venda que será migrado, pois nesse caso as máquinas são melhores e não vale o esforço com certeza.
Comunicação com Libs em geral em Java é Fod… o problema é não dar exception, sempre que há um erro, simplesmente o Java fecha do nada, imprimindo um “log de erro muito amigável”.
Também achei meio complicado o debug do Eclipse, ainda não sei se será a escolha final se não tiver uma forma de melhorar o debug.

Abraço valeu pelas dicas…

Quanto ao javax.comm concordo. É uma pena uma api daquelas ter sido deixada no esquecimento, mas o rxtx considero uma ótima opção em comparação a outras (como a giovynet por exemplo), nesse caso gostaria de saber por que você acha que o rxtx deixa a desejar?

Já usou serial no C++?

Por incrível que pareça, é muito mais fácil que a RXTX. É mais fácil usar pinos em paralelo ou sincronizar dados.

Na verdade como disse no post anterior, não acho o problema exclusivo do RxTx, que funciona bem, o problema é a interação do Java com Lib (.so ou .dll).
Quando ocorre uma falha as libs não retornam erro para o Java, a VM simplesmente fecha.
O problema realmente não é o erro em si e sim a falta do motivo. Veja como exemplo, identificamos que no Debian, quando não há pariedade de memória (duas memórias de tamanho diferentes) eventualmente a VM fecha, quando as memórias são casadas corretamente isso não ocorre.

Em linguagens compiladas como C, C++ ou Pascal o acesso é mais natural e os tratamentos são melhores na minha opnião…

O duro são sempre os erros relacionados aos dangling pointers. Eles acabam abortando o programa sem muita informação também. Por isso é bem escolher um bom compilador, e ser muito, muito, muito, muito, muito, chato com alocação e desalocação de memória.

Não deixe de usar RAII e de seguir as dicas do Effective C++, ou você vai ter muitas dores de cabeças com erros sem qualquer tipo de informação.

Há um livro (um pouco antigo por sinal) chamado “J2EE Antipatterns”. Um dos antipatterns é “usar JNI”. Eles dizem que “use só quando não houver outra alternativa, e se possível segregar o código C/C++ em outro executável, e se comunicar com esse executável (por exemplo) via sockets ou arquivos.”

Já usou serial no C++?

Por incrível que pareça, é muito mais fácil que a RXTX. É mais fácil usar pinos em paralelo ou sincronizar dados.

Ahh bom, quando você se referiu à deixar de desejar estava falando de facilidade de manuseio e manipulações mais apuradas (usar pinos em paralelo), tinha entendido que a critica estava ligada a fatores como perdas de dados e coisas como performance (que se considerarmos que estamos usando java e acessando uma lib c++ está dentro do aceitável), enfim coisas que até hoje não tinha observado.

black_fire:

Fala ae pessoal, blz.
A muito tempo não passo por aqui, madar um super abraço para os velhos amigos…

Estou migrando uma aplicação de Java para C++, como sei que isso vai dar mais que um único post
resolvi criar um blog para isso…

Quem tiver interesse em acompanhar o andamento dessa migração, segue abaixo o link do blog:

Moderadores, minha intenção é apenas compartilhar o estudo.

Grande abraço a todos.

Espero que tenhas uma boa razão para esta migração, porque senao podera ser esforço em vão e perda de performance e perda de portabilidade, e milhares de linhas de codigos a mais…
mas boa sorte, nao entendo porque que ainda tem pessoas que querem trocar um BMW X6 com um BMW X0

sulito:

Espero que tenhas uma boa razão para esta migração, porque senao podera ser esforço em vão e perda de performance e perda de portabilidade, e milhares de linhas de codigos a mais…
mas boa sorte, nao entendo porque que ainda tem pessoas que querem trocar um BMW X6 com um BMW X0

As razões estão escritas no blog dele:

• Necessidade de controle fino sobre portas seriais;
• Necessidade de integração com recursos do SO;
• Necessidade de rodar em computadores bem modestos;

Nenhum dos três atributos são muito bem atendidos pelo Java.

Novo post incluído no blog,
.
Primeira Aplicação - Ferramenta SQL em QT