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

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

0

0

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

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

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

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

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

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

0

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

0

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

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

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

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

0

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

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

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

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

0

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

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

0

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

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

0

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

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

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

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

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

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

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

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

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

0

Сообщение от CyberSolver ну кроме всяких

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

0

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

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

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

0

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

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

0

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

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

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

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

0

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

Это какие?

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

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

0

Сообщение от 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

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

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

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

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

0

Сообщение от Kastaneda Живой пример

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

0

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

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

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

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

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

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

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

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

0

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

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

0