Comments 13
Sergey Kosarevsky,
мне одному так тяжело код с таким стилем читать? Или я очень придирчив?
мне одному так тяжело код с таким стилем читать? Или я очень придирчив?
0
А как Вам, например, вот такой стиль:
См. UnrealEngine\Engine\Source\Runtime\Engine\Private\ErrorChecking.cpp
FArchive& operator<<( UObject*& Object )
{
// Avoid duplicate entries.
if ( Object != NULL && !SerializedObjects.Contains(Object) )
{
SerializedObjects.Add(Object);
if ( !Object->IsA(UField::StaticClass())
&& (Object->NeedsLoadForClient() || Object->NeedsLoadForServer()) )
{
if (EditorContentPackages.Contains(Object->GetOutermost())
&& Object->GetOutermost() != Object )
{
ReferencedEditorOnlyObjects.Add(Object);
}
Object->Serialize(*this);
}
}
return *this;
}
См. UnrealEngine\Engine\Source\Runtime\Engine\Private\ErrorChecking.cpp
0
Очень впечатляет, однако это скорее демонстрация возможностей gcc оптимизатора. Как видно на последнем листинге, этот код не делает вообще НИЧЕГО в рантайм. Число итераций предвычисляется во время компиляции и все, всего одна инструкция, естественно что минимально рабочий код на может быть предвычислен.
Мне кажется ценность статьи в другом — часто во время тестирования надо как раз надурить оптимизатор и избежать оптимизации циклов, вот тут то мы теперь и будем знать что делать.
Мне кажется ценность статьи в другом — часто во время тестирования надо как раз надурить оптимизатор и избежать оптимизации циклов, вот тут то мы теперь и будем знать что делать.
+5
Очевидно, пока вызываемая функция не завершится, смарт-указатель в вызывающем коде будет жить, поэтому объект не будет уничтожен.
У меня все функции принимают обычный указатель, а не умный.
Вместо
я пишу
Мне кажется, так код выглядит проще. А если компилятор не заинлайнит
В шаблоне
У меня все функции принимают обычный указатель, а не умный.
Вместо
void Process(const clPtr<clTestObject>& ptr);
я пишу
void Process(const clTestObject* ptr);
Мне кажется, так код выглядит проще. А если компилятор не заинлайнит
Process
, код этой ф-ции будет ещё и короче (т.к. не надо доставать указатель из контейнера).В шаблоне
clPtr
есть оператор преобразования к указателю, поэтому в месте вызова функции я пишу так же — Process(smartPtr)
, не надо писать Process(smartPtr.get())
. 0
А если ссылка на смарт указатель это ссылка на поле объекта?
0
Возникает вопрос, зачем вообще передавать в функцию умный указатель? Если эта функция не оставляет у себя копий указателя — то лучше передавать в нее простой указатель, а не умный. А если она оставляет копии — то в любом случае придется выполнять операции со счетчиком ссылок. Оптимизация за счет передачи ссылки на умный указатель будет возможна и в этом случае. Но такая оптимизация — это исключение вызовов конструктора и деструктора при передаче объекта по значению — возможна для любого нетривиального типа объектов, а не только умных указателей.
+1
Об этом и говорят Александреску, Саттер и Майерс.
0
C++ язык маркетологов. Ежу блин понятно, что если передаваемый в функцию объект больше разрядности регистра, то нужно передовать по ссылке.
С новыми стандартами к этому правилу добвляется еще то, что если владение объектом передается в вызываемый код, то нужно передавать по значению, из за move семантики.
С новыми стандартами к этому правилу добвляется еще то, что если владение объектом передается в вызываемый код, то нужно передавать по значению, из за move семантики.
0
Помимо атомарных операций будет экономия на SEH фреймах, если в пределах тела функции нет ARC объектов.
+1
Ну а также постоянное копирование умных указателей может замедлить выполнение паралельных задач
+1
Only those users with full accounts are able to leave comments. Log in, please.
Передача умных указателей по константной ссылке. Вскрытие