Russian Qt Forum
Март 29, 2024, 15:43 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 2 [3]   Вниз
  Печать  
Автор Тема: Нетипичное наследование  (Прочитано 14554 раз)
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2094



Просмотр профиля
« Ответ #30 : Октябрь 12, 2017, 21:04 »

Цитировать
Так что в данном случае просто auto будет достаточно.
Нет, не всегда.. Если нет копирующего конструктора, определённого пользователем, то будет вызван конструктор по умолчанию (поправьте, если не так), что может быть затратно..

Цитировать
Скукатень. А где здесь развесистые switch'и?  Улыбающийся
Это да - не канонично  Смеющийся
« Последнее редактирование: Октябрь 12, 2017, 21:20 от m_ax » Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #31 : Октябрь 12, 2017, 23:08 »

auto&& - это т.н. "универсальная ссылка", которая биндится либо к T&, либо к T&& в зависимости от того, что стоит справа от = (т.е. в случае цикла, что возвращает operator* итератора).
Основной юзкейз использования - если предполагается делать std::forward.

Т.е., например, можно сделать итератор, который будет мувать элементы из контейнера, если контейнер - временный объект (перегрузить begin()&& и end)&&).
На практике такое, конечно же, не всречается, даже разрабы стандарта не столь упороты.

Минусом у auto&& является то, что она теряет константность, если контейнер в for-е неконстантный, а итератор возвращает ссылку.
Самое смешное, что тут поможет qAsConst, который сделан, чтобы залечить проблемы implicit sharing.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #32 : Октябрь 13, 2017, 12:04 »

Да, именно так. Это тот самый случай, когда необходимо разруливать (развлетвлять) поведение системы в зависимости только от пренадлежности её к определённому типу, минуя необходимость создавать объект класса.. Это классический паттерн класс харрактеристик (type traits). И да, он работает (и как это видно из контекста) в тех случаях, когда  "checkCommand не обязан иметь внутренние данные команды чтобы он мог что-то решать."  Улыбающийся Короче, всё решается в зависимости только от типа.
Очень сомневаюсь что на голом типе/статиках можно много решить

Нет, не всегда.. Если нет копирующего конструктора, определённого пользователем, то будет вызван конструктор по умолчанию (поправьте, если не так), что может быть затратно..
Конструктор копирования по умолчанию, который автоматычно вызывает конструкторы копирования для всех членов.

А все-таки как охотно подхватывается любой "синтаксический сахар"  Улыбающийся До самой задачи дела никому нет, главное - чтобы написано было круто. А еще говорят что погоня за модой - чисто женская черта  Улыбающийся
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4349



Просмотр профиля
« Ответ #33 : Октябрь 13, 2017, 12:09 »

А все-таки как охотно подхватывается любой "синтаксический сахар"  Улыбающийся До самой задачи дела никому нет, главное - чтобы написано было круто. А еще говорят что погоня за модой - чисто женская черта  Улыбающийся
Улыбающийся
Как раз задачу мы и решали, в отличие от вас. Улыбающийся
Мы добились того, что необходимые флаги для каждой команды можно описывать при создании новой команды и проверять их без создания экземпляра команды.
Если в дальнейшем, для принятия решения, понадобится экземпляр класса задачи, его всегда можно создать.
Записан
Страниц: 1 2 [3]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.049 секунд. Запросов: 23.