| Autor |
Mensagem |
|
|
|
o qt usa o mingw tmb. Além de ser usado pra desenvolver para dispositivo movel, embutido, e o proprio kde(e tudo mais que tem nele).
|
 |
|
|
Larga mão de Visual C++ e Netbeans. O netbeans só vai funcionar com cygnus. Use esta ferramenta:
www.qtsoftware.com/products/
Tem um framework totalmente orientado a objetos. Hoje o mercado usa mais ela que MSVisual C++.
|
|
|
|
Diabo Loiro wrote:entao cara precizo implementar isso em C nao tem buble sort nen string na verdade precizo trabalhar com ints e funcçao recusiva
Bubble Sort é um algoritmo de ordenação. Vc pode implementar em qualquer linguagem. Mas o correto seria um algoritmo de combinação.
Sobre strings, em c é um ponteiro pra um char
char *gols=null;
|
|
|
|
|
Isso pode ser resolvido com estatística(combinação,), para se achar as possíveis combinações de gols. Entra no www.4shared.com e procura uma apostila de estatística.
|
|
|
|
|
Convenção de Nomes é uma solução ótima. Boa parte da degradação do código se deve ao mal uso de nomes de variáveis, classes, etc....
|
|
|
|
rubinelli wrote:Ah não. Nem tudo é relativo. Até aceito que normalmente existem N soluções boas, agora se o colega do Vinicius insiste em usar uma das N^3 soluções que só pioram o problema, uma providência tem que ser tomada. É claro que, se você acabou de chegar e já está descendo o sarrafo, vai ficar tachado de chato, de pretensioso. Por isso que tem que ir na manha, comendo pelas beiradas, ou então fazer a trouxa e cair fora. Agora ninguém aqui é babá pra ficar limpando caca dos outros.
Se você é profissional, então é obrigado a seguir padrão, simples assim. Imagina se todo piloto resolvesse pousar o avião a seu modo? Ainda mais hoje em dia, que a IDE já vai completando pra você, dá mais trabalho fazer fora do padrão do que segui-lo.
A questão não é ser "tachado" de pretensiovo. Você estará sendo pretencioso. Criticar o trabalho de um colega não é uma coisa bem vista em lugar algum, e pode ser ainda, que o trabalho dele seja melhor que o seu usando determinadas metodologias. O correto seria sentar e chegar a um consenso.(deixo claro que não estou pregando desorganização, e sim comunicação).
|
|
|
|
Olha, estive nessa situação, mas comigo é um pouco diferente. Acho que estou no lugar do seu colega de trabalho. rs
Dizer que o trabalho do seu colega não é adequado não é e nem será conveniente.
Sobre padrões, ninguém é obrigado a usar. O código pode ser legível e fácil de se manter, mesmo sem eles.
Também conta, que, você está acostumado a codificar de uma maneira, e ele de outra(mas isso não quer dizer, que você é melhor que ele ou vice-versa).
A melhor maneira de resolver esses problemas de comunicação, é sentar e expor opiniões.
Nós nos expressamos e pensamos de maneiras diferentes, e isso não quer dizer que temos de ter a razão.
|
|
|
|
Giulliano wrote:Olha...até onde eu entendi o JSR 927 é oficial. Como dito na própria página.
This is an updated version of the Final Release of this Specification, as described in Section 4.2.1 of the Java Community ProcessSM Program, version 2.6.
Nosso midleware não é 100% brasileiro. Isso foi uma parceria entre Japão e Brasil. Diferente do midleware que roda na Europa e que não é tão maleável como o que foi criado aqui.
A idéia é padronizar esse conceito para toda a América e não só Brasil. O que expande o mercado para nós. E ao mesmo tempo abre barreiras para empresas estrangeiras.
Sim, mas é algo assim você assina em baixo sem saber o que espera por você.
Se eu escrevo, eu assino embaixo.
Pra falar a verdade, o ginga é bem menos brasileiro do que se pensa. O projeto tv digital do brasil foi alvo de política do governo, e até de certas emissoras. O Brasil tem um projeto do seu proprio padrão de TV digital(Tecnologia Própria, que é muito superior ao europeu, e ao japonês). Mas por força política, foi implantado o padrão japonês.
|
|
|
|
|
O seu contrato deve especificar que o produto é propriedade da empresa. Pra poder colocar o seu nome como autor, deve procurar um instituto de pesquisa. Mas ae vai ter que virar Mestre ou Doutor.
|
|
|
|
|
Alguém conhece uma boa implementação de uma pilha rtp? Já tentei usar jmf, mas não ficou legal. Preciso enviar imagens 32 câmeras pela rede, sendo estas 320x240. Meu maior problema é performance. Se alguém já teve o mesmo problema, poderia me ajudar?
|
|
|
|
|
larga mão de tendência. Esse tipo de coisa não vai te dar dinheiro nem conhecimento.
|
|
|
|
Tem o source dos applets ae tmb
http://homepages.inf.ed.ac.uk/rbf/HIPR2/wksheets.htm
|
|
|
|
louds wrote:
Java é até hoje o patinho feito quando o assunto é, por exemplo, escrever uma aplicação integrada
ao desktop. Enquanto o AWT foi um enorme fracasso, o Swing tomou proporções épicas. Enquanto com
a CLR é possível fazer o binding de uma API escrita com C em poucos minutos, com Java leva uma semana.
Só comparar, por exemplo, os bindings para QT, KDE, GNOME e GTK+ para Java e Mono. Os do Java são
continuam uma piada. E a Java-ObjC bridge? Uma porcaria. Para o Mono existem 4 projetos distintos de binding.
Porém isso não se limita a aplicações desktop. Embutir Java dentro de outras aplicações é um sofrimento tão grande
por conta do JNI que ninguém mais tenta.
Essa atitude altista por parte da Sun limitou em muito o alcance da plataforma de forma que hoje é basicamente financeiramente
inviável inovar com ela. Basta ver que as principais plataformas lançadas nos últimos 3 anos (PS3, XBOX360, Wii, iPhone) não existe
nem sinal de rodarem Java.
Por fim, argumentar que essa decisão foi tomada pensando no melhor para os desenvolvedores pois alguns poderiam abusar disso é
muita condescendência, infantilização, mas também tratá-los por estúpidos. Foi uma decisão errada e o Stanford Ego prevaleceu.
Tem razão. Vem sendo um sacrifício enorme desenvolver determinadas aplicações, em conjunto com a engenharia eletrica, justamente por causa da dificuldade do jni. Como foi dito num post, existe o recurso do jna. Mas mesmo assim, ainda complica em relação ao pinvoke c#. A equipe da sun deveria rever alguns recursos da linguagem realmente.
Eu até desejaria um byte não sinalizado. Mas é uma opinião pessoal.
|
|
|
|
A proporção dos profissionais que escrevem c ou c++ é enorme. São eles que escrevem sistemas operacionais e a maioria da tecnologia, e apis que vc usa. É só olhar no www.codeproject.com e no www.sourceforge.net.
Se vc não precisa codificar em c ou assembly hoje, e achava ruim, é o seu gosto. Mas é inegável a necessidade delas no dia a dia de certas áreas.
Eu não sinto nenhuma dificuldade de usar assembly, c ou pascal, nem teho nada contra. Eles são necessários para resolver meus problemas.
O JNA é um recurso muito bom que implementaram, mas ainda está longe do pinvoke do c#, fora unsafe.
|
|
|
|
|
Não podemos generalizar isso, porque todos nós aqui trabalhamos em áreas diferentes. JNI não é questão de performance. Onde eu trabalho desenvolvemos aplicações de segurança. Essas aplicações precisam se comunicar com hardware, então a dificuldade do JNI me atrapalha muito. Tenho usado muito mais c# devido ao tempo que levo em escrever o equivalente a jni.
|
|
|
|