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

Pzz>>Если деструктор не имеет значимых для логики программы side effects, типа отпускания мутекса, вам должно быть совершенно все равно, кто и когда их зовет.

RO>...разрыва соединения с БД, закрытия дескриптора устройства?

А какая вам разница, когда закрывается соединение с БД или файл? Лишь бы они тоннами не накапливались.

RO>std::unique_ptr — очень высокоуровневая вещь и совсем без оверхеда.

Вот ведь, чего только люди не придумают, чтобы скрыть тот факт, что в языке нет нормальных встроенных средств для работы с данными по ссылке!

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

RO>В случае GC тоже кто-то должен отследить время жизни объекта и своевременно удалить, что точно так же небесплатно. Так что оверхеда здесь нет — ты захотел воспользоваться объектом, нуждающемся в последующей очистке, ты получил ее. Опять же, у тебя есть выбор между throw всё_пропало() и просто std::terminate(), если нет объектов, требующих освобождения для других процессов.

Фрейм компилятору заводить придётся...

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

E>>1) Аналогии идут лесом

Pzz>Ну почему же, в языке есть великолепное встроенное средство задать требуемое подмножество: надо для файлов с исходными текстами использовать расширение .c, а не .cpp, .cc и т.п. Большинство компиляторов эту фичу поддерживают

К сожалению, это будет не подмножество...

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

Pzz>>>Если деструктор не имеет значимых для логики программы side effects, типа отпускания мутекса, вам должно быть совершенно все равно, кто и когда их зовет.
RO>>...разрыва соединения с БД, закрытия дескриптора устройства?
Pzz>А какая вам разница, когда закрывается соединение с БД или файл? Лишь бы они тоннами не накапливались.
Как только следом за закрытием идёт операция, к моменту начала которой соединение/файл должны быть закрыты сразу появляется существенная разница.

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

E>>

struct S {
    int x;
    int y;
};
int foo()
{
    S s = { 1, 2 };
    return s.x + s.y;
}

PD>Здравствуйте! Это С++ или С ? В С деструктор никак не может вызываться ввиду его отсутствия.
PD>А в С++ вызывается дефолтный деструктор, который ничего не делает, но это по стандарту есть.
Надеюсь при этом всё таки понимаешь что и в С и в С++ для вышеприведённого кода никаких деструкторов не будет ни сгенерировано ни вызвано?

PD>А в С++ } влечет за собой вызов деструкторов для автоматических переменных. И это нужно понимать.
Еще нужно понимать что если деструктор не выполняет полезную работу то он и не генерится вовсе.

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

PD>Будет. Конечно, реального вызова не будет, но логически деструктор есть и он должен вызваться. Ну а оптимизатор имеет право не вызывать реально функцию, которая ничего не делает. Впрочем, компилятор вправе эту функцию не компилировать, если захочет. Все они вправе. Но деструктор там в языке есть.

"В теории, практика не отличается от теории. Но на практике — отличается" (С)

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

T>Кроме того со смартпоинтерами код проще становится, особенно при использовании всяких ветвлений и вложенных циклов:
T>

T>void function()
T>{
T>  std::auto_ptr<A> pA(new A(...));
T>  //...
T>}
T>

Надо полагать твой оппонент тебя не понимает потому, что С++сники как правило под smart pointer понимают указатель со счётчиком ссылок.
А auto_ptr это скорее scoped pointer.

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


PD>1. Добавим классы и инкапсуляцию. Чистый выигрыш. Код понятнее, оверхед нулевой.
PD>2. Добавим наследование, но без виртуальности. Чистый выигрыш. На С пришлось бы возиться долго, устраивая пародию на наследование, и код получился бы на порядок менее понятный.
PD>3. Добавим виртуальность и исключения. Виртуальность — ненулевой оверхед, но моделировать ее на С будет еще сложнее и оверхед будет не меньше. Что касается исключений, то это как сказать. Кому-то они нравятся, кому-то нет.
3.5 Шаблоны
PD>4. Добавим библиотеки типа STL, boost и т.п. Тут уже оверхед может быть приличным, ясность и понятность упасть тоже прилично, но зато все преимущества, что они дают.

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

E>Фрейм компилятору заводить придётся...

Что такое фрейм?

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

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

A>>Если позанудствовать, то можно упомянуть, что на некоторых компиляторах возможен незначительный overhead из-за включенной обработки исключений. Т.е. при прочих равных код на С будет скомпилирован в меньший по размеру бинарь. Скорость исполнения будет отличаться, скорее всего, весьма и весьма незначительно.

A>>Если выключить исключения и rtti — разницы скорее всего не будет (для g++ 3.4.x) это проверено

E>Если позанудствовать поточнее, то можно заметить, что надо сравнивать одинаковые программы.
E>Если у тебя в проге нет ничего кроме POD, то у тебя и на RTTI и на исключения никакого оверхеда не случиться...

вы *точно* знаете о чем говорите?

я с этим сталкивался, одной из причин, почему фирма, в которой я работал не использовала исключения — распухающий бинарь, больший процентов на 30 его аналога скомпиленного с выключенными исключениями (ARM gcc 3.4.5).

только что проверил на gcc:

gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8)


текст программы:

#include <stdio.h>

struct Test {
    int a;
};

static void print_test(struct Test * t) {
    fprintf(stdout, "a = %d\n", t->a);
}

int main() {
    struct Test t;
    t.a = 145;
    print_test(&t);
    return 0;
}

строки компиляции:

gcc main.c -O2 -Wall -o mc
g++ main.cpp -O2 -Wall -o mcpp

выход:

rwxr-xr-x  1 alex alex 8342 2010-02-25 18:24 mc
-rwxr-xr-x  1 alex alex 8465 2010-02-25 18:24 mcpp

При компиляции `g++ main.cpp -O2 -Wall -fno-rtti -fno-exceptions -o mcpp_noex' результат почти одинаков с аналогом на С:

-rwxr-xr-x  1 alex alex 8344 2010-02-25 18:26 mcpp_noex

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

Pzz>>>Если деструктор не имеет значимых для логики программы side effects, типа отпускания мутекса, вам должно быть совершенно все равно, кто и когда их зовет.
RO>>...разрыва соединения с БД, закрытия дескриптора устройства?

Pzz>А какая вам разница, когда закрывается соединение с БД или файл? Лишь бы они тоннами не накапливались.

Так ведь будут же накапливаться. Кроме того, открытие некоторых устройств блокирует их для остальных процессов.

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

RO>Что такое фрейм?
стековый фрейм.

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

Pzz>>А какая вам разница, когда закрывается соединение с БД или файл? Лишь бы они тоннами не накапливались.
CC>Как только следом за закрытием идёт операция, к моменту начала которой соединение/файл должны быть закрыты сразу появляется существенная разница.

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

Если вам важно, чтобы какая-то операция произошла в определенное время, сделайте ее явной и явно в нужное время пните.

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

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

T>>Кроме того со смартпоинтерами код проще становится, особенно при использовании всяких ветвлений и вложенных циклов:
T>>

T>>void function()
T>>{
T>>  std::auto_ptr<A> pA(new A(...));
T>>  //...
T>>}
T>>

CC>Надо полагать твой оппонент тебя не понимает потому, что С++сники как правило под smart pointer понимают указатель со счётчиком ссылок.
CC>А auto_ptr это скорее scoped pointer.

Ну по идее в контексте темы про плюсы и минусы сишного стиля по сравнению с С++ что-то не входящее в стандарт по умолчанию не подразумевается. То есть если даже STL не используется и исключения, какой на фиг тут boost и shared_ptr с его заморочками. Да, auto_ptr или scoped_ptr — это самый простой smart pointer, про который выше говорилось что must have.

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

Pzz>>А какая вам разница, когда закрывается соединение с БД или файл? Лишь бы они тоннами не накапливались.

RO>Так ведь будут же накапливаться. Кроме того, открытие некоторых устройств блокирует их для остальных процессов.

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

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

RO>>Так ведь будут же накапливаться. Кроме того, открытие некоторых устройств блокирует их для остальных процессов.

Pzz>Значит, семантика захвата ресурса при инициализации плохо подходит для работы с этими устройствами.

Не нравится мне название «RAII». Речь же об освобождении при разрушении, а не наоборот. Если разрушение детерминировано, то семантика вполне подходит.

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

RO>>Что такое фрейм?
E>стековый фрейм.

Всё равно не понял, как исключения на него влияют?

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

Pzz>>Значит, семантика захвата ресурса при инициализации плохо подходит для работы с этими устройствами.

RO>Не нравится мне название «RAII». Речь же об освобождении при разрушении, а не наоборот. Если разрушение детерминировано, то семантика вполне подходит.

Детермнинированное разрушение очень плохо observable. Вы передали объект кому-то, и он пропал из поля вашего зрения. Вы не можете больше знать, в какой момент он будет разрушен. Лучше вообще не закладываться на автоматическое разрушение в операциях, которые должны произойти в определенное время, а не когда рак на горе свистнет. Сделайте их явными, и ваша голова будет болеть реже.

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

Pzz>Детермнинированное разрушение очень плохо observable. Вы передали объект кому-то, и он пропал из поля вашего зрения. Вы не можете больше знать, в какой момент он будет разрушен. Лучше вообще не закладываться на автоматическое разрушение в операциях, которые должны произойти в определенное время, а не когда рак на горе свистнет. Сделайте их явными, и ваша голова будет болеть реже.

Проведи (буквально) вертикальную такую линию из того места в коде, где объект захватывает ресурс, и при любом пересечении ее справа налево ресурс будет освобожден. Если же пытаться освобождать его вручную, то return, исключения и т. п. сильно испортят эти планы.

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

RO>Проведи (буквально) вертикальную такую линию из того места в коде, где объект захватывает ресурс, и при любом пересечении ее справа налево ресурс будет освобожден. Если же пытаться освобождать его вручную, то return, исключения и т. п. сильно испортят эти планы.

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

В языке сильно не хватает слова finally, если уж на то пошло.