так что, теперь с наличием лямбд имеет смысл поведение определять не в методах а в лямбдах которые, потом можно динамечески менять на любые?
например для избежания наследования мы теперь может композитить, и то что мы раньше перегружали теперь можно определит как std::fucntion у поля класса и подменять динамически
с одной стороны изврат делающий из с++ скриптовой язык с другой типобезопасность не страдает
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>так что, теперь с наличием лямбд имеет смысл поведение определять не в методах а в лямбдах которые, потом можно динамечески менять на любые? K>например для избежания наследования мы теперь может композитить, и то что мы раньше перегружали теперь можно определит как std::fucntion у поля класса и подменять динамически
Смысл есть если есть потребность менять имплементацию динамически, либо если методы класса, которые подразумеваются быть виртуальными, между собой не связаны по смыслу (т.е. не имплементируют отдельный интерфейс ). В противном случае лучше выделить отдельный интерфейс и наследовать имплементации от него, т.к. это лучше выразит семантику и повысит грепабельность кода.
Re[2]: Lambda решает вопрос модификации поведения при композиции?
Здравствуйте, turbocode, Вы писали:
K>>с одной стороны изврат делающий из с++ скриптовой язык с другой типобезопасность не страдает T>Для скриптового языка нужен Eval которым в С++ и не пахнет.
K>>>с одной стороны изврат делающий из с++ скриптовой язык с другой типобезопасность не страдает T>>Для скриптового языка нужен Eval которым в С++ и не пахнет.
EP>Пахнет, например Cling, в котором REPL
Очевидно что имелась ввиду встроенная поддержка eval в С++ без сторонних библиотек.
Re[4]: Lambda решает вопрос модификации поведения при композиции?
Здравствуйте, turbocode, Вы писали:
EP>>Пахнет, например Cling, в котором REPL T>Очевидно что имелась ввиду встроенная поддержка eval в С++ без сторонних библиотек.
Совсем не очевидно. Если вводить подобные искусственные ограничения, то так C++ вообще без компилятора останется, ибо они все "сторонние"
Смысл eval в инкрементальном добавлении и выполнении кода — вот Cling это и даёт.
Re[5]: Lambda решает вопрос модификации поведения при композиции?
EP>Совсем не очевидно. Если вводить подобные искусственные ограничения, то так C++ вообще без компилятора останется, ибо они все "сторонние"
Имелась ввиду поддержка на уровне синтаксиса С++.
EP>Смысл eval в инкрементальном добавлении и выполнении кода — вот Cling это и даёт.
Не понятно как оно взаимодействует с внешним окружением, например как байндить внешние функции классов и использовать их внутри скрипта.
Re: Lambda решает вопрос модификации поведения при композиции?
Здравствуйте, Kingofastellarwar, Вы писали:
K>так что, теперь с наличием лямбд имеет смысл поведение определять не в методах а в лямбдах которые, потом можно динамечески менять на любые?
Вряд ли это всегда удобно.
Когда поведение определяется двумя методами, которые ещё имеют общий контекст, то что, тащить tuple с двумя function и одним shared_ptr<void> , держащим этот общий контекст?
K>делающий из с++ скриптовой язык
но кстати да, иногда удобно сначала попробовать на лямбдах, а потом сделать "по-нормальному"
