Re: Чего принципиально не может C по сравнению c C++.
От: igna Россия  
Дата: 03.02.11 11:40
Оценка: 2 (2) +7
Здравствуйте, more, Вы писали:

M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.

M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.

Шаблоны "обладают полнотой по Тьюрингу" во время компиляции. Аналога в C нет.
Re[2]: Чего принципиально не может C по сравнению c C++.
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 03.02.11 13:10
Оценка: 15 (1) +1 :))) :)))
Здравствуйте, Viper_Craft, Вы писали:

V_C>забавно у меня был противоположный случай )))

Это легко. На С++ нельзя операционки писать, и пример тому Симбиан

V_C>бежать от такой команды надо, как от огня...

Это точно.
Re: Чего принципиально не может C по сравнению c C++.
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 03.02.11 11:38
Оценка: 9 (2) +6
Здравствуйте, more, Вы писали:

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.

M>Нет говорят, все не то.

Само-собой. Затрахать собеседника вопросами по Си, существенно сложнее чем вопросами по Плюсам. Так что правильный ответ: вынести мозг кандидату дурацкими вопросами.
Re[3]: Чего принципиально не может C по сравнению c C++.
От: Alexey F  
Дата: 03.02.11 12:45
Оценка: 13 (3) +1
Здравствуйте, 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++.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.02.11 19:18
Оценка: 1 (1) +3
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.

Нужно было спросить, по каким критериям выделяется "принципиальная возможность".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Чего принципиально не может C по сравнению c C++.
От: ArtyomR0Bot  
Дата: 03.02.11 11:59
Оценка: 1 (1) +1
Здравствуйте, more, Вы писали:

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.

Вопрос неоднозначный. В смысле результата — можно всё.

M>Я сказал, что фактически, все возможно.

Правильно сказали.

M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.

M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
Это всё никак не сказывается на результате, по крайней мере положительно. Тут вопрос в том, насколько для программиста удобно реализовывать алгоритмы. Можно делать списки, деревья, стеки; работать с указателями. Что ещё надо?
Re: Чего принципиально не может C по сравнению c C++.
От: Кодёнок  
Дата: 03.02.11 12:33
Оценка: 1 (1) +1
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.

Зависит от набора ограничений. Ведь в предельном случае можно на C написать компилятор/интерпретатор другого языка, превосходящего C++, и исполнить программу на нем из строковой переменной.
Re: Чего принципиально не может C по сравнению c C++.
От: Kluev  
Дата: 03.02.11 11:44
Оценка: +2
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.

Деструкторы не может.
Re: Чего принципиально не может C по сравнению c C++.
От: Erop Россия  
Дата: 03.02.11 12:40
Оценка: :))
Здравствуйте, more, Вы писали:

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.

M>Нет говорят, все не то.

Функциональщину нельзя, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 03.02.11 12:59
Оценка: -2
Здравствуйте, los puercos, Вы писали:

NB>>не уверен. может исключения?


LP>Реализуется через longjmp()


не тестировал, но думаю по производительности не дотянет до плюсовых.
опять, же контекст в функции передавать придется.
вобщем, скорее нет чем да
Re[5]: Чего принципиально не может C по сравнению c C++.
От: denisko http://sdeniskos.blogspot.com/
Дата: 03.02.11 13:37
Оценка: -2
Здравствуйте, Кодёнок, Вы писали:

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


Кё>>>Если допускается заменять вычисления в compile-time вычислениями в рантайме, то метапрограммирование и все что угодно остальное не проблема.

O>>Тогда это уже будет не метапрограммирование.

Кё>Я напишу интерпретатор лисп и сделаю на лиспе любое метапрограммирование, чтобы под этим ни понималось.

Напиши лучше машину времени и убей страутсрупа, чтобы глупостей не делал.
<Подпись удалена модератором>
Re[5]: Чего принципиально не может C по сравнению c C++.
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.11 15:43
Оценка: +1 :)
Здравствуйте, Erop, Вы писали:

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


J>>Только вот код на этом хаосе нечитабельный совсем

E>Речь, вроде как, шла о принципиальной невозможности, а не о читабельности, юзабельности и т. д...
Тоже верно.
Я просто одно время воодушевился, когда узнал про chaos-pp, но меня так и не хватило разобраться в их базовых примерах даже.
Старый я стал совсем
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Чего принципиально не может C по сравнению c C++.
От: TimurSPB Интернет  
Дата: 03.02.11 19:37
Оценка: -1 :)
Код:


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++.
От: igna Россия  
Дата: 04.02.11 07:41
Оценка: +2
Здравствуйте, night beast, Вы писали:

NB>не тестировал, но думаю по производительности не дотянет до плюсовых.


Тоже не тестировал, но видел как longjmp выглядит на ассемблере. Было бы странно, если бы он куда-то там не дотянул, он же делает ведь сущую ерунду, стек назад не раскручивает, деструкторов не вызывает, а просто восстанавливает когда-то запомненное состояние стека, предоставляя программисту самому заботиться об освобождении выделенной динамической памяти и других ресурсов.
Re[4]: Чего принципиально не может C по сравнению c C++.
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 04.02.11 08:29
Оценка: +2
Здравствуйте, igna, Вы писали:

I>Здравствуйте, kaa.python, Вы писали:


KP>> ... если разговор идет о выполнимости той или иной задачи, то тут Си скорее даже лидирует ...


I>Что ты имеешь в виду, новые возможности C99, которых еще нет в C++?


Нет, я имею ввиду что на Си можно написать что угодно, а для ряда экзотических ситуаций использование плюсов просто не возможно (например из за отсутствия компилятора для какого-то девайса).
Посути, вопрос не полон. Толи речь идет о фенечках языка, толи о спектре решаемых задач.
Re[2]: Чего принципиально не может C по сравнению c C++.
От: Sni4ok  
Дата: 03.02.11 18:19
Оценка: 2 (1)
Здравствуйте, 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++.
От: Erop Россия  
Дата: 04.02.11 10:29
Оценка: 1 (1)
Здравствуйте, more, Вы писали:

M>Нет говорят, все не то.


Ещё есть вариант такой, что на С фиг напишешь библиотеку состоящую только их хедеров. Но я не уверен, что это можно считать "принципиальным ограничением"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Чего принципиально не может C по сравнению c C++.
От: Viper_Craft  
Дата: 03.02.11 11:41
Оценка: +1
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.

забавно у меня был противоположный случай )))

бежать от такой команды надо, как от огня...
Re: Чего принципиально не может C по сравнению c C++.
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.11 12:53
Оценка: :)
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.

Когда увидел это сообщение, почти сразу вспомнил про метапрограммирование.
Например, вычисление факториала (самый популярный пример для начинающих осваивать тему) на шаблонах.
Или класс N-мерной таблицы, размерность которой задается параметром шаблона.
Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.
Re[2]: Чего принципиально не может C по сравнению c C++.
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 03.02.11 13:07
Оценка: +1
Здравствуйте, okman, Вы писали:

O>Когда увидел это сообщение, почти сразу вспомнил про метапрограммирование.

O>Например, вычисление факториала (самый популярный пример для начинающих осваивать тему) на шаблонах.
O>Или класс N-мерной таблицы, размерность которой задается параметром шаблона.
O>Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.

Да ладно, посмотри order-pp и chaos-pp, там в примерах вычисляется факториал и преобразуется
в строку из 100 или даже 200 цифр. Такие вещи на С++ препроцессоре не сделать, нужен C99.
Re[3]: Чего принципиально не может C по сравнению c C++.
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.11 13:09
Оценка: :)
Здравствуйте, alnsn, Вы писали:

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


O>>Когда увидел это сообщение, почти сразу вспомнил про метапрограммирование.

O>>Например, вычисление факториала (самый популярный пример для начинающих осваивать тему) на шаблонах.
O>>Или класс N-мерной таблицы, размерность которой задается параметром шаблона.
O>>Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.

A>Да ладно, посмотри order-pp и chaos-pp, там в примерах вычисляется факториал и преобразуется

A>в строку из 100 или даже 200 цифр. Такие вещи на С++ препроцессоре не сделать, нужен C99.
Только вот код на этом хаосе нечитабельный совсем
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: Чего принципиально не может C по сравнению c C++.
От: Кодёнок  
Дата: 03.02.11 13:45
Оценка: +1
Здравствуйте, okman, Вы писали:

Кё>>Я напишу интерпретатор лисп и сделаю на лиспе любое метапрограммирование, чтобы под этим ни понималось.

O>Но работать-то это будет на стадии исполнения C-программы, а значит, С-метапрограммированием считаться уже не будет.

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

Идея в том, что без дополнительных ограничений, никакая одна фича не является ответом на вопрос. В такой постановке это либо все фичи, либо ни одна.
Re[7]: Чего принципиально не может C по сравнению c C++.
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.11 13:52
Оценка: -1
Здравствуйте, Кодёнок.

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

P.S. Говорить "нельзя" всегда проще, чем отстаивать обратное, признаю.
Re[5]: Чего принципиально не может C по сравнению c C++.
От: MescalitoPeyot Украина  
Дата: 04.02.11 08:22
Оценка: +1
В общем, к чему это я? К тому что деструкторы это вовсе не принципиально недостижимая в C фича C++. Если нет настоящих исключений, то деструкторы не более чем облегчают жизнь имхо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[6]: Чего принципиально не может C по сравнению c C++.
От: ArtDenis Россия  
Дата: 04.02.11 08:23
Оценка: +1
Здравствуйте, night beast, Вы писали:

NB>ну что тут скажешь, "нет преграды патриотам" (с)


Вот-вот. На что только православные сишники не пойдут, лишь бы с++ не использовать
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[8]: Чего принципиально не может C по сравнению c C++.
От: igna Россия  
Дата: 04.02.11 10:02
Оценка: +1
Здравствуйте, night beast, Вы писали:

NB>имхо еще тормознее получится.


Это у тебя ошибочное имхо, получится по крайней мере не тормознее. А в случаях когда единственным ресурсом является память и освобождение происходит "одним махом", то получится быстрее.
Re[7]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 04.02.11 10:55
Оценка: +1
Здравствуйте, Erop, Вы писали:

NB>>то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов


E>Ну, так в С иначе просто принято владеть ресурсами, чем в С++. Да и только.


да я не спорю.
ошибки там тоже принято по другому обрабатывать...
Re[5]: Чего принципиально не может C по сравнению c C++.
От: CreatorCray  
Дата: 04.02.11 11:55
Оценка: +1
Здравствуйте, MescalitoPeyot, Вы писали:

MP>>>Имхо в отсутствии исключений деструкторы и упомянутые ниже умные указатели не более чем синтаксический сахар.

CC>>Отнюдь.
CC>>Тот же RAII отлично работает и без исключений.

MP>И без деструкторов тоже.

MP>Если мы говорим о принципиальной возможности получить в plain C возможности C++ то никто не мешает вместо деструкторов использовать некий аналог Symbian-овского cleanup stack и Objective-C-шного NSAutoreleasePool.

MP>Пример на псевдо-C-коде (5-минутный концепт, не вполне безопасен и корректен, но как концепт сойдет; для исключений добавить longjmp'ы с инструментарием по типу Symbian-овского):

MP>

MP>int some_function()
MP>{
MP>    FUNCTION_BEGIN(int);
    
MP>    FUNCTION_END();
MP>}

MP>


RAII работает не только при завершении функции но и при любом выходе из scope, будь то return или просто }
Что у тебя произойдёт при return из некоторой вложенности, в каждой из которых добавляются ещё RAII объекты?
Можно конечно попробовать сэмулировать но код будет уже децл макаронный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Чего принципиально не может C по сравнению c C++.
От: more  
Дата: 03.02.11 11:35
Оценка:
Сегодня был на собеседовании по C++.
Спросили чего такого принципиального нельзя сделать на C но можно на C++.
Я сказал, что фактически, все возможно.
Перебрал все стандартные варианты вроде наследования, виртуальных функций.
Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
В конце концов, C обладает полнотой по Тьюрингу.
Нет говорят, все не то.
Re: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 03.02.11 11:39
Оценка:
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.

не уверен. может исключения?
Re: Чего принципиально не может C по сравнению c C++.
От: winston Россия  
Дата: 03.02.11 12:05
Оценка:
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.

Шаблоны, исключения, перегрузка функций, параметры по умолчанию и т.д. если еще подумать. В принципе то и полноценное ООП на С не сделать, ну или это будет очень геморно и монстрообразно, макросы там курят и ничего не решают, нужен рантайм с хэшами, строковыми именами и прочей лабудой.
Если вопрос про конечный результат, то на С сделать можно все то же что и на С++, но затратнее.
Re[2]: Чего принципиально не может C по сравнению c C++.
От: more  
Дата: 03.02.11 12:06
Оценка:
I>Шаблоны "обладают полнотой по Тьюрингу" во время компиляции. Аналога в C нет.
То есть по вашему, препроцессор C не обладает полнотой по Тьрингу? Ну-ну.
Re: Чего принципиально не может C по сравнению c C++.
От: szag  
Дата: 03.02.11 12:08
Оценка:
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.

Смартпоинтеры? ну и т.д. Т.е. не может автоматизировать симметричные операции. Да и вообще не корректно сравнивать Си и Си++, так как языки совершенно разные и подходы в программировании у них разные.
Re[2]: Чего принципиально не может C по сравнению c C++.
От: los puercos  
Дата: 03.02.11 12:43
Оценка:
Здравствуйте, night beast, Вы писали:

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


M>>Сегодня был на собеседовании по C++.

M>>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>>Я сказал, что фактически, все возможно.
M>>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>>В конце концов, C обладает полнотой по Тьюрингу.
M>>Нет говорят, все не то.

NB>не уверен. может исключения?


Реализуется через longjmp()
Re[2]: Чего принципиально не может C по сравнению c C++.
От: Кодёнок  
Дата: 03.02.11 13:04
Оценка:
Здравствуйте, okman, Вы писали:

O>Такие вещи на препроцессоре не сделать. Так что правильный ответ тут уже написали.


Это не может быть хорошим ответом.

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

Если такого не допускается, то подходит любая языковая фича C++, которой нет в C — перегрузка операторов, полиморфизм, наследование, шаблоны, потому что ее делает компилятор во время компиляции, а мы выбрали, что симулировать выполняемое в compile-time действиями в рантайме запрещено.
Re: Чего принципиально не может C по сравнению c C++.
От: denisko http://sdeniskos.blogspot.com/
Дата: 03.02.11 13:10
Оценка:
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.
Ну если частности, то я не могу придумать как перегрузить операторы (вообще). И не могу придумать как сделать автоматическую конструкцию/деструкцию без дикого геммороя с учетом того, что могут бросаться исключения.
<Подпись удалена модератором>
Re[4]: Чего принципиально не может C по сравнению c C++.
От: wander  
Дата: 03.02.11 13:15
Оценка:
Здравствуйте, night beast, Вы писали:

NB>вобщем, скорее нет чем да


Посмотри исходники postgresql, например.
Re[5]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 03.02.11 13:19
Оценка:
Здравствуйте, wander, Вы писали:

NB>>вобщем, скорее нет чем да


W>Посмотри исходники postgresql, например.


вот уж послал, так послал
неужели не лонгджампах обработку ошибок сделали?
ну что тут скажешь, "нет преграды патриотам" (с)
Re[4]: Правильный ответ. Выше.
От: more  
Дата: 03.02.11 13:22
Оценка:
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++.
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.11 13:24
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Если допускается заменять вычисления в compile-time вычислениями в рантайме, то метапрограммирование и все что угодно остальное не проблема.


Тогда это уже будет не метапрограммирование.
Re: Чего принципиально не может C по сравнению c C++.
От: lxa http://aliakseis.livejournal.com
Дата: 03.02.11 13:30
Оценка:
Не совсем в тему и полусерьезно. По себе я бы сказал, принципиально невозможно заставить себя переписать например, это на С.
Может, это несколько отвлеченный от жизни пример, но с другой стороны — реально работающая программа, при написании которой TM очень помогло, практически сделало это возможным.
Re[4]: Чего принципиально не может C по сравнению c C++.
От: Кодёнок  
Дата: 03.02.11 13:34
Оценка:
Здравствуйте, okman, Вы писали:

Кё>>Если допускается заменять вычисления в compile-time вычислениями в рантайме, то метапрограммирование и все что угодно остальное не проблема.

O>Тогда это уже будет не метапрограммирование.

Я напишу интерпретатор лисп и сделаю на лиспе любое метапрограммирование, чтобы под этим ни понималось.
Re[5]: Чего принципиально не может C по сравнению c C++.
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.11 13:41
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Я напишу интерпретатор лисп и сделаю на лиспе любое метапрограммирование, чтобы под этим ни понималось.


Но работать-то это будет на стадии исполнения C-программы, а значит, С-метапрограммированием считаться уже не будет.
Re[5]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 03.02.11 14:03
Оценка:
Здравствуйте, wander, Вы писали:

NB>>вобщем, скорее нет чем да


W>Посмотри исходники postgresql, например.


глянул одним глазом. как оно в многопоточном окружении работает?
Re[4]: Чего принципиально не может C по сравнению c C++.
От: Erop Россия  
Дата: 03.02.11 15:10
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Только вот код на этом хаосе нечитабельный совсем

Речь, вроде как, шла о принципиальной невозможности, а не о читабельности, юзабельности и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Чего принципиально не может C по сравнению c C++.
От: Erop Россия  
Дата: 03.02.11 15:33
Оценка:
Здравствуйте, okman, Вы писали:

O>Но работать-то это будет на стадии исполнения C-программы, а значит, С-метапрограммированием считаться уже не будет.


"Стадия исполнения", "стадия компиляции" -- развели из С/С++ какую-то fort-систему.
Вдруг у меня вообще не компилятор, а интерпретатор С?

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

Хотя, конечно, существенно использовать систему типов языка при генерации кода в С намного сложнее, чем в С++. Правда и в С++ не сахар. Так что тёмный вопрос какой-то...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Чего принципиально не может C по сравнению c C++.
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 03.02.11 17:57
Оценка:
Здравствуйте, 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++.
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 03.02.11 17:57
Оценка:
E>>Здравствуйте, jazzer, Вы писали:
J>Я просто одно время воодушевился, когда узнал про chaos-pp, но меня так и не хватило разобраться в их базовых примерах даже.
У меня то же самое. Интересно, что автор думает в ретроспективе ...
Re: Чего принципиально не может C по сравнению c C++.
От: ononim  
Дата: 03.02.11 19:09
Оценка:
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
RAII?
Как много веселых ребят, и все делают велосипед...
Re[2]: Чего принципиально не может C по сравнению c C++.
От: MescalitoPeyot Украина  
Дата: 03.02.11 20:01
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Деструкторы не может.


Имхо в отсутствии исключений деструкторы и упомянутые ниже умные указатели не более чем синтаксический сахар.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re: Чего принципиально не может C по сравнению c C++.
От: Oleg Bekhter Украина www.bekhter.net
Дата: 03.02.11 21:36
Оценка:
Здравствуйте, more, Вы писали:

M>Сегодня был на собеседовании по C++.

M>Спросили чего такого принципиального нельзя сделать на C но можно на C++.
M>Я сказал, что фактически, все возможно.
M>Перебрал все стандартные варианты вроде наследования, виртуальных функций.
M>Поведение шаблонов с допущениями тоже можно реализовать с помощью макросов. В крайнем случае в рантайм реализовать.
M>В конце концов, C обладает полнотой по Тьюрингу.
M>Нет говорят, все не то.
Вопрос из области: Что лучше, куча арбузов или трамвайная остановка?
Кто мешает получить ассеблерный код любой фичи в С++ и вставить его в С?
Best regards,
Oleg Bekhter
Software Developer
Re[3]: Чего принципиально не может C по сравнению c C++.
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.11 23:37
Оценка:
Здравствуйте, Sni4ok.

Я намерен отстоять свое мнение.

В С++ возможен статический вывод типов (читай — ветвление) на основе различий их размеров.
Специально приготовил пример.

Следующий код компилируется для 32- и 64-разрядных платформ, причем для каждой версии
печатается своя текстовая строка. На 16-разрядных и прочих архитектурах, где размер
указателя не равен ни 4, ни 8 байтам, получим ошибку:
Error: 'CheckPointerSize' uses undefined class 'MUST_HAVE_4_OR_8_BYTES_SIZE<T_PointerSize>'

  Скрытый текст
#include <iostream>



template<size_t T_PointerSize>
class MUST_HAVE_4_OR_8_BYTES_SIZE;



template <>
class MUST_HAVE_4_OR_8_BYTES_SIZE<4>
{
public:
    MUST_HAVE_4_OR_8_BYTES_SIZE()
    {
        std::cout << "4 bytes." << std::endl;
    }
};



template <>
class MUST_HAVE_4_OR_8_BYTES_SIZE<8>
{
public:
    MUST_HAVE_4_OR_8_BYTES_SIZE()
    {
        std::cout << "8 bytes." << std::endl;
    }
};



int main()
{
MUST_HAVE_4_OR_8_BYTES_SIZE<sizeof (void *)> CheckPointerSize;

return 0;
}


Отмечу — выбор типа статический, то есть, на этапе компиляции.
Попробуйте сделать то же самое на С.

S>fail


Мимо.
Re[3]: Чего принципиально не может C по сравнению c C++.
От: CreatorCray  
Дата: 04.02.11 00:45
Оценка:
Здравствуйте, MescalitoPeyot, Вы писали:

MP>Имхо в отсутствии исключений деструкторы и упомянутые ниже умные указатели не более чем синтаксический сахар.

Отнюдь.
Тот же RAII отлично работает и без исключений.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 04.02.11 05:11
Оценка:
Здравствуйте, night beast, Вы писали:

NB>>>не уверен. может исключения?


LP>>Реализуется через longjmp()


NB>не тестировал, но думаю по производительности не дотянет до плюсовых.

NB>опять, же контекст в функции передавать придется.
NB>вобщем, скорее нет чем да

2 Pavel Dvorkin:
так то мне на минусы покласть
но тема интересная, так что если есть чего сказать, то буду раз послушать.
или ты просто это, выражаешь "активную гражданскую позицию"?
Re[4]: Чего принципиально не может C по сравнению c C++.
От: Сергей Мухин Россия  
Дата: 04.02.11 06:14
Оценка:
Здравствуйте, okman, Вы писали:

O>Я намерен отстоять свое мнение.

не поверишь, это можно писать всем во всех сообщениях на RSDN Но обычно это все опускают.

O>В С++ возможен статический вывод типов (читай — ветвление) на основе различий их размеров.

O>Специально приготовил пример.


O>Отмечу — выбор типа статический, то есть, на этапе компиляции.

O>Попробуйте сделать то же самое на С.

плохой проимер, т.к. выражение
if ( 4 == sizeof int ) ...

и в С и в С++ будет вычислено статически.

второе, статически или нет вычисляется что-ниб — это оптимизация, и не имеет никакого отножение к subj.
---
С уважением,
Сергей Мухин
Re[5]: Чего принципиально не может C по сравнению c C++.
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.11 07:17
Оценка:
Здравствуйте, Сергей Мухин, Вы писали:

O>>Отмечу — выбор типа статический, то есть, на этапе компиляции.

O>>Попробуйте сделать то же самое на С.

СМ>плохой проимер, т.к. выражение

СМ>
СМ>if ( 4 == sizeof int ) ...
СМ>

СМ>и в С и в С++ будет вычислено статически.

Выражение будет вычислено статически, однако ветвление на основе размеров типов в C придется писать примерно так:

if (sizeof (void *) == 4)
{
    // x86-specific code
}

else if (sizeof (void *) == 8)
{
    // amd64-specific code
}

else
{
    // throw ?
}


потому что написать #if (sizeof (void *) == n) не позволяют правила языка.
Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).
Re[6]: Чего принципиально не может C по сравнению c C++.
От: jyuyjiyuijyu  
Дата: 04.02.11 07:54
Оценка:
Здравствуйте, okman, Вы писали:

O>Здравствуйте, Сергей Мухин, Вы писали:


O>>>Отмечу — выбор типа статический, то есть, на этапе компиляции.

O>>>Попробуйте сделать то же самое на С.

СМ>>плохой проимер, т.к. выражение

СМ>>
СМ>>if ( 4 == sizeof int ) ...
СМ>>

СМ>>и в С и в С++ будет вычислено статически.

O>Выражение будет вычислено статически, однако ветвление на основе размеров типов в C придется писать примерно так:


O>
O>if (sizeof (void *) == 4)
O>{
O>    // x86-specific code
O>}

O>else if (sizeof (void *) == 8)
O>{
O>    // amd64-specific code
O>}

O>else
O>{
O>    // throw ?
O>}
O>


O>потому что написать #if (sizeof (void *) == n) не позволяют правила языка.

O>Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).
разве компилятор не выкинет условие известное на этапе компиляции ?
Re[2]: Чего принципиально не может C по сравнению c C++.
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 04.02.11 08:05
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Нужно было спросить, по каким критериям выделяется "принципиальная возможность".


Что-то мне подсказывает, что это единственный правильный ответ на данный вопрос. Ведь если разговор идет о выполнимости той или иной задачи, то тут Си скорее даже лидирует, ну а если разговор о "фенечках", то Си явно в пролете и сожно брать простейшие примеры, такие как например классы.
Re[3]: Чего принципиально не может C по сравнению c C++.
От: igna Россия  
Дата: 04.02.11 08:08
Оценка:
Здравствуйте, Sni4ok, Вы писали:

S>на шаблонах нет- ибо в си их нет, но в compile time на макросах- запросто:


Обладает ли язык макросов полнотой по Тьюрингу?
Re[3]: Чего принципиально не может C по сравнению c C++.
От: igna Россия  
Дата: 04.02.11 08:10
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP> ... если разговор идет о выполнимости той или иной задачи, то тут Си скорее даже лидирует ...


Что ты имеешь в виду, новые возможности C99, которых еще нет в C++?
Re[6]: Чего принципиально не может C по сравнению c C++.
От: Сергей Мухин Россия  
Дата: 04.02.11 08:13
Оценка:
Здравствуйте, okman, Вы писали:


O>потому что написать #if (sizeof (void *) == n) не позволяют правила языка.

O>Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).

1. ну и что что менее эффективно? какое это имеет отношение к "Чего принципиально не может C"?
2. Вы абсолютно ничего не понимаете в компиляторах. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"

т.е. по логиге 2, по матчасти 2.
---
С уважением,
Сергей Мухин
Re[4]: Чего принципиально не может C по сравнению c C++.
От: MescalitoPeyot Украина  
Дата: 04.02.11 08:18
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


MP>>Имхо в отсутствии исключений деструкторы и упомянутые ниже умные указатели не более чем синтаксический сахар.

CC>Отнюдь.
CC>Тот же RAII отлично работает и без исключений.

И без деструкторов тоже.
Если мы говорим о принципиальной возможности получить в plain C возможности C++ то никто не мешает вместо деструкторов использовать некий аналог Symbian-овского cleanup stack и Objective-C-шного NSAutoreleasePool.

Пример на псевдо-C-коде (5-минутный концепт, не вполне безопасен и корректен, но как концепт сойдет; для исключений добавить longjmp'ы с инструментарием по типу Symbian-овского):

extern struct CleanupStack * CurrentCleanupFrame;
extern struct CleanupStack * GlobalCleanupFrame;

#define FUNCTION_BEGIN(type)                                                                                    \
    type retValue;                                                                                                            \
    struct CleanupStack * CurrentCleanupFrame = CleanupStack_create()
    
#define FUNCTION_END()                                                                                                                                                \
    function_end:                                                                                                                                                                \
        if (CurrentCleanupFrame != GlobalCleanupFrame) CleanupStack_destroy(CurrentCleanupFrame);    \
        return retValue

#define RETURN(value)        \
    retValue = (value);        \
    goto function_end
    
#define MALLOC(size)    \
    CleanupStack_register(CurrentCleanupFrame, malloc(size))
    
int some_function()
{
    FUNCTION_BEGIN(int);
    
    FUNCTION_END();
}
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[5]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 04.02.11 08:19
Оценка:
Здравствуйте, igna, Вы писали:

NB>>не тестировал, но думаю по производительности не дотянет до плюсовых.


I>Тоже не тестировал, но видел как longjmp выглядит на ассемблере. Было бы странно, если бы он куда-то там не дотянул, он же делает ведь сущую ерунду, стек назад не раскручивает, деструкторов не вызывает, а просто восстанавливает когда-то запомненное состояние стека, предоставляя программисту самому заботиться об освобождении выделенной динамической памяти и других ресурсов.


не-не дэвид блейн.
плюсовые исключения подразумевают вызов деструкторов.
то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов
struct test {
   test() { /*can throw*/ }
   ~test() { /*not throw*/ }
};

try {
   test x,y,z;
} catch (...) {
   //
}


или без исключений (код не рабочий)
#define TRY /*save context*/ if ( sigsetjmp(context, 0) == 0 ) { /*save context*/
#define CATCH } else {
#define END_TRY } /*restore context*/

typedef struct test {} test;

void construct_test ( sigjmp_buf * context, test * ptr ) { /* can throw */ }
void destruct_test ( test * ptr ) { /* not throw */ }

sigjmp_buf context;

TRY {
  test x, y, z;
  TRY {
    construct_test( &context, &x );
    TRY {
      construct_test( &context, &y );
      TRY {
//...
      } CATCH { } END_TRY;
      desctuct_test( &y );
    } CATCH { } END_TRY;
    desctuct_test( &x );
  } CATCH { } END_TRY;

} CATCH { } END_TRY;


поправь если где ошибся.

ну а сравнение табличных исключений с исключениями на ифах я пока искать не буду (оно было не в пользу ифов)
Re[7]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 04.02.11 08:37
Оценка:
Здравствуйте, ArtDenis, Вы писали:

NB>>ну что тут скажешь, "нет преграды патриотам" (с)


AD>Вот-вот. На что только православные сишники не пойдут, лишь бы с++ не использовать


не, на самом деле для кодогенерации самое то, если б только не засада с исключениями
если кто подскажет как сделать табличную реализацию на сях, буду очень благодарен
Re[7]: Чего принципиально не может C по сравнению c C++.
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.11 09:21
Оценка:
Здравствуйте, Сергей Мухин, Вы писали:

СМ>1. ну и что что менее эффективно? какое это имеет отношение к "Чего принципиально не может C"?


Моя точка зрения заключается в том, что в С невозможно вывести тип (структуру) или сделать ветвление на стадии компиляции,
которое бы основывалось на различиях в размерах данных. Что тут непонятного ? Напишите пример, если хотите опровергнуть.

СМ>2. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"


При использовании шаблонов я имею стопроцентную гарантию того, что данного холостого кода не будет.
А в Вашем примере мне приходится полагаться на компилятор и его оптимизацию.
Поверю, если покажете пункт Стандарта, где это гарантируется.
Re[8]: Чего принципиально не может C по сравнению c C++.
От: Сергей Мухин Россия  
Дата: 04.02.11 09:25
Оценка:
Здравствуйте, okman, Вы писали:

O>Здравствуйте, Сергей Мухин, Вы писали:


СМ>>1. ну и что что менее эффективно? какое это имеет отношение к "Чего принципиально не может C"?


O>Моя точка зрения заключается в том, что в С невозможно вывести тип (структуру) или сделать ветвление на стадии компиляции,

O>которое бы основывалось на различиях в размерах данных. Что тут непонятного ? Напишите пример, если хотите опровергнуть.
Это ОПТИМИЗАЦИЯ какое это имеет отношение к "Чего принципиально не может C"?

СМ>>2. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"


O>При использовании шаблонов я имею стопроцентную гарантию того, что данного холостого кода не будет.

O>А в Вашем примере мне приходится полагаться на компилятор и его оптимизацию.
O>Поверю, если покажете пункт Стандарта, где это гарантируется.

какое это имеет отношение к "Чего принципиально не может C"?

Вы пишите, что вот С++ здесь не генерить, а С генерит (да и то на самом деле не генереит), и это ПРИНЦИПИАЛЬНАЯ разница??? бред бред
---
С уважением,
Сергей Мухин
Re[6]: Чего принципиально не может C по сравнению c C++.
От: igna Россия  
Дата: 04.02.11 09:39
Оценка:
Здравствуйте, night beast, Вы писали:

NB>плюсовые исключения подразумевают вызов деструкторов.

NB>то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов

Освобождение ресурсов может быть совсем по другому организовано, не обязательно имитировать C++. Например:

1. Вызываем setjump и инициализируем репозитарий запрошенных ресурсов.
2. Работаем запрашивая ресурсы и сохраняя информацию о них в репозитарии.
3. При возникновении исключительной ситуации выполняем longjmp и освобождаем ресурсы.
Re[7]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 04.02.11 09:43
Оценка:
Здравствуйте, igna, Вы писали:

NB>>плюсовые исключения подразумевают вызов деструкторов.

NB>>то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов

I>Освобождение ресурсов может быть совсем по другому организовано, не обязательно имитировать C++. Например:


I>1. Вызываем setjump и инициализируем репозитарий запрошенных ресурсов.

I>2. Работаем запрашивая ресурсы и сохраняя информацию о них в репозитарии.
I>3. При возникновении исключительной ситуации выполняем longjmp и освобождаем ресурсы.

имхо еще тормознее получится.
Re[2]: Чего принципиально не может C по сравнению c C++.
От: denisko http://sdeniskos.blogspot.com/
Дата: 04.02.11 09:56
Оценка:
Здравствуйте, 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 notions
int 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 quit
void 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);
}
//test
int 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++.
От: denisko http://sdeniskos.blogspot.com/
Дата: 04.02.11 09:58
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Нужно было спросить, по каким критериям выделяется "принципиальная возможность".


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

Индивидуально. В общем случае, очевидно, не так поскольку никто не мешает писать на ++ в C стиле.
<Подпись удалена модератором>
Re[9]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 04.02.11 10:08
Оценка:
Здравствуйте, igna, Вы писали:

NB>>имхо еще тормознее получится.


I>Это у тебя ошибочное имхо, получится по крайней мере не тормознее. А в случаях когда единственным ресурсом является память и освобождение происходит "одним махом", то получится быстрее.


трудно что-то с чем-то сравнивать, не имея этого чего-то перед глазами
ну да ладно.
Re[4]: Чего принципиально не может C по сравнению c C++.
От: Erop Россия  
Дата: 04.02.11 10:18
Оценка:
Здравствуйте, okman, Вы писали:


O>Отмечу — выбор типа статический, то есть, на этапе компиляции.

O>Попробуйте сделать то же самое на С.

Массив указателей на строки, индексируемый размером структуры, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Чего принципиально не может C по сравнению c C++.
От: Erop Россия  
Дата: 04.02.11 10:20
Оценка:
Здравствуйте, okman, Вы писали:

O>Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).


Чушь! Нормальный компиллер С всё заоптимизирует и никакой динамики в коже не останется...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Чего принципиально не может C по сравнению c C++.
От: Erop Россия  
Дата: 04.02.11 10:23
Оценка:
Здравствуйте, night beast, Вы писали:


NB>то есть чтобы реализовать это на си нужно соответственно делать освобождение ресурсов


Ну, так в С иначе просто принято владеть ресурсами, чем в С++. Да и только.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Чего принципиально не может C по сравнению c C++.
От: Erop Россия  
Дата: 04.02.11 10:28
Оценка:
Здравствуйте, okman, Вы писали:

O>При использовании шаблонов я имею стопроцентную гарантию того, что данного холостого кода не будет.

O>А в Вашем примере мне приходится полагаться на компилятор и его оптимизацию.
Зато тебе приходится рассчитывать на то, что всё за'inline'тся...
Кстати, и безусловный переход оптимизировать легче, и потери, в случае файла оптимизатора больше и код в С понятнее получается...

Ты не в туда копаешь. В С не получится написать удобный массив. Но получится неудобный. Ну и т. д. и т. п...

На самом деле можно предложить такую головоломную конструкцию, которая хитро очень с системой типов взаимодействует. Но это егаэкзотика. И я уверен, что та задача, для которой такая мегаэкзотика нужна, не решается на С как-то иначе. Наверняка проще, кстати
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Чего принципиально не может C по сравнению c C++.
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.11 10:52
Оценка:
Здравствуйте, Сергей Мухин,
Вы писали:

СМ>Это ОПТИМИЗАЦИЯ какое это имеет отношение к "Чего принципиально не может C"?


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

Например:

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


Для любого типа, заданного шаблонным параметром T, будет выведен соответствующий тип type_array с массивом char
соответствующей размерности внутри. Для бесконечно большого количества входных типов T всегда будет
оставаться одна декларация этой шаблонной структуры, потому что выводимые типы создаются компилятором.

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

СМ>>>2. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"

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

Если бред — не читайте. Никто не заставляет.
Re[8]: Чего принципиально не может C по сравнению c C++.
От: Erop Россия  
Дата: 04.02.11 11:05
Оценка:
Здравствуйте, night beast, Вы писали:

NB>ошибки там тоже принято по другому обрабатывать...



Ну лонгджамп -- это, тем не менее, С'шная функция, а не плюсовая
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: Чего принципиально не может C по сравнению c C++.
От: monah_tuk Пират http://htrd.su
Дата: 04.02.11 11:06
Оценка:
Здравствуйте, night beast, Вы писали:
NB>не уверен. может исключения?

делали на основе setjmp/longjmp и макросов препроцессорных. Возможно есть подводные камни.
Re[9]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 04.02.11 11:09
Оценка:
Здравствуйте, Erop, Вы писали:

NB>>ошибки там тоже принято по другому обрабатывать...


E>Ну лонгджамп -- это, тем не менее, С'шная функция, а не плюсовая


ага. в плюсах она вообще вредная
Re[10]: Чего принципиально не может C по сравнению c C++.
От: uzhas Ниоткуда  
Дата: 04.02.11 12:13
Оценка:
Здравствуйте, okman, Вы писали:


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


O>Например:


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


давайте не будем вводить в заблуждение
я бы назвал это статическим полиморфизмом, а вывод типов — это немного другое
Re[6]: Чего принципиально не может C по сравнению c C++.
От: MescalitoPeyot Украина  
Дата: 04.02.11 19:36
Оценка:
Здравствуйте, 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++.
От: MasterZiv СССР  
Дата: 04.02.11 20:35
Оценка:
On 03.02.2011 17:03, night beast wrote:

> W>Посмотри исходники <http://www.postgresql.org/ftp/source/&gt; postgresql, например.

> глянул одним глазом. как оно в многопоточном окружении работает?

По идее его там быть не должно. Я правда не уверен на счёт постгреса, но
в принципе в нормальной СУБД многопоточности быть не должно.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Чего принципиально не может C по сравнению c C++.
От: CreatorCray  
Дата: 04.02.11 20:47
Оценка:
Здравствуйте, MescalitoPeyot, Вы писали:

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


Ну вот и получается. Что написать то можно всё. Но вот какой ценой это напишется?
Даже на ассемблере можно написать вообще всё, один фиг все языки в итоге приходят к тому, что машинный код исполняется на проце, пусть даже язык интерпретируемый.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: Чего принципиально не может C по сравнению c C++.
От: MescalitoPeyot Украина  
Дата: 04.02.11 23:25
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Ну вот и получается. Что написать то можно всё. Но вот какой ценой это напишется?

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

Ну речь-то в исходном посте шла о принципиальной возможности. А принципиально в C можно сделать — и делают все вышеперечисленное (разве что cleanup stack не видел, но я довольно молодой и вообще плюсовик).
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[10]: Чего принципиально не может C по сравнению c C++.
От: SleepyDrago Украина  
Дата: 05.02.11 10:48
Оценка:
Здравствуйте, 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 просто по причине того что проверки типов там не нужны и с точки зрения поведения это все массивы символов.
Re[11]: Чего принципиально не может C по сравнению c C++.
От: okman Беларусь https://searchinform.ru/
Дата: 06.02.11 15:30
Оценка:
Здравствуйте, SleepyDrago,
Вы писали:

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


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


Моя версия правильного ответа на вопрос "чего принципиально не может C по сравнению c C++" была подробно представлена выше.
Не считаю нужным опять ее разжевывать.
Re[7]: Чего принципиально не может C по сравнению c C++.
От: night beast СССР  
Дата: 07.02.11 04:54
Оценка:
Здравствуйте, MasterZiv, Вы писали:

>> W>Посмотри исходники <http://www.postgresql.org/ftp/source/&gt; postgresql, например.

>> глянул одним глазом. как оно в многопоточном окружении работает?

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


почему?

MZ>Я правда не уверен на счёт постгреса, но

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

в постгресе они указатель на текущий sigjmp_buf в глобальной переменной хранят
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.