Discussion :

[Roland Chastain]

Bonjour !

J'ai une unité que j'ai voulu transformer en DLL et apparemment je m'y suis mal pris puisque le programme utilisant la DLL cesse de fonctionner au moment de se fermer. (Plus exactement, l'une des deux versions de ce programme, l'autre paraissant fonctionner normalement.) La fonction appelée reçoit comme paramètre une chaîne (entre autres) et renvoie une chaîne. J'ai fait quelques recherches sur le sujet et j'ai cru comprendre que c'est de là que venait le problème, mais je n'ai pas trouvé d'exemple qui colle exactement à mon cas.
Je voudrais, si possible, que ma DLL soit également compilable et utilisable avec Free Pascal. Pourriez-vous me mettre sur la voie de la solution la plus universelle, c'est-à-dire qui puisse fonctionner avec différents compilateurs, et éventuellement même me permettre d'utiliser ma DLL depuis un programme en C (si possible).
Voici l'en-tête de ma fonction. Je mets dans une pièce jointe tous les autres fichiers, y compris le résultat de mes essais avec différents compilateurs (Delphi 7, Delphi XE2, Free Pascal). Pour résumer, le chargement statique (j'espère ne pas dire de bêtise) fonctionne. C'est avec le chargement dynamique que l'erreur se produit. Par contre, avec Free Pascal, les deux versions plantent en cours de route. Mais si j'utilise directement l'unité qui est "derrière" la DLL, tout fonctionne correctement avec les trois compilateurs.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
library Matador;
 
{$IFDEF FPC}{$MODE DELPHI}{$ENDIF}
{$WARN SYMBOL_PLATFORM OFF}
 
uses
  SysUtils, MatadorCore;
 
function SolveMate(
  const aFen: string;
  const aMovesNumber: integer;
  const aSearchAllMoves: boolean
): string; export;

[Paul TOTH]

tu peux lire ce fil sur le problème que tu rencontres.

mais pour faire court, remplace tes String pas de PChar et tu seras compatible FreePascal et même tout autre lange de programmation. Le type String de Delphi implique l'usage du gestionnaire de mémoire de celui qui la crée, ce n'est donc pas une bonne idée de transmettre des Strings à une DLL

[Invité]

Bonjour,

je n'ai pas examiné votre code (question de temps ) mais d'une manière générale, je ne comprends pas* (plus) l'intérêt de créer une dll en Delphi/Lazarus pour l'utiliser... en Delphi/Lazarus. Ne serait-ce que pour simplifier les problèmes de compilation, la création et l'utilisation d'un composant à la place d'une dll sont nettement plus performantes. Les facilités de ré-employabilité et la réalisation d'éventuelles corrections immédiates de cette pseudo "dll" (i.e. le composant) directement à partir du projet, sous n'importe quel OS, sont d'un confort et d'une "productivité" (dirait Serge) incomparables... Je parle de Lazarus parce que je suis beaucoup moins convaincu par Delphi FMX (et pas du tout par Qt à ce niveau, parce qu'en ce domaine, la création et l'utilisation de composants personnels sont dans les faits quasiment inenvisageables)

Par contre (et pour rendre ce message un peu plus productif), j'utilise assez fréquemment en Windev des dll créées en Lazarus (avec source de 3 méthodes Lazarus appelées par Windev). On utilise également des pChar pour passer des chaînes. Entre 2 langages quand c'est possible (par exemple utiliser des bibliothèques C++ en Lazarus ne l'est pas... et c'est bien dommage !), cela présente en effet un intérêt. Mais quelle lourdeur !

En Lazarus attention à la déclaration des méthodes : stdcall vs cdecl.

---

*Il est vrai que si vous êtes sous Delphi, je considère que la facilité de mise en oeuvre des composants est nettement inférieure à celle de Lazarus. Alors peut-être que la dll est plus pratique à mettre en oeuvre au départ...

[Roland Chastain]

Merci pour vos réponses. Je vais donc regarder du côté des PChars.

@selzig

Merci pour le lien vers les exemples. A plus tard pour la suite de la discussion !

[Ph. B.]

Bonjour,

*Il est vrai que si vous êtes sous Delphi, je considère que la facilité de mise en oeuvre des composants est nettement inférieure à celle de Lazarus. Alors peut-être que la dll est plus pratique à mettre en oeuvre au départ...

Y aurait-il un contresens dans cette phrase ?
Utilisant les 2 environnements, passer d'un système de composants liés dynamiquement (Delphi) à un système de composants liés statiquement (Lazarus) est AMHA un inconvénient sérieux.

[Invité]

Bonjour,

Non, non, aucun contresens. Je ne parle pas de compilation mais de mise en oeuvre, de simplicité (d'environnement et de réalisation). Tout est dans les détails, certes. Mais les Lazarusiens sont très forts à ce niveau. C'est à peu près du même acabit que les ancrages des objets graphiques sur une Form. Quand on revient à Delphi, on trouve leur choix "inapproprié", lourd et maladroit... Quoiqu'il en soit, je fais avec. Il est vrai que ma référence à Lazarus est maladroite : les composants sont tout à fait (facilement) réalisables avec Delphi (y compris FMX), c'est une des premières choses que j'ai vérifiée en "reprenant" Delphi.

D'un autre côté, hormis pour le déploiement, où je privilégie la compilation statique (indispensable à mon avis en multi-OS), les 2 choix ont respectivement leurs avantages et leurs inconvénients. Et que ce soit Delphi et Lazarus, compiler un projet est extrêmement rapide (et simple).

[Roland Chastain]

Donc j'ai essayé de remplacé les strings par des pchars (ou plutôt par des pansichars, je pense que c'est le meilleur choix dans ce cas, non ?) et tout semble fonctionner. Enfin, tout fonctionne avec Delphi 7 et Free Pascal. Avec XE2, ça ne plante plus mais ça ne renvoie plus les bons résultats. Je suppose qu'il faut que je mette des ansistrings partout, mais j'aurais aimé avoir votre avis avant de me lancer à tout modifier.

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
library Matador;
 
{$WARN SYMBOL_PLATFORM OFF}
{$IFDEF FPC}{$MODE DELPHI}{$ENDIF}
 
uses
  SysUtils, MatadorCore;
 
function SolveMate(
  //const aFen: string;
  const aFen: pansichar;
  const aMovesNumber: integer;
  const aSearchAllMoves: boolean
//): string; export;
): pansichar; export;
var
  lMoveDepth: integer;
  lTurn: integer;
  lMove: TMoveRecord;
  lFen: ansistring;
begin
  //result := '';
  result := #0;
  lFen := aFen;
 
  //if InitializeGlobalPosition(aFen, lTurn) then
  if InitializeGlobalPosition(lFen, lTurn) then
  begin
    gNodes := 0;
 
    if SearchMate(
      lTurn,
      1,
      aMovesNumber,
      lMoveDepth,
      lMove,
      not aSearchAllMoves
    ) then
      //result := Concat(SquareToStr(lMove.sqFrom), SquareToStr(lMove.sqTo));
      result := pansichar(Concat(SquareToStr(lMove.sqFrom), SquareToStr(lMove.sqTo)));
  end;
end;

Remarquez que je n'emploie ni le mot-clé stdcall ni cdecl, mais simplement export : c'est comme ça qu'était fait l'exemple de DLL dont j'étais parti.

Autre chose, toujours dans l'idée de pouvoir utiliser ma DLL dans un programme écrit dans un autre langage (en C par exemple), ne faudrait-il pas remplacer l'argument de type boolean par, mettons, un argument de type integer ? Qu'en pensez-vous ?