Discussion :

[rolkA]

Je suis tout à fait d'accord et je ne vois pas ce que viendrait faire VisualC++ dans les vrais outils RAD comme Delphi ou Windev.

Confonds pas "RAD" au sens strict du niveau d'assistance du RAD en question... C'est sûr que Delphi ou WinDev génèrent bien plus de code que Visual C++, mais quoi qu'il en soit, ce dernier est bien un RAD malgré tout : cf. les Wizards "New MFC Application", "Insert new class", "Insert new form", etc...

On joue sur le sens du mot "Rapid" dans "Rapid Application Developpement"
Car les taches que tu m'a citées sont + des modèles paramètrables je trouve, non ?

[Mac LAK]

On joue sur le sens du mot "Rapid" dans "Rapid Application Developpement"

Oui et non : non, parceque le terme "RAD" regroupe tout ce qui accélère le développement, le "facteur" d'accélération n'étant pas précisé particulièrement. En général, ça sous-entend soit que l'on fait les choses d'une autre manière (dessiner une fiche graphiquement plutôt que de calculer les positions des contrôles sur une grille), soit que l'environnement génère une partie du code pour toi.
Et oui, parceque le terme "Rapid" ici ne signifie plus grand-chose, tout comme le "multi" de "multimédia" : c'est devenu un terme général, même s'il n'est plus tout à fait exact. C'est pas la première fois que ça arrive en informatique.

Car les taches que tu m'a citées sont + des modèles paramètrables je trouve, non ?

Et que fais donc Delphi, par exemple, lorsque tu demandes à insérer un nouveau thread dans l'application, si ce n'est pas une application d'un modèle paramétrable ? ;-)
Il y a un peu plus de paramètres, ou un peu plus de complétude, mais c'est tout : ça ne change pas fondamentalement le principe du RAD, qui est finalement le même pour Delphi ou pour Visual C++.
La différence entre les deux est que Delphi te génère du code de "comportement habituel", alors que Visual te génère du code de "minimum requis", mais c'est lié à l'orientation choisie par les éditeurs pour chacun de ces deux compilateurs.

[rolkA]

Car les taches que tu m'a citées sont + des modèles paramètrables je trouve, non ?

Et que fais donc Delphi, par exemple, lorsque tu demandes à insérer un nouveau thread dans l'application, si ce n'est pas une application d'un modèle paramétrable ? ;-)
Il y a un peu plus de paramètres, ou un peu plus de complétude, mais c'est tout : ça ne change pas fondamentalement le principe du RAD, qui est finalement le même pour Delphi ou pour Visual C++.
La différence entre les deux est que Delphi te génère du code de "comportement habituel", alors que Visual te génère du code de "minimum requis", mais c'est lié à l'orientation choisie par les éditeurs pour chacun de ces deux compilateurs.

[En parlant de prog Win32: ]
Mais Delphi utilise une Bibliothèque propriétaire ! Quand tu utilise la VCL, avec C++Builder, c'est çà pour moi le vrai RAD: çà ne génère pas de code MFC ou Win32 dans ton code... Ce n'est donc pas du "modèle paramètrable", c'est une vraie bibliothèque à part entière... Et c'est elle qui accélère énormément le développement. Entre autres. C'est à dire que C++Builder ne crée pas de code MFC ou Win32 à partir d'un assisant. non, c'est bien plus que çà: On utilise directement la VCL ! C'est comme entre l'assembleur et le C: Tu utilise directement les fonctions du langage C et tu ne t'occupe jamais de comment çà se passe en interne. Le comparaison est un peu limite mais c'est simplement pour essayer de faire comprendre ce que je veux dire

EDIT: Encore dit autrement: Quand on programme avec VisualC++ on doit connaître les MFC et/ou Win32 (je parle pas de .NET qui est encore hors-sujet dans ce que je dis car je connais pas donc j'avance rien). Alors qu'avec Delphi, C++Builder, WinDev... On y touche pas.

EDIT: Encore une précision: Par exemple pour manipuler des chaînes on utilise une classe AnsiString dans C++Builder, pas CString. On veut une liste de chaîne ? pas de problème, une calsse TStringList permet de gérer çà avec un temps de développement record et des très nombreuses fonctionnalités réduisant la quantité de code à taper. Ce ne sont que deux exemples parmi tant d'autres améliorant au final le temps de développement => RAD. Or les MFC sont disponbiles sans VisualC++: ce n'est pas propre à VisualC++, d'où mon avis sur le coté non-RAD de Visual C++ (mais IDE poussé et complet, là oui). Je ne parlait donc pas simplement des wiazrds de création de projet ou de positionnement d'objets visuels.

[Mac LAK]

ça ne génère pas de code MFC ou Win32 dans ton code...

Pas de MFC, en effet (cf. plus bas). Mais du code Win32, ça en génère à la pelle !!!

Ce n'est donc pas du "modèle paramètrable", c'est une vraie bibliothèque à part entière...

Non. C'est bien une bibliothèque, mais au dessus de Win32. Quant au modèle paramétrable, demande à insérer un nouveau thread : il va te demander le nom de classe, le nom du thread et écrire dans le source :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{ MonNomDeClasse }

procedure MonNomDeClasse.SetName;
{$IFDEF MSWINDOWS}
var
  ThreadNameInfo: TThreadNameInfo;
{$ENDIF}
begin
{$IFDEF MSWINDOWS}
  ThreadNameInfo.FType := $1000;
  ThreadNameInfo.FName := 'MonNomDeThread';
  ThreadNameInfo.FThreadID := $FFFFFFFF;
  ThreadNameInfo.FFlags := 0;

  try
    RaiseException( $406D1388, 0, sizeof(ThreadNameInfo) div sizeof(LongWord), @ThreadNameInfo );
  except
  end;
{$ENDIF}
end;

Si ça, c'est pas un modèle paramétré, je suis un moine !

EDIT: Encore dit autrement: Quand on programme avec VisualC++ on doit connaître les MFC et/ou Win32 (je parle pas de .NET qui est encore hors-sujet dans ce que je dis car je connais pas donc j'avance rien). Alors qu'avec Delphi, C++Builder, WinDev... On y touche pas.

MFC est une surcouche partielle de Win32, tout comme la VCL. C'est donc "MFC et Win32" ou "Win32" tout court.
MFC vs. VCL : les deux API ont une complexité similaire, tout comme leur domaine d'application. De même qu'utiliser la VCL à partir de Visual C++ serait infernal, utiliser les MFC au sein de Delphi frise la folie furieuse : ces deux systèmes sont conçus pour un compilateur donné, l'utiliser en dehors n'est ni prévu, ni judicieux.

Quant à utiliser "seulement" la VCL sans toucher à Win32... On va dire que c'est possible tant que tu te contentes d'applications simples, voire primitives. Dès que tu commences à "jouer" un peu avec la VCL (notamment en créant tes propres composants), tu te rends vite compte que tu es tenu d'y toucher, et au minimum de savoir comment fonctionne Win32 dans l'ensemble.
Exemple : la fonction "Application.ProcessMessages", d'après toi, ça a quel rôle dans Delphi ? C'est quoi, ces "messages" dont t'abreuve l'OS ? ;-)
N'oublie pas que la VCL est construite et conçue pour (et sur) Win32 !!
Il n'y a justement qu'avec du code managé (.NET par exemple) que tu peux faire abstraction de l'API de l'OS. Sinon, dans un langage natif, tu dois toujours t'y plier à un moment ou à un autre... ou alors abandonner définitivement certaines possibilités. Va voir la FAQ Delphi sur la manière d'obtenir la liste de toutes les adresses IP d'une machine, tu verras un joli appel Win32 dedans, car c'est impossible à faire en VCL "pur" !!

AnsiString dans C++Builder, pas CString

Vrai. Mais t'as pas bien regardé comment est implémenté le type AnsiString en interne. Et le type CString est un très mauvais exemple : c'est justement une des classes MFC les plus "abstraites" et une des plus complètes, et tout comme AnsiString, elle se comporte de manière polymorphe vis-à-vis de l'API Win32.

améliorant au final le temps de développement => RAD

Oui, c'est ce que je te disais. Visual C++ améliore effectivement moins le temps de dev que BCB ou Delphi, mais par rapport à GCC/MinGW (qui possède au mieux un IDE), y'a pas photo : je sais lequel des deux est le plus lent. Visual C++ est bien un RAD.

MFC : Certes, elles existent en dehors de Visual C++. Essaie d'importer une classe C++ MFC exportée d'une DLL dans un autre compilateur que Visual C++, tu auras une bonne idée de ce qu'est le masochisme... ;-)

Bon, faudrait arrêter sur le sujet, ça dérive du topic initial, là... ;-) On peut continuer en MP si tu le désire, ou alors on ouvre un nouveau topic ?

[rolkA]

En effet on dérive assez du sujet initial donc je vais réagir par MP
Pour la création d'un topic à part je ne sais pas trop car c'est quand même, il faut l'avouer, un faux problème: tout tiens à la limite que l'on fait entre un IDE et un RAD