Много функций против множества лямбд?

Перед этим я опубликовал несколько вопросов, касающихся использования std::function вместо быстрых делегатов и способов хранения std::function в коллекции, чтобы продемонстрировать поведение события, которое можно добавлять и удалять. Я также поинтересовался лучшими практиками написания целой тонны маленьких классов типа EventArg, и это маленькое дизайнерское решение также было отложено. Это отличное сообщество!

Теперь, если отбросить преамбулу, у меня есть необходимая структура, и пришло время написать все обработчики, которые будут обрабатывать входящие данные. У меня есть std::map, это выглядит так:

typedef std::function<void(const CommandData&)> CommandDelegate;
typedef boost::shared_ptr<CommandDelegate> CommandDelegatePtr;
typedef std::map<short, CommandDelegatePtr> CommandMap;

И я хочу добавить к этому около 200 обработчиков. У меня есть выбор между стандартными функциями-членами и лямбда-выражениями.

Первое, о чем я подумал, когда думал о функциях-членах, это 200 объявлений и 200 реализаций и один большой исходный файл.

Вместо того, чтобы загрязнять мой класс всеми этими обработчиками, я подумал: «Ну, это всего лишь дескрипторы, почему бы не использовать лямбда-выражения? Это кажется достаточно простым, когда класс создан, он может назначить все эти анонимные функции карте. Работа сделана!

Потом я понял, что конструктор будет огромным. Я мог бы вызвать вспомогательную функцию «initializeMap», которая могла бы войти в свой собственный файл из-за размера.

Что вы думаете, ребята?

  1. 200 объявлений в файле .h, 200 реализаций (среди прочих функций) в файле .cpp
  2. 200 объявлений в файле .h, отдельный файл реализации 'handlers.cpp`
  3. Нет объявлений, 200 лямбда назначено в ctor
  4. Никаких объявлений, 200 лямбд, назначенных в функции initializeMap в собственном файле.

Заранее спасибо!


person Moo-Juice    schedule 08.01.2011    source источник


Ответы (2)


Мое мнение: используйте лямбда-выражения везде, где это возможно. Они гораздо более ремонтопригодны. Например, если у вас есть функция-член, вам придется обновлять объявление и определение каждый раз, когда вы его изменяете, а также вам нужно будет присвоить ему уникальное имя. Лямбды - лучший вариант. Если бы я мог иметь автоматический вывод типа для переменных-членов, я бы никогда не использовал функции-члены.

person Puppy    schedule 08.01.2011
comment
Я склоняюсь к лямбдам. Мне нравится идея, что в моем основном классе не будет кучи маленьких обработчиков. Итак, я предполагаю, что вопрос в том, чтобы назначить их - отсюда и вопрос о функции конструктора/инициализатора класса. - person Moo-Juice; 08.01.2011
comment
3 или 4, это действительно не имеет значения, хотя лично я предпочитаю больше исходных файлов, а не меньше, поскольку современные компиляторы могут компилировать одновременно. - person Puppy; 08.01.2011
comment
Я почти согласен, но хотел убедиться. Спасибо за ваш ответ. - person Moo-Juice; 08.01.2011

Вам действительно нужно, чтобы эти функции были динамическими? Потому что, если ваша единственная забота - не загрязнять ваш основной класс, есть лучшие (более быстрые) решения, такие как создание подкласса или просто разделение всего кода на несколько файлов.

Если у вас есть шапка с 200 функциями, но она никогда не меняется, это не так сильно раздует ваш проект, потому что будет просто лежать. С другой стороны, раздутый конструктор хуже, потому что выше вероятность того, что вам когда-нибудь придется его изменить, а затем ему придется перекомпилировать все эти 200 инициализаций.

Это время компиляции, вероятно, в любом случае не будет таким долгим, но зачем вообще беспокоиться?

Я бы просто сохранил их функции с объявлениями либо в вашем основном классе, либо в каком-то другом выделенном классе или файле, но не инициализируя их динамически в ctor.

person Cray    schedule 08.01.2011
comment
Не уверен, что вы имели в виду под «динамическим»... данные поступают с кодом, и необходимо вызвать соответствующий обработчик для этого кода, следовательно, карта с std::function. Если это не то, что вы имели в виду под динамикой, что вы имели в виду? - person Moo-Juice; 08.01.2011