C != C++

C99 allows literals having types other than primitive types (e.g., user-defined structure or array types) to be specified in constant expressions; these are called compound literals. For example:

struct info
{
char name[8+1];
int type;
};

extern void add(struct info s);
extern void move(float coord[2]);

void predef(void)
{
add((struct info){ "e", 0 }); // A struct literal
move((float[2]){ +0.5, -2.7 }); // An array literal
}

C++ does not support this feature.

C99 introduces the feature of designated initializers, which allows specific members of structures, unions, or arrays to be initialized explicitly by name or subscript. For example:

struct info
{
char name[8+1];
int sz;
int typ;
};

struct info arr[] =
{
[0] = { .sz = 20, .name = "abc" },
[9] = { .sz = -1, .name = "" }
};

Unspecified members are default-initialized.

C++ does not support this feature.

мнда, давайте теперь создадим ещё несколько топиков с прописными истинами a la "бога нет", "вода мокрая", "люди умирают", etc.

http://www.linux.org.ru/view-message.jsp?msgid=2313264&lastmod=1196623219122

C++ 98 года не поддерживает фичи C 99 года. Отлично!

Вот только в gcc всё это поддерживается и работает без проблем. Странно да? И в C++ следующего стандарта всё это будет поддерживаться.

Так что С++ это С плюс объекты плюс шаблоны + стандартная библиотека.

Иди в толкс из моего Development!

C++ = C + костыли + несовместимость + трудночитаемость

> С++ - не улучшеный Си.

Ухудшенный.

>С++ - не улучшеный Си.

Также, как C99 != Си ;)

>трудночитаемость

Довели бы до уровня Перла - хотябы понтово было бы. А так - дерьмо дерьмом, как всегда.

size_t sum(int sz) { float arr[sz]; // VLA, dynamically allocated

while (sz-- > 0) arr[sz] = sz; return sizeof(arr); // Evaluated at runtime }

C++ does not support VLAs.

не пишите бред

в С++ все это достигается средствами самого языка

в данном случае

std::vector<float> arr[sz];

while (sz-- > 0)

arr[sz] = sz;

return arr.size(); // Evaluated at runtime

>C99 allows literals having types other than primitive types (e.g., user-defined structure or array types) to be specified in constant expressions; these are called compound literals. For example:

>struct info
{
char name[8+1];
int type;
};

>extern void add(struct info s);
extern void move(float coord[2]);

>void predef(void)
{
add((struct info){ "e", 0 }); // A struct literal
move((float[2]){ +0.5, -2.7 }); // An array literal
}

>C++ does not support this feature.




struct info
{
typedef char name_t [8+1];
typedef int type_t;
info(name_t _name, type_t _type)
: type(_type)
{
memcpy(name, _name, sizeof(name_t));
}
private:
char name[8+1];
int type;
};

struct vec2
{
vec2()
: x(0), y(0)
{}
vec2(float x,float y)
: x(x), y(y)
{}
vec2(const float *v)
: x(v[0]), y(v[1])
{}
vec2(const vec2 &v)
: x(v.x), y(v.y)
{}

operator float*()
{
return(float*)&x;
}
operator const float*() const
{
return(float*)&x;
}

union
{
struct
{
float x,y;
};
float v[2];
};
};


void add(info const& refInfo)
{
}

void move(vec2 const& refVec2)
{
}


add(info("e", 0));
move(vec2(0.5f, -2.7f));

http://boost.org/libs/assign/doc/index.html

Это все костыли. Как всегда.

>Это все костыли. Как всегда.
Красноглазый бред!

С != ++С

> С != ++С

++C == C++ // ? =)

>> С++ - не улучшеный Си.

> Ухудшенный.

Ну так и сказано: (not (enhanced C)) :-D

это не костыли, а показывает насколько язык гибок

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

вот скажите что это еще костыль

это настоящий инструмент, реализованный средствами языка

http://boost.org/libs/spirit/index.html

>вот скажите что это еще костыль

Это мегакривой и убогий недокостыль. Посмотри, как аналогичные инструменты реализуются в Lisp, и сдохни.

cedet/semantic круче. А standalone yacc ещё круче.

> Это мегакривой и убогий недокостыль. Посмотри, как аналогичные инструменты реализуются в Lisp, и сдохни.

Что-то их плюсатый молоток для забивания гвоздей больше на башенный кран похож.

+1

Для С/С++ Lex+Yacc рулят до сих пор. Шаблонные монстры из буста -- удел краноглазых фанатегов.

> Для С/С++ Lex+Yacc рулят до сих пор.

Vala, кстати, так сделана.

>>вот скажите что это еще костыль

>Это мегакривой и убогий недокостыль. Посмотри, как аналогичные инструменты реализуются в Lisp, и сдохни.

аргументируй пожалуйста или это получается что ты ничего не знаешь

где и в каких местах он кривой и чем он убогий?

про то как делается на lisp я в курсе, но от вас уж слишком пахнет незнаниями и не адекватом, лучше бы молчали и не кричали что все криво кроме lisp, видимо вы его не настолько хорошо знаете и проблемы того же lisp'a

>где и в каких местах он кривой и чем он убогий?

Исходники boost::spirit > 1.5МБ кривого, трудночитаемого шаблонного
говнокода. Для меня это достаточной повод считать эту поделку
недокостылём.

Для справки:

Исходники Berkley Yacc ~ 130КБ.
Исходники DSL парсера для MzScheme ~ 90КБ.
Исходники Haskell Parsec ~ 70КБ.
Всем этим, а также boost::spirit, я пользовался.

>лучше бы молчали и не кричали что все криво кроме lisp

Простите, Вы дурак? Где я такое сказал?

>Простите, Вы дурак? Где я такое сказал? >Посмотри, как аналогичные инструменты реализуются в Lisp, и сдохни.

>Исходники boost::spirit > 1.5МБ кривого, трудночитаемого шаблонного говнокода. Для меня это достаточной повод считать эту поделку недокостылём.

ваше мнение меня не интересует, то что для вас он трудночитаем это ваши проблемы

Гм, давайте будем объективны. 1) Так или иначе, любой язык - это всего лишь инструмент для решения задач определенного класса. Язык может решать класс задач хорошо, а может не очень, и это проблема не языка, а программиста использующего язык не по назначению. 2) Возникают ситуации, когда проект состоит из различных подзадач, для решения каждой из которой не подходит один и тот же язык, т.к. разные требования. Какие существуют решения? а) Использовать разные языки/инструменты и прокидывать мосты между модулями б) Использовать язык, который лучше всего ложится в комплексе

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

Естественно, что такой язык будет иметь слабые места.

То, что вы, уважаемые посетители ЛОРа, называете "костылями" - тот же boost::spirit, и есть примеры задач, которые В ПРИНИЦИПЕ решаются, пусть и не очень красиво на С++. Есть ситуации, когда нам на все хватает С++, бинарник генерируется эффективный, код - красивый и компактный, легко поддерживается и (вот незадача!) нету синтаксического анализатора. Мы можем прикрутить bison,lexx,yacc - бесспорно! Но не может ли так быть, что мы за****ся потом с интеграцией всего этого хозяйства в С++ код? Вполне может быть, проще заюзать boost::spirit. И так далее.. Направление мысли вы поняли, кто не понял - прочтите еще раз или подучите матчасть и более критично оцените свой опыт разработки.

Далее. С++ - отличный, мультипарадигменный, эффективный язык. У него есть слабые места - безусловно! И я их не отрицаю. Однако - откуда они все проистекают? 1) Препроцессор (наследство Си) 2) Модель разделения на хидеры и цпп файлы (наследство Си) 3) Уебищная грамматика (наследство Си) 4) Невозможность описания замыканий и анонимных вызовов (наследство Си)

Выкиньте наследство Си - и получите отличный язык, который, к слову, называется D.

А C++, как он есть - сложный, с больным наследством, и так далее - пока вне конкуренции при реализации большим проектов с жесткими требованиями на время выполнения программы/потреблением ресурсов.

>мнда, давайте теперь создадим ещё несколько топиков с прописными истинами a la "бога нет"

Уффф.. ну как вы уже надоели. Хочешь поговорить об этом?

>C++ = C + костыли + несовместимость + трудночитаемость

+ трудноосиливаемость ;)

>кривого, трудночитаемого шаблонного говнокода. Для меня ...

Для _тебя_ это слишком сложно, малыш :)

А чего вы ждали от _универсального_ языка? Плюс неодназначности и сложности С++, как я уже написал выше - наследство Си)

да во всем виноват С =)

>да во всем виноват С =) acefsm (*) (03.12.2007 16:36:52)

Не красноглазь) Это был необходимый этап для миграции, сейчас этот аргумент - совместимость, изжил себя.

все проблемы всех продуктов это проблема обратно совместимости

это касается как языков так и ОС

вместо того чтобы делать что нить более новое и лучшее все гонятся за обратной совместимостью

> 1) Препроцессор (наследство Си)

ну им как раз никто пользоваться не заставляет. не нравится - не пользуйтесь.

> 2) Модель разделения на хидеры и цпп файлы (наследство Си)

а это то чем не угодило? чисто техническая фишка. к языку как к таковому отношения не имеет.

> 3) Уебищная грамматика (наследство Си)

тут можно было бы и расширить мысль..

> 4) Невозможность описания замыканий и анонимных вызовов (наследство Си)

ммм.. а оно надо?

// wbr

> ну им как раз никто пользоваться не заставляет. не нравится - не пользуйтесь.

А как вы будете писать на плюсах мультиплатформенный код?

> а это то чем не угодило? чисто техническая фишка. к языку как к таковому отношения не имеет.

А как вы без препроцессора будете бороться с множественным включением хидеров? Без #if(n)def-то?

> тут можно было бы и расширить мысль..

Синтаксис портабельного, чисто императивного ассемблера, очень сильно мешает тому, во что сейчас плюсы пытаются превратить.

> ммм.. а оно надо?

Нет, Скрипач не нужен. Темплейты-недомакросы тоже не нужны.

> 1) Препроцессор (наследство Си) ну им как раз никто пользоваться не заставляет. не нравится - не пользуйтесь.

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

> 2) Модель разделения на хидеры и цпп файлы (наследство Си) а это то чем не угодило? чисто техническая фишка. к языку как к таковому отношения не имеет.

Чисто техническая, но вот проблема с ADL, поиском Кенига, экспортом шаблонов, и ошибками линковки - это большой пласт проблем С++, который могло и не быть, если применить подход жава/сишарп

> 3) Уебищная грамматика (наследство Си) тут можно было бы и расширить мысль..

http://community.livejournal.com/ru_programming/864583.html?style=mine&th... - тут подробно.

> 4) Невозможность описания замыканий и анонимных вызовов (наследство Си) ммм.. а оно надо?

Как показывает практика - отсутвие closure и functional object в языке ведет к велосипедостроению и раздуванию кода. Могу примеры, если интересно

> А как вы будете писать на плюсах мультиплатформенный код?

hm.. вот так вот брать, руками, и писать :-? не вижу особой проблемы.

предполагается, что вся платформо-зависимая часть уже скрыта от нас низлежащим уровнем, написанном скорее всего на том-же C. если уж сравнивать C++ с кем-либо ещё и ставить их в равные условия.

> А как вы без препроцессора будете бороться с множественным включением хидеров? Без #if(n)def-то?

препроцессор? акститесь, это мантра такая, какой препроцессор. ну да, нужно в каждом .h внести теги вида #ifndef <tag> #define <tag> <body> #endif. и все. кто такой препроцессор?

ps: есть какие-то комментарии по поводу необходимости использования препроцессора по существу помимо тривиального включения заголовков, который действительно можно свести до уровня автомата?

> Синтаксис портабельного, чисто императивного ассемблера, очень сильно мешает тому, во что сейчас плюсы пытаются превратить.

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

> Нет, Скрипач не нужен. Темплейты-недомакросы тоже не нужны.

а что нужно?

// wbr

> предполагается, что вся платформо-зависимая часть уже скрыта от нас низлежащим уровнем, написанном скорее всего на том-же C. если уж сравнивать C++ с кем-либо ещё и ставить их в равные условия.

Да программы вообще низкооплачиваемые негры в Гарлеме пишут, настоящие мужики только диаграммы Ганта рисуют и бабло в кармане считают.

> препроцессор? акститесь, это мантра такая, какой препроцессор. ну да, нужно в каждом .h внести теги вида #ifndef <tag> #define <tag> <body> #endif. и все. кто такой препроцессор?

Это такая фигня, от которой плюсатые программисты всё время пытаются абстрагироваться, но как в любой файл из восхваляемых стл/буст/локи ни залезешь, так всё в его директивах пестрит.

> ps: есть какие-то комментарии по поводу необходимости использования препроцессора по существу помимо тривиального включения заголовков, который действительно можно свести до уровня автомата?

А если из плюсов убрать всё, что там сейчас есть, и добавить s-expressions, то получится неплохой диалект лиспа.

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

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

> а что нужно?

Мне бы пива, пожалуйста.

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

Э-э-э... Вы ниасилили C++. И вы никогда в глаза не видели production cod'а ни на Си, ни на C++. Иначе вы бы не несли такого феерического бреда.

А реальность такова: большинство кода на Си пишется в объектно-ориентированном стиле. Что это значит?

Инкапсуляция: обычные struct'ы, насквозь открытые — они «скрывают» состояние классов. Функции-члены моделируются обычными функциями, получающими в качестве первого параметра указатель на такую структуру.

Наследование: дублирование в начале «класса-потомка» полей «класса-предка», возможно с помощью макросов. Небезопасные Си-стайл-касты на каждом шагу.

Полиморфизм: либо ручная эмуляция vtable, либо хранение и ручная инициализация указателей на «функции-члены».

Поэтому процитированная ваша фраза — наглая ложь. Всё, что поместится в два экрана кода на Си, займёт не больше места и на C++. Наоборот — нет, и поддерживать объектно-ориентированный код на Си *гораздо сложнее*. На вопросы, почему архитектура какой-нибудь сишной библиотеки (e. g., IJG jpeg) выглядит так уёбищно принято отвечать в духе «Of course this would all be a lot easier if we were using C++, but we are not yet prepared to assume that everyone has a C++ compiler.»

-- Qbit

> Поэтому процитированная ваша фраза — наглая ложь.

C - это уровень выше? Или с категориями сравнения не в порядке?

+1

>Инкапсуляция: обычные struct'ы, насквозь открытые — они «скрывают» состояние классов

Садитесь, двойка. Вы ниасилили C. И вы никогда в глаза не видели production cod'а ни на С. Иначе вы бы не несли такого феерического бреда.

> Поэтому процитированная ваша фраза — наглая ложь. C - это уровень выше? Или с категориями сравнения не в порядке?

У вас проблемы с логикой или читаебельным аппаратом - глазами там или мозгом?

Есть ассемблер. Уровень выше - Си. Еще выше - С++.

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

Что непонятно с уровнями?

ЗЫ: Если какие-то слова непонятны - рекомендую почитать википедию, т.к. это азбука.

>Инкапсуляция: обычные struct'ы, насквозь открытые — они «скрывают» состояние классов Садитесь, двойка. Вы ниасилили C. И вы никогда в глаза не видели production cod'а ни на С. Иначе вы бы не несли такого феерического бреда.

Дорогой анонимус, я видел production code на Си, и с мнением Qbit соглашусь, а под каждым его словом - подпишусь.

В студию примеры (в виде ссылок на продукты) являющиеся, на Ваш взгляд, образцовыми примерами production Си кода.

man ADT, затем поботай на тему грамотной реализации ADT на С. Какая, нахрен, "насквозь открытая структура".

>man ADT, затем поботай на тему грамотной реализации ADT на С. Какая, нахрен, "насквозь открытая структура".

http://www.google.ru/search?q=ADT&ie=utf-8&oe=utf-8&aq=t&rls=...

Гуглеж ничего вразумительного не дал.

Может быть, продемонстрируете или дадите ссылок?

Ну так у меня 4-я ссылка http://en.wikipedia.org/wiki/Abstract_data_type

Тамошняя реализация на С с использованием целочисленного дескриптора не самый удачный и не единственный вариант. Часто в качестве непрозрачного дескриптора (opaque handle) выступает указатель на структуру (содержимое которой недоступно, т.е. видно только объявление а-ля struct foo). Это является механизмом инкапсуляции, по мощности совершенно идентичным C++ pimpl idiom.

> У вас проблемы с логикой или читаебельным аппаратом - глазами там или мозгом?

Дорогие мои Qbit и zabivator! Возьмите, наконец, книжку Розенталя и осильте её, если вам не понятно, что я написал. Для тех, кто не знает, кто такой Розенталь, я, так уж и быть, проведу разбор предложения: "Это когда вместо двух экранов кода на языке уровнем выше нужно две недели трахаться с проектированием и отладкой колоды классов".

Итак, в предложении сравниваются две сущности: то, в контексте чего проходит полемика, т.е. язык C++, и нечто, уровнем выше. Что же мы имеем? А имеем мы два экрана кода (стандартно по 25 строк) на том самом языке уровнем выше (как вы уже любезно напомнили, в иерархии языков C стоит выше ассемблера и ниже C++), т.е. позволяющего манипулировать более мощными абстракциями с меньшими затратами на их описание. С другой стороны, для достижения той же функциональности нам нужно потратить очень много времени для проектирования большого количества классов (т.н. "колоды") на предмете спора (языке С++), т.к. это первый шаг, к которому принуждает практика программирования на C++. Автор также обозначил, что отладка и далнейшая поддержка этих классов является более трудоёмким процессом, чем те самые два экрана код на более высокоуровневом языке.