alexeiz wrote:
>> > А вот этого не надо. SomeClazz(_other) кидает исключение и приплыли.
> C>Естественно, используется только с небросающими конструкторами. Либо
> C>делаем специальный fallback-constructor, который переводит объект в
> C>состояние "lame duck" в случае исключения.
> Зачем так усложнять? Этот трюк у меня в чёрном списке. Я не знаю случая,
> где нельзя было бы применить более простой, надёжный и эквивалентный по
> производительности метод.
Зависит от ситуации. У меня в моей библиотеке контейнеров и так уже есть
состояние "lame duck" — оно возникает, например, в случае броска
исключения при удалении элемента из середины контейнера. Так что
использование его в копикторе не вызывает проблем.

Здравствуйте, Cyberax, Вы писали:

C>alexeiz wrote:
>> Этот "временный" объект впоследствии переносится в this. Поэтому он не
>> есть временный в том смысле, что он зря создаётся, а потом просто
>> выбрасывается.
C>Он временный по своей сути.

Что сути дела не меняет.

>>> > temp.swap(*this); // cheap swap
>> C>А кто сказал, что "swap" — всегда дешовый?
>> Нужно его сделать дешёвым. Если нет, то есть другие методы, опять же
>> отличные от "трюка".
C>Вот пример:
C>

C>class SmallString
C>{
C>    char buf[32];
C>    SmallString(){memset(buf,0,32);}
    
C>    void swap(SmallString &_other)
C>    {
C>        //???
C>    }
C>};
C>

C>Точно так же и с другими подобными случаями.

Когда swap не сильно дешёвый, нужно работать над copy-constructor'ом. Я не говорю, что пологаться на swap — это единственный способ его реализации. Это типичный способ. По причинам производительности он может не совсем подходить. Но твой трюк-хак, это все равно не выход. По-моему, в нём больше проблем, чем пользы.

>> C>Например, в своей реализации велосипедных контейнеров у меня этот трюк
>> C>используется для ускорения присваивания строк со включенным
>> C>small-string-optimization.
>> Мне кажется, что лучше просто побайтно скопировать. Но приведи
>> реализацию, посмотрим.
C>Все достаточно большое, могу послать целиком.

Посылай. Мне интересно сравнить с другими реализациями small string optimization.

WolfHound,

> WH>>Да брось ты... например я часто использую IDisposable + using для того чтобы отрубать события на время массовых изменений...

> ПК>А в этом случае тебе важно, если Dispose не будет вызван в случае какого-нибудь исключения, или система потом как-нибудь "сама" в норму вернется?

> Ничего не понял. В таком коде все всегда вызывается

Это я напоминаю о контексте разговора: речь ведь не о том, управляемые или неуправляемые ресурсы используются в IDisposable, а о том, важно или не важно их не освободить, и о том, насколько неудобно отсутствие автоматизации для освобождения членов. Вот в твоем случае, например, насколько я вижу, освобождение критично.