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

J>ну, на мое имхо — сильно хуже, потому что в RAII деструкторы регистрируются по мере добавления, а с finally их наод в одном месте все создавать, флажки всякие заводить, нужно откатывать или не нужно, и все такое. С RAII это все автоматом, пишешь и не думаешь ни о чем, можешь в любой момент в любом порядке все пеетасовать.
На жебе да не удобно.
А вот на C# вполне себе:

using (Stream file1 = File.Open(...))
using (Stream file2 = File.Open(...))
using (Stream file3 = File.Open(...))
using (Stream file4 = File.Open(...))
{
}

От RAII не сильно отлячается.

_Jane_ пишет:

>> > А смесь пробелов и табуляции -- это вообще как свидетельство того, что
>> > человек не владеет инструментами, которыми пользуется (не способен
>> > настроить свой редактор/IDE).
>
> S>А я вот вполне осознанно пробелы с табуляцией мешаю Не знал, что это
> S>может кого-то бесить...
>
> Не подскажете, в каких случаях это может пригодиться? Как именно
> расставляются пробелы и табуляции, систематически?

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

> Дело в том, что если их расставлять как попало, то кому-то другому,
> который будет смотреть этот код, придётся временно выставить размер
> табуляции в тот, который использовался при написании кода, что бывает не
> удобно.

Эта проблема появится не раньше, чем у нас в конторе заведётся человек,
который выставит размер табуляции отличный от 4 и начнёт на это
жаловаться. Пока таких не было.

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

NB>Google C++ Style Guide

эх, у меня когда-то мечта была, в гугл попасть, даже пытался туда устроиться- но на собеседование даже не пригласили..
если бы я знал их кодестайл, мне бы это столько времени бы сыкономило

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

S>Здравствуйте, night beast, Вы писали:

NB>>Google C++ Style Guide

S>эх, у меня когда-то мечта была, в гугл попасть, даже пытался туда устроиться- но на собеседование даже не пригласили..
S>если бы я знал их кодестайл, мне бы это столько времени бы сыкономило

Думаю, что в Гугл нужны люди, которых заботит не кодинг стайл, а решение проблем. Какая на фиг разница, как писать? Заботиться о кодинг стайле — изощренная форма отлынивания. Писать надо так, как команда пишет. Если команды нет — так, как нравится, но одинаково.

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

S>Видимо, просто мало кто знает как работает auto_ptr — а работает он
S>неочевидно.
Его в контейнеры положить нельзя.

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

CTH>Здравствуйте, night beast

CTH>после беглого прочтения не понял следующего

>>> If you actually need pointer semantics, scoped_ptr is great. You should only use std::tr1::shared_ptr under very specific conditions, such as when objects need to be held by STL containers. You should never use auto_ptr.

>>> Use streams only for logging.

CTH>чем им не угодили потоки и auto_ptr?

Это просто 3.14здец какой-то! shared_ptr under very specific conditions? Тогда как shared_ptr в разы увеличивает надежность кода. А scoped_ptr существенно ограничен по применению. Как они собираются возвращать указатель из функции, например? Единственный разумный ответ в такой ситуации — как голый указатель. А вся мощь smart pointer'ов осталась за бортом.

Поэтому я не могу терпеть большинство coding stadards. Какой-нибудь полоумный architect их напишет, который сам в последний раз что-либо новое про C++ узнал году так в 95-м. Про shared_ptr он услышал от вчерашнего студента (спасибо студенту, а так бы вообще не услышал), и подумал: "не-не-не, Дэвид Блэйн! Only under very specific conditions!"

auto_ptr — действительно в топку, когда у тебя есть shared_ptr.

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

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

J>>ну, на мое имхо — сильно хуже, потому что в RAII деструкторы регистрируются по мере добавления, а с finally их наод в одном месте все создавать, флажки всякие заводить, нужно откатывать или не нужно, и все такое. С RAII это все автоматом, пишешь и не думаешь ни о чем, можешь в любой момент в любом порядке все пеетасовать.
WH>На жебе да не удобно.
WH>А вот на C# вполне себе:
WH>

WH>using (Stream file1 = File.Open(...))
WH>using (Stream file2 = File.Open(...))
WH>using (Stream file3 = File.Open(...))
WH>using (Stream file4 = File.Open(...))
WH>{
WH>}
WH>

WH>От RAII не сильно отлячается.
Это только если все в одном месте.
Если нужны промежуточные шаги — все, получится куча вложенных скобок, правильно?

using (Stream file1 = File.Open(...))
{
  // что-то делаем
  using (Stream file2 = File.Open(...))
  {
    // что-то делаем
    using (Stream file3 = File.Open(...))
    {
      // что-то делаем
      using (Stream file4 = File.Open(...))
      {
      }
    }
  }
}

You will always get what you always got
  If you always do  what you always did

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

S>Здравствуйте, night beast, Вы писали:

NB>>Google C++ Style Guide

S>эх, у меня когда-то мечта была, в гугл попасть, даже пытался туда устроиться- но на собеседование даже не пригласили..
S>если бы я знал их кодестайл, мне бы это столько времени бы сыкономило

ты документ внимательно читал?
этот стайлгайд для опенсорсных проектов гугла, а не для их внутренних разработок.

You will always get what you always got
  If you always do  what you always did

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

A>Это просто 3.14здец какой-то! shared_ptr under very specific conditions? Тогда как shared_ptr в разы увеличивает надежность кода. А scoped_ptr существенно ограничен по применению. Как они собираются возвращать указатель из функции, например? Единственный разумный ответ в такой ситуации — как голый указатель. А вся мощь smart pointer'ов осталась за бортом.

Действительно, зачем у гугола опыт перенимать? Кто они такие и что могут?

A>Поэтому я не могу терпеть большинство coding stadards. Какой-нибудь полоумный architect их напишет, который сам в последний раз что-либо новое про C++ узнал году так в 95-м. Про shared_ptr он услышал от вчерашнего студента (спасибо студенту, а так бы вообще не услышал), и подумал: "не-не-не, Дэвид Блэйн! Only under very specific conditions!"

Конечно студенты напишут лучше...

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

J>ты документ внимательно читал?
J>этот стайлгайд для опенсорсных проектов гугла, а не для их внутренних разработок.

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

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

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

J>>ты документ внимательно читал?
J>>этот стайлгайд для опенсорсных проектов гугла, а не для их внутренних разработок.

S>люди из конторы в которой я работыю уверяли, что в гугле этот кодестайл и для внутреннего использования, более того ему заставляют следовать, иначе код с ревью на доработку отправляется.

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

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

J>Это только если все в одном месте.
J>Если нужны промежуточные шаги — все, получится куча вложенных скобок, правильно?
У тебя такой код вобще бывает?
Вот у меня нет.
Один максимум 2 файла за раз открывать приходится.
Так что Имею Мнение Хрен Оспоришь что польза от RAII при наличии GC мягко говоря приувеличина.

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

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

J>>Это только если все в одном месте.
J>>Если нужны промежуточные шаги — все, получится куча вложенных скобок, правильно?
WH>У тебя такой код вобще бывает?

Бывает, сплошь и рядом (не с файлами, конечно ).

WH>Вот у меня нет.
WH>Один максимум 2 файла за раз открывать приходится.

не, файлы, конечно, ты вряд ли больше чем два в одной функции открывать будешь, но что, у тебя программы только файлами занимаются?

WH>Так что Имею Мнение Хрен Оспоришь что польза от RAII при наличии GC мягко говоря приувеличина.

RAII используется в первую очередь для отката (с конкретными временными рамками, а именно — область видимости) какого-то действия, и захват ресурса — это только одна из разновидностей подобных действий, а уж захват памяти, от которого помогает GC — это еще меньшее подмножество подобных действий.

Так что GC и RAII несколько ортогональны, хотя в области конкретно управления памятью они могут использоваться более-менее взаимозаменяемо (в определенных рамках, естественно, связанных с деструкторами, поскольку, так уж получилось, освобождение памяти и смерть объекта обычно взаимосвязаны).

You will always get what you always got
  If you always do  what you always did

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

J>Бывает, сплошь и рядом (не с файлами, конечно ).
А с чем?

J>не, файлы, конечно, ты вряд ли больше чем два в одной функции открывать будешь, но что, у тебя программы только файлами занимаются?
Не только.
Но критичных ресурсов все так же мало.
Раз два и обчелся.

J>RAII используется в первую очередь для отката (с конкретными временными рамками, а именно — область видимости) какого-то действия, и захват ресурса — это только одна из разновидностей подобных действий,
Пример в студию.

J>а уж захват памяти, от которого помогает GC — это еще меньшее подмножество подобных действий.
Чё? Да это 99% случаев использования RAII если не больше.

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

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

J>>Бывает, сплошь и рядом (не с файлами, конечно ).
WH>А с чем?

J>>не, файлы, конечно, ты вряд ли больше чем два в одной функции открывать будешь, но что, у тебя программы только файлами занимаются?
WH>Не только.
WH>Но критичных ресурсов все так же мало.
WH>Раз два и обчелся.

J>>RAII используется в первую очередь для отката (с конкретными временными рамками, а именно — область видимости) какого-то действия, и захват ресурса — это только одна из разновидностей подобных действий,
WH>Пример в студию.

да любое изменение — изменение значения переменной, вставка объекта в контейнер, удаление объекта из контейнера и т.д.
если ты хочешь обеспечить транзакционность метода в условиях летающих исключений — как ты это без RAII будешь делать?
и тут, как видишь, слово "ресурс" вообще не возникает, а RAII, тем не менее, в полный рост.

J>>а уж захват памяти, от которого помогает GC — это еще меньшее подмножество подобных действий.
WH>Чё? Да это 99% случаев использования RAII если не больше.
У кого как

You will always get what you always got
  If you always do  what you always did

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

J>да любое изменение — изменение значения переменной, вставка объекта в контейнер, удаление объекта из контейнера и т.д.
Что-то ни разу не хотелось сделать что-то подобное.
Можешь показать зачем оно тебе?

J>если ты хочешь обеспечить транзакционность метода в условиях летающих исключений — как ты это без RAII будешь делать?
Очень зависит от того что за метод и что за транзакции.

J>и тут, как видишь, слово "ресурс" вообще не возникает, а RAII, тем не менее, в полный рост.
У кого как.
Лично у меня в коде на С++ RAII только для того чтобы захватить/освободить некий ресурс.
Не важно файл, мьютекс, некий тяжелый объект из пула, кусок памяти...

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

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

J>>да любое изменение — изменение значения переменной, вставка объекта в контейнер, удаление объекта из контейнера и т.д.
WH>Что-то ни разу не хотелось сделать что-то подобное.
WH>Можешь показать зачем оно тебе?

Почитай здесь.

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

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

J>>да любое изменение — изменение значения переменной, вставка объекта в контейнер, удаление объекта из контейнера и т.д.
WH>Что-то ни разу не хотелось сделать что-то подобное.
WH>Можешь показать зачем оно тебе?

Например для исправления этой ситуации:

std::vector<int*> vec;
vec.push_back(new int);

Другой пример, из буста: "io state savers"

Rationale
...

#include <ostream>
#include <ios>

void  hex_my_byte( std::ostream &os, char byte )
{
    os << std::hex << static_cast<unsigned>(byte);
}

The os stream will retain its new hexadecimal printing mode after the call to hex_my_byte. The stream's printing mode can be saved and restored with manual calls to the stream's state inspecting and mutating member functions. The manual method becomes unwieldy if the main functionality is complex and/or needs to be exception safe. A saver class can implement the better "resource acquisition is initialization" strategy.

J>>если ты хочешь обеспечить транзакционность метода в условиях летающих исключений — как ты это без RAII будешь делать?
WH>Очень зависит от того что за метод и что за транзакции.

Как реализуется strong guarantee("все, либо ничего") в присутствии исключений? Вариантов обычно два — клонирование+изменение+swap, либо изменение "in place" с откатами при исключениях. Изменение состояния потока относится к тому случаю, когда клонирование невозможно, поэтому остается только вариант с приведением состояния к первоначальному. Такие вот транзакции...

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

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

J>>да любое изменение — изменение значения переменной, вставка объекта в контейнер, удаление объекта из контейнера и т.д.
WH>Что-то ни разу не хотелось сделать что-то подобное.
WH>Можешь показать зачем оно тебе?

Ну вот у меня в системе летают сообщения, и в программе есть некий state, который обновляется с приходом разнообразных сообщений (т.е. мы добавили элемент в контейнер А, изменили статистику в объекте В, нашли объект в контейнере С и в контейнере, который в нем, удалили какой-то элемент, и так далее, куча действий на разных уровнях).
Но сообщения могут быть ошибочными по той или иной причине, и такие сообщения должны игнорироваться.
Игнорироваться — это значит, что state после их прихода должен быть таким, как будто ничего не приходило вообще.
Причем проверка сообщения — вещь многоуровневая, в одну функцию на входе ее не запихнешь, да и дорого это и неудобно — мы хотим оптимизировать по скорости сценарий, когда сообщение корректное.
Т.е. ты начинаешь делать какие-то действия, предполагая, что с сообщением все хорошо, а если где-то дальше по стеку что-то не так — откатываешь свои изменения.

Другой пример — загрузка иерархического конфига, когда ошибка в конфиге должна привести к "незагрузке" только этой маленькой ветки, а все остальное должно загрузиться — начинаешь парсить и грузить все в память, создавать всякие деревья и прочее, а в какой-то момент, глубоко в стеке, раз — и опаньки, надо ветку, которая вызвала ошибку, не загружать, лишь ругнуться в лог, и продолжить загрузку дальше, как будто ошибочного текста не было вообще.

в общем, сложно все упомнить — они реально на каждом шагу.

короче, транзакционность по отношению к возникновению исключения: если при обработке события возникло исключение, то надо сделать так, будто такого события не было вообще в природе (разве что в логе).

J>>если ты хочешь обеспечить транзакционность метода в условиях летающих исключений — как ты это без RAII будешь делать?
WH>Очень зависит от того что за метод и что за транзакции.

да не зависит.
транзакция — это действия по изменению + действия по коммиту либо действия по откату.
И вот для автоматизации этих действия как раз RAII　и используется.

J>>и тут, как видишь, слово "ресурс" вообще не возникает, а RAII, тем не менее, в полный рост.
WH>У кого как.
WH>Лично у меня в коде на С++ RAII только для того чтобы захватить/освободить некий ресурс.
WH>Не важно файл, мьютекс, некий тяжелый объект из пула, кусок памяти...

Это я понял, не понял лишь, зачем ты так насильственно сужаешь область применения RAII.

You will always get what you always got
  If you always do  what you always did

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


A>Это просто 3.14здец какой-то! shared_ptr under very specific conditions? Тогда как shared_ptr в разы увеличивает надежность кода. А scoped_ptr существенно ограничен по применению. Как они собираются возвращать указатель из функции, например? Единственный разумный ответ в такой ситуации — как голый указатель. А вся мощь smart pointer'ов осталась за бортом.

передаёшь scoped_ptr по ссылке, и нет проблем, хотя согласен, что scoped_ptr, что shared_ptr хороши лишь для внутреннего использования в своём коде,
для какого-нить общего апи они ниподходят никак(поскольку навязывают программисту способ использования, а это стиль какой-нить явы, но не плюсов), поскольку не позволяют освобождать указатель от своего владения, а вот auto_ptr в этом случае вполне применим.

A>Поэтому я не могу терпеть большинство coding stadards. Какой-нибудь полоумный architect их напишет, который сам в последний раз что-либо новое про C++ узнал году так в 95-м. Про shared_ptr он услышал от вчерашнего студента (спасибо студенту, а так бы вообще не услышал), и подумал: "не-не-не, Дэвид Блэйн! Only under very specific conditions!"

A>auto_ptr — действительно в топку, когда у тебя есть shared_ptr.

на такой поток сознания даже и отвечать не хочется.