Как сделать реализацию виртуального метода статическим?

Потому что либа для С, а не для С++ с сахаром. Попробуй использовать обертку

AbstractChannel *channel1_ptr = nullptr;

static int channel1_getChar(arg) {
  return channel1_ptr->getChar(arg);
}


int main() {
  channel1_ptr = new FileChannel();
  Parser->GetChanApi().onCHAN_Getc = &channel1_getChar;
}

Для начала, вам с «писателем» парсера нужно определиться, для какого языка пишется парсер — для С или для С++ ))

Если же парсеро-писатель окажется упертым и будет настаивать на интерфейсе в виде структуры с указателями на статичные функции, то не надо городить весь этот огород с абстрактным классом и его наследниками — можно реализовать несколько совершенно разных классов с соответствующими статичными методами, плюс, определить отдельно интерфейсную структуру для парсера. Ну и в каждом потоковом классе предусмотреть метод инициализации интерфейсной структуры (или, к примеру, ручками её заполнять).

Для начала, вам с «писателем» парсера нужно определиться, для какого языка пишется парсер — для С или для С++ ))

А какая разница? Если в callback не передаётся указатель на пользовательские данные, то и на голых сях придётся делать изврат с глобальной переменной. Налицо косяк архитектуры.

А какая разница? Если в callback не передаётся указатель на пользовательские данные, то и на голых сях придётся делать изврат с глобальной переменной. Налицо косяк архитектуры.

Если всё пишется на C++, то писателю парсера логичнее было бы принимать в качестве интерфейса указатель на тот самый абстрактный класс, а не указатель на структуру - это более правильное и элегантное решение. Ну и пользовательские данные при вызове callback-ов не нужны.

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

Проблема в том, что писатель парсера мыслит чисто в C-шном стиле (и интерфейс соответствующий придумал), а пользователь парсера (ТС) норовит мыслить только в терминах плюсовых классов с общим абстрактным родителем.

зачем же глобальная, достаточно скоупом файла обойтись :)

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

А объект, к которому привязан метод, который должен дёрнуться из этой твоей сишной функции, ты будешь в астрале хранить?

Его можно хранить где угодно. Внутри другого класса, например. Глобальной в этом случае будет только std::function

Если нет

не использовать такую либу, потому что она скорее всего кривая и так.

Тут в треде уже написали, что можно трамплин сделать.

Но да, колбеки без пользовательских данных говорят о том, что автор библиотеки плохо понимает, как проектировать библиотеки. Вероятно, и другие его решения тоже будут спорными.

Ну там коллбеки с пользовательскими данными есть. Например, парсер нашел в потоке метку времени - вызвал соответствующую функцию пользователя, передав в нее время. Нашел в потоке значащие данные - вызвал соответствующую функцию пользователя, передав в нее эти данные.

Эта шутка не смешная.

Куда тимлид смотрит? Он вам уже руки должен был отрубить.

Ребята, советовать ТАКОЕ для ПРОДАКШЕНА!

Так как библиотека суть быдлокод, соответственно, чтоб её заюзать нужно накатать свой быдлокод.

static в классе это фактически глобальная функция.

1. Если у тебя место общения с данной «библиотекой» только в одном месте, то заводишь глобальный метод и глобальную переменную и переключаешь её в нужный момент на свои реализации канала.

2. На каждую твою реализацию канала пишешь структуру со статическими методами и её возвращаешь в своём канале для общения с данной «библиотекой».

Но фактически для работы с данной «библиотекой» нужно программировать на с.

+1 только завернуть в статический класс вместо глобальной переменной статический сеттер