LINUX.ORG.RU

Модули... модули? Какие модули?!

 ,


0

5

Привет, ЛОР!

Решил я тут взять C++ для одного своего маленького проекта. Давно ничего сложнее багфиксов в старый код не писал на этом языке по причине его особой не нужности, но тут подумал: «Почему бы и нет?» Естественно, хочу C++ со всеми последними вкусностями, в частности нормальными модулями.

Скажи, ЛОР, как эти модули вообще использовать? Если в рамках моего проекта всё примерно понятно, то использование модулей из сторонних библиотек вызывает много вопросов. Стандартная библиотека, как я понимаю, в модули до сих пор не обёрнута?

Компиляция вот этого примера падает с кучей странных ошибок:

import <iostream>;
import <string>;

std::string s = "Hello World";

int main(void)
{
  std::cout << s << std::endl;
}
$ g++ -std=c++2b -fmodules-ts mod.cc -o mod
In module imported at mod.cc:1:1:
/nix/store/z9jxhrbxm5lxrjpia9xcqjgk990ffr2j-gcc-11.1.0/include/c++/11.1.0/iostream: error: failed to read compiled module: No such file or directory
/nix/store/z9jxhrbxm5lxrjpia9xcqjgk990ffr2j-gcc-11.1.0/include/c++/11.1.0/iostream: note: compiled module file is ‘gcm.cache/./nix/store/z9jxhrbxm5lxrjpia9xcqjgk990ffr2j-gcc-11.1.0/include/c++/11.1.0/iostream.gcm’
/nix/store/z9jxhrbxm5lxrjpia9xcqjgk990ffr2j-gcc-11.1.0/include/c++/11.1.0/iostream: note: imports must be built before being imported
/nix/store/z9jxhrbxm5lxrjpia9xcqjgk990ffr2j-gcc-11.1.0/include/c++/11.1.0/iostream: fatal error: returning to the gate for a mechanical issue
compilation terminated.
$ 
$ clang++ -std=c++2b -fmodules-ts mod.cc -o mod
mod.cc:1:8: error: header file <iostream> (aka '/nix/store/dlni53myj53kx20pi4yhm7p68lw17b07-gcc-10.3.0/include/c++/10.3.0/iostream') cannot be imported because it is not known to be a header unit
import <iostream>;
       ^
mod.cc:2:8: error: header file <string> (aka '/nix/store/dlni53myj53kx20pi4yhm7p68lw17b07-gcc-10.3.0/include/c++/10.3.0/string') cannot be imported because it is not known to be a header unit
import <string>;
       ^
mod.cc:4:1: error: use of undeclared identifier 'std'
std::string s = "Hello World";
^
mod.cc:8:3: error: use of undeclared identifier 'std'
  std::cout << s << std::endl;
  ^
mod.cc:8:21: error: use of undeclared identifier 'std'
  std::cout << s << std::endl;
                    ^
5 errors generated.

GCC и Clang почти последние: 11.1 и 12.0.1. Выходит, модули не работают? Что делать, ЛОР? Отложить C++ до лучших времён?

★★★★★

Последнее исправление: hateyoufeel (всего исправлений: 2)

Ответ на: комментарий от alysnix

тогда компилятору нужен лишний проход только для компиляции определений, как минимум…

Учитывая, сколько проходов уже нужно для компиляции C++, это не так страшно.

простоте компилятора

C++

Ну чувак, ну…

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Так, для дискуссии …

Ныне вот в C++ активно добавляются возможности мета программирования во время компиляции.
По существу это генерация нового кода.
И что это за «метаданные», которые в run-time не доступны?

anonymous
()
Ответ на: комментарий от hateyoufeel

Ну чувак, ну…

я не про с++ :)

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

alysnix ★★★
()
Ответ на: комментарий от hateyoufeel

Учитывая, сколько проходов уже нужно для компиляции C++, это не так страшно.

если не трогать темплейты - то вроде двух и хватит.

да вроде и на темплейты доп. проход не нужен.

alysnix ★★★
()
Ответ на: комментарий от alysnix

я не про с++ :)

А про что? Потому что из активно развиваемых языков, я не припомню ни одного кроме C/C++, где взаимно рекурсивные функции или типы требовали бы предварительного объявления.

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

да вроде и на темплейты доп. проход не нужен.

Да там второй проход вообще никогда не нужен, на самом деле. Сейчас не 1971, а твой комп — не PDP-11 с 4кб памяти. AST можно и в памяти держать.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Многопроходной компилятор, представь какой ад ты предлагаешь:

//any external library qq.hh
void fn(int) {}
void call() {fn(5.0);}

//user code
#include <qq.hh>

void fn(double) {}
int main() {call();}
kvpfs ★★
()
Ответ на: комментарий от alysnix

если не трогать темплейты -

то ты компилируешь С.

Siborgium ★★★★★
()
Ответ на: комментарий от hateyoufeel

не PDP-11 с 4кб памяти

С 32кб.
При этом добротный компилятор с Pascal отжирал не более 16KB.
Нынешние компьютера с 3000 раз более быстрыми процессорами сильно то не выигрывают ни в разработке ни в компиляции, ни …

А теоретически - ДОЛЖНЫ!
anonymous
()
Ответ на: комментарий от hateyoufeel

Да там второй проход вообще никогда не нужен, на самом деле. Сейчас не 1971, а твой комп — не PDP-11 с 4кб памяти. AST можно и в памяти держать.

понятно, что второй проход уже не по тексту, а по дереву.

alysnix ★★★
()
Ответ на: комментарий от alysnix

понятно, что второй проход уже не по тексту, а по дереву.

Да нет там все много более хитро.
Об этом были статьи в inet …

anonymous
()
Ответ на: комментарий от anonymous

Нынешние компьютера с 3000 раз более быстрыми процессорами…

… компилируют зеро-кост-абстракции

anonymous
()
Ответ на: комментарий от anonymous

Да нет там все много более хитро.

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

alysnix ★★★
()
Ответ на: комментарий от kvpfs

Родной, ты бы вылез из криокамеры, может бы и про неймспейсы узнал.

anonymous
()
Ответ на: комментарий от anonymous

Почитайте https://docs.microsoft.com/ru-ru/cpp/build/reference/file-types-created-for-visual-cpp-projects?view=msvc-160 типы файлов, создаваемые для проектов Visual Studio C++

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

Ю ну и какое отношение это имеет к модулям? это всякая вспомогательная бурда, …

Так ваши посты тоже не о модулях …

anonymous
()
Ответ на: комментарий от anonymous

Всегда придерживаюсь при разработке следующего суждения

Где просто, там ангелов со ста.  
Где мудрено там ни одного!
anonymous
()
Ответ на: комментарий от anonymous

c++ для нового проекта имеет смысл выбирать только чтобы поржать над c++

Недальновидно использовать новомодные rust, go или даже хипстерский haskell. Если свой прожект в стол, то пожалуйста! Если пытаться построить бузинес, то глупо.

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

В этом смысле, С++ имеет гораздо меньше рисков. Риски на несколько порядков ниже. А иначе будешь с тем же rust или go сосать потом лапу. А что касается языка, современный С++20 не так и плох, совсем даже неплох.

Да, и с переносимостью на новые или редкие архитектуры возникнут у тебя большие проблемы, если это не C++, не C и не Фортран. Тогда можно будет пососать уже вторую лапу.

Удачи!

anonymous
()
Ответ на: комментарий от anonymous

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

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от kvpfs

Почему? -Werror решает эту проблему у меня. Если тебе нравится говнокодить, я тебе не мешаю никак.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

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

anonymous
()
Ответ на: комментарий от hateyoufeel

Почему? Ждать 10 лет после выхода стандарта – это как-то очень странно.

Использовать молоток, который изменяется в руке, — это не только странно, но и травмоопасно.

slackwarrior ★★★★★
()
Ответ на: комментарий от kvpfs

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

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

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

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

Ну в чём-то ты прав, но не учитываешь кое-что: 100К строк плюсового кода компилятся секунд 30, если мы обернули стд и внешние либы в модули, то можно сказать, что все эти 100К строк под твою писанину. Много у тебя таких проектов где ты руками наколотил столько?

Я ведь модули не отрицаю совсем, это следующий уровень абстрации над обычными хидерами.

kvpfs ★★
()
Ответ на: комментарий от Pavval

С модулями такого не будет.

Чойта не будет? будет перекомпилироваться по дереву зависимостей модулей друг от друга.

alysnix ★★★
()
Ответ на: комментарий от kvpfs

Много у тебя таких проектов где ты руками наколотил столько?

На моей работе - да.

Pavval ★★★★★
()
Ответ на: комментарий от alysnix

Чойта не будет? будет перекомпилироваться по дереву зависимостей модулей друг от друга.

Только если интерфейс модуля изменился. А не на любой чих.

Pavval ★★★★★
()
Последнее исправление: Pavval (всего исправлений: 1)

А что там в комитете про модульный std, кто-то знает? Планировали в 23-м, но в bad^W trip report’ах незаметно ничего про это. Да и вообще как-то тухло с прогрессом.

anonymous
()
Ответ на: комментарий от Pavval

Только если интерфейс модуля изменился. А не на любой чих.

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

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

и где отличие от хидеров?

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от Pavval

Только если интерфейс модуля изменился. А не на любой чих.

А если модуль экспортирует функцию, помеченную для inline, и её тело поменялось? Она не помечена, но компилятор решает её всё равно заинлайнить?

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от alysnix

вообще плюсы должны были сделать «продолжение» класса.

типа в хидере ты пишешь

class A{
public:
  int f();
}

а в файле реализации можно класс «дописать» типа

continue class A{
  int ff();
  void fff();
  ...
}

то есть присоединить к классу новые функции, но не переменные.

тогда снаружи видна только f(),

а внутри - f(), ff(), fff(). и не надо лишние методы выкладывать в хидер.

alysnix ★★★
()
Ответ на: комментарий от alysnix

и не надо лишние методы выкладывать в хидер.

А если выкинуть хидеры совсем, то никакие методы туда не надо будет выкладывать и всё будет работать.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

А если выкинуть хидеры совсем, то никакие методы туда не надо будет выкладывать и всё будет работать.

А объявления структур, … куда девать?

anonymous
()
Ответ на: комментарий от hateyoufeel

А если выкинуть хидеры совсем, то никакие методы туда не надо будет выкладывать и всё будет работать.

я не про «выкинуть хидеры».

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

alysnix ★★★
()
Ответ на: комментарий от anonymous

А что там в комитете про модульный std, кто-то знает? Планировали в 23-м, но в bad^W trip report’ах незаметно ничего про это. Да и вообще как-то тухло с прогрессом.

Бьярне, Габриэль(Gabriel Dos Reis) и Кэмерон(Cameron Dacamara) работают над этим:

http://open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2412r0.pdf

вот небольшой обзор модулей: https://youtu.be/YcZntyWpqVQ

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от alysnix

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

Не улучшила бы. Основная проблема хидеров: они тупо копируются во все файлы, где они включены, пофиг напрямую или черед другой хидер. В результате у тебя один и тот же код парсится и собирается 100500 раз. И если в обычном C это ещё терпимо, то в C++, где ВНЕЗАПНО есть встроенный функциональный крайне паршиво оптимизированный недоязычок, выполняемый по время компиляции, сборка превращается в медленный ад. Добавь к этому популярность header only библиотек, которые ЦЕЛИКОМ мать его на шаблонах.

Тут вот любят ругать другие языки – дескать, они жрут много. У меня был опыт перепиливания лапши на шаблонах, чтобы заставить её собираться на 32-битных платформах. GCC при сборке этой лапши вылезал за 4 гига на одном файле и радостно дох. Такие дела.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

У меня был опыт перепиливания лапши на шаблонах, чтобы заставить её собираться на 32-битных платформах. GCC при сборке этой лапши вылезал за 4 гига на одном файле и радостно дох

модули от «лапши на шаблонах» не спасут. шаблоны все равно инстанциируются в точке применения, и надо их тащить хоть в текстовом, хоть в промежуточном, представлении в эту точку.

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

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

это про рантайм скорее всего. когда хеловорд получается в десяток мегабайт со сборкой мусора и рефлексиями всякими.

alysnix ★★★
()
Ответ на: комментарий от alysnix

модули от «лапши на шаблонах» не спасут. шаблоны все равно инстанциируются в точке применения

Частично спасут, если везде используется какой-то общий инстанс шаблона. Сейчас это вроде никак не кэшируется.

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

Да нет. Это просто C++ сосёт. Шаблоны в плюсах – обыкновенный параметрический полиморфизм. Только, в отличие от других языков, в плюсах он сделан крайне через жопу. Тут можно было бы сделать по-человечески, но это может сломать совместимость, на которую плюсисты так яростно наяривают. Плюс, нужно чтобы комитет собрался и одобрил эту идею, а потом ещё нужно подождать 10 лет пока её таки включат в стандарт и запилят в компиляторах.

это про рантайм скорее всего. когда хеловорд получается в десяток мегабайт со сборкой мусора и рефлексиями всякими.

Ну да, это про рантайм. Рантайм компилятора. Или компилятор – это не программа, по-твоему?

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Шаблоны в плюсах – обыкновенный параметрический полиморфизм.

хорошо, что не утиная типизация ad-hoc-полиморфизм

anonymous
()
Ответ на: комментарий от anonymous

хорошо, что не утиная типизация ad-hoc-полиморфизм

Ad-hoc – это концепты :DDDD

Хотя они тоже через шаблоны сделаны…

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Шаблоны в плюсах – обыкновенный параметрический полиморфизм.

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

anonymous
()
Ответ на: комментарий от hateyoufeel

Ну да, это про рантайм. Рантайм компилятора. Или компилятор – это не программа, по-твоему?

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

alysnix ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.