Salut,
 
Je voulais avoir un peu de renseignemtns sur le langage Delphi. Le titre de mon post pet paraitre curieux, mais en fait, je voulais savoir si Delphi était un langage "dans le vent", c'est à dire savoir s'il était beaucoup utilisé, et quels sont les intérêts qu'il peut apporter par rapport à d'autres langages plus traditionnels tels que C++ ou Java?
 
En fait, je connais pas mal ces deux derniers langages. Je vais avoir des choix technologiques à faire (choix de langage) et je me demandais si ça pouvait valoir le coupde mettre Delphi dans la course (dans quel contexte)
 
merci beaucoup, et désolé si ma question parait floue. Toute tentative de réponse (selon vos expériences et connaissancesà de votre part sera la bienvenue.

Delphi est pas mal pour le même type d'utilisation que VB 6 : des petits softs ou des trucs vite fait.
C'est un langage orienté objet, et on peut aussi faire des plus gros softs sans trop de problèmes.
Perso je trouve le Delphi/Pascal plus lisible que du C++, mais c'est peut-être juste une question d'habitude.
Pour tout ce qui est création d'interfaces utilisateur, Delphi avait de l'avance, mais avec VC++ 7 Microsoft a ratrappé ce retard.
Ce qui est pratique aussi c'est que ça compile vite, pas comme le C++

Donc, ça peut être intéressant d'apprendre le Delphi, c'est un langage quelque peu puissant pouvant servir à créer (tout comme VB/VBA) des applis assez rapidement (mais à qui il ne fo pas demander une très grande rapidité?)

Si, il est très rapide, c'est pas du VB hein

 
Si si, c'est à peu près aussi rapide que du C++.
Mais les librairies (VCL) sont plus "lourdes" que les MFC de Microsoft vu qu'elles sont beaucoup plus riches (enfin, vu que Microsoft a abandonné les MFC de toute façon...)

Ah bon? Microsoft a abandonné les MFC? En faveur de quoi? PArce que justement, chui un peu perdu avec les MFC, et j'arrive pas à trouver de bons tutoriaux ou bouquins à propos des MFC (à part les bouquins qui ne savent pas dire autre chose que comment utiliser les "Wizards" de Visual C++)

Maintenant c'est WinForms, avec .NET, non ?
Dans Visual Studio .NET

 
C'est pas notre avis a nous au boulot ! Une des principales raisons qui nous fait regreter de ne pas avoir choisi le C++ comme langage. L'optimiseur de code Delphi date de la prehistoire !!! Le manque d'inlining et de templates est très très très penalisant. A tel point que nous somme ammenés à faire de l'inlining à la main pour obtenir de bonnes perfs. Avec du calcul sur des pointeurs bien sur et vous savez à quel point les traitements sur des pointeurs sont lisibles en Delphi. Et je ne parle pas des perfs horribles en calcul sur des flottants.
 
Remarque, on gagnerais tout de suite un peu de perfs si on passait de Delphi 5 a Delphi 7

 
http://www.kkhec.ac.ir/Touska%20Fo [...] 20VC++.htm

 
maintenant que delphi se met à .net, ça vaut pu vraiment la peine de l'apprendre...
de plus tu connais très pas mal les deux langages les plus utilisé...

Et concernant les MFC, est ce que ca vaut le coup de les apprendre, ou alors je px directement me mettre au .NET?  
 
En tout cas, je ne sais aps où trouver de la bonne doc sur les MFC (ou un bon tutorial??)
 

 
oublie les mfc, je ne connais pas ton niveau... mais tu peux toujours te perfectionner à fond dans c++ et java

 
Génial, une comparaison Delphi 5/Visual C++ 6. J'en avais vu aucune encore.
 

 
C'est un gros ramassis de conneries ce truc !!! Evidement, dans des tests de perfs synthetique avec 2 fonctions : main et calcule, l'inlining n'apporte rien.
 
Tout ce que je dis au dessus, je l'ai experimenté moi même. L'absence d'inlining tue complètement les performances du code que l'on produit chez nous. Oui car nous fesons de la POO, avec des get et des set, des assert a tout bout de champ pour tester les paramètres, avec en général plein des fonctions de très petite taille qui passent leur temps à s'appeler les unes des autres.
 
Et je peux en ajouter d'autres sur Delphi 5 : les operations sur les flottants utilisent très mal les registres de la FPU. Entre chaque ligne de calcul flottant, Delphi extrait le résultat de la FPU pour le mettre dans une variable locale avant de le reinjecter à l'identique dans la FPU pour le calcul suivant. Bravo pour l'optimisation. A quoi cela sert donc d'avoir plusieurs registres flottants dans ce cas ?
 
Peut-être que ces problèmes viennent d'une mauvais utilisation de notre part ( encore que pour l'absence d'inlining ... ), mais il n'y avais écrit nulle part ce qu'il faut faire.
 
PS : je ne parle pas des très mauvaises perfs des operations sur les strings car de gros efforts on été fais dans Delphi 7
 
PPS : la verification des overflow sur les entiers, vous avez une idée sur comment Delphi fait ? Au hazard, en ajoutant entre chaque operation une verification des flags du CPU.

 
Je pense que j'ai un niveau honorable en C++ (je parle du langage, indépendemment de l'implémentation).
En Java, j'ai un niveau très basique. Je connais bien le langage de base, mais très peu les JFC
 
Je parlais de MFC, car je compte surtout programmer sous Windows, donc, ça passe nécessairtement (enfin, c'était ce que je croyais) par les MFC. Donc, c'est pour ça que j'aurais voulu acquérir des bases saines...

 
C'est l'option "overflow checking" ? pcq c'est désactiver par défaut et dans la doc ils disent que ça diminue les perfs.

 
Desactivé par défaut ? Ca veut dire que qq a fait l'effort de l'activer dans nos projets pour nous pourrir encore plus les perfs. Il faut donc que je fasse gaffe à ne pas insulter cette même personne sans m'en rendre compte un jour ou je serais un peut trop enervé contre les plantages qu'elle me cause

C'est pour du debug

 
Mais au fait, je peux donc utiliser l'instruction $Q- pour desactiver ce truc dans le code que je produis ! Chouette, plus de problème de overflow en vue   Par contre le range checking sur les array et les strings est très utile.
 
PS : ils ont oublié de parler du overflow checking sur shl. Celui-là est particulièrement lourd.

Bah suffit de désactiver l'option globalement dans le projet.
Normalement elle ne doit être activée que pour le debug.
Le range-checking sur les arrays et strings je n'en ai jamais eu besoin pour autre chose que pour trouver des bugs (tests insuffisants par ex)

 
Et moua, on m'oublie?  

 
Juste un conseil perso : evite les MFC comme la peste. Ces trucs sont un peu comme le coté obscur de la force, mais quand tu grattes un peu, tu te rends compte que tu est moins fort qu'avant et que tu ne peux pas revenir au coté lumineux
 
Appli C++ graphiques sous Windows ( par ordre de preference perso donc très subjectif ) =>
- QT
- wxWindows
- Borland C++ Builder
- .Net
 
A toi de choisir

 
Mais je ne comprends pas? Cette liste est une liste de différentes librairies graphiques qui permettent de faire des choses sous Windows indépendemment des MFC? Ou elles utilisent LES MFC, et ce sont des couches plus hautes?
 
Sinon, les MFC, ce ne sont pas que des librairies graphiques, n'est ce pas?
 
Enfin, le problème, c'est que les MFC sont souvent utilisées en milieu professionnel, donc, les ignorer constiturait pour moi une grave erreur...

Commence par apprendre à programmer des interfaces graphiques sans faire appel aux MFC et avec une vrai API de qualité. Après essaye les MFC pour comprendre à quel point ce truc est mal fichu. Si tu le fais dans l'autre sens tu risque de te rendre ridicule plus tard en disant que Visual C++ avec MFC est le meilleur IDE sous Windows pour faire des interfaces graphiques. On a eu un stagiare qui disait ça. Il disait aussi que toutes les implementations de malloc étaient buggées et qu'il fallait alouer au moins 3 octets de plus arrondi au multiple de 4 superrieur pour éviter les plantages.

"Commence par apprendre à programmer des interfaces graphiques"
 
Tu veux dire quoi par là?
Genre tracer des lignes en C???
 
Concernant les MFC, e sais déja faire pas mal de trucs, des petites appli maison, mais franchement, j'ai pas du tout l'impression de maitriser! Par exemple, j'ai du mal à comprendre comment est effectué l'enchainementdes appels lorsqu'une appli est ouvrte, etc... Bref, je suis un utilisateur de Wizards Visual C++, mais je n'ai pas une grnade connaissance de ce qu'il se passe en dessous

Interfaces graphiques : boites de dialogue, boutons, combo box, barres de defilement etc...
 
Vu ta situation, essaye wxWindows. QT est mieux mais il est payant sous Windows D'ailleurs, ces API ne sont pas limitées au interfaces : sockets, OpenGL, SQL. Tout ça est possible aussi et même de façon portable

 
les mfc c'est mort et ça ne sera pu utilisé avec .net
 
d'ailleur à quant un qt.net, wxwindows .net....

En fait, je crois que j'ai besoin d'une petite remise à niveau coté technologies.
 
MFC, c'est quoi? Est ce que c'est une librairie qui a été créée par Microsoft, et qui permet de faire appel à des fonctionnalités Windows de couche plus basse?
 
Si j'utilise WxWindow, est ce qu'il va y avoir des appels MFC sous jacents que je ne verrai pas? Ou alors, est ce que c'est totalement indépendant, et quelque part en "concurrence" avec les MFC?
 
Pour en revenir à wxWindow... Sous quel environneent vais je pouvoir les utiliser? Sous Visual, c'est OK?
 
Je sais que les MFC se trouvent sous forme d'une DLL, genre MFC42.dll! Pour Wc Window, ca marche comment? Les utilisateurs cible vont ils avoir besoin de posséder une Dll? ou alors vais je pouvoir l'inclure à chaque fois dans mes exécutables?
 
J'ai vraiment besoin d'être éclairé là! J'ai l'impression d'avoir plein de fausses idées...

Perso j'ai commencé à apprendre à programmer des interfaces graphiques avec l'API de Windows, puis je suis passé à C++Builder et Delphi (la VCL donc).
Par après quand j'ai dû utiliser les MFC je n'ai pas eu trop de problèmes.
Mais ne pas connaître le fonctionnement de l'API derrière des librairies plus évoluées comme la VCL est un manque je trouve.

franchement, delphi n'a strictement aucun intérêt, je vois pas pourquoi il est pas mort de sa belle mort, avec VB et les dinos qui l'utilisent encore.

 
parce que des gens t'ont vu et se sont dit "pour ne pas devenir comme lui, programmons dans d'autres langages que lui"

 
et quel langage à de l'intérêt?

Ada par exemple, qui possède un vrai système de types ou Eiffel qui propose des choses innovantes par les contrat, avec la preuve en route.
 
Mais c'est sûr qu'on est assez loin des trucs de dynos à ce niveau.

 
alors écrit à l'auteur et fait un prog avec vc++ et et delphi pour lui montrer qu'il a tord

 
tous des langages très utilisé
 
Ruby avec ça?

Si personne n'a la volonté de les utiliser, ils sont pas près d'être très utilisés. Pour l'instant seule une certaine élite les utilise, mais il faut arriver à convaincre les masses et là c'est plus dur.
 
Mais bon il y a 2 ans, les lecteurs MP3 étaient quasi inexistants et ils sont devenu l'objet à la mode de noel, donc les gens sont pas aussi cons que ce que toi, ils suivent aussi l'innovation de temps en temps.

Je crois que ce débat n'a pas vraiment lieu d'être...
 
Il fo savoir si on aime un langae parce qu'il respecte des contraintes que la plupart des théoriciens vont adorer (genre un typage béton) ou alors si on l'aime parce qu'il va être pratique, efficace et facile à utiliser!
 
Trouver LE langage qui satisfasse tout le monde, je ne pense pas que ce soit ne serait ce qu'envisageable!...
 
Alors, on stop les bla bla! Là, dans ma question, je parlais du coté pratique et efficace du langage, pas du coté théorique qui ferait plaisir aux profs d'info.

Et faire plaisir aux familles des victimes des choix du codeur ?
 
On ne peux pas augmenter la place de l'informatique et surtout l'interdépendance des systèmes sans prendre conscience de sa responsabilité individuelle. Quand le système croit, c'est le maillon le plus faible qui devient limitant, on arrive plus à rendre étanche les parties critiques et les autres.

Attends!
 
Je sais bien que si mon but est de programmer un systeme critique, devant etre totalement safe, alors j'irai plutot utiliser de l'Ada que du Java!
 
Mais là, ce n'est pas mon but, donc, je n'ai pas besoin d'un langage hyper strict, mais plutot d'un langage efficace. Tout est une question de contraintes, et trop de contraintes tuent l'efficacité! D'où l'intérêt d'avoir une pléthore de solutions différentes !

ok, je vois que tu sais lire. Tu voudrais pas faire un métier plus simple ?

une élite , n'importe quoi
 
ada à sorti en 1978 et Eiffel  1986
ça en prend des années avant d'être populaire
 
 

 
 
 
faudrait peut-être pensé à inover tes conneries connard