Funktionsdeklaration: Beste Vorgehensweise

[Zend]

Hallo,

ich soll demnächst eine DLL schreiben die von einigen Tools anderer Programmierer aufgerufen wird und Informationen liefern muss.

Beispielsweise habe ich eine Funktion GetProjectPath() die den Namen eines Projektes übergeben bekommt und einen dazugehörigen Pfad ermitteln soll. Bsp:

Delphi-Quellcode:

Path = GetProjectPath("Mein Projekt") // Rückgabe: "C:/Tolle Projekte/Mein Project"

Welche Vorgehensweise wäre die bessere:

Möglichkeit 1)

Die Funktion bekommt den Projektnamen als PChar übergeben und liefert den ermittelten Pfad als Rückgabewert.

Delphi-Quellcode:

function GetProjectPath(PrjName: PChar): PChar;

Möglichkeit 2)
Die Funktion bekommt den Projektnamen als PChar übergeben und schreibt den Rückgabewert in einen zweiten übergebenen PChar.

Delphi-Quellcode:

procedure GetProjectPath(PrjName: PChar; Path: PChar);

Der Unterschied zwischen den beiden Möglichkeiten liegt meiner Meinung nach in der Speicherverwaltung:

Bei Methode 1 ist die Funktion GetProjectPath für die Speicheranforderung verantwortlich, während bei Methode 2 die aufrufende Funktion Speicher reservieren muss. Allerdings kann diese den Speicher vor dem Aufruf der Funktion gar nicht reservieren, weil diese nicht weiß wie groß der zurückgelieferte sein wird, kann aber vorsorglich mehr Speicher als dann tatsächlich benötigt (MAX_PATH) reservieren?

Habe ich das richtig erkannt? Zu welcher Methode würdet ihr mir raten?

Grüße
Zend

[shmia]

Zitat:

Zitat von Zend (Beitrag 1055387)

ich soll demnächst eine DLL schreiben die von einigen Tools anderer Programmierer aufgerufen wird und Informationen liefern muss

Welche Programmiersprachen?
Ich frage deshalb, weil ich hier eine ActiveX-DLL empfehlen würde.
Die Probleme mit der Übergabe von Strings wären damit erledigt.

[Zend]

Hallo,

der Aufruf muss neben C und Delphi auch aus Python heraus erfolgen welches meines Wissens nach nicht mit ActiveX umgehen kann.

Grüße
Zend

[himitsu]

Ansonsten über Interfaces und als Typen den WideString, Integer, Byte, ByteBool/LongBool/Boolean und Co.

in C++:
LongBool = BOOL
ich blaub ByteBol = bool (Boolean wäre nahezu kompatibel dazu, also soloange man nicht auf =True prüft :stupid: )
Integer = int
Cardinal = uint
...
WideString = SysAllocStringLen, SysReAllocStringLen, SysFreeString, SysStringLen ...

Somit wäre es zu C++ und Delphi kompatibel.

[shmia]

Zitat:

Zitat von Zend (Beitrag 1055387)

Allerdings kann diese den Speicher vor dem Aufruf der Funktion gar nicht reservieren, weil diese nicht weiß wie groß der zurückgelieferte sein wird, kann aber vorsorglich mehr Speicher als dann tatsächlich benötigt (MAX_PATH) reservieren?

Üblicherweise gibt der Aufrufer über einen weiteren Parameter mit, wieviel Speicherplatz er reserviert hat:

Delphi-Quellcode:

function GetProjectPath(PrjName: PChar; Path: PChar; PathSize:Integer):integer;


// so könnte der Aufruf aussehen:
var
  len : integer;  // Länge des Ergebnisses
  path : string;
begin
  SetLength(path, 200 {MAX_PATH});  // Speicher reservieren
  len := GetProjectPath('Test', PChar(Path), Length(Path));
  if len < 0 then
    raise Exception.Create('Puffer für GetProjectPath zu klein');
  SetLength(path, len);  // "path" auf tatsächliche Länge kürzen

Ziemlich aufwändig für meinen Geschmack; bei einer ActiveX-DLL schreibt man einfach:

Delphi-Quellcode:

path := objectXY.GetProjectPath('Test');

[shmia]

Zitat:

Zitat von Zend (Beitrag 1055389)

der Aufruf muss neben C und Delphi auch aus Python heraus erfolgen welches meines Wissens nach nicht mit ActiveX umgehen kann.

Phyton kann als ActiveX Client arbeiten:
http://stackoverflow.com/questions/1...ivex-in-python

Dann käme es nur noch darauf an, einen zeitgemässen C/C++-Compiler zu finden, der ActiveX-DLLs einbinden kann.

[Zend]

Hallo,

mir gefällt die Vorstellung über ActiveX zu gehen.

Der verwendete C-Compiler wäre der aus Visual Studio 2010. Ich denke wenn es einen gibt der damit umgehen kann, dann ist es gerade dieser oder?

Grüße
Zend

[Luckie]

Ich würde es so machen: http://www.michael-puff.de/Artikel/StringDLL.shtml