А потом на

import org.c.std;

предлогает

предлагает же.

А зачем? Что это изменит?

import std.math;
import std.vector;

Примеры из презентации. Аргументируют это тем, что это поможет ускорить скорость компиляции. Например для

#include <iostream>
int main(void)
{
  std::cout << "Hello world" << std::endl;
}

cast kernelpanic

Ну можно время компиляции сократить. А вообще идея хорошая, фреймворки Маковские крайне хороши и удобны для разработки. Достаточно компилятору путь до фреймворка указать и он сам разберется, это удобнее, чем с pkgconfig шаманить.

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

Ждем, когда они запилят это в llvm (ну и добавление поддержки в cmake и emacs).

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

uses std; круче.

trollface

а потом пойти в суд и требовать такого префикса везде import com.apple.inc

ещё патент выкапают который получили лет 10 назад.

Беспокоит лишь то, как именно они собираются это делать

// module.map
module std {
  module stdio { header "stdio.h" }
  module stdlib { header "stdlib.h" }
  module math { header "math.h }
}

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

Надеюсь еще Страуструп и Ко. не отвернут свои носы от этого.

Ну на самом деле это на вид похоже на pkgconfig на стероидах. Да и тут в модулях ничего не говорится о том, как же эти самые либы подключать.

Похоже, что старым добрым -I

Вам не нравилась отладка кода на Си? Вы еще это не видели!

То есть на линуксах эта хрень явно будет в паре с pkgconfigом работать, а на виндах как всегда через жопу. Плюс еще непонятно что делать со всякими конструкциями типа LIB_EXPORT и прочими дефайнами, от которых зависят подключаемые хедеры. То есть тут определенно надо что-то с линковкой делать. Старый добрый -l напарывается с разбегу на грабли.

Скорей, это её чуть упростит.

Надеюсь еще Страуструп и Ко. не отвернут свои носы от этого.

Ну, nvidia сделала свой диалект С - CUDA. Скорее всего, это тоже станет диалектом в llvm, мэйнстримом не станет.

расскажите им про precompiled headers

Плюс еще непонятно что делать со всякими конструкциями типа LIB_EXPORT и прочими дефайнами, от которых зависят подключаемые хедеры. То есть тут определенно надо что-то с линковкой делать. Старый добрый -l напарывается с разбегу на грабли.

Если cmake научится с этим работать - никаких проблем не будет.

расскажите им про precompiled headers

Они про них знают:

Precompiled headers are a terrible solution

а перечисление недостатков для Ъ будет?

Интересно? Значит скачайте презентацию, пересказывать всё, что там написано глупо.

там tldr, и кроме того не написано почему /Precompiled headers are a terrible solution/

Чем? Тем, что вместо простых как молоток хидеров будет очередная абстракция?

uses std; круче.

Удваиваю. А еще begin и end; вместо непонятных фигурных скобок. И точкой завершать обязательно.

Что ж ты такой умный на простом как молоток ассемблере не кодишь?

Лучше без begin и без точки (c) lua

#define uses(_H) #include <_H.h>
#define begin {
#define end }

нащет точки надо подумать

Лучше без begin и без точки (c) lua

На котором нет потоков и все числа double - с таким упрощением слон превращается, превращается слон - в элегантного кабана.

они переизобрели D, или просто прочитали про него ?

Это всё можно выразить в двух словах: «clang тормозит».

будем посмотреть, может что и хорошее родят

Хороший предкомпилированный заголовок ускоряет повторный разбор в 3-10 раз, а в современных условиях возникли ситуации, когда надо в 100. Инкрементальную компиляцию поцоны пока не осиливают.

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

Нипонятно.

Все 87страниц не осилил, после 20-30стало скушно.

Выводы:

Про ускорение:

$time gcc hello.c -S

real    0m0.018s
user    0m0.012s
sys     0m0.003s

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

real    0m0.008s
user    0m0.003s
sys     0m0.005s

$cat hello.c 
#include <stdio.h>
int main(void) {
    fprintf(stdout, "Hello, World\n");
}

Это так блин ваще медленно, всего-то компиляция сократится на 0.1-0.3%. Хотя возможно плюсовая шаблонная каша будет долго тупить.

Профитов невижу, удобства тоже.

А если в заголовочнике нет пространства имен, а тупо лежат классы/функции? Как они предлагают импортировать?

И, что самое плохое, они предлагают синтаксический сахар, который сломает совместимость.

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

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

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

Во-первых они предлагают несколько вариантов реализации, один из которых совместимость не ломает, а фактически даёт компилятору указания, как заголовки превратить в модули. Во-вторых модули предлагались как часть C++ 2011, но не вошли - и детали не додумали, и авторам компиляторов решили не добавлять работы.

Видимо авторы clang решили немного ускорить события и представить публике годную реализацию модулей до стандарта C++ 2017. В принципе оправданно, сейчас компилятора серьёзных осталось только 3, и два из них опенсурсные, модули реализуют без проблем. MS с их лозунгом going native придётся тоже пойти следом за gcc/clang.

скорость парсинга уменьшится многократно

Ой, опечатался. Время парсинга уменьшается многократно при использовании модулей - т.к. вместо 100.000 строк придётся разобрать 1-2 тыс., а импортированные модули будут дёргаться уже на этапе семантического анализа из заранее готового кеша.

А какие минусы?

Не в том месте, на компиляции он быстрей.

Размер iostream в 10 раз больше stdio.h

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

Они изобрели D?

Футуристический вариант шикарен — модули выглядят почти как в Java.

Не трожь С!

Хороший язык, нечего его в говнопитон превращать!

А чем это лучше precompiled headers?

Они изобрели Модулу.

Они изобрели Модулу.

Не, они хотят запатентовать Модулу :)

Да падет на них проклятие Святого Никлауса :)

а перечисление недостатков для Ъ будет?

Тот самый, главный и фатальный.