В поисках совершенных абстракций

[pu4koff]

1. Как Вы собираетесь это использовать на практике?

        // Оператор сложения
        // arg addend="добавляемое"
        // return "сумма"
        virtual TSequence& operator+(const TSequence& addend) const = 0;

К чему этот самый addend прибавлять будем?
2. Как быть с закрытыми (private) членами? Объявлять друзьями эти классы сложения, вычитания,...?
3. Как с Вашим подходом реалиовать следующее:

int a;
string b;
list<float> c;
c = a + b;

4. Оба подхода (что уже есть и предложенный Вами), как мне кажется, по своему правильны. Это как: "хватай мешки, вокзал поехал". т.е. зависит от того, с какой стороны смотреть.

int a;

Что за сущность у нас такая int? Если это принять его за простое хранилище целочисленных данных, то операторам тут не место и, если бы int был классом, то были только конструкторы и всё, а все операции над int'ами нужно было бы реализовать в каком-нибудь IntManager'е, который умел уже и складывать и умножать и много чего еще интересного.
Но почему бы не принять int как целое число в математике? Вполне логично, что операторы все уже будут находиться в самом "классе" int и никакие менеджеры не нужны будут. Чем тут не ООП подход?
Если я правильно понял ТС, то история про отделение бизнес-логики от модели предметной области и что-то общее с выбором между двумя такими паттернами, как "Active Record" и "Data Mapper" (по крайней мере у Фаулера они так называются )

[atomicxp]

Сообщение от pu4koff

1. Как Вы собираетесь это использовать на практике?

        // Оператор сложения
        // arg addend="добавляемое"
        // return "сумма"
        virtual TSequence& operator+(const TSequence& addend) const = 0;

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

Сообщение от pu4koff

К чему этот самый addend прибавлять будем?

Ну если нет augend, тогда к this. Аналогично с другими операциями.

Сообщение от pu4koff

2. Как быть с закрытыми (private) членами? Объявлять друзьями эти классы сложения, вычитания,...?

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

Сообщение от pu4koff

3. Как с Вашим подходом реалиовать следующее:

int a;
string b;
list<float> c;
c = a + b;

Ну это как бы не совсем мой подход, так учат делать с 10 по 15 главу книги "Язык программирования C++" у которой автор создатель языка Бьерн Страуструп. Скажем так, мне вот такое выражение совсем не нравится, есть в нём нечто не правильное. Но опять же если уж очень надо инициализирующий конструктор для строки и целого в вещественном типе.

Сообщение от pu4koff

4. Оба подхода (что уже есть и предложенный Вами), как мне кажется, по своему правильны. Это как: "хватай мешки, вокзал поехал". т.е. зависит от того, с какой стороны смотреть.

int a;

Что за сущность у нас такая int? Если это принять его за простое хранилище целочисленных данных, то операторам тут не место и, если бы int был классом, то были только конструкторы и всё, а все операции над int'ами нужно было бы реализовать в каком-нибудь IntManager'е, который умел уже и складывать и умножать и много чего еще интересного.
Но почему бы не принять int как целое число в математике? Вполне логично, что операторы все уже будут находиться в самом "классе" int и никакие менеджеры не нужны будут. Чем тут не ООП подход?

Это не ООП. Вот у меня конкретные примеры Qt SDK, PhysX, OpenCASCADE и другие. Они используют свои типы для натуральных, целых, вещественных и других чисел. По сути чистый int мало где применяется в таких библиотеках, во всех аргументах функций и многом другом прописано своё. И это при том, что у них там тоже не везде чистый ООП, а тоже как попало сделано, видимо вокзал уезжал приходилось срочно хватать код.

[pu4koff]

Сообщение от atomicxp

Ну если нет augend, тогда к this. Аналогично с другими операциями.

т.е. будет как-то так:

class MyInt: public Addition<MyInt>, public Subtraction<MyInt>,...
{
...
};

?
Надеюсь всёже, что нет, но тогда не понимаю как можно к this прибавить что-то?

[atomicxp]

Сообщение от pu4koff

т.е. будет как-то так:

class MyInt: public Addition<MyInt>, public Subtraction<MyInt>,...
{
...
};

?
Надеюсь всёже, что нет, но тогда не понимаю как можно к this прибавить что-то?

Наверное я не точно выразился. Если речь идёт о this как о инструкции, то это присваивание с какой-либо арифметической операцией. В C++ тогда прямо инструкция this и применяется, из-за этого скорость выше, чем у обычных операций (естественно все операции подобного типа inline). А если надо операцию без присваивания, то вместо первого аргумента берётся тоже this, но присваивается не ему, а временному объекту.

В книге "Язык программирования C++" Бьерна Страуструпа на странице 330 есть глава 11.6 Большие объекты. Вообще, 11 глава об операторах, а вот в этой конкретно говорится о том как можно избегать копирования если этого не нужно.

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



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

Надо собрать наследованием арифметические операции и потом уже наследовать их к числовым типам, то есть код по идее должен быть не как у тебя показано. Плюс полиморфные классы цель которых использование полиморфных функций в классах потомках это конечно немножко не то. Необходимо создать соединение с различными обычными операторами. Между прочим тут подумалось, что операции PPU если считаешь физику тоже можно использовать подобным образом, а не только GPU от NVidia, ну или любой другой CPU.

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

[pu4koff]

Сообщение от atomicxp

Наверное я не точно выразился. Если речь идёт о this как о инструкции, то это присваивание с какой-либо арифметической операцией. В C++ тогда прямо инструкция this и применяется, из-за этого скорость выше, чем у обычных операций (естественно все операции подобного типа inline). А если надо операцию без присваивания, то вместо первого аргумента берётся тоже this, но присваивается не ему, а временному объекту.

Мне непонятна планируемая реализация следующего класса:

class IntAddition: public Addition<int>
{
public:
  int& operator + (const int& addend) const
  {
    return (x + addend); // Откуда тут возьмём x? т.е. к чему прибавим addend?
  }
  ...
};

Сообщение от atomicxp

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

В принципе они всюду и используются. Винда например "понимает" FAT32 и NTFS. В недрах нет никаких if'ов, что если сейчас FAT32, то копируем файл так, а для NTFS копирование происходит эдак. Существует виртуальная файловая система, с которой винда уже по определенному интерфейсу общается, а та в свою очередь уже выполняет нужные операции с файловой системой. Эту самую виртуальную ФС я считаю абстракцией.
Так же библиотека WinSock в винде. Хочешь TCP, хочешь UDP, да и с IrDa посредством неё работаешь практически одинаково. Флаги только нужные выставляешь. Тоже абстракция какая никакая, хотя и без ООП
Просто обычно абстракции более низкоуровневые и не так "красивы", как хотелось бы, зато производительности лучшей добиться можно.
В .NET и Java так вообще кругом они. ADO.NET, JDBC,...

[atomicxp]

Сообщение от pu4koff

Мне непонятна планируемая реализация следующего класса:

class IntAddition: public Addition<int>
{
public:
  int& operator + (const int& addend) const
  {
    return (x + addend); // Откуда тут возьмём x? т.е. к чему прибавим addend?
  }
  ...
};

Такого как IntAddition не будет, скорее всего по твоей аналогии Integer, но с разрядами и прочим. Здесь как бы не важно, int x или нечто другое, может будут комплексные числа или всё что угодно с чем могут работать данные операции. Вот так примерно, если грубо:

class IntAddition: public Addition<int>
{
private:
  int x;
public:
  int& operator + (const int& addend) const
  {
    int& temp = get_new_temp(this.x + addend); // создаём и возвращаем новый объект
    return temp ; // Откуда тут возьмём x? т.е. к чему прибавим addend?
  }
  ...
};

Хотя на самом деле это будет не совсем так, или совсем не так, потому что у тебя нет использования шаблонов. Когда надо будет написать какой-нибудь код, напишу. Если не сработает это просто перепишу на то что сработает. Мне важнее абстракция, а не её представление, потому что представление все равно получится сделать, а вот написать абстракцию не знаю.

class IntAddition: public Addition<int>
{
private:
  int x;
public:
  void operator += (const int& addend)
  {
    this.x += addend;
  }
  ...
};

Вот ещё принцип, только не надо меня бить если пример не сработает. Главное, что в общем и целом C++ позволяет сделать то что мне надо.

Сообщение от pu4koff

В принципе они всюду и используются. Винда например "понимает" FAT32 и NTFS. В недрах нет никаких if'ов, что если сейчас FAT32, то копируем файл так, а для NTFS копирование происходит эдак. Существует виртуальная файловая система, с которой винда уже по определенному интерфейсу общается, а та в свою очередь уже выполняет нужные операции с файловой системой. Эту самую виртуальную ФС я считаю абстракцией.

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

Сообщение от pu4koff

Так же библиотека WinSock в винде. Хочешь TCP, хочешь UDP, да и с IrDa посредством неё работаешь практически одинаково. Флаги только нужные выставляешь. Тоже абстракция какая никакая, хотя и без ООП
Просто обычно абстракции более низкоуровневые и не так "красивы", как хотелось бы, зато производительности лучшей добиться можно.
В .NET и Java так вообще кругом они. ADO.NET, JDBC,...

Про яву не знаю, так только пару раз нетбинс запускал, да и всё, но тут как бы не суть важно, их абстракции на сайте сана видны. А вот .NET излазил рефлектором 1.1 и 2.0 библиотеки. И VB.NET подставлял в этом декомпилятори и C#.

Так вот абстракции .NET Framework это очень плохо написанные абстракции. И ведь в отличие от C++ так просто не перепишешь, да и возможностей у дотнета почти никаких. Всё приходится портировать, причём с проектов на C++, тогда как на самом C++ достаточно скачать и включить в код нужную библиотеку.

ADO.NET тоже жуть, в целом же всё это становится понятным, если самому сделать некоторые классы дотнета существенно упрощающие работу с кривым фреймворком. В общем, абстракции майкрософт как всегда ужасны и с каждой новой версией становятся только хуже.

А хорошие видимо никак кроме как самому написать не получить.

[pu4koff]

class IntAddition: public Addition<int>
{
private:
  int x;
public:
  int& operator + (const int& addend) const
  {
    int& temp = get_new_temp(this.x + addend); // создаём и возвращаем новый объект
    return temp ; // Откуда тут возьмём x? т.е. к чему прибавим addend?
  }
  ...
};

Опасная штука при многопоточном программировании. Придется на каждый плюс по блокировке ставить, иначе распараллеливание: (a + b) + (c + d) выльется в непонятный результат

Сообщение от atomicxp

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

Скорость и объем в любом случае пострадают

Сообщение от atomicxp

Так вот абстракции .NET Framework это очень плохо написанные абстракции. И ведь в отличие от C++ так просто не перепишешь, да и возможностей у дотнета почти никаких. Всё приходится портировать, причём с проектов на C++, тогда как на самом C++ достаточно скачать и включить в код нужную библиотеку.

Не знаю. А мне нравится. Хотя не то, чтобы много под него программил.
Ну и надеюсь под .NET не на C++ писали, а на шарпе

Сообщение от atomicxp

А хорошие видимо никак кроме как самому написать не получить.

Проблема вероятно в том, что это самое хорошее у всех разное и что нравится Вам может вызывать отвращение у других и наоборот. Кому-то и STL нравится

[atomicxp]

Сообщение от pu4koff

Опасная штука при многопоточном программировании. Придется на каждый плюс по блокировке ставить, иначе распараллеливание: (a + b) + (c + d) выльется в непонятный результат

Не знаю, mustaf0id сказал в этой теме, что можно какой-то open-mp использовать, и т.п. Но что-то здесь не так. Иными словами у меня возникают пока что неподтверждённые собственными опытами подозрения, что проблемы будут из-за специальных компиляторов. Но вот если применить простое распараллеливание. Впрочем здесь надо опыты проводить, так ничего сказать не могу.

[pu4koff]

Допустим имеется 2 потока.
Первый считает: a + b
Второй: c + d
Переменная x внутри объекта "сумматора" одна на всех и потому записать в неё значение может первый поток, а считать - второй. Или наоборот. В итоге вместо 2 + 2 посчитается какое-нибудь 2 + 15.
Придется на каждый поток заводить свой "сумматор" и очень много со всем этим возиться в итоге

[mustaf0id]

Ну, open-mp это я к примеру назвал . Можно и свои потоками, допустим посчитать надо сумму массива и есть n ядер, каждым потоком считаем сумму 1/n части массива и потом считаем сумму сумм. Блокировка на каждый плюс не нужна, только для сохранения потоком своей суммы.

Посмотрел что за open-mp, мне лично совсем не понравился принцип, убивает все абстракции.

Да, я и говорю - если и использовать то запихнуть в отдельный класс, подальше от этих абстракий

Кстати, насчет абстракций, а какие можно выделить критерии "хорошей" абстракции? Я думаю один из таких критериев - простота. Например, for можно выразить через while, (или не дай бог goto ) но тогда появляется излишняя "свобода действий" и код становить трудно читать.
Вот помоему интересное мнение по этому поводу http://blog.intentsoft.com/intention...ons_and_p.html там правда про языки программирования но суть та же.

int a;
string b;
list<float> c;
c = a + b;

Ужас, вот так лучше помоему никогда не делать