Здравствуйте, more, Вы писали:
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
Шаблоны "обладают полнотой по Тьюрингу" во время компиляции. Аналога в C нет.
Re[2]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Viper_Craft, Вы писали:
V_C>забавно у меня был противоположный случай )))
Это легко. На С++ нельзя операционки писать, и пример тому Симбиан
V_C>бежать от такой команды надо, как от огня...
Это точно.
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Нет говорят, все не то.
Само-собой. Затрахать собеседника вопросами по Си, существенно сложнее чем вопросами по Плюсам. Так что правильный ответ: вынести мозг кандидату дурацкими вопросами.
Re[3]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>То есть по вашему, препроцессор C не обладает полнотой по Тьрингу? Ну-ну.
Ну да, не обладает.
Потому что программа препроцессируется только один раз и рекурсивных раскрытий макросов просто не получится.
Однако, если программа будет #include-ть себя саму, можно получить, к примеру, решение ханойской башни.
См. это сообщение: http://mail.szabgab.com/pipermail/perl/2003-July/002701.html
и, в частности, этот код: http://www0.us.ioccc.org/1995/vanschnitz.c
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно.
Нужно было спросить, по каким критериям выделяется "принципиальная возможность".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
Вопрос неоднозначный. В смысле результата — можно всё.
M>Я сказал, что фактически, все возможно.
Правильно сказали.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
Это всё никак не сказывается на результате, по крайней мере положительно. Тут вопрос в том, насколько для программиста удобно реализовывать алгоритмы. Можно делать списки, деревья, стеки; работать с указателями. Что ещё надо?
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
Зависит от набора ограничений. Ведь в предельном случае можно на C написать компилятор/интерпретатор другого языка, превосходящего C++, и исполнить программу на нем из строковой переменной.
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно. M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
Деструкторы не может.
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Нет говорят, все не то.
Функциональщину нельзя, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, okman, Вы писали:
Кё>>>Если допускается заменять вычисления в compile-time вычислениями в рантайме, то метапрограммирование и все что угодно остальное не проблема. O>>Тогда это уже будет не метапрограммирование.
Кё>Я напишу интерпретатор лисп и сделаю на лиспе любое метапрограммирование, чтобы под этим ни понималось.
Напиши лучше машину времени и убей страутсрупа, чтобы глупостей не делал.
<Подпись удалена модератором>
Re[5]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Только вот код на этом хаосе нечитабельный совсем E>Речь, вроде как, шла о принципиальной невозможности, а не о читабельности, юзабельности и т. д...
Тоже верно.
Я просто одно время воодушевился, когда узнал про chaos-pp, но меня так и не хватило разобраться в их базовых примерах даже.
Старый я стал совсем
class MyClass
{
int A;
};
int main( void )
{
MyClass test;
return 0;
}
C++: No errors or program output
C:
Line 1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'MyClass'
In function 'main':
Line 8: error: 'MyClass' undeclared (first use in this function)
Line 8: error: (Each undeclared identifier is reported only once
Line 8: error: for each function it appears in.)
Line 8: error: expected ';' before 'test'
Т.е. классы он принципиально не может.
Make flame.politics Great Again!
Re[4]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, night beast, Вы писали:
NB>не тестировал, но думаю по производительности не дотянет до плюсовых.
Тоже не тестировал, но видел как longjmp выглядит на ассемблере. Было бы странно, если бы он куда-то там не дотянул, он же делает ведь сущую ерунду, стек назад не раскручивает, деструкторов не вызывает, а просто восстанавливает когда-то запомненное состояние стека, предоставляя программисту самому заботиться об освобождении выделенной динамической памяти и других ресурсов.
Re[4]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, kaa.python, Вы писали:
KP>> ... если разговор идет о выполнимости той или иной задачи, то тут Си скорее даже лидирует ...
I>Что ты имеешь в виду, новые возможности C99, которых еще нет в C++?
Нет, я имею ввиду что на Си можно написать что угодно, а для ряда экзотических ситуаций использование плюсов просто не возможно (например из за отсутствия компилятора для какого-то девайса).
Посути, вопрос не полон. Толи речь идет о фенечках языка, толи о спектре решаемых задач.
Re[2]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Например, вычисление факториала (самый популярный пример для начинающих осваивать тему) на шаблонах.
на шаблонах нет- ибо в си их нет, но в compile time на макросах- запросто:
#define DECL_MUL(z, n, text) BOOST_PP_IF(n, * n, 1)
#define FACTORIAL(n) BOOST_PP_REPEAT(BOOST_PP_INC(n), DECL_MUL, )
O>Или класс N-мерной таблицы, размерность которой задается параметром шаблона.
таки да, в си вообще нет классов, но к вопросу топика это не относится.
O>Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.
fail
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Нет говорят, все не то.
Ещё есть вариант такой, что на С фиг напишешь библиотеку состоящую только их хедеров. Но я не уверен, что это можно считать "принципиальным ограничением"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно. M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
забавно у меня был противоположный случай )))
бежать от такой команды надо, как от огня...
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно. M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
Когда увидел это сообщение, почти сразу вспомнил про метапрограммирование.
Например, вычисление факториала (самый популярный пример для начинающих осваивать тему) на шаблонах.
Или класс N-мерной таблицы, размерность которой задается параметром шаблона.
Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.
Re[2]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Когда увидел это сообщение, почти сразу вспомнил про метапрограммирование. O>Например, вычисление факториала (самый популярный пример для начинающих осваивать тему) на шаблонах. O>Или класс N-мерной таблицы, размерность которой задается параметром шаблона. O>Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.
Да ладно, посмотри order-pp и chaos-pp, там в примерах вычисляется факториал и преобразуется
в строку из 100 или даже 200 цифр. Такие вещи на С++ препроцессоре не сделать, нужен C99.
Re[3]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, alnsn, Вы писали:
A>Здравствуйте, okman, Вы писали:
O>>Когда увидел это сообщение, почти сразу вспомнил про метапрограммирование. O>>Например, вычисление факториала (самый популярный пример для начинающих осваивать тему) на шаблонах. O>>Или класс N-мерной таблицы, размерность которой задается параметром шаблона. O>>Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.
A>Да ладно, посмотри order-pp и chaos-pp, там в примерах вычисляется факториал и преобразуется A>в строку из 100 или даже 200 цифр. Такие вещи на С++ препроцессоре не сделать, нужен C99.
Только вот код на этом хаосе нечитабельный совсем
Здравствуйте, okman, Вы писали:
Кё>>Я напишу интерпретатор лисп и сделаю на лиспе любое метапрограммирование, чтобы под этим ни понималось. O>Но работать-то это будет на стадии исполнения C-программы, а значит, С-метапрограммированием считаться уже не будет.
Будет, т.к. мы изначально согласились, что замена компайлтайм на рантайм для нас годится. Если не согласились, то см. другую ветку рассуждения.
Идея в том, что без дополнительных ограничений, никакая одна фича не является ответом на вопрос. В такой постановке это либо все фичи, либо ни одна.
Re[7]: Чего принципиально не может C по сравнению c C++.
Хорошо, тогда я перефразирую: "на C нельзя производить рекурсивные вычисления в процессе компиляции".
Думаю, что если покопаться в шаблонах, можно будет вспомнить еще пару вещей, связанных с выведением типов.
P.S. Говорить "нельзя" всегда проще, чем отстаивать обратное, признаю.
Re[5]: Чего принципиально не может C по сравнению c C++.
В общем, к чему это я? К тому что деструкторы это вовсе не принципиально недостижимая в C фича C++. Если нет настоящих исключений, то деструкторы не более чем облегчают жизнь имхо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[6]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, night beast, Вы писали:
NB>имхо еще тормознее получится.
Это у тебя ошибочное имхо, получится по крайней мере не тормознее. А в случаях когда единственным ресурсом является память и освобождение происходит "одним махом", то получится быстрее.
Re[7]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Erop, Вы писали:
NB>>то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов
E>Ну, так в С иначе просто принято владеть ресурсами, чем в С++. Да и только.
да я не спорю.
ошибки там тоже принято по другому обрабатывать...
Re[5]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, MescalitoPeyot, Вы писали:
MP>>>Имхо в отсутствии исключений деструкторы и упомянутые ниже умные указатели не более чем синтаксический сахар. CC>>Отнюдь. CC>>Тот же RAII отлично работает и без исключений.
MP>И без деструкторов тоже. MP>Если мы говорим о принципиальной возможности получить в plain C возможности C++ то никто не мешает вместо деструкторов использовать некий аналог Symbian-овского cleanup stack и Objective-C-шного NSAutoreleasePool.
MP>Пример на псевдо-C-коде (5-минутный концепт, не вполне безопасен и корректен, но как концепт сойдет; для исключений добавить longjmp'ы с инструментарием по типу Symbian-овского): MP>
RAII работает не только при завершении функции но и при любом выходе из scope, будь то return или просто }
Что у тебя произойдёт при return из некоторой вложенности, в каждой из которых добавляются ещё RAII объекты?
Можно конечно попробовать сэмулировать но код будет уже децл макаронный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Сегодня был на собеседовании по C++.
Спросили чего такого принципиального нельзя сделать на C но можно на C++.
Я сказал, что фактически, все возможно.
Перебрал все стандартные варианты вроде наследования, виртуальных функций.
Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
В конце концов, C обладает полнотой по Тьюрингу.
Нет говорят, все не то.
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно. M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
не уверен. может исключения?
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно. M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
Шаблоны, исключения, перегрузка функций, параметры по умолчанию и т.д. если еще подумать. В принципе то и полноценное ООП на С не сделать, ну или это будет очень геморно и монстрообразно, макросы там курят и ничего не решают, нужен рантайм с хэшами, строковыми именами и прочей лабудой.
Если вопрос про конечный результат, то на С сделать можно все то же что и на С++, но затратнее.
Re[2]: Чего принципиально не может C по сравнению c C++.
I>Шаблоны "обладают полнотой по Тьюрингу" во время компиляции. Аналога в C нет.
То есть по вашему, препроцессор C не обладает полнотой по Тьрингу? Ну-ну.
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно. M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
Смартпоинтеры? ну и т.д. Т.е. не может автоматизировать симметричные операции. Да и вообще не корректно сравнивать Си и Си++, так как языки совершенно разные и подходы в программировании у них разные.
Re[2]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, more, Вы писали:
M>>Сегодня был на собеседовании по C++. M>>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>>Я сказал, что фактически, все возможно. M>>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>>В конце концов, C обладает полнотой по Тьюрингу. M>>Нет говорят, все не то.
NB>не уверен. может исключения?
Реализуется через longjmp()
Re[2]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.
Это не может быть хорошим ответом.
Если допускается заменять вычисления в compile-time вычислениями в рантайме, то метапрограммирование и все что угодно остальное не проблема.
Если такого не допускается, то подходит любая языковая фича C++, которой нет в C — перегрузка операторов, полиморфизм, наследование, шаблоны, потому что ее делает компилятор во время компиляции, а мы выбрали, что симулировать выполняемое в compile-time действиями в рантайме запрещено.
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно. M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
Ну если частности, то я не могу придумать как перегрузить операторы (вообще). И не могу придумать как сделать автоматическую конструкцию/деструкцию без дикого геммороя с учетом того, что могут бросаться исключения.
<Подпись удалена модератором>
Re[4]: Чего принципиально не может C по сравнению c C++.
M>>То есть по вашему, препроцессор C не обладает полнотой по Тьрингу? Ну-ну. AF>Ну да, не обладает. AF>Потому что программа препроцессируется только один раз и рекурсивных раскрытий макросов просто не получится. AF>Однако, если программа будет #include-ть себя саму, можно получить, к примеру, решение ханойской башни. AF>См. это сообщение: AF>http://mail.szabgab.com/pipermail/perl/2003-July/002701.html AF>и, в частности, этот код: AF>http://www0.us.ioccc.org/1995/vanschnitz.c
Посыпаю свою голову пеплом.
Re[3]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Кодёнок, Вы писали:
Кё>Если допускается заменять вычисления в compile-time вычислениями в рантайме, то метапрограммирование и все что угодно остальное не проблема.
Тогда это уже будет не метапрограммирование.
Re: Чего принципиально не может C по сравнению c C++.
Не совсем в тему и полусерьезно. По себе я бы сказал, принципиально невозможно заставить себя переписать например, это на С.
Может, это несколько отвлеченный от жизни пример, но с другой стороны — реально работающая программа, при написании которой TM очень помогло, практически сделало это возможным.
Re[4]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
Кё>>Если допускается заменять вычисления в compile-time вычислениями в рантайме, то метапрограммирование и все что угодно остальное не проблема. O>Тогда это уже будет не метапрограммирование.
Я напишу интерпретатор лисп и сделаю на лиспе любое метапрограммирование, чтобы под этим ни понималось.
Re[5]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, jazzer, Вы писали:
J>Только вот код на этом хаосе нечитабельный совсем
Речь, вроде как, шла о принципиальной невозможности, а не о читабельности, юзабельности и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Но работать-то это будет на стадии исполнения C-программы, а значит, С-метапрограммированием считаться уже не будет.
"Стадия исполнения", "стадия компиляции" -- развели из С/С++ какую-то fort-систему.
Вдруг у меня вообще не компилятор, а интерпретатор С?
Вообще, охота вам метапрограммирования, ну, типа там тип какой нагенерить хитрый, или данные вычислить и в статический массив положить, то на С и С++ это принято делать по разному, просто.
На С просто пишут свой генератор, и в make-файле зависимости правильно прописывают. А в С++ умные делают так же, а остальные пишут головоломные шаблоны
Хотя, конечно, существенно использовать систему типов языка при генерации кода в С намного сложнее, чем в С++. Правда и в С++ не сахар. Так что тёмный вопрос какой-то...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, alnsn, Вы писали:
A>Да ладно, посмотри order-pp и chaos-pp, там в примерах вычисляется факториал и преобразуется A>в строку из 100 или даже 200 цифр. Такие вещи на С++ препроцессоре не сделать, нужен C99.
Насчет ста это я загнул, а проверить не мог, что-то с SF неладное после атаки. Нашел код здесь:
$ cvs -d:pserver:anonymous@chaos-pp.cvs.sourceforge.net:/cvsroot/chaos-pp login
$ cvs -z3 -d:pserver:anonymous@chaos-pp.cvs.sourceforge.net:/cvsroot/chaos-pp co -P chaos-pp
$ cvs -z3 -d:pserver:anonymous@chaos-pp.cvs.sourceforge.net:/cvsroot/chaos-pp co -P order-pp
$ cd order-pp/example
$ grep -A 6 'int main' fibonacci.c
int main(void) {
printf
("The 500th Fibonacci number is "
ORDER_PP(8stringize(8to_lit(8fib(8nat(5,0,0)))))
".\n");
return 0;
}
$ cpp -I../inc fibonacci.c 2>/dev/null | grep -A 6 'int main'
int main(void) {
printf
("The 500th Fibonacci number is "
"139423224561697880139724382870407283950070256587697307264108962948325571622863290691557658876222521294125"
".\n");
return 0;
}
Re[6]: Чего принципиально не может C по сравнению c C++.
E>>Здравствуйте, jazzer, Вы писали: J>Я просто одно время воодушевился, когда узнал про chaos-pp, но меня так и не хватило разобраться в их базовых примерах даже.
У меня то же самое. Интересно, что автор думает в ретроспективе ...
Re: Чего принципиально не может C по сравнению c C++.
Здравствуйте, more, Вы писали:
M>Сегодня был на собеседовании по C++. M>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>Я сказал, что фактически, все возможно. M>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>В конце концов, C обладает полнотой по Тьюрингу. M>Нет говорят, все не то.
Вопрос из области: Что лучше, куча арбузов или трамвайная остановка?
Кто мешает получить ассеблерный код любой фичи в С++ и вставить его в С?
Best regards,
Oleg Bekhter
Software Developer
Re[3]: Чего принципиально не может C по сравнению c C++.
В С++ возможен статический вывод типов (читай — ветвление) на основе различий их размеров.
Специально приготовил пример.
Следующий код компилируется для 32- и 64-разрядных платформ, причем для каждой версии
печатается своя текстовая строка. На 16-разрядных и прочих архитектурах, где размер
указателя не равен ни 4, ни 8 байтам, получим ошибку:
Error: 'CheckPointerSize' uses undefined class 'MUST_HAVE_4_OR_8_BYTES_SIZE<T_PointerSize>'
Здравствуйте, MescalitoPeyot, Вы писали:
MP>Имхо в отсутствии исключений деструкторы и упомянутые ниже умные указатели не более чем синтаксический сахар.
Отнюдь.
Тот же RAII отлично работает и без исключений.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, night beast, Вы писали:
NB>>>не уверен. может исключения?
LP>>Реализуется через longjmp()
NB>не тестировал, но думаю по производительности не дотянет до плюсовых. NB>опять, же контекст в функции передавать придется. NB>вобщем, скорее нет чем да
2 Pavel Dvorkin:
так то мне на минусы покласть
но тема интересная, так что если есть чего сказать, то буду раз послушать.
или ты просто это, выражаешь "активную гражданскую позицию"?
Re[4]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Я намерен отстоять свое мнение.
не поверишь, это можно писать всем во всех сообщениях на RSDN Но обычно это все опускают.
O>В С++ возможен статический вывод типов (читай — ветвление) на основе различий их размеров. O>Специально приготовил пример.
O>Отмечу — выбор типа статический, то есть, на этапе компиляции. O>Попробуйте сделать то же самое на С.
плохой проимер, т.к. выражение
if ( 4 == sizeof int ) ...
и в С и в С++ будет вычислено статически.
второе, статически или нет вычисляется что-ниб — это оптимизация, и не имеет никакого отножение к subj.
---
С уважением,
Сергей Мухин
Re[5]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Сергей Мухин, Вы писали:
O>>Отмечу — выбор типа статический, то есть, на этапе компиляции. O>>Попробуйте сделать то же самое на С.
СМ>плохой проимер, т.к. выражение СМ>
СМ>if ( 4 == sizeof int ) ...
СМ>
СМ>и в С и в С++ будет вычислено статически.
Выражение будет вычислено статически, однако ветвление на основе размеров типов в C придется писать примерно так:
потому что написать #if (sizeof (void *) == n) не позволяют правила языка.
Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).
Re[6]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Сергей Мухин, Вы писали:
O>>>Отмечу — выбор типа статический, то есть, на этапе компиляции. O>>>Попробуйте сделать то же самое на С.
СМ>>плохой проимер, т.к. выражение СМ>>
СМ>>if ( 4 == sizeof int ) ...
СМ>>
СМ>>и в С и в С++ будет вычислено статически.
O>Выражение будет вычислено статически, однако ветвление на основе размеров типов в C придется писать примерно так:
O>
O>потому что написать #if (sizeof (void *) == n) не позволяют правила языка. O>Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).
разве компилятор не выкинет условие известное на этапе компиляции ?
Re[2]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Нужно было спросить, по каким критериям выделяется "принципиальная возможность".
Что-то мне подсказывает, что это единственный правильный ответ на данный вопрос. Ведь если разговор идет о выполнимости той или иной задачи, то тут Си скорее даже лидирует, ну а если разговор о "фенечках", то Си явно в пролете и сожно брать простейшие примеры, такие как например классы.
Re[3]: Чего принципиально не может C по сравнению c C++.
O>потому что написать #if (sizeof (void *) == n) не позволяют правила языка. O>Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).
1. ну и что что менее эффективно? какое это имеет отношение к "Чего принципиально не может C"?
2. Вы абсолютно ничего не понимаете в компиляторах. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"
т.е. по логиге 2, по матчасти 2.
---
С уважением,
Сергей Мухин
Re[4]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, MescalitoPeyot, Вы писали:
MP>>Имхо в отсутствии исключений деструкторы и упомянутые ниже умные указатели не более чем синтаксический сахар. CC>Отнюдь. CC>Тот же RAII отлично работает и без исключений.
И без деструкторов тоже.
Если мы говорим о принципиальной возможности получить в plain C возможности C++ то никто не мешает вместо деструкторов использовать некий аналог Symbian-овского cleanup stack и Objective-C-шного NSAutoreleasePool.
Пример на псевдо-C-коде (5-минутный концепт, не вполне безопасен и корректен, но как концепт сойдет; для исключений добавить longjmp'ы с инструментарием по типу Symbian-овского):
Здравствуйте, igna, Вы писали:
NB>>не тестировал, но думаю по производительности не дотянет до плюсовых.
I>Тоже не тестировал, но видел как longjmp выглядит на ассемблере. Было бы странно, если бы он куда-то там не дотянул, он же делает ведь сущую ерунду, стек назад не раскручивает, деструкторов не вызывает, а просто восстанавливает когда-то запомненное состояние стека, предоставляя программисту самому заботиться об освобождении выделенной динамической памяти и других ресурсов.
не-не дэвид блейн.
плюсовые исключения подразумевают вызов деструкторов.
то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов
Здравствуйте, ArtDenis, Вы писали:
NB>>ну что тут скажешь, "нет преграды патриотам" (с)
AD>Вот-вот. На что только православные сишники не пойдут, лишь бы с++ не использовать
не, на самом деле для кодогенерации самое то, если б только не засада с исключениями
если кто подскажет как сделать табличную реализацию на сях, буду очень благодарен
Re[7]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>1. ну и что что менее эффективно? какое это имеет отношение к "Чего принципиально не может C"?
Моя точка зрения заключается в том, что в С невозможно вывести тип (структуру) или сделать ветвление на стадии компиляции,
которое бы основывалось на различиях в размерах данных. Что тут непонятного ? Напишите пример, если хотите опровергнуть.
СМ>2. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"
При использовании шаблонов я имею стопроцентную гарантию того, что данного холостого кода не будет.
А в Вашем примере мне приходится полагаться на компилятор и его оптимизацию.
Поверю, если покажете пункт Стандарта, где это гарантируется.
Re[8]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>1. ну и что что менее эффективно? какое это имеет отношение к "Чего принципиально не может C"?
O>Моя точка зрения заключается в том, что в С невозможно вывести тип (структуру) или сделать ветвление на стадии компиляции, O>которое бы основывалось на различиях в размерах данных. Что тут непонятного ? Напишите пример, если хотите опровергнуть.
Это ОПТИМИЗАЦИЯ какое это имеет отношение к "Чего принципиально не может C"?
СМ>>2. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"
O>При использовании шаблонов я имею стопроцентную гарантию того, что данного холостого кода не будет. O>А в Вашем примере мне приходится полагаться на компилятор и его оптимизацию. O>Поверю, если покажете пункт Стандарта, где это гарантируется.
какое это имеет отношение к "Чего принципиально не может C"?
Вы пишите, что вот С++ здесь не генерить, а С генерит (да и то на самом деле не генереит), и это ПРИНЦИПИАЛЬНАЯ разница??? бред бред
---
С уважением,
Сергей Мухин
Re[6]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, night beast, Вы писали:
NB>плюсовые исключения подразумевают вызов деструкторов. NB>то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов
Освобождение ресурсов может быть совсем по другому организовано, не обязательно имитировать C++. Например:
1. Вызываем setjump и инициализируем репозитарий запрошенных ресурсов.
2. Работаем запрашивая ресурсы и сохраняя информацию о них в репозитарии.
3. При возникновении исключительной ситуации выполняем longjmp и освобождаем ресурсы.
Re[7]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, igna, Вы писали:
NB>>плюсовые исключения подразумевают вызов деструкторов. NB>>то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов
I>Освобождение ресурсов может быть совсем по другому организовано, не обязательно имитировать C++. Например:
I>1. Вызываем setjump и инициализируем репозитарий запрошенных ресурсов. I>2. Работаем запрашивая ресурсы и сохраняя информацию о них в репозитарии. I>3. При возникновении исключительной ситуации выполняем longjmp и освобождаем ресурсы.
имхо еще тормознее получится.
Re[2]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, more, Вы писали:
M>>Сегодня был на собеседовании по C++. M>>Спросили чего такого принципиального нельзя сделать на C но можно на C++. M>>Я сказал, что фактически, все возможно. M>>Перебрал все стандартные варианты вроде наследования, виртуальных функций. M>>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать. M>>В конце концов, C обладает полнотой по Тьюрингу. M>>Нет говорят, все не то.
K>Деструкторы не может.
Ограниченно может. Например, для элементов создающихся с помощью nuovo деструкторы будут вызываться. Если допилить и приукрасить то наверное даже без гемморая FUNCTION или CALL
//macro#define getHashCode(T) hash(#T)
#define nuovo(T)(construct(sizeof(T),getHashCode(#T)),(T*)currentPointer)
#define FUNCTION(f)(callPrologue(),f)
#define CALL(f) f##,##callEpilogue()
//base notionsint hash(char* values)
{
int count = 0;
char* p = values;
while(*p!=0)
{
count += *p;
p++;
}
return count;
}
typedef struct _Node
{
int elementTypeHash;
void* elementPointer;
struct _Node* nextNode;
}Node;
typedef struct _NodeHolder
{
Node* firstNode;
Node* lastNode;
}NodeHolder;
//global state variables
NodeHolder holder;
Node* currentNode;
void* currentPointer;
Node* beforeCallNode;
//global functions;void globalStateInit()
{
currentNode = NULL;
holder.firstNode = holder.lastNode = NULL;
}
//construct, destruct void construct(int size, int hashCode)
{
currentPointer = malloc(size);
currentNode = (Node*)malloc(sizeof(Node));
currentNode->elementTypeHash = getHashCode(int);
currentNode->elementPointer = currentPointer;
currentNode->nextNode = 0;
if(holder.firstNode == NULL)
{
holder.firstNode = holder.lastNode = currentNode;
}
else
{
holder.lastNode->nextNode = currentNode;
holder.lastNode = currentNode;
}
}
void destructElement(int code, void* pointer)
{
//поиск детсруктора по хэш коду
;
free(pointer);
}
//prologue epilogue to clean after quitvoid callPrologue()
{
beforeCallNode = holder.lastNode;
//сохранение состояния для исключения.
printf("we are int prologue \n");
}
void callEpilogue()
{
int elementDeleted = 0;
if(NULL == beforeCallNode)
{
beforeCallNode = holder.firstNode;
}
while(beforeCallNode)
{
destructElement(beforeCallNode->elementTypeHash, beforeCallNode->elementPointer);
beforeCallNode = beforeCallNode->nextNode;
elementDeleted ++;
}
printf("epilogue %d \n", elementDeleted);
}
//testint add(int a, int b)
{
int v1 = *nuovo(int);
char v2 = *nuovo(char);
return a+b;
}
int _tmain(int argc, _TCHAR* argv[])
{
int a = 52;
int b = 25;
int c = 0;
globalStateInit();
c = CALL(FUNCTION(add)(a,b));
return 0;
}
<Подпись удалена модератором>
Re[3]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Нужно было спросить, по каким критериям выделяется "принципиальная возможность".
KP>Что-то мне подсказывает, что это единственный правильный ответ на данный вопрос. Ведь если разговор идет о выполнимости той или иной задачи, то тут Си скорее даже лидирует, ну а если разговор о "фенечках", то Си явно в пролете и сожно брать простейшие примеры, такие как например классы.
Индивидуально. В общем случае, очевидно, не так поскольку никто не мешает писать на ++ в C стиле.
<Подпись удалена модератором>
Re[9]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, igna, Вы писали:
NB>>имхо еще тормознее получится.
I>Это у тебя ошибочное имхо, получится по крайней мере не тормознее. А в случаях когда единственным ресурсом является память и освобождение происходит "одним махом", то получится быстрее.
трудно что-то с чем-то сравнивать, не имея этого чего-то перед глазами
ну да ладно.
Re[4]: Чего принципиально не может C по сравнению c C++.
O>Отмечу — выбор типа статический, то есть, на этапе компиляции. O>Попробуйте сделать то же самое на С.
Массив указателей на строки, индексируемый размером структуры, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).
Чушь! Нормальный компиллер С всё заоптимизирует и никакой динамики в коже не останется...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Чего принципиально не может C по сравнению c C++.
NB>то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов
Ну, так в С иначе просто принято владеть ресурсами, чем в С++. Да и только.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>При использовании шаблонов я имею стопроцентную гарантию того, что данного холостого кода не будет. O>А в Вашем примере мне приходится полагаться на компилятор и его оптимизацию.
Зато тебе приходится рассчитывать на то, что всё за'inline'тся...
Кстати, и безусловный переход оптимизировать легче, и потери, в случае файла оптимизатора больше и код в С понятнее получается...
Ты не в туда копаешь. В С не получится написать удобный массив. Но получится неудобный. Ну и т. д. и т. п...
На самом деле можно предложить такую головоломную конструкцию, которая хитро очень с системой типов взаимодействует. Но это егаэкзотика. И я уверен, что та задача, для которой такая мегаэкзотика нужна, не решается на С как-то иначе. Наверняка проще, кстати
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Сергей Мухин,
Вы писали:
СМ>Это ОПТИМИЗАЦИЯ какое это имеет отношение к "Чего принципиально не может C"?
Принципиальная разница в том, что С++ позволяет выводить на стадии компиляции новые типы, свойства которых,
опираясь на одну и ту же декларацию, реализуются избирательно для каждого типа в отдельности.
Это и есть вывод типов (одна из форм вычислений в compile-time, которую невозможно подделать макросами).
Для любого типа, заданного шаблонным параметром T, будет выведен соответствующий тип type_array с массивом char
соответствующей размерности внутри. Для бесконечно большого количества входных типов T всегда будет
оставаться одна декларация этой шаблонной структуры, потому что выводимые типы создаются компилятором.
В C для этого пришлось бы создавать бесконечно большое количество вариаций type_array, которые все равно
годились бы только для используемого программой набора типов — при включении новых типов пришлось бы
снова создавать разновидности type_array. Все потому, что выводить новые типы (структуры) C не умеет.
Из-за этого отличия шаблон type_array может использоваться любым клиентским кодом без модификаций, а аналог,
написанный на C, потребует ручной реализации каждого нового типа.
СМ>>>2. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода" СМ>Вы пишите, что вот С++ здесь не генерить, а С генерит (да и то на самом деле не генереит), и это ПРИНЦИПИАЛЬНАЯ разница??? бред бред
Если бред — не читайте. Никто не заставляет.
Re[8]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, night beast, Вы писали:
NB>ошибки там тоже принято по другому обрабатывать...
Ну лонгджамп -- это, тем не менее, С'шная функция, а не плюсовая
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, Erop, Вы писали:
NB>>ошибки там тоже принято по другому обрабатывать...
E>Ну лонгджамп -- это, тем не менее, С'шная функция, а не плюсовая
ага. в плюсах она вообще вредная
Re[10]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, 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++ и ассемблером и что ни делай (объекты, виртуальные функции, исключения, сборщик мусора) оно все на виду будет, под капот не спрячешь, так что нечего туда пальцы совать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[6]: Чего принципиально не может C по сравнению c C++.
On 03.02.2011 17:03, night beast wrote:
> W>Посмотри исходники <http://www.postgresql.org/ftp/source/> postgresql, например. > глянул одним глазом. как оно в многопоточном окружении работает?
По идее его там быть не должно. Я правда не уверен на счёт постгреса, но
в принципе в нормальной СУБД многопоточности быть не должно.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, MescalitoPeyot, Вы писали:
MP>Естественно подобные соглашения накладывают определенные ограничения на код, требуют от разработчика следовать каким-то соглашениям, но тут уж извините — C по уровню находится где-то между C++ и ассемблером и что ни делай (объекты, виртуальные функции, исключения, сборщик мусора) оно все на виду будет, под капот не спрячешь, так что нечего туда пальцы совать.
Ну вот и получается. Что написать то можно всё. Но вот какой ценой это напишется?
Даже на ассемблере можно написать вообще всё, один фиг все языки в итоге приходят к тому, что машинный код исполняется на проце, пусть даже язык интерпретируемый.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, CreatorCray, Вы писали:
CC>Ну вот и получается. Что написать то можно всё. Но вот какой ценой это напишется? CC>Даже на ассемблере можно написать вообще всё, один фиг все языки в итоге приходят к тому, что машинный код исполняется на проце, пусть даже язык интерпретируемый.
Ну речь-то в исходном посте шла о принципиальной возможности. А принципиально в C можно сделать — и делают все вышеперечисленное (разве что cleanup stack не видел, но я довольно молодой и вообще плюсовик).
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[10]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, okman, Вы писали:
O>Принципиальная разница в том, что С++ позволяет выводить на стадии компиляции новые типы, свойства которых, O>опираясь на одну и ту же декларацию, реализуются избирательно для каждого типа в отдельности. O>Это и есть вывод типов (одна из форм вычислений в compile-time, которую невозможно подделать макросами).
O>Например:
O>
... O>В C для этого пришлось бы создавать бесконечно большое количество вариаций type_array, которые все равно O>годились бы только для используемого программой набора типов — при включении новых типов пришлось бы O>снова создавать разновидности type_array. Все потому, что выводить новые типы (структуры) C не умеет. O>Из-за этого отличия шаблон type_array может использоваться любым клиентским кодом без модификаций, а аналог, O>написанный на C, потребует ручной реализации каждого нового типа.
СМ>>>>2. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода" СМ>>Вы пишите, что вот С++ здесь не генерить, а С генерит (да и то на самом деле не генереит), и это ПРИНЦИПИАЛЬНАЯ разница??? бред бред
O>Если бред — не читайте. Никто не заставляет.
натуральный бред. Все ваши типы жестко прошиты в бинарник. Никаких новых типов без тайпящего ручками программиста не может быть в принципе. Разница с С в том что кто-то сэкономил 1 строку кода на тип. Вы там бонусы за строки кода получаете? Как 1 строка кода стала принципиальной разницей ?
Кстати программистам на C не нужны все ваши type_array просто по причине того что проверки типов там не нужны и с точки зрения поведения это все массивы символов.
Re[11]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, SleepyDrago,
Вы писали:
SD>натуральный бред. Все ваши типы жестко прошиты в бинарник. Никаких новых типов без тайпящего ручками программиста не может быть в принципе. Разница с С в том что кто-то сэкономил 1 строку кода на тип. Вы там бонусы за строки кода получаете? Как 1 строка кода стала принципиальной разницей ?
SD>Кстати программистам на C не нужны все ваши type_array просто по причине того что проверки типов там не нужны и с точки зрения поведения это все массивы символов.
Моя версия правильного ответа на вопрос "чего принципиально не может C по сравнению c C++" была подробно представлена выше.
Не считаю нужным опять ее разжевывать.
Re[7]: Чего принципиально не может C по сравнению c C++.
Здравствуйте, MasterZiv, Вы писали:
>> W>Посмотри исходники <http://www.postgresql.org/ftp/source/> postgresql, например. >> глянул одним глазом. как оно в многопоточном окружении работает?
MZ>По идее его там быть не должно.
почему?
MZ>Я правда не уверен на счёт постгреса, но MZ>в принципе в нормальной СУБД многопоточности быть не должно.
в постгресе они указатель на текущий sigjmp_buf в глобальной переменной хранят