D as a Better C

Ты даже не можешь описать толком что хочешь. Был упомянут питоновский модуль, я показал системный пакет с ним. Его бы я и поставил, а не хрен знает что pip'ом. Дальше сам, я понятия не имею вообще что это за hash и как называется оригинальный сишный проект.

Ты даже не можешь описать толком что хочешь.

Могу (и описал). Я хочу сишную библиотеку с jenkins hash.

Был упомянут питоновский модуль, я показал системный пакет с ним. Его бы я и поставил, а не хрен знает что pip'ом. Дальше сам, я понятия не имею вообще что это за hash и как называется оригинальный сишный проект.

Это обычная хеш-функция. Сишная реализация — в википедии и на сайте автора, потому что header-only, пакет под все дистрибутивы ему делать лень. В питоновом же репозитории лежит уже готовый модуль, который можно либо pip'ом поставить, либо опакетить.

Новый GCC врубает оптимизации и выясняет, что у тебя каждый элемент массива меньше 1024. Шоп этого избежать, нужно сделать volatile. Но тогда у тебя будет два memory access к indexes вместо одного. Однако, можно сделать вот так:

#define _GNU_SOURCE

#include <limits.h>
#include <stdio.h>
#include <time.h>
#include <fcntl.h>
#include <unistd.h>

#define SEC_TO_NSEC(x) ((x) * 1000000000U)
#define RND_SIZE (1024)

int main(void) {
    int                   fd;
    volatile unsigned int indexes[RND_SIZE];
    volatile size_t       array[1024] = {0};
    struct timespec       t1 = {0};
    struct timespec       t2 = {0};

    if ((fd = open("/dev/random", O_RDONLY)) == -1)
    	    return 1;

    if (read(fd, (void *)&indexes, sizeof(indexes)) == -1)
    	    return 1;

    for (size_t i = 0; i < RND_SIZE; i++)
        indexes[i] = indexes[i] % 1024;

    clock_gettime(CLOCK_MONOTONIC_RAW, &t1);
    for (size_t i = 0; i < 1000000000; ++i) {
        int a = indexes[i % RND_SIZE];
#ifdef BOUNDS
        if (a >= 1024)
            return 1;
#endif
        array[a] = i;
    }
    clock_gettime(CLOCK_MONOTONIC_RAW, &t2);

    printf("time = %luns\n",
           (SEC_TO_NSEC(t2.tv_sec) + t2.tv_nsec) -
           (SEC_TO_NSEC(t1.tv_sec) + t1.tv_nsec));

    return 0;
}

Результаты:

$ gcc -Wall -Wextra -std=c11 -O2 -DBOUNDS -o bounds test.c
$ gcc -Wall -Wextra -std=c11 -O2          -o no-bounds test.c
$ ./bounds   
time = 664032235ns
$ ./no-bounds
time = 673871646ns

С этим припеваючи живут десятки репозиториев из десятков тысяч пакетов.

man Dependency hell

BSD?

Шутки ниже плинтуса.

man Dependency hell

Я повторяю: припеваючи живут десятки репозиториев из десятков тысяч пакетов

Я повторяю: припеваючи живут десятки репозиториев из десятков тысяч пакетов
припеваючи

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

Вот уж мимо так мимо.

Вот уж мимо так мимо.

Окей. Я вот считаю, что так себе там припеваюче. Но это мелочи. Ты по коду сверху (с моими правками) что-нибудь сказать можешь? Я не вижу там 30% дропа.

Ты по коду сверху (с моими правками) что-нибудь сказать можешь?

Могу сказать только что ты скорее всего подвираешь, ибо на gcc 7.2.0 дроп хоть и меньше, но всё ещё дохера. Это мой код, безо всяких volatile.

% gcc7 -v
gcc version 7.2.0 (FreeBSD Ports Collection)

% gcc7 -O2 1.c && ./a.out         
time = 839573938ns
% gcc7 -O2 -DBOUNDS 1.c && ./a.out 
time = 981204552ns

Могу сказать только что ты скорее всего подвираешь,

Ну я тебе только что вывод запостил.

Это мой код, безо всяких volatile.

Запусти мой :)

HINT: У меня меньше memory access'ов к indexes[] за счет кеширования результата indexes[i % RND_SIZE]. Судя по всему, это окупается.

Что самое смешное, clang все ещё тормозит. Судя по asm коду, он один хрен зачем-то генерит два обращения к массиву.

P.S. gcc-4.9 выдает такие же цифры на моем коде, как и 7.1.

половина boost header-only если не нужны os специфичные вещи а-ля многопоточности, filesystem и прочего то пересобирать вообще ничего не надо

C’s longstanding issues

preprocessor

Сам такой.

но он же тормоз, он вынуждает оптимизировать и анализировать одни и те же определения (особенно, если в заголовочнике есть inline функции) кучу раз, если бы были модули(которые были бы уже в виде ast понятного компилятору), то скорость компиляции бы возросла.

Ты потри его немножко, станет твердым как картошка! :)

Я не спорю, что стало бы лучше. Но это конкретно проблема #include, нет? И это пытаются исправить всяким дерьмом, типа прекомпилированных хедеров. А препроцессор, между прочим, не только из #include состоит.

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

Тот же часто повторяющийся код можно спрятать под макросы и генерировать код на ходу.

И тут выясняется, что у всех разная система сборки, разный механизм передачи CFLAG'ов и прочее.

дык, есть стандарт. CFLAGS и ничего лишнего. как раз в автотулзах всё довольно однозначно. это потом расплодилась куча разных систем сборки. но в любом случае файлы для автотулзов с проектом должны поставляться (либо их пишут майнтейнеры пакетов в дистрибутивах, хотя это задача самого разработчика). всякие сконсы - это у себя дома, на коленке. хочешь выпускать библиотеку в мир - потрудись написать нормальные файлы для стандартной сборки. в этом плане как раз единообразие достигается очень просто. и хедер-онли проблем не вызывает, если написан грамотно и не надо каждый раз включать кучу разных файлов. с хэдер-онли вообще нет проблем. а вот за локальный копипаст хэдеров надо руки отрывать. потому что в системе должны быть единые хэдеры, а не у каждого своя копия разных версий. а то насобирают фигни, а потом начинают ныть, что «что-то не работает».

разруливание макросов препроцессором безболезненно, и не влияет на построение ast. в Java несилен, но разве

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

не решается подсовыванием пустого пакета с реализацией интерфейса рекламного api.

Тот же часто повторяющийся код можно спрятать под макросы и генерировать код на ходу.

Что ещё более замедлит компиляцию т.к сначала придётся их свернуть в блок кода а потом его ast оптимизировать если это в разных объектыных файлах то всё печаль(что можно устранить только на lto, что само по себе замедляют сборку)

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

Предкомпилированные хидеры уг т.к зависят от настроек компилятора и содержат по сути бинари. Модули же предполагают что они содержат только interface part c описаниями функциями + ast для компилятора(1 и тот же модуль будет и в debug и в release )

В идеальном мире так бы все и было. В реальности имеем зоопарк.

А потом тебе в попец я присуну огурец.

в общем, резюмируем: D не взлетел, победить С++ не удалось, поэтому мы придумали новый язык из обрезков и будем бороться с С. но название менять не будем, чтоб все думали что это перемога

не решается подсовыванием пустого пакета с реализацией интерфейса рекламного api.

Нет. Делать мне ещё нечего стабы лепить повсюду.

Что ещё более замедлит компиляцию т.к сначала придётся их свернуть в блок кода а потом его ast оптимизировать если это в разных объектыных файлах то всё печаль(что можно устранить только на lto, что само по себе замедляют сборку)

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

впилить модули != выпишите препроцессор. Я прекрасно знаю что он может быть нужен для конкатенации токенов/условной компиляции/генерации compile-time expressionов. Но все это не оказывает нагрузку на этапе компиляции т.к не идёт в код, как ты и сказал. А оказывает как раз код из header который бы и неплохо себе сидел в модуле.

Возможно, в таком ключе это было бы неплохо, что ускорило бы компиляцию. Но кто сделает клон Си, только с выносом объявлений функций и типов в модули? Теперь помечтаем, и представим что так и есть. Как IDE должен догадаться, что объявляет конкретный модуль? Для этого он должен быть в каком-нибудь формате, но Си как-никак, единственный язык, который абстрагируется от всего, что может быть хоть немного platform-dependent. Конечно, можно переложить такое на компилятор, но здесь это не работает. Си не имеет ни одного компилятора, который можно было бы назвать эталоном.

Притом, у #include всё равно есть свои преимущества. Поскольку, он поставляет содержимое файла, можно вынести множество объявлений использующий некий макрос, а этот макрос описывать при его включении так, как это необходимо в некой ситуации. :)

Странная штука какая-то. Я к D с симпатией отношусь, многое мне в нём нравится даже больше чем в расте, но вот такие метания удивляют: выглядит как отчаянный поиск ниши. Так понимаю, что этот режим «просто» отключает часть рантаймовой фигни - это полезно, но (очередная) попытка представить это как замена С выглядит слегка притянутой за уши.

D активно используют такие конторы, как, например, Facebook

Так уж активно?

надо ещё подумать и понять о последствиях

Разумеется, ты подумал и сейчас нам расскажешь, так?

Я не ANSI и не архитектор языка. Но введение модулей как минимум приведёт к новой версии стандарта, теоретической замены некоторых стандартных библиотек на модули, это уже ого-го. Я не задумывался об этом по серьёзному, врать не стану. Но сам посуди, добавить в С модули и ничего не поломать это сверхзадача. Если решат и решат безболезненно, то хорошо. Если не решат то тоже хорошо. Я, не , вижу, надобности, модулей в Си. Что они дадут?

Я, не , вижу, надобности, модулей в Си.

OK.

А ты многословен, дал бы пищу для размышлений парой слов. Если я не вижу это не значит что они ненужны. Скажешь мне хоть пару доводов в их необходимости или при их наличии упрощения жизни разработчика?

Так ведь даже в этой теме оно было. Более того, ты сам ответил на эти аргументы в духе «зачем расписывать только плюсы, надо посмотреть и на минусы».

Тьфу ж ты, да ты прав, но это когда было то. Я уже и забыл, а топик снова пересматривать лень.