Salut,
 
J'ai un type, que nous appelerons TMonBeauTableau, qui est un tableau dynamique de string :  
 

 
J'ai une procédure, que nous appelerons MaBelleFonction, qui prend un paramètre de type TMonBeauTableau, de type nul par défaut :  
 

 
Ma question : comment appeler cette procédure en initialisant le paramètre tableau directement au moment de l'appel (comme cela est possible avec un tableau à taille fixe ?
 
En gros, là je suis obligé de faire :  
 

 
Or, je voudrais faire quelque chose comme :
 

 
Mais ..... comme je suis un gros boulet je n'y arrive pas
 
Merci pour votre aide =)
 

Et si tu mets "array of string" plutôt qu'un type prédéfini ?
S'il n'accepte pas le nil, ce qui est bien possible, tu peux mettre [] (tableau vide) à la place normalement

 
Salut, merci pour ta réponse.
 
En fait, j'ai deux possibilités :  
 
1) Utiliser un type maison, TMonBeauTableau. Dans ce cas :
- Je peux affecter une valeur par défaut à un paramètre de ce type (mais en utilisant nil, et non [])
- Je ne peux pas construire 'dynamiquement' un paramètre de ce type lors de l'appel à une fonction
 
2) Utiliser un type de base non redéfini (array of string). Dans ce cas !
- Je ne peux plus affecter de valeur par défaut à un paramètre de ce type, que ce soit via nil ou []
- Je peux construire dynamiquement un paramètre de ce type quand j'appelle ma procédure
 
Bref - pas moyen d'avoir le beurre et l'argent du beurre ?

En y repensant, j'ai dû avoir ce problème aussi.
Deux solutions :
- passer "manuellement" un tableau vide [] plutôt que de pouvoir appeler la fonction sans paramètre
- faire une seconde fonction (overload) qui a le même nom mais pas de paramètre, et qui appelle la première en passant nil ou [] si veux avoir un seul endroit où cette valeur vide est définie.

 
Oui tout à fait, actuellement je me suis rabattu sur cette seconde solution. Mais je ne comprends pas qu'en faisant :  
 

 
On n'ait ces différences bizarres de comportement suivant qu'une variable ou un paramètre est déclaré(e) en tant que TMonBeauType ou en tant qu'array of string...  
 
Bref tant pis, et merci de t'être penché sur mon problème en tout cas !  

Delphi est assez strict avec les types.
 
Il me semble qu'il y a un truc de ce genre :
 
var
  a: array of string;
  b: array of string;
 
a et b ne sont pas du même type
 
var
  a, b: array of string;
 
a et b sont du même type
 

 
Hmm tu es sûr ?
 
J'aurais plutôt dit :  
 

 
Non ?
 
Enfin bref, le Pascal Objet est du genre super typé - on est bien d'accord

 
"a := b" ça passe, "a := c" donne "[Error] Unit1.pas(32): Incompatible types"

 
Ha oui au temps pour moi : tu as parfaitement raison - d'ailleurs j'imagine que c'est pour ça qu'il est toujours conseillé de définir ses propres types personnalisés, non ?
 
(bon sauf que dans mon cas, je suis justement obligé d'utiliser un type de base ... )
 
Mais merci pour cette précision

 
C'est vrai que ça permet de rendre le code plus clair et parfois d'éviter des erreurs.
 
Il vaut par exemple mieux utiliser des énumérations que des entiers pour des paramètres, pour éviter les erreurs (d'ailleurs Delphi est bien à ce niveau : on ne risque pas d'accidentellement mettre une valeur d'une enum à la place d'une valeur d'une autre enum comme on le ferait en C).
 
Ça permet aussi de changer facilement un type, genre si on utilise TYear au lieu de Byte, quand on se rend compte que les années peuvent s'écrire sur 4 chiffres on change le type de TYear plutôt que de devoir aller le changer partout dans le code (exemple bidon car ce n'est pas toujours si simple, mais tu vois où je veux en venir).
 
Mais d'un autre côté avoir des dizaines de types à soi c'est un truc pour s'embrouiller