Альтернатива ctor / inventory при компиляции в wasm? - PullRequest
1 голос
/ 12 июля 2020

Ящик ctor в настоящее время не поддерживает веб-сборку, хотя идет активное обсуждение того, как это исправить .

Хотя я хорошо осведомлен о проблемах, связанных с stati Инициализация c, исходящая из C ++, возможность регистрировать вещи с помощью фабрики при запуске - очень удобная возможность и во многих случаях необходима, чтобы избежать нарушения принципа DRY. Без него каждый раз, когда вы хотите добавить новую возможность в свой factory, вам нужно добавить отдельную строку кода в main(), возможно, больше строк, если вам нужно импортировать новую функцию. Это быстро становится утомительным.

Мне интересно, можно ли построить что-то эквивалентное (по крайней мере, когда все, что вы хотите зарегистрировать, сосредоточено внутри одного ящика), используя макрос процедурных атрибутов и build.rs. Макрос будет использоваться для обозначения функций, которые я хочу зарегистрировать, и его реализация сохранит пути модулей ("crate::your::registered_function") этих функций в стороне где-то в файле, но в противном случае будет просто сквозной передачей. Тогда build.rs сгенерирует функцию, которая вызывает все функции, перечисленные в файле, и я бы main() вызвал эту одну функцию вручную.

  • Есть ли другой трюк, который будет работать вместо этого ?
  • Существует ли где-нибудь реализация этого, которую я мог бы использовать в качестве ссылки?
  • Как процедурный макрос фактически генерирует путь к модулю для вызываемой функции? Существует module_path!, но при вызове из определения процедурного макроса он даст путь к модулю для макроса, а не путь к модулю, связанный с тем, во что будет расширяться TokenStream. Макрос может сгенерировать вызов module_path!, но это не будет выполняться до тех пор, пока не будет запущена последняя программа.
...