давно не писал на плюсах, вот вернулся снова и понеслась душа в пляс
Надоели всякие Begin, End, Open, Close методы в программах. Хочу придерживаться принципа RAII.
Но возникает классическая проблема вылетает исключение в конструкторе и пипец. Ну скажем я Handle какой-нибудь на ресурс получил, а после исключения естественно деструктор не вызывается и ресурс не освобождается. Ну как бы, да, есть ломовое решение перехватывать закрыть конструктор в try catch и освобождать ресурсы через метод Release(), которой так же дергается и в самом деструкторе нашего класса.
Но как вам решение проблемы деструкции данных класса через базовый класс? Т.е. пихаем все ресурсные поля класса в базовый класс, который умеет их зачищать в деструкторе. После того как в нашем классе в конструкторе вылетает исключение, в любом случае вызовится деструктор базового класса и он освободит ресурсы. Есть такой подход в Си++ мире или лучше так не делать?
Со своей стороны я вижу очевидный плюс такого подхода — нет лишних методов типа Release, Close и т.д. Все делается средствами самого языка: конструктор-деструктор. Как бы чисто всё чтоли.
Пример:
template<typename TData>
struct A : public TData
{
A()
{
_someHandle1 = LoadHeavyResource1(); //Тут может быть исключение
_someHandle2 = LoadHeavyResource2(); //Тут может быть исключение
_someHandle3 = LoadHeavyResource3(); //Тут может быть исключение
}
}
struct A_Data
{
HANDLE _someHandle1 = NULL;
HANDLE _someHandle2 = NULL;
HANDLE _someHandle3 = NULL;
~A_Data()
{
if (_someHandle1 != NULL) ReleaseHeavyResource1(_someHandle1);
if (_someHandle2 != NULL) ReleaseHeavyResource2(_someHandle2);
if (_someHandle3 != NULL) ReleaseHeavyResource3(_someHandle3);
}
}
Здравствуйте, C0x, Вы писали:
C0x>Но как вам решение проблемы деструкции данных класса через базовый класс? Т.е. пихаем все ресурсные поля класса в базовый класс, который умеет их зачищать в деструкторе. После того как в нашем классе в конструкторе вылетает исключение, в любом случае вызовится деструктор базового класса и он освободит ресурсы. Есть такой подход в Си++ мире или лучше так не делать?
Сложно --- наследование и шаблоны на ровном месте, ненадежно --- можно забыть освободить ресурс или освободить не в том порядке. Пусть каждый ресурс будет отдельным объектом с RAII в составе A. При вылете исключения из конструктора A для тех из них, которые успели сконструироваться, будут вызваны деструкторы.
Здравствуйте, C0x, Вы писали:
C0x>Но как вам решение проблемы деструкции данных класса через базовый класс?
Креативно.
Но обычно в таком случае делается класс-обертка для конкретного типа ресурсов. Тогда весь код выглядит так:
struct A
{
private:
smart_resource_ptr _someHandle1 = LoadHeavyResource1(); //Тут может быть исключение
smart_resource_ptr _someHandle2 = LoadHeavyResource2(); //Тут может быть исключение
smart_resource_ptr _someHandle3 = LoadHeavyResource3(); //Тут может быть исключение
}
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, C0x, Вы писали:
C0x>Но как вам решение проблемы деструкции данных класса через базовый класс?
В Qt есть базовый класс, называется QObject. Наследуешься от него естественно не забывая про метаобъектный компилятор, а когда создаёшь объект в куче присваиваешь родителя. Удалишь родительский объект, удалишь и дочерние объекты.
Другой вариант использовать умный указатель, но это везде в C++ и не по одной реализации в каждой библиотеке. Есть различные виды умных указателей. Классический, как только пропадают все ссылки на объект в куче, так он автоматически уничтожается.
Порядок уничтожения между этими способами разный, но результат автоматическое уничтожение без вызова delete.
C0x>Со своей стороны я вижу очевидный плюс такого подхода — нет лишних методов типа Release, Close и т.д.
А вот это я думаю вовсе не лишние методы, а так специально спроектированная система. Если сделали методы вроде открыть, закрыть, например, для файла или соединения с базой данных, то это как бы разработчики непрозрачно намекают, чтобы программист управлял вручную всем этим хозяйством пока существует объект с этими методами.
Автоматическое освобождение любых ресурсов не проблема, просто в C++ не принято решать за программиста такие вопросы, он должен сам выбрать нужно ему это или нет для оптимальной производительности.
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, C0x, Вы писали:
C0x>>Но как вам решение проблемы деструкции данных класса через базовый класс?
V>В Qt есть базовый класс, называется QObject. Наследуешься от него естественно не забывая про метаобъектный компилятор, а когда создаёшь объект в куче присваиваешь родителя. Удалишь родительский объект, удалишь и дочерние объекты. V>Другой вариант использовать умный указатель, но это везде в C++ и не по одной реализации в каждой библиотеке. Есть различные виды умных указателей. Классический, как только пропадают все ссылки на объект в куче, так он автоматически уничтожается.
Я имел ввиду проблемы деструкции в момент исключения в конструкторах. Удаление может быть не тривиальной операцией и содержать логику. Простыми умными указателями тут не обойтись. Но мне нужно гарантировать что уничтожение пройдет правильно в любом случае даже если объект не до конца создан.
C0x>>Со своей стороны я вижу очевидный плюс такого подхода — нет лишних методов типа Release, Close и т.д.
V>А вот это я думаю вовсе не лишние методы, а так специально спроектированная система. Если сделали методы вроде открыть, закрыть, например, для файла или соединения с базой данных, то это как бы разработчики непрозрачно намекают, чтобы программист управлял вручную всем этим хозяйством пока существует объект с этими методами. V>Автоматическое освобождение любых ресурсов не проблема, просто в C++ не принято решать за программиста такие вопросы, он должен сам выбрать нужно ему это или нет для оптимальной производительности.
Вот я сейчас как раз поэтому задался этим вопросом, потому-что создаю библиотеку которая работает с кучей видео-аудио потоков. Мне было очевидно использовать Open, Close, потому-что это сходит из самых низов — Си, открыть, закрыть в нужный момент. Но я сейчас смотрю на это все и понимаю, а ведь есть такая штука как RAII, и будет дурно не использовать эту возможность которую дает тебе сам язык. Пробую теперь обойтись без Open/Close, возможно и не получится. Но в любом случае хочется построить красивый стройный код, без необходимости (ой, забыл вызвать Close перед этим другим Close).
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, velkin, Вы писали:
V>>Другой вариант использовать умный указатель, но это везде в C++ и не по одной реализации в каждой библиотеке. Есть различные виды умных указателей. Классический, как только пропадают все ссылки на объект в куче, так он автоматически уничтожается.
C0x>Я имел ввиду проблемы деструкции в момент исключения в конструкторах. Удаление может быть не тривиальной операцией и содержать логику. Простыми умными указателями тут не обойтись. Но мне нужно гарантировать что уничтожение пройдет правильно в любом случае даже если объект не до конца создан.
Какой нетривиальной операцией и какую логику? У тебя в пример вызывается просто ReleaseHeavyResource1. Это обычным std::unique_ptr делается:
Ну и аналогично со всеми другими умными указателями.
Просто используешь в своём классе не голый HANDLE, а этот тип: std::unique_ptr<HANDLE, ReleaseHeavyResource1Deleter> _someHandle1 = NULL; — и его ресурсы будут освобождены как при нормальном разрушении объекта, так и при любых исключениях в конструкторе или в другом месте.
Здравствуйте, Basil2, Вы писали:
B>Но обычно в таком случае делается класс-обертка для конкретного типа ресурсов. Тогда весь код выглядит так:
В простых случаях да, это поможет. Но если нужна сложная логика освобождения? Я видел какие-то велосипеды с shared_ptr куда пихается лямбда функция с какой-то логикой, но это как-то помоему велосипедно слишком выглядит и не похоже на какой-то общий паттерн, который можно по всей либе юзать.
Здравствуйте, watchmaker, Вы писали:
W>Здравствуйте, C0x, Вы писали:
W>Просто используешь в своём классе не голый HANDLE, а этот тип: std::unique_ptr<HANDLE, ReleaseHeavyResource1Deleter> _someHandle1 = NULL; — и его ресурсы будут освобождены как при нормальном разрушении объекта, так и при любых исключениях в конструкторе или в другом месте.
Хм, спасибо, видал уже где-то такое, можно еще и лямбду в птр зафигачить при желании. Но как-то это страшно все потом выглядит. На лапшу похоже.
Здравствуйте, PlushBeaver, Вы писали:
PB>Здравствуйте, C0x, Вы писали:
C0x>>Но как вам решение проблемы деструкции данных класса через базовый класс? Т.е. пихаем все ресурсные поля класса в базовый класс, который умеет их зачищать в деструкторе. После того как в нашем классе в конструкторе вылетает исключение, в любом случае вызовится деструктор базового класса и он освободит ресурсы. Есть такой подход в Си++ мире или лучше так не делать?
PB>Сложно --- наследование и шаблоны на ровном месте, ненадежно --- можно забыть освободить ресурс или освободить не в том порядке. Пусть каждый ресурс будет отдельным объектом с RAII в составе A.
Мне вот это почему-то тоже кажется сложным. У меня есть типы типа HANDLE, оборачивать их в спец объект ради одной простой цели — надежного уничтожения везде и всегда кажется черезчурным. Да и хочется не с врапперами в коде работать а с исходными типами (видить их в полях класса и возращаемых зачениях функций). Смартпоинтеры на мой личный взгляд это в целом костыль, который превращает код в лапшу.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, C0x, Вы писали:
C0x>> A() C0x>> { C0x>> _someHandle1 = LoadHeavyResource1(); //Тут может быть исключение C0x>> _someHandle2 = LoadHeavyResource2(); //Тут может быть исключение C0x>> _someHandle3 = LoadHeavyResource3(); //Тут может быть исключение C0x>> }
C0x>> ~A_Data() C0x>> { C0x>> if (_someHandle1 != NULL) ReleaseHeavyResource1(_someHandle1); C0x>> if (_someHandle2 != NULL) ReleaseHeavyResource2(_someHandle2); C0x>> if (_someHandle3 != NULL) ReleaseHeavyResource3(_someHandle3); C0x>> }
TB>Каждая пара LoadHeavyResource1()-ReleaseHeavyResource1 должна быть в отдельном объекте. TB>Один объект — один ресурс.
Попробую объяснить свою думку. Мне использование спец. объектов (те же смартпоинтеры) для уничтожения кажется большим костылем. И такие костыли вызывают у программистов на Си#/Java насмешки типа "Да у вас там в Си++ всё на костылях и костылями погоняете". А вот моё решении, на мой опять же взгляд, более похоже на четкий паттерн для решения задачи освобождения ресурсов заданного класса на базе языковой конструкции и порядка вызова деструкторов. И вот это мне кажется более аккуратным способом, чем тот же "костыль" IDisposable в C# для управления освобождением ресурсов.
Здравствуйте, C0x, Вы писали:
C0x>Попробую объяснить свою думку. Мне использование спец. объектов (те же смартпоинтеры) для уничтожения кажется большим костылем.
Вообще-то это и есть использование RAII по назначению. Только не смартпоинтер, конечно. А именно HWND_Holder, DC_Holder итд
Здравствуйте, C0x, Вы писали:
C0x>Попробую объяснить свою думку. Мне использование спец. объектов (те же смартпоинтеры) для уничтожения кажется большим костылем. И такие костыли вызывают у программистов на Си#/Java насмешки типа "Да у вас там в Си++ всё на костылях и костылями погоняете". А вот моё решении, на мой опять же взгляд, более похоже на четкий паттерн для решения задачи освобождения ресурсов заданного класса на базе языковой конструкции и порядка вызова деструкторов. И вот это мне кажется более аккуратным способом, чем тот же "костыль" IDisposable в C# для управления освобождением ресурсов.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, Basil2, Вы писали:
B>>Но обычно в таком случае делается класс-обертка для конкретного типа ресурсов. Тогда весь код выглядит так:
C0x>В простых случаях да, это поможет. Но если нужна сложная логика освобождения? Я видел какие-то велосипеды с shared_ptr куда пихается лямбда функция с какой-то логикой, но это как-то помоему велосипедно слишком выглядит и не похоже на какой-то общий паттерн, который можно по всей либе юзать.
А какая разница вызывается эта сложная логика после того как освобождаемый ресурс стал не нужен или же в случае раскрутки стека из-за исключения?
Просто не забывать про SOLID и делать классы максимально простыми — первая же буква S.
Каждому типу ресурса соответствует один маленький класс-обёртка над ним, в том случае, т.к. логика освобождения ресурсов различается по их типам.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, T4r4sB, Вы писали:
TB>>Каждая пара LoadHeavyResource1()-ReleaseHeavyResource1 должна быть в отдельном объекте. TB>>Один объект — один ресурс.
C0x>Попробую объяснить свою думку. Мне использование спец. объектов (те же смартпоинтеры) для уничтожения кажется большим костылем. И такие костыли вызывают у программистов на Си#/Java насмешки типа "Да у вас там в Си++ всё на костылях и костылями погоняете". А вот моё решении, на мой опять же взгляд, более похоже на четкий паттерн для решения задачи освобождения ресурсов заданного класса на базе языковой конструкции и порядка вызова деструкторов. И вот это мне кажется более аккуратным способом, чем тот же "костыль" IDisposable в C# для управления освобождением ресурсов.
Базовые классы и наследование от них — это инструмент взаимозаменяемости. Когда клиент класса освобождается от знания о том, какой же на самом деле тип ему был передан для использования.
Все другие варианты использования наследования — типа ради попыток запихнуть в базовый класс повторяющуюся функциональность — это от лукавого — по канонам ООП должно делаться через агрегированием с делегированием внешних вызовов.
Причин тому миллион.
Здравствуйте, C0x, Вы писали:
C0x>Я имел ввиду проблемы деструкции в момент исключения в конструкторах. Удаление может быть не тривиальной операцией и содержать логику. Простыми умными указателями тут не обойтись. Но мне нужно гарантировать что уничтожение пройдет правильно в любом случае даже если объект не до конца создан.
Умный указатель всего лишь решает проблему автоматического удаления объекта, как вариант, когда на него больше никто не ссылается. А конструктор и деструктор это методы, или как в C++ принято функции-члены. В них можно поместить любую логику, или просто вызов функций отвечающих за эту логику.
То есть new в случае указателей и умных указателей запустит один из конструкторов, а delete запустит деструктор, но в случае с умными указателями последний может вызваться так сказать автоматически согласно запрограммированной логике.
Я уж забыл из какого это источника, но там говорилось что-то вроде того, что помните, конструктор и деструктор это методы (функции-члены). Это вроде бы кажется очевидным, но люди об этом забывают, когда создают классы. С тем же успехом можно было написать свою собственную реалиацию, ну то есть void my_new() или void my_delete(), а потом при создании объекта вызвать их вручную.
В каком-то смысле все эти конструкции языка C++ не более, чем синтаксический сахар. Точно так же как другие операторы, ведь как бы они не выглядели это просто функции члены или друзья. Важно ведь не то, что конкретно написано в данном случае, важно то, что программист хочет этим выразить.
привет, подобная машинерия лишь усложняет код на ровном месте, и то что автору кажется "удобным" становится головной болью для мэйнтейнеров кода. Как ad-hoc решение используется тайпдеф а std::unique_ptr с кастомным делетером, о чём уже упомянуто выше, или нужно не полениться и написать таки враппер для конкретного типа хендла.
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, C0x, Вы писали:
V>В каком-то смысле все эти конструкции языка C++ не более, чем синтаксический сахар. Точно так же как другие операторы, ведь как бы они не выглядели это просто функции члены или друзья. Важно ведь не то, что конкретно написано в данном случае, важно то, что программист хочет этим выразить.
На самом деле все не совсем так. Я стараюсь не использовать new и deleted в своих программах, а создавать объекты на стеке. Также я стараюсь писать логику программы зная один очень полезный факт из мира Си, объекты на стеке удаляюься сразу же по выходу из блока кода, а это значит автоматический вызов деструктора. Например в языке Go ввели специальную конструкцию derer для того чтобы что-то сделать по выходу из блока и в нужном порядке, а тут бесплатно.
Здравствуйте, Мирный герцог, Вы писали:
МГ>Здравствуйте, C0x, Вы писали:
C0x>>Привет,
МГ>привет, подобная машинерия лишь усложняет код на ровном месте, и то что автору кажется "удобным" становится головной болью для мэйнтейнеров кода. Как ad-hoc решение используется тайпдеф а std::unique_ptr с кастомным делетером, о чём уже упомянуто выше, или нужно не полениться и написать таки враппер для конкретного типа хендла.
То есть тебе не кажется странным использовать объект с именем unique_ptr для совершенно другой цели — выполнить логику удаления? Это я и называю костылями — использования не по назначению типов. Что касается врапперов над хэндлами все ок,пока логика — просто удалить хэндл, а если чуть сложнее то уже придется городить ещё кучу объектов непонятного назначения.
Здравствуйте, C0x, Вы писали:
PB>>Сложно --- наследование и шаблоны на ровном месте, ненадежно --- можно забыть освободить ресурс или освободить не в том порядке. Пусть каждый ресурс будет отдельным объектом с RAII в составе A.
C0x>Мне вот это почему-то тоже кажется сложным. У меня есть типы типа HANDLE, оборачивать их в спец объект ради одной простой цели — надежного уничтожения везде и всегда кажется черезчурным.
Три даже не класса, а typedef'а для unique_ptr, каждый из которых делает одну простую вещь, сложнее, чем один класс, который в конструкторе и деструкторе жонглирует тремя хэндлами? Бонусом смартпоинтеры запретят копирование A, но разрешает его перемещение.
C0x>Да и хочется не с врапперами в коде работать а с исходными типами (видить их в полях класса и возращаемых зачениях функций).
А почему? Например, по HANDLE нельзя сказать, мы владеем этим объектом или нам его дали откуда-то и уничтожат вовне, а по Resource vs const Resource& или Resource vs HANDLE это видно, если не использовать голые хэндлы и указатели как владеющие (что сейчас рекомендуемая практика, кроме Qt). Насчет draw(HANDLE brush, HANDLE dc) против draw(const Brush& brush, const DC& dc) можно поспорить, что скрывается сущность ресурсов, но на мой взгляд, читаемость выше, а за точными типами пусть компилятор следит.
C0x>Смартпоинтеры на мой личный взгляд это в целом костыль, который превращает код в лапшу.
"Лапша" в данном случае в том, что вместо ApiFunc(resource1) придется писать ApiFunc(resource1.get()). Но это как раз и хорошо, что нельзя отдать куда-то хэндл и не подумать о владении им. Смартпоинтеры не просто автоматически освобождают ресурс, они еще и делают логику использующего их кода проще (не надо описывать освобождение, копирование, перемещение) и безопаснее (заставяют думать о владении).
Здравствуйте, C0x, Вы писали:
C0x>Также я стараюсь писать логику программы зная один очень полезный факт из мира Си, объекты на стеке удаляюься сразу же по выходу из блока кода, а это значит автоматический вызов деструктора.
Но тут тоже есть свои минусы, указатель то всяко быстрее переместить в памяти, чем всю структуру, плюс по указателю можно многократно ссылаться на одну и ту же структуру. Где-то имеет смысл стек данных, а где-то выгоднее использовать указатель.
Я даже читал как-то такую отмазу, что это не Java такая тормознутая, это повёрнутые на абстракциях программисты сделали из неё тормознутую. А если вроде как писать в другом стиле, то всё будет не так уж и плохо.
C++ традиционно считается быстрым, но так ли это? А дело то не в том, что он быстрый сам по себе, а в том, что программисты всё же стараются выбирать наиболее быстрые решения.
Когда программисты говорят, а вот у нас есть в языке такая то особая функция, а вот у вас её нет. Так без проблем, эти функции можно создать самим, если уж так надо.
Если мне нравится некая абстракция, а на самом деле это будет просто уродское решение, да ещё и тормознутое, могу ли я сказать, что идите вы все, я так вижу, или попытаться понять чуждую философию.
Некоторые считают, что C++ это язык с низким уровнем абстракции, потому что он позволяет вытворять низкоуровневые штучки. Но лично я бы сказал, что это язык с избыточным уровнем абстракций и пользуясь всеми возможностями можно зайти очень далеко.
Вот тот же механизм исключений в C++, если вдуматься это высокоуровневая абстракция. Её можно использовать, если нужны исключения, вопрос в том, можно ли обойтись без исключений. Это всё не так однозначно, а к примеру, в .NET я бы по аналогии напихал их везде и даже не стал бы думать над такими вопросами.
Здравствуйте, C0x, Вы писали:
C0x>Надоели всякие Begin, End, Open, Close методы в программах. Хочу придерживаться принципа RAII.
А почему он вас так привлекает? Или только потому что миллионы мух не ошибаются?
Гораздо логичнее что бы за все ресурсы, которые использует объект, отвечал не он, а тот кто заставил его работать.
Так в любой момент можно его пристрелить остановить и не торопясь освобождать то что он использовал, не заботясь о том в каком состоянии он умер.
Более того сразу можно смотреть что он использовал, сколько и ограничивать ресурсы по ходу выполнения если необходимо.
Здравствуйте, C0x, Вы писали:
C0x>То есть тебе не кажется странным использовать объект с именем unique_ptr для совершенно другой цели — выполнить логику удаления? Это я и называю костылями — использования не по назначению типов. Что касается врапперов над хэндлами все ок,пока логика — просто удалить хэндл, а если чуть сложнее то уже придется городить ещё кучу объектов непонятного назначения.
А зачем тогда у unique_ptr, shared_ptr есть такая возможность если не для этого
Здравствуйте, C0x, Вы писали:
C0x>Попробую объяснить свою думку. Мне использование спец. объектов (те же смартпоинтеры) для уничтожения кажется большим костылем. И такие костыли вызывают у программистов на Си#/Java насмешки типа "Да у вас там в Си++ всё на костылях и костылями погоняете".
Хочу, говорит, RAII использовать. А потом заявляет, что это костыль. Занятно.
А вообще, все эти высказывания про костыли, они ведь от непонимания. Или от поверхностного понимания, что еще хуже.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
C0x>>Здравствуйте, Basil2, Вы писали:
B>>>Но обычно в таком случае делается класс-обертка для конкретного типа ресурсов. Тогда весь код выглядит так:
C0x>>В простых случаях да, это поможет. Но если нужна сложная логика освобождения? Я видел какие-то велосипеды с shared_ptr куда пихается лямбда функция с какой-то логикой, но это как-то помоему велосипедно слишком выглядит и не похоже на какой-то общий паттерн, который можно по всей либе юзать.
A>А какая разница вызывается эта сложная логика после того как освобождаемый ресурс стал не нужен или же в случае раскрутки стека из-за исключения?
Меня интересует только второй случай, потому-что ресурс в любом случае станет не нужен как-только объект содержащий его будет уничтожен. У меня ресурсы не шарятся между объектами.
A>Просто не забывать про SOLID и делать классы максимально простыми — первая же буква S.
В моем случае SOLID то же вроде как не нарушается. У меня есть 1 базовый класс, делающий только одно — Release данных которые собственно сам же и представляет.
Здравствуйте, PlushBeaver, Вы писали:
PB>Здравствуйте, C0x, Вы писали:
PB>>>Сложно --- наследование и шаблоны на ровном месте, ненадежно --- можно забыть освободить ресурс или освободить не в том порядке. Пусть каждый ресурс будет отдельным объектом с RAII в составе A.
C0x>>Мне вот это почему-то тоже кажется сложным. У меня есть типы типа HANDLE, оборачивать их в спец объект ради одной простой цели — надежного уничтожения везде и всегда кажется черезчурным.
PB>Три даже не класса, а typedef'а для unique_ptr, каждый из которых делает одну простую вещь, сложнее, чем один класс, который в конструкторе и деструкторе жонглирует тремя хэндлами? Бонусом смартпоинтеры запретят копирование A, но разрешает его перемещение.
Конструктор и деструктор изначально для этого и нужны в Си++ у каждого объекта, чтобы его данные можно было подчищать. То что программисты ленивые и придумывают костыли, чтобы не забыть что-то удалить, это нормально, но это костыли порожденные пороком
C0x>>Да и хочется не с врапперами в коде работать а с исходными типами (видить их в полях класса и возращаемых зачениях функций).
PB>А почему? Например, по HANDLE нельзя сказать, мы владеем этим объектом или нам его дали откуда-то и уничтожат вовне, а по Resource vs const Resource& или Resource vs HANDLE это видно, если не использовать голые хэндлы и указатели как владеющие (что сейчас рекомендуемая практика, кроме Qt). Насчет draw(HANDLE brush, HANDLE dc) против draw(const Brush& brush, const DC& dc) можно поспорить, что скрывается сущность ресурсов, но на мой взгляд, читаемость выше, а за точными типами пусть компилятор следит.
Ну например хотя бы потому, что код работающий с Хэндлами легко найти на Github, а если его завернуть во Wrapper то на Гитхаб будет помойка из разнородного кода, который вроде бы делает одно и то же но при этом выглядит совершенно по разному.
C0x>>Смартпоинтеры на мой личный взгляд это в целом костыль, который превращает код в лапшу.
PB>"Лапша" в данном случае в том, что вместо ApiFunc(resource1) придется писать ApiFunc(resource1.get()). Но это как раз и хорошо, что нельзя отдать куда-то хэндл и не подумать о владении им.
Нет не хорошо, потому-что нужно придерживаться принципа KISS и YAGNI, иначе мы будем думать о многом, а в итоге нам нужно просто вызвать API функции и передать туда тупа Хэндл.
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, C0x, Вы писали:
C0x>>Также я стараюсь писать логику программы зная один очень полезный факт из мира Си, объекты на стеке удаляюься сразу же по выходу из блока кода, а это значит автоматический вызов деструктора.
V>Но тут тоже есть свои минусы, указатель то всяко быстрее переместить в памяти, чем всю структуру, плюс по указателю можно многократно ссылаться на одну и ту же структуру. Где-то имеет смысл стек данных, а где-то выгоднее использовать указатель.
Нет, я видимо не правильно объяснил. Я стараюсь в логике алгоритмов не использовать указателей, а только стэковые объекты и ссылки на них. Передача объектов по ссылке по скорости то же самое или даже быстрее чем по указателю. New и Delete я конечно же буду использовать там где мне нужно выделять болшие массивы данных, например передавать картинки или звуковые потоки. Но эти данные будут завернуты внутри простых объектов у которых будет просто ссылка на эти данные и естественно деструктор который их почистит (либо vector<BYTE>).
V>Если мне нравится некая абстракция, а на самом деле это будет просто уродское решение, да ещё и тормознутое, могу ли я сказать, что идите вы все, я так вижу, или попытаться понять чуждую философию.
На то мы и программисты, чтобы делать то что нам нравится. Другое дело, что это не всегда можно пустить в Продакшен. Вот мне лично нравится жонглировать Шаблонами, я люблю в Си++ по максимуму использовать Шаблоны, кому-то это покажется сложным или тормозным и т.д. и т.п., но я лично считаю что Шаблоны например одно из самых крутых фич языка Си++.
V>Некоторые считают, что C++ это язык с низким уровнем абстракции, потому что он позволяет вытворять низкоуровневые штучки. Но лично я бы сказал, что это язык с избыточным уровнем абстракций и пользуясь всеми возможностями можно зайти очень далеко.
V>Вот тот же механизм исключений в C++, если вдуматься это высокоуровневая абстракция. Её можно использовать, если нужны исключения, вопрос в том, можно ли обойтись без исключений. Это всё не так однозначно, а к примеру, в .NET я бы по аналогии напихал их везде и даже не стал бы думать над такими вопросами.
Я начал писать свою библиотеку и старался опираться везде на коды ошибок. Потом столкнулся с проблемой что эти коды в 99% нужно переводить в строковое описание. В итоге пришел к тому, что проще кидать исключения со строками чем городить кучу не нужного кода.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
C0x>>Здравствуйте, T4r4sB, Вы писали:
TB>>>Каждая пара LoadHeavyResource1()-ReleaseHeavyResource1 должна быть в отдельном объекте. TB>>>Один объект — один ресурс.
C0x>>Попробую объяснить свою думку. Мне использование спец. объектов (те же смартпоинтеры) для уничтожения кажется большим костылем. И такие костыли вызывают у программистов на Си#/Java насмешки типа "Да у вас там в Си++ всё на костылях и костылями погоняете". А вот моё решении, на мой опять же взгляд, более похоже на четкий паттерн для решения задачи освобождения ресурсов заданного класса на базе языковой конструкции и порядка вызова деструкторов. И вот это мне кажется более аккуратным способом, чем тот же "костыль" IDisposable в C# для управления освобождением ресурсов.
A>Базовые классы и наследование от них — это инструмент взаимозаменяемости.
Поклонники ООП считают что это их инструмент, а я не поклонник и смотрю на это просто как на инструмент Языка.
A>по канонам ООП должно делаться через агрегированием с делегированием внешних вызовов.
Си++ не был бы Си++ если бы не был мультипарадигменным языком, поэтому Каноны ООП это лишь каноны ООП.
Здравствуйте, wander, Вы писали:
W>Здравствуйте, C0x, Вы писали:
C0x>>Попробую объяснить свою думку. Мне использование спец. объектов (те же смартпоинтеры) для уничтожения кажется большим костылем. И такие костыли вызывают у программистов на Си#/Java насмешки типа "Да у вас там в Си++ всё на костылях и костылями погоняете".
W>Хочу, говорит, RAII использовать. А потом заявляет, что это костыль. Занятно.
Смартпоинтер и RAII это одно и тоже?
W>А вообще, все эти высказывания про костыли, они ведь от непонимания. Или от поверхностного понимания, что еще хуже.
Естественно, за любым костылем лежит целая история причинно-следственных связей. Ну вот к примеру взять Смартпоинтер. Любой программист на языке с GC скажет что это очевидно костыль, просто потому-что у вас ребята нет GC, но вы пытаетесь обойти этот недостаток пихая во все щели свои смартпоинтеры. Программист на Си++99 смотря на смартпоинтер скажет что это костыль, потому-что вы лентяи и не можете аккуратно писать код и следить за указателями и хэндлами.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, a7d3, Вы писали:
A>>по канонам ООП должно делаться через агрегированием с делегированием внешних вызовов.
C0x>Си++ не был бы Си++ если бы не был мультипарадигменным языком, поэтому Каноны ООП это лишь каноны ООП.
И всего их две штуки — процедурная и ОО. Потому и выбор между — либо крестик снять, либо трусы надеть.
Это идиом с подходами в С++ много, но они все в рамках или процедурного (модульного) программирования или же ООП.
Так что или соблюдаешь ООП или идёшь дальше клянчить или выдумывать свои паттерны.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
C0x>>Здравствуйте, a7d3, Вы писали:
A>>>по канонам ООП должно делаться через агрегированием с делегированием внешних вызовов.
C0x>>Си++ не был бы Си++ если бы не был мультипарадигменным языком, поэтому Каноны ООП это лишь каноны ООП.
A>И всего их две штуки — процедурная и ОО. Потому и выбор между — либо крестик снять, либо трусы надеть. A>Это идиом с подходами в С++ много, но они все в рамках или процедурного (модульного) программирования или же ООП. A>Так что или соблюдаешь ООП или идёшь дальше клянчить или выдумывать свои паттерны.
А вот тут ты не прав. Есть ещё шаблоны и стат.программирование, ни с процедурами ни с ООП они ничего общего не имеют и дают совершенно интересные решения по сравнению с классическим ООП.
Здравствуйте, C0x, Вы писали:
... C0x>Смартпоинтеры на мой личный взгляд это в целом костыль, который превращает код в лапшу.
Нужно только разобраться со смартпоинтерами — и Ваше мнение о них изменится! Они станут Вашими друзьями.
На самом деле — это очень толковая штука, решающая многие проблемы, и прежде всего — высвобождения ресурсов.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, a7d3, Вы писали:
A>>А какая разница вызывается эта сложная логика после того как освобождаемый ресурс стал не нужен или же в случае раскрутки стека из-за исключения?
C0x>Меня интересует только второй случай, потому-что ресурс в любом случае станет не нужен как-только объект содержащий его будет уничтожен. У меня ресурсы не шарятся между объектами.
A>>Просто не забывать про SOLID и делать классы максимально простыми — первая же буква S.
C0x>В моем случае SOLID то же вроде как не нарушается. У меня есть 1 базовый класс, делающий только одно — Release данных которые собственно сам же и представляет.
Вопрос был в принципе, для понимания и анализа — проведения параллелей и осмысления. Сегодня интересует одно, а завтра другое — это не повод смотреть кусками, местами и урывками.
Сначала надо было уйти от классов управляющих множеством ресурсов напрямую. Если есть минимально возможные обёртки над ресурсами, каждым типом в отдельности, то это следование SRP.
А вот пихать эти классы-обёртки в качестве базовых, строя иерархию сугубо ради повторного использования кода — это нарушение LSP.
Здравствуйте, C0x, Вы писали:
... C0x>Нет не хорошо, потому-что нужно придерживаться принципа KISS и YAGNI, иначе мы будем думать о многом, а в итоге нам нужно просто вызвать API функции и передать туда тупа Хэндл.
ИМХО повседневная практика разработки софта — это как раз компромисс между минимальщиной (KISS & YAGNI) и реальной оценкой требований Заказчика.
И если есть надёжный и полезный для практики C++ инструмент, такой как смарт-поинтеры, то как раз отказ от его применения и есть ошибка
Здравствуйте, C0x, Вы писали:
C0x>Я стараюсь в логике алгоритмов не использовать указателей, а только стэковые объекты и ссылки на них. Передача объектов по ссылке по скорости то же самое или даже быстрее чем по указателю.
Можно пример кода, в котором передача указателя на стековый объект куда-то была бы медленнее, чем передача ссылки на такой же стековый объект?
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, a7d3, Вы писали:
A>>Здравствуйте, C0x, Вы писали:
A>>И всего их две штуки — процедурная и ОО. Потому и выбор между — либо крестик снять, либо трусы надеть. A>>Это идиом с подходами в С++ много, но они все в рамках или процедурного (модульного) программирования или же ООП. A>>Так что или соблюдаешь ООП или идёшь дальше клянчить или выдумывать свои паттерны.
C0x>А вот тут ты не прав. Есть ещё шаблоны и стат.программирование, ни с процедурами ни с ООП они ничего общего не имеют и дают совершенно интересные решения по сравнению с классическим ООП.
Это какая-то своя терминология от любителя изобретать свои паттерны? Чем не устраивает общепринятая?
По крайней мере нужна для того, чтобы получалось комуницировать с собратьями по разуму.
Моё раздражение вызвано тем, что в С++ вечно лезут кулибины, которые ни языка, ни средств его, ни идиом с парадигмами не знают, но очень хотят себе пространство для самовыражения найти. Свою гениальность миру показать, ничего не изучая и не осваивая.
Для примера, в данном случае, в этом треде достаточно знать про делегирование конструкторов и вопрос решается — освоением средств языка.
А можно и лучше через SRP SOLID — каждому типу сделать свой класс отвечающий за стратегию захвата и освобождения. Тогда класс использующий эти ресурсы, будет отвечать лишь за порядок захвата (выделения) и освобождения.
Здравствуйте, a7d3, Вы писали:
C0x>>А вот тут ты не прав. Есть ещё шаблоны и стат.программирование, ни с процедурами ни с ООП они ничего общего не имеют и дают совершенно интересные решения по сравнению с классическим ООП.
A>Это какая-то своя терминология от любителя изобретать свои паттерны? Чем не устраивает общепринятая?
Сложно сказать, что такое "стат.программирование", но вот шаблоны в C++ -- это обобщенное программирование (generic programming), еще одна парадигма, доступная в C++ наряду с процедурным подходом и ООП. И это общепринятая формулировка.
Здравствуйте, C0x, Вы писали:
...
C0x>Хм, спасибо, видал уже где-то такое, можно еще и лямбду в птр зафигачить при желании. Но как-то это страшно все потом выглядит. На лапшу похоже.
Когда всё четко уложено в сознании — не будет ощущения "лапши"!
Важно понимать, что smart-pointers основаны на принцыпе подсчёта ссылок на объект.
Когда счётчик ссылок уйдёт в ноль — то автоматически сработает деструктор объекта.
Здравствуйте, уважаемый velkin, Вы писали:
V>Умный указатель всего лишь решает проблему автоматического удаления объекта, когда на него больше никто не ссылается.
Так корректнее.
V>А конструктор и деструктор это методы, или как в C++ принято функции-члены.
Специализированные методы — так точнее.
V>В них можно поместить любую логику, или просто вызов функций отвечающих за эту логику.
Но обычно — в конструкторе то, что создаёт конкретный объект, в деструкторе — то, что конкретный объект уничтожает.
V>То есть new в случае указателей и умных указателей запустит один из конструкторов,
Да, но здесь потребуется вручную (в Вашем коде) указывать конкретный конструктор (у класса может быть несколько перегруженных конструкторов).
V>а delete запустит деструктор, но в случае с умными указателями последний может вызваться так сказать автоматически согласно запрограммированной логике.
Да, delete запустит деструктор — автоматически (без указания явного вызова delete в Вашем коде) при использовании smart-pointer (умного указателя).
V>Я уж забыл из какого это источника, но там говорилось что-то вроде того, что помните, конструктор и деструктор это методы (функции-члены).
Специализированные функции-члены.
Здравствуйте, C0x, Вы писали:
C0x>Я видел какие-то велосипеды с shared_ptr куда пихается лямбда функция с какой-то логикой, но это как-то помоему велосипедно слишком выглядит и не похоже на какой-то общий паттерн, который можно по всей либе юзать.
shared_ptr используется потому, что в С++ до сих пор нет готового класса для вызова кода по выходу из блока.
C0x>В простых случаях да, это поможет. Но если нужна сложная логика освобождения?
То вам придется писать сложный код в деструкторе. Не принципиально, будет это деструктор shared_ptr или ваш собственный. Но в любом случае непонятно, зачем вам в данной ситуации наследование.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, C0x, Вы писали:
C0x>Привет,
C0x>давно не писал на плюсах, вот вернулся снова и понеслась душа в пляс
C0x>Надоели всякие Begin, End, Open, Close методы в программах. Хочу придерживаться принципа RAII.
Чем не RAII спрятать конструктор и вызывать его в статической функции, типа Create? Внутри все ресурсы резервируются, обёрнутые в try-catch. Она или правильный указатель будет возвращать, null или exception будет кидать в случае ошибки. Или на стеке тоже очень надо уметь инициализироваться?
А в конструкторе не надо исключения кидать. Это моветон.
Здравствуйте, C0x, Вы писали:
C0x>Смартпоинтер и RAII это одно и тоже?
Смартпойнтер — это воплощение идеи RAII. И речь не про конкретный условный unique_ptr, а в целом про концепцию объекта-владельца. Не нравится вам unique_ptr — всегда можно сделать к нему алиас, или написать свой, или взять готовый чужой — это чисто технический момент. Но все эти решения следуют одной концепции. Судя по тому, что вы возразили каждому, кто предлагал один из этих вариантов — вы отвергаете саму концепцию, а значит отвергаете и RAII.
C0x>Естественно, за любым костылем лежит целая история причинно-следственных связей. Ну вот к примеру взять Смартпоинтер. Любой программист на языке с GC скажет что это очевидно костыль, просто потому-что у вас ребята нет GC, но вы пытаетесь обойти этот недостаток пихая во все щели свои смартпоинтеры. Программист на Си++99 смотря на смартпоинтер скажет что это костыль, потому-что вы лентяи и не можете аккуратно писать код и следить за указателями и хэндлами.
Я и говорю — непонимание.
Особенно это:
C0x> пихая во все щели
А с пониманием станет ясно, что далеко не во все щели.
И продолжая вашу аналогию, программист на языке без GC должен считать наличие GC костылем (мол, чего это они сами не могут за ресурсами следить)? Это очень поверхностное суждение.
Любой язык с GC являет нам его составной частью своей концепции. То, что задумано изначально, не может быть костылем по определению.
RAII — был задуман изначально. Первые обобщенные реализации смартпойнтеров в открытом доступе появились уже в 90-м году.
И это было просто использование концепции и инструмента по назначению.
Здравствуйте, C0x, Вы писали:
C0x>То есть тебе не кажется странным использовать объект с именем unique_ptr для совершенно другой цели — выполнить логику удаления?
Вообще управления владением и доступом к имуществу. Это единственная семантика этого умного указателя == реализовать эксклюзивное владение.
Если твой большой объект владеет этим ресурсом (хэндлом, потоком и т. п.) эксклюзивно, то использовать std::unique_ptr -- прямой способ выразить это отношение на современном C++
Кстати, unique_ptr -- это не имя объекта, а часть имени типа объекта.
Из него не надо выводиться, сделай его полем с понятным именем, и будет просто и понятно.
C0x>Это я и называю костылями — использования не по назначению типов. Что касается врапперов над хэндлами все ок,пока логика — просто удалить хэндл,
А какое, по твоему, назначение std::unique_ptr ?
C0x>а если чуть сложнее то уже придется городить ещё кучу объектов непонятного назначения.
С этого места хотелось бы пример, что конкретно имеется в виду.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
C0x>>>А вот тут ты не прав. Есть ещё шаблоны и стат.программирование, ни с процедурами ни с ООП они ничего общего не имеют и дают совершенно интересные решения по сравнению с классическим ООП.
A>>Это какая-то своя терминология от любителя изобретать свои паттерны? Чем не устраивает общепринятая?
S>Сложно сказать, что такое "стат.программирование", но вот шаблоны в C++ -- это обобщенное программирование (generic programming), еще одна парадигма, доступная в C++ наряду с процедурным подходом и ООП. И это общепринятая формулировка.
Как будто обобщенное программирование является взаимоисключающим с процедурным и/или же ООП, таким же образом как и они между собой.
Для примера — модель акторов является взаимоисключащей с CSP? Вот так же и тут с обобщеным программированием.
Здравствуйте, a7d3, Вы писали:
A>Как будто обобщенное программирование является взаимоисключающим с процедурным и/или же ООП, таким же образом как и они между собой.
Вообще-то речь об этом:
A>И всего их две штуки — процедурная и ОО.
В С++, как минимум, три парадигмы из коробки: процедурное программирование, ООП и обобщенное. Хотя можно еще и про функциональщину говорить (скажем, в compile-time на шаблонах или на constexpr функциях), но это уже менее очевидно и может быть предметом спора.
Так что когда COx говорит о том, что парадигм в C++ не две, то он более прав, чем вы.
A>Для примера — модель акторов является взаимоисключащей с CSP?
Вообще-то да. Поскольку или-или. Т.е. либо вы кусок кода пишете на акторах одним способом, либо на CSP другим. И дополнять они могут друг-друга только если разные куски программы написаны по-разному.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Для примера — модель акторов является взаимоисключащей с CSP?
S>Вообще-то да. Поскольку или-или. Т.е. либо вы кусок кода пишете на акторах одним способом, либо на CSP другим. И дополнять они могут друг-друга только если разные куски программы написаны по-разному.
Именно, а выбирая обобщённое программирование человек может писать либо в рамках процедурного, либо в ООП.
Потому что нет выбора «обобщённое или ООП» как и нет выбора «обобщённое или процедурное».
Здравствуйте, a7d3, Вы писали:
A>Именно, а выбирая обобщённое программирование человек может писать либо в рамках процедурного, либо в ООП.
Вы заблуждаетесь.
A>Потому что нет выбора «обобщённое или ООП» как и нет выбора «обобщённое или процедурное».
Есть.
Попробуйте написать sort в каждой из этих трех парадигм и вы увидите, что вы вынуждены принимать разные проектные решения. Что будет выражаться на уровне даже интерфейса sort. Не говоря уже про детали реализации. И последствия. В частности, a) невозможность скрытия реализации шаблонных функций/классов в DLL/so, и b) ресурсоемкость компиляции обобщенного кода.
S>В С++, как минимум, три парадигмы из коробки: процедурное программирование, ООП и обобщенное. Хотя можно еще и про функциональщину говорить (скажем, в compile-time на шаблонах или на constexpr функциях), но это уже менее очевидно и может быть предметом спора.
Иван Чукич вполне обосновал Функциональное программирование на С++. С помощью чистых функций, как оно и требуется. И каррирование у него там есть, и монады. Ленивые вычисления тоже, но это еще раньше было понятно, до него.
Так что 4 парадигмы — однозначно.
И еще метапрограммирование на шаблонах, которое тоже функциональное.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, so5team, Вы писали:
S>Попробуйте написать sort в каждой из этих трех парадигм и вы увидите, что вы вынуждены принимать разные проектные решения. Что будет выражаться на уровне даже интерфейса sort. Не говоря уже про детали реализации. И последствия. В частности, a) невозможность скрытия реализации шаблонных функций/классов в DLL/so, и b) ресурсоемкость компиляции обобщенного кода.
Зачем в трёх? Почему не в четырёх?
Первое в процедурном с шаблонами (дженериками) и второе — ООП с шаблонами.
И ещё два — просто в процедурном и просто в ООП.
Само по себе обобщённое программирование не бывает, оно либо процедурное, либо на базе ООП.
Здравствуйте, a7d3, Вы писали:
S>>Попробуйте написать sort в каждой из этих трех парадигм и вы увидите, что вы вынуждены принимать разные проектные решения.
A>Зачем в трёх? Почему не в четырёх?
Потому что выше было сказано, что в C++ гарантированно поддерживаются три парадигмы. А по поводу четвертой можно спорить, есть ли поддержка ФП в C++ или нет: кто-то считает, что есть, кто-то -- что нет.
И вот в рамках трех парадигм (процедурная, объектная, обобщенная) у вас sort будет совершенно разный.
A>Само по себе обобщённое программирование не бывает, оно либо процедурное, либо на базе ООП.
Бывает. В Generic Programming функции и классы являются всего лишь строительными блоками, поэтому вам может казаться, что есть процедурное GP, и есть объектное GP.
Здравствуйте, so5team, Вы писали:
A>>Само по себе обобщённое программирование не бывает, оно либо процедурное, либо на базе ООП.
S>Бывает. В Generic Programming функции и классы являются всего лишь строительными блоками, поэтому вам может казаться, что есть процедурное GP, и есть объектное GP.
А почему не процедурное с шаблонами/дженериками и не ООП с шаблонами/дженериками?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
S>>>Попробуйте написать sort в каждой из этих трех парадигм и вы увидите, что вы вынуждены принимать разные проектные решения.
A>>Зачем в трёх? Почему не в четырёх?
S>Потому что выше было сказано, что в C++ гарантированно поддерживаются три парадигмы. А по поводу четвертой можно спорить, есть ли поддержка ФП в C++ или нет: кто-то считает, что есть, кто-то -- что нет.
Бред был сказан и сейчас отсылка идёт к этому уже сказанному бреду.
Как одна из форм хамства и отказа аргументировать собственное мнение.
Говорят в деревнях с глубинками и на промышленных производствах до сих пор так принято общаться с коллегами и подчинёнными.
Здравствуйте, a7d3, Вы писали:
A>Говорят в деревнях с глубинками и на промышленных производствах до сих пор так принято общаться с коллегами и подчинёнными.
Да, мы народ простой. Чуть что, сразу конкретный пример. Ну а если этот пример столичной штучке с тонкой душевной организации не нравится, ну это не наши проблемы. Мы не огорчаемся от того, что ваше мнение оказывается бездоказательным.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Говорят в деревнях с глубинками и на промышленных производствах до сих пор так принято общаться с коллегами и подчинёнными.
S>Да, мы народ простой. Чуть что, сразу конкретный пример. Ну а если этот пример столичной штучке с тонкой душевной организации не нравится, ну это не наши проблемы. Мы не огорчаемся от того, что ваше мнение оказывается бездоказательным.
Конкретика где? Только бредовые утверждения на уровне псевдорелигиозных верований и попытки ссылаться на них.
Где пример того, насколько и чем конкретно обобщённое программирование на С++ отличается от ООП обыкновенного?
Такого плана, когда визави и содержимое STL знакомо, и SOLID & DI/IoC не чужды.
Для чего? Чтобы показать состоятельность и самостоятельность «обощённого программирования». Приводящую к необходимости выбирать между ним или процедурным или ООП.
В примере с sort. Разницу между процедурным и обобщенным программированием легко увидеть на cppreference (тыц раз, тыц два). Аналог sort-а на чистом ООП оставлю вам в качестве домашнего задания.
A>Где пример того, насколько и чем конкретно обобщённое программирование на С++ отличается от ООП обыкновенного?
А вы решите пример с sort-ом и сами увидите. Ну или можете посмотреть в сторону policy/trait-based подходов. В частности, почему в C++ для контейнеров аллокаторы или компараторы задаются посредством параметров шаблонов, а не через "ООП обыкновенный" с интерфейсами, наследованием и виртуальными методами.
Кроме того, обобщенное программирование в C++ вынуждено применять элементы из "типа ООП" потому, что в C++ даже struct -- это уже элемент ООП (так уж вышло, что между struct и class в С++ лишь косметические различия). И даже такие вещи, как tuple или sum types в C++ вынуждено выражаются через class. Тогда как будь в языке отдельное понятие для tuple и sum type (как, скажем, в Rust), то можно было бы увидеть и обобщенное программирование вообще без элементов ООП.
Как раз все это в сумме и позволяет говорить об Generic Programming как об отдельной парадигме.
A>Для чего? Чтобы показать состоятельность и самостоятельность «обощённого программирования». Приводящую к необходимости выбирать между ним или процедурным или ООП.
Выбор приходится делать. Причины излагались выше. И в этом посте, и выше по обсуждению.
Ну и на правах записного хама позволю себе ткнуть вас в _полное_ отсутствие каких-либо примеров с вашей стороны. Видимо, столичные штучки привыкли, что им верят на слово после употребления SOLID, DI, IoC и других страшных слов. В нашей деревне не прокатывает, звиняйте.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, C0x, Вы писали:
C0x>>Я стараюсь в логике алгоритмов не использовать указателей, а только стэковые объекты и ссылки на них. Передача объектов по ссылке по скорости то же самое или даже быстрее чем по указателю.
S>Можно пример кода, в котором передача указателя на стековый объект куда-то была бы медленнее, чем передача ссылки на такой же стековый объект?
Я допустил такую возможность ввиду компиляторных оптимизаций, но скорее всего я ошибаюсь.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
A>от любителя изобретать свои паттерны?... Моё раздражение вызвано тем, что в С++ вечно лезут кулибины...
Здравствуйте, 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-м году писали ООП программы на чистом Си и полиморфизм был и наследования.
Вы сейчас зачем эту ссылку привели?
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 (память):
Здравствуйте, C0x, Вы писали: C0x>Например в нужном порядке провести релиз ресурсов, и по условию либо закрыть файлы, либо удалить их, если запись прошла не успешно на момент вызова деструктора, и в зависимости от этого отправить пуш нотификацию в центр. C0x>Т.е. суть в том что деструктор может резилить ресурсы не тупым способом а по определенной логике в зависимости от состояния объекта на текущий момент.
По умолчанию деструктор разрушает ресурсы в порядке обратном объявлению их как RAII-членов данных.
Если нужно другое поведение, то надо что-то свое наколхозить.
Тут уже правильно подсказывали с делегирурющим конструктором для пометки объекта ка полностью сконструированного, но есть и другие варианты.
В одном из проектов надо было при входе в приложение инициализировать заранее неизвестный список ресурсов, а при выходе их освобождать в порядке обратном инициализации. Стандатрный подход с членами данных, даже и опциональными, тут не прокатывает, надо накапливать список ресурсов с функциями их освобождения в рантайм.
Здравствуйте, 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.
Апеллирование к мнению реальных или дутых авторитетов — это смешно, но ещё веселее, когда апеллирующий отказывается видеть то, на что сам же и ссылается. Страуструп говорит о возможности использования в С++ обобщённого программирования именно как о стиле и технике, а не парадигме. И если непонятно почему именно такие определения с формулировками, то стоит задуматься не один раз и не два.
Итак, к чему была ссылка на статью про trait-ы?
A>Ненаглядный ООП никак не конкретизирует варианты полиморфизма и потому не важно какой именно используется в конкретном языке, и отдельно взятом случае — статический или же динамический или же оба сразу. Меньше или больше ООП не становится от того, какой именно полиморфизм был выбран программирующим.
Во-вторых, на чем базируются эти утверждения?
Классический ООП -- это инкапсуляция, наследование и полиморфизм, где под полиморфизимом понималось позднее связывание. Т.е. то, какая именно реализация метода будет вызвана, определялось в run-time. Что автоматически делает неприменимым статический полиморфизм по отношению к ООП.
Если вы утверждаете, что для ООП не важно, какой именно полиморфизм применяется, то остается разве что узнать -- это какая-то общепринятая точка зрения или это ваше личное и безаппеляционное мнение.
A>Generic programming является стилем программирования, а не парадигмой и это давным давно закреплено на уровне определений, после того как это вопрос мусолился туеву тучу лет назад. Известен данный стиль ещё с 1970-х годов, а generics как и parameterized types использовались ещё в ранних 90-х и встречаются в ранних изданиях таких книжек как GoF.
Из того, что generic programming известен давно вовсе никак не следует, что generic programming не является парадигмой (тем более, что сам термин "парадигма" он не слишком четкий).
A>Апеллирование к мнению реальных или дутых авторитетов — это смешно, но ещё веселее, когда апеллирующий отказывается видеть то, на что сам же и ссылается. Страуструп говорит о возможности использования в С++ обобщённого программирования именно как о стиле и технике, а не парадигме. И если непонятно почему именно такие определения с формулировками, то стоит задуматься не один раз и не два.
В-третьих, Страуструп и об ООП говорит как о стиле, а не о парадигме. Тем не менее, ООП является вполне себе парадигмой.
В-четвертых, я ссылаюсь на вещи, которые высказывались раньше и более-менее устоялись. Т.е. это не моя личная придурь и не мои личные заблуждения (а если и заблуждения, то не только мои личные).
А вот вы высказываете свою собственную точку зрения которая еще где-нибудь находит подтверждение? Или это все из категории "я так сказал"?
Буду очень признателен, если вы перестанете выбрасывать из разговора пункты, которые вам не удобны, и сможете ответить предметно по каждому из заданных вам вопросов. Сомневаюсь, что вы сможете. Но буду признателен если таки.
C0x>Продолжая твою логику ООП это всего лишь процедурное программирование с диспетчеризацией вызовов нужных функций в зависимости от... Кстати, мы еще в далеком 2003-м году писали ООП программы на чистом Си и полиморфизм был и наследования.
C0x>Почитай книгу https://www.ozon.ru/context/detail/id/2260909/
может по другому будешь немного смотреть на парадигмы в целом и в Си++ в частности.
У ненаглядного ООП есть чёткое и однозначное определение, если оно не знакомо, то не надо этим своим невежеством размахивать на форумах. Хочется ООП, значит надо обеспечить три из трёх — инкапсуляцию, полиморфизм и наследование.
И обсуждение здесь, в этом треде, идёт с того, что некоторые личности отказывались понять на кой лад в ООП нужно наследование. А заодно, как оказалось отрицают и все 40 лет развития да осмысления ООП, как подхода к программированию и созданию кода.
Теперь же выясняется, что эта же персона ни сном ни духом даже о столь элементарных вещах, как существовании классического и однозначного определения ООП. Превосходно, это сделало мой день
Например, в языке C имеется превосходная поддержка инкапсуляции. Рассмотрим простую программу на C:
Пользователи point.h не имеют доступа к членам структуры Point. Они могут вызывать функции makePoint() и distance(), но не имеют никакого представления о реализации структуры Point и функций для работы с ней.
Это отличный пример поддержки инкапсуляции не в объектно-ориентированном языке. Программисты на C постоянно использовали подобные приемы. Мы можем объявить структуры данных и функции в заголовочных файлах и реализовать их в файлах реализации. И наши пользователи никогда не получат доступа к элементам в этих файлах реализации.
Ни разу не отношу себя к адептам Дяди Боба, особенно имея представление о том насколько его книги расходятся с его же 40 годами опыта боевого разработчика. Седовласый гандурас, Роберт Мартин, очень даже прав в данном конкретном случае.
Здравствуйте, so5team, Вы писали:
S>Буду очень признателен, если вы перестанете выбрасывать из разговора пункты, которые вам не удобны, и сможете ответить предметно по каждому из заданных вам вопросов. Сомневаюсь, что вы сможете. Но буду признателен если таки.
Что за попытки сразу пачкой обсуждать очень разные вопросы, расположенные довольно далеко друг от друга? А потом ещё и претензии предъявлять, что эти попытки пресекаются и не поощряются?
Есть очень простое правило — всё, что отходит от основной канвы обсуждения — это должно идти отдельным письмом или отдельным постом. А если же оно идёт в купе с основным, то считается риторическими вопросами. Призванными продемонстрировать, что собеседник чего-то не понял или чему-то удивился.
Здравствуйте, a7d3, Вы писали:
A>Что за попытки сразу пачкой обсуждать очень разные вопросы, расположенные довольно далеко друг от друга? А потом ещё и претензии предъявлять, что эти попытки пресекаются и не поощряются?
Пресекать и не поощрять взялся хз кто, единственным обоснованием чьих слов является "я так сказал". Ну ок, звездун, так звездун.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3
S>Во-первых, было бы очень хорошо, если бы вы смогли ответить на вопрос, который вам был задан, а именно:
S>
Что за манеры, любезный? Диалог с позиции постоянных наездов и претензий с разнообразными предъявлениями?
Это психологическая защита сработала, пытающаяся оттолкнуть собеседника, чтобы тот ни в коем случае не поколебал привычную картину давно сложившегося маня мирка?
Очень сомнительно, чтобы собеседник не сообразил из контекста обсуждения, что смотреть надо на дату публикации, в связки с тем, о чём в ней излагается.
Здравствуйте, 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 посмотреть.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, C0x, Вы писали:
C0x>... C0x>Как раз все наоборот получилось, некоторые личности отказываются упорно понять, что C++ и ООП это разные вещи. То что я пишу в коде Си "class" вообще не означает ООП. Если я захочу следовать канонам ООП я могу им даже в чистом Си следовать, я тебе уже об этом выше говорил. C0x>... A>>[q] A>>Например, в языке C имеется превосходная поддержка инкапсуляции. Рассмотрим простую программу на C:
C0x>Круто! И дальше то что?
Так уже упоминалось — или трусы надеть, или крестик снять.
Либо не использовать С++ вообще — отложить его подальше, либо выбрать парадигму и решать задачи создания кода только лишь в рамках выбранной парадигмы.
Здравствуйте, a7d3, Вы писали:
S>>Итак, к чему была ссылка на статью про trait-ы?
A>Что за манеры, любезный?
Нормальные, цензурные и даже без перехода на личности. В отличии от.
A>Очень сомнительно, чтобы собеседник не сообразил из контекста обсуждения, что смотреть надо на дату публикации, в связки с тем, о чём в ней излагается.
Еще раз прямой вопрос: с какой целью вы привели ссылку на статью про trait-ы?
Нужен прямой ответ, который бы не заставил меня додумывать за вас.
Здравствуйте, a7d3, Вы писали:
A>На том, что характер и тип полиморфизма, упоминаемого в ООП нигде, никогда и никем не конкретизировался.
Конкретизировался. Про то, что в ООЯ полиморфизим реализуется именно как late binding пишут повсюду. Воспользуйтесь гуглом (вот например). Или хотя бы в Wikipedia загляните (тыц раз вместе с цитатой из Алана Кея, тыц два).
A>Любая попытка додумывать в духе «под полиморфизимом понималось позднее связывание» — это краеугольный камень для последующих заблуждений с домыслами. Её следует отследить до первоисточника и поинтересоваться «какого фига» да «с какой целью» человек выплеснул в мир эту дезинформацию.
Позволю себе дать совет: хватит звиздеть. Если все, что вы можете сказать в подтверждение своей точки зрения -- это "я так сказал", то можете больше не трудится. Вы уже окрасили себя в те цвета...
Здравствуйте, σ, Вы писали:
_>>Гораздо логичнее что бы за все ресурсы, которые использует объект, отвечал не он, а тот кто заставил его работать. σ>https://youtu.be/rwOv_tw2eA4?t=1611
Нет, я имею ввиду что в языке должна быть возможность отанавливать потоки не переводя программу в UB.
И всё сваливать на RAII это не очень хорошо. С++ никогда не сможет работать на оборудовании со сбоями.
Мне больше такой подход нравиться.
Здравствуйте, 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>Да и хочется не с врапперами в коде работать а с исходными типами (видить их в полях класса и возращаемых зачениях функций).
Можно и в возвращаемых значениях и в аргументах функций, а обёртку использовать для владения ресурсом и задать там конструкторы и операторы приведения типов.
Здравствуйте, so5team, Вы писали:
S>Еще раз прямой вопрос: с какой целью вы привели ссылку на статью про trait-ы?
S>Нужен прямой ответ, который бы не заставил меня додумывать за вас.
Больше двадцати лет, в контексте С++, идут эти разговоры — о том, какова роль обобщённого программирования.
И до сих пор, в результате всех принятых стандартов, оно так и не стало отдельной парадигмой.
За всё это время нет работ (публикаций), которые обосновали бы, что дескать статический полиморфизм обобщённого программирования якобы выходит за рамки ООП, создавая собственную отдельную парадигму.
Здравствуйте, C0x, Вы писали:
C0x>Конструктор и деструктор изначально для этого и нужны в Си++ у каждого объекта, чтобы его данные можно было подчищать.
Но не обязательно же в них работать только с сырыми данными. Деструктор по умолчанию, который вызовет деструкторы членов-смартпоинтеров --- это то же самое, только писать код не надо. Вас же не смущает, что если в объекте лежат два вектора, не надо вручную следить за их удалением?
C0x>>>Да и хочется не с врапперами в коде работать а с исходными типами (видить их в полях класса и возращаемых зачениях функций).
PB>>А почему? <skip>
C0x>Ну например хотя бы потому, что код работающий с Хэндлами легко найти на Github, а если его завернуть во Wrapper то на Гитхаб будет помойка из разнородного кода, который вроде бы делает одно и то же но при этом выглядит совершенно по разному.
А еще переменные по-своему названы и скобки по-разному расставлены --- на GitHub'е нет поиска по структуре кода, а ищут обычно по имени функции API.
PB>>"Лапша" в данном случае в том, что вместо ApiFunc(resource1) придется писать ApiFunc(resource1.get()). Но это как раз и хорошо, что нельзя отдать куда-то хэндл и не подумать о владении им.
C0x>Нет не хорошо, потому-что нужно придерживаться принципа KISS и YAGNI, иначе мы будем думать о многом, а в итоге нам нужно просто вызвать API функции и передать туда тупа Хэндл.
О чем нужно и не нужно думать --- вопрос уровня абстракции. Смартпоинтеры как раз берут на себя все вопросы, как сделать так, чтобы объект единолично владел ресурсом, пока сам жив. Вам остается думать только о решении задачи уровнем выше, где есть просто операция "взять имеющийся ресурс". В сухом остатке со смартпоинтерами код короче и не загроможден чисто языковыми вещами, вроде промежуточного класса с данными (ваша идея), делегирования конструкторов (из соседней ветки), удаления конструктора копирования.
Отличная демонстрация, почему в соседних ветках правильно советуют готовый 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.".
Здравствуйте, so5team, Вы писали:
S>Я вас отправил смотреть в сторону policy/trait based подхода для того, чтобы вы сами могли увидеть как в GP легко и непринужденно делается то, что в классическом ООП или нельзя сделать, или же это делается гораздо сложнее, менее эффективно и менее надежно.
За 20 с лишним лет никто не смог развить обобщённое программирование в С++ до отдельной самостоятельной парадигмы. Всё эти вещи, сродни policy/trait based подхода — давно известные баяны и тянут лишь на некий стиль/вариант программирования в рамках или процедурной парадигмы или же ООП.
Отказ видеть и понимать очевидные вещи — это проблемы с которыми надо к психоаналитику/психотерапевту. Пусть поможет с прохождением каких-то там личностных кризисов и переосмыслением собственной профессиональной значимости с достижениями.
Здравствуйте, Мирный герцог, Вы писали:
МГ>Здравствуйте, so5team, Вы писали:
S>>Конкретизировался. Про то, что в ООЯ полиморфизим реализуется именно как late binding пишут повсюду. Воспользуйтесь гуглом (вот например). Или хотя бы в Wikipedia загляните (тыц раз вместе с цитатой из Алана Кея, тыц два).
МГ>Как следствие C++ это ООП язык
Я тебе больше скажу, Erlang ООП язык и даже на чистом Си можно писать в стиле ООП.
Здравствуйте, so5team, Вы писали:
S>Надо же, персонаж, который заявлял буквально "Апеллирование к мнению реальных или дутых авторитетов — это смешно" внезапно переобулся в воздухе и требует цитат и ссылок на источники. Так их есть у меня. S> ... S>Но даже без отсылок к авторитетам, исходя из здравого смысла путем только логических заключений легко прийти к выводу, что в ООП полиморфизм существует только на уровне поведения объектов, а поведение объектов обеспечивается реализацией их методов (операций). Изменение поведения происходит за счет переопределения метода в наследнике (объекте-наследнике при прототипном ООП или классе-наследнике при классовом ООП). А механизм позднего (динамического) связывания обеспечивает вызов должного метода даже если вызов делается через ссылку на родителя.
S>Поэтому никакого статического (параметрического) полиморфизма в класическом ООП нет.
S>Но вы можете и дальше отрицать очевидные вещи.
Очередная настойчивая попытка выдавать желаемое за действительное.
В приводимом нет ничего о том, почему не может использоваться другой вариант полиморфизма. Авторы цитат всего лишь показывают самый простой для понимания и толкования вариант реализаций. Потому что в этих местах своих работ они должны привести нечто, что в их понимании может считаться полиморфизмом.
И вопрос был не в том, чтобы поковыряться во мнениях авторитетов. А сводится к — есть ли работы, в которых обосновывалось и показывалось бы, что в ООП полиморфизм может и должен быть сугубо динамическим. Или что он гарантированно не может и не должен быть статическим.
В который раз уже приходится обращать внимание на это?
Хватит клоунады с подменами и откровенно безумными притягиваниями за уши, разбавленными поисками поводов для наезда на собеседника. Уровень вашей культуры диалога, глубина личностно-профессиональных кризисов давно ясны и понятны.
Ваша способность упорно отрицать объективную реальность может посоревноваться разве что с вашим же желанием высказать что-либо нелицеприятное в адрес собеседника.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, a7d3, Вы писали:
A>>Здравствуйте, C0x, Вы писали:
A>>Но парадигмы то всего три: A>>
A>>процедурное A>>функциональное A>>объектно-ориентированное A>>
C0x>Любовь к самограничению я смотрю во всём
C0x>Я там выше ссылку на умную книжку кидал, там парадигм больше чем у тебя
Умные книжки — это которые обосновывают, не просто перечисляют и транслируют с целью ознакомления/обзора для читателя.
Строгая систематизация это скорее самодисциплина, нежели самоограничение.
В остальном же, в разработке софта (создании кода), вещи надо делать максимально простыми и внятными, как и во многих других инженерных дисциплинах.
Делегирующие конструкторы в С++ один из таких примеров — просто и внятно решает ту проблему, из-за которой появился этот тред. На кой хрен при этом суетиться с наследованием, вынося функциональность в базовый класс и нарушая принципы ООП — это совершенно непонятно.
Да и глупо заниматься творчеством (отсебятиной). Особенно, так толком и не освоив инструментарий (С++), и на том поприще, где уже тридцать лет толкутся миллионы людей.
Здравствуйте, so5team, Вы писали:
S>Ваша способность упорно отрицать объективную реальность может посоревноваться разве что с вашим же желанием высказать что-либо нелицеприятное в адрес собеседника.
Так будет отсылка хотя бы на одну работу, обосновывающую неприменимость или неприемлемость статического полиморфизма в рамках парадигмы ООП?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>За 20 с лишним лет никто не смог развить обобщённое программирование в С++ до отдельной самостоятельной парадигмы.
S>В 1991-1992 годах это смог сделать Алекс Степанов. А уж продолжателей было... Один Александреску чего стоит.
S>И не будь GP отдельной самостоятельной парадигмой, не было бы для нее отдельного раздела здесь: https://en.wikipedia.org/wiki/Programming_paradigm
Очередной притягивание за уши. Саша никогда не полагал, что занимаясь обобщёнными програмиированием создал или развил новую парадигму. Что мешает спросить у него лично? Если так уж хочется притащить в данный спор мнение этого человека, устроив отсылку к авторитетом, за неимением собственных аргументов.
Касаемо ссылок на википедию, то это очень напоминает отсылку к «давно и широко известным вещам» с устоявшимися убеждениями большинства.
S>Но вам никто не запрещает верить во что угодно. Раз уж столько всего интересного и важного прошло мимо вас.
Что мешает написать письмо Степанову и просить лично у него, разделяет ли автор STL ваши верования с заблуждениями. Вот только аккуратнее с формулировками, чтобы очередной раз не сесть в лужу из-за явной попытки натянуть сову на глобус.
Здравствуйте, a7d3, Вы писали:
A>Так будет отсылка хотя бы на одну работу, обосновывающую неприменимость или неприемлемость статического полиморфизма в рамках парадигмы ООП?
Сверх того, что уже было, включая цитаты из Кея, Мейера и Буча? Нет, конечно.
Здравствуйте, a7d3, Вы писали:
S>>И не будь GP отдельной самостоятельной парадигмой, не было бы для нее отдельного раздела здесь: https://en.wikipedia.org/wiki/Programming_paradigm
A>Очередной притягивание за уши.
Это всего лишь ваше оценочное суждение. Которое ничего не стоит просто в силу того, что вы, собственно, никто и звать вас никак.
A>Саша никогда не полагал, что занимаясь обобщёнными програмиированием создал или развил новую парадигму.
Его личное мнение ничего не изменит. Он может относиться к результатам своего труда как угодно. Получившегося результата это не изменит.
Так же мнение Степанова не влияет на то, является ли GP новой парадигмой или нет.
Собственно, новизна или неновизна GP здесь так же не является предметом обсуждения, если вы еще не поняли. Так что хватит апеллировать к "новизне" или "баянам".
Но если вас все же мнение авторитета волнует (что противоречит вашим же словам), то спросите у него сами.
A>Касаемо ссылок на википедию, то это очень напоминает отсылку к «давно и широко известным вещам» с устоявшимися убеждениями большинства.
Если вы еще не в курсе, сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. Сам факт фиксации этого набора взглядов в Wikipedia может считаться достаточным для того, чтобы считать GP именно что парадигмой.
Безотносительно к тому, что по этому поводу думаете вы или Алекс Степанов.
A>Что мешает написать письмо Степанову и просить лично у него, разделяет ли автор STL ваши верования с заблуждениями. Вот только аккуратнее с формулировками, чтобы очередной раз не сесть в лужу из-за явной попытки натянуть сову на глобус.
Вам же ничего не мешает верить в ООП с параметрическим полиморфизимом. Не удивлюсь, если это посложнее натягивания совы на глобус будет.
Здравствуйте, kov_serg, Вы писали:
_>>>Гораздо логичнее что бы за все ресурсы, которые использует объект, отвечал не он, а тот кто заставил его работать. σ>>https://youtu.be/rwOv_tw2eA4?t=1611 _>Нет, я имею ввиду что в языке должна быть возможность отанавливать потоки не переводя программу в UB. _>И всё сваливать на RAII это не очень хорошо. С++ никогда не сможет работать на оборудовании со сбоями. _>Мне больше такой подход нравиться.
Почему это никогда? Если в С++ добавят std::process и он будет достаточно легким (легковесным), то отличия от Эрланга будут косметическими.
Здравствуйте, Мирный герцог, Вы писали:
МГ>это определение из твоих же ссылок, ты в адеквате?
Это попытка поговорить с вами на вашем же языке.
Но если вы свой же язык не понимаете, то пожалуйста, попробуем по-человечески:
1. "Ахинею не неси" относилось не к определениям из Wikipedia, а к вашему оценочному суждению, а именно: "Я вот, разделяю определение по ссылке на late binding, и считаю что vtable это static binding, а late binding это именно когда "method is looked up by name at runtime."." То, что вы считаете "vtable это static binding" -- это и есть "ахинея". Могу объяснить почему так думаю.
2. Ссылки на Wikipedia были даны не потому, что Wikipedia является истиной в последней инстанции. А потому что это одно из легконаходимых мест, в которых полиморфизм и позднее (динамическое) связывание упоминаются в контексте ООЯ. Ибо a7d3 не верил, что такое вообще происходит.
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. With late binding the compiler does not read enough information to verify the method exists or bind its slot on the v-table. Instead the method is looked up by name at runtime.
я считаю написанным неправильно. Могу расписать почему, но сейчас на это нет времени.
Тем не менее, в этом же разделе касательно late binding в C++ написано вполне пристойно:
In C++, late binding (also called "dynamic binding") refers to what normally happens when the virtual keyword is used in a method's declaration. C++ then creates a so-called virtual table, which is a look-up table for such functions that will always be consulted when they are called.[6] Usually, the "late binding" term is used in favor of "dynamic dispatch".
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
C0x>>Здравствуйте, a7d3, Вы писали:
A>>>Здравствуйте, C0x, Вы писали:
A>>>Но парадигмы то всего три: A>>>
A>>>процедурное A>>>функциональное A>>>объектно-ориентированное A>>>
C0x>>Любовь к самограничению я смотрю во всём
C0x>>Я там выше ссылку на умную книжку кидал, там парадигм больше чем у тебя
A>Умные книжки — это которые обосновывают, не просто перечисляют и транслируют с целью ознакомления/обзора для читателя.
Умные книжки, это книжки, которые написаны умными людьми, которые в теме понимают побольше меня и тебя вместе взятых.
A>Строгая систематизация это скорее самодисциплина, нежели самоограничение.
Хорошо, если тебе так больше нравится.
A>В остальном же, в разработке софта (создании кода), вещи надо делать максимально простыми и внятными, как и во многих других инженерных дисциплинах.
Ага, и в целом программировать надо правильно и хорошо! И код писать надо без ошибок.
Время простых и внятных вещей осталось в мире чистого Си. Само по себе ООП это уже костыль, а не серебренная пуля. И этим костылем далеко не все проблемы хорошо решаются.
A>Делегирующие конструкторы в С++ один из таких примеров — просто и внятно решает ту проблему, из-за которой появился этот тред. На кой хрен при этом суетиться с наследованием, вынося функциональность в базовый класс и нарушая принципы ООП — это совершенно непонятно.
Я извиняюсь, но не работает "Делегирующие конструкторы" в моем коде. У меня вся архитектура построена на стэковых объектах и ссылочной связи между ними. Делегирующий конструктор если я правильно понимаю нельзя вызывать если у меня в классе в полях ссылки есть. Меня свой подход я не собираюсь ради вызова делегирующего конструктора.
A>Да и глупо заниматься творчеством (отсебятиной). Особенно, так толком и не освоив инструментарий (С++), и на том поприще, где уже тридцать лет толкутся миллионы людей.
Я творчеством занимался еще до того как в STL Си++ появились нормальные смартпоинтеры и делегирующие конструкторы. После 10-ти летней паузы не все стандартны успел изучить. Поэтому кстати и пришел сюда, со своей бедой.
S>1. "Ахинею не неси" относилось не к определениям из Wikipedia, а к вашему оценочному суждению, а именно: "Я вот, разделяю определение по ссылке на late binding, и считаю что vtable это static binding, а late binding это именно когда "method is looked up by name at runtime."." То, что вы считаете "vtable это static binding" -- это и есть "ахинея". Могу объяснить почему так думаю.
Объясни.
S>я считаю написанным неправильно. Могу расписать почему, но сейчас на это нет времени.
Распиши.
S>Тем не менее, в этом же разделе касательно late binding в C++ написано вполне пристойно:
пристойно, потому что тебе оно нравится?
Для тех кто в 90-х ещё под стол пешком ходил поясняю, понятие late binding пришло вместе с dll, а стало на слуху позже с COM, и оно означает именно то что я написал, "method is looked up by name at runtime."
Здравствуйте, Мирный герцог, Вы писали:
S>>1. "Ахинею не неси" относилось не к определениям из Wikipedia, а к вашему оценочному суждению, а именно: "Я вот, разделяю определение по ссылке на late binding, и считаю что vtable это static binding, а late binding это именно когда "method is looked up by name at runtime."." То, что вы считаете "vtable это static binding" -- это и есть "ахинея". Могу объяснить почему так думаю.
МГ>Объясни.
Потому что late binding -- это о том, что вызывающая сторона определяет, что именно будет вызвано только в момент произведения вызова. Наличие/отсутствие vtable определяет только технические детали этого процесса, но не меняет принцип.
Так, у нас может быть:
// Фрагмент №1class A {
public:
virtual void f() = 0;
...
};
A * a;
...
a->f(); // (1)
...
// Фрагмент №2.
// Где-то совсем-совсем в другом месте.class Actual_A : public A {
void f() override {...};
...
};
a = new Actual_A(); // (2)
В точке (1) у нас определяется только позиция в vtable, которая должна использоваться для вызова f(). Конкретное значение этой ячейки в vtable при компиляции фрагмента №1 неизвестно.
Точное значение для vtable будет получено только при компиляции фрагмента №2 в точке (2).
Но во время фактического вызова в точке (1) адрес реальной реализации f() будет определен только во время исполнения кода. Что не может в принципе являться static binding.
Поэтому, с моей точки зрения, "vtable это static binding" не соответствует действительности.
S>>я считаю написанным неправильно. Могу расписать почему, но сейчас на это нет времени. МГ>Распиши.
К этому абзацу, есть, как минимум, две претензии:
1. Там сразу подразумевается, что ООЯ языки должны быть компилируемыми и статически-типизированными. Что необязательно должно быть так. Применение vtable и фазы компиляции -- это особенность, характерная для статически-типизированных языков. И если говорить о них, то тогда реализация late binding через vtable имеет смысл. Для динамического ООЯ vtable в принципе может не применяться, а late binding может быть реализован как раз через поиск по имени в словаре (с дальнейшим делегированием в какой-нибудь method_missing при неудаче).
Это два принципиально разных подхода к реализации late binding и, имхо, неправильно смешивать это все в кучу в рамках одного абзаца.
2. То, что компилятор статически-типизированного ООЯ расставляет в местах вызова обращения к конкретным индексам vtable не превращает late binding в static binding по причинам, которые уже были описаны выше. Наглядной демонстрацией отсутствия static binding-а является ручная подгрузка DLL с новой реализацией класса с виртуальными методами и вызов методов из этой новой DLL в старом коде.
S>>Тем не менее, в этом же разделе касательно late binding в C++ написано вполне пристойно: МГ>пристойно, потому что тебе оно нравится?
Потому, что оно не противоречит наблюдаемой уже много лет ральности.
МГ>Для тех кто в 90-х ещё под стол пешком ходил поясняю, понятие late binding пришло вместе с dll, а стало на слуху позже с COM, и оно означает именно то что я написал, "method is looked up by name at runtime."
Dynamic linking может использоваться в качестве реализации late binding. Но то, что о late binding стали много говорить лишь с началом 1990-х, вовсе не означает, что late binding как-то связан с DLL.
<твои заблуждения поскипаны>
S>Dynamic linking может использоваться в качестве реализации late binding. Но то, что о late binding стали много говорить лишь с началом 1990-х, вовсе не означает, что late binding как-то связан с DLL.
в твоей же ссылке на википедию первой же строкой написано: >Late binding, dynamic binding[1], or dynamic linkage
можешь сам додумать, насколько dynamic linkage связано c dll
Здравствуйте, Мирный герцог, Вы писали:
МГ><твои заблуждения поскипаны>
Я так понимаю, что возразить нечего. Ок.
S>>Dynamic linking может использоваться в качестве реализации late binding. Но то, что о late binding стали много говорить лишь с началом 1990-х, вовсе не означает, что late binding как-то связан с DLL.
МГ>в твоей же ссылке на википедию первой же строкой написано: >>Late binding, dynamic binding[1], or dynamic linkage МГ>можешь сам додумать, насколько dynamic linkage связано c dll
Додумывать про dynamic linkage и dll я предоставлю вам, т.к. я говорил про late binding, а не про dynamic linking.
МГ>в microsoft тоже дураки сидят?
Было бы хорошо, если бы статью про late/early binding из COM вы смогли привязать к разговору о связи полиморфизма и late binding в ООП (где П -- это парадигма).
Здравствуйте, so5team, Вы писали:
S>Додумывать про dynamic linkage и dll я предоставлю вам, т.к. я говорил про late binding, а не про dynamic linking.
рация работает на бронепоезде? Повторю ещё раз. Первая строка по ссылке в википедии?
Late binding, dynamic binding[1], or dynamic linkage
late binding or dynamic linkage
late binding or dynamic linkage
late binding or dynamic linkage
S>Было бы хорошо, если бы статью про late/early binding из COM вы смогли привязать к разговору о связи полиморфизма и late binding в ООП (где П -- это парадигма).
П это программирование, и late binding я к ООП привязывать не собираюсь, потому что это ортогональные понятия, и связаны они только в твоей голове.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Maniacal, Вы писали:
M>>А в конструкторе не надо исключения кидать. Это моветон.
S>И давно это стало моветоном?
Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Здравствуйте, Мирный герцог, Вы писали:
МГ>рация работает на бронепоезде? Повторю ещё раз. Первая строка по ссылке в википедии? МГ>Late binding, dynamic binding[1], or dynamic linkage
Претензии к Wikipedia. Почему я привел ссылку на Wikipedia я уже объяснял, перечитайте если до вас не дошло.
S>>Было бы хорошо, если бы статью про late/early binding из COM вы смогли привязать к разговору о связи полиморфизма и late binding в ООП (где П -- это парадигма). МГ>П это программирование, и late binding я к ООП привязывать не собираюсь, потому что это ортогональные понятия, и связаны они только в твоей голове.
Вы ввязались в разговор о парадигмах. В частности о том, что именно подразумевается под полиморфизмом в объектно-ориентированной парадигме. a7d3 не верит, что в классическом ООП есть только динамический полиморфизм. Тогда как в классическом ООП именно динамический полиморфизим, реализуемый посредством позднего связывания (late binding). Подтвержения этому и приводились, в том числе и цитатами из Кея, Мейера и Буча.
То, что вы слишком молоды и для вас late binding -- это нечто тесно завязанная на COM и DLL штука можно понять. Но это не мои проблемы.
Здравствуйте, Maniacal, Вы писали:
S>>И давно это стало моветоном?
M>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, so5team, Вы писали:
S>>Здравствуйте, Maniacal, Вы писали:
M>>>А в конструкторе не надо исключения кидать. Это моветон.
S>>И давно это стало моветоном?
M>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Какая идея хорошая для обработки ошибок в конструкторе?
Здравствуйте, so5team, Вы писали:
S>Претензии к Wikipedia. Почему я привел ссылку на Wikipedia я уже объяснял, перечитайте если до вас не дошло.
я уже понял, что у тебя wishfull thinking в отношении википедии
S>Вы ввязались в разговор о парадигмах. В частности о том, что именно подразумевается под полиморфизмом в объектно-ориентированной парадигме. a7d3 не верит, что в классическом
я ввязался в разговор о late binding, потому что этот термин употреблён не к месту, и тот же кей говорил об "extreme late binding", а именно о диспетчеризации по имени в рантайме, потому что смоллток — только единственная правильная имплементация ООП, а Кей — пророк его (по мнению Кея)
>ООП есть только динамический полиморфизм. Тогда как в классическом ООП именно динамический полиморфизим, реализуемый посредством позднего связывания (late binding). Подтвержения этому и приводились, в том числе и цитатами из Кея, Мейера и Буча.
наша песня хороша, начинай с начала
S>То, что вы слишком молоды и для вас late binding -- это нечто тесно завязанная на COM и DLL штука можно понять. Но это не мои проблемы.
тогда, старпёр, это твои проблемы, т.к. уже выросло поколение, которое понимает late binding именно так, как его понимаю я:
Здравствуйте, Мирный герцог, Вы писали:
S>>Претензии к Wikipedia. Почему я привел ссылку на Wikipedia я уже объяснял, перечитайте если до вас не дошло.
МГ>я уже понял, что у тебя wishfull thinking в отношении википедии
Еще раз: Wikipedia была приведена как легкодоступный источник, в котором говорится про взаимосвязь динамический полиморфизм и late binding.
S>>То, что вы слишком молоды и для вас late binding -- это нечто тесно завязанная на COM и DLL штука можно понять. Но это не мои проблемы.
МГ>тогда, старпёр, это твои проблемы, т.к. уже выросло поколение, которое понимает late binding именно так, как его понимаю я:
Binding is an association of function calls to an object.
The binding of a member function, which is called within an object and is called compiler time or static type or early binding.
All the methods are called an object or class name are the examples of compile time binding
The binding of the function calls an object at the run time is called run time or dynamic or late binding. Late binding is achieved, using virtual methods, the virtual methods are overridden in the derived class as per the specific requirement.
Здравствуйте, Мирный герцог, Вы писали:
МГ>в твоей же ссылке на википедию первой же строкой написано: >>Late binding, dynamic binding[1], or dynamic linkage МГ>можешь сам додумать, насколько dynamic linkage связано c dll
Мне вот интересно, как вы классифицируете следующую ситуацию:
1. Есть DLL a.dll с библиотекой импорта a.lib, из которой экспортируется класс:
class A {
virtual void g() { std::cout << "A::g" << std::endl; }
public:
virtual void f() = 0;
};
2. Есть DLL b.dll с библиотекой импорта b.lib, в которой есть не экспортируемый класс:
class B : public A {
public:
void f() override { g(); std::cout << "B::f" << std::endl; }
};
а экспортируется из b.dll вот такая функция:
A & get() {
static B b;
return b;
}
3. Есть основная программа demo.exe, которая линкуется с a.lib и b.lib:
int main() {
get().f(); // (1)return 0;
}
Вот здесь в точке (1) по вашему мнению что будет иметь место: late binding, dynamic linkage или что-то другое?
Здравствуйте, C0x, Вы писали:
C0x>Хм, спасибо, видал уже где-то такое, можно еще и лямбду в птр зафигачить при желании. Но как-то это страшно все потом выглядит. На лапшу похоже.
Лямбда удобна когда нужно сделать при удалении несколько операций, или твой закрывающий метод требует каких-то дополнительных параметров. Если освобождение ресурса тривиально, то она не нужна.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, T4r4sB, Вы писали:
TB>Вообще-то это и есть использование RAII по назначению. Только не смартпоинтер, конечно. А именно HWND_Holder, DC_Holder итд
Это на каждый чих что ли по холдеру? Стандартные смартпоинтеры как раз избавят тебя от размножения сущностей.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, C0x, Вы писали:
C0x>То есть тебе не кажется странным использовать объект с именем unique_ptr для совершенно другой цели — выполнить логику удаления? Это я и называю костылями — использования не по назначению типов. Что касается врапперов над хэндлами все ок,пока логика — просто удалить хэндл, а если чуть сложнее то уже придется городить ещё кучу объектов непонятного назначения.
Так проблема в названии класса? Ну сделай алиас и используй его.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, C0x, Вы писали:
C0x>Конструктор и деструктор изначально для этого и нужны в Си++ у каждого объекта, чтобы его данные можно было подчищать. То что программисты ленивые и придумывают костыли, чтобы не забыть что-то удалить, это нормально, но это костыли порожденные пороком
C0x>Нет не хорошо, потому-что нужно придерживаться принципа KISS и YAGNI, иначе мы будем думать о многом, а в итоге нам нужно просто вызвать API функции и передать туда тупа Хэндл.
подсказываю KISS подход к работе с ресурсами — заворачиваешь каждый ресурс требующий удалять его в деструкторе в unique_ptr и не пишешь больше деструкторы, т.к. компилятор будет генерировать деструкторы за тебя, про HANDLE компилятор ничего не знает, это сущность, время жизни которой в коде не выражена явно, а куча неявных assumptions в коде усложняет его
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, T4r4sB, Вы писали:
TB>>Как? И причём тут поинтеры, если нам нужна стековая сущность, держащая DC?
Ops>Так смартпоинтеры — это только название такое, они могут что угодно держать.
Название кривое.
По поводу сущностей — какая разница они один фиг создают новый тип с соотвествющим деструктором. И разве не короче написать
Здравствуйте, AleksandrN, Вы писали:
M>>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
AN>Какая идея хорошая для обработки ошибок в конструкторе?
Есть такая книжка хорошая, только не помню как называется, что-то типа "С++ для профессионалов", что-то то там про количество советов было в названии.
Конструктор не должен бросать исключений принципиально. Можно статическую функцию-конструктор запилить, которая конструирует объект и кидает исключение, если что не так, освобождая ресурсы. Любо. Но тут мы выходим в анлайк ТС. Он не хочет никакие Опены и Клоузы. Так что это не тема для разговора. "Надо, Федя, надо!" (с)
Здравствуйте, T4r4sB, Вы писали:
TB>Название кривое.
Что выросло — то выросло. Странно, что все не привыкли.
TB>По поводу сущностей — какая разница они один фиг создают новый тип с соотвествющим деструктором. И разве не короче написать
TB>
Короче чем unique_ptr<HDC> smart_dc(dc, &ReleaseDC);? Вряд ли.
Добавлю, что твой велосипед неизвестен другому программисту, и ему, возможно, придется смотреть код, а еще кто-то может написать такой класс по-своему для другого ресурса, и будут разные "холдеры" с разными неконсистентными интерфейсами. А unique_ptr (или шаред, зависит от задачи) стандартные, сразу понятно чем они занимается и как с ними работать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, AleksandrN, Вы писали:
M>>>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
AN>>Какая идея хорошая для обработки ошибок в конструкторе?
M>Есть такая книжка хорошая, только не помню как называется, что-то типа "С++ для профессионалов", что-то то там про количество советов было в названии. M>Конструктор не должен бросать исключений принципиально. Можно статическую функцию-конструктор запилить, которая конструирует объект и кидает исключение, если что не так, освобождая ресурсы. Любо. Но тут мы выходим в анлайк ТС. Он не хочет никакие Опены и Клоузы. Так что это не тема для разговора. "Надо, Федя, надо!" (с)
Если не производить полную инициализацию в конструкторе то усложняем инвариант класса и усложняем код.
Кому это нужно ?
Только потому что кто-то сказал , что это плохо?
Здравствуйте, C0x, Вы писали:
C0x>Я извиняюсь, но не работает "Делегирующие конструкторы" в моем коде. У меня вся архитектура построена на стэковых объектах и ссылочной связи между ними. Делегирующий конструктор если я правильно понимаю нельзя вызывать если у меня в классе в полях ссылки есть. Меня свой подход я не собираюсь ради вызова делегирующего конструктора.
A>>Да и глупо заниматься творчеством (отсебятиной). Особенно, так толком и не освоив инструментарий (С++), и на том поприще, где уже тридцать лет толкутся миллионы людей.
C0x>Я творчеством занимался еще до того как в STL Си++ появились нормальные смартпоинтеры и делегирующие конструкторы. После 10-ти летней паузы не все стандартны успел изучить. Поэтому кстати и пришел сюда, со своей бедой.
стэковые объекты — это какой-то свой собственный изобретённый термин или же неказистая попытка обозначить экземпляры классов находящиеся на стэке, а не в динамически выделяемой памяти (heap'е)?
Что это за болезненное стремление нагородить колхозной мутоты по мере освоения какого-то инструмента? А когда оказывается, что не обязательно долбаться шлицевой отвёрткой с шурупами имеющими крестообразную насечку на шляпке, то вдруг выясняется, что свой сложившийся подход никто менять не собирается.
Если не осилил письменность и дорожные знаки — то не беда, недостающее можно выдумать и вольно интерпретировать на свой вкус по ходу движения. По-человечески развалиться за рулём и крутить его двумя пальцами одной руки, лишь бы не выглядеть как остальные чмошники-обсосы, среди которых приходится толкаться в транспортном потоке.
Глупость и есть глупость, сама по себе, без спихивания ответственности на биографию.
Именно таким образом и выглядит поведение в этом треде. Зато теперь понятно, от кого защищаются собеседующие, когда просят прислать им примеры кода на том или ином языке программирования.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Касаемо ссылок на википедию, то это очень напоминает отсылку к «давно и широко известным вещам» с устоявшимися убеждениями большинства.
S>Если вы еще не в курсе, сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. Сам факт фиксации этого набора взглядов в Wikipedia может считаться достаточным для того, чтобы считать GP именно что парадигмой.
А вот и корень зла с причиной проблем в логике рассуждений.
Парадигмы в контексте программирования — это далеко не та сущность, которую можно обозначить «неким устоявшимся в обществе набором взглядов».
Да, само программирование в чистом виде является искусством, но это не относится к разработка софта. Потому что создание программного кода, выражающего определённую архитектуру с идиомами — это давным давно стало обыденной инженерией. Оперирующей абстракциями однозначно сформированными через определения с перечнями обязательных условий. Типа что нет ООП без соблюдения трёх условий (наследование, полиморфизм, инкапсуляция).
Хватит уже мнить себя творцом-художником имеющим право восклицать: «я — художник, я так вижу!». Может среди доярок с трактаристами-комбайнёрами такое и прокатит, но уж точно не в среде вроде RSDN-тусовки.
Здравствуйте, _NN_, Вы писали:
_NN>Если не производить полную инициализацию в конструкторе то усложняем инвариант класса и усложняем код. _NN>Кому это нужно ? _NN>Только потому что кто-то сказал , что это плохо?
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, _NN_, Вы писали:
_NN>>Если не производить полную инициализацию в конструкторе то усложняем инвариант класса и усложняем код. _NN>>Кому это нужно ? _NN>>Только потому что кто-то сказал , что это плохо?
M>Вызов деструктора в конструкторе это нормально?
Какой ещё вызов деструктора в конструкторе ?
Как можно вызвать деструктор для объекта, который не смог быть сконструированным ?
M>>Вызов деструктора в конструкторе это нормально?
_NN>Какой ещё вызов деструктора в конструкторе ? _NN>Как можно вызвать деструктор для объекта, который не смог быть сконструированным ?
про это и речь. Если конструктор не смог отработать, какие освобождения ресурсов в деструкторе, которые ещё и конструктор должен вызывать. Ты меня сиплюсплюсника с двадцатилетним стажем не путай, плиз. Тут же ещё new с выделением на стеке нужно не путать.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, _NN_, Вы писали:
M>>>Вызов деструктора в конструкторе это нормально?
_NN>>Какой ещё вызов деструктора в конструкторе ? _NN>>Как можно вызвать деструктор для объекта, который не смог быть сконструированным ?
M>про это и речь. Если конструктор не смог отработать, какие освобождения ресурсов в деструкторе, которые ещё и конструктор должен вызывать. Ты меня сиплюсплюсника с двадцатилетним стажем не путай, плиз. Тут же ещё new с выделением на стеке нужно не путать.
Я лишь указал на глупый совет данный в книге.
Бросать исключения из конструктора это правильно и полезно.
Гораздо проще работать в рамках транзакционной модели когда успешный вызов конструктора означает, что с объектом можно спокойно работать.
P.S.
Мерятся стажем не имеет смысла, я встречал достаточно людей со стажем 10-ти лет и не знающими что такое исключения.
Если что у меня тоже двадцать лет стажа =0
Здравствуйте, a7d3, Вы писали:
A>Парадигмы в контексте программирования — это далеко не та сущность, которую можно обозначить «неким устоявшимся в обществе набором взглядов».
С каким же упорством вы отвергаете реальность. Просто удивительно.
A>Типа что нет ООП без соблюдения трёх условий (наследование, полиморфизм, инкапсуляция).
Очевидно, что вы не в курсе, что даже определение "наследование, инкапсуляция, полиморфизм" -- это всего лишь одно из.
Как и не в курсе, что даже в рамках этого определения для программирования в ОО-стиле не обязательно выполнения всех трех "условий". Запросто можно ограничится инкапсуляцией+наследованием или наследованием+полиморфизм.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
C0x>>Я извиняюсь, но не работает "Делегирующие конструкторы" в моем коде. У меня вся архитектура построена на стэковых объектах и ссылочной связи между ними. Делегирующий конструктор если я правильно понимаю нельзя вызывать если у меня в классе в полях ссылки есть. Меня свой подход я не собираюсь ради вызова делегирующего конструктора.
A>>>Да и глупо заниматься творчеством (отсебятиной). Особенно, так толком и не освоив инструментарий (С++), и на том поприще, где уже тридцать лет толкутся миллионы людей.
C0x>>Я творчеством занимался еще до того как в STL Си++ появились нормальные смартпоинтеры и делегирующие конструкторы. После 10-ти летней паузы не все стандартны успел изучить. Поэтому кстати и пришел сюда, со своей бедой.
A>стэковые объекты — это какой-то свой собственный изобретённый термин или же неказистая попытка обозначить экземпляры классов находящиеся на стэке, а не в динамически выделяемой памяти (heap'е)?
для особо ограниченных плюсовиков (в смысле любителей самоограничений) я постараюсь расширить твои границы и предложить пройтись для начала в Гугл stack objects
A>Что это за болезненное стремление нагородить колхозной мутоты по мере освоения какого-то инструмента?
A>Именно таким образом и выглядит поведение в этом треде.
Именно таким оно выглядит только в твоей голове, ни больше не меньше.
A>Зато теперь понятно, от кого защищаются собеседующие, когда просят прислать им примеры кода на том или ином языке программирования.
Утикакой! Не взяли на очередное собеседование? Вот почему ты самоограничениями так обложился.
Меня собеседования не волнуют уже лет 10, я давно уже сам решаю как писать программы и на чем. А ты не завидуй!
А вообще я не понимаю ну не взяли на собеседование, чего срываться то на коллегах???
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Парадигмы в контексте программирования — это далеко не та сущность, которую можно обозначить «неким устоявшимся в обществе набором взглядов».
S>С каким же упорством вы отвергаете реальность. Просто удивительно.
A>>Типа что нет ООП без соблюдения трёх условий (наследование, полиморфизм, инкапсуляция).
S>Очевидно, что вы не в курсе, что даже определение "наследование, инкапсуляция, полиморфизм" -- это всего лишь одно из. S>Как и не в курсе, что даже в рамках этого определения для программирования в ОО-стиле не обязательно выполнения всех трех "условий". Запросто можно ограничится инкапсуляцией+наследованием или наследованием+полиморфизм.
Вот только «программирование в ОО-стиле», это далеко не тоже самое, что парадигма ООП.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, a7d3, Вы писали:
A>>стэковые объекты — это какой-то свой собственный изобретённый термин или же неказистая попытка обозначить экземпляры классов находящиеся на стэке, а не в динамически выделяемой памяти (heap'е)?
C0x>для особо ограниченных плюсовиков (в смысле любителей самоограничений) я постараюсь расширить твои границы и предложить пройтись для начала в Гугл stack objects
Не надо так переживать и дёргаться. Ничего страшного, к 20-25 годам опыта этот гонор со снобизмом уходят. Вырабатывается привычка уточнять, что же именно собеседник пытается сообщить, что конкретно имеет в виду.
Это когда за плечами лишь полторы книжки прочитанных, тогда и кажется, что все на одном языке говорить должны/обязаны, в рамках какого-то одного набора терминов с определениями.
Здравствуйте, so5team, Вы писали:
S>Мне вот интересно, как вы классифицируете следующую ситуацию:
Что сотрудник решивший экспортировать С++ классы из DLL'ок подлежит увольнению, за вопиющую профнепригодность.
Если это в США, то в течении двух минут после обнаружения данного творчества в продакшен коде.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
C0x>>Здравствуйте, a7d3, Вы писали:
A>>>стэковые объекты — это какой-то свой собственный изобретённый термин или же неказистая попытка обозначить экземпляры классов находящиеся на стэке, а не в динамически выделяемой памяти (heap'е)?
C0x>>для особо ограниченных плюсовиков (в смысле любителей самоограничений) я постараюсь расширить твои границы и предложить пройтись для начала в Гугл stack objects
A>Не надо так переживать и дёргаться. Ничего страшного, к 20-25 годам опыта этот гонор со снобизмом уходят.
О наконец-то дошло дело до меряния пиписьками. У меня всего 15 лет проф.опыта, поэтому я пока не дотягиваю.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, kov_serg, Вы писали:
_>>>>Гораздо логичнее что бы за все ресурсы, которые использует объект, отвечал не он, а тот кто заставил его работать. σ>>>https://youtu.be/rwOv_tw2eA4?t=1611 _>>Нет, я имею ввиду что в языке должна быть возможность отанавливать потоки не переводя программу в UB. _>>И всё сваливать на RAII это не очень хорошо. С++ никогда не сможет работать на оборудовании со сбоями. _>>Мне больше такой подход нравиться.
BFE>Почему это никогда? Если в С++ добавят std::process и он будет достаточно легким (легковесным), то отличия от Эрланга будут косметическими.
BFE>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1750r0.pdf
Поржал. Запуск нового процесса — легковеснная операция (особенно в винде — сотни миллисикунд).
Дело не в процессах, и не в стандарте c++, а в posix runtime. runtime должен быть контектозависимый, а не глобальным. так что бы родитель мог контролировать то чем и как пользуется порождаемый подпрограмма или поток. А пока можно похвастаться только разнобразием UB.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, so5team, Вы писали:
S>>Здравствуйте, Maniacal, Вы писали:
M>>>А в конструкторе не надо исключения кидать. Это моветон.
S>>И давно это стало моветоном?
M>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Странно так ограничивать любой конструктор. Default или move — это еще можно понять.
Любое выделение памяти в конструкторе — это как минимум возможность std::bad_alloc.
Многие конструкторы std::vector и std::string делают аллокации и потенциально кидают исключения.
Так что, не использовать вектора и строки как члены данных в своих классах?
Здравствуйте, qaz77, Вы писали:
M>>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Q>Странно так ограничивать любой конструктор. Default или move — это еще можно понять.
Не стоит принимать всерьез. Очевидно, что человек "слышал звон, но не знает где он"
Здравствуйте, Maniacal, Вы писали:
M>Есть такая книжка хорошая, только не помню как называется, что-то типа "С++ для профессионалов", что-то то там про количество советов было в названии.
я прочёл все хорошие книжки типа "C++ для профессионалов", в т.ч. где про количество советов было в названии, и ни в одной из них не было запрета на выброс исключений из конструктора.
Здравствуйте, Maniacal, Вы писали:
M>Ты меня сиплюсплюсника с двадцатилетним стажем
ИМХО, это вот главная трудность.
Ну то есть, условно говоря, сеньер с 20+ стажем что-то такое узнал в своем профессиональном "детстве", запомнил, и все 20 лет применяет,
а это — бац — и неверно оказалось, ну или просто бессмысленно.
Я так с одним уважаемым человеком несколько лет бодался насчет delete для указателя со значением nullptr.
Ни в какую не хотел убеждаться. Ни ссылки на стандарт, ни апелляции к здравому смыслу — не помогали.
Тут не что-то подобное? Может ну его этот стаж-то, может просто разобраться в теме надо, а не слепо верить установкам 20-летней давности?
Я вот так, кстати, однажды тоже через себя переступил и обнаружил, что не допускается, оказывается, по стандарту С и С++ разрядность char меньше 8-ми бит.
А ведь все 20+ лет был уверен, что может быть такое, я ведь даже машины с 4-х разрядными регистрами этими вот своими руками трогал.
Здравствуйте, kov_serg, Вы писали:
_>>>Мне больше такой подход нравиться. BFE>>Почему это никогда? Если в С++ добавят std::process и он будет достаточно легким (легковесным), то отличия от Эрланга будут косметическими. _>Поржал. Запуск нового процесса — легковеснная операция (особенно в винде — сотни миллисикунд). _>Дело не в процессах, и не в стандарте c++, а в posix runtime.
Расскажите, пожалуйста, про связь posix runtime с Эрланг.
_>runtime должен быть контектозависимый, а не глобальным. так что бы родитель мог контролировать то чем и как пользуется порождаемый подпрограмма или поток. А пока можно похвастаться только разнобразием UB.
Если у вас есть запуск процесса, то вокруг него можно навернуть любой контекст. Ничего особо сложного для С++ тут я не вижу. Если хотите запускать процессы в posix runtime контексте, то что же вам мешает?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Вот только «программирование в ОО-стиле», это далеко не тоже самое, что парадигма ООП.
S>Доказывается это, традиционно для вас, аргументом "я так сказал", не правда ли?
Путать стиль программирования с парадигмой программирования допустимо лишь в среде АСУТПэшников. Людей привыкших работать топорно и толком не видевших в своей жизни ничего окромя промышленных линий на заводах и производствах.
Любой диспут на профессиональные темы всегда сводится к спору о терминах и определениях. Является ли этот факт открытием и насколько культурно проходят эти самые споры — это уже показатель/индикатор того, к каким социальным стратам относится визави.
Здравствуйте, Voivoid, Вы писали:
V>Здравствуйте, qaz77, Вы писали:
M>>>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Q>>Странно так ограничивать любой конструктор. Default или move — это еще можно понять.
V>Не стоит принимать всерьез. Очевидно, что человек "слышал звон, но не знает где он"
Били-то, небось, по рукам за исключение выбрасываемое из деструкторов.
Однако, система образования настолько замечательна, что потом в голове, по этому вопросу, конструкторы с деструкторами поменялись местами.
Здравствуйте, a7d3, Вы писали:
A>Путать стиль программирования с парадигмой программирования допустимо лишь в среде АСУТПэшников.
Как и предсказывалось, доказательство из категории "я так сказал".
Складывается впечатление, что "парадигма" для вас -- это нечто вроде физических законов или математических аксиом.
A>Является ли этот факт открытием и насколько культурно проходят эти самые споры — это уже показатель/индикатор того, к каким социальным стратам относится визави.
Поэтому, наверное, вы постоянно пытаетесь проехаться по личностям собеседников. Возможно, вы не можете пережить того, что не в состоянии предметно возразить какому-то колхознику из болот Полесья.
Здравствуйте, so5team, Вы писали:
S>Поэтому, наверное, вы постоянно пытаетесь проехаться по личностям собеседников. Возможно, вы не можете пережить того, что не в состоянии предметно возразить какому-то колхознику из болот Полесья.
Колхозник в данном случае упорно отказывается понять разницу между параллелограммом и прямоугольником, заявляя, что это одно и то же. А так же, что он и трапецию готов называть прямоугольником, ведь у неё столько же сторон и углов.
Лениво ему быть аккуратным в терминологии, держа в голове какие-то там эти все нафиг никому не нужные тонкости с нюансами. Даже когда предлагают перейти на использование термина «четырёхугольник», то всё равно пытается всех вокруг дерьмом полить.
Не со зла, конечно, а просто потому что иначе не умеет общаться, да и вообще — удобрение же, расти будет лучше.
Здравствуйте, wander, Вы писали:
W>Здравствуйте, Maniacal, Вы писали: W>ИМХО, это вот главная трудность.
Там все рога растут, насколько я помню, что до завершения работы конструктора не гарантирует полную инициализацию объекта. На этом всё. Нельзя к this обращаться и к мемберам нормально. А то может не повезти. И вообще эксепшн в конструкторе это как в анекдоте про бегемота "И правда, чего это я?!".
Здравствуйте, wander, Вы писали:
W>Тут не что-то подобное? Может ну его этот стаж-то, может просто разобраться в теме надо, а не слепо верить установкам 20-летней давности?
тут всё гораздо проще. Вся архитектура строится или на возвратах кода ошибки или на эксепшенах. В первом случае идея с эксепшенами в конструкторе проваливается с самого начала. Конструктор не возвращает кода. Думаю, тут прикладная проблема миграции кода на ООП. Но идея кидания исключений в недостроенном конструкторе интересна. Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, a7d3, Вы писали:
A>>Здравствуйте, C0x, Вы писали:
A>>от любителя изобретать свои паттерны?... Моё раздражение вызвано тем, что в С++ вечно лезут кулибины...
C0x>Мдя... а как все хорошо начиналось...
Здравствуйте, a7d3, Вы писали:
S>>Возможно, вы не можете пережить того, что не в состоянии предметно возразить какому-то колхознику из болот Полесья.
A>Колхозник в данном случае упорно отказывается понять разницу между параллелограммом и прямоугольником, заявляя, что это одно и то же. А так же, что он и трапецию готов называть прямоугольником, ведь у неё столько же сторон и углов. A>Лениво ему быть аккуратным в терминологии, держа в голове какие-то там эти все нафиг никому не нужные тонкости с нюансами. Даже когда предлагают перейти на использование термина «четырёхугольник», то всё равно пытается всех вокруг дерьмом полить.
Ибо возражая предметно вы бы могли сказать "стиль программирования -- это..., а парадигма программирования -- это..., исходя из чего стиль != парадигме".
Ну или вы могли вместо цитирования используемых вами (а это важно, т.к. используемые вами вовсе не обязательно окажутся общепринятыми, или хотя бы более-менее известными) определений вы могли бы дать ссылки на эти самые определения в других источниках.
Вот тогда бы было предметное возражение.
Но нет, вы не можете. Вы порождаете какой-то мутный поток собственных оценочных суждений, который отражает только бардак в вашей голове, а отнюдь не позицию вашего собеседника.
И так во всем споре. Особенно умиляет ваша позиция "я верю в некую неведомую ерунду, а вы мне покажите, где написано, что этой неведомой ерунды быть не может, но при этом ссылаться на авторитетов смешно". Это ведь игра, в которую можно играть вдвоем. Некто a7d3 может пить коньяк по утрам, а вечерам обнюхается кокаина и смотрит детское порно. И пусть мне приведут источники, в которых написано, что этого не может быть.
Здравствуйте, Maniacal, Вы писали:
M> Но идея кидания исключений в недостроенном конструкторе интересна. Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
Никаких велосипедов. Рекомендации по комфортной работе в этих условиях были даны еще в 1990-х: списки инициализации вместо ручного присваивания значений в конструкторе, индивидуальные RAII обертки для каждого подлежащего освобождению ресурса вместо ручной очистки ресурсов в деструкторе (что тут во множестве адекватных комментариев ТС-у и советуют).
Как за 20 лет стажа не узнать об этих рекомендациях...
Здравствуйте, Maniacal, Вы писали:
M>тут всё гораздо проще. Вся архитектура строится или на возвратах кода ошибки или на эксепшенах.
Вообще мой комментарий касался высказывания о моветоне и сделанных из этого выводов.
То, что, разумеется, при определенных стратегиях разработки некоторые инструменты могут не понадобиться или даже мешать, — это отдельный вопрос.
M>Но идея кидания исключений в недостроенном конструкторе интересна. Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
finally в С++ не нужен именно из-за RAII и деструкторов.
Здравствуйте, Maniacal, Вы писали:
M>.... Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
Какой велосипед? Это здравое разделение ответственности. Воплощение SRP в области управления ресурсами. А делегированный конструктор — средство языка, позволяющее воспользоваться стандартной схемой управления ресурсами — RAII.
Бесполезно вести диалог с человеком, который начинает «подгонять» определения, потому что спорил о парадигмах программирования, облажался несколько раз, но очень хочет отстоять собственную точку.
Если вы еще не в курсе, сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. Сам факт фиксации этого набора взглядов в Wikipedia может считаться достаточным для того, чтобы считать GP именно что парадигмой.
Это уже «клиника», однозначно. Того разряда, когда солипсизм является симптомом.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, wander, Вы писали:
W>>Тут не что-то подобное? Может ну его этот стаж-то, может просто разобраться в теме надо, а не слепо верить установкам 20-летней давности?
M>тут всё гораздо проще. Вся архитектура строится или на возвратах кода ошибки или на эксепшенах. В первом случае идея с эксепшенами в конструкторе проваливается с самого начала. Конструктор не возвращает кода. Думаю, тут прикладная проблема миграции кода на ООП. Но идея кидания исключений в недостроенном конструкторе интересна. Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
Я не припомню когда в последний раз нужен был finally.
Всё обычно решается через try with resource в Java или using в C#.
A>Если вы еще не в курсе, сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. Сам факт фиксации этого набора взглядов в Wikipedia может считаться достаточным для того, чтобы считать GP именно что парадигмой.
A>Это уже «клиника», однозначно. Того разряда, когда солипсизм является симптомом.
Для того, чтобы доказать, что это "клиника" и "солипсизм" следовало бы хотя бы привести ссылку на определение понятия "парадигма программирования", которого вы сами придерживаетесь (можно даже не обсуждать вопрос адекватности этого определения).
Здравствуйте, _NN_, Вы писали:
_NN>Я не припомню когда в последний раз нужен был finally. _NN>Всё обычно решается через try with resource в Java или using в C#.
На Java писал (по работе) последний раз в 2000 году, возможно, тогда таких конструкций в языке ещё не было. На C# пока писать не приходилось, но про using читал.
Но я уже понял, что ляпнул не подумавши. Смешал две вещи. Что не стоит использовать указатель this в конструкторе C++ (особенно в списке инициализации), ибо непредвиденный результат, в зависимости от реализации компилятора, и подход, когда код всегда возвращает код ошибки, а не бросает исключения (тут не надо быть капитаном очевидность, чтобы понять, что при таком подходе об исключениях речи идти не может, а конструктор это функция, которая ничего возвращать не должна, по-хорошему, но и тут есть нюансы).
Здравствуйте, so5team, Вы писали:
S>Для того, чтобы доказать, что это "клиника" и "солипсизм" следовало бы хотя бы привести ссылку на определение понятия "парадигма программирования", которого вы сами придерживаетесь (можно даже не обсуждать вопрос адекватности этого определения). S>Но вы и этого не смогли. S>Ожидаемо.
Важен сам факт того, что человек, испробовав ряд приёмов для защиты своего мировоззрения, так и не остановился, а пробил дно —дойдя уже до «подгонки» определений.
Очень странно выглядит, когда человек пытается в сфере программной инженерии разгуливать с определением парадигмы из научного мира. Игнорируя всю нелепость ситуации лишь потому, что это позволяет ему отстоять или как-то оправдать свою точку зрения.
Ни разу не похоже это всё на попытку сбросить накопившийся контекст и вести диалог уже в русле споров о терминах с определениях.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, so5team, Вы писали:
S>>Для того, чтобы доказать, что это "клиника" и "солипсизм" следовало бы хотя бы привести ссылку на определение понятия "парадигма программирования", которого вы сами придерживаетесь (можно даже не обсуждать вопрос адекватности этого определения). S>>Но вы и этого не смогли. S>>Ожидаемо.
A>Очень странно выглядит, когда человек пытается в сфере программной инженерии разгуливать с определением парадигмы из научного мира.
Странно это когда человек отрицает одно определение и не приводит другое, при этом продолжая рассуждать о сферических конях в вакууме.
Здравствуйте, a7d3, Вы писали:
A>Очень странно выглядит, когда человек пытается в сфере программной инженерии разгуливать с определением парадигмы из научного мира.
Вас ведь не затруднит указать на хоть какое-либо определение парадигмы, которое я здесь привел? Хоть из научного мира, хоть из ненаучного.
А то вы утверждаете про "разгуливать с определением парадигмы из научного мира", хотя я лично ни одного определения для "парадигмы" пока здесь не озвучивал и ни на какие определения не ссылался.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Очень странно выглядит, когда человек пытается в сфере программной инженерии разгуливать с определением парадигмы из научного мира.
S>Вас ведь не затруднит указать на хоть какое-либо определение парадигмы, которое я здесь привел? Хоть из научного мира, хоть из ненаучного.
S>А то вы утверждаете про "разгуливать с определением парадигмы из научного мира", хотя я лично ни одного определения для "парадигмы" пока здесь не озвучивал и ни на какие определения не ссылался.
А вот это что было?
...сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. ...
Очень напоминает пересказ своими словами классического варианта определения парадигмы принятое в научном мире. Взятый с какой-нибудь википедии или другого схожего ресурса.
Здравствуйте, a7d3, Вы писали:
S>>А то вы утверждаете про "разгуливать с определением парадигмы из научного мира", хотя я лично ни одного определения для "парадигмы" пока здесь не озвучивал и ни на какие определения не ссылался.
A>А вот это что было? A>
A>...сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. ...
A>Очень напоминает пересказ своими словами классического варианта определения парадигмы принятое в научном мире. Взятый с какой-нибудь википедии или другого схожего ресурса.
Попытка объяснить чем "парадигма" не является, ваш К.О.
Под определение, с очень большой натяжкой, может сойти разве что вот эта часть фразы "А некий устоявшийся в сообществе набор взглядов". Но если для вас это сошло за определение, то: во-первых, ой, все еще хуже, чем я думал, и, во-вторых, вы-то и отдаленно чего-либо похожего привести не можете.
Здравствуйте, Maniacal, Вы писали:
M>Есть такая книжка хорошая, только не помню как называется, что-то типа "С++ для профессионалов", что-то то там про количество советов было в названии. M>Конструктор не должен бросать исключений принципиально.
Для конструктора же бросок исключения — самый естественный способ сообщить о невозможности конструирования объекта (аутпут параметры я даже рассматривать не хочу). Даже оператор new обязан подчистить за собой выделенную память, если в конструкторе возникло исключение. Это в стандарте прописано. Стандарт так же описывает, что должно происходить при броске исключения из конструкторов подобъектов составных типов — те подобъекты, которые сконструированы на этот момент, должны быть корректно разрушены, причем, в строго определенном порядке. Смотри, сколько всего предусмотрено, а ты говоришь "не должен бросать принципиально". Ты, видимо, просто перепутал конструкторы с деструкторами.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, so5team, Вы писали:
S>Попытка объяснить чем "парадигма" не является, ваш К.О.
S>Под определение, с очень большой натяжкой, может сойти разве что вот эта часть фразы "А некий устоявшийся в сообществе набор взглядов". Но если для вас это сошло за определение, то: во-первых, ой, все еще хуже, чем я думал, и, во-вторых, вы-то и отдаленно чего-либо похожего привести не можете.
Идея в том, чтобы посмотреть на разницу парадигмы в научном мире с парадигмой программирования в инженерии программной.
И растёт это всё из случившейся ранее попытки объявить стиль программирования синонимом парадигмы программирования.
Здравствуйте, a7d3, Вы писали:
S>>Под определение, с очень большой натяжкой, может сойти разве что вот эта часть фразы "А некий устоявшийся в сообществе набор взглядов". Но если для вас это сошло за определение, то: во-первых, ой, все еще хуже, чем я думал, и, во-вторых, вы-то и отдаленно чего-либо похожего привести не можете.
A>Идея в том, чтобы посмотреть на разницу парадигмы в научном мире с парадигмой программирования в инженерии программной. A>И растёт это всё из случившейся ранее попытки объявить стиль программирования синонимом парадигмы программирования.
"Если у вас есть идея, то купите селедку и морочьте ей голову" (c)
А если вы хотите предъявить что-то мне, то озвучивайте причины, почему в вашем мире, настолько оторванном от реальности, что аж страшно, "стиль программирования" не может быть синонимом "парадигмы программирования". Для чего вам придется либо озвучить свои определения, либо дать на них ссылки. О чем вам толкуют уже в который раз.
Здравствуйте, so5team, Вы писали:
S>"Если у вас есть идея, то купите селедку и морочьте ей голову" (c)
S>А если вы хотите предъявить что-то мне, то озвучивайте причины, почему в вашем мире, настолько оторванном от реальности, что аж страшно, "стиль программирования" не может быть синонимом "парадигмы программирования". Для чего вам придется либо озвучить свои определения, либо дать на них ссылки. О чем вам толкуют уже в который раз.
С какой целью? Чтобы общаться на одном языке с колхозником, показавшим себя во всей красе в этом тредике?
Спасибо, не интересно. Пусть дальше полагает, что единственно верный полиморфизм в контексте ООП сводится late & dynamic binding.
Что какая-нибудь двойная диспетчеризации может производиться лишь в рантайме, а если в компил-тайме, то это, якобы, уже не ООП.
Здравствуйте, a7d3, Вы писали:
A>Спасибо, не интересно.
Не интересно учиться и узнавать что-то новое? Обмениваться знаниями? Ну бывает. Когда думаешь, что за спиной 25 лет опыта, то можно и разучиться новую информацию воспринимать.
A>Пусть дальше полагает, что единственно верный полиморфизм в контексте ООП сводится late & dynamic binding.
Речь не про верный/неверный. А про то, что когда динамический полиморфизм, то это ООП. А другие случаи -- не ООП.
Всего лишь.
И да, сколько вы не будете пытаться надувать щеки, обосновать свою точку зрения у вас не выйдет. Многократо доказано и перепровенено.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, so5team, Вы писали:
S>>"Если у вас есть идея, то купите селедку и морочьте ей голову" (c)
S>>А если вы хотите предъявить что-то мне, то озвучивайте причины, почему в вашем мире, настолько оторванном от реальности, что аж страшно, "стиль программирования" не может быть синонимом "парадигмы программирования". Для чего вам придется либо озвучить свои определения, либо дать на них ссылки. О чем вам толкуют уже в который раз.
A>С какой целью? Чтобы общаться на одном языке с "колхозником"
У тебя какой-то комплекс на тематике колхоза. Тяжелая деревенская жизнь? В школе били часто?
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, so5team, Вы писали:
S>>"Если у вас есть идея, то купите селедку и морочьте ей голову" (c)
S>>А если вы хотите предъявить что-то мне, то озвучивайте причины, почему в вашем мире, настолько оторванном от реальности, что аж страшно, "стиль программирования" не может быть синонимом "парадигмы программирования". Для чего вам придется либо озвучить свои определения, либо дать на них ссылки. О чем вам толкуют уже в который раз.
A>С какой целью? Чтобы общаться на одном языке с колхозником, показавшим себя во всей красе в этом тредике? A>Спасибо, не интересно. Пусть дальше полагает, что единственно верный полиморфизм в контексте ООП сводится late & dynamic binding.
Проведу сеанс снятия запоров ограничений в понимании ООП и полиморфизма.
Внимание! Следи за руками:
Чаще всего выделяют следующие необходимые и достаточные элементы ООП:
1) инкапсуляция;
2) наследование;
3) полиморфизм.
Реазация динамического полиморфизма подразумевает Наследование. Именно поэтому её и только её относят к ООП парадигме.
А теперь смотри фокус. Пример "статического полиморфизма"
template<class T>
struct A
{
void foo(T t)
{
...
t.do();
...
}
}
struct B
{
void do()
{...}
}
int main()
{
A<B> a;
a.foo(B());
...
...
}
Теперь вопрос: этот код можно назвать кодом в классической ООП парадигме?
Здравствуйте, Maniacal, Вы писали:
M>Есть такая книжка хорошая, только не помню как называется, что-то типа "С++ для профессионалов", что-то то там про количество советов было в названии. M>Конструктор не должен бросать исключений принципиально.
Кто автор и как называется? Мне печку для пиццы растапливать надо чем-то.
Конструктор принципиально обязан выбросить исключение, если создать объект по какой-то причине не удается.
Автор(ы): Дж. Коплиен
