Какие есть компиляторы c++ без изменения синтаксиса

@kaheu · Регистрация: 19.08.2013

Author24 — интернет-сервис помощи студентам

какие есть компиляторы c++ без изменения синтаксиса?

@0x10 · 28.07.2014, 20:15

Не по теме:

Сообщение от CyberSolver

Топикстартер ведь говорил про расширение языка в смысле изменения семантики

По постам автора, я не уверен, что он сам знает о чем говорит.

Evg · 28.07.2014, 21:10

Сообщение от CyberSolver

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

Понятие "расширение" подразумевает введение дополнений, а не изменение существующих конструкций

Сообщение от CyberSolver

Вообще, это было первое, чему меня научили в Си++ (раньше чем using namespace std; ) - всё, что non-standart, - сразу в топку. А в стандарте ясно написано: любые изменения стандарта автоматически non-standart (привет, кэпы из ISO).

Об чём и идёт речь с самого начала. Вопрос только в том, что такое non-standard. Для эксперта этот вопрос затруднений не вызывает. А новичку далеко не сразу и не везде понятно, что есть стандарт, а что нет. Потому ТС и спросил, как сие возможно проконтролировать в автоматическом режиме, а не в режиме постоянного чтения стандартов

Сообщение от Toshkarik

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

Это не так. Этим расширением пользуется множество разработчиков, выпускающих программные продукты, которые поставляют дополнительные хидеры. Т.е. разработчики библиотек. А так же разработчики ядра линукса (потому что ядро поставляет множество инклюдов в user-space). А может кто-то ещё. В любом случае новичок, увидевший где-то использование typeof и попробовавший его на gcc, далеко на сразу поймёт, что сие есть расширение языка C, а не стандартный C

@Toshkarik · 28.07.2014, 21:15

Видать, опять неправильно поняли. Я имел ввиду, что typeof - расширение для сторонних разработчиков, а __typeof__ - для внутренней реализации. Хоть они и выполняют одно и то же. Возможно, даже один является макросом другого.

Evg · 28.07.2014, 22:51

Нет. Точно так же __typeof__'ом пользуются все. К тому же glibc (которая является системной библиотекой) НЕ является частью компилятора. Как минимум это говорит о том, что __typeof__ - это не внутреннее расширение, а для широкого использования

Добавлено через 1 час 27 минут

Сообщение от CyberSolver

Топикстартер ведь говорил про расширение языка в смысле изменения семантики

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

@CyberSolver · 29.07.2014, 06:42

Сообщение от Evg

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

Сообщение от 0x10

Не по теме:
Сообщение от CyberSolver
Топикстартер ведь говорил про расширение языка в смысле изменения семантики
По постам автора, я не уверен, что он сам знает о чем говорит.

По поводу гнусных расширений и не только - я бы использовал только в каких-то библиотечных файлах для оптимизации (для чего-то эти расширения же придумали). Но я бы их обернул во что-то, что хотя бы потенциально может быть перенесено на другие платформы. Про glibc и linux kernel - поскольку конечный юзер напрямую их почти не использует (а если использует, явно понимает, что к чему), пусть пишут там что душе угодно. Но по мне так это порочная практика. Как же принцип мира Unix: жертвуй производительностью ради переносимости? gcc со своими расширениями, конечно, переносимый, но это какая-то узкая трактовка понятия "переносимость". Ну и может я ламер, но я ещё не встретил в жизни ситуации, когда мне позарез нужны были расширения компилятора.

Может, кто-то поделится примерами из практики?

@0x10 · 29.07.2014, 07:55

Сообщение от CyberSolver

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

В большей части прикладного кода они и не встетятся.
Пример из стандартной библиотеки - реализация type_traits.
http://en.cppreference.com/w/cpp/types
https://gcc.gnu.org/onlinedocs... ype-Traits

Evg · 29.07.2014, 09:06

Сообщение от CyberSolver

Как же принцип мира Unix: жертвуй производительностью ради переносимости?

Сколько десятилетий назад провозгласили этот принцип? И насколько с тех пор изменился мир? И вообще, были ли в то время такие понятия, как "задача реального времени"?

@CyberSolver · 29.07.2014, 19:19

Сообщение от 0x10

Пример из стандартной библиотеки - реализация type_traits.

Ээээээ. Ну кагбэ Александреску всё это сделал 100500 лет назад в своей Loki. На том же cpprefernece Possible implementation почти копирует его код (ну кроме всяких remove_reference). Так что мимо.

Добавлено через 6 минут

Сообщение от Evg

Сколько десятилетий назад провозгласили этот принцип?

Примерно 40. Фортрану поболе будет. Да и Лиспу. Думаю, постарше вас.

Сообщение от Evg

И насколько с тех пор изменился мир?

Нинасколько. Всё так же Си, всё те же яйца. Только теперь куча придурков решило: раз венда - это 90% рынка, а она только под Intel, то и нафиг все эти ваши Linux и ARM. Дружно все пишем на шарпе. Или уэб-интерфейсы. А хто самый умный, тому невероятно переносимая Java.

Сообщение от Evg

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

=-O Вы меня, конечно, извините, но вы вроде эксперт Си++, а морозите какую-то чушь.

@0x10 · 29.07.2014, 19:26

Сообщение от CyberSolver

ну кроме всяких

Я и не сказал, что трейтсы должны быть на 100% реализованы на расширениях компилятора. Часть их используют (has_trivial_[constructor|destructor|etc...])

@CyberSolver · 29.07.2014, 19:34

Сообщение от 0x10

Я и не сказал, что трейтсы должны быть на 100% реализованы на расширениях компилятора.

Вообще, про то и речь: все traits давно реализованы на чистых шаблонах уже лет 10-15 как. Здесь та же ситуация, что с Boost: творения всяких маньяков типа Александреску попадают в стандарт. (Даже странно, что в Си++11/14 не добавили сериализацию, в бусте давно есть).

Так что мало того что всё это не требует никаких расширений компилятора вообще, так и возникает вопрос: а зачем вам столько информации о типах на этапе компиляции?

@uglyPinokkio · 29.07.2014, 19:39

Сообщение от Evg

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

В то время были ОС реального времени

.

@0x10 · 29.07.2014, 19:42

Сообщение от CyberSolver

Так что мало того что всё это не требует никаких расширений компилятора вообще,

Я говорю об обратном - некоторые трейтсы требуют поддержки компилятора.

Сообщение от CyberSolver

а зачем вам столько информации о типах на этапе компиляции?

Повторю то, что уже говорил выше: это может быть неочевидно для прикладного программиста. Я не писал библиотечный код, а потому не могу привести конкретные примеры применимости.

@CyberSolver · 29.07.2014, 19:52

Сообщение от 0x10

Я говорю об обратном - некоторые трейтсы требуют поддержки компилятора.

Это какие?

Сообщение от 0x10

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

Может, я дурак, но что кому неочевидно?

@0x10 · 29.07.2014, 19:57

Сообщение от CyberSolver

Это какие?

http://www.boost.org/doc/libs/... uctor.html

Without some (as yet unspecified) help from the compiler, has_trivial_constructor will never report that a user-defined class or struct has a trivial constructor;

Просмотр всех остальных оставляю по желанию, сам не искал.

Сообщение от CyberSolver

Может, я дурак, но что кому неочевидно?

Прикладному программисту может быть неочевидно "зачем столько информации о типах на этапе компиляции". Сходу мне придумывается оптимизация функции типа push_back: при перевыделении памяти переместить объекты из старой памяти в новую безопасно можно только если их move-конструкторы не бросают исключений. Кажется нормальным вариантом для оптимизации.

@Kastaneda · 29.07.2014, 20:27

Сообщение от CyberSolver

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

Если разработака ведется именно под Linux, то бывает эти расширения во всю используются.

Сообщение от CyberSolver

Но я бы их обернул во что-то, что хотя бы потенциально может быть перенесено на другие платформы.

Живой пример (из OpenJDK)

C++

#ifdef __GNUC__
#define LIKELY(x) __builtin_expect((x),1)
#define UNLIKELY(x) __builtin_expect((x),0)
#else
#define LIKELY(x) (x)
#define UNLIKELY(x) (x)
#endif
 
if (LIKELY(ptr != NULL) {
    // code
}

@CyberSolver · 29.07.2014, 20:39

Сообщение от Kastaneda

Живой пример

Ну вот примерно так бы и обернул, хотя бы define'ами.

Evg · 29.07.2014, 22:40

Сообщение от CyberSolver

Нинасколько. Всё так же Си, всё те же яйца

Только вот процессора сильно поменялись в своём внутреннем устройстве. Если раньше достаточно было повысить частоту в два раза, после чего программа начинала работать в два раза быстрее, то сейчас это уже не так. Процессоры стали сложнее, а потому стало сложнее писать под них оптимальный код. Далеко не всегда получается это сделать на чистом языке без использования расширений. Я уж не говорю о том, что приличная доля вычислений перетекла с CPU на GPU, где чистый язык вообще мало канает

Сообщение от CyberSolver

Только теперь куча придурков решило: раз венда - это 90% рынка, а она только под Intel, то и нафиг все эти ваши Linux и ARM

Опять-таки мало понятно, откуда ты такую ересь высасываешь. Есть конкретное приложение, работающее под вполне себе конкретной системой, к которой ставится вполне себе нехилое требование - миллион транзакций в секунду. Все доводы из разряда "жертвуй производительностью ради переносимости" идут лесом как минимум потому, что переносимость нафиг никому не нужна при такой постановке задачи. Понятно, что всегда нужно по возможности стараться писать максимально переносимый код, но когда из принципа начинает уродоваться программа из соображений "пусть в 10 раз медленнее, зато строго по стандарту", то это такой же маразм диванных теоретиков, как "программирование без goto".

Сообщение от CyberSolver

Вы меня, конечно, извините, но вы вроде эксперт Си++, а морозите какую-то чушь

В каком конкретно месте чушь и в чём она выражается?

Сообщение от uglyPinokkio

В то время были ОС реального времени

И что, они писались на чистом (стандартном) языке программирования без расширений? А ведь именно в контексте использования расширений и начался спор

@uglyPinokkio · 30.07.2014, 06:07

Сообщение от Evg

И что, они писались на чистом (стандартном) языке программирования без расширений?

О задачах реального времени имеет смысл говорить только применительно к ОС реального времени, а это ниша довольно специфическая. RT11 помнится была написана на ассемблере. А в целом вполне очевидно, что есть задачи, для которых производительность важнее переносимости, иначе вот этого: https://software.intel.com/sit... sicsGuide/ бы не было.

@Toshkarik 1181 / 894 / 94 Регистрация: 03.08.2011 Сообщений: 2,461
	28.07.2014, 21:15	23
	Видать, опять неправильно поняли. Я имел ввиду, что typeof - расширение для сторонних разработчиков, а __typeof__ - для внутренней реализации. Хоть они и выполняют одно и то же. Возможно, даже один является макросом другого. 0

@CyberSolver 102 / 75 / 17 Регистрация: 23.07.2014 Сообщений: 877 Записей в блоге: 1
	29.07.2014, 06:42	25
	Сообщение от Evg К слову говоря, такого он вовсе не говорил. Это уже ты за него придумал Сообщение от 0x10 Не по теме: Сообщение от CyberSolver Топикстартер ведь говорил про расширение языка в смысле изменения семантики По постам автора, я не уверен, что он сам знает о чем говорит. По поводу гнусных расширений и не только - я бы использовал только в каких-то библиотечных файлах для оптимизации (для чего-то эти расширения же придумали). Но я бы их обернул во что-то, что хотя бы потенциально может быть перенесено на другие платформы. Про glibc и linux kernel - поскольку конечный юзер напрямую их почти не использует (а если использует, явно понимает, что к чему), пусть пишут там что душе угодно. Но по мне так это порочная практика. Как же принцип мира Unix: жертвуй производительностью ради переносимости? gcc со своими расширениями, конечно, переносимый, но это какая-то узкая трактовка понятия "переносимость". Ну и может я ламер, но я ещё не встретил в жизни ситуации, когда мне позарез нужны были расширения компилятора. Может, кто-то поделится примерами из практики? 0

@uglyPinokkio 327 / 230 / 55 Регистрация: 30.05.2014 Сообщений: 682
	29.07.2014, 19:39	31
	Сообщение от Evg И вообще, были ли в то время такие понятия, как "задача реального времени"? В то время были ОС реального времени . 0

@0x10 3257 / 2059 / 351 Регистрация: 24.11.2012 Сообщений: 4,909
	29.07.2014, 19:42	32
	Сообщение от CyberSolver Так что мало того что всё это не требует никаких расширений компилятора вообще, Я говорю об обратном - некоторые трейтсы требуют поддержки компилятора. Сообщение от CyberSolver а зачем вам столько информации о типах на этапе компиляции? Повторю то, что уже говорил выше: это может быть неочевидно для прикладного программиста. Я не писал библиотечный код, а потому не могу привести конкретные примеры применимости. 0

@CyberSolver 102 / 75 / 17 Регистрация: 23.07.2014 Сообщений: 877 Записей в блоге: 1
	29.07.2014, 19:52	33
	Сообщение от 0x10 Я говорю об обратном - некоторые трейтсы требуют поддержки компилятора. Это какие? Сообщение от 0x10 Повторю то, что уже говорил выше: это может быть неочевидно для прикладного программиста. Может, я дурак, но что кому неочевидно? 0

@kaheu 34 / 0 / 1 Регистрация: 19.08.2013 Сообщений: 246
		1
	Какие есть компиляторы c++ без изменения синтаксиса 27.07.2014, 12:19. Показов 2642. Ответов 37 Метки нет (Все метки) какие есть компиляторы c++ без изменения синтаксиса? 0

@0x10
	28.07.2014, 20:15 Какие есть компиляторы c++ без изменения синтаксиса #21
	Не по теме: Сообщение от CyberSolver Топикстартер ведь говорил про расширение языка в смысле изменения семантики По постам автора, я не уверен, что он сам знает о чем говорит. 0

Evg 21279 / 8301 / 637 Регистрация: 30.03.2009 Сообщений: 22,659 Записей в блоге: 30
	28.07.2014, 21:10	22
	Сообщение от CyberSolver Запретить, конечно, не может. Но если они изменят семантику, к примеру, try-catch, можно сразу и навсегда выкинуть сие... хм, поделие на мороз. Понятие "расширение" подразумевает введение дополнений, а не изменение существующих конструкций Сообщение от CyberSolver Вообще, это было первое, чему меня научили в Си++ (раньше чем using namespace std; ) - всё, что non-standart, - сразу в топку. А в стандарте ясно написано: любые изменения стандарта автоматически non-standart (привет, кэпы из ISO). Об чём и идёт речь с самого начала. Вопрос только в том, что такое non-standard. Для эксперта этот вопрос затруднений не вызывает. А новичку далеко не сразу и не везде понятно, что есть стандарт, а что нет. Потому ТС и спросил, как сие возможно проконтролировать в автоматическом режиме, а не в режиме постоянного чтения стандартов Сообщение от Toshkarik Одно дело, когда функция/оператор существует лишь для реализации компилятора и стандартной библиотеки, и другое, когда их делают для использования сторонними разработчиками. typeof и __typeof__, как мне кажется, наглядный пример Это не так. Этим расширением пользуется множество разработчиков, выпускающих программные продукты, которые поставляют дополнительные хидеры. Т.е. разработчики библиотек. А так же разработчики ядра линукса (потому что ядро поставляет множество инклюдов в user-space). А может кто-то ещё. В любом случае новичок, увидевший где-то использование typeof и попробовавший его на gcc, далеко на сразу поймёт, что сие есть расширение языка C, а не стандартный C 0

Evg 21279 / 8301 / 637 Регистрация: 30.03.2009 Сообщений: 22,659 Записей в блоге: 30
	28.07.2014, 22:51	24
	Нет. Точно так же __typeof__'ом пользуются все. К тому же glibc (которая является системной библиотекой) НЕ является частью компилятора. Как минимум это говорит о том, что __typeof__ - это не внутреннее расширение, а для широкого использования Добавлено через 1 час 27 минут Сообщение от CyberSolver Топикстартер ведь говорил про расширение языка в смысле изменения семантики К слову говоря, такого он вовсе не говорил. Это уже ты за него придумал 0

@0x10 3257 / 2059 / 351 Регистрация: 24.11.2012 Сообщений: 4,909
	29.07.2014, 07:55	26
	Сообщение от CyberSolver я ещё не встретил в жизни ситуации, когда мне позарез нужны были расширения компилятора В большей части прикладного кода они и не встетятся. Пример из стандартной библиотеки - реализация type_traits. http://en.cppreference.com/w/cpp/types https://gcc.gnu.org/onlinedocs... ype-Traits 0

Evg 21279 / 8301 / 637 Регистрация: 30.03.2009 Сообщений: 22,659 Записей в блоге: 30
	29.07.2014, 09:06	27
	Сообщение от CyberSolver Как же принцип мира Unix: жертвуй производительностью ради переносимости? Сколько десятилетий назад провозгласили этот принцип? И насколько с тех пор изменился мир? И вообще, были ли в то время такие понятия, как "задача реального времени"? 0

@CyberSolver 102 / 75 / 17 Регистрация: 23.07.2014 Сообщений: 877 Записей в блоге: 1
	29.07.2014, 19:19	28
	Сообщение от 0x10 Пример из стандартной библиотеки - реализация type_traits. Ээээээ. Ну кагбэ Александреску всё это сделал 100500 лет назад в своей Loki. На том же cpprefernece Possible implementation почти копирует его код (ну кроме всяких remove_reference). Так что мимо. Добавлено через 6 минут Сообщение от Evg Сколько десятилетий назад провозгласили этот принцип? Примерно 40. Фортрану поболе будет. Да и Лиспу. Думаю, постарше вас. Сообщение от Evg И насколько с тех пор изменился мир? Нинасколько. Всё так же Си, всё те же яйца. Только теперь куча придурков решило: раз венда - это 90% рынка, а она только под Intel, то и нафиг все эти ваши Linux и ARM. Дружно все пишем на шарпе. Или уэб-интерфейсы. А хто самый умный, тому невероятно переносимая Java. Сообщение от Evg вообще, были ли в то время такие понятия, как "задача реального времени"? =-O Вы меня, конечно, извините, но вы вроде эксперт Си++, а морозите какую-то чушь. 0

@0x10 3257 / 2059 / 351 Регистрация: 24.11.2012 Сообщений: 4,909
	29.07.2014, 19:26	29
	Сообщение от CyberSolver ну кроме всяких Я и не сказал, что трейтсы должны быть на 100% реализованы на расширениях компилятора. Часть их используют (has_trivial_[constructor\|destructor\|etc...]) 0

@CyberSolver 102 / 75 / 17 Регистрация: 23.07.2014 Сообщений: 877 Записей в блоге: 1
	29.07.2014, 19:34	30
	Сообщение от 0x10 Я и не сказал, что трейтсы должны быть на 100% реализованы на расширениях компилятора. Вообще, про то и речь: все traits давно реализованы на чистых шаблонах уже лет 10-15 как. Здесь та же ситуация, что с Boost: творения всяких маньяков типа Александреску попадают в стандарт. (Даже странно, что в Си++11/14 не добавили сериализацию, в бусте давно есть). Так что мало того что всё это не требует никаких расширений компилятора вообще, так и возникает вопрос: а зачем вам столько информации о типах на этапе компиляции? 0

@0x10 3257 / 2059 / 351 Регистрация: 24.11.2012 Сообщений: 4,909
	29.07.2014, 19:57	34
	Сообщение от CyberSolver Это какие? http://www.boost.org/doc/libs/... uctor.html Without some (as yet unspecified) help from the compiler, has_trivial_constructor will never report that a user-defined class or struct has a trivial constructor; Просмотр всех остальных оставляю по желанию, сам не искал. Сообщение от CyberSolver Может, я дурак, но что кому неочевидно? Прикладному программисту может быть неочевидно "зачем столько информации о типах на этапе компиляции". Сходу мне придумывается оптимизация функции типа push_back: при перевыделении памяти переместить объекты из старой памяти в новую безопасно можно только если их move-конструкторы не бросают исключений. Кажется нормальным вариантом для оптимизации. 0

	30.07.2014, 06:07

@CyberSolver 102 / 75 / 17 Регистрация: 23.07.2014 Сообщений: 877 Записей в блоге: 1
	29.07.2014, 20:39	36
	Сообщение от Kastaneda Живой пример Ну вот примерно так бы и обернул, хотя бы define'ами. 0

Evg 21279 / 8301 / 637 Регистрация: 30.03.2009 Сообщений: 22,659 Записей в блоге: 30
	29.07.2014, 22:40	37
	Сообщение от CyberSolver Нинасколько. Всё так же Си, всё те же яйца Только вот процессора сильно поменялись в своём внутреннем устройстве. Если раньше достаточно было повысить частоту в два раза, после чего программа начинала работать в два раза быстрее, то сейчас это уже не так. Процессоры стали сложнее, а потому стало сложнее писать под них оптимальный код. Далеко не всегда получается это сделать на чистом языке без использования расширений. Я уж не говорю о том, что приличная доля вычислений перетекла с CPU на GPU, где чистый язык вообще мало канает Сообщение от CyberSolver Только теперь куча придурков решило: раз венда - это 90% рынка, а она только под Intel, то и нафиг все эти ваши Linux и ARM Опять-таки мало понятно, откуда ты такую ересь высасываешь. Есть конкретное приложение, работающее под вполне себе конкретной системой, к которой ставится вполне себе нехилое требование - миллион транзакций в секунду. Все доводы из разряда "жертвуй производительностью ради переносимости" идут лесом как минимум потому, что переносимость нафиг никому не нужна при такой постановке задачи. Понятно, что всегда нужно по возможности стараться писать максимально переносимый код, но когда из принципа начинает уродоваться программа из соображений "пусть в 10 раз медленнее, зато строго по стандарту", то это такой же маразм диванных теоретиков, как "программирование без goto". Сообщение от CyberSolver Вы меня, конечно, извините, но вы вроде эксперт Си++, а морозите какую-то чушь В каком конкретно месте чушь и в чём она выражается? Сообщение от uglyPinokkio В то время были ОС реального времени И что, они писались на чистом (стандартном) языке программирования без расширений? А ведь именно в контексте использования расширений и начался спор 0

@uglyPinokkio 327 / 230 / 55 Регистрация: 30.05.2014 Сообщений: 682
	30.07.2014, 06:07	38
	Сообщение от Evg И что, они писались на чистом (стандартном) языке программирования без расширений? О задачах реального времени имеет смысл говорить только применительно к ОС реального времени, а это ниша довольно специфическая. RT11 помнится была написана на ассемблере. А в целом вполне очевидно, что есть задачи, для которых производительность важнее переносимости, иначе вот этого: https://software.intel.com/sit... sicsGuide/ бы не было. 0