Holy C++

Объекты прекрасно компонуются. Они для того и были придуманы - декомпозиция кода на объекты, чтобы компоновать уже их.

Абстракции для того и нужны, чтобы скрывать несущественные детали, в частности эффекты.

Ага, эмулируя объекты через грязные хуки.

Интересно конечно, но на каждый метод создавать класс обёртку это вообще не удобно, также какие проблемы уходят при этом решении, по-моему их становится только больше, получается если код практически полностью полагается на вызовы виртуальных методов везде придётся писать aa::invoke<method class>? К тому же судя по реализации any_with он работает только с movable классами. И давайте ещё немного немного усложним задачу.

struct Widget : GraphicObject
{
    virtual void draw() override
    {
        ...
    }
};

struct Label : Widget
{
    virtual void draw() override
    {
        Widget::draw();
        ...
    }
};

draw можно будет поменять на event например, будет более логично.

move не нужно будет иметь потому что есть aa::move, то есть это ведёт себя как объект, а не как указатель на объект.

Так что будете писать a = b; а не a=b->copy() и прочая муть.

Методов может хоть 2 хоть 102, просто указываете. По неймингу понятно, что вы не совсем поняли суть, GraphicObject это не интерфейс целиком, а лишь один метод, из множества методов можно собрать интерфейс

Так что назовите его скажем Draw

и потом

using any_drawable = aa::any_with<Draw, aa::move, aa::copy>;(что вам там нужно то и берите)

Ну и в examples там показано, что можно в методы добавлять сразу интерфейс, чтобы писать не aa::invoke<Draw>(v), а v.draw();

Получается вы создали псевдотаблицу виртуальных методов.

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

Причём класс наследника может быть реализован позже разработки самого базового класса.

class Base {
public:
    virtual void foo() { std::cout << "Base::foo" << std::endl; };
    void bar() {  std::cout << "Base::bar" << std::endl; }
    void baz() {  foo();  bar(); }
};

class AB : public Base {
public:
    void foo() { std::cout << "AB::foo" << std::endl; }
    void bar() { std::cout << "AB::bar" << std::endl; }
};

class DAB : public AB {
public:
    void foo() { std::cout << "DAB::foo" << std::endl; }
    void bar() { std::cout << "DAB::bar" << std::endl; }
};

int main( int argc, char * argv[], char * env ) {

    DAB tAB;
    tAB.baz();

В graalVM вы можете на прямую ходить в Линукс и делать что хотите. POSIX доступен, ровно как на сях. Просто в доках этого нет ещё граалевских.

Просто повторюсь, я спокойно ддергал mmap и управлял регистрами прямо из java и Грааль.

То о чем вы говорите - это netty+vert.x+quarkus.... Просто никому не интересно 2й nginx писать... Зачем?

Не "хочешь", а надо или не надо.
Вот "платформонезависимость" - не надо. Своей тонны java кода нет, что-бы пытаться не переписывая получить профит в производительности и эффективности. А начинать писать на java, то что можно эффективнее и оптимальнее реализовать на C/C++ - лишено смысла, кроме как в случае, если вокруг одни java-программисты и ты один со своим cpp.

Когда речь заходит про "реальную производительнось" не следует забывать про тип задач и количество программистов в нем. Если это какое то небольшое приложение - да, вы совершенно правы. А если это скажем риалтайм биллинг, который пишут 300 человек, то производительнось встаёт на 2й план после стоимости программистов. То есть своей задачи свое решение. Тут и производительность и time to market и главное цена. Одна и та же система, но сделанная "по дзену" но в 100 раз дороже никому на рынке не будет нужна

Да нет смысла в этом... Особенно для java + graal. Оно ж заточено куда - в облако. На 10мб alpine работает.

Это всякие извращенцы типа меня делают embedded to cloud. В большинстве случаев это не нужно

но MKL это разновидность BLAS+LAPACK и быстрее он только на Intel

Хотя конечно сам по себе хорош

https://github.com/Kotofay/JavaVsC

Test time : 1538
Result : -1.0, -2.696002453891236

Да, согласен, тоже глянул и поразился. Удивительно, но даже в случае С-совместимого кода гарантируется нормальный layout, но толку в этом ноль, компилятор может делать что хочет если идёт доступ не к тем полям что присвоены.

Такие объемы вы уже вряд ли в памяти будете хранить. Ибо и памяти на пару объектов хватит только и врятли "просто случайный доступ" это бизнес кейс.

У вас уже он где то будет валятся - а дальше что-то типа https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#map(java.nio.channels.FileChannel.MapMode, long, long)

И вперёд...

Именно так... для не стандартных кейсов не стандартные решения...

А давайте перефразирую: Работаешь с 64-х битными массивами - учи С++ :)

В реальности, по моему скромному мнению, массивы только в нише специфичных кейсов остались. 90% народа работает с листами, мапами, сетами и прочими обертками

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

это называется контекстно зависимое ключевое слово

Ключевые слова не могут быть использованы в качестве идентификаторов.

Я использовал здесь final два раза в качестве идентификатора (имя структуры и имя переменной) безо всяких проблем, и ни один из 4-х компиляторов даже не пикнул: https://godbolt.org/z/rKh169Wb3

Если же прочитать нечто, достаточно близкое к оригиналу:

https://en.cppreference.com/w/cpp/keyword

То выяснится, что final среди ключевых слов отсутствует.

Зато он присутствует среди идентификаторов с особым смыслом/значением, который (смысл, то бишь, или значение) они (идентификаторы) имеют лишь в определённых контекстах.
В другом месте https://en.cppreference.com/w/cpp/language/final он описывается как спецификатор.
И нигде он не описывается как ключевое слово.

Специально глянул драфт 2015-го года -- там final описывается в главе 2.10, которая называется Identifiers.

Вот пункт 2 оттуда:

2 The identifiers in Table 2 have a special meaning when appearing in a certain context. When referred to in the grammar, these identifiers are used explicitly rather than using the identifier grammar production. Unless otherwise specified, any ambiguity as to whether a given identifier has a special meaning is resolved to interpret the token as a regular identifier.

Table 2 — Identifiers with special meaning

override final

Думаю, излишне будет уточнять, что Стандарт имеет силу аксиомы, то есть, он -- абсолютен, и если он указывает, что это -- identifier with special meaning, а не ключевое слово, значит, это абсолютно именно так и есть.

Напрашивается вопрос: зачем выдумывать про ключевые слова?

Прежде чем будет достигнута программистская зрелость, неизбежно придётся неоднократно взбираться на пик глупости кривой Даннинга-Крюгера.
То есть, само по себе, хоть это и неприятно, -- это необходимая издержка.
Но в дальнейшем -- всё определяется выбором, который делает человек, оказавшись там.
Выборе, сделанном для того, чтобы научиться не попадать туда больше, или для того, чтобы во чтобы то ни стало каждый раз "казаться правым".

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

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

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

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

Но возможность изменить свой выбор всегда остаётся.