LINUX.ORG.RU
Новости — Open Source  

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

 ,


3

4

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

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

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Silent (всего исправлений: 6)
← libc++ теперь есть и в Debian Experimental
The Humble Bundle for Android 3 →
  1 2 3 4 5 6 7 8 9 10
Ответ на: комментарий от Pinkbyte

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

Ошибку можно увидеть _только_ проследив использование void *. Синтаксический мусор явного каста этому не поможет.

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

не стоит путать синтаксический мусор и нужные конструкции языка. А то мы так докатимся до брейнфака... Не, ну а чо - зачем писать эти длинные, неудобочитаемые printf или cout. Это ж синтаксический мусор...

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

не стоит путать синтаксический мусор и нужные конструкции языка.

Я и не путаю.

ну а чо - зачем писать эти длинные, неудобочитаемые printf или cout. Это ж синтаксический мусор...

...и ты не путай.

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

речь именно про реализацию - см. выше

Так и для того и для другого существует интерпретатор (на уровне GIMPLE делается constant propagation и aggressive DCE, а для этого необходим интерпретатор IR).

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

Тред почти не читал

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

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


struct a {
virtual void m() {...}
};

struct b: public a {
virtual void m() {...}
};

struct c: public b {
virtual void m() {...}
};

...

void func(void *v) {
    a *p=v; // Очевидно, ошибка
    ...
    v->m();
    ...
}

К какому классу приводить v? Компилятор знать не может, ибо даже если мы передаем указатель на конкретный класс (например c), то в функции, по логике работы программы может требоваться другой класс иерархии (например b). Чтобы решить этот вопрос без привлечения libastral требуется явно указывать желаемый тип (класс).

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

Хорошо, буду играть по твоим правилам - я тупой, объясни мне разницу между моим вырожденным примером с брейнфаком и тем что ты считаешь, что явный каст в случае void* - это что-то лишнее? Я лично разницы не вижу...

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

буду играть по твоим правилам - я тупой

Если тупой - лучше не играй.

объясни мне разницу между моим вырожденным примером с брейнфаком

Я не знаю брейнфака, но давай ссылку на пример.

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

В брейнфаке вывод данных на экран осуществляется одним символом(кажется это запятая). Собственно мой постулат был - «ты считаешь, что код будет правильнее и понятнее если просто писать меньше текста?». На заметку, я тоже не люблю синтаксический сахар, но здесь явный каст - явно не из этой оперы...

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

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

Это вопрос, а не постулат. На этот вопрос нельзя просто ответить «да» или «нет». Для конкретного случая преобразования void * я ответил.

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

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

Pinkbyte ★★★★★
()

Компилятор С++ переходит на С++.

/fixed

ЗЫ. Когда в компилятор запилят первый шаблон, запостите новость на главной.

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

тоесть ты знаешь о том какработает кланг ещё меньше меня.

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

Компилятор С++

facepalm

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

А это тебе что, не новость? Уже запилили.

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

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

у тебя сломался libastral, анонимус — срочно его пересобери

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

при этом никто не обещал, что этих типов будет конечное число или что они будут известны на этапе компиляции (хотя можно попросить, чтобы типы аргументов сопадали: f(Type1 x1, Type1 x2) )

теперь:

1. возьми мне пожалуста адрес у функции 

template<class Elem> List<Elem*>* append(List<Elem*>* x, List<Elem*>* y)
и запиши его в массив, откуда я смогу его потом прочитать и использовть для двух своих списков, Elem у которых совсем не тот, о котором ты мог подумать

напоминаю определение — append должна быть одной функцией с четко определенным адресом, а не 100500 функциями с чем-то похожими именами /сарказм/

2. на тему (бес)кончености числа типов пробегало тут на лор-е, гуглить видимо по miguel скалярное произведение

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

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

надо слушать воспитательницу и есть всю кашу, которую дают // fixed for the greater justice

Если честно, то еще не видел такой концепции, которую нельзя было бы выразить на С++. Также как и на С, так же как и на питоне и прочих явах.

второе предложение, к сожалению, обесценивает первое

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

Параметрический полиморфизм поддерживается С++ напрямую...

... если нам не нужно брать адреса параметрически полиморфных функций (реализованных как шаблонные функции)

... и если нам не надо полагаться на некоторые соотношения между типами, которые компилятор может проверить для конечного числа аргументов, но не может для бесконечного (например «если T<x>=T<y>, то для любого натурального a T<x+a>=T<y+a>»)

... и если нам не нужен virtual template или мы согласны вместо него заняться борьбой с типизаций (tm) которая в данном случае скорее всего приведет к созданию визиторов и еще неизвестно, чьей победой закончится — нашей, или типизации :-)

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

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

Ну это вы уже динамику приплели, параметрический полиморфизм здесь не причём. man dynamic_cast, boost::any, boost::variant. Второй пункт - не критерий параметрического полиморфизма.

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

алсо void* не одной из этих «проблем» не решит и в любом случае это худшее решение которое только можно придумать.

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

Из чего я делаю вывод что libpthread написана на C.

Я даже больше скажу — вообще все системные функции POSIX являются (по интерфейсу) сишными, да.

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

А это тебе что, не новость? Уже запилили.

Не, пока на компиляцию не требуется 8-16 гектар рамы, фигня это а не шаблоны.

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

бесполезные VM тоже VM

Ладно, ок GCC, LLVM, MSVC — все они VM. Итого — все компиляторы VM, проблемы с LLVM нет никакой.

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

Итого — все компиляторы VM

неправильный вывод - VM подразумевает симуляцию или интерпретацию, не каждый компилятор это умеет

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

неправильный вывод -

У-тю-тю

VM подразумевает симуляцию или интерпретацию, не каждый компилятор это умеет

Каждый. Ты туп.

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

Каждый

#include <cstring>
#include <fstream>
#include <iostream>
using namespace std;

unsigned char out[] = {
0x7f,0x45,0x4c,0x46,0x02,0x01,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x02,0x00,0x3e,0x00,0x01,0x00,0x00,0x00,0xb0,0x00,0x40,0x00,0x00,0x00,
0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xf0,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x40,0x00,0x38,0x00,0x02,0x00,0x40,0x00,
0x04,0x00,0x03,0x00,0x01,0x00,0x00,0x00,0x05,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x40,0x00,0x00,0x00,0x00,0x00,0xcd,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xcd,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x20,0x00,0x00,0x00,0x00,0x00,
0x01,0x00,0x00,0x00,0x06,0x00,0x00,0x00,0xd0,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0xd0,0x00,0x60,0x00,0x00,0x00,0x00,0x00,0xd0,0x00,0x60,0x00,0x00,0x00,
0x00,0x00,0x07,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x07,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x20,0x00,0x00,0x00,0x00,0x00,0xba,0x07,0x00,0x00,
0x00,0xb9,0xd0,0x00,0x60,0x00,0xbb,0x01,0x00,0x00,0x00,0xb8,0x04,0x00,0x00,
0x00,0xcd,0x80,0xb8,0x01,0x00,0x00,0x00,0xcd,0x80,0x00,0x00,0x00,0x41,0x3a,
0x20,0x30,0x30,0x30,0x0a,0x00,0x2e,0x73,0x68,0x73,0x74,0x72,0x74,0x61,0x62,
0x00,0x2e,0x74,0x65,0x78,0x74,0x00,0x2e,0x64,0x61,0x74,0x61,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x0b,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x06,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0xb0,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0xb0,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x1d,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x10,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x11,0x00,0x00,0x00,0x01,0x00,0x00,
0x00,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xd0,0x00,0x60,0x00,0x00,0x00,
0x00,0x00,0xd0,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x07,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x04,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,
0x00,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0xd7,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x17,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00 };

int main()
{
	int value;
	char program[] = "123;exit;";

	char* p = strtok( program, ";" );
	while( p )
	{
		if( !strcmp( p, "exit" ) )
			break;

		value = atoi( p );
		p = strtok( NULL, ";" );
	}	

	out[ 211 ] = '0' + value / 100;
	out[ 212 ] = '0' + value / 10 % 10;
	out[ 213 ] = '0' + value % 10;

	ofstream( "b.out", ios::binary ).write( (char*) out, sizeof(out) );
}

компилятор для примитивного (но не такого как ты) «ЯП» в elf64, где тут интерпретация или симуляций?

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

где тут интерпретация или симуляций?

я думал ты спросишь где тут C++

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

ну так и откуда подозрения в том, что я наркоман тогда? :-)

pthread не входит в стандарт Си, поэтому все, кто называет ее «функцией Сишной библиотеки», попадают под подозрение %)

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

Как вам в этом во всем поможет void*? Это ведь всего лишь указатель на хрен-знает-что. Я вам пример с потоками привел не просто так. Параметрический полиморфизм подразумевает своего рода создание фрейма стека с информацией о типах. Так сконструируйте его сами, не через один единственный вызов а несколько последовательных операторов. Тут вы сможете проверить типы того что пытаетесь передавать, и еще применить контракты. Хотя с контрактами в плюсах беда, лично мне их дико не хватает. Не то что бы их невозможно было реализовать но хотелось бы плюшек на уровне синтаксиса.

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

Потому что такую ошибку легче выявить...

Совершенно бездоказательное утверждение. Я сам наступал на эти грабли, лично мне ничем не легче было.

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

ну так и откуда подозрения в том, что я наркоман тогда? :-)

... что вы оглашали базовые общеизвестные факты о POSIX API.

Ну и «функция Сишной библиотеки», но видимо имелоcь в виду «функция библиотеки на Си», это большая разница...

sv75 ★★★★★
()
Последнее исправление: sv75 (всего исправлений: 1)
Ответ на: комментарий от wota

Я уже пару страниц подозреваю, что вы просто демагог и софист — спасибо, что подтвердили, а то бы я ещё время потратил.

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

Просто Вы не в курсе, как влияет промежуточное представление на возможности дальнейших оптимизаций. LLVM следует по пути - как сделать простой инструмент, а не быстрый код.

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

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

ну так ты нам поведай, чо

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

ололо, я так и думал что сказать тебе нечего :)

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

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

Давайте начнём с простого вопроса — есть ли принуципиальные отличия между представлением GIMPLE и IR?

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

Ну неправильно выразился. Под «Сишная библиотека» я имел ввиду любую библиотеку, написанную на языке С, а не то, что должен был иметь ввиду - то есть libc

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

А мне было. И моим знакомым программистам - тоже. Согласен, опыт - вещь субъективная, но все же...

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

Оглашающий общеизвестные факты - это ИМХО К.О., а норкоман(именно с таким акцентом :-)) - это тот, кто бредит и порет чушь так, что та аж визжит...

А с библиотекой да, неясно выразился, виноват...

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

Я уже пару страниц подозреваю, что вы просто демагог и софист — спасибо, что подтвердили,

ок, если такой небольшой пример для тебя не кажется доводом, то возьми код tcc - там тоже нет оптимизаций, которые бы требовали какой-либо интерпретации, обоснуй - чем это VM

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

и заметь я изначально придерживаюсь одного мнения: есть интерпретатор - есть VM, а ты делаешь прямо противоположные заявления

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

есть интерпретатор - есть VM,

То есть python у нас VM, а C# и Java (на x86) — не VM, раз там JIT? И VirtualBox тоже не VM, да? Я вообще обсуждал тезис товарища, что якобы LLVM по определению говно, раз там некое VM.

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

а C# и Java (на x86) — не VM, раз там JIT?

JIT там лишь дополнительная возможность

И VirtualBox тоже не VM, да?

VM, т.к. симуляция - но это не имеет отношения к компиляторам, потому в предыдущем комментарии я пропустил ее

Я вообще обсуждал тезис товарища, что якобы LLVM по определению говно, раз там некое VM.

он не прав

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

Во-первых, GIMPLE и есть intermediate representation.

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

В-третьих, самобытность GIMPLE в данном случае и является определяющим фактором, (хотя само построение отнюдь не идеально - факт) посему отличие intermediate representation в gcc и llvm принципиально.

В-четвертых, посмотрите же, наконец, проблемы оптимизации RISC-style и интерпретируемого кода, llvm это не остриё науки, все шишки давно набиты.

frost_ii ★★★★★
()
Последнее исправление: frost_ii (всего исправлений: 2)
Ответ на: комментарий от frost_ii

Во-первых, GIMPLE и есть intermediate representation.
Во-вторых, GIMPLE это весьма ёмкое понятие, чтобы так вот бросать сравнения

это ж б..., горы, та-та-та-та-та

shty ★★★★★
()
Последнее исправление: shty (всего исправлений: 1)
Ответ на: комментарий от frost_ii

Во-первых, GIMPLE и есть intermediate representation.

Я конкретно про LLVM IR, ну неужели не ясно из контекста?

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

Засчитано нежелание обсуждать по делу.

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

он не прав

А, то есть вам просто хотелось поиграться терминами и побыть формалистом, я понял ))

sv75 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8 9 10
← libc++ теперь есть и в Debian Experimental
Open Source
The Humble Bundle for Android 3 →