Итераторы

[Авварон]

можно просто перегрузить функцию для ссылки и указателя без шаблонов=)

Код:

void foo(Type &t) {...}
void foo(Type *t) {foo(*t); }

[Igors]

 

можно просто перегрузить функцию для ссылки и указателя без шаблонов=)

Код:

void foo(Type &t) {...}
void foo(Type *t) {foo(*t); }

Не уловил идею

[Fregloin]

Вам уже указали решение вашей пробелмы - std::advance

[Igors]

Вам уже указали решение вашей пробелмы - std::advance

"А можно пример?" Потому что не вижу каким боком здесь поможет advance

И что там за "плохо скрываемое раздражение"? Нет удобного решения - ну у меня его тоже нет.

[Racheengel]

Навеяло:

Джун: так, сейчас по быстрому наговнокодим, так, ну скомпилилось, ну вроде не падает... иногда... фух, в продакшен.

Мидл: так, что эти джуны там наваяли, ой блин, говнокод, лапша, нет структуры и ПолётаМысли... Ну ща тут абстрактную шаблонную фабрику прикрутим, там визитор, тут обсервер... 95 из 100 тестов прошло, значит уже хорошо, эй, менеджер, готово!

Синьйор: так, блин, что за GOFнокод... Фабрики в лес, визиторы в лес, оставим пару классов, чтобы KISS и иже с ним... Ага, раз в 50 быстрее работает... готово

Тимлид: народ, давайте-ка код ревью по быстрому проведём, а то отдавать скоро.

Начальник разработки: так, что там в задаче сказано? А, найти площадь прямоугольника. Где там мой калькулятор...

[AkonResumed]

struct CBigClass {
...
 QList<CData> mData;
 QSet<CData *> mSelection;
...
};

Я бы сделал так:

Код:

struct CBigClass {
...
 QList<CData> mData;
 QSet<std::reference_wrapper<CData>> mSelection; 
...
};

Теперь тип элемента в контейнерах, можно сказать, одинаковый.

Если QSet<CData *> mSelection; нужно оставить, то сделайте zero-cost адаптер, чтобы оперировать ссылками, а не указателями:

Код:

struct CBigClass {
...
	QSet<std::reference_wrapper<CData>>& mSelectionAsRefs() 
	{
		static_assert(sizeof(CData*) == sizeof(std::reference_wrapper<CData>));
		return reinterpret_cast<QSet<std::reference_wrapper<CData>>&>(mSelection);
	}
};

Итак, std::reference_wrapper внутренне реализован как указатель, но имеет семантику ссылки. Собственно, она часто и используется с контейнерами.

Теперь адаптер: он не имеет накладных расходов (ссовсем), поскольку размер std::reference_wrapper == размеру указателя, и мы жестко реинтерпретируем. Но равенство размеров не гарантируется (не уверен), поэтому мы это проверяем в compile-time static_assert-ом.

И еще. В вашем QSet<CData *> mSelection; могут быть нулевые указатели? Предполагаю - нет. Если указатель не может быть нулевым - используйте ссылку (во всех таких случаях). Читаемость и строгость кода же повышаются. Хотя, в плане читаемости - спорно (std::reference_wrapper<> - много букв  ).

[Igors]

Да, интересный приемчик с reference_wrapper, не знал, спасибо

[AkonResumed]

Не вопрос. Да и это делеко не последний писк моды - это c C++11.

[Авварон]

Код:

return reinterpret_cast<QSet<std::reference_wrapper<CData>>&>(mSelection);

Это UB

[AkonResumed]

Это не UB. В худшем (маловероятном) случае, это compile-time error. Потому что так перед грязным хаком (reinterpret_cast) идет

Код:

static_assert(sizeof(CData*) == sizeof(std::reference_wrapper<CData>));

что делает хак чистым. Прпосто вдумайтесь в смысл условия ассерта.

Если уж подходить совсем параноидально, то в теории UB возможен, но такая реализация std::reference_wrapper лишена практического смысла. Например,  std::reference_wrapper хранит не исходный указатель, а смещенный на 5, например, или в форме инверсных битов. 

[Old]

Ну это все таки грязный хак.
А что если у QSet для указателей и нет разные специализации?

[Авварон]

Это UB, в общем случае нельзя делать reinterpret_cast между unrelated типами.

https://en.cppreference.com/w/cpp/language/reinterpret_cast

std::pair<int, int> and std::pair<const int, int> are not similar.

Компилятор предполагает что 2 ссылки/указателя на различные типы не могут ссылаться не одну область памяти (strict alias rule) и строит на этом оптимизации.
reinterpret_cast ломает это предположение - если компилятор тупенький и не оптимизирует, то это будет работать, если умный, то сломается. UB.

[Авварон]

Ну или более сложный пример, вы знаете что на вашей платформе sizeof(bool) == sizeof(int8_t) (ну или char).
Значит вы можете сделать

Код:

vector<bool> bools;
auto &chars = reinterpret_cast<vector<char>&>(bools);

?

[AkonResumed]

А что если у QSet для указателей и нет разные специализации?

Ах, таки вы меня подсекли! Про возможную специализацию внешнего типа я упустил. В данном случае специализации QSet нет, работать будет. Но в общем случае - да, это нужно учитывать.

Авварон,

Код:

vector<bool> bools;
auto &chars = reinterpret_cast<vector<char>&>(bools);

Как метко подметил Old, причина этого UB в специализации vector<bool>. Она хранит биты, а не байты.

По поводу strict alias rule и оптимизации (привет restrict poiners): А как вы соотнесете это с placement new(), например?

[Авварон]

Ах, таки вы меня подсекли! Про возможную специализацию внешнего типа я упустил. В данном случае специализации QSet нет, работать будет. Но в общем случае - да, это нужно учитывать.

Там внутри могут быть всякие traits которые для разных типов разные.
Но в любом случае, даже если битовое представление одинаковое, это UB.

По поводу strict alias rule и оптимизации (привет restrict poiners): А как вы соотнесете это с placement new(), например?

В чем проблема-то? Единственный валидный юзкейз reinterpret_cast между разными типами это каст к массиву байт (или void*) и обратно.
Компилятор знает что вон тот char buffer[] потенциально может алиаситься с вот этим указателем и сгенерит менее производительный код.
placement new как раз подпадает под это - буфер чаров может алиаситься (и делает это) с указателем на произвольный T.
А вот любые другие типы (например int* в double*) алиаситься не могут.