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

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

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

C0x>>Смартпоинтер и RAII это одно и тоже?

W>Смартпойнтер — это воплощение идеи RAII. И речь не про конкретный условный unique_ptr, а в целом про концепцию объекта-владельца. Не нравится вам unique_ptr — всегда можно сделать к нему алиас, или написать свой, или взять готовый чужой — это чисто технический момент. Но все эти решения следуют одной концепции. Судя по тому, что вы возразили каждому, кто предлагал один из этих вариантов — вы отвергаете саму концепцию, а значит отвергаете и RAII.

Я с тобой почти во всем согласен. Просто я пишу код в такой идеологии что моя программа это исключительно объекты на стэке (за исключением больших блоков данных, которые создаются на куче через vector<>) и передача их по ссылке, поэтому у меня нет необходимости в Смартпоинтерах впринципе, т.к. поинтеров у меня нет. Я для себя сейчас просто поставил задачу писать код в таком стиле, если разочаруюсь значит не судьба.

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

E>С этого места хотелось бы пример, что конкретно имеется в виду.

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

_>Гораздо логичнее что бы за все ресурсы, которые использует объект, отвечал не он, а тот кто заставил его работать.
https://youtu.be/rwOv_tw2eA4?t=1611

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

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

A>>Конкретика где?

S>В примере с sort. Разницу между процедурным и обобщенным программированием легко увидеть на cppreference (тыц раз, тыц два). Аналог sort-а на чистом ООП оставлю вам в качестве домашнего задания.
S>...
S>Как раз все это в сумме и позволяет говорить об Generic Programming как об отдельной парадигме.

баяны 20-летней давности https://accu.org/index.php/journals/442
и каждые пять лет подрастает/вылупляется/размораживается стадо выскочек, возомнивших себя теми, кто узрел свет истины недоступный всем остальным.
поменьше гонора с хамством и очень быстро самомнение с самолюбием перестанут быть уязвленными.

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

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

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

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

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

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

A>>>Конкретика где?

S>>В примере с sort. Разницу между процедурным и обобщенным программированием легко увидеть на cppreference (тыц раз, тыц два). Аналог sort-а на чистом ООП оставлю вам в качестве домашнего задания.
S>>...
S>>Как раз все это в сумме и позволяет говорить об Generic Programming как об отдельной парадигме.

A>баяны 20-летней давности https://accu.org/index.php/journals/442
A>и каждые пять лет подрастает/вылупляется/размораживается стадо выскочек, возомнивших себя теми, кто узрел свет истины недоступный всем остальным.
A>поменьше гонора с хамством и очень быстро самомнение с самолюбием перестанут быть уязвленными.

A>полиморфизм есть полиморфизм — нет разницы статический он или же динамический.
A>аспекты и подходы в реализации статического или же динамического полиморфизма не создают новых парадигм программирования. а всего лишь являются частными случаями реализации полиморфиза (в рамках того же ООП).

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

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

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

Почитай книгу https://www.ozon.ru/context/detail/id/2260909/ может по другому будешь немного смотреть на парадигмы в целом и в Си++ в частности.

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

A>баяны 20-летней давности https://accu.org/index.php/journals/442

Вы сейчас зачем эту ссылку привели?

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

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

A>полиморфизм есть полиморфизм — нет разницы статический он или же динамический.

Одна проблема. В классическом ООП нет статического полиморфизма.

A>аспекты и подходы в реализации статического или же динамического полиморфизма не создают новых парадигм программирования. а всего лишь являются частными случаями реализации полиморфиза (в рамках того же ООП).

Возможно, ваша проблема в том, что вы осваивали ООП уже после того, как шаблоны пришли в C++, а генерики в Java и C#. Поэтому вы не застали классического ООП, в котором полиморфизм был только времени исполнения. И поэтому вам кажется, что обычный ООП -- это уже ООП с возможностью обобщения.

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

Надо же. А, например, некто Страуструп, считает, что Generic Programming -- это отдельный подход к программированию: https://isocpp.org/blog/2014/12/myths-1 (раздел №3). Поддержка которого в С++ и не позволяет называть C++ "чисто ОО языком".

Здравствуйте, C0x, Вы писали:
C0x>Просто я пишу код в такой идеологии что моя программа это исключительно объекты на стэке (за исключением больших блоков данных, которые создаются на куче через vector<>) и передача их по ссылке, поэтому у меня нет необходимости в Смартпоинтерах впринципе, т.к. поинтеров у меня нет. Я для себя сейчас просто поставил задачу писать код в таком стиле, если разочаруюсь значит не судьба.

Использование unique_ptr не подразумевает обязательного динамического выделения памяти (в отличие от shared_ptr).
Это один из способов уникального владения и освобождения любых ресурсов, в том или ином виде представимых в виде указателя/хэндла.
При этом под капотом никаких new не притаилось.

Вот пример использования unique_ptr для управления такими разными хэндлами Windows как HMODULE (DLL) и HLOCAL (память):

////////////////////////////////////////////////////////////////////////
// HMODULE + FreeLibrary
typedef std::unique_ptr<
    std::remove_pointer<HMODULE>::type,
    decltype(&::FreeLibrary)>
        module_holder_t;

inline module_holder_t attach_module(HMODULE handle) throw()
    { return module_holder_t(handle, &::FreeLibrary); }

inline module_holder_t load_library(const wchar_t* library_name) throw()
    { return attach_module(::LoadLibraryW(library_name)); }

////////////////////////////////////////////////////////////////////////
// HLOCAL + LocalFree
typedef std::unique_ptr<
    std::remove_pointer<HLOCAL>::type,
    decltype(&::LocalFree)>
        local_mem_holder_t;

inline local_mem_holder_t attach_local_mem(HLOCAL handle) throw()
    { return local_mem_holder_t(handle, &::LocalFree); }

inline local_mem_holder_t alloc_local_mem(UINT flags, size_t bytes) throw()
    { return attach_local_mem(::LocalAlloc(flags, bytes)); }

Здравствуйте, C0x, Вы писали:
C0x>Например в нужном порядке провести релиз ресурсов, и по условию либо закрыть файлы, либо удалить их, если запись прошла не успешно на момент вызова деструктора, и в зависимости от этого отправить пуш нотификацию в центр.
C0x>Т.е. суть в том что деструктор может резилить ресурсы не тупым способом а по определенной логике в зависимости от состояния объекта на текущий момент.

По умолчанию деструктор разрушает ресурсы в порядке обратном объявлению их как RAII-членов данных.
Если нужно другое поведение, то надо что-то свое наколхозить.
Тут уже правильно подсказывали с делегирурющим конструктором для пометки объекта ка полностью сконструированного, но есть и другие варианты.

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

////////////////////////////////////////////////////////////////////////
// in hpp
class AppInit
{
public:
    explicit AppInit(log_stream& log);
    ~AppInit();

public:
    void ole();
    void help();
    // ...

private:
    struct deinit_proc
        {
            std::string tag;
            std::function<void()> proc;
        };

    template<typename T>
    void reg_deinit(const std::string& tag, T proc)
        { m_deinit_list.emplace_back(deinit_proc{ tag, proc }); }

private:
    log_stream& m_log;
    std::vector<deinit_proc> m_deinit_list;

    AppInit(const AppInit&) = delete;
    AppIni& operator=(const AppInit&) = delete;
};

////////////////////////////////////////////////////////////////////////
// in cpp
AppInit::AppInit((log_stream& & log):
    m_log(log)
{
}

AppInit::~AppInit()
{   // deinitialize all in reverse order
    for (auto it = m_deinit_list.crbegin(); it != m_deinit_list.crend(); ++it)
    {
       try
       {
           it->proc();
       }
       catch (...)
       {
           try
           {
               if (auto r = make_log_record(m_log))
               {
                   const std::string err_msg = get_current_exception_message();
                   r << "Deinitialization failure for: " << it->tag << " (" << err_msg << ")";
               }
           }
           catch (...) { assert(0); }
       }
    }
}

////////////////////////////////////////////////////////////////////////
void AppInit::ole()
{
    HRESULT hr = ::OleInitialize(nullptr);
    if (FAILED(hr))
        ::AfxThrowOleException(hr);
    reg_deinit(L"OLE", ::OleUninitialize);
}

void AppInit::help()
{
    InitHelp();
    reg_deinit(L"Help", DoneHelp);
}

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

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

A>>аспекты и подходы в реализации статического или же динамического полиморфизма не создают новых парадигм программирования. а всего лишь являются частными случаями реализации полиморфиза (в рамках того же ООП).

S>Возможно, ваша проблема в том, что вы осваивали ООП уже после того, как шаблоны пришли в C++, а генерики в Java и C#. Поэтому вы не застали классического ООП, в котором полиморфизм был только времени исполнения. И поэтому вам кажется, что обычный ООП -- это уже ООП с возможностью обобщения.

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

S>Надо же. А, например, некто Страуструп, считает, что Generic Programming -- это отдельный подход к программированию: https://isocpp.org/blog/2014/12/myths-1 (раздел №3). Поддержка которого в С++ и не позволяет называть C++ "чисто ОО языком".

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

Generic programming является стилем программирования, а не парадигмой и это давным давно закреплено на уровне определений, после того как это вопрос мусолился туеву тучу лет назад. Известен данный стиль ещё с 1970-х годов, а generics как и parameterized types использовались ещё в ранних 90-х и встречаются в ранних изданиях таких книжек как GoF.

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

Здравствуйте, a7d3

Во-первых, было бы очень хорошо, если бы вы смогли ответить на вопрос, который вам был задан, а именно:

A>баяны 20-летней давности https://accu.org/index.php/journals/442
> Вы сейчас зачем эту ссылку привели?

Итак, к чему была ссылка на статью про trait-ы?

A>Ненаглядный ООП никак не конкретизирует варианты полиморфизма и потому не важно какой именно используется в конкретном языке, и отдельно взятом случае — статический или же динамический или же оба сразу. Меньше или больше ООП не становится от того, какой именно полиморфизм был выбран программирующим.

Во-вторых, на чем базируются эти утверждения?

Классический ООП -- это инкапсуляция, наследование и полиморфизм, где под полиморфизимом понималось позднее связывание. Т.е. то, какая именно реализация метода будет вызвана, определялось в run-time. Что автоматически делает неприменимым статический полиморфизм по отношению к ООП.

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

A>Generic programming является стилем программирования, а не парадигмой и это давным давно закреплено на уровне определений, после того как это вопрос мусолился туеву тучу лет назад. Известен данный стиль ещё с 1970-х годов, а generics как и parameterized types использовались ещё в ранних 90-х и встречаются в ранних изданиях таких книжек как GoF.

Из того, что generic programming известен давно вовсе никак не следует, что generic programming не является парадигмой (тем более, что сам термин "парадигма" он не слишком четкий).

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

В-третьих, Страуструп и об ООП говорит как о стиле, а не о парадигме. Тем не менее, ООП является вполне себе парадигмой.

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

А вот вы высказываете свою собственную точку зрения которая еще где-нибудь находит подтверждение? Или это все из категории "я так сказал"?

Буду очень признателен, если вы перестанете выбрасывать из разговора пункты, которые вам не удобны, и сможете ответить предметно по каждому из заданных вам вопросов. Сомневаюсь, что вы сможете. Но буду признателен если таки.

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

C0x>Продолжая твою логику ООП это всего лишь процедурное программирование с диспетчеризацией вызовов нужных функций в зависимости от... Кстати, мы еще в далеком 2003-м году писали ООП программы на чистом Си и полиморфизм был и наследования.

C0x>Почитай книгу https://www.ozon.ru/context/detail/id/2260909/ может по другому будешь немного смотреть на парадигмы в целом и в Си++ в частности.

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

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

Например, в языке C имеется превосходная поддержка инкапсуляции. Рассмотрим простую программу на C:
point.h
struct Point;
struct Point* makePoint(double x, double y);
double distance (struct Point *p1, struct Point *p2);

point.c
#include "point.h"
#include <stdlib.h>
#include <math.h>

struct Point {
    double x,y;
};

struct Point* makepoint(double x, double y) {
    struct Point* p = malloc(sizeof(struct Point));
    p->x = x;
    p->y = y;
    return p;
}

double distance(struct Point* p1, struct Point* p2) {
    double dx = p1->x - p2->x;
    double dy = p1->y - p2->y;
    return sqrt(dx*dx+dy*dy);
}
Пользователи point.h не имеют доступа к членам структуры Point. Они могут вызывать функции makePoint() и distance(), но не имеют никакого представления о реализации структуры Point и функций для работы с ней.
Это отличный пример поддержки инкапсуляции не в объектно-ориентированном языке. Программисты на C постоянно использовали подобные приемы. Мы можем объявить структуры данных и функции в заголовочных файлах и реализовать их в файлах реализации. И наши пользователи никогда не получат доступа к элементам в этих файлах реализации.

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

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

S>Буду очень признателен, если вы перестанете выбрасывать из разговора пункты, которые вам не удобны, и сможете ответить предметно по каждому из заданных вам вопросов. Сомневаюсь, что вы сможете. Но буду признателен если таки.

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

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

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

A>Что за попытки сразу пачкой обсуждать очень разные вопросы, расположенные довольно далеко друг от друга? А потом ещё и претензии предъявлять, что эти попытки пресекаются и не поощряются?

Пресекать и не поощрять взялся хз кто, единственным обоснованием чьих слов является "я так сказал". Ну ок, звездун, так звездун.

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

S>Здравствуйте, a7d3

S>Во-первых, было бы очень хорошо, если бы вы смогли ответить на вопрос, который вам был задан, а именно:

S>

A>>баяны 20-летней давности https://accu.org/index.php/journals/442
>> Вы сейчас зачем эту ссылку привели?

S>Итак, к чему была ссылка на статью про trait-ы?

Что за манеры, любезный? Диалог с позиции постоянных наездов и претензий с разнообразными предъявлениями?
Это психологическая защита сработала, пытающаяся оттолкнуть собеседника, чтобы тот ни в коем случае не поколебал привычную картину давно сложившегося маня мирка?

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

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

A>>Ненаглядный ООП никак не конкретизирует варианты полиморфизма и потому не важно какой именно используется в конкретном языке, и отдельно взятом случае — статический или же динамический или же оба сразу. Меньше или больше ООП не становится от того, какой именно полиморфизм был выбран программирующим.

S>Во-вторых, на чем базируются эти утверждения?

S>Классический ООП -- это инкапсуляция, наследование и полиморфизм, где под полиморфизимом понималось позднее связывание. Т.е. то, какая именно реализация метода будет вызвана, определялось в run-time. Что автоматически делает неприменимым статический полиморфизм по отношению к ООП.

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

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

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

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

C0x>>Продолжая твою логику ООП это всего лишь процедурное программирование с диспетчеризацией вызовов нужных функций в зависимости от... Кстати, мы еще в далеком 2003-м году писали ООП программы на чистом Си и полиморфизм был и наследования.

C0x>>Почитай книгу https://www.ozon.ru/context/detail/id/2260909/ может по другому будешь немного смотреть на парадигмы в целом и в Си++ в частности.

A>У ненаглядного ООП есть чёткое и однозначное определение, если оно не знакомо

Спасибо, вкурсе.

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

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

A>Теперь же выясняется, что эта же персона ни сном ни духом даже о столь элементарных вещах, как существовании классического и однозначного определения ООП.

Сам что-то себе придумал, потом принял это за аксиому, потом сделал какие-то выводы. Ну молодец, чо ))

A>[q]
A>Например, в языке C имеется превосходная поддержка инкапсуляции. Рассмотрим простую программу на C:

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

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

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

В этом случае вы можете сделать класс-закрыватель объекта. Тогда код будет выглядить так:

const HANDLE resource = GetOpenedHandle();
HandleCloser callCloseHandleAtScopeExit(resource);
// далее работа с resource... //

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

Еще можете библиотеку WIL посмотреть.

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

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

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

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

	От:	C0x
	Дата:	07.07.20 08:25
	Оценка:

	От:	C0x
	Дата:	07.07.20 09:35
	Оценка:

	От:	C0x
	Дата:	07.07.20 09:46
	Оценка:

	От:	C0x
	Дата:	07.07.20 09:54
	Оценка:

	От:	σ
	Дата:	07.07.20 10:03
	Оценка:

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

От:	Basil2	https://starostin.msk.ru
Дата:	07.07.20 15:21
Оценка: