Shared C Bibliothek in fpc einbindne

[Maik81ftl]

Moin Moin,

von einigen bei euch weiß ich ja, das die mit Bibliotheken arbeiten, welche in C/C++ geschrieben wurden.

wenn ich nun in C eine *.so schreibe und die function folgende Parameter hat wie muß ich die in meinen Programmen aufrufen?

Code: Alles auswählen

char *ctb(unsigned short usocfe)

kann ich das in dem Fall überhaupt so stehen lassen, ob bekomme ich da ggf. probleme bei der Übergabe?

dazugesagt! die "so" soll via MonoDev geschrieben werden. muß ich da noch anderes Beachten? um das Forum nicht unnötig vollzuschreiben, würde mir auch ein Link zu einer Onlineanleitung reichen.

Praktisches Bsp. wäre als Gedanken hilfe auch gut.

noch dazugesagt! die menge der zu sendenden Parameter kann sich ggf noch ändern.

Edit! habe analog Hier http://de.wikibooks.org/wiki/GNU-Pascal ... 3.A4rung_3 was gefunden würde es schon reichen, wenn ich mich in etwa daran halte?

[Targion]

dein Code kann über

Code: Alles auswählen

function ctb (int usocfe): PChar; cdecl; external "library.so";

aufgerufen werden. Wenn du mit MonoDev den C-Quelltext schreibst und nicht irgendwelchen C# oder CLI-Kram machst, geht das in Ordnung.
Wenn sich die Parametermenge ändert (du also das API brichst), musst du in Pascal interface die Änderungen natürlich auch vornehmen.
Irgendwo gibt es auch einen C<->Pascal Guide, der Probleme beim erstellen von Bindings beschreibt, finde aber grade den Link dazu nicht. (werde ich evtl. nachreichen)

[theo]

Oder so:

Code: Alles auswählen

function ctb (usocfe:Word): PChar; cdecl; external "library.so";

[Targion]

@theo: Mist, klar Ich benutze seit Monaten fast nur noch Vala und C++, also sorry für den Syntax-Matsch oben ^^ (und Word ist natürlich auch geeigneter als ein Integer)

[Maik81ftl]

Jopp! danke. so in der richtung dachte ich mir das auch.

lass meine Testfile, welche später in die .so übergehen soll via konsole durchgehen und glaub ich spinne...

Code: Alles auswählen

Ich bin der Buschstabe G und sehe wie folgt aus: 71d `�N11100010b, @�N701o und 0x �N74

wenn ich mir das mal so anschaue, vermute ich mal, das da irgendwas auf dem Zeigerliegt. weiß nun aber auch nicht, ob ich dies denne auch in Functionsaufruf der .so hab. wenn ja wäre doof.

wäre denne die entsprechende Meldung inna konsole

Code: Alles auswählen

Conditional jump or move depends on uninitialised value(s)
==18493==    at 0x4C2836A: strcat (mc_replace_strmem.c:176)
==18493==    by 0x400C49: ctb (in /home/maik81ftl/Programming/viaC/Test2/Laufende-Programme/Test1/Wandela)
==18493==    by 0x400CFE: main (in /home/maik81ftl/Programming/viaC/Test2/Laufende-Programme/Test1/Wandela)

Der block hier unten läst mir zu dem auch keine ruhe...

Code: Alles auswählen

HEAP SUMMARY:
==18493==     in use at exit: 0 bytes in 0 blocks
==18493==   total heap usage: 42 allocs, 42 frees, 224 bytes allocated
==18493== 
==18493== All heap blocks were freed -- no leaks are possible
==18493== 
==18493== For counts of detected and suppressed errors, rerun with: -v
==18493== Use --track-origins=yes to see where uninitialised values come from
==18493== ERROR SUMMARY: 21 errors from 3 contexts (suppressed: 4 from 4)

[Keifor]

Valgrind hat schon die richtige Antwort gegeben. Ein teil der Variablen ist nicht (vollständig) initialisiert für die Nutzung.
C String Operationen (strcpy/strlen/strcat/... und dergleichen auf char*) gehen von Null-terminierten Zeichenketten aus. So werden in den Zeichenketten halt die enden markiert.

Malloc holt nur Speicher ran, initialisiert in aber nicht. Wenn du eine leere Null-Terminierte Zeichenkette brauchst, dann mach sowas:

Code: Alles auswählen

char* string = (char*)malloc(100 + 1); // 100 zeichen, +1 fuer terminierung
string[0] = 0; // string ist nun leer

Beispiel bei deinem code, setze hex[0] = 0; nach dem Speicher ranholen, sonst baut strcat( hex, tmp ) einfach den Müll in hex bis zum ersten 0 an den Anfang. Analog für bin/okt.

Anmerkung 1:
Konstante Zeichenketten werden, soweit ich mich erinnere, vom compiler bereits Null Terminiert abgespeichert, daher gibts auch keine Probleme wenn die in String Funktionen als Quelle genutzt werden.
Anmerkung 2:
Dein Code hat noch viel Potential für Optimierungen.

[carli]

Und einen char *zurückgeben zu lassen ist auch nicht gerade schlau, da der Speicher dann nicht mehr der Lib gehört.
Zumindest solltest du den Lebenszyklus des allokieren Speichers im Überblick behalten.

Ansonsten mach's so wie die WinAPI: Gib der Lib nen Platz, wo sie den Speicher hinkopieren soll und eine Maximallänge.
Den Speicher reservierst du vom Programm und ist somit voll unter deiner Kontrolle.

[Maik81ftl]

Valgrind hat schon die richtige Antwort gegeben. Ein teil der Variablen ist nicht (vollständig) initialisiert für die Nutzung.
C String Operationen (strcpy/strlen/strcat/... und dergleichen auf char*) gehen von Null-terminierten Zeichenketten aus. So werden in den Zeichenketten halt die enden markiert.

Malloc holt nur Speicher ran, initialisiert in aber nicht. Wenn du eine leere Null-Terminierte Zeichenkette brauchst, dann mach sowas:

Code: Alles auswählen

char* string = (char*)malloc(100 + 1); // 100 zeichen, +1 fuer terminierung
string[0] = 0; // string ist nun leer

machen hier 101 wirklich sin, wenn ich max 8+1 brauche?

Beispiel bei deinem code, setze hex[0] = 0; nach dem Speicher ranholen, sonst baut strcat( hex, tmp ) einfach den Müll in hex bis zum ersten 0 an den Anfang. Analog für bin/okt.

Jopp! schaut schon besser aus.

Anmerkung 2: Dein Code hat noch viel Potential für Optimierungen.

Leider. Vermute mal, das du damit auch die Bezeichnung der Funktionen sowie der Parameter meinst. die main fliegt sowieso raus, da die nur zum Test drinne ist für die Konsole. Werd erst mal versuchen die functionen so in die -so zu bekommen, und denne versuchen zu optimieren.
Hmmm die ftk ctb hab ich kürzen könne. und schaut nun so aus.

Code: Alles auswählen

char *ctb(unsigned short usocfe) //	 usocfe = Zeiger "unsigned short of cfe"
{
	char *bin = malloc(sizeof(char) * (8 + 1));			// Speicher aus 9 resavieren
	char *temp = malloc(sizeof(char) * (8 + 1));		// -------------"------------
	char b[2] = "0"
	bin[0] = temp[0] = 0;
	int a;	
	for (a=0; a<=7; ++a)
		{
		b[0]=(char)(usocfe%BIN)+48;
		usocfe=usocfe/BIN;
		strcpy(temp, b);
		strcat(bin, temp);
		}
	strcpy(temp, bin);
	free(temp);
	return(bin);
}

wenn ich die nun noch sichtig kommentiere, sollt ich die Grundlagen dann doch schon verstanden haben. auch was das casten angeht.

Und einen char *zurückgeben zu lassen ist auch nicht gerade schlau, da der Speicher dann nicht mehr der Lib gehört.
Zumindest solltest du den Lebenszyklus des allokieren Speichers im Überblick behalten.

Ansonsten mach's so wie die WinAPI: Gib der Lib nen Platz, wo sie den Speicher hinkopieren soll und eine Maximallänge.
Den Speicher reservierst du vom Programm und ist somit voll unter deiner Kontrolle.

sowas vie z.B. den Speicher via Adresse vordefinieren? WinAPI kenn ich mich net aus.

[Maik81ftl]

Suber... Läuft wie es soll

aber wie gesagt! bei dem letzten, weiß ich leider net, was genau gemeint wurde.

Aber mal was anderes? würde ihr die lib's in einer seperaten Unit sammeln oder nur da, wo die auch gebraucht werden?

[Keifor]

Suber... Läuft wie es soll

Zufall. In dem Code von oben müßte b mit b[1] = 0 initialisiert werden. Da b[0] in der Schleife eh überschrieben wird und dann StrCpy (tmp,b) genutzt wird, ist das immer noch fehlerhaft. Wie gesagt nur Zufall das nichts schief läuft.

Aber mal was anderes? würde ihr die lib's in einer seperaten Unit sammeln oder nur da, wo die auch gebraucht werden?

Separat. Das vereinfacht Anpassungen.

machen hier 101 wirklich sin, wenn ich max 8+1 brauche?

Das war nur ein Beispiel .

Anmerkung 2: Dein Code hat noch viel Potential für Optimierungen.

Leider. Vermute mal, das du damit auch die Bezeichnung der Funktionen sowie der Parameter meinst. die main fliegt sowieso raus, da die nur zum Test drinne ist für die Konsole. Werd erst mal versuchen die functionen so in die -so zu bekommen, und denne versuchen zu optimieren.

Beizeichner usw. sind mir eigentlich relativ egal. Ich wollte eher darauf ansprechen das du eine Menge string Manipulationen (strcpy, strcat) benutzt, wo sie nicht nötig sind.

Ansonsten mach's so wie die WinAPI: Gib der Lib nen Platz, wo sie den Speicher hinkopieren soll und eine Maximallänge.
Den Speicher reservierst du vom Programm und ist somit voll unter deiner Kontrolle.

sowas vie z.B. den Speicher via Adresse vordefinieren? WinAPI kenn ich mich net aus.

Was carli vermutlich damit sagen wollte ist: Das ganze Speicher ranholen und zurückgeben von Lib an Programm ist keine ungefährliche Sache. Vor allem bei Freepascal/Delphi/.. da sie standardmäßig Speichermanager benutzen. C benutzt in der Regel direkt die Betriebsystem Routinen. Die Mischung kann zu Problemen führen wenn der Speichermanager Speicherblöcke in die Finger bekommt, die nicht ihm gehören.

Dafür gibt es allerdings auch eine Reihe von Lösungen die alle das selbe bedeuten. Man benutzt nicht überschneidendes Speichermanagement.
Möglichkeiten:

• In allen Freepascal Programmen und Bibliotheken wird cmem eingebunden. Der Speichermanager wird damit quasi ausgeschaltet, indem die Routinen vom Betriebsystem direkt verwendet werden. Bei C ist das Standard. Der Nachteil daran ist, das es Performance kosten kann, denn (die Kurzfassung) solche aufrufe benötigen Kontextwechsel und haben erheblichen Overhead. Genau so etwas versucht der Speichermanager zu vermeiden.
• Die Bibliothek stellt eine Schnittstelle zur Verfügung, für Speicher der von der Bibliothek gehandhabt wird.
• Die Möglichkeit von der carli (glaube ich) sprach benötigt keine Schnittstellen. Das Programm stellt der Bibliothek einen Speicherblock zur Verfügung (also im Programm alloziert, den Zeiger[+Größe falls notwendig] als Parameter beim Aufruf übergeben) und die Bibliothek arbeitet darauf oder kopiert Ergebnisse in den Block.

Und um gleich den "Spaß" vorweg zu nehmen. 3 Weitere Probleme neben dem "String/Speicher Management", wenn man C/C++ und Pascal über Bibliotheken mischt sind

• Die Calling Convention bzw. Aufrufkonvention. Die (amd/win64) 64Bit ABI macht das ganze mehr oder minder überflüssig, das heißt cdecl/stdcall werden nicht mehr verwendet, stattdessen gibt es unter Linux und Windows einheitliche Konventionen für das übergeben von Parametern etc. Wunder dich also nicht wenn fpc oder gcc sagen das "cdecl" veraltet ist bzw. ignoriert wird. Wichtig ist das immer noch für 32bit.
• Anpassung von Pascal Typen an C Typen (und umgekehrt). Vor allem bei Fremd-Bibliotheken gemischt mit dem C Makroprozessor kann es immer wieder ein Spaß werden herauszufinden welche Größe die Parameter einer Funktion eigentlich haben.
• Sprachfeatures. Das beste ist die Schnittstelle so einfach wie möglich zu halten und im Notfall ein paar Wrapper zu basteln.

[carli]

Anmerkung 2: Dein Code hat noch viel Potential für Optimierungen.

Leider.

Nein, das ist gut.
Du musst nicht alles optimieren. Wichtiger ist, dass das Programm für jede Eingabe korrekt funktioniert und dass es auf keinen Fall crashen kann.
Was die Optimierung angeht, die sollte man sich offen lassen, dabei sollte man es dann aber auch belassen. Der Computer arbeitet in 90% der Zeit nur 10% deines Codes ab. Sollte dein Programm wirklich mal unter Hochlast rechnen und dir zu langsam sein, dann suche die 10% und optimiere die. Aber sonst nicht. (Es sei denn, es macht die Spaß)

[Maik81ftl]

Beizeichner usw. sind mir eigentlich relativ egal. Ich wollte eher darauf ansprechen das du eine Menge string Manipulationen (strcpy, strcat) benutzt, wo sie nicht nötig sind.

ich glaube du meinst z.B. den hier

Code: Alles auswählen

strcat(bin, temp);

Code: Alles auswählen

strcat(okt, temp);

Code: Alles auswählen

strcat(hex, temp);

grad ausgeklammert. geht auch ohne ---> 3 zeilen weniger.

Was carli vermutlich damit sagen wollte ist: Das ganze Speicher ranholen und zurückgeben von Lib an Programm ist keine ungefährliche Sache. Vor allem bei Freepascal/Delphi/.. da sie standardmäßig Speichermanager benutzen. C benutzt in der Regel direkt die Betriebsystem Routinen. Die Mischung kann zu Problemen führen wenn der Speichermanager Speicherblöcke in die Finger bekommt, die nicht ihm gehören.

Dafür gibt es allerdings auch eine Reihe von Lösungen die alle das selbe bedeuten. Man benutzt nicht überschneidendes Speichermanagement.
Möglichkeiten:

• In allen Freepascal Programmen und Bibliotheken wird cmem eingebunden. Der Speichermanager wird damit quasi ausgeschaltet, indem die Routinen vom Betriebsystem direkt verwendet werden. Bei C ist das Standard. Der Nachteil daran ist, das es Performance kosten kann, denn (die Kurzfassung) solche aufrufe benötigen Kontextwechsel und haben erheblichen Overhead. Genau so etwas versucht der Speichermanager zu vermeiden.
• Die Bibliothek stellt eine Schnittstelle zur Verfügung, für Speicher der von der Bibliothek gehandhabt wird.
• Die Möglichkeit von der carli (glaube ich) sprach benötigt keine Schnittstellen. Das Programm stellt der Bibliothek einen Speicherblock zur Verfügung (also im Programm alloziert, den Zeiger[+Größe falls notwendig] als Parameter beim Aufruf übergeben) und die Bibliothek arbeitet darauf oder kopiert Ergebnisse in den Block.

Und um gleich den "Spaß" vorweg zu nehmen. 3 Weitere Probleme neben dem "String/Speicher Management", wenn man C/C++ und Pascal über Bibliotheken mischt sind

• Die Calling Convention bzw. Aufrufkonvention. Die (amd/win64) 64Bit ABI macht das ganze mehr oder minder überflüssig, das heißt cdecl/stdcall werden nicht mehr verwendet, stattdessen gibt es unter Linux und Windows einheitliche Konventionen für das übergeben von Parametern etc. Wunder dich also nicht wenn fpc oder gcc sagen das "cdecl" veraltet ist bzw. ignoriert wird. Wichtig ist das immer noch für 32bit.
• Anpassung von Pascal Typen an C Typen (und umgekehrt). Vor allem bei Fremd-Bibliotheken gemischt mit dem C Makroprozessor kann es immer wieder ein Spaß werden herauszufinden welche Größe die Parameter einer Funktion eigentlich haben.
• Sprachfeatures. Das beste ist die Schnittstelle so einfach wie möglich zu halten und im Notfall ein paar Wrapper zu basteln.

Jopp. da muß ich auch nochmal eine gute quelle suchen, die mir erklärt, wie ich einer via fpc vorsorglich 1K für nur für die .so resaviere, damit ich auch im weiteren verlauf mit den Zeigern, welche ich in der C - .so als einsprung nuzte keinen streß bekommen kann. weis net, ob i via den mem-routinen in c was mit machen kann.

aber was du schreibst, das hier speicherprobleme auftretten können hab ich mir der selbigen .so unter fpc geschrieben schon durch...

Nein, das ist gut. Du musst nicht alles optimieren. Wichtiger ist, dass das Programm für jede Eingabe korrekt funktioniert und dass es auf keinen Fall crashen kann. Was die Optimierung angeht, die sollte man sich offen lassen, dabei sollte man es dann aber auch belassen. Der Computer arbeitet in 90% der Zeit nur 10% deines Codes ab. Sollte dein Programm wirklich mal unter Hochlast rechnen und dir zu langsam sein, dann suche die 10% und optimiere die. Aber sonst nicht. (Es sei denn, es macht die Spaß)

Das lässt dich ganz einfach raus bekommen. einfach via Testprog. 256 Zeichen an die .so schicken und die Rückantwort auswerten. Das ganze insgesamt 6 mal (1 mal / funktion.

[carli]

Nein, das ist gut. Du musst nicht alles optimieren. Wichtiger ist, dass das Programm für jede Eingabe korrekt funktioniert und dass es auf keinen Fall crashen kann. Was die Optimierung angeht, die sollte man sich offen lassen, dabei sollte man es dann aber auch belassen. Der Computer arbeitet in 90% der Zeit nur 10% deines Codes ab. Sollte dein Programm wirklich mal unter Hochlast rechnen und dir zu langsam sein, dann suche die 10% und optimiere die. Aber sonst nicht. (Es sei denn, es macht die Spaß)

Das lässt dich ganz einfach raus bekommen. einfach via Testprog. 256 Zeichen an die .so schicken und die Rückantwort auswerten. Das ganze insgesamt 6 mal (1 mal / funktion.

Der Ernstfall wird wohl eher erst ab 10.000 bis 100.000 Aufrufen passieren. Und solange du diesen Ernstfall nicht hast, brauchst du auch nicht auf Optimierungen groß achten.

[Maik81ftl]

Nein, das ist gut. Du musst nicht alles optimieren. Wichtiger ist, dass das Programm für jede Eingabe korrekt funktioniert und dass es auf keinen Fall crashen kann. Was die Optimierung angeht, die sollte man sich offen lassen, dabei sollte man es dann aber auch belassen. Der Computer arbeitet in 90% der Zeit nur 10% deines Codes ab. Sollte dein Programm wirklich mal unter Hochlast rechnen und dir zu langsam sein, dann suche die 10% und optimiere die. Aber sonst nicht. (Es sei denn, es macht die Spaß)

Das lässt dich ganz einfach raus bekommen. einfach via Testprog. 256 Zeichen an die .so schicken und die Rückantwort auswerten. Das ganze insgesamt 6 mal (1 mal / funktion.

Der Ernstfall wird wohl eher erst ab 10.000 bis 100.000 Aufrufen passieren. Und solange du diesen Ernstfall nicht hast, brauchst du auch nicht auf Optimierungen groß achten.

läst sich zufällig auch realisieren. brauch nur einen Text mit ü 10k Zeichen...

note k = 1000

[carli]

Der Ernstfall wird wohl eher erst ab 10.000 bis 100.000 Aufrufen passieren. Und solange du diesen Ernstfall nicht hast, brauchst du auch nicht auf Optimierungen groß achten.

läst sich zufällig auch realisieren. brauch nur einen Text mit ü 10k Zeichen...

note k = 1000

Mit 10 KB Datentransfer im Speicher knockst du den Rechner noch nicht aus.
Probier's lieber mal mit 2 GB, die du im RAM kopieren willst und überlege dann, ob du wirklich mal einen so langen String haben wirst.