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

CC>RAII работает не только при завершении функции но и при любом выходе из scope, будь то return или просто }
CC>Что у тебя произойдёт при return из некоторой вложенности, в каждой из которых добавляются ещё RAII объекты?
CC>Можно конечно попробовать сэмулировать но код будет уже децл макаронный.

RAII, если понимать его как "захват ресурса есть инициализация" здесь и так работает. Против бесхозного return есть #define return, в продлении жизни объекта до конца функции, а не до конца скопа особой проблемы не вижу (да и при желании #define BEGIN, #define END объявить можно или #define MANAGED_SCOPE_BEGIN и #define MANAGED_SCOPE_END в случае аллергии).

Естественно подобные соглашения накладывают определенные ограничения на код, требуют от разработчика следовать каким-то соглашениям, но тут уж извините — C по уровню находится где-то между C++ и ассемблером и что ни делай (объекты, виртуальные функции, исключения, сборщик мусора) оно все на виду будет, под капот не спрячешь, так что нечего туда пальцы совать.

On 03.02.2011 17:03, night beast wrote:

> W>Посмотри исходники <http://www.postgresql.org/ftp/source/&gt; postgresql, например.
> глянул одним глазом. как оно в многопоточном окружении работает?

По идее его там быть не должно. Я правда не уверен на счёт постгреса, но
в принципе в нормальной СУБД многопоточности быть не должно.

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

MP>Естественно подобные соглашения накладывают определенные ограничения на код, требуют от разработчика следовать каким-то соглашениям, но тут уж извините — C по уровню находится где-то между C++ и ассемблером и что ни делай (объекты, виртуальные функции, исключения, сборщик мусора) оно все на виду будет, под капот не спрячешь, так что нечего туда пальцы совать.

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

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

CC>Ну вот и получается. Что написать то можно всё. Но вот какой ценой это напишется?
CC>Даже на ассемблере можно написать вообще всё, один фиг все языки в итоге приходят к тому, что машинный код исполняется на проце, пусть даже язык интерпретируемый.

Ну речь-то в исходном посте шла о принципиальной возможности. А принципиально в C можно сделать — и делают все вышеперечисленное (разве что cleanup stack не видел, но я довольно молодой и вообще плюсовик).

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

O>Принципиальная разница в том, что С++ позволяет выводить на стадии компиляции новые типы, свойства которых,
O>опираясь на одну и ту же декларацию, реализуются избирательно для каждого типа в отдельности.
O>Это и есть вывод типов (одна из форм вычислений в compile-time, которую невозможно подделать макросами).

O>Например:

O>

O>template <typename T>
O>struct type_array;
O>{
O>    char Array[sizeof (T)];
O>};
O>

...
O>В C для этого пришлось бы создавать бесконечно большое количество вариаций type_array, которые все равно
O>годились бы только для используемого программой набора типов — при включении новых типов пришлось бы
O>снова создавать разновидности type_array. Все потому, что выводить новые типы (структуры) C не умеет.
O>Из-за этого отличия шаблон type_array может использоваться любым клиентским кодом без модификаций, а аналог,
O>написанный на C, потребует ручной реализации каждого нового типа.

СМ>>>>2. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"
СМ>>Вы пишите, что вот С++ здесь не генерить, а С генерит (да и то на самом деле не генереит), и это ПРИНЦИПИАЛЬНАЯ разница??? бред бред

O>Если бред — не читайте. Никто не заставляет.

натуральный бред. Все ваши типы жестко прошиты в бинарник. Никаких новых типов без тайпящего ручками программиста не может быть в принципе. Разница с С в том что кто-то сэкономил 1 строку кода на тип. Вы там бонусы за строки кода получаете? Как 1 строка кода стала принципиальной разницей ?

Кстати программистам на C не нужны все ваши type_array просто по причине того что проверки типов там не нужны и с точки зрения поведения это все массивы символов.

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

SD>натуральный бред. Все ваши типы жестко прошиты в бинарник. Никаких новых типов без тайпящего ручками программиста не может быть в принципе. Разница с С в том что кто-то сэкономил 1 строку кода на тип. Вы там бонусы за строки кода получаете? Как 1 строка кода стала принципиальной разницей ?

SD>Кстати программистам на C не нужны все ваши type_array просто по причине того что проверки типов там не нужны и с точки зрения поведения это все массивы символов.

Моя версия правильного ответа на вопрос "чего принципиально не может C по сравнению c C++" была подробно представлена выше.
Не считаю нужным опять ее разжевывать.

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

>> W>Посмотри исходники <http://www.postgresql.org/ftp/source/&gt; postgresql, например.
>> глянул одним глазом. как оно в многопоточном окружении работает?

MZ>По идее его там быть не должно.

почему?

MZ>Я правда не уверен на счёт постгреса, но
MZ>в принципе в нормальной СУБД многопоточности быть не должно.

в постгресе они указатель на текущий sigjmp_buf в глобальной переменной хранят