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

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

Ты хочешь сказать, что

resource r;
...
r.assign(get_some_resource());
try
{
    return do_something(r.get());
}
finally
{
    r.release();
}

лучше, чем

resource r;
...
r.assign(get_some_resource());
return do_something(r.get());

?

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

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

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

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

раскрутка стека как по твоему выполняется ?

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

RO>Всё равно не понял, как исключения на него влияют?
От реализации исключений зависит.
Тебе при какой из известных реализаций не ясна связь?

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

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

A>#include <stdio.h>
A>    fprintf(stdout, "a = %d\n", t->a);
A>

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

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

T>Ну так жизнь вообще сложная штука Поэтому отображение ее в коде тоже бывает непростым. Но при правильном использовании ООП реально помогает бороться со сложностью, за счет разделения предметной области на иерархию понятных разработчику объктов и уровней абстракции. В виде кода это действительно выглядит иногда сложновато. Зато при правильном отображении предметной области на объектную иерархию разработчику проще адаптировать код к изменившимся условиям, и разработка идет быстрее. То есть в С++ для этого есть достаточно удобные встроенные средства, и идеология в принципе позволяет сделать то что выше так, чтобы знакомому с предметной областью второму разработчику было наоборот проще вникать в архитектуру. Если не получается достичь нужного качества отображения — так это проблема не языка, а архитектора.

Так ООП вполне можно и на С замутить. Вот окошки Windows, например -- чистое ООП, а всё на С

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

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

Да какая разница? GC -- это всего лишь один из подходов к управлению памятью. Он нифига не универсальный. В С и С++ можно много разных подходов использовать...

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

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

Можно легко забыть "пнуть". Особенно при модификациях кода или при использовании исключений...

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

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

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

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

А что будет делать тот объект, который вы передали куда-то, а потом закрыли?

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

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

Ничто не мешает такие объекты сильно ограничить в правах.
Например открытые файлы обычно нельзя копировать, и проблем не возникает

Pzz>В языке сильно не хватает слова finally, если уж на то пошло.
Да ладно. Под виндой оно фактически есть, но популярностью не особо пользуется...

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

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

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

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

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

E>А что будет делать тот объект, который вы передали куда-то, а потом закрыли?

Ну если его умный человек писал, взорвется с громкими воплями. А если совсем умный, то выделение ресурсов и синхронизация не будут смешаны в одну кучу. Мне по-большому счету все равно, когда закрываются файловые дескрипторы, лишь бы их не болталось ненужными и незакрытыми неразумное количество. Мне важно, когда данные окажутся на диске, разделяемый ресурс будет отпущен и т.п.. И это уже синхронизация, а не освобождение ресурсов.

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

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

L>Я не хотел в этот спор влезать, но знаете что? С предложениями внести в язык всякие finally, идите-ка по-доброму куда подальше.
L>Там и без того способов стрельбы по ногам хватает

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

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


L>>Я не хотел в этот спор влезать, но знаете что? С предложениями внести в язык всякие finally, идите-ка по-доброму куда подальше.
L>>Там и без того способов стрельбы по ногам хватает

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

Вот и не надо всякого предлагать. А то ведь они возьмут, и внесут. А нам потом с этим жить.

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

E>Так ООП вполне можно и на С замутить. Вот окошки Windows, например -- чистое ООП, а всё на С

Так там базовая логика и должна быть кондовой. Когда код на миллиардах машин по всему миру работает, и API более-менее стабильное, по любому не жалко времени на разруливание сишных неудобств Но гуй на сях для обычных прилад никому в здравом уме уже делать не придет, потому что есть WTL, MFC, VCL и т.п. Это как раз хороший пример того, как может быть проще оперировать на уровне объектных абстракций, вместо плоской массы структурок и функций.

Здравствуйте, Аноним, Вы писали:

А>Некоторые говорят что код на С работает быстрее чем C++. Т. е. для разработки высокопроизводительного SW предпочтительно использовать С вместо C++. Кто нибудь может подсказать в чем это преимущество (не считая использование виртуальных функции, здесь очевидно почему медленее)

Я знаю одно замечение где C++ медленне С — это использование глобальных статический объектов с конструкторами и/или деструкторами. В этом случае относительно долго (по сравнению с С кодом) происходит запуск/завершение процесса. Для UNIX систем это бывает важно.

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


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

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

CC>Еще нужно понимать что если деструктор не выполняет полезную работу то он и не генерится вовсе.

Это верно для С++ в VC++ для очень многих функций и просто кусков кода. Например, вот такое

for(int i = 0; i < 1000; i++);

Если ты утверждаешь. что здесь нет в С++ цикла — я категорически не согласен. Есть она тут на С++. Но VC++/Release этот код выкинет и правильно сделает.

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

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

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

PD>Если ты утверждаешь. что здесь нет в С++ цикла — я категорически не согласен. Есть она тут на С++. Но VC++/Release этот код выкинет и правильно сделает.
С точки зрения сравнения производительности/эффективности языков тут цикла нет. Стоимость этой строки в runtime == 0.

Тебе шашечки или ехать?

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

T>Ну по идее в контексте темы про плюсы и минусы сишного стиля по сравнению с С++ что-то не входящее в стандарт по умолчанию не подразумевается.
Всё, что можно написать, пользуясь средствами самого языка (не либ, впрочем один фиг либы написаны на этом языке), что упростит жизнь программисту — надо сравнивать.
Шаблоны в стандарт входят? Входят.
Я могу использовать шаблоны? Могу.

T> То есть если даже STL не используется и исключения
STL это всего лишь либа. Исключения всего лишь инструмент. Ими можно как пользоваться так и не пользоваться в зависимости от того, помогают они решить задачу, вписываясь в её (задачи) условия или нет.

T> какой на фиг тут boost и shared_ptr с его заморочками.
буст это всего лишь ещё одна либа.
Ну а shared pointer это скорее уже паттерн.

T> Да, auto_ptr или scoped_ptr — это самый простой smart pointer, про который выше говорилось что must have.
scoped — must have, да. Тут базару нет в принципе.