7 odpowiedzi w tym temacie

[Rivit]

Witam,

tak jak w temacie. Co robi param_convert()

 

W źródełkach znalazłem takie cudeńka:

Spoiler

/This is basically right from dJeyL's lib_convert function
//This awesome hack modifies the stack frame to have an address offset
// that will align to the other plugin's memory.
//I've no idea how he thought of this, but it's great.  No idea how well it works.
static cell AMX_NATIVE_CALL param_convert(AMX *amx, cell *params)
{
	if (!g_pCurNative || (g_pCurNative->amx != amx))
	{
		LogError(amx, AMX_ERR_NATIVE, "Not currently in a dynamic native");
		return 0;
	}
	if (g_pCurNative->style != 1)
	{
		LogError(amx, AMX_ERR_NATIVE, "Wrong style of dynamic native");
		return 0;
	}
	cell p = params[1];

	AMX *caller = g_pCaller;

	unsigned char *data =amx->base+(int)((AMX_HEADER *)amx->base)->dat;
	unsigned char *realdata = caller->base+(int)((AMX_HEADER *)caller->base)->dat;

	* (cell *)(data+(int)amx->frm+(p+2)*sizeof(cell)) -= (cell)data-(cell)realdata;

	return 1;
} 

[DarkGL]

Konwertuje parametr natywu aby działał jako zmienne przekazywana przez referencje , czyli wartość parametru jest konwertowana na adres do którego się odnosi.

 

param_convert i natywy w stylu 1 nie powinny już być używane zamiast tego powinny być używane w stylu 0

[Robiin]

Konwertuje parametr natywu aby działał jako zmienne przekazywana przez referencje , czyli wartość parametru jest konwertowana na adres do którego się odnosi.

 

param_convert i natywy w stylu 1 nie powinny już być używane zamiast tego powinny być używane w stylu 0

 

A to dlaczego? Używam style 1 i param_convert i nie było większych problemów (z racji na mój błąd oczywiście).

[_McHappy]

Stosowanie natywów dynamicznych z parametrem 'style' równym 1 uniemożliwia kontrolę liczby przekazywanych do natywu (przy wywołaniu) parametrów, co w przypadku bardziej złożonych funkcji przekłada się na zwiększone ryzyko wystąpienia komplikacji w trakcie wykonywania kodu. Ponadto, natywy rejestrowane bez w/w parametru pozwalają na identyfikację pluginu, który je wywołał oraz nie wymagają w/w, dodatkowej konwersji parametrów (tablic) do postaci referencyjnej.

Często, dla prostych kontrukcji natywów, rejestrowanie z parametrem 'style' równym 1 wydaje się być właściwszym rozwiązaniem (rozwiązanie mniej skomplikowane i szybsze).

Użytkownik _McHappy edytował ten post 12.09.2018 19:08

[DarkGL]

This function has been deprecated, do NOT use it

Reason: Style 1 natives are deprecated and should be converted to style 0. This should not be used.

Skoro są deprecated to i można spodziewać się ich usunięcia w kolejnych wersjach amxx

[Rivit]

Dzięki Panowie

W sumie tak teraz patrze to wystarczyło zajrzeć do .inc

[Robiin]

Stosowanie natywów dynamicznych z parametrem 'style' równym 1 uniemożliwia kontrolę liczby przekazywanych do natywu (przy wywołaniu) parametrów, co w przypadku bardziej złożonych funkcji przekłada się na zwiększone ryzyko wystąpienia komplikacji w trakcie wykonywania kodu. Ponadto, natywy rejestrowane bez w/w parametru, pozwalają na identyfikację pluginu, który je wywołał oraz nie wymagają w/w, dodatkowej konwersji parametrów (tablic) do postaci referencyjnej.

Często, dla prostych kontrukcji natywów, rejestrowanie z parametrem 'style' równym 1 wydaje się być właściwszym rozwiązaniem (rozwiązanie mniej skomplikowane i szybsze).

 

To ma sens dla np. silników modów i większych pluginów, które są udostępniane publicznie. Tak jak mówisz - style 1 wydaje się być rozwiązaniem lepszym, bo jest mniej skomplikowane, a w pojedynczych, małych pluginach jak np. Exp, monety itp. gdzie autor ma na celu stworzenie konstrukcji na wyłącznie jeden serwer i jest świadomy (wydaje się, że już odruchowo) w jaki sposób działa natyw i jak należy go użyć, to niechętnie będzie to zmieniał. Fair point z identyfikatorem pluginu.

 

 

This function has been deprecated, do NOT use it

Reason: Style 1 natives are deprecated and should be converted to style 0. This should not be used.

Skoro są deprecated to i można spodziewać się ich usunięcia w kolejnych wersjach amxx

 

 

"Usuwamy styl natywu 1. bo działa źle/nie podoba nam się jak działa" - tak to widzę 

[DarkGL]

"Usuwamy styl natywu 1. bo działa źle/nie podoba nam się jak działa" - tak to widzę  :crazy:

Normalne jest to że niektóre funkcjonalność zostają zastąpione lub usunięte jeśli nie są już potrzebne. Albo trzeba zmusić community do użycia lepszych rozwiązań