RAII и исключения в конструкторе - C/C++

Здравствуйте, a7d3, Вы писали:

A>Здравствуйте, C0x, Вы писали:

C0x>>...
C0x>>Как раз все наоборот получилось, некоторые личности отказываются упорно понять, что C++ и ООП это разные вещи. То что я пишу в коде Си "class" вообще не означает ООП. Если я захочу следовать канонам ООП я могу им даже в чистом Си следовать, я тебе уже об этом выше говорил.
C0x>>...
A>>>[q]
A>>>Например, в языке C имеется превосходная поддержка инкапсуляции. Рассмотрим простую программу на C:

C0x>>Круто! И дальше то что?

A>Так уже упоминалось — или трусы надеть, или крестик снять.
A>Либо не использовать С++ вообще — отложить его подальше, либо выбрать парадигму и решать задачи создания кода только лишь в рамках выбранной парадигмы.

Хочешь себя ограничивать, да ради бога. Вот как раз если мне понадобится писать в чисто ООП парадигме я выберу для этого гораздо более подходящие инструменты, например Java или C#. Если мне нужно будет писать функциональный код, я выберу Scala. Если нужно процедурный код писать так есть чистый Си. Ещё раз тебе повторю — си плюс плюс я выбираю за его мультипарадигменность.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, a7d3, Вы писали:

A>>На том, что характер и тип полиморфизма, упоминаемого в ООП нигде, никогда и никем не конкретизировался.

S>Конкретизировался. Про то, что в ООЯ полиморфизим реализуется именно как late binding пишут повсюду. Воспользуйтесь гуглом (вот например). Или хотя бы в Wikipedia загляните (тыц раз вместе с цитатой из Алана Кея, тыц два).

A>>Любая попытка додумывать в духе «под полиморфизимом понималось позднее связывание» — это краеугольный камень для последующих заблуждений с домыслами. Её следует отследить до первоисточника и поинтересоваться «какого фига» да «с какой целью» человек выплеснул в мир эту дезинформацию.

S>Позволю себе дать совет: хватит звиздеть. Если все, что вы можете сказать в подтверждение своей точки зрения -- это "я так сказал", то можете больше не трудится. Вы уже окрасили себя в те цвета...

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

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

Здравствуйте, C0x, Вы писали:

C0x>Здравствуйте, a7d3, Вы писали:

A>>Так уже упоминалось — или трусы надеть, или крестик снять.
A>>Либо не использовать С++ вообще — отложить его подальше, либо выбрать парадигму и решать задачи создания кода только лишь в рамках выбранной парадигмы.

C0x>Хочешь себя ограничивать, да ради бога. Вот как раз если мне понадобится писать в чисто ООП парадигме я выберу для этого гораздо более подходящие инструменты, например Java или C#. Если мне нужно будет писать функциональный код, я выберу Scala. Если нужно процедурный код писать так есть чистый Си. Ещё раз тебе повторю — си плюс плюс я выбираю за его мультипарадигменность.

Но парадигмы то всего три:

процедурное
функциональное
объектно-ориентированное

Обобщённое же программирование и остальное — это лишь стили в рамках этих трёх парадигм (в контексте С++).

Здравствуйте, C0x, Вы писали:

C0x>Мне вот это почему-то тоже кажется сложным. У меня есть типы типа HANDLE, оборачивать их в спец объект ради одной простой цели — надежного уничтожения везде и всегда кажется черезчурным.

Если софт работает 24/7 то позаботиться о надёжно освобождении ресурсов необходимо. Но и если не 24/7, то всё равно ресурсы нужно надёжно освобождать.

C0x>Да и хочется не с врапперами в коде работать а с исходными типами (видить их в полях класса и возращаемых зачениях функций).

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

// Прототипы функций, использующих HANDLE
HANDLE LoadHeavyResource1();
HANDLE LoadHeavyResource2();
HANDLE LoadHeavyResource3();

void ReleaseResource(HANDLE handle);

void UseHandle(HANDLE handle);


// Обёртка.
struct HandleWrapper
{
    HANDLE handle;

    HandleWrapper() : handle(NULL) {}
    HandleWrapper(HANDLE h) : handle(h) {}
    HandleWrapper(HandleWrapper &h) : handle(h.handle)
    {
        h.handle = NULL;
    }

    ~HandleWrapper()
    {
        if (handle)
            ReleaseResource(handle);
    }

    operator HANDLE() { return handle; }

    HandleWrapper& operator=(HandleWrapper &h) // Тут лучше, бы, конечно, семнтику перемещений использовать.
    {
        handle = h.handle;
        h.handle = NULL;
    }

    HandleWrapper& operator=(HANDLE h)
    {
        handle = h;
    }
};


// Тогда можно использовать.
struct A_Data
{
   HandleWrapper _someHandle1;
   HandleWrapper _someHandle2;
   HandleWrapper _someHandle3;

   A_Data()
   : _someHandle1(LoadHeavyResource1()),
     _someHandle2(LoadHeavyResource2()),
     _someHandle3(LoadHeavyResource3())
   {
   }

   ~A_Data() = default;

   void Foo()
   {
       UseHandle(_someHandle1);
       UseHandle(_someHandle2);
       UseHandle(_someHandle3);
   }
};

Здравствуйте, so5team, Вы писали:

S>Еще раз прямой вопрос: с какой целью вы привели ссылку на статью про trait-ы?

S>Нужен прямой ответ, который бы не заставил меня додумывать за вас.

Больше двадцати лет, в контексте С++, идут эти разговоры — о том, какова роль обобщённого программирования.
И до сих пор, в результате всех принятых стандартов, оно так и не стало отдельной парадигмой.
За всё это время нет работ (публикаций), которые обосновали бы, что дескать статический полиморфизм обобщённого программирования якобы выходит за рамки ООП, создавая собственную отдельную парадигму.

Здравствуйте, C0x, Вы писали:

C0x>Конструктор и деструктор изначально для этого и нужны в Си++ у каждого объекта, чтобы его данные можно было подчищать.

Но не обязательно же в них работать только с сырыми данными. Деструктор по умолчанию, который вызовет деструкторы членов-смартпоинтеров --- это то же самое, только писать код не надо. Вас же не смущает, что если в объекте лежат два вектора, не надо вручную следить за их удалением?

C0x>>>Да и хочется не с врапперами в коде работать а с исходными типами (видить их в полях класса и возращаемых зачениях функций).

PB>>А почему? <skip>

C0x>Ну например хотя бы потому, что код работающий с Хэндлами легко найти на Github, а если его завернуть во Wrapper то на Гитхаб будет помойка из разнородного кода, который вроде бы делает одно и то же но при этом выглядит совершенно по разному.

А еще переменные по-своему названы и скобки по-разному расставлены --- на GitHub'е нет поиска по структуре кода, а ищут обычно по имени функции API.

PB>>"Лапша" в данном случае в том, что вместо ApiFunc(resource1) придется писать ApiFunc(resource1.get()). Но это как раз и хорошо, что нельзя отдать куда-то хэндл и не подумать о владении им.

C0x>Нет не хорошо, потому-что нужно придерживаться принципа KISS и YAGNI, иначе мы будем думать о многом, а в итоге нам нужно просто вызвать API функции и передать туда тупа Хэндл.

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

Здравствуйте, AleksandrN, Вы писали:

AN>// Обёртка.
AN>struct HandleWrapper
AN>{
AN> <skip>

Отличная демонстрация, почему в соседних ветках правильно советуют готовый unique_ptr: не так-то просто грамотно описать владельца даже одного ресурса (я про размер класса и количество неоднозначных мест, а не про качество кода на скорую руку для форума).

Здравствуйте, a7d3, Вы писали:

A>Подмена понятий. Варианты реализации полиморфизма в отдельно взятых ООЯ никак не сообщают о том, конкретизировались ли варианты полиморфизма в самой парадигме ООП.

Конкретизировались. Об этом говорилось чуть ли не в каждой первой статье про ООП времен конца 1980-х и начала 1990-х.

A>Вместо этого надо дать ответ на простой вопрос: кто и в каких работах утверждал, что полиморфизм в ООП обязательно должен быть динамическим?
A>Именно это и даст понять, почему статический полиморфизм якобы не подходит для ООП и не может в нём использоваться.

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

Начнем сразу с одного из отцов ООП, Алана Кея (вы бы сами нашли ее, если бы прошли по ранее приведенной ссылке в Wikipedia):

"OOP to me means only messaging, local retention, and protection and hiding of state-process, and extreme late-binding of all things." src

Бертран Мейер. Объектно-ориентированное конструирование программных систем:

Полиморфизм

При наследовании, требование статической типизации, о котором говорилось выше, становится ограничивающим, если бы оно означало, что каждая сущность типа C может быть связана только с объектом точно такого же типа C. Например в системе управления навигацией сущность типа BOAT нельзя было бы использовать для объектов класса MERCHANT_SHIP или SPORTS_BOAT, хотя оба класса являются потомками класса BOAT.

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

Должна иметься возможность в период выполнения присоединять к сущности объекты различных возможных типов под управлением наследования.

Динамическое связывание

Сочетание последних двух механизмов, переопределения и полиморфизма, непосредственно предполагает следующий механизм. Допустим, есть вызов, целью которого является полиморфная сущность, например сущность типа BOAT вызывает компонент turn. Различные потомки класса BOAT, возможно, переопределили этот компонент заличными способами. Ясно, что должен существовать автоматический механизм, гарантирующий, что версия turn всегда соответствует фактическому типу объекта, вне зависимости от того, как объявлена сущность. Эта возможность называется динамическим связыванием (dynamic binding).

Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений. Издание третье.

Полиморфизм тесно связан с механизмом позднего связывания. При полиморфизме связь метода и имени определяется только в процессе выполнения программы. В языке C++ программист имеет возможность выбирать между ранним и поздним связыванием имени с членом-функцией. В частности, если метод объявлен как виртуальный, то реализуется позднее связывание, а функция считается полиморфной. Если объявление виртуальной функции отсутствует, то используется раннее связывание и метод уточняется на этапе компиляции. В языке Java позднее связывание не требует использования ключевого слова virtual.

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

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

Поэтому никакого статического (параметрического) полиморфизма в класическом ООП нет.

Но вы можете и дальше отрицать очевидные вещи.

A>Хамство, общение через наезды и явную подмену — это однозначная агрессия. Осталось понять что является причиной таких попыток оттолкнуть собеседника. Видимо, это попытка отстоять систему верований, которая на поверку оказалась заблуждениями.

Еще раз: хватит звиздеть. Есть что сказать по теме -- говорите. А от попыток в очередной раз проехаться по собеседнику воздержитесь. Вам это не поможет все равно.

Здравствуйте, a7d3, Вы писали:

S>>Нужен прямой ответ, который бы не заставил меня додумывать за вас.

A>Больше двадцати лет, в контексте С++, идут эти разговоры — о том, какова роль обобщённого программирования.
A>И до сих пор, в результате всех принятых стандартов, оно так и не стало отдельной парадигмой.
A>За всё это время нет работ (публикаций), которые обосновали бы, что дескать статический полиморфизм обобщённого программирования якобы выходит за рамки ООП, создавая собственную отдельную парадигму.

Я вас отправил смотреть в сторону policy/trait based подхода для того, чтобы вы сами могли увидеть как в GP легко и непринужденно делается то, что в классическом ООП или нельзя сделать, или же это делается гораздо сложнее, менее эффективно и менее надежно.

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

Собственно, с вами все понятно. Звездун в чистом виде.

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

Здравствуйте, PlushBeaver, Вы писали:

PB>Здравствуйте, AleksandrN, Вы писали:

AN>>// Обёртка.
AN>>struct HandleWrapper
AN>>{
AN>> <skip>

PB>Отличная демонстрация, почему в соседних ветках правильно советуют готовый unique_ptr: не так-то просто грамотно описать владельца даже одного ресурса (я про размер класса и количество неоднозначных мест, а не про качество кода на скорую руку для форума).

Это понятно, что готовый стандартный велосипед в большинстве случаев использовать разумнее, чем писать самому. Я привёл примерный набросок того, как это может быть сделано (и получилась пародия на unique_ptr).

Здравствуйте, so5team, Вы писали:

S>Конкретизировался. Про то, что в ООЯ полиморфизим реализуется именно как late binding пишут повсюду. Воспользуйтесь гуглом (вот например). Или хотя бы в Wikipedia загляните (тыц раз вместе с цитатой из Алана Кея, тыц два).

Ахинею не неси. То что там у Алана Кея позднее связывание это "самое правильное ооп" это понятно, человек рекламирует смоллток как может. Но вот то что в википедии по одной ссылке vtable это "late binding, because virtual function calls are not bound until the time of invocation", а по другой это уже static binding, т.к. "With early binding, or static binding, in an object-oriented language, the compilation phase fixes all types of variables and expressions. This is usually stored in the compiled program as an offset in a virtual method table ("v-table") and is very efficient." много говорит о википедии. Я вот, разделяю определение по ссылке на late binding, и считаю что vtable это static binding, а late binding это именно когда "method is looked up by name at runtime.". Как следствие C++ это ООП язык, а Алан Кей может дальше плясать со своим смолтоком, да и вообще он часто несёт смолток-ориентированную ахинею, но не обязательно за ним её повторять. Нормально разбирающийся в ООП дед это не алан кей, а бертран мейер, если что.

Здравствуйте, Мирный герцог, Вы писали:

МГ>Я вот, разделяю определение по ссылке на late binding, и считаю что vtable это static binding, а late binding это именно когда "method is looked up by name at runtime.".

"Ахинею не неси." (c)

Здравствуйте, so5team, Вы писали:

S>Я вас отправил смотреть в сторону policy/trait based подхода для того, чтобы вы сами могли увидеть как в GP легко и непринужденно делается то, что в классическом ООП или нельзя сделать, или же это делается гораздо сложнее, менее эффективно и менее надежно.

За 20 с лишним лет никто не смог развить обобщённое программирование в С++ до отдельной самостоятельной парадигмы. Всё эти вещи, сродни policy/trait based подхода — давно известные баяны и тянут лишь на некий стиль/вариант программирования в рамках или процедурной парадигмы или же ООП.

Отказ видеть и понимать очевидные вещи — это проблемы с которыми надо к психоаналитику/психотерапевту. Пусть поможет с прохождением каких-то там личностных кризисов и переосмыслением собственной профессиональной значимости с достижениями.

Здравствуйте, a7d3, Вы писали:

A>За 20 с лишним лет никто не смог развить обобщённое программирование в С++ до отдельной самостоятельной парадигмы.

В 1991-1992 годах это смог сделать Алекс Степанов. А уж продолжателей было... Один Александреску чего стоит.

И не будь GP отдельной самостоятельной парадигмой, не было бы для нее отдельного раздела здесь: https://en.wikipedia.org/wiki/Programming_paradigm

Но вам никто не запрещает верить во что угодно. Раз уж столько всего интересного и важного прошло мимо вас.

Здравствуйте, Мирный герцог, Вы писали:

МГ>Здравствуйте, so5team, Вы писали:

S>>Конкретизировался. Про то, что в ООЯ полиморфизим реализуется именно как late binding пишут повсюду. Воспользуйтесь гуглом (вот например). Или хотя бы в Wikipedia загляните (тыц раз вместе с цитатой из Алана Кея, тыц два).

МГ>Как следствие C++ это ООП язык

Я тебе больше скажу, Erlang ООП язык и даже на чистом Си можно писать в стиле ООП.

Здравствуйте, a7d3, Вы писали:

A>Здравствуйте, C0x, Вы писали:

A>Но парадигмы то всего три:
A>

процедурное
A>

функциональное
A>

объектно-ориентированное
A>

Любовь к самограничению я смотрю во всём

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

Здравствуйте, so5team, Вы писали:

S>Надо же, персонаж, который заявлял буквально "Апеллирование к мнению реальных или дутых авторитетов — это смешно" внезапно переобулся в воздухе и требует цитат и ссылок на источники. Так их есть у меня.
S> ...
S>Но даже без отсылок к авторитетам, исходя из здравого смысла путем только логических заключений легко прийти к выводу, что в ООП полиморфизм существует только на уровне поведения объектов, а поведение объектов обеспечивается реализацией их методов (операций). Изменение поведения происходит за счет переопределения метода в наследнике (объекте-наследнике при прототипном ООП или классе-наследнике при классовом ООП). А механизм позднего (динамического) связывания обеспечивает вызов должного метода даже если вызов делается через ссылку на родителя.

S>Поэтому никакого статического (параметрического) полиморфизма в класическом ООП нет.

S>Но вы можете и дальше отрицать очевидные вещи.

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

И вопрос был не в том, чтобы поковыряться во мнениях авторитетов. А сводится к — есть ли работы, в которых обосновывалось и показывалось бы, что в ООП полиморфизм может и должен быть сугубо динамическим. Или что он гарантированно не может и не должен быть статическим.
В который раз уже приходится обращать внимание на это?

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

От:	so5team	https://stiffstream.com
Дата:	07.07.20 15:58
Оценка:

От:	so5team	https://stiffstream.com
Дата:	07.07.20 16:03
Оценка:	+2

	От:	kov_serg
	Дата:	07.07.20 18:47
	Оценка:

	От:	C0x
	Дата:	07.07.20 21:36
	Оценка:

	От:	a7d3
	Дата:	07.07.20 21:52
	Оценка:

	От:	Мирный герцог
	Дата:	08.07.20 07:12
	Оценка: