АК
Окей, я рассматриваю где-то случай использования библиотеки в этом контексте?
Size: a a a
2020 July 25
VK
Мне трудно представить случай, где необходимо получить Н сишных колбеков
VK
С одинаковой сигнатурой, при этом.
АК
#include "../CallbackConnector/CallbackConnector.h"this = 000000000023F6E8
#include <iostream>
struct A {
using cb_t = void (*)();
cb_t func;
A() {
func = cbc::obtain_connector(
[this]() { std::cout << "this = " << (void*)this << "\n"; });
}
};
int main() {
A a, b;
a.func();
b.func();
}
this = 000000000023F6E8
вот пример, @Valentyn_Korniienko предложи его решение, чтобы this выводился разным
АК
Мне трудно представить случай, где необходимо получить Н сишных колбеков
очень легко.
возьмём кнопку, которая что-то где-то биндит. складываем кнопки в вектор (у нас ведь может быть массив кнопок?) - бабах
возьмём кнопку, которая что-то где-то биндит. складываем кнопки в вектор (у нас ведь может быть массив кнопок?) - бабах
VO
или просто описание интерфейса в конфиге
VK
вот пример, @Valentyn_Korniienko предложи его решение, чтобы this выводился разным
Хм. Если тег-инт - можно добавить в библиотеку счетчик, чтобы получать теги для создания сигнатуры?
VO
сигнатура создается на этапе компиляции
VO
впрочем можно за собой таскать libllvm...
АК
Хм. Если тег-инт - можно добавить в библиотеку счетчик, чтобы получать теги для создания сигнатуры?
Счётчик времени компиляции, а длина цикла рантаймовая
O
for (int i = 0; i < rand() % 5; i++) {
cbc::obtain_connector(...);
}
удачи с прописыванием теговВ целом, можно заранее в компил-тайме нагенерировать какое-то максимальное число инстанцирований функции, а потом уже в рантайме выбирать нужные
АК
В целом, можно заранее в компил-тайме нагенерировать какое-то максимальное число инстанцирований функции, а потом уже в рантайме выбирать нужные
Ты сам прекрасно знаешь, почему это плохо в общем случае
VK
Ты сам прекрасно знаешь, почему это плохо в общем случае
Why?
VK
в целом и в общем, это будет работать
VK
А, если задача стоит в пробросе вектора сишных колбеков. Ну хм, это печаль
2020 July 26
AB
Планируют ли в си убрать каст funcptr->void* из implementation defined?
d
Планируют ли в си убрать каст funcptr->void* из implementation defined?
это технически сложно, пока есть упоротые пишущие под дос однозначно так и останется
d
да и наверняка до сих пор существуют другие упоротые архитектуры с адресами разных размеров