The following code example shows how to use _declspec(dllimport) to import function calls from a DLL into an application. Assume that func1 is a function that resides in a DLL separate from the .exe file that contains the main function.

Without __declspec(dllimport), given this code:

int main(void)
{
   func1();
}


the compiler generates code that looks like this:

call func1


and the linker translates the call into something like this:

call 0x4000000         ; The address of 'func1'.


If func1 exists in another DLL, the linker cannot resolve this directly because it has no way of knowing what the address of func1 is. In 16-bit environments, the linker adds this code address to a list in the .exe file that the loader would patch at run time with the correct address. In 32-bit and 64-bit environments, the linker generates a thunk of which it does know the address. In a 32-bit environment the thunk looks like:

0x40000000:    jmp DWORD PTR __imp_func1


Here imp_func1 is the address for the func1 slot in the import address table of the .exe file. All the addresses are thus known to the linker. The loader only has to update the .exe file's import address table at load time for everything to work correctly.

Therefore, using __declspec(dllimport) is better because the linker does not generate a thunk if it is not required. Thunks make the code larger (on RISC systems, it can be several instructions) and can degrade your cache performance. If you tell the compiler the function is in a DLL, it can generate an indirect call for you.

So now this code:

__declspec(dllimport) void func1(void);
int main(void)
{
   func1();
}


generates this instruction:

call DWORD PTR __imp_func1


There is no thunk and no jmp instruction, so the code is smaller and faster.

On the other hand, for function calls inside a DLL, you do not want to have to use an indirect call. You already know a function's address. Because time and space are required to load and store the address of the function before an indirect call, a direct call is always faster and smaller. You only want to use __declspec(dllimport) when calling DLL functions from outside the DLL itself. Do not use __declspec(dllimport) on functions inside a DLL when building that DLL.

А ты что, 1С++ на VC переводишь? И как, получается?

Вот тут надо будет особенно внимательно все проверять. Как проверял совместимость CRT?

Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
 

Ну, 9-й Интел тоже не так уж сильно тормозит

Возможно, вылез наружу скрытый баг   Или заглючил ms-specific. В 1С++-ных контекстах оно есть. По стандартам надо код писать Йоксель после LTCG нормально работает.

Это, конечно, надо смотреть. Но вроде бы там полно случаев, когда память выделяется в 1С и освобождается в 1С++ и наоборот - тот же CString можно взять.

Например, прямой доступ к члену CString в объекте CValue. Если там уже есть значение, выделенное 1С, то при записи туда чего-то нового может понадобиться освободить и заново выделить память. Освобождаем память выделенную 1С. Выделяем память через свою CRT. Потом при уничтожении CValue 1С будет освобождать нашу память.

Всякие еще сохранения CValue в CString... Вообще, функций, которые принимают ссылку или указатель на наш объект CString хватает. Это что вспомнилось.

Ага, вот еще что вспомнил - контексты. При создании контекста одинэсина вызывает НАШУ функцию, которая выделяет память. А удаляет контекст она САМА через delete. Правда, вроде бы там в vtable должен быть адрес нашего operator delete...   Хм...

Ага, как раз хотел предложить изменить интерфейс провайдера - добавить передачу смартпойнтеров вместо простых указателей.

kms писал(а) 18. Мая 2008 :: 02:21:

Будем надеяться.

Все нормально компилируется - только в паре мест понадобилось добавить typename. И это называется более строгим контролем?

warning #1595: non-POD (Plain Old Data) class type passed through ellipsis
warning #1125: function "CBLContext::GetPropName(int, int) const" is hidden by "CCellAppearance::GetPropName" -- virtual function override intended?
 

BL_METH("SetRowsPictures", "УстановитьКартинкиСтрок", 2, &MethSetRowsPictures, NULL, DefSetRowsPictures)
error C4867: 'CV7GridColumn::DefSetRowsPictures': function call missing argument list; use '&CV7GridColumn::DefSetRowsPictures' to create a pointer to member
 

m_CommandQueue.Add(&CCursorGridCtrl::OnActivateRow);
error C2276: '&' : illegal operation on bound member function expression
 

CMapOfInfoUnlimitsParamsPtr& GetBindInstanceValueList() const
{ return m_BindInstanceValueList; }

error C2440: 'return' : cannot convert from 'const CMapOfInfoUnlimitsParamsPtr' to 'CMapOfInfoUnlimitsParamsPtr &'
 

warning C4018: '<' : signed/unsigned mismatch
 

warning C4244: '=' : conversion from 'double' to 'USHORT', possible loss of data
 

GlobalMethods.h	warning C4996: 'swprintf': swprintf has been changed to conform with the ISO C standard, adding an extra character count parameter. To use traditional Microsoft swprintf, set _CRT_NON_CONFORMING_SWPRINTFS.
 

Preprocessor.h: std::auto_ptr<CRangesOfDescrImpl> m_pImpl;
warning C4150: deletion of pointer to incomplete type 'CRangesOfDescrImpl'; no destructor called
 

DynaValue.cpp	    if (pContext != NULL && pContext->GetRuntimeClass()->m_lpszClassName == "CComponentClass")
warning C4130: '==' : logical operation on address of string constant