Вопрос по C++
есть ли способ "научить" функцию принимать TMBMCpart* в качестве одного или обоих аргументов? Вариант с использованием overloading и написанием ещё трёх копий этой функции не рассматривается.
bool SameSign(TMBMCpart *ix, TMBMCpart *iy)
{
return (ix && iy && ix->pdgid*iy->pdgid>0);
}
Не?
Ну это примерно то же, что и перегрузка. Хотелось бы иметь одну функцию, которая бы сама по необходимости dereference-ила аргументы и выполняла код.
Заодно второй вопрос: какой код будет эффективнее, если делать тупую перегрузку -
или
Заодно второй вопрос: какой код будет эффективнее, если делать тупую перегрузку -
bool SameSign(TMBMCpart* ix, TMBMCpart iy)
{
return SameSign(*ix, iy);
}
или
bool SameSign(TMBMCpart* ix, TMBMCpart iy)
{
return (ix->pdgid*iy.pdgid
}
Или ты о таком?
Так демоны тьмы пожрут твою душу!
class A {
int f1, f2;
public:
A(int f1 = 0, int f2 = 0): f1(f1 f2(f2) {}
A(const A *a) {
if(a) {
f1 = a->f1;
f2 = a->f2;
}
}
int p const {return f1 * f2;}
};
#include <iostream>
void print(A a) {
std::cout << a.p << std::endl;
}
int main {
A *a = new A(10, 15);
print(a);
delete a;
}Так демоны тьмы пожрут твою душу!
Заодно второй вопрос: какой код будет эффективнее, если делать тупую перегрузку -Второй, разумеется. У тебя параметры передаются по значению, в первом происходит два копирования, YOBA.
Всё ясно - я хочу странного (с). Ладно, будем ручками делать. Спасибо!
Так демоны тьмы пожрут твою душу!
Ты хочешь экзотичного конструктора. 
Ты делаешь неправильно.
Тебе следует делать
В зависимости от ситуации ещё лучше может быть подключить буст и передавать const shared_ptr<TMBMCpart> &.
Тебе следует делать
bool SameSign(const TMBMCpart & ix, const TMBMCpart & iy)и потихоньку изживать поинтеры из всех каллеров.
В зависимости от ситуации ещё лучше может быть подключить буст и передавать const shared_ptr<TMBMCpart> &.
> const shared_ptr<TMBMCpart> &
с констом и ссылкой это еще больший изврат, нежели просто указатели
с констом и ссылкой это еще больший изврат, нежели просто указатели
В зависимости от ситуации ещё лучше может быть подключить буст и передавать const shared_ptr<TMBMCpart> &.Ага, а потом отхватывать жуткие тормоза при lock/unlock.
не надо смешивать безопасность и производительность
это плохой троллинг
это плохой троллинг
А при чем тут безопасность? Где использование shared_ptr добавляет безопасности? Если уж говорить о безопасности, то в большинстве случаев достаточно auto(unique)_ptr. И чем вариант f(const shared_ptr<T>&) лучше варианта f(const T*) или f(const T&)?
потихоньку изживать поинтеры из всех каллеров.Как только их в фреймворке изведут - так сразу.
И чем вариант f(const shared_ptr<T>&) лучше варианта f(const T*) или f(const T&)?Очевидно тем, что в первом случае можно ссылку на шареный объект куда-то сохранить и иметь ее там так долго, как захочешь?
Откуда лок/анлок если я передаю по ссылке?
Алсо, ты в курсе, что если нет contention, то "тормоза" при передаче не по сыылке занимают в районе 15-20 циклов, то есть как промах мимо L1 кэша?
А смысл в этом как Возбу говорит: конечно, если ты пишешь функцию у которой ты единственный юзер, и ты хочешь передавать туда какой-то объект который у тебя есть непосредственно, то передавай по ссылке конечно. А если её будет дёргать кто-нибудь другой, и она с объектом будет делать что-то нетривиальное, то обычно лучше shared_ptr всё-таки!
@propellerman: ну, я тут глянул на интервьюшечку с Саттером, Александреску и Мейерсом недавно, и они все трое говорили что нужно передавать shared_ptr по конст ссылке почти всегда (кроме дико редких случаев, где ты и за передачу const string& можешь огрести)!
Алсо, ты в курсе, что если нет contention, то "тормоза" при передаче не по сыылке занимают в районе 15-20 циклов, то есть как промах мимо L1 кэша?
А смысл в этом как Возбу говорит: конечно, если ты пишешь функцию у которой ты единственный юзер, и ты хочешь передавать туда какой-то объект который у тебя есть непосредственно, то передавай по ссылке конечно. А если её будет дёргать кто-нибудь другой, и она с объектом будет делать что-то нетривиальное, то обычно лучше shared_ptr всё-таки!
@propellerman: ну, я тут глянул на интервьюшечку с Саттером, Александреску и Мейерсом недавно, и они все трое говорили что нужно передавать shared_ptr по конст ссылке почти всегда (кроме дико редких случаев, где ты и за передачу const string& можешь огрести)!
Я так не делаю вот по какой причине: когда ты передаешь по конст ссылке объект, то он не изменяем и делая копию, ты не трогаешь сам аргумент. И я так привык уже за много лет относиться к константно-ссылочным аргументам. А когда также передают шаред, мои шаблоны благополучно рвутся. Т.е. в функциях аргументы-шареды я определяю либо как shared_ptr<T>, либо shared_ptr<const T>.
Мы похоже спорим про разное. Что значила твоя фраза:
Следует ли из этого, что ты предлагаешь хранить большинство объектов на куче, причем обернутыми в shared_ptr?
Или это просто совет, что в случаях, когда используешь shared_ptr его следует передавать по const&?
Если первое, то можно поспорить.
Если второе, то я согласен, но непонятно, к чему была эта фраза в контексте данного треда?
В зависимости от ситуации ещё лучше может быть подключить буст и передавать const shared_ptr<TMBMCpart> &?
Следует ли из этого, что ты предлагаешь хранить большинство объектов на куче, причем обернутыми в shared_ptr?
Или это просто совет, что в случаях, когда используешь shared_ptr его следует передавать по const&?
Если первое, то можно поспорить.
Если второе, то я согласен, но непонятно, к чему была эта фраза в контексте данного треда?
Т.е. в функциях аргументы-шареды я определяю либо как shared_ptr<T>, либо shared_ptr<const T>.Насколько я помню и понимаю, передавать shared_ptr по ссылке тупо быстрее, т.к. нет лишних изменения счетчика. Но чаще всего это, наверное, не играет никакой роли.
Оставить комментарий
Bird_V
Есть такая функция:Вопрос: есть ли способ "научить" функцию принимать TMBMCpart* в качестве одного или обоих аргументов? Вариант с использованием overloading и написанием ещё трёх копий этой функции не рассматривается.