Баян. Модули - это одно из предложений, которое не вошло в С++11 ввиду незрелости, но планирует войти в след. стандарт.

Apple предлагает заменить #include <stdio.h> на import std;

Вечно со своей раскладушкой в наш си-шный мавзолей кто-то лезет.

уже запатентировали?

предлагаю заменить Apple на Samsung.

Презентация у них относительно неразжёванная, но я могу добавить подробностей. Сейчас XCode и Visual Studio для разбора кода в редакторе используют не какой-то быстро действующий кем-то написанный движок, а непосредственно компилятор - XCode точно использует clang, студия вроде как использует библиотеки msvc, и разбирает код ещё дольше чем XCode. А пару месяцев назад я взял и скачал ветку QtCreator с плагином, использующим clang вместо быстрой, но обречённой быть неточной нативной модели кода. И - тормоза, на i5 уходит в среднем 1 секунда на подсветку и 0,3-0,5 на автокомплит.

Визуал стодия по качеству парсера в жопе, по сравнению с тем же кдевелопом. Я когда-то пытался собрать кути/стл поделку на венде(которая была в комплекте с ноутом, пока она там была), и заодно решил зачекать «всеми любимую», «самую лучшую» визуал студию, которую я никогда в жизни не видел и не юзал - да это такое тормазящие говнецо, что на моём e6320 кдевелоп работает раз в 20-30быстрее, чем студия работала на i5-м санди, который у меня в ноуте - делаем вывод. Эта вырвиглазное, ущербное, кривое, тормазящие говнище даже рядом с nano не валялось, куда этому говну до нормального парсера и перфоманса?

kdevelop выводит идеальный комплит/подстветку намного быстрее, автокоплит из кеша(а это в 95% случаев) для тяжелого объекта(полсотни методов) - даже даже меньше 100мс, даже 50мс - я почти не замечаю этой задержки.

QtCreator, имхо ваще неок поделка. Причем я даже недавное её глядел - где-то в районе года-полугода назад. Ваще неок и фигня.

Так вот быстрая скорость разбора плюсов нужна как раз для сред разработки, а в будущем - для небольших скриптов на python для рефакторинга, которые будет писать сам программист под свои нужды. Годами на это забивали и впаривали шаблоны + кучу макросни ради оптимизаций и совместимости, пренебрегая возможностями инкрементальной компиляции и т.д., теперь эти времена заканчиваются.

Да не нужна она, просто кто-то не осилил написать нормальный парсер/анализатор и хочет захапать всё от компилятора.

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

Что касается gcc hello.c -E, clang ещё года 3 назад тестировали на реальных проектах, а не на hello.c - и получили 25% времени на препроцессинг, 25% на парсинг, и около 40-45% на генерацию кода - то есть как у вас с gcc и у меня с clang на файле hello.c. Вот только при использовании clang как тулзы обработки кода, а не как компилятора, нет этапа генерации кода, а скорость парсинга уменьшится многократно. Останется 5-10% от семантического анализа и пара процентиков на препроцессинг и парсинг.

Да не, брось. Я ещё поверю, что в сишечке 20-25% тратится на препроцесор+парсер и то с O0.

Да вот:

$ time gcc ffmpeg.c -I. -S -O2 &> /dev/null 

real    0m1.600s
user    0m1.509s
sys     0m0.088s

$ time gcc ffmpeg.c -I. -S -O0 &> /dev/null 

real    0m0.439s
user    0m0.402s
sys     0m0.035s

$ time gcc ffmpeg.c -I. -E &> /dev/null 

real    0m0.041s
user    0m0.032s
sys     0m0.007s

К сведению, ffmpeg.c - 4-5к строк до препроцессора, 18к строк после препроцессора.

Последние пару предложений я не «распарсил», никаких проблем сейчас с парсингом/препроцессингом нет, особенно в плюсах. Шланг как анализёр - да в добрый путь, но как это связанно с парсингом?

И запретят использовать любые import'ы в опенсорсных проектах.

Только вот.

Теперь я понял, но это не отменяет того факта, что парсится всё за 2-3сек и проблемы нет.

В чем проблема? Хедер - это дефайны, структуры, и прототипы функций. Никакой другой инфы там нет, а если есть - она не нужна. Препроцесор парсит+гинерит 5/ 20к строк за 30-40мс, т.е. полсекунды на 100к строк. Парсить хедер надо один раз - дальше в кеш, если про анализатор кода, в чем проблемы? Пусть это 1-2секунды на 100к строк - это не проблема, ибо 100к строк - это длинна 95% проектов.

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

А вы в курсе, что можно написать #include «/dev/tty» и подавать компилятору код в stdin? Вообще сишная система модулей изначально поломанная, странно что в крестах эту поломку сохранили.

Вот это ТОРТ! В С++ больше всего удивляет наличие Trigraph sequences, где символы формата ??= заменяются на # т.д. Это сделанно для клавиатур, где нет #, [, }, ^,~ и т.д.

Парсить хедер надо один раз - дальше в кеш, если про анализатор кода, в чем проблемы

Состояние препроцессора влияет на директиву #include. Да и не только оно, видал я такой трюк:

enum Variants {
    #include "variants.def"
};

Иногда в С++ я сам того не замечая использую and or not вместо && || ! и оно внезапно работает.

Насчёт убогости редактора кода в студии согласен (по сути, она берёт подсаживанием на иглы типа средств командной разработки и XNA, с которых попробуй потом слезь).

Вот только я не про качество редактора и не про время отзыва говорил. А про глубину анализа кода движком. Т.е. красивую картинку можно и в OpenGL нарисовать, и работать будет в реальном времени, и покупать будут с удовольствием игрушку с графикой как Dota 2 / Skyrim; но физически обоснованные эффекты получаются обратной трассировкой лучей.

Использование библиотек компилятора в среде разработки напоминает перенос вычислений на GPU - при внешней бредовости идеи она потенциально способна дать фишки, которых никогда не будет у самописных эвристических движков подстветки. Но сейчас главный недостаток - очень низкая скорость и невероятная трудность инкрементального анализа для неэвристических движков; вот и пытаются его преодолеть разными способами.

А вот список фишек, составляющих затруднение для эвристических движков

• Собственно все ошибки находятся так же и сообщения выводятся так же, как при компиляции
• Т.к. компилятор содержит огромное количество тестов и имеет огромные требования к устойчивости, то не будет досадных ошибок вроде этой, возникающих при глубокой рекурсии или нехватке памяти. Тот же clang может крахнуться, но при использовании libclang это вызовет лишь завершение того потока, в котором сама libclang запустила обработчик исходного кода.
• Автокомплит может принимать во внимание контекст кода, например в этом месте он предложит только типы:

  class Derived : public <?>
  

• Автокомплит clang очень хорошо расставляет приоритеты и может наращивать эвристику анализа приоритетов очень долго. В эвристических движках лучшее что есть - это Eclipse, который для расстановки приоритетов использует... базу предпочтений пользователей, ранее использовавших автокомплит.
• В декабре выйдет версия clang, умеющая анализировать doxygen на соответствие коду - вот статья на форониксе. Для включения нужен флаг -Wdocumentation. И ничто не мешает в будущем добавить новые стадии анализа, например спелл-чекинг в тех участках кода, для которых он требуется, а не просто всё содержимое комментариев и литералов прогонять.

В общем clang не идеален в плане API и умеет не всё, что хотелось бы, но он позволяет по-настоящему отделить IDE от движка анализа кода и получить все полагающиеся плюшки.

Интеграции уровня KDevelop нет и не будет, потому что это требует доработки самого clang, что гораздо сложнее чем написать ещё немного поддержки C++ 2011 для KDevelop в рамках Google Summer Of Code. Я писал патчи для улучшения поддержки C++2011 в QtCreator и ничего неординарного там не было.

Ах да, забыл приложить пример. Вот как «замечательно» KDevelop обрабатывает контекст автодополнения и расставляет приоритеты: скриншот. При отделении движка от среды, превращении возможностей движка в плоский API эти маленькие, но доставучие проблемы можно устранить.

Хотя QtCreator в данном конкретном месте и сейчас нормально срабатывает.

В декабре выйдет версия clang, умеющая анализировать doxygen на соответствие коду

О, это супер.

// Как в KDevelop с QML?

А что, у ядрописецев отнимут #include?

import std.stdio;
void main() {
writeln(typeid(typeof("Hello, world!")));
}

Думаете, что это из презентации яблочников? А вот и нет, это из «The D Programming Language».

Они упоролись? модуль по умолчанию у них игнорирует препроцессор стейт перед импортом. А в том же ядре до **пы хедеров которые только макросами и утыканы, которые по разному от этого препроцессор стейт работают (тот же dev_dbg, например).

Ждем комментария Линуса.

В предложении для стандарта С++ (нифига не уверен, что это Apple предлагал) модули позиционируются как альтернатива #include, но сам #include конечно же никуда не девается. Т.е. новый код в модули, старый и код с предпроцессором - в #include.

Всё правильно сделали

Господи, неужели я до этого дожил?

Отсутствие модульности - самая раздражающая вещь в C и C++. Даже по сравнению с объектным Паскалем, не говоря уже о Модуле-2 или тем более Яве с её иерархиями пакетов.

Давно пора было понять, что #include и namespace - это не модульность, а костыли для имитации оной.

Самое безобидное из следствий этой костыльности - увеличение времени компиляции. Иначе и быть не может, когда сначала препроцессор лепит несколько километровых простынь из кода и определений, потом каждая из этих простынь компилируется в файл .o с неразрешёнными именами, и финальным аккордом компоновщик пытается подобрать для каждого неразрешённого имени объект, который вроде-бы-как подходит по имени и типам.

Гораздо хуже непредсказуемость реакции компилятора на ошибку программиста, забывшего нужный #include или написавший его неправильно. Поскольку заголовочные файлы зависят друг от друга, результат компиляции одного и того же кода зависит от самого компилятора, стандартной библиотеки и фазы Луны.

Так что саму идею всецело одобряю. Другое дело - как будет решаться вопрос совместимости с тоннами старого кода.

Другое дело - как будет решаться вопрос совместимости с тоннами старого кода.

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

Не трави. Давно хочу какой-нибудь велосипед попробовать на D написать, да руки не доходят.

Я правильно понимаю, что компиляторы D дают нормальный нативный код, не завязанный на кучу runtime-говнища? И как там насчёт линковки с теми же плюсами и другими языками?

Тут найдешь ответы на эти и многие другие вопросы.

#include со скруглёнными уголками

Где мне найти игрушку, где для скриптования логики потребовались потоки в скриптах?

Например такую в которой будут _жить_ и мыслить несколько ботов, каждый в своём потоке + поток на графику + поток на коммутацию, если таких нет, то это говорит лишь о том что игры спинномозговые мультимедийные.

Т.е. новый код в модули, старый и код с предпроцессором - в #include.

Это будет жуткий зоопарк. Кроме того программист должен будет помнить, что подключать модулями, а что #include.

Например такую в которой будут _жить_ и мыслить несколько ботов

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

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

Монстр получается, хотя работать должен.