Войти
ФлеймФорумПрограммирование

C++20 утвердили (28 стр)

Страницы: 127 28 29 3033 Следующая »
#405
14:01, 23 ноя 2020

3dhater
> У современного C++ появилась возможность грузить .dll и получать адреса
> функций?
Так она давно есть. :trf:

void main()
{
  HINSTANCE hModule=NULL;
  typedef  BOOL (WINAPI MESS)(UINT);
  MESS* me=NULL;
  hModule=::LoadLibrary("user32.dll");
  if (hModule!=NULL)
  {
    me=(MESS*)::GetProcAddress((HMODULE)hModule,"MessageBeep");
    if (me!=NULL)
    {
      UINT type=1;
      BOOL result;
      result=(*me)(type);
    }
    else cout << "Error Load function" << endl;
    ::FreeLibrary(hModule); 
  }
  else cout << "error load Dll" << endl;
#406
14:08, 23 ноя 2020

3dhater
> У современного C++ появилась возможность грузить .dll

c++ знает про dll?

#407
14:13, 23 ноя 2020

Хотелось бы не писать\копипастить обёртки для работы с .dll\.so

раз два и готово типа так

std::load_dl("mylib.dll");
#408
14:28, 23 ноя 2020

3dhater
в dll\so нет информации о сигнатурах функций, только имена. Так что тут проблема не на стороне крестов.

#409
15:35, 23 ноя 2020

3dhater
это не задача языка, ты еще спроси появилась ли в крестах возможность включать чайник по утрам. По типу:

std::turn_electricity_on("Teapot-sn7891");
#410
15:43, 23 ноя 2020

Aroch
> это не задача языка, ты еще спроси появилась ли в крестах возможность включать
> чайник по утрам. По типу:
>
>

ненадо придираться

filesystem добавили почему бы и всё остальное не добавить.

#411
15:51, 23 ноя 2020

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

3dhater
> filesystem добавили почему бы и всё остальное не добавить.
Нашлись те, кому filesystem сильно нужен был, вот его и протолкнули в стандарт. А тех, кому нужно по 100 раз на дню грузить руками динасические библиотеки - тех не нашлось.

#412
15:53, 23 ноя 2020

3dhater
> почему бы и всё остальное не добавить.

Потому же, почему и в остальные языки не добавили, - потому что DLL это не модуль и автоматически распарсить и подключить произвольную библиотеку невозможно, в общем случае из-за нейм-менглинга и заранее неизвестной конвенции вызова аргументов.

#413
17:17, 23 ноя 2020

0iStalker
> автоматически распарсить и подключить произвольную библиотеку невозможно, в
> общем случае из-за нейм-менглинга и заранее неизвестной конвенции вызова
> аргументов

А в С++ не появилось какой-нибудь фичи, позволяющей заранее описать совокупность типовых и нетиповых параметров шаблона одной сущностью, чтоб потом эту одну сущность подставлять?

Тогда могло бы быть что-то типа такого

mylib.h

#define MYLIB_FILE "mylib"

typedef string __stdcall Myfunc1Type(int, string);
templatepack myfunc1pack <mangletype = std::dl::Mangle::VC, funcname = "myfunc1", Myfunc1Type>;

typedef int __stdcall Myfunc2Type();
templatepack myfunc2pack <mangletype = std::dl::Mangle::VC, funcname = "myfunc2", Myfunc2Type>;

файл, подгружающий либу

#include <mylib.h>

HLIB hlib = std::dl::load(MYLIB_FILE);

Myfunc1Type myfunc1 = std::dl::find<myfunc1pack>(hlib);
string result = myfunc1(1, "qwerqwer");

Myfunc2Type myfunc2 = std::dl::find<myfunc2pack>(hlib);
int x = myfunc2();

UPD. А, даже не так, это ж C++ :)

файл, подгружающий либу

#include <mylib.h>

HLIB hlib = std::dl::load(MYLIB_FILE);

Myfunc1Type myfunc1 = hlib.find<myfunc1pack>();
string result = myfunc1(1, "qwerqwer");

Myfunc2Type myfunc2 = hlib.find<myfunc2pack>();
int x = myfunc2();
#414
18:07, 23 ноя 2020

https://www.boost.org/doc/libs/1_74_0/doc/html/boost_dll.html
На сколько понимаю Полухин хочет её в стандарт пропихнуть.

#415
19:58, 23 ноя 2020

0iStalker
> ну кто же виноват, что нормального языка без эзотерики и мусоросборщиков с
> байткодами и виртуальными машинами никто так и не придумал.
Тут проблема не в языке, а в API/ABI.
Вот есть Rust (возлагал надежды, но сильно разочаровался).
Смотрим, если на нём игровые движки: есть, но все они полагаются на нижнем слое в биндинги к SDL2/GLFW и тому подобные либы.
Т.е. если "нормальный язык" (а это будет смена "парадигмы") сделают нужно будет еще и на нем переписать вообще все базовые библиотеки для предметной области (например для геймдева).
Маловероятно.

>Что мешает сделать компилируемый язык, который не будет С++, я без понятия.
Ну вот есть FreePascal. И что?

>без эзотерики
Ну, кому эзотерика, а кому прогресс и будущее программирования.

#416
20:12, 23 ноя 2020

ffinder
> Т.е. если "нормальный язык" (а это будет смена "парадигмы") сделают нужно будет
> еще и на нем переписать вообще все базовые библиотеки для предметной области
> (например для геймдева).
> Маловероятно.

Можно не переписывать, а пометить биндинги как unsafe код.

#417
20:13, 23 ноя 2020

Went
> Столько копий ломается вокруг этого несчастного управления памятью... Долбаный
> стыд. Есть вопросы намного интереснее.
Конечно есть.
Например, сменить доминирующую "парадигму" с клонов Алгола и пожеланий её улучшения.

#418
20:26, 23 ноя 2020

gamedevfor
> Можно не переписывать, а пометить биндинги как unsafe код.
Сейчас я могу сказать, что нет доверия к unsafe, ты возразишь, что unsafe это не вседозволенность, а только отключение нескольких проверок компилятора...
Проблема не в языке. Проблема в том, что к языку нужны биндинги к библиотекам.
А к С и С++ они не нужны. C API это lingua franca - общий стандарт для библиотек. И пока С будет занимать это положение ничего не изменится, ни один "просто компилируемый язык" не сможет конкурировать с С и С++ только из-за этого одного факта.
Вот есть например транспайлеры типа Nim (и даже Kotlin) и еще всяких других "просто компилируемых языков" в С.
А почему? Ведь можно "просто" написать биндинги? Можно. Но в С и С++ их просто не нужно писать, их пишут авторы библиотек. А вот к Rust'у - нужно.

#419
20:42, 23 ноя 2020

ffinder
> А к С и С++ они не нужны.
То есть файлики opengl32.h и opengl32.lib не нужны, дллки сразу можно вызывать?

Страницы: 127 28 29 3033 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.