О компиляторах вообще и C/C++, в частности (компиляторы годные и не очень)

[Bizdelnick]

Мой оппонент тоже приводил ссылку на вики здесь.
И тоже русскоязычную. А мне почему нельзя?

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

Я помню, как-то запустил Borland Pascal вместо Turbo Pascal. Случайно, второпях.
И у меня чего-то там не скомпилилось. Ошибки синтаксиса нашлись. А в Turbo Pascal - нормально.
Какие-то различия были на уровне языка. То ли типы данных, то ли объекты...

См. обсуждение разных компиляторов языка C++ выше ;-)
А может, причина была не в самом компиляторе, а в библиотеках?

[Женя Подсыпальников]

Что мне у Борланду сразу понравилось -
так это, конечно, правильно настраивающая юного человека установка :

(были и ещё более романтические картинки, в ранних версиях, но не нашёл уже...)

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

[Hephaestus]

А может, причина была не в самом компиляторе, а в библиотеках?

Может. Всё может быть. Может быть даже, что это какая-то самодеятельность от Borland, нигде толком не описанная.
Но в справке, вроде, что-то упоминалось об этом. Всё-таки.

Однако, суть не в этом.
Вы привели Turbo Pascal как пример, когда одним названием величают и среду, и язык. Правильно, так и есть.
Но путаницы это не вызывало, как ни странно. Почему?
Потому что нормальные люди, в том числе нормальные авторы указывали явно, что они имеют в виду: "среда Turbo Pascal", "язык Turbo Pascal", "IDE Turbo Pascal", и т.д.
И в случае с Pascal никто не переименовывал язык посреди дела так, что в самой среде использовалось бы и старое, и новое название.
Другой пример - FoxPro. Это и название СУБД, и название среды, и название языка. И нормальные авторы, опять же, об этом говорят. Первым делом.
И в книге принимается соглашение по этому поводу - что как обозначать, и как называть в контексте.

А вот с Дельфи я такой ясности не наблюдаю.
Представьте, написал человек книгу по Дельфи 7.
И на страницах книги он везде под "Дельфи" подразумевает среду, а язык называет Object Pascal.
Проходит годика два. Появляется вот этот документ,
и если кто-то начинает пользоваться "новым" языком и "новым" названием, начинается путаница, потому что среда разработки осталась та же - Дельфи7.
Хотя по-хорошему, в момент "создания нового языка" должна появиться какая-нибудь Дельфи8, в которой языка Object Pascal уже нет, а есть язык Дельфи.

Это не Бог весть, какая страшная проблема, но для преподавателя это важно. Потому что он учит студентов.
И раз уж он в курсе этих "языковых новшеств", он должен о них сказать. Пару строк.
Хотя бы потому, что среда и язык называются одинаково, и нужно в тексте как-то их различать.
Как те добросовестные авторы, о которых я говорил выше.

[Bizdelnick]

Вы привели Turbo Pascal как пример, когда одним названием величают и среду, и язык.

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

нормальные люди, в том числе нормальные авторы указывали явно, что они имеют в виду: "среда Turbo Pascal", "язык Turbo Pascal", "IDE Turbo Pascal", и т.д.

Нормальные люди называют книги "Программирование на языке Паскаль" или "Программирование в [среде] Turbo Pascal". Или даже "Программирование на языке Паскаль в среде Turbo Pascal".

[NickLion]

g++. Что там не так?

ну значит надо багрепорт писать. См. выше.

Посмотрите, например, на этот баг, который висел более 10 лет, и который исправили аж в версии 4.7. Т.е. как минимум до версии 4.7 g++ стандарт не поддерживал хотя бы по этому флагу.
Но в принципе, g++ один из лучших в поддержке стнадарта.

это у вас чушь: нельзя быть немножко беременной. Если в стандарте Z666 прописано property, то компилятор обязан поддерживать. Иначе он не поддерживает Z666.

В стандарте C11 (не С++) ввели optional, так что в Си теперь можно быть немножечко беременной

[Женя Подсыпальников]

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

Чтобы потом студенты не сознавались, что сними работали "даром" :

[NickLion]

Вот тут возникает вопрос: Как это определить?
Как я могу узнать, отличный код генерит компилятор или плохой?

В сравнении по скорости работы и потреблению памяти с другими компиляторами. Но тут ещё 100500 настроек у каждого компилятора имеется, так что ответа простого нет. Иногда пробуют, тестируют. Можно поискать эти тесты.

Или оболочка от Борланд собирает программы по стандарту С++ или в обход стандарта. Как узнать?
Вот компилятор собрал программу. Как узнать, что он там внутри насобирал? По стандарту оно или нет?

Не встречал комплексных тестов по проверке поддержки стандарта. Конечно, у разработчиков компилеров они должны быть, но всегда может найтись какой-то новый пример, когда компилер делает что-то не то. Но тут нужно различать одно из двух:
1. Это баг в компилере и его разработчики будут править (например, был код с шаболнами, который не компилировался g++ 4.8.0, хотя компилировался 4.7.x, и потом пофиксили в 4.8.1).
2. Это "особенность" компилятора, которую фиксить не будут (тут яркими примерами служат borland'овский и microsoft'овский компиляторы, впрочем, MS в последнее время исправляется и даже поддержку C99 улучшили, убрали многие проблемы с C++).

[Женя Подсыпальников]

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

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

Так, например, некоторые разработчики твёрдо знают:
цикл "for" не отменят, а без "auto" - можно обойтись почти в 100%

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

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

[Hephaestus]

NickLion
Женя Подсыпальни...

В итоге получается, что если кто-то делает заявление в духе "компилятор X плохой, потому что не дружит со стандартом Y", то оно, вероятней всего голословно. Так?
Дело в том, что отрицательные отзывы о фирме Борланд (в частности) я видел в нескольких местах в Сети. Говорили, что их компиляторы лучше не использовать и т.д.
Но нигде я не видел аргументов типа "по стандарту должно быть так, а компилятор такой-то сделал мне эдак, вот он, зараза, не умеет стандарт".

[Женя Подсыпальников]

Не обязательно голословно, например - в контексте нового многоцелевого (платформы, ОС) приложения.
Конечно, удобнее написать один раз для одного компилятора, чем n раз для m компиляторов

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

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

[drBatty]

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

за то оно не тупило и не тормозило.

[drBatty]

Посмотрите, например, на этот баг, который висел более 10 лет, и который исправили аж в версии 4.7. Т.е. как минимум до версии 4.7 g++ стандарт не поддерживал хотя бы по этому флагу.

Код: Выделить всё

Synopsis: __cplusplus defined to 1, should be 199711L
 Priority: low
 Severity: non-critical

ну хватит вам уже буквоедством заниматься!

Но в принципе, g++ один из лучших в поддержке стнадарта.

ну наконец-то...

В стандарте C11 (не С++) ввели optional, так что в Си теперь можно быть немножечко беременной

а что смайл грустный такой?

[drBatty]

В сравнении по скорости работы и потреблению памяти с другими компиляторами

для этого надо Over9000 компьютеров с разными CPU. Такое себе может только Сообщество позволить, которое у GСС.

без "auto" - можно обойтись почти в 100%

можно. Используя нестандартные костыли и всякий быдлокод с жёстким кастом.

В итоге получается, что если кто-то делает заявление в духе "компилятор X плохой, потому что не дружит со стандартом Y", то оно, вероятней всего голословно. Так?

очевидно, тут нужен пример, типа "__cplusplus defined to 1, should be 199711L".

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

я не знаю как сейчас, но раньше там действительно такое было. Они свои фишки придумывали. Но это было давно, потому сегодня я спорить не готов. Может всё изменилось. Может -- нет. Я не в курсе, не слежу.

[Женя Подсыпальников]

Используя нестандартные костыли и всякий быдлокод с жёстким кастом.

Очень интересно... А пример - есть к этому ?

[drBatty]

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

компилятор имеет полно право как угодно (не)компилировать UB-код. К примеру, код

Код: Выделить всё

x-- - --x;

имеет полное право отправить вашей маме письмо с текстом "мама, роди меня обратно!"

Очень интересно... А пример - есть к этому ?

это вы мне продемонстрируйте, каким макаром присвоить переменной x значение хрен знает какого типа? Причём без auto и без каста скажем к void*.

[Женя Подсыпальников]

это вы мне продемонстрируйте, каким макаром присвоить переменной x значение хрен знает какого типа? Причём без auto и без каста скажем к void*.

Такого нема.
Пользую полиморфию, СОМ или типизированные API-вызовы.
А значит, наверное, нема и быдлокоду

[drBatty]

Такого нема.
Пользую полиморфию

ну вот там оно и появляется. Когда у вас есть классы Б и Ц, наследованные от А. Вам придётся делать объект А, но это бывает невозможно, если к примеру в А есть чистые виртуальные функции. Вам придётся делать какой-то метод для определения типа Б или Ц, и ветвление, что бы создать объект Б, ИЛИ объект Ц. Это всё усложняет и замедляет код.

Попробуйте например умножить матрицу на матрицу или на столбец. Очевидно, получится вв первом случае матрица, а во втором случае -- столбец. Ну и как вы это запишите? Я вот так запишу:

Код: Выделить всё

auto X = Y * Z;

Тут тип X определяется типом Z.

А вы как?

СОМ

а... Ну да.

[Женя Подсыпальников]

Вам придётся делать объект А, но это бывает невозможно, если к примеру в А есть чистые виртуальные функции. Вам придётся делать какой-то метод для определения типа Б или Ц, и ветвление, что бы создать объект Б, ИЛИ объект Ц. Это всё усложняет и замедляет код.

Не придётся делать, буду использовать ссылку ли указатель на базовый (пусть и чисто-виртуальный) объект.
Кроме того, по пути к любому интерфейсу возможен промежуточный базовый объект, его тоже не обязательно делать, а лишь ссылаться

Попробуйте например умножить матрицу на матрицу или на столбец

А нельзя определить столбец яко матрицу с одним столбцом
ли ввести класс произведения с двумя конструкторами/операторами ?

Зато везде пойдёт потом, на голом-то С++

[NickLion]

NickLion
Женя Подсыпальни...

В итоге получается, что если кто-то делает заявление в духе "компилятор X плохой, потому что не дружит со стандартом Y", то оно, вероятней всего голословно. Так?

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

[Hephaestus]

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

Это здорово, конечно. Но...
Понятно, что 100% поддержка стандарта - дело сложное и нет её ни в Борланд, ни в M$.
Но Борланд за это ругают, на чём свет стоит и не рекомендуют к использованию. А к M$ отношение прямо противоположное.
На чём-то ведь это основано.
Хотя встречал и такие высказывания: "Не люблю Борланд, сам не знаю, за что".

[Женя Подсыпальников]

Хотя встречал и такие высказывания: "Не люблю Борланд, сам не знаю, за что".

Некоторые предпочитают одну и ту же крышу репитиции и представления,
бо "горло по дороге не простудится"

[serzh-z]

это диалекты. Тоже стандарты, но не в том смысле.

_Диалекты стандарта_? =))

[drBatty]

А нельзя определить столбец яко матрицу с одним столбцом

можно, но это костыль. О чём и речь.

ли ввести класс произведения с двумя конструкторами/операторами ?

типа Matrix::Matrix(const &Vector &) ? Можно и такой костыль, кто спорит?

Зато везде пойдёт потом, на голом-то С++

отсутствие auto -- это дефект ЯП. Очевидно жеж.

Диалекты стандарта

да, а что? В русском языке 95% слов -- заимствования из жаргона и сленга. Чем сишечка хуже естественного языка? Тоже самое: сначала слово используют только в узком кругу специалистов, потом -- все. А потом оно попадает в словари и энциклопедии. А потом -- становится "исконно русским", вроде слова "крюк". В ЯП всё точно также. Этот наш "gnu++11" -- на сегодня "стандартный диалект". Я именно им и пользуюсь.

[Женя Подсыпальников]

А нельзя определить столбец яко матрицу с одним столбцом

можно, но это костыль. О чём и речь.

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

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

[yars]

Вообще-то это вполне себе язык.

Турбопаскаль - это IDE, если не ошибаюсь, язык там - ранняя реализация Object Pascal.

[drBatty]

А по-моему, так наоборот - авто - это костыль,

ИМХО нет.

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

Няня я у них поел.

[Женя Подсыпальников]

ИМХО нет.

Спросил у старших, когда у нас тут авто применяется,
сам-то - только предписание "не применять" помню , оказывается:

Зашибато, если разнотипизированные объекты шаблонного класса
возвращают разные типы одноимённой функцией.

Предписания не отменили,
но теперь ясны примеры невозможной полиморфии.

Спасибо - за наводку !

[drBatty]

Предписания не отменили,
но теперь ясны примеры невозможной полиморфии.

ну если уж совсем честно, то вообще ВСЕ фичи C++ нужно применять с огромной осторожностью. C++ это очень сильный ЯП. Ну типа как BFG-10k в Quake2. Опасность не в том, что это не заработает, опасность в том, что это заработает не так, и кому-то придётся всю ночь искать грабли, в виде вашего auto, которое вы поставили совсем не там, где это уместно. Потому что auto оно ваще-то действует на что угодно, в т.ч и на то, чего вы совсем не ожидали. В C++ полно таких интересных мест и граблей.