в любом случае 95% include-директив в моем примере генерируются, так что с этим проблем не будет

🤔

Так что придётся mv iostream impl/iostream echo "import std.iostream\n#pragma once" >iostream ???? sed -i 's/include/import/g' impl/iostream ???? make module iostream from impl/iostream И разбираться с проблемами

а этого я не знал

ну там видимо проблема, что непонятно, откуда цеплять

но ведь импортировать и инклюдить одновременно смысла нет?

но ведь импортировать и инклюдить одновременно смысла нет?

портировать все или ничего

в любом случае 95% include-директив в моем примере генерируются, так что с этим проблем не будет

когда фича дает благо, то я бы не стеснялся говорить и о 146%

но ведь импортировать и инклюдить одновременно смысла нет?

Нет, но при большой кодовой базе и сторонних библиотеках это случится

портировать все или ничего

Вот это проблема. Перейти плавно будет практически невозможно.

ну только подменяя заголовочный файл на файл импортирующий модуль (как в псевдокоде выше)

Так что придётся mv iostream impl/iostream echo "import std.iostream\n#pragma once" >iostream ???? sed -i 's/include/import/g' impl/iostream ???? make module iostream from impl/iostream И разбираться с проблемами

В моей уютненькой MSVCPP у меня всё std проходит через stdafx, который дергает общий для всех проектов заголовочный файл

Интересно, а импорт модуля можно же include-нуть?

Интересно, а импорт модуля можно же include-нуть?

Да :)

Да :)

Ну вот, std я уже подключил во всех файлы как модуль)

А в какой точке происходит запись инстанцированных шаблонов?

Она привязывается к импортирующему модулю?

ох

Или все-таки к экспортирующему?

Это детали реализации.... тут уж кто во что горазд и у кого получится лучше. У MSVC есть единое место для хранения инстансов, у GCC нет

Это детали реализации.... тут уж кто во что горазд и у кого получится лучше. У MSVC есть единое место для хранения инстансов, у GCC нет

Хм... то есть инстанцирование в разных модулях одного шаблона по-разному всё еще no-diagnosis ODR violation?

А что происходит с inline-функциями/переменными? Их экспортирует модуль?

А что происходит с inline-функциями/переменными? Их экспортирует модуль?

Хм... вроде, да, у него же выбора нет

У меня пока получается что-то вроде идеи свалить весь код в один большой .cpp файл 😆

Что это по-сути вот так работает

В некоторых языках все гораааздо хуже

Ну а если перегрузить на базовый тип

Вопрос по cmake, есть решение лучше для такого случая? # Find VTK # Maybe we set VTK_DIR location set(_VTK_DIR ${VTK_DIR}) find_package(VTK 8.0 QUIET) if(NOT VTK_FOUND) # Restore VTK_DIR (CMake overwrites it) set(VTK_DIR ${_VTK_DIR}) find_package(VTK 7.0 REQUIRED) endif() Проблема в том, что find_package не будет работать с разными major-версиями. Нельзя задать что-то вроде: ">=7.0", если просто указать "7.0", с "8.0" будет ошибка при конфигурировании, типа "найдена версия 8, но требуется 7".

CMake Error at CMakeLists.txt:92 (find_package): Could not find a configuration file for package "VTK" that is compatible with requested version "7". The following configuration files were considered but not accepted: C:/B/VTK/VTKConfig.cmake, version: 8.0.1 Как-то так.

не указывай версию

find_package без версии

а уже потом как найдешь, ругайся

если она не в списке допустимых

find_package(VTK REQUIRED) а потом проверяй версию, если надо

:)

Разумно! Попробую, спасибо!

#cpp #cxx #book #books #nopiracy #practical #design #architecture

А почему собственно нет?

Вот только язык делает implicit срезку

Если я написал утюг == сковородка мне нужно специально уточнять, что не нужно сравнить два кухонных прибора

Угу, а теперь утюг и сковородка наследуют кухонный прибор, который можно сравнить

Ну не знаю, в стандартной библиотеке 146 примеров, когда для не final класса определено ==

Например, для std::vector, std::string

Публично наследуют, а кухонные приборы сравниваются по наличию ручки

Да, только теперь любые потомки std::vector можно сравнить как std::vector

А что мне мешает это делать?

Например, чтобы стандартные функции интегрировать, вроде сортировки с непараметрическим компаратором

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

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

Первый из них это std::vector<int> в чистом виде с определенным сложением, второй это первый плюс отрезок

Ну вот вам пример. Я должен вектор композировать?

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

сравниваем верхний левый угол и нижний правый

как обычно

Адрес вершины в дереве это вектор из номеров вершин на пути от корня до нее. Как мне определить тип адреса вершины?

если они совпадают, то неважно, квадраты мы сравниваем, или прямоугольник с квадратом

А что с типом делать?

Если я создам об\ект класса "прямоугольник" и запишу ему width такой же кк height, он почему-то средствами языка вдруг не станет объектом класса "квадрат"

Вот беда

Ну квадрат и прямоугольник плохо, надо квадрат и круг

Которые подозрительно имеют общий тип "шары в метрике"

Всем привет

Адрес вершины в дереве это вектор из номеров вершин на пути от корня до нее. Как мне определить тип адреса вершины?

Илья, вот вам вопрос

Единственное отличие адреса вершины от std::vector в семантике сложения. { 1, 10, 100 } + {3, 30, 300} это {1, 10, 103, 30, 300}

Вообще неудачный пример с геометрическими фигурами. Я даже где-то статью давно видел, что не надо так делать. Тут входят в противостояние геометрия и ООП

Вообще неудачный пример с геометрическими фигурами. Я даже где-то статью давно видел, что не надо так делать. Тут входят в противостояние геометрия и ООП

Правильный общий тип - шары в какой-то метрике

Для окружностей и квадратов

У типа три параметра - центр и радиус

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

Илья, вон там мой лежит

ООП не отражает отношения между объектами реального мира, вот так сюрприз! Не все объекты входят в отношение друг с другом совместимо с LSP.

Путь в дереве это последовательность произвольной длины. Точко-векторная аналогия, весьма успешная в геометрии, говорит, что нужно не различать точки и смещения. Поэтому у пути в дереве определено сложение следующего вида: { 1, 10, 100 } + {3, 30, 300} это {1, 10, 103, 30, 300}. Как мне сделать тип пути в дереве?

Что непонятно? Что такое дерево, что такое путь в дереве, что такое геометрия?)

Я все еще хочу узнать, должен ли я наследовать std::vector, если единственное, что мне нужно - это определить одну операцию

Я могу пофиксить все проблемы с наследованием и operator == в С++ одной конструкцией языка - ссылкой, которой запрещен полиморфизм

Кстати, с присваиванием тоже

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

bool equal(const Rectangle& r1, const Rectrange& r2) { return r1.topLeft() == r2.topLeft() && r1.bottomRight() == r2.bottomRight(); } Квадрат - это наследник прямоугольника.