Примери за това, когато побитово swap() е лоша идея?

Ще твърдя, че това почти винаги е лоша идея, освен в конкретния случай, когато е направено профилиране и по-очевидно и ясно изпълнение на swap има проблеми с производителността. Дори в този случай бих използвал този вид подход само за директни структури без наследяване, никога за какъвто и да е клас. Никога не знаете кога ще бъде добавено наследяване, което потенциално ще разруши всичко (вероятно и по наистина коварни начини).

Ако искате бърза реализация на суап, може би по-добрият избор (където е подходящо) е да размените класа и след това просто да размените имплементацията (отново, това предполага, че няма обратни указатели към собственика, но това лесно се съдържа в класа & impl, а не външни фактори).

РЕДАКТИРАНЕ: Възможни проблеми с този подход:

• Указатели обратно към себе си (пряко или косвено)
• Ако класът съдържа обект, за който директното копиране на байтове е безсмислено (ефективно преобразувайки тази дефиниция) или за което копирането обикновено е забранено
• Ако класът се нуждае от някакво заключване за копиране
• Лесно е случайно да подадете два различни типа тук (необходима е само една междинна функция, за да накарате производния клас да изглежда като родителя) и след това да размените vptrs (ОУ!)

Това не е конкретно за swap, а пример, показващ, че оптимизациите на ниско ниво може би не си струват труда. Компилаторът често го разбира така или иначе.

Разбира се, това е любимият ми пример, в който компилаторът има изключителен късмет, но така или иначе не трябва да приемаме, че компилаторите са глупави и че можем лесно да подобрим генерирания код с някои прости трикове.

Моят тестов код е - конструирайте std::string и го копирайте.

std::string whatever = "abcdefgh";
std::string whatever2 = whatever;

Първият конструктор изглежда така

  basic_string(const value_type* _String,
               const allocator_type& _Allocator = allocator_type() ) : _Parent(_Allocator)
  {
     const size_type _StringSize = traits_type::length(_String);

     if (_MySmallStringCapacity < _StringSize)
     {
        _AllocateAndCopy(_String, _StringSize);
     }
     else
     {
        traits_type::copy(_MySmallString._Buffer, _String, _StringSize);

        _SetSmallStringCapacity();
        _SetSize(_StringSize);
     }
  }

Генерираният код е

   std::string whatever = "abcdefgh";
000000013FCC30C3  mov         rdx,qword ptr [string "abcdefgh" (13FD07498h)]  
000000013FCC30CA  mov         qword ptr [whatever],rdx  
000000013FCC30D2  mov         byte ptr [rsp+347h],0  
000000013FCC30DA  mov         qword ptr [rsp+348h],8  
000000013FCC30E6  mov         byte ptr [rsp+338h],0  

Тук traits_type::copyсъдържа извикване на memcpy, което е оптимизирано в едно регистърно копие на целия низ (внимателно избран, за да пасне). Компилаторът също така трансформира извикването към strlen във време за компилиране 8.

След това го копираме в нов низ. Конструкторът за копиране изглежда така

  basic_string(const basic_string& _String)
     : _Parent(std::allocator_traits<allocator_type>::select_on_container_copy_construction(_String._MyAllocator))
  {
     if (_MySmallStringCapacity < _String.size())
     {
        _AllocateAndCopy(_String);
     }
     else
     {
        traits_type::copy(_MySmallString._Buffer, _String.data(), _String.size());

        _SetSmallStringCapacity();
        _SetSize(_String.size());
     }
  }

и води до само 4 машинни инструкции:

   std::string whatever2 = whatever;
000000013FCC30EE  mov         qword ptr [whatever2],rdx  
000000013FCC30F6  mov         byte ptr [rsp+6CFh],0  
000000013FCC30FE  mov         qword ptr [rsp+6D0h],8  
000000013FCC310A  mov         byte ptr [rsp+6C0h],0  

Имайте предвид, че оптимизаторът помни, че char все още са в регистър rdx и че дължината на низа трябва да бъде същата, 8.

Именно след като виждам неща като тези, обичам да се доверявам на компилатора си и да избягвам да се опитвам да подобря кода с битова игра. Това не помага, освен ако профилирането не открие неочаквано тясно място.

(с участието на MSVC 10 и моята реализация на std::string)

Защо са измислени "самопоказатели"?

class RingBuffer
{
    // ...
private:
    char buffer[1024];
    char* curr;
};

Този тип съдържа буфер и текуща позиция в буфера.

Или може би сте чували за iostreams:

class streambuf
{
  char buffer[64];
  char* put_ptr;
  char* get_ptr;
  // ...
};

Както някой друг спомена, оптимизацията на малък низ:

// untested, probably buggy!
class String {
  union {
    char buf[8];
    char* ptr;
  } data;
  unsigned len;
  unsigned capacity;
  char* str;
public:
  String(const char* s, unsigned n)
  {
    if (n > sizeof(data.buf)-1) {
      str = new char[n+1];
      len = capacity = n;
    }
    else
    {
      str = data.buf;
      len = n;
      capacity = sizeof(data.buf) - 1;
    } 
    memcpy(str, s, n);
    str[n] = '\0';
  }
  ~String()
  {
    if (str != data.buf)
      delete[] str;
  }
  const char* c_str() const { return str; }
  // ...
};

Това също има самопоказател. Ако конструирате два малки низа и след това ги размените, деструкторите ще решат, че низът е "нелокален" и ще се опитат да изтрият паметта:

{
  String s1("foo", 3);
  String s2("bar", 3);
  bad_swap(s1, s2);
}  // BOOM! destructors delete stack memory

Valgrind казва:

==30214== Memcheck, a memory error detector
==30214== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==30214== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==30214== Command: ./a.out
==30214== 
==30214== Invalid free() / delete / delete[]
==30214==    at 0x4A05E9C: operator delete[](void*) (vg_replace_malloc.c:409)
==30214==    by 0x40083F: String::~String() (in /dev/shm/a.out)
==30214==    by 0x400737: main (in /dev/shm/a.out)
==30214==  Address 0x7fefffd00 is on thread 1's stack
==30214== 
==30214== Invalid free() / delete / delete[]
==30214==    at 0x4A05E9C: operator delete[](void*) (vg_replace_malloc.c:409)
==30214==    by 0x40083F: String::~String() (in /dev/shm/a.out)
==30214==    by 0x400743: main (in /dev/shm/a.out)
==30214==  Address 0x7fefffce0 is on thread 1's stack

Така че това показва, че засяга типове като std::streambuf и std::string, едва ли измислени или езотерични примери.

По принцип bad_swap никога не е добра идея, ако типовете могат да се копират тривиално, тогава std::swap по подразбиране ще бъде оптимален (на вашия компилатор не го оптимизира към memcpy, вземете по-добър компилатор) и ако те не подлежат на тривиално копиране, това е чудесен начин да се срещнете с г-н Недефинирано поведение и неговия приятел г-н Сериозен бъг.

Освен примерите, споменати в други отговори (особено обекти, съдържащи указатели към части от себе си и обекти, нуждаещи се от заключване), може да има и случай на указатели към обекта, управляван от външна структура от данни, която трябва да бъде актуализирана съответно (моля, имайте предвид, че примерът е донякъде измислен, за да не бъде прекомерен (и може би бъги поради това, че не е тестван)):

class foo
{
private:
   static std::map<foo*, int> foo_data;
public:
   foo() { foo_data.emplace(this, 0); }
   foo(const foo& f) { foo_data.emplace(this, foo_data[&f]); }
   foo& operator=(const foo& f) { foo_data[this] = foo_data[&f]; return *this}
   ~foo() { foo_data.erase(this); }
   ...
};

очевидно нещо подобно би се счупило лошо, ако обектите се разменят от memcpy. Разбира се, примерите от реалния свят за това обикновено са малко по-сложни, но смисълът трябва да е ясен.

Освен примерите мисля, че копирането (или размяната) на нетривиално копируеми обекти като това е недефинирано поведение от стандарта (може да проверите това по-късно). В този случай няма да има никаква гаранция този код да работи с по-сложни обекти.

Някои вече неспоменати:

• Размяната може да има странични ефекти, например може да се наложи да актуализирате указателите на външни елементи, за да сочат към новото местоположение, или да информирате слушащите обекти, че съдържанието на обекта е променено.
• Размяната на два елемента, които използват относителни адреси, би причинила проблеми