Re: 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.

Re: C != C++

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.

Re: C != C++

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

Re: C != C++

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

Re: C != C++

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

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

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

Re: C != C++

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

Re: C != C++

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

Re: C != C++

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

Ухудшенный.

Re: C != C++

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

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

Re: C != C++

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

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

Re: C != C++

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

Re: 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.




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

Re: C != C++

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

Re: C != C++

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

Re: C != C++

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

Re: C != C++

С != ++С

Re: C != C++

> С != ++С

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

Re: C != C++

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

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

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

Re: C != C++

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

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

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

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

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

Re: C != C++

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

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

Re: C != C++

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

Re: C != C++

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

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

Re: C != C++

+1

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

Re: C != C++

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

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

Re: C != C++

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

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

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

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

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

Re: C != C++

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

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

Для справки:

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

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

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

Re: C != C++

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

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

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

Re: C != C++

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

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

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

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

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

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

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

Re: C != C++

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

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

Re: C != C++

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

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

Re: C != C++

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

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

Re: C != C++

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

Re: C != C++

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

Re: C != C++

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

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

Re: C != C++

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

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

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

Re: C != C++

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

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

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

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

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

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

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

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

// wbr

Re: C != C++

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

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

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

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

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

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

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

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

Re: C != C++

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

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

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

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

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

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

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

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

Re: C != C++

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

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

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

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

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

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

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

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

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

а что нужно?

// wbr

Re: C != C++

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

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

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

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

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

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

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

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

> а что нужно?

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

Re: C != C++

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

Э-э-э... Вы ниасилили 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

Re: C != C++

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

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

Re: C != C++

+1

Re: C != C++

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

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

Re: C != C++

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

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

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

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

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

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

Re: C != C++

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

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

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

Re: C != C++

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

Re: C != C++

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

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

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

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

Re: C != C++

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

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

Re: C != C++

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

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

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