LINUX.ORG.RU

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

 ,


3

4

Для начала изменен только bootstrap код. Цель — улучшение качества кода (поскольку С++ жестче работает с типами). Когда там появятся классы и темплейты?.. Официально заявленные причины использовать С++:

  • C++ — стандартизованный, популярный язык.
  • C++ — практически надмножество C90, используемого внутри GCC.
  • Совместимый с С C++ код так же эффективен, как просто код C.
  • C++ поддерживает более чистый код во многих важных ситуациях.
  • C++ позволяет легче создавать и поддерживать четкие интерфейсы.
  • C++ никогда не требует более кривого кода.
  • C++ не панацея, но улучшение.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Silent (всего исправлений: 6)

Ответ на: комментарий от frost_ii

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

Thero ★★★★★
()
Ответ на: комментарий от unsigned

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

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

q0tw4 ★★★★
()
Ответ на: комментарий от Pinkbyte

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

Вообще я про С писал. Я не считаю, что типобезопасность не нужна, я считаю, что говорить про то, что void* - безусловно говнокод, это перебор. А так, согласен.

AptGet ★★★
()
Ответ на: комментарий от q0tw4

предлагаю хаскель

на перле 6-м

Ну вот представь, сколько народу осилит эти книги, а сколько - с явой ) Рассчитано-то не на спецов в CS. MCI тоже на ML была написана, но потом добавили «народные» версии.

unsigned ★★★★
()
Ответ на: комментарий от gh0stwizard

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

Мыло — для грязных, деньги — для жадных…

Xenesz ★★★★
()
Ответ на: комментарий от LamerOk

и посмотри, что именно оно «даёт». ;)

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

svu ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

окстись

и скорость кодогенерации и качество(скорость исполнения) сгенерированного - оба критерия важны в промышленном программировании.

если бы важна только скорость исполнения сгенерированного ( есть такие прикладные области кстати) - то компиляторы начинают использовать np-полные алгоритмы( как тебе должно быть извествно из курса построения компиляторов многие (тоже распределение регистров) подзадачи при компиляции np-полные именно поэтому в промышленных компиляторах вынужденны различные эвристики использовать вместо идеальных по качеству сгенерированного кода алгоритмов )

qulinxao ★★☆
()
Ответ на: комментарий от svu

Охохох.

struct a * pa = &aaa;
void *pv = pa;
struct b * pb;
// теперь тут никакой беды нет?
pb = (struct b *)pv;

И что ты _теперь_ увидел в строке с присваиванием? Что стало болеее очевидным?

LamerOk ★★★★★
()

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

Это всё равно что перейти на brainfuck.

Hertz ★★★★★
()
Ответ на: комментарий от LamerOk

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

svu ★★★★★
() автор топика

GCC не нужно.

anonymous
()
Ответ на: комментарий от A-234

В С++ необходимость в void* возникает только в двух случаях:

В изначально 146%-расово чистом трижды насквозь Си++ проекте - может быть. Но, как ты помнишь, речь о постепенном переводе Си-проекта на Си++.

tailgunner ★★★★★
()
Ответ на: комментарий от LamerOk

Вообще-то текст вида

void f(void *arg)
{
	struct foo *p = (struct foo*) arg;
	...

ничем не лучше вышеприведенного Сишного кода. В С++ рекомендуется использовать другие конструкции вроде xxxx_cast<newtype>(arg).

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

void f(struct foo *arg)
?

Не надо писать на С++ как на С (хотя для людей со слабой психикой это не запрещено, что дает С++ еще больше плюсов), тогда все будет хорошо.

dr_dobermann
()
Ответ на: комментарий от tailgunner

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

A-234 ★★★★★
()
Ответ на: комментарий от dr_dobermann

В этом треде всем пофиг, по крайней мере на C касты, ещё с самого его начала :)

Deleted
()
Ответ на: комментарий от dr_dobermann

Покажите третий вариант, пожалуйста.

Представь: тебе задают вопрос и предлагают 2 одинаково идиотских варианта варианта ответа. Ты спрашиваешь «а третьего варианта нет?». Тебе отвечают «предложи третий вариант». Твоя реакция? Моя - сказать «Уходи, норкоман». Это же и тебе повторю - уходи, норкоман.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от A-234

Я, как Ъ, по ссылкам не ходил и думал, что они забабахали новую архитектуру заточенную под плюсы.

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

sv75 ★★★★★
()
Ответ на: комментарий от LamerOk

При чём тут авторы гцц? Мы вообще-то обсуждаем тезис

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

А что не так? Как ты проверишь на этапе исполнения, что тебе в твой void* пришло именно struct foo*?

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

С++ при правильном дизайне убьет подобный мусор на этапе компиляции.

И даже если интерфейс менять нельзя, потому как опубликован давно и используется честно, то и тут конструкция c dynamic_cast даст стопроцентный результат защиты от дурака.

dr_dobermann
()
Ответ на: комментарий от red_eyed_peguin

Для некоторых и на брейнфаке писать проблемы нет, но это не повод так делать. Особенно если это не write-only код.

Deleted
()
Ответ на: комментарий от tailgunner

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

В данном конкретном случае кривой код на С заменен на кривой код на С.

Из возможностей С++ тут не используется ничего.

dr_dobermann
()
Ответ на: комментарий от dr_dobermann

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

Какие размеры? Мужского полового или женских молочных?

red_eyed_peguin
()
Ответ на: комментарий от tailgunner

Ты спрашиваешь «а третьего варианта нет?». Тебе отвечают «предложи третий вариант». Твоя реакция?

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

Моя - сказать «Уходи, норкоман»

да, у тебя это частая реакция

wota ★★
()
Ответ на: комментарий от dr_dobermann

конструкция c dynamic_cast даст стопроцентный результат защиты от дурака.

...при включенном RTTI.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А еще у меня 2*2 часто равно 4.

ну что ж, все не так плохо, но надо работать над 100% результатом

Блин, я даже не припомню случая, чтобы !=.

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

wota ★★
()
Ответ на: комментарий от LamerOk

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

каким боком объявление void foo(void* arg) прозрачно при чтении исходников?

Без тонны комментариев ты никогда не догадаешься, что нужно этой функции.

При этом объявление вида void foo(struct foo* arg) вообще не нуждается в комментариях. При этом оно автоматически кастится до коллбаков с желаемым void*

dr_dobermann
()
Ответ на: комментарий от dr_dobermann

Речь не про 'foo', а про 'callback'.

Начиная с pthread_create, и любыми иными случаями таскания за собой контекста через void *.

sv75 ★★★★★
()
Ответ на: комментарий от dr_dobermann

Постоянное желание пренебречь типами с упованием на автоприведение.

Хм. Что заставляет тебя думать, будто у меня есть такое желание?

Не?

Даже и не близко, я вообще сторонник фашистской строгой типизации. Но в Си это невозможно, использование void * неизбежно, и мелкие удобства при его использовании приятны.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Н-да.. школота одна на моём лоре осталась... Пора сваливать.

anonymous
()
Ответ на: комментарий от tailgunner

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

// fixed

shty ★★★★★
()
Ответ на: комментарий от tailgunner

сказать «Уходи, норкоман». Это же и тебе повторю - уходи, норкоман.

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

А вопрос про третий вариант был задан по причине неадекватности приведенных выводов, более подходящих упертому фанатику, чем мыслящему человеку.

Но с учетом последних ваших комментариев, ясно, что дискутировать с вами бесполезно в принципе. Удачи в полях.

dr_dobermann
()
Ответ на: комментарий от shty

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

Палишься.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

лучше верни аккаунт настоящему тейлганнеру

shty ★★★★★
()
Ответ на: комментарий от LamerOk

Да, вполне мог бы пропустить... Люблю, когда язык по возможности защищает от ошибок (соббсно только в этом смысл языков с жесткой типизацией).

svu ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.