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

вот код

struct my_data *p = data;

Ну это частный пример.
Да, если переменная сразу инициализируется,
то приведение — считай дублирование (хоть и совсем нестрашное).
А если так:

void my_callback(void *data)
{
struct my_data *p = NULL;
...
p = (struct my_data *) data;
...
}

Уже есть вероятность, что приведение из void* поможет ошибок избежать.

ЗЫ. Ну а в GLib/Gtk вообще святое дело не игнорировать такие ворнинги и все приводить макросами вроде GtkWidget *w = GTK_WIDGET(data). Тут вам вообще all inclusive в зависимости от опций сборки: либо динамические проверки типов например при отладке (макросы приведения = функции проверки типов), либо нулевые накладные расходы при релизе (макросы приведения = простые сишные приведения типов).

А какие еще есть варианты в С, кроме void*?

enum type { P1, P2 };

union ps {
  type *p1;
  type *p2;
}

struct s {
  union ps p;
  enum type t;
}

Это было ещё со времён 4.7dev.

можно было использовать Vala. Великолепный язык, хоть...

...тормознутый, плохо переносимый и недопиленный

//и что там такого великолепного в языке есть?

он бабавангу не обязан включать

Именно. Более того, он _обязан_ её выключать, когда ему русским языком говорят «void *». Объясни, с херали он полсе этого требует приведения при присваивании к и из void* указателя любого другого типа? Ведь это присваивание - заведомо _корректная_ операция.

Если я вижу только прототип, я долго буду сидеть и думать, какой же именно тип там ожидается.

Ты почему-то ставишь равенство между «непонятно» и «неявно».

Так ты все 3 достоинства и перечислил.

p = (struct my_data *) data;

Уже есть вероятность, что приведение из void* поможет ошибок избежать.

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

Ну это частный пример.

Это самый типовой пример использования void*. Он для такого применения был создан.

А если так: ... Уже есть вероятность, что приведение из void* поможет ошибок избежать.

Это каким же образом?

Если девелоперам гцц хотелось красивого, совремнного, объектно ориентированного языка со строгой типизацией, можно было использовать Vala

Вещества....

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

GCC прожил 25 лет и проживет еще долго.

p = (struct my_data *) data;
Уже есть вероятность, что приведение из void* поможет ошибок избежать.

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

Поможет, если по ошибке выше поменяют тип p.

он _обязан_ её выключать, когда ему русским языком говорят «void *».

ну вот он адъ и израиль в одном флаконе, нафига вообще типы, если что угодно к чему угодно прикастовать можно?

Ведь это присваивание - заведомо _корректная_ операция.

присваивание некорректно только когда в константу или в rvalue, но этого багов меньше не становится

Поможет, если по ошибке выше поменяют тип p.

ну если так - согласен, но это никак не поможет если p будет некорректным

Если я вижу только прототип, я долго буду сидеть и думать, какой же именно тип там ожидается.

Если совсем-совсем не знать С/С++, можно еще дольше сидеть и думать, что же значат эти закорючки. ;)

нафига вообще типы, если что угодно к чему угодно прикастовать можно?

Секундочку. А кто говорит о кастинге «чего угодно к чему угодно»? Речь идёт о том, что у нас есть тип, представляющий собой абстракцию любого адреса в памяти. Вопрос заключается в том, почему при использовании этого типа программист должен дублировать информацию о типе, который или к которому присваивается обобщённый указатель?

Это только если они шаблоны заюзают.

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

Че не понятного? Как уже говорилось гцц хотят переписать на С++.

походу это начало конца

вот потому что «нормальный» Си по факту считается языком с нестрогой типизацией

Да, и? Я не понял сути комментария. Писать на С / использовать void* больше нельзя, тк это говнокод?

C++ позволяет легче создавать и поддерживать четкие интерфейсы.

Риальне, поцаны?

Это ок когда типы хоть как-то известны.

C++ никогда не требует более кривого кода.

__ptr *list_entry() throw()
{
return reinterpret_cast<__ptr*>(reinterpret_cast<char*>(this)
    - reinterpret_cast<unsigned>(&static_cast<__ptr*>(0)->lh_));
}

А этому

struct s var = {
  .first = 1,
  .second = 2,
  .third = 3
};

И ещё вечный throw() на функциях...

Мелочи, а неприятно.

И ещё вечный throw() на функциях...

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

Если девелоперам гцц хотелось красивого, совремнного, объектно ориентированного языка со строгой типизацией, можно было использовать Vala.

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

C++ позволяет легче создавать и поддерживать четкие интерфейсы.

гопники в восторге

ocaml

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

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

С какой скоростью работает ядро, собранное шлангом?

По своему опыту хочу заметить, что в проектах на C++ кастование в/из (void*) встречается ооочень редко. И данный пример выглядит притянутым за уши.

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

теперь надо писать:

struct foo *p = (struct foo*) arg;

Тоже херня. Ты постоянно делаешь упор на то, что пишется всё разными программистами. Так вот, при разработке либы или чего бы там ни было, я, как программист, должен считать пользователей мудаками, и и проверять, а действительно ли мне дали указатель на struct foo*? И функция должна завершиться с ошибкой, а не вызвать segmentation fault. Проверками можно пренебречь только в действительно узких местах, где производительность выше всего.

Это ахтунг, друзья мои.

Си постепенно развивается, медленно, имхо, слишком, еще бы ввели слово pure для обозначения «чистых» функций, было бы классно.

Более строгая типизация - это всегда хорошо.

Главное в топике не указано. Они ограничатся лишь c-like подмножеством c++ или упорятся по полной местным ООП, шаблонами, перегрузкой функций, операторов, ссылками и прочими изысками?

Интересно как теперь надо будет делать этот самый bootstrap. Раньше для сборки cross-toolchain сначала gcc собирался только с поддержкой языка C, и уже потом, после сборки libc оно могло собрать само себя с поддержкой C++.

еще бы ввели слово pure для обозначения «чистых» функций, было бы классно.

Сори, что за чистые функции?

Сферическая функция в вакууме, эталон в палате мер и весов :}

с плюшками типа auto и strongly-typed enums.

Ты как раз вовремя.

чёткие интерфейсы

Пацаны-то одобряют?

Сори, что за чистые функции?

Функциональное задротство. Вроде бы как функции, результат которых зависит только от поданных аргументов.

Возвращение массива в Си полностью противоположно чистой функции.

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

const uint8_t buf[SIZE]; // strict one byte per element
cerr << string(static_cast<const char *>(static_cast<const void *>(buf));
unsigned_char_func(static_cast<const unsigned char*>(static_cast<const void *>(buf)));

код стал хуже

из-за явного каста код стал хуже? Куда катится мир... Этот спор даже не стоит времени на него потраченного.

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

еще бы ввели слово pure

Ну, в gcc уже есть. Или ты имеешь в виду внести в стандарт?

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

переписывать ядро на си++ не будут.

Риву! Риву, в Антанариву пишуть хаскил хаскиры на Риву! А нолиспи пишеццо осамл Вижу, ты об этом знаешь сам.

теперь будет собираться только с поддержкой си++ а уже потом со всем остальным?

Ядро в смысле линукс или в смысле сердцевина?