Сообщение Re[2]: Интерфейс плагина и его vtable от 12.10.2017 9:13
Изменено 12.10.2017 9:41 AlexGin
Re[2]: Интерфейс плагина и его vtable
Здравствуйте, uzhas, Вы писали:
U>вы там определитесь нужна ли обратная совместимость со старыми плагинами или нет.
Вообще-то НЕ обязательна.
Так как все плагины всё равно завязаны на головное приложение.
Посторонних разработчиков/компаний, которые бы занимались клепанием плагинов к нашей системе нет.
U>как только определитесь, то и решение сможете принять
Ну ИМХО для решения важно также и смотреть вперёд — сегодня совместимость не актуальна, а завтра...
U>насчет обратной совместимости: я работал с подобной системой и там виртуальные методы добавлялись в конец (там обязательно надо было поддерживать обратную совместимость) и вот однажды после добавления очередного метода совместимость сломалась.
U>оказалось, что если добавляется метод с именем, который уже есть (но с другим аргументами, к примеру), то студийный компилятор ломает порядок методов, группируя методы с одинаковым именем
U>так что будьте внимательны
Перегрузка виртуальных методов, в общем-то также может иметь место. Здесь спорить не буду.
В общем — спасибо, за совет, примем к сведению.
U>вы там определитесь нужна ли обратная совместимость со старыми плагинами или нет.
Вообще-то НЕ обязательна.
Так как все плагины всё равно завязаны на головное приложение.
Посторонних разработчиков/компаний, которые бы занимались клепанием плагинов к нашей системе нет.
U>как только определитесь, то и решение сможете принять
Ну ИМХО для решения важно также и смотреть вперёд — сегодня совместимость не актуальна, а завтра...
U>насчет обратной совместимости: я работал с подобной системой и там виртуальные методы добавлялись в конец (там обязательно надо было поддерживать обратную совместимость) и вот однажды после добавления очередного метода совместимость сломалась.
U>оказалось, что если добавляется метод с именем, который уже есть (но с другим аргументами, к примеру), то студийный компилятор ломает порядок методов, группируя методы с одинаковым именем
U>так что будьте внимательны
Перегрузка виртуальных методов, в общем-то также может иметь место. Здесь спорить не буду.
В общем — спасибо, за совет, примем к сведению.
Re[2]: Интерфейс плагина и его vtable
Здравствуйте, uzhas, Вы писали:
U>вы там определитесь нужна ли обратная совместимость со старыми плагинами или нет.
Вообще-то НЕ обязательна.
Так как все плагины всё равно завязаны на головное приложение.
Посторонних разработчиков/компаний, которые бы занимались клепанием плагинов к нашей системе пока нет.
Точнее — пока что не предвидится.
U>как только определитесь, то и решение сможете принять
Ну ИМХО для решения важно также и смотреть вперёд — сегодня совместимость не актуальна, а завтра...
U>насчет обратной совместимости: я работал с подобной системой и там виртуальные методы добавлялись в конец (там обязательно надо было поддерживать обратную совместимость) и вот однажды после добавления очередного метода совместимость сломалась.
U>оказалось, что если добавляется метод с именем, который уже есть (но с другим аргументами, к примеру), то студийный компилятор ломает порядок методов, группируя методы с одинаковым именем
U>так что будьте внимательны
Это интересный факт.
Перегрузка виртуальных методов, в общем-то также может иметь место. Здесь спорить не буду.
Получается, что совместимость основанная на таком предположении, что добавляем вирт-методы в конец — несостоятельная
В общем — спасибо, за совет, примем к сведению.
U>вы там определитесь нужна ли обратная совместимость со старыми плагинами или нет.
Вообще-то НЕ обязательна.
Так как все плагины всё равно завязаны на головное приложение.
Посторонних разработчиков/компаний, которые бы занимались клепанием плагинов к нашей системе пока нет.
Точнее — пока что не предвидится.
U>как только определитесь, то и решение сможете принять
Ну ИМХО для решения важно также и смотреть вперёд — сегодня совместимость не актуальна, а завтра...
U>насчет обратной совместимости: я работал с подобной системой и там виртуальные методы добавлялись в конец (там обязательно надо было поддерживать обратную совместимость) и вот однажды после добавления очередного метода совместимость сломалась.
U>оказалось, что если добавляется метод с именем, который уже есть (но с другим аргументами, к примеру), то студийный компилятор ломает порядок методов, группируя методы с одинаковым именем
U>так что будьте внимательны
Это интересный факт.
Перегрузка виртуальных методов, в общем-то также может иметь место. Здесь спорить не буду.
Получается, что совместимость основанная на таком предположении, что добавляем вирт-методы в конец — несостоятельная
В общем — спасибо, за совет, примем к сведению.