Великий и ужасный C++

[vak]

Что напечатает следующая программа? Компилируем посредством "clang++ -std=c++11 lol.cc -o lol".

#include <iostream>

using namespace std;

int main() {
    int lol = 10;
    int l​ol = 10;
    int l​o​l = 10;
    int l​​ol = lol + l​ol + l​o​l;
    cout << l​​ol << endl;
    return 0;
}

(отсюда)

Comments

[cross_join]

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

[ircicq]

Вариант для русскоязычного:

int abc = 10;
int abс = 10;


перепутать легко, русская 'c' на той же клавише.

[cross_join]

Классика ФИДО - замена "Н" на латинскую "аш".

[vak]

Тут clang нужен. GCC не поддерживает эту фичу.

[cross_join]

clang - это одно большое недоразумение, примерно такое же, как С++ для .NET.

[vak]

Дефолтный компилятор в MacOSX и BSD.

[cross_join]

Дефолтный для прикладников, как и .NET.

[vak]

Почему только для прикладников? Все пакеты ним собираются, включая ядро Юникса и драйверы.

[cross_join]

Под LLVM (согласно открытой информации в вики)

[vak]

LLVM и clang - два разных слова для обозначения одного и того же. Внутри LLVM нет никакой VM, и это иногда вызывает путаницу.

[cross_join]

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

[netch80]

Что в нём не нравится?

[cross_join]

То же, что и в C++.NET - наличие прокладки в виде LLVM

[netch80]

GCC тоже состоит из фронтэнда и кодогенератора, их можно отделить друг от друга (собственно, clang долго имел GCC фронтэнд). Чем кодогенератор, входное представление которого можно сериализовать и сохранить, а потом применить из сохранённого, хуже такого, с которым этого сделать нельзя?

[cross_join]

Все компиляторы имеют раздельные синтаксический анализатор и кодогенератор. Речь о конкретных реализациях.
Если clang прикрутить к кодогенератору в машкод, то получится "еще один C++", только обратно несовместимый. Нахрена он нужен, не могу представить.

[netch80]

> Нахрена он нужен, не могу представить.
1. Просто альтернативная реализация - всегда полезна хотя бы для сравнения и контроля.
2. Многим не подходит лицензия GPL, даже с исключениями. Многим - GPLv3 (поэтому GCC остался на 4.2).
3. LLVM сейчас объективно проще и удобнее для расширения и развития, чем GCC, в котором legacy в совершенно безумном объёме.

[cross_join]

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

[netch80]

> LLVM и .NET - одна ниша.

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

> Болезнь развертывания и дополнительного слоя зависимостей не лечится, ибо заложена в приципе.

Какая нафиг "болезнь развертывания и дополнительного слоя зависимостей", если clang в обычном режиме просто собирает объектники и бинарники? Вы его вообще хоть раз запускали?

[cross_join]

Пущай собирает. Легаси-код он присобрать не может.
А про новые проекты я уже сказал.

[netch80]

> Легаси-код он присобрать не может.

K&R? А где он вообще остался?

> А про новые проекты я уже сказал.

Настолько сумбурно, что ничего не ясно.

[cross_join]

Какой K&R??
На С++ за 30 лет написано столько библиотек, включая стандартную, что K&R тут вообще не при делах.
У меня, например, есть выбор между старым bcc32 и новым сlang. И с новым я практически ничего не могу сдкелать, только начинать с нуля переписывание миллиона строк.