Re[3]: Чего принципиально не может C по сравнению c C++. - C/C++

Код:

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'

Т.е. классы он принципиально не может.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>

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

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

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

Мимо.

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

2 Pavel Dvorkin:
так то мне на минусы покласть
но тема интересная, так что если есть чего сказать, то буду раз послушать.
или ты просто это, выражаешь "активную гражданскую позицию"?

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

O>Я намерен отстоять свое мнение.
не поверишь, это можно писать всем во всех сообщениях на RSDN

Но обычно это все опускают.

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

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

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

if ( 4 == sizeof int ) ...

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

второе, статически или нет вычисляется что-ниб — это оптимизация, и не имеет никакого отножение к subj.

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

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).

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

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

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

Здравствуйте, 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).
разве компилятор не выкинет условие известное на этапе компиляции ?

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

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

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

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

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

Обладает ли язык макросов полнотой по Тьюрингу?

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

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

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

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

O>потому что написать #if (sizeof (void *) == n) не позволяют правила языка.
O>Получается наличие холостого кода плюс накладные расходы (потому что выбор ветки case идет в рантайме, а не в compile-time).

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

т.е. по логиге 2, по матчасти 2.

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

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

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

ну а сравнение табличных исключений с исключениями на ифах я пока искать не буду (оно было не в пользу ифов)

В общем, к чему это я? К тому что деструкторы это вовсе не принципиально недостижимая в C фича C++. Если нет настоящих исключений, то деструкторы не более чем облегчают жизнь имхо.

... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>

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

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

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

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

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

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

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

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

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

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

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

не, на самом деле для кодогенерации самое то, если б только не засада с исключениями

если кто подскажет как сделать табличную реализацию на сях, буду очень благодарен

	От:	TimurSPB
	Дата:	03.02.11 19:37
	Оценка:	-1

	От:	MescalitoPeyot
	Дата:	03.02.11 20:01
	Оценка:

От:	Oleg Bekhter	www.bekhter.net
Дата:	03.02.11 21:36
Оценка:

От:	okman	https://searchinform.ru/
Дата:	03.02.11 23:37
Оценка:

	От:	CreatorCray
	Дата:	04.02.11 00:45
	Оценка:

	От:	Сергей Мухин
	Дата:	04.02.11 06:14
	Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	04.02.11 08:05
Оценка: