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

хотел написать ГЦЦ, но коммуникационному модулю всёравно как называть объекты (

Так Vala, же.

да, в стандарт.

из-за явного каста код стал хуже?

Да.

Куда катится мир...

?

что с ворнингом делать?

?

Забыли про венгерскую нотацию;)

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

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

Потому что придется написать все приведения типов, в явном виде. А значит - еще раз подумать, нет ли шансов, что в pv окажется что-то, не являющееся struct b *. Человеку свойственно ошибаться - поэтому переспросить никогда не вредно.
А вообще тут преавильно написали, что макросы в духе GTK_WIDGET(w) рулят. В сущности, gobject немножко ужесточает работу с типами в С (необходимо для ОО).

.first = 1,

А разве в сырцах gcc такое было?? Это ж довольно свежий стандарт С

.first = 1,

А разве в сырцах gcc такое было?? Это ж довольно свежий стандарт С

Этому стандарту уже 13 лет :)

какое счастье, что есть clang

какое счастье, что обезьян не умеющих мыслить абстрактно, так мало.

Этому стандарту уже 13 лет :)

и уже 13 лет его нельзя использовать, если ставишь цель писать код, который собирается хотя бы 3-4 самыми популярными компиляторами

Заявка на разрыв шаблона?)

А зачем вы свои шаблоны бережёте?
Смотрите.
Так и будете всю жизнь с не порванным шаблоном ходить.

C разрешает не только из/в void*, но и вообще из/в любой указатель. Да и вообще между типами очень свободно неявно конвертирует. Можно считать, что статическая типизация в C отсутствует. В C++ хоть какие-то минимальные меры против этого свального греха предприняты. И, кстати, зачем дезинформировать, C++ конвертирует любой указатель в void* неявно. По поводу явного приведения из void* - есть существенная разница между «конвертится ко всем типам» и «конвертится к любому типу». Чтобы исключить конвертацию ко всем типам, следует явно указывать этот самый «любой тип». Предположим, что на комитет нашло помраченье и в C++XX стало как в C. Начались бы неприятности:

#include <memory>

struct component { virtual void serialize() {} };
struct view : component { virtual void draw() {} };
struct control : component, view {};
void refresh(view* v) { v->draw(); }

int main()
{
    const std::unique_ptr< view > v(new view);
    const std::unique_ptr< control > c(new control);
    void* pv = v.get();
    void* pc = c.get();
    refresh(pv); // refresh(static_cast< view* >(pv));
    refresh(pc); // refresh(static_cast< control* >(pc));
    return 0;
}

man visitor

В Си есть несколько вещей, которые сделаны лучше, чем в Си++, и работа с void * - одна из них.

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

Больше неявных кастов - меньше надёжность, это вам не демон и не гуй какой-нибудь, который легко на части дробится. Страшно представить, как в gcc сейчас работает обход синтаксического дерева или выбор действия в зависимости от типа выражения... C++ намного улучшит конкретно эти части.

Хотя наиболее сложные части, вроде как, оптимизации над GIMPLE и генерация кода.

Говнокод можно писать на любом языке. Новость лишь подтверждает пополнение неосиляторов Си в составе команды gcc, ждем переписывания на Java :)

Порванному шаблону разрыв не грозит.

что макросы в духе GTK_WIDGET(w) рулят

много макросов дебажил? макросы должны быть выкинуты.

C++-компиляцию

Проприетарщина не нужна!

Сборка быстрее работает, а само ядро нет

Торвальдс хотя бы будет верен своим убеждениям...

Жаст фор фан?

Ого! Команда GCC признала, что С++ лучше С?

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html

2010 october
clang builds working linux kernel

А разве в сырцах gcc такое было??

Я код не видел, но ожидал бы такое встретить: работа с деревом, например, требует виртуальных функций, а vtbl делается именно так.

Есть милые проекты, которые не используют исключения вообще и потому счастливы.

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

Я стар... Я очень стар... Я суперстар..

Увы, без макросов в С никак.

C++ конвертирует любой указатель в void* неявно.

И указатель на метод, да?

Новость лишь подтверждает пополнение неосиляторов Си в составе команды gcc

Неосиляторы Си в команде компилятора языка Си? o_O

ждем переписывания на Java

А Java то тут каким боком? Java внезапно стала надмножеством Си или c++? Вообще-то она скорее подмножество с++ c принудительным использованием ООП и кастрированными возможностями. В данном случае никак не катит, это компилятор, а не enterprize с индусами.

Блин, сделали бы уже какой-то С+, который бы являл собой С со строгой типизацией

Нестрогая типизация - фича языка, т. к. позволяет его сделать простым и мощным (со строгой типизацией - выберите что-то одно).

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

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

и strongly-typed enums.

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

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

Java внезапно стала надмножеством Си или c++?

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

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

А что мешает именно так и писать на плюсах? Или рядом дядька с автоматом следит за полнотой использования возможностей языка?

ЗЫЖ помнится меня тут как раз за такой «быдлокод» и критиковали))))

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

Список классической литературы можно?

В этом случае ключевые слова «бессмысленное усложнение».

Ты знаешь, а я как бы считаю, что это «правильное» усложнение. Ибо нефиг.

Тред полон неосиляторов указателей. Не можешь укротить void* — дуй обратно в свой педон писать 1001-й сайт на джанге.

Вообще-то новость о компиляторе, причём компиляторе, мягко говоря, сложном. В таком контексте неявные касты из void* - зло,

Явные касты в стиле Си++ - просто бесполезная дурь. Все разглагольствования про «это подпись кодера под своим решением» - маразм.

и не удивлюсь, если они и были одной из причин перехода к C++.

Не были, я гарантирую это.

а я как бы считаю, что это «правильное» усложнение. Ибо нефиг.

«А слова как пудовые гири верны» (ц)

Этому стандарту уже 13 лет :)

и уже 13 лет его нельзя использовать, если ставишь цель писать код, который собирается хотя бы 3-4 самыми популярными компиляторами

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

Откуда тот чувак на канарах, который закочнил проект 10 лет назад, знает, какую структуру _я_ буду использовать здесь и сейчас в этом проекте?

Тот чувак на канарах написал функцию которая ожидает вполне себе определённую структуру. Каковую ты по уму и должен передать в функцию. А то, что _ты_ передаешь в эту функцию другую структуру - это уже неправильно, вследствие чего ты должен подтвердить приведением типов, что ты знаешь что делаешь.

Явные касты в стиле Си++ - просто бесполезная дурь.

И вообще типы данных не нужны, да?

2010 october clang builds working linux kernel

Еще 10 лет будем ждать «clang builds production-ready linux kernel». А то, что оно один раз где-то там заработало...

Явные касты в стиле Си++ - просто бесполезная дурь.

И вообще типы данных не нужны, да?

Что заставляет тебя так думать?

А что мешает именно так и писать на плюсах?

Увы, стиль диктуют фреймворки (Qt в моём случае) и библиотеки. И, конечно, унаследованный код. Если работать с чужим кодом - я бы предпочёл си, или такой вот си+ - с ними проще. Если писать с нуля - да, можно и на урезанном си++.

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

Нет. Зачем?

Нормальный способ передавать данные в обобщенную функцию.

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

Список классической литературы можно?

Dragon book, Modern compiler implementation (с вариантами).

Это никак не мешает написать на ней компилятор си )

Так пишите, а речь идет про gcc (читаем топик). Кроме того, скорость компиляции - важная характеристика компилятора.

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

Не знаю про какую «классическую» литературу Вы говорите (желательно обсуждать конкретные примеры), но даже если это и так, то писать действительно можно на чем угодно. И скорее всего для литературы даже больше бы подошел паскаль, чем Java.

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

Кроме того, скорость компиляции - важная характеристика компилятора.

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