GCC переходит на С++ компиляцию самого себя с целью улучшения качества кода

и, мож, с плюшками типа auto

Не очень нужно, пока в си нет всяких std::map<const char*, unsigned long>::const_iterator.

«Не очень нужно» - это значит «можно обойтись»? Ну да, можно. Но с auto было бы лучше.

и strongly-typed enums.

На них даже флаги нормально не сделаешь.

Не делай на них флаги.

Я наоборот мечтаю о си с классами (без наследования) и перегрузкой операторов, и лучше без совместимости с си.

Он у тебя уже есть - это Си++. Что, фреймворки и легаси диктуют стиль? Так и на твоем «несовместимом Си» можно будет писать только новые программы.

Что то я в драконе примеров на Java не вижу. Может плохо искал, djvu все-таки

А я просто развиваю твою идея о ненужности проверки типов указателей.

Не приписывай мне свое непонимание.

Что то я в драконе примеров на Java не вижу.

Вроде бы в последнем издании есть.

Так вроде же новость была год назад или полтора. Мол gcc переходит на Си++ же

Самая важная характеристика компилятора - эффективность генерируемого кода, соответствие стандартам, расширяемость и сопровождабельность, и уже только в самом конце идет скорость компиляции.

1. Соответствие стандартам

2. эффективность генерируемого кода

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

Вроде бы в последнем издании есть.

Последнее издание - не кслассика :-)

Он в фундаментальных алгоритмах Седжвика как минимум 3 издания с примерами на С. С++, Java.

При этом суть алгоритмов не меняется.

Посему считаю, что суть удобства Java для компилеров не раскрыта.

Вендопроблемы.

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

Так им же всё равно приходится явно указывать этот throw(), не?

Нет. Зачем?

Читал где-то, что иначе будут накладные расходы на обработку несуществующих исключений. Ну и в libc почти все функции так помечены.

здоровая конкуренция всегда выгодна конечным пользователям.

Но не в мире Линупс. :( КАЖДЫЙ форк, «альфа», «вобрал лучшие идеи» и т.п. - это удар по и так немногочисленному сообществу тех, _кто_действительно_пишет_ что-то под Линукс. Каждая альтернатива - это выбор «за» или «против» и в конечном итоге распыление сил. Не конкурировать надо, а жёстко отсекать альтернативы, если их можно заменить улучшением существующих приложений.

Вроде бы в последнем издании есть.

Последнее издание - не кслассика :-)

Почему? Алгоритмы те же.

Посему считаю, что суть удобства Java для компилеров не раскрыта.

А кто-то говорил, что она удобна? Для компиляторов удобны языки семейства ML, всё остальное - просто разные степени неудобства :)

Эх, svu, жаль ты не набросил в новость отсюда: http://gcc.gnu.org/wiki/cxx-conversion

Выдержки из того, что уже мерджнули:

• Велосипед на макросах VEC успешно заменен на std::vector
• Велосипед хеш-таблицы переведен на шаблонную С++ реализацию (О ужас! С++-фобы в шоке.)
• Ряд макросоов переписан на inline-функции. Теперь-то их можно отлаживать.
• Тип double_int переписан как класс с переопределенными операторами (+,-,++ и т.д.). Теперь его использование выглядит по человечески.

В планах:

• Виртальные функции
• getters and setters
• smart pointers, чтобы избавиться от сборщика мусора gcc и таким образом уменьшить потребление памяти компилятором.
• И да - побольше классов!

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

А что «всё»? В GCC инициализация с именованными полями работает, в Intel - тоже, ибо он компилирует ядро.

Ну а MSVC - вендопроблемы, ясное дело.

Нету try/catch - нету и расходов.

Ты знаешь так много назначений для «обощеныных функций» кроме write/read и их аналогов типа ioctl/send/recv???

qsort()/alphasort()/versionsort()

bsearch()/lsearch()

tsearch()/tfind()/tdelete()/twalk()/tdestroy()

операции с памятью и т.д.

qsort()

который в gcc собираются заменить на типобезопасный std::sort(). Причем последний по их словам еще и быстрее.

А кто-то говорил, что она удобна?

Это не в твой огород.

Беззнаковый писал :

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

Во, блин, срач развели на кучу страниц :))) А мне как-то похрену :))) Мне главное - чтоб всё работало :)

А что «всё»? В GCC инициализация с именованными полями работает, в Intel - тоже, ибо он компилирует ядро.

я про поддержку C99 в целом

Ну а MSVC - вендопроблемы, ясное дело.

несомненно, так им и надо, но код на С в большинстве случаев пишут таки под C89, при том, что сейчас стандарт уже C11, и проблема тут именно в зоопарке компиляторов, таким образом «вендопроблемы» хоть и косвенно, хоть и частично, но таки не только «вендо-»

который в gcc собираются заменить на типобезопасный std::sort(). Причем последний по их словам еще и быстрее.

Для нового gcc на С++ это ок, но есть же и на С проекты.

.to

А что «всё»? В GCC инициализация с именованными полями работает, в Intel - тоже, ибо он компилирует ядро.

я про поддержку C99 в целом

Так какие фишки C99 в разных компиляторах не работают?

код на С в большинстве случаев пишут таки под C89, при том, что сейчас стандарт уже C11, и проблема тут именно в зоопарке компиляторов, таким образом «вендопроблемы»

По слухам, из всех компиляторов, самые большие проблемы с C99 - у MSVC, так что это именно «вендопроблемы» (== «проблемы, имеющие корни в венде»).

Так какие фишки C99 в разных компиляторах не работают?

вот, например, для gcc, который ты привел в пример:

http://gcc.gnu.org/c99status.html

По слухам, из всех компиляторов, самые большие проблемы с C99 - у MSVC,

они вообще забили на C99

== «проблемы, имеющие корни в венде»

не только в ней, но в целом и общем - да

В пень этот gcc и его binutils сателлит. Надеюсь, у кого-нибудь дойдут руки до допилки tinycc.

http://gcc.gnu.org/c99status.html

Это я знаю. Там нет никаких собственно языковых конструкций.

Беззнаковый писал :

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

Я просто константирую факт - в указанных книгах (а это самые известные) выбрали яву. Я тоже не знаю, чем она удобна - наверно, дело только в её популярности.

Я отвечал товарищу, который отверг яву для написания компилятора си.

я про поддержку C99 в целом

Так какие фишки C99 в разных компиляторах не работают?

http://gcc.gnu.org/c99status.html

Там нет никаких собственно языковых конструкций.

таки нам трудно найти общий язык

Но с auto было бы лучше.

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

Не делай на них флаги.

А в си можно было ;) Пусть и без проверки типов, но хотя бы в качестве документации.

Что, фреймворки и легаси диктуют стиль? Так и на твоем «несовместимом Си» можно будет писать только новые программы.

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

и strongly-typed enums.

На них даже флаги нормально не сделаешь.

Не делай на них флаги.

А в си можно было ;)

enum foo { FOO1 = 1, FOO2 = 1 << 1 };

void f(enum foo);

void bar(void)
{
  f(FOO1 | FOO2);
}

ты о таком? Руки за это отрывать.

Я отвечал товарищу, который отверг яву для написания компилятора си.

Который в свою очередь был против идиотской идеи переписывания gcc на Java :)

И вообще - передачу параметров через void* оценят на этом ресурсе.

В Си без этого никуда. Начиная с pthread_create.

Блин, сделали бы уже какой-то С+, который бы являл собой С со строгой типизацией и, мож, с плюшками типа auto и strongly-typed enums.

Free Pascal? И скорость компиляции высокая, inline assembler с пространством имён остального кода.

Я просто константирую факт - в указанных книгах (а это самые известные) выбрали яву.

Как обладатель и читатель скажу, что это явно не плюс книги. (

Руки за это отрывать.

Ты имеешь в виду, что FOO1|FOO2 не входит в enum foo? Но мы же знаем, что всё это инты.

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

который бы являл собой С со строгой типизацией

писать перед всеми malloc() приведение типов? А нафига?

Ты имеешь в виду, что FOO1|FOO2 не входит в enum foo? Но мы же знаем, что всё это инты.

Если тебе нужен int, напиши int.

А ты что предлагаешь, явные инты? Но это будет то же самое

Это не будет никого путать.

То, что my_callback надо сразу объявлять с правильным аргументом

Ну тогда будет приведение типа при set_callback. Что, кстати, ещё более вредно!

Как раз так вполне даже правильно. Я дал пример кода

В С++ необходимость в void* возникает только в двух случаях:
1) использование кода на С
2) недостаточная компетентность прогера (местоположение рук, головы)

давай не будем путать вырожденные примеры синтаксически корректного кода с нормальным, production-quality кодом, ок?

Как раз так вполне даже правильно.

Ага, правильно, особенно если потом set_callback начнёт ожидать в аргументах int callback(void *) вместо void callback(void *)

Это мина в поддержке кода.

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

А вообще нефиг API менять, особенно так опасно;)

На них даже флаги нормально не сделаешь.

А ты не делай. Я молчу про то, что в С++ strict-typed enums идут в дополнение к обычным enum.

Convert qsort

Convert calls to qsort into calls to std::sort, which typically leads to code which is larger but runs faster. 

Взято отсюда

Ждем раздутия кода и увеличения(???) производительности.

Баян. GCC переходит на С++ компиляцию самого себя с целью улучшения качества кода (комментарий)

Скажи, очень часто нужна функция, принимающая указатели на ЛЮБЫЕ объекты? Особенно в С++, где, например, можно сделать класс, от которого уже унаследовать все нужные классы, объекты которых будут передавать в функцию. И тогда там нужен будет не void* а SomeCoolClass*, что, согласись более разумно. Не, можно конечно напихать dynamic_cast в ф-цию, но лучше, если возможно, ограничить параметры сразу на входе

И тогда там нужен будет не void* а SomeCoolClass*

Каков будет SomeCoolClass для вышеупомянутой pthread_create?

Что самое важное - явный кусок кода

Ничего «явного» в этом куске кода нет. Это просто бессмысленное дублирование. Я уже устал это объяснять.

И эта явность приведений делает менее вероятным для программиста ошибочный код в духе

struct a * pa = &aaa;
void *pv = pa;
struct b * pb;
// вот тут беда
pb = pv;

Очень хороший пример. Теперь дополни этот код явным привдением типа и посмотри, что именно оно «даёт». ;)

shi~, не успел (:

Особенно в С++, где, например, можно сделать класс, от которого уже унаследовать все нужные классы, объекты которых будут передавать в функцию.

Object

И получится жавка.