Register for your free account! | Forgot your password?

Go Back   elitepvpers > Coders Den > C/C++
You last visited: Today at 17:18

  • Please register to post and access all features, it's quick, easy and FREE!

Advertisement



von autoit zu c++

Discussion on von autoit zu c++ within the C/C++ forum part of the Coders Den category.

Reply
 
Old 03/07/2014, 23:15   #16


 
elite*gold: 1091
Join Date: Jun 2007
Posts: 19,836
Received Thanks: 7,180
Quote:
Originally Posted by Master674b View Post
Btw: std::function zu benutzen um fremde Funktionen aufzurufen halte ich für sehr unklug (wo gibst du da bitte die Aufrufkonvention an?). Da wäre soetwas schon besser:

Code:
typedef int (__cdecl *tInitDecoration) (int);
tInitDecoration pInitDecoration = reinterpret_cast<tInitDecoration>(
        GetProcAddress(skincrafterHandle, "InitDecoration"));
pInitDecoration(1);
Darf ich fragen warum? std::function ist doch lediglich ein Wrapper für Funktionspointer? Abgesehen davon muss man die Calling Convention nicht berücksichtigen.

->
Mostey is offline  
Old 03/07/2014, 23:17   #17
 
Master674b's Avatar
 
elite*gold: 0
Join Date: Dec 2012
Posts: 255
Received Thanks: 110
Quote:
Originally Posted by Mostey View Post
Darf ich fragen warum? std::function ist doch lediglich ein Wrapper für Funktionspointer? Abgesehen davon muss man die Calling Convention nicht berücksichtigen.

->
Habe es bereits vor deinem Post korrigiert. Ja das hatte ich nicht berücksichtigt, aber std::function macht hier wirklich keinen Sinn, das versteckt dir nur unnötig die Aufrufkonvention. Und die muss man sehr wohl berücksichtigen! std::function hält intern die Funktionssignatur versteckt um den Aufruf tätigen zu können. Ist bei seinem Compiler etwas anderes als __cdecl als Standard-Aufrufkonvention eingetragen, dann gibt es einen Crash weil du mit der Zuweisung ne falsche Signatur übergeben hast.

Siehe:

Code:
std::function<int(int)> InitDecoration = reinterpret_cast<int(*)(int)>(GetProcAddress(hModule, "InitDecoration"));
Das hier würde funktionieren:

Code:
std::function<int(int)> InitDecoration = reinterpret_cast<int (__cdecl*) (int)>(GetProcAddress(hModule, "InitDecoration"));
Der Grund:

Das int (*) (int) wird vom Compiler ergänzt zu:
int (default_call_convention *) (int).
Master674b is offline  
Thanks
1 User
Old 03/07/2014, 23:20   #18


 
elite*gold: 1091
Join Date: Jun 2007
Posts: 19,836
Received Thanks: 7,180
Quote:
Originally Posted by Master674b View Post
Habe es bereits vor deinem Post korrigiert. Ja das hatte ich nicht berücksichtigt, aber std::function macht hier wirklich keinen Sinn, das versteckt dir nur unnötig die Aufrufkonvention.
Aber warum ist das denn unbedingt schlecht? Normalerweise ändert die sich doch nicht sporadisch, wenn man also über einen Kommentar diese vermerkt, sollte das doch in Ordnung gehen. Ich wüsste nicht, warum ich nicht den neuen Wrapper nutzen sollte, der mir das etwas erleichert?

€: Du editierst ziemlich oft ;O
Der Grund scheint plausibel, wusste ich nicht. Trotzdem finde ich die Anwendung des Wrappers eleganter. Egal, jedem das seine.
Mostey is offline  
Old 03/07/2014, 23:23   #19
 
Master674b's Avatar
 
elite*gold: 0
Join Date: Dec 2012
Posts: 255
Received Thanks: 110
Quote:
Originally Posted by Mostey View Post
Aber warum ist das denn unbedingt schlecht? Normalerweise ändert die sich doch nicht sporadisch, wenn man also über einen Kommentar diese vermerkt, sollte das doch in Ordnung gehen. Ich wüsste nicht, warum ich nicht den neuen Wrapper nutzen sollte, der mir das etwas erleichert?
Der Post wurde soeben nochmal editiert um deine Frage zu beantworten.
Master674b is offline  
Old 03/08/2014, 02:23   #20


 
MrSm!th's Avatar
 
elite*gold: 7110
Join Date: Jun 2009
Posts: 28,904
Received Thanks: 25,394
Quote:
Originally Posted by omitma View Post
z.b. InitLicenKeys(param1, param2, param3 usw....);
ABER das std::function ist nicht richtig. das erste int ist der rückgabe wert und das 2. der wert des 1. parameters glaube ich. Benutze immer nur das was ich gepostet habe so wie du es anscheinend auch gemacht hast. Wenn du dann das std::function änderst musst du natürlich auch reinterpret_cast anpassen. Musst das halt auf die Funktion anpassen. Ich nutze aber lieber meine Version. Wahrscheinlich aber nur weil ich da weiß wo welcher typ für den 1. parameter hin muss, was ich bei std::function nicht sicher weiß.
Du hast Unsinn geposted, die Funktion ist keine __stdcall Funktion. Und es gibt auch keinen Grund, rohe Pointer std::function vorzuziehen.

Den Rückgabetyp kann man auf 32bit auch ohne Probleme als int lassen, mehr passt da sowie nicht ins EAX Register (jaja an die Klugscheißer, ich weiß, dass einer von hundert Compilern für einen Int auch nur 16bit reservieren könnte ;o).
Quote:
Originally Posted by Master674b View Post
Habe es bereits vor deinem Post korrigiert. Ja das hatte ich nicht berücksichtigt, aber std::function macht hier wirklich keinen Sinn, das versteckt dir nur unnötig die Aufrufkonvention. Und die muss man sehr wohl berücksichtigen! std::function hält intern die Funktionssignatur versteckt um den Aufruf tätigen zu können. Ist bei seinem Compiler etwas anderes als __cdecl als Standard-Aufrufkonvention eingetragen, dann gibt es einen Crash weil du mit der Zuweisung ne falsche Signatur übergeben hast.

Siehe:

Code:
std::function<int(int)> InitDecoration = reinterpret_cast<int(*)(int)>(GetProcAddress(hModule, "InitDecoration"));
Das hier würde funktionieren:

Code:
std::function<int(int)> InitDecoration = reinterpret_cast<int (__cdecl*) (int)>(GetProcAddress(hModule, "InitDecoration"));
Der Grund:

Das int (*) (int) wird vom Compiler ergänzt zu:
int (default_call_convention *) (int).
Das ist kein Problem von std::function. Wenn du die Calling Convention beim C Funktionspointer weglässt, wird ebenso der Default verwendet.
MrSm!th is offline  
Thanks
1 User
Reply




All times are GMT +2. The time now is 17:18.


Powered by vBulletin®
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Support | Contact Us | FAQ | Advertising | Privacy Policy | Terms of Service | Abuse
Copyright ©2024 elitepvpers All Rights Reserved.