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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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;
}

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

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

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

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

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

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

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

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

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

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

трудно что-то с чем-то сравнивать, не имея этого чего-то перед глазами
ну да ладно.

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


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

Массив указателей на строки, индексируемый размером структуры, например...

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

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

Чушь! Нормальный компиллер С всё заоптимизирует и никакой динамики в коже не останется...

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


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

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

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

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

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

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

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

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

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

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

СМ>Это ОПТИМИЗАЦИЯ какое это имеет отношение к "Чего принципиально не может 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. Все эти выражения вычислятся статически и не приведут к созданию "холостого кода"
СМ>Вы пишите, что вот С++ здесь не генерить, а С генерит (да и то на самом деле не генереит), и это ПРИНЦИПИАЛЬНАЯ разница??? бред бред

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

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

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

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

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

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

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


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

Здравствуйте, night beast, Вы писали:
NB>не уверен. может исключения?

делали на основе setjmp/longjmp и макросов препроцессорных. Возможно есть подводные камни.

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

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

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

ага. в плюсах она вообще вредная

Здравствуйте, 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 объекты?
Можно конечно попробовать сэмулировать но код будет уже децл макаронный.

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


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

O>Например:

O>

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

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