Сообщение Re[15]: Функции должны быть компактными от 27.04.2016 18:04
Изменено 27.04.2016 19:15 __kot2
Здравствуйте, IT, Вы писали:
IT>Наследоваться не получится, т.к. не мы создаём его экземпляры. Делегировать хоть обделегируйся, но рано или поздно мы всё равно придём к тому же самому switch.
вообще не понимаю в чем проблема сделать UnaryExpression и BinaryExpression который будет реализовывать чисто виртуальный метод sub_expressions и выдавать соотв-но их.
или, чтобы, для перфоманса, не создавать временного списка, можно for_every_subexpression прямо соб-но его виртуальным мембером и сделать
IT>Наследоваться не получится, т.к. не мы создаём его экземпляры. Делегировать хоть обделегируйся, но рано или поздно мы всё равно придём к тому же самому switch.
вообще не понимаю в чем проблема сделать UnaryExpression и BinaryExpression который будет реализовывать чисто виртуальный метод sub_expressions и выдавать соотв-но их.
или, чтобы, для перфоманса, не создавать временного списка, можно for_every_subexpression прямо соб-но его виртуальным мембером и сделать
Re[15]: Функции должны быть компактными
Здравствуйте, IT, Вы писали:
IT>Наследоваться не получится, т.к. не мы создаём его экземпляры. Делегировать хоть обделегируйся, но рано или поздно мы всё равно придём к тому же самому switch.
вообще не понимаю в чем проблема сделать UnaryExpression и BinaryExpression который будет реализовывать чисто виртуальный метод sub_expressions и выдавать соотв-но их.
или, чтобы, для перфоманса, не создавать временного списка, можно for_every_subexpression прямо соб-но его виртуальным мембером и сделать
аа, похоже понял — такие кривые экземпляры генерируются где-то внутри и нам придется перегенерировать все дерево выражений, если мы хотим работать с ним удобно. то есть основная проблема в том, что в мс придумали архитектуру с которой невыносимо работать. ну, чего ж тут удивительного. либо мы создаем дерево-враппер и работаем по-человечески, либо так криво со свичами, как говорится, в заданном стиле. хотя переименовать пару методов все равно стоит, хотя бы для того, чтобы понятно было где дерево, где его обход, а где код обработки какого рода операций
IT>Наследоваться не получится, т.к. не мы создаём его экземпляры. Делегировать хоть обделегируйся, но рано или поздно мы всё равно придём к тому же самому switch.
вообще не понимаю в чем проблема сделать UnaryExpression и BinaryExpression который будет реализовывать чисто виртуальный метод sub_expressions и выдавать соотв-но их.
или, чтобы, для перфоманса, не создавать временного списка, можно for_every_subexpression прямо соб-но его виртуальным мембером и сделать
аа, похоже понял — такие кривые экземпляры генерируются где-то внутри и нам придется перегенерировать все дерево выражений, если мы хотим работать с ним удобно. то есть основная проблема в том, что в мс придумали архитектуру с которой невыносимо работать. ну, чего ж тут удивительного. либо мы создаем дерево-враппер и работаем по-человечески, либо так криво со свичами, как говорится, в заданном стиле. хотя переименовать пару методов все равно стоит, хотя бы для того, чтобы понятно было где дерево, где его обход, а где код обработки какого рода операций