Форум на Исходниках.RU

VS 2017, memcpy()

Mikle — Mon, 18 Feb 2019 18:08:12 +0000

Mikle:

Цитата Qraizer @ 18.02.19, 15:49

Ну ты же понимаешь, что intrinsic-и зависят от реализации. Версии компилятора там, мало ли.

У меня dll полна интринсиков с SIMD инструкциями, так что один простой __movsd вряд ли сыграет роль.

VS 2017, memcpy()

Qraizer — Mon, 18 Feb 2019 15:49:19 +0000

Qraizer: Ну ты же понимаешь, что intrinsic-и зависят от реализации. Версии компилятора там, мало ли. А вот WinAPI как бы одинакова. Какая-нибудь StringCchCopyEx() не изменится и будет всегда. Другой вопрос – производительность.

VS 2017, memcpy()

Mikle — Mon, 18 Feb 2019 12:45:28 +0000

Mikle:

Цитата Qraizer @ 18.02.19, 12:18

Формально в WinAPI есть аналоги, можешь ими пользоваться.

Я и воспользовался интринсиком, который никаких проблем вообще за собой не тянет.

VS 2017, memcpy()

Qraizer — Mon, 18 Feb 2019 12:18:41 +0000

Qraizer:

Цитата Mikle @ 18.02.19, 06:04

Да, теперь появилась зависимость от рантайма,
да, его вроде можно статически прилинковать,
да, он несовместим с XP (а я пока не хочу терять совместимость)

Она как бы и задействована, ибо ты сам заюзал эту функцию, и она как раз ран-таймовая. Формально в WinAPI есть аналоги, можешь ими пользоваться.
Его и надо статически. Точнее, желательно. Можно вместо либы с реализацией взять библиотеку импорта к DLL, но зависимость не исчезнет и даже в некотором смысле усугубится, т.к. придётся DLL таскать с собой и ещё заботиться о совпадении версий.
Совместимость с XP обеспечивается параметрами проекта. Это в VS2012 нужно было ставить спец.апдейт. В VS2013 и позднее просто выставляешь галку установщику, и появляется галка в параметрах проекта.

VS 2017, memcpy()

ЫукпШ — Mon, 18 Feb 2019 12:07:29 +0000

ЫукпШ:

Цитата Mikle @ 18.02.19, 09:59

Цитата ЫукпШ @ 18.02.19, 09:33

Тогда не понятно, зачем отказываться от VS 2008 ?

1. Express версия не компилирует в x64.

Всё стабильно работает.
У Микрософта на сайте даже была подробная инструкция, как это сделать.

VS 2017, memcpy()

Mikle — Mon, 18 Feb 2019 09:59:26 +0000

Mikle:

Цитата ЫукпШ @ 18.02.19, 09:33

Тогда не понятно, зачем отказываться от VS 2008 ?

1. Express версия не компилирует в x64.
2. Быстродействие на VS 2017 получается повыше, особенно оптимизация интринсиков.

VS 2017, memcpy()

ЫукпШ — Mon, 18 Feb 2019 09:33:00 +0000

ЫукпШ:

Цитата Mikle @ 18.02.19, 06:04

да, он несовместим с XP (а я пока не хочу терять совместимость),

Тогда не понятно, зачем отказываться от VS 2008 ?

Цитата

Этот же код в VS 2008 Express без проблем компилируется и корректно работает

VS 2017, memcpy()

Mikle — Mon, 18 Feb 2019 06:04:37 +0000

Mikle: Вопрос решился прилинковкой vcruntime.lib.
Да, теперь появилась зависимость от рантайма,
да, его вроде можно статически прилинковать,
да, он несовместим с XP (а я пока не хочу терять совместимость),
да, в студии, вроде как, можно ещё что-то прилинковать для совместимости.

Но интринсик с этим справляется без всех этих проблем.
Источник проблемы установлен, вопрос решён.

VS 2017, memcpy()

Mikle — Sun, 17 Feb 2019 18:47:26 +0000

Mikle:

Цитата Qraizer @ 17.02.19, 18:02

нет, случайно, какого-нибудь /NODEFAULTLIB?

Нет.

VS 2017, memcpy()

Qraizer — Sun, 17 Feb 2019 18:02:37 +0000

Qraizer:

Цитата Славян @ 17.02.19, 12:51

Наверное, всё же трабла в настройках проекта.

Там нет, случайно, какого-нибудь /NODEFAULTLIB? Ибо у меня синтетический пример прекрасно собрался:

// .DLL

#include <cstring>

extern "C" __declspec(dllexport) void __stdcall f(void *dst, const void *src, size_t size)

{

memcpy(&dst, &src, size);

}

// .EXE

int a;

int b;

extern "C" __declspec(dllimport) void __stdcall f(void *dst, const void *src, size_t size);

int main()

{

f(&a, &b, sizeof(a));

}

VS 2017, memcpy()

ЫукпШ — Sun, 17 Feb 2019 15:03:46 +0000

ЫукпШ: Mikle, а каталоги для VS - пути файлов библиотек, исполнимых файлов и хеадеров
указаны правильно ? в том числе VC, SDK, а также всех других, которые необходимы.

Цитата Mikle @ 17.02.19, 13:35

Славян
В моём случае это так:

EXPORTS

PAINT

Если ты используешь def - файл в dll проекте,
то это:

extern "C" __declspec(dllexport)

можно не использовать. Это, как-бы, определено самим фактом
использования имён в def-файле.

VS 2017, memcpy()

Славян — Sun, 17 Feb 2019 14:01:48 +0000

Славян: Да нет никакой разницы. Ну убрал указание на вызов по ординалу 1, всё равно успешно собралось. Надо что-то в настройках вашего проекта колдовать. :yes-sad:

Добавлено 17.02.19, 14:04
Впрочем, может оттого, что у меня VS 2017 Professional?, - не очень я в этих кашах разбираюсь. :blush:

VS 2017, memcpy()

Mikle — Sun, 17 Feb 2019 13:35:48 +0000

Mikle: Славян
В моём случае это так:

EXPORTS

PAINT

VS 2017, memcpy()

Славян — Sun, 17 Feb 2019 13:06:37 +0000

Славян: Добавил test.def в проект, всё успешно прошло:

EXPORTS

PAINT @1

VS 2017, memcpy()

Mikle — Sun, 17 Feb 2019 13:00:27 +0000

Mikle: Я эту проблему решил заменой memcpy() на соответствующий интринсик, но разобраться всё равно интересно.

VS 2017, memcpy()

Славян — Sun, 17 Feb 2019 12:58:48 +0000

Славян: А! Нет, это не баг, там какая-то своя хитрая схема. Надо вспоминать. Всё там норм!

VS 2017, memcpy()

Mikle — Sun, 17 Feb 2019 12:57:26 +0000

Mikle: Там ещё .def файл присоединён, чтобы избавиться в именах от окончаний типа "@24", экспортируется функция с именем PAINT.
А линкер пишет об ошибке в _PAINT@24, вот тут у меня и сомнения возникают, может баг студии, ведь в 2008 это работает. А без memcpy() работает и в 2017.

Цитата Славян @ 17.02.19, 12:51

и на такое компиляторы могут ругаться!

Ругается линкер.

VS 2017, memcpy()

Славян — Sun, 17 Feb 2019 12:51:34 +0000

Славян: Действительно странно, у меня эти 6 строчек успешно в DLL собираются:

#include <memory>

extern "C" __declspec(dllexport) void __stdcall PAINT(int* src, int* dst, int w, int h, int ws, int wd)

{

memcpy( (void*)1, (void*)2, 3);

}

Наверное, всё же трабла в настройках проекта. :-?

Добавлено 17.02.19, 12:53
А мож надо всё же прямо привести int* к void*, а то (помнится) сейчас и на такое компиляторы могут ругаться!.. ???

Добавлено 17.02.19, 12:54
Э-э... или правильно сказать "компоновщики"? Короче, кто-то из них.

VS 2017, memcpy()

Mikle — Sun, 17 Feb 2019 12:30:04 +0000

Mikle:

Цитата Славян @ 17.02.19, 11:39

Вроде #include помогало.

Тот же эффект, что и от #include . Функция memcpy() видится, даже компилируется, она не линкуется.

VS 2017, memcpy()

Славян — Sun, 17 Feb 2019 11:39:38 +0000

Славян: Вроде #include помогало.

VS 2017, memcpy()

Mikle — Sun, 17 Feb 2019 11:29:32 +0000

Mikle: Есть проект на C++, Win32 dll, в нём никаких зависимостей, всё на самом низком уровне, из инклюдов только #include .
В проекте было много асм-вставок, решил переписать всё на C++, чтобы портировать на x64.
Использовались MMX инструкции, поэтому добавил #include , проблем не возникло.
В другом месте копировал память с помощью "rep movsd", переписал циклом - стало заметно медленнее, тогда решил задействовать memcpy(), для этого подключаю #include .
Использую VS 2017 Community.
Такая функция:

extern "C" __declspec(dllexport) void __stdcall PAINT(int* src, int* dst, int w, int h, int ws, int wd)

{

w = w * 4;

for (int y = 0; y < h; y++)

{

memcpy(dst, src, w);

dst += wd;

src += ws;

}

при компиляции даёт ошибку:

Цитата

Ошибка LNK2019 ссылка на неразрешенный внешний символ _memcpy в функции _PAINT@24

Этот же код в VS 2008 Express без проблем компилируется и корректно работает.
Куда копать?