encore microsoft.... - Page 6

Miles
: Ouais, enfin, je ne sais si j'ai envie de tester le GCC3.3.x si le problème que j'ai rencontré n'a pas été corrigé - c'est à dire le travail sur des structures interfaces virtuelles non explicitement définies dans le code lui-même,

Comment peux-tu savoir que le problème n'a pas été corrigé sans tester? As-tu ouvert un bug report? (Chose que tu es d'ailleurs censée faire...)

même si je pense que c'est très réducteur par rapport au problème en lui-même qui pourrait simplement être un problème de compatibilité -

Le fait de lire "problème de compatibilité" m'a rappelé un truc: As-tu essayé -fms-extensions?

snow-tiger :
extern "HS" {
(HEIN KEVIN, FAUDRAIT L'IMPLEMENTER LE C++ !!!!!!!!!!!!!!!!!!!!!!!!!!!!) }

extern "HS" {
1. Arrête de GUEULER!
2. Le C++ est trop inefficace pour une calculatrice.
3. Ça ne te servirait pas à grand chose, parce que les headers TIGCCLIB ne sont pas compatibles C++ (utilisation d'extensions gérées par le frontend C seulement, utilisation de macros qui ne respectent pas les namespaces, ...).
}

Pour VB, VB5 Professional/Enterprise et VB6 peuvent compiler en natif.

extern "HS" {
1. Arrête de GUEULER!
2. Le C++ est trop inefficace pour une calculatrice.
3. Ça ne te servirait pas à grand chose, parce que les headers TIGCCLIB ne sont pas compatibles C++ (utilisation d'extensions gérées par le frontend C seulement, utilisation de macros qui ne respectent pas les namespaces, ...).
}

C++ sur calto LOL et pourquoi pas un sgbdr et un client-serveur transactionnel tant qu'on y est ?... le C est très bien sur calto, je vois pas l'intérêt de l'alourdir inutilement, K² à 200% raison...

Pour VB, VB5 Professional/Enterprise et VB6 peuvent compiler en natif.

petit bémol pour certaines config (aussi bien vb5 que 6) la compilation en natif est parfois quelque peu douteuse (surtout quand on se met à utiliser beaucoup d'appels à des DLLs non-M$...)

extern "HS" {

Kevin Kofler
:

snow-tiger :
extern "HS" {
(HEIN KEVIN, FAUDRAIT L'IMPLEMENTER LE C++ !!!!!!!!!!!!!!!!!!!!!!!!!!!!) }

2. Le C++ est trop inefficace pour une calculatrice.

D'ailleurs ça me rappelle une suggestion de Thibaut d'il y a un mois ou deux, à laquelle je ne pouvais pas répondre puisque je n'avais pas encore programmé en C++, mais maintenant je pense que je sais à peu près de quoi je parle, même si je suis loin de maîtriser.

Je suis relativement d'accord avec Kevin, dans le sens où le C++ encourage des constructions très très lourdes à implémenter (notamment 'string', etc...), et qui non seulement seraient assez inefficaces en vitesse (mais ce n'est pas forcément un problème, puisque c'est quand même très pratique de pouvoir utiliser des std::string ou des std::vector dans un endroit du prog où la vitesse n'est pas critique), mais surtout affreusement grosses... A la limite, on pourrait avoir un compilo C++ qui génère un code à la fois natif (pour le code critique, mais il faut évidemment que le programmeur sache parfaitement ce qu'il fait, sinon on se retrouve avec un code 10x plus lent que du C), et interprété (code d'initialisation, communication, etc... le tout avec des demandes en mémoire assez faibles) Le problème c'est que ça demanderait un boulot gigantesque, puisqu'il faudrait le compilo C++, le backend pour l'interpréteur, et l'interpréteur (et dans ce cas-là, autant utiliser GT-Basic )

De toute façon, je n'implémenterai pas le C++ on-calc pour la bonne et simple raison que son parsing est bien plus lent (compilation en deux passes....), et aussi parce que ça impliquerait de devoir complètement changer le format de headers compressés, pour gérer les templates, la pré-compilation des classes (on ne peut pas se permettre de parser toutes les classes de la hiérarchie dès qu'on utilise une classe donnée, sans compter qu'il faudrait aussi parser les fonctions inline, donc pour l'éviter, il faudrait pouvoir dumper ça dans les headers, etc... => bref, gigantesque).

Et contrairement à ce que disait snow-tiger dans un topic d'il y a pas lgtps (je crois que c'était lui, mais je me trompe peut-être), un compilo C++ est loin d'être trivial à implémenter : par exemple, toute la gestion des exceptions est assez compliquée : quand on lance une exception, il faut détruire les objets alloués par les fonctions sur la pile, avec tout ce que ça implique... Et je ne parle même pas des template et de la spécialisation de template

Et enfin pour avoir un compilo C++ potable il faudrait avoir la STL, qui est elle aussi gigantesque (donc pas question de la faire tenir on-calc).

}

A propos du framework.net :


Il faut savoir que le framework est plus ou moins la meme chose que les MFCs a pars que se n'est encore installé en standard sur aucun OS gd publique.

Pour se qui est de la "compilation" que fait VS.net (MSIL quoi) il faut savoir qu'il s'agit d'une forme de pCode, permetant d'avoie une appli au format MSIL et de la faire fonctionner sur n'importe quel OS ayant un framework compatible. Et chaque appli non compilé en native (oui c'est possible avec n'importe quel language de VS.net de compiler en natif) une "re"compilation en natif est effectué avant l'execution. donc.

Et il y a une superbe DLL à inclure dans le déploiement - mais comme on peut générer automatiquement un setup, c'est impeccable -

Pour Kevin : j'ai déjà assez de mal à comprendre les makefile... alors rajouter des options alors que le projet devait être importé correctement par l'IDE DevC++, j'en ai eu marre - j'ai tout essayer au nveau du code, enfin tout ce qui était faisable sans détruire ce que faisait l'appli -
En revanche, il est possible qu'on se repenche sur le problème assez rapidement.

Pour VB, VB5 Professional/Enterprise et VB6 peuvent compiler en natif.

Ah, ben me semblait bien que seuls les vieux VB avaient besoin de tout un fatras à la con pour marcher.

Le C++ est trop inefficace pour une calculatrice.

Tout est relatif. J'ai jamais demandé de faire Chrono Fantasy en C++.
Mais ça serait simpa de l'avoir, juste comme ça. Les améliorations par rapport au C sont quand même loin
d'être négligeable. Et au pire comme je te l'avais dit.... Objective C ?

Au fait Kevin, mais comment vous compilez le GCC pour Windows ????

n'importe quel OS ayant un framework compatible

Windows, quoi
Enfin, il paraît qu'il y en a pas mal dans le monde Linunix qui pensent que c'est juste un effet de mode et que de toute façon, rien ne vaut un bon vieux code source en C ou en autre chose Donc peut-être qu'il ne faut pas s'attendre à avoir un support monstrueux pour le .NET? En tout cas, certainement pas avant qu'il n'y ait de "vraies" apps pour .NET (s'il y en a un jour ), et dans ce cas là Linux aura une longueur de retard sur Windows...

Miles>
C'est seulement une DLL? Je pense que c'est le gros framework qu'il faut inclure à chaque fois, donc si c'est le cas, tant que .NET n'est pas généralisé, c'est pas top pour faire des petites apps (imaginez, une app de 500 ko pour laquelle il faut télécharger un framework de 50 Mo )

snow-tiger> Ils utilisent mingw je crois.

-- snow tiger --
Mais ça serait simpa de l'avoir, juste comme ça. Les améliorations par rapport au C sont quand même loin d'être négligeable. Et au pire comme je te l'avais dit.... Objective C ?

Bah non, juste comme ça, ça suffit pas pour un tel investissement.

Pollux> Pour le source C, je suis assez d'accord... pour faire "djeunz", à l'IUT, ils ont abandonné le C/C++ pour le Java. Résultat, personne l'utilise le Java : trop lourd, ça a maintenant les mêmes défauts que le C (pas aussi portable que prévu ), pas utilisé pour l'embarqué et la programmation de PICs... résultat, j'ai toute une culture C à me refaire tout seul :/.

Bah non, juste comme ça, ça suffit pas pour un tel investissement.

Je savais qu'on allait me reprendre sur le "juste come ça" (Fait chier) et j'ai expliqué juste après les raisons valant cet investissement.

Pollux > Je connait rien dessus, sauf que Dev-C++ l'utilise... C'est une lib, mais elle fait quoi ?

Bah non, juste comme ça, ça suffit pas pour un tel investissement.

Clair...

lourd, ça a maintenant les mêmes défauts que le C (pas aussi portable que prévu )

Dans quel sens? En tout cas c'est évident que sur les machines à faible qté de RAM ou avec un CPU pas terrible ce n'est pas du tout adapté, mais pour le reste?

pas utilisé pour l'embarqué et la programmation de PICs

Oui, dans ce cas là rien ne remplace le C ou l'ASM. Mais dans 10 (ou 20) ans, est-ce que ça existera encore? On aura certainement des mini-processeurs à plus de 100 MHz avec des dizaines de Mo de RAM intégrés pour un prix/une consommation/une taille équivalente à un PIC, donc le PIC, rien à foutre... Je pense que les écoles sont quand même plus dans une perspective de long terme. Mais c'est vrai que c'est important de connaître le C (ou l'ASM), rien que pour savoir "comment ça marche" à l'intérieur de la boîte noire qu'est la VM Java...

bah là où ils pensaient faire #tada# avec java c'est la programmation graphique qui a gagné... surtout les pics, pour lesquels sont sortis des logiciels permettant de câbler des circuits logique graphiquement et qui sort la matrice au format RAW à envoyer sur la puce...

c'est tiptop pour les électroniciens non informaticiens...

Lourd dans le sens ou t'as besoin d'une VM, donc t'es pas en natif, donc tu charges un module supplémentaire qui ne fait qu'interpreter (enfin, c'est déjà mieux que du basic interprété direct depuis le code). Tu peux dire qu'on peut faire des programmes java autonomes, mais du fait qu'ils utilisent plus que souvent une API spécifique, ça fait ça du plus à charger sur le système :/.
Portable : ben même problème que le C : il existe des bibliothèques java qu'on ne trouve que sur une platefrome (ou pas dans les mêmes versions suivant les plateformes)... et même comble du comble, quand je travaillais en Java 1.2.1, la gestion des coordonnées dans les frames était inversée sous Linux et sous Windows (un partait en haut à gauche, et l'autre en bas à gauche ).

Euh désolé je ne voulais pas copier-coller "lourd" (sinon je l'aurais aussi fait pour "trop" )

il existe des bibliothèques java qu'on ne trouve que sur une platefrome (ou pas dans les mêmes versions suivant les plateformes)...

Cite-moi un seul langage où il n'y a pas ces problèmes...

la gestion des coordonnées dans les frames était inversée sous Linux et sous Windows

ça c'est con

vince > Mais Java ils l'ont fait comme des aussi...

tous > Ben on devrait pas dire que le C++ n'irait pas du tout sur caltos tant qu'on a pas essayé.

Et malgré l'investissement je serais bien prêt à essayer, justement (Si je savais compiler le GCC pour Win, d'abord,
et que je trouvais les bonnes sources pour cible 68000, d'autre part. Puis modifications et bidouilles, 5 ans passent,
je sors de ma chambre, barbu, et je vous dis soit CRAAAAACK ça marche c'est trop FORT , soit "5 ans pour rien....

Cite-moi un seul langage où il n'y a pas ces problèmes...

Bah oui, bien sur, mais à l'origine, le Java, c'était universel, magique, formidable, standard... c'était une remise à 0 du C++ en partant sur des bases saines... pis ça finit moyen, je trouve (entre les fonctions deprecated parce que le travail de fond a mal été fait et cet problèmes de librairies, ça perd beaucoup de ses atouts).

Nil > Je suis parfaitement d'accord.

Entre Sun et Sux, de toute manière...

Evidemment, c'est pas "magique"... D'ailleurs je pense qu'il faudra s'attendre à un truc du même genre pour le C#, dans quelques années

Mais pas tout de suite

Normal, ça marche que sous Windows, donc il risque pas d'y avoir de problèmes de portabilité

Pollux :
Euh désolé je ne voulais pas copier-coller "lourd" (sinon je l'aurais aussi fait pour "trop" )

il existe des bibliothèques java qu'on ne trouve que sur une platefrome (ou pas dans les mêmes versions suivant les plateformes)...

Cite-moi un seul langage où il n'y a pas ces problèmes...

NCL (utilisé sous natstar ou nsdk, les agl de cognicase, récemment racheté par salomé engineering...)

je bosse là dessus au taf, si c'est programmé à peu près proprement ton source (sous forme de dictionnaire et de logs) est lisible et compilable sous tous les os (enfin les plus utilisés...) et les applis générées sont semblables et auront un fonctionnement identique (d'autant plus vrai que la plus part des traitements spécifiques sont en RPC)

Pollux :
Normal, ça marche que sous Windows, donc il risque pas d'y avoir de problèmes de portabilité

Mais pas du tout cher monsieur, ici la portabilité prime grâce au tout
nouveau Microsoft .NET Framework; Avec, on pourra bénéficier
d'un langage portable sur... ...pas portable, ni compilé en natif.
Original, n'est-ce pas ? Et surtout, méga-performant.

En fait y'a des mecs qui font un portage Linux, ça marche mais c'est rudimentaire,
rien à voir avec Java qui est pourtant la cible principale (Tiens, pourquoi la Java VM est plus
incluse dans Ouin-dose eXPire ? Mikrokoft s'est faché avec Soleil on dirait... )

ça fait un bon moment qu'ils sont fachés, fo se tenir au courant ...

Je sais, je sais, je m'amusais à l'écrire d'une façon style LouisXIV.

Amusant, amusant....

C'est à LouisXIV qu'il faut le dire, pas à moi.

snow-tiger
:

Pour VB, VB5 Professional/Enterprise et VB6 peuvent compiler en natif.

Ah, ben me semblait bien que seuls les vieux VB avaient besoin de tout un fatras à la con pour marcher.

C'est le cas. Même compilé en natif, un programme VB a toujours besoin de MSVBVM??.DLL et tout ce qui va avec.

Au fait Kevin, mais comment vous compilez le GCC pour Windows ????

http://www.mingw.org
Il faut des binaires de GCC pour pouvoir compiler la source de GCC.
Si tu veux les instructions ligne par ligne, je peux te les donner.

Pollux
:

n'importe quel OS ayant un framework compatible

Windows, quoi

http://www.go-mono.com

"compatible" sous-entend complètement compatible. Je ne sais pas s'il y a bcp de programmes qui s'exécutent "out-of-the-box" sous Mono... (sauf ceux qui ont été spécialement prévus pour, évidemment, comme leur compilo C#)

ça ressemble à quoi au juste le "do dièse" (quel super jeu de mots ) ?

ouéééééééé