Форум на Исходниках.RU

Delphi vs C++ vs C#

Qraizer — Mon, 22 Feb 2016 11:00:46 +0000

Qraizer: Это я уже всё понял, leo. Спасибо, однако, я ожидал от Shaggy подтверждения. Другими словами, в Плюсах это само собой разумеющиеся поведение, ибо по дефолту абстрактные классы, каковые мы используем в качестве интерфейсов, не наследуются виртуально, тогда как в Дельфи дефолтовое поведение интерфейсов как раз обратное. Прикол-то как раз в том, что что интерфейсы, что абстрактные классы для реализации одних и тех же парадигм в обоих языках подходят одинаково, тогда как когда мы допытывались у них, как они собираются реализовывать отдельные реализации одного и того же интерфейса, если вдруг понадобится, в ответ было либо "такого никогда не нужно", либо приводился пример с отдельными реализациями в разных классах, с последующим агрегированием и делегированием, что вообще-то больше на подпорку похоже. Вот мне и интересно, почему нам сразу не показали, что делегированием можно управлять и на уровне интерфейсов, а не только реализаций.

Добавлено 22.02.16, 11:02
Впрочем, возможно и показывали. Я уходил из темы, когда тут начали лить воду по десятку страниц в час.

Delphi vs C++ vs C#

leo — Mon, 22 Feb 2016 09:14:39 +0000

leo:

Цитата Qraizer @ 21.02.16, 03:24

Почему ручная делегация не затрагивает унаследованный от базового интерфейса метод расширяющего интерфейса?

Потому, что она "придумана" не просто для возможности "алиасинга имен" интерфейсного и реализующего метода, а как раз для задания различных\индивидуальных реализаций для одноименных методов разных интерфейсов - не важно, связанных между собой "родственными узами" или нет. Поэтому делегация IMyInterface.Handle = ...; относится только к реализации указанного интерфейса IMyInterface и ни к какому другому (ни к наследнику, ни к предку). Поэтому если ты по каким-то причинам хочешь использовать другое имя реализующего метода, то нужно делегировать его всем реализуемым интерфейсам

TMyObject = class(TInterfacedObject, IMyInterface, IMyInterface2)

protected

procedure _Handle;

procedure IMyInterface.Handle = _Handle;

procedure IMyInterface2.Handle = _Handle; //тут можно задать и другой реализующий метод

end;

Цитата Qraizer @ 21.02.16, 03:24

если IMyInterface2 расширяет IMyInterface, то IMyInterface.Handle в равной мере принадлежит обоим интерфейсам

Цитата Qraizer @ 21.02.16, 18:33

Я понимаю так, что расширение – это создание нового на основе существующего, при этом новый включает в себя из него всё.

Вопрос в том, что "включает" и что "в равной мере принадлежит". Расширение\наследование интерфейса означает наследование деклараций методов и последовательность расположения их адресов в vmt\vtable. Однако то, что унаследованный IMyInterface2 не добавляет новых методов к IMyInterface, не означает, что при реализации этих интерфейсов одним объектом они непременно должны ссылаться на одну и ту же (разделяемую) vmt - это могут быть две разные vmt, идентичные по содержанию. И как было сказано выше, использование делегирования метода как раз и подразумевает, что один и тот же метод может иметь разные реализации у предка и наследника, и соотв-но они 100% будут иметь разные vmt. Поэтому в том, что "один и тот же интерфейс IMyInterface, будучи в TMyObject доступным по двум маршрутам, ... присутствует в двух экземплярах", ничего удивительного нет, т.к. во-первых, мы сами этого "захотели", используя делегирование, во-вторых, это "не запрещено законом" :)

Delphi vs C++ vs C#

Qraizer — Sun, 21 Feb 2016 18:33:04 +0000

Qraizer: Ну, как бы как я себе и представлял.

Цитата Shaggy @ 21.02.16, 05:44

с сообщением похоже просто баг, я уже отправил репорт

Ага. Вот теперь у меня всё срослось. Вроде.
Тогда в заключение: расширение интерфейса и его наследование в вашей терминологии – в чём разница? Я понимаю так, что расширение – это создание нового на основе существующего, при этом новый включает в себя из него всё. Наследование интерфейса как термин по-хорошему вообще не используется, и вместо него существует термин "реализация интерфейса". Получается, что нельзя создать новый интерфейс, расширив более одного?

Добавлено 21.02.16, 18:39

Цитата Shaggy @ 21.02.16, 05:44

например, в самой IDE есть галочка - импортировать интерфейсы из TLB c safecall или stdcall методами

Цитата

Safecall functions automatically implement COM conventions for errors and exception handling, converting HRESULT error codes into exceptions. If you are entering function declarations in RIDL, you must explicitly specify the calling convention as safecall or stdcall.

А, т.е. компилятор для safecall фактически создаёт некий прокси над тем, что написал програмер. О как.

Delphi vs C++ vs C#

Shaggy — Sun, 21 Feb 2016 05:44:35 +0000

Shaggy: от интерфейса не наследуются, его реализуют(как и получают) целиком, как неделимую единицу
поэтому в записи:

TMyObject = class(TInterfacedObject, IMyInterface, IMyInterface2)

IMyInterface реализуется один раз и доступен по одному маршруту
в Interface table этого класса всего три записи: IInterface, IMyInterface, IMyInterface2

а из этого класса:

TMyObject2 = class(TObject, IMyInterface2)

мы не сможем получить даже IInterface т.к.
в Interface table этого класса одна запись: IMyInterface2

но:

var

Obj:TMyObject2;

Intf:IMyInterface2

I:IInterface;

begin

...

Intf:=Obj as IMyInterface2; // получение интерфейса

// или

Intf:=Obj; // неявный as

I:=Obj; // неявный as, но облом, не реализован IInterface

I:=Intf; // тут, т.к. IMyInterface наследуется от IInterface, просто усечение

пример из жизни:
в кафешке под пиво можно заказать набор закусок с соусами
мне соусы не нужны, но:
набор готовится с соусами и заказать можно только целиком (реализация и получение)
но после получения заказа соус можно выкинуть (усечение)
:)

с сообщением похоже просто баг, я уже отправил репорт

Цитата Qraizer @ 21.02.16, 03:24

а это, случайно, не грязный хак?

ну как сказать...

например, в самой IDE есть галочка - импортировать интерфейсы из TLB c safecall или stdcall методами

Цитата

Добавлено 21.02.16, 06:01
и да, правильнее всё-таки говорить о расширении интерфейсов, а не о наследовании
т.к. при такой записи (если бы она была разрешена)

type

IMyIntf3 = interface(IMyIntf, IMyIntf2)

мы бы поимели ваши проблемы: дублирование _AddRef, _Release, QyeryInterface
(и это только в самом простом случае)

Delphi vs C++ vs C#

Qraizer — Sun, 21 Feb 2016 03:24:27 +0000

Qraizer: Вот в этом-то и был вопрос: если IMyInterface2 расширяет IMyInterface, то IMyInterface.Handle в равной мере принадлежит обоим интерфейсам. Т.е. прикол в том, что ручная делегация не затрагивает IMyInterface2, и это не ошибка модели интерфейсов в языке, а тупо нефик лезть руками в вещи, которые легко сломать, если не понимаешь, что делаешь?

Добавлено 21.02.16, 03:30

Цитата Shaggy @ 21.02.16, 02:00

PS с т.з. языка IMyInterface, IMyInterface2 - это два разных типа
это не зависит от наличия и значения GUID'а

Ну это-то понятно. Другое дело, что один из них является подтипом другого и в этом смысле полностью заменяем им, но не наоборот (что, впрочем, при пустом IMyInterface2 не имеет значения).

Добавлено 21.02.16, 03:47
Тогда дополнительно ещё три вопроса:Я не придираюсь, я хочу разобраться. На последний вопрос и в контексте Плюсов не так-то просто ответить.

Добавлено 21.02.16, 03:53

Цитата Shaggy @ 21.02.16, 02:00

это конечно чревато, но иногда удобно
...

Хм... а это, случайно, не грязный хак? safecall кем обеспечивается? Разве не самим методом?

Delphi vs C++ vs C#

Shaggy — Sun, 21 Feb 2016 02:00:32 +0000

Shaggy: неверное имя в сообщении, похоже баг

Цитата Qraizer @ 20.02.16, 20:56

Дельфисты, поясните, плз, что тут не так:

класс обязан выполнить два контракта:

1. автопилот(сопоставление по имени)

TMyObject = class(TInterfacedObject, IMyInterface, IMyInterface2)

protected

procedure Handle;

end;

а) метод Handle в классе есть - контракт IMyInterface выполнен
б) метод Handle в классе есть - контракт IMyInterface2 выполнен
ок

2. ручное управление

TMyObject = class(TInterfacedObject, IMyInterface, IMyInterface2)

protected

procedure _Handle;

procedure IMyInterface.Handle = _Handle;

end;

а) контракт IMyInterface выполняется с помощью метода _Handle
б) метод Handle отсутствует - - контракт IMyInterface2 НЕ выполнен
фейл

Цитата Qraizer @ 20.02.16, 20:56

Даже на Плюсах проверил:

шикарно :lool:

type

IMyInterface = interface

procedure Handle;

end;

IMyInterface2 = interface(IMyInterface)

end;

TMyObject = class(TInterfacedObject, IMyInterface, IMyInterface2)

public

procedure _Handle;

procedure Handle;

end;

procedure TMyObject._Handle;

begin

end;

procedure TMyObject.Handle;

begin

_Handle;

end;

тоже работает :lol:

PS с т.з. языка IMyInterface, IMyInterface2 - это два разных типа
это не зависит от наличия и значения GUID'а

GUID можно указать любой, компилятор это не контролирует
это конечно чревато, но иногда удобно

type

IMyInterface = interface ['GUID']

procedure Handle; safecall;

end;

IMyInterface2 = interface ['GUID']

function Handle:HRESULT; stdcall;

end;

TMyObject = class(TInterfacedObject, IMyInterface)

public

procedure Handle;

end;

...

Intf:=Obj as IMyInterface; // и далее работаем с исп. исключений

Intf:=Obj as IMyInterface2; // исп. коды ошибок

Delphi vs C++ vs C#

Qraizer — Sat, 20 Feb 2016 20:56:12 +0000

Qraizer: Дельфисты, поясните, плз, что тут не так:

type

IMyInterface = interface ['некий GUID']

procedure Handle;

end;

IMyInterface2 = interface(IMyInterface) ['некий другой GUID']

end;

TMyObject = class(TInterfacedObject, IMyInterface, IMyInterface2) // E2291: Missing implementation of interface method IMyInterface.Handle.

protected

procedure _Handle;

procedure IMyInterface.Handle = _Handle;

end;

procedure TMyObject._Handle;

begin

end;

С моим пониманием интерфейсов всё должно быть в порядке. Даже на Плюсах проверил:

class IMyInterface

{

public:

virtual void Handle() = 0;

};

class IMyInterface2: public IMyInterface

{

};

class TMyObject: virtual public IMyInterface, virtual public IMyInterface2

{

protected:

void _Handle() {}

void Handle() { _Handle(); }

};

TMyObject a;

Или я чего-то не так понимаю в интерфейсах?

Добавлено 20.02.16, 20:59
P.S. Правильно ли я понимаю, что причина в разных GUID, из-за чего IMyInterface.Handle и IMyInterface2.Handle тоже разные, и если б GUID не различались (это вообще возможно?), то и проблемы б не было?

Delphi vs C++ vs C#

Qraizer — Fri, 20 Dec 2013 15:30:39 +0000

Qraizer: Та я ж забуду туда заглядывать.

Добавлено 20.12.13, 15:31
А! Подписка ж есть. Да, похоже ты прав.

Добавлено 20.12.13, 15:31
О! А обсуждение можно и Плюсовом разделе оформить. Точно.

Delphi vs C++ vs C#

korvin — Fri, 20 Dec 2013 14:50:55 +0000

korvin:

Цитата Qraizer @ 20.12.13, 13:35

но я там редкий гость

Ну и что, что редкий? Там и публикуй.

Delphi vs C++ vs C#

Qraizer — Fri, 20 Dec 2013 13:35:06 +0000

Qraizer:

Цитата MyNameIsIgor @ 19.12.13, 17:10

Ну, тогда измените мой пример.

Зачем? Ты понял мою мысль, я понял твою. Я ж не говорю, мол, бесполезная фича, я говорю, без неё обойтись можно практически безболезненно. Для сравнения: без лямбд тоже обойтись можно, но отнюдь не так безболезненно.

Цитата MyNameIsIgor @ 19.12.13, 17:10

Т.е. вы таки покажете код, который гарантированно на любом компиляторе покажет мне требуемую диагностику?

Если б он был, не требовалось бы ничего нового стандартизировать. Фактически же, разница примерно как с неявным int-ом: в C это варнинг, в C++ - ошибка.

P.S. Когда занимался мультиметодами, интеловый компилер достал просто этим варнингом. Но там так было нужно, это не ошибка. Получалось что-то вроде (после разворачивания списков типов):

template <typename T> class Value { virtual T doIt() = 0; };

template <typename T1, typename T2>

class A: public Value<T1>, public Value<T2> { /* ... */ };

template <typename T1, typename T2>

class B1: public A<T1, T2> { virtual T1 doIt(); };

template <typename T1, typename T2>

class B2: public B1<T1, T2> { virtual T2 doIt(); };

Класс A использовался для восстановления динамического типа Tx из базового T посредством вызова селектора Value<>::doIt(). Список типов из вот таких вот A итерировался по всем параметрам мультиметода, восстанавливая динамический тип каждого.

Добавлено 20.12.13, 13:45

Цитата MyNameIsIgor @ 19.12.13, 17:10

Оставив в стороне необходимость фичи, я не понимаю, каким образом она является синтаксическим сахаром?

Ну не синтаксическим. Всё равно сахаром. Разве сложно это сделать самостоятельно? При определённых условиях. Я ради прикола когда-то реализовал подобную вещь на BC4.5 ещё, который в отличие от VC и Intel поддерживал спецификацию исключений для функций, и использовал её, чтобы протащить неожидаемое исключение сквозь спецификацию наружу. При условии единого полиморфного предка для всех классов исключений с фабрикой копирования контейнер сооружается легко. Вот только не пригодилось ни разу. Вся роль нового Стандарта тут, это обязывание компиляторов делиться скрытой RTTI с реализациями STL, чтобы те могли предоставить готовый же std::nested_exception без упомянутых ограничений.

Добавлено 20.12.13, 14:01

Цитата MyNameIsIgor @ 19.12.13, 17:10

С чего бы? Конструктор потомка то ещё не отработал.

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

Цитата MyNameIsIgor @ 19.12.13, 14:54

Замени на метод.

Не уловил сути задачи. Что мешает написать просто test(int& i) : i(i) {};?

Добавлено 20.12.13, 14:09
Чёрт... Парни, подскажите, где лучше всего создать тему по мультиметодам. В январе пойду в отпуск на пару недель, надо взять себя в руки и-таки опубликовать. Лучше всего подходят "Наши проекты", но я там редкий гость. Плюсовый раздел подходит для обсуждения, но не публикации.

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 19 Dec 2013 17:10:45 +0000

MyNameIsIgor:

Цитата Qraizer @ 19.12.13, 16:58

Отнюдь.

Ну, тогда измените мой пример.

Цитата Qraizer @ 19.12.13, 16:58

Т.е. таки сахар

Я же сказал - надо подумать.

Цитата Qraizer @ 19.12.13, 16:58

Не новая, улучшенная старая

Т.е. вы таки покажете код, который гарантированно на любом компиляторе покажет мне требуемую диагностику?

Цитата Qraizer @ 19.12.13, 16:58

Это прекрасно делалось мааааленькой модификацией семантики throw-спецификаторов.

Т.е. не сахар.

Цитата Qraizer @ 19.12.13, 16:58

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

Оставив в стороне необходимость фичи, я не понимаю, каким образом она является синтаксическим сахаром?

Добавлено 19.12.13, 17:11

Цитата Qraizer @ 19.12.13, 16:58

После отработки делегируемого объект-то уже будет иметь свой собственный динамический тип, ведь так?

С чего бы? Конструктор потомка то ещё не отработал.

Delphi vs C++ vs C#

Qraizer — Thu, 19 Dec 2013 16:58:36 +0000

Qraizer:

Цитата MyNameIsIgor @ 19.12.13, 13:59

Цитата Qraizer @ 19.12.13, 13:48

делегирующий конструктор - метод

Метод требует, чтобы все поля класса были сконструированы, делегирующий конструктор - нет.

Отнюдь. Метод не обязан полагаться на контракты. Да, это плохо, но в каждом классе есть хотя бы один такой, собственно конструктор (иногда неявный), так что считать ли некий метод (не конструктор) специальным, личное дело прогаммера. Впрочем, на эту тему я писал не раз, не буду повторяться. Там один итог в итоге: такие методы должны быть приватные. Собственно делегируемые конструкторы по ряду причин тоже.

Цитата MyNameIsIgor @ 19.12.13, 13:59

Цитата Qraizer @ 19.12.13, 13:48

пользовательские литералы- #defines

Я подумаю... Не очень хорошо знаю пользовательские литералы. Но как минимум - засорение глобального пространства имён.

Т.е. таки сахар. Вместо макросов подойдут и inline. Даже constexpr, если есть возможность.

Цитата MyNameIsIgor @ 19.12.13, 13:59

Цитата Qraizer @ 19.12.13, 13:48

override - улучшенная диагностика многих компиляторов

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

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

Цитата MyNameIsIgor @ 19.12.13, 13:59

Цитата Qraizer @ 19.12.13, 13:48

noexcept - throw();

Нет. Я могу написать

template<class T>

void foo(T t) noexcept(noexcept(T(t)) { /*...*/ }

И вообще, noexept(expression) - это константное выражение, которое я могу использовать, например, при выборе специализации шаблона.

Это прекрасно делалось мааааленькой модификацией семантики throw-спецификаторов.
Но тут надо отметить, что throw()-спецификаторы себя не оправдали. Так что на лицо не столько сахар, сколько мотивация к отказу от старой семантики.

Цитата MyNameIsIgor @ 19.12.13, 13:59

Цитата Qraizer @ 19.12.13, 13:48

std::nested_exception - не заменяется, но непонятно, а занафик нужно, окромя редчайших моментов отладки

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

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

Добавлено 19.12.13, 17:02

Цитата D_KEY @ 19.12.13, 14:49

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

Ум-м-м... до меня только что дошло. После отработки делегируемого объект-то уже будет иметь свой собственный динамический тип, ведь так? Так что не виртуальные конструкторы, "о котором так много говорили ©" дельфисты, но-таки полноформатный полиморфизм в делегирующем конструкторе мы вполне получаем. Однако, во-первых, нет симметрии с деструкторами, во-вторых, ... ну были ж фабрики.

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 19 Dec 2013 14:54:39 +0000

MyNameIsIgor:

Цитата D_KEY @ 19.12.13, 14:49

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

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

Добавлено 19.12.13, 15:05
D_KEY, вот код

struct test

{

int& i;

std::string s;

test(int& i) : test(i, std::string()) {}

test(int& i, std::string s) : i(i), s(std::move(s)) {}

};

Замени на метод.

Delphi vs C++ vs C#

D_KEY — Thu, 19 Dec 2013 14:49:22 +0000

D_KEY:

Цитата MyNameIsIgor @ 19.12.13, 14:40

делегирующий же конструктор именно частью списка инициализации и является.

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

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 19 Dec 2013 14:40:32 +0000

MyNameIsIgor:

Цитата D_KEY @ 19.12.13, 14:39

После отработки вызываемого конструктора у тебя будет готовый объект со всеми инициализированными полями. Или я ошибаюсь и тут?

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

Добавлено 19.12.13, 14:41

Цитата D_KEY @ 19.12.13, 14:32

Виртуальные методы вводят новую концепцию динамической диспетчеризации метода по типу объекта.

Что на практике всего лишь указатели на функции - можно сделать руками.

Delphi vs C++ vs C#

D_KEY — Thu, 19 Dec 2013 14:39:05 +0000

D_KEY:

Цитата MyNameIsIgor @ 19.12.13, 13:59

Цитата Qraizer @ 19.12.13, 13:48

делегирующий конструктор - метод

Метод требует, чтобы все поля класса были сконструированы, делегирующий конструктор - нет.

Delphi vs C++ vs C#

Romkin — Thu, 19 Dec 2013 14:33:09 +0000

Romkin: Все можно назвать синтаксическим сахаром, кроме ассемблера. Да и там он есть.

Delphi vs C++ vs C#

D_KEY — Thu, 19 Dec 2013 14:32:35 +0000

D_KEY:

Цитата MyNameIsIgor @ 19.12.13, 13:18

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

Да, но вот считать ли это новой семантикой?

Цитата

Ну, виртуальные методы - это сахар или нет?

Виртуальные методы вводят новую концепцию динамической диспетчеризации метода по типу объекта. Т.е. семантически новый вид методов. В случае await мы просто получаем ..эм.. автоматический генератор правильного для нашего случая std::future. Или мы получаем что-то еще?

Впрочем, какой-то мутный разговор получается :D

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 19 Dec 2013 14:23:11 +0000

MyNameIsIgor:

Цитата Flex Ferrum @ 19.12.13, 14:21

В том то и дело, что нет. Приходится извращаться.

Тогда почему Qraizer не прав в этом пункте?

Delphi vs C++ vs C#

Flex Ferrum — Thu, 19 Dec 2013 14:21:46 +0000

Flex Ferrum:

Цитата MyNameIsIgor @ 19.12.13, 14:21

А оно чем-то заменяется?

В том то и дело, что нет. :) Приходится извращаться.

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 19 Dec 2013 14:21:04 +0000

MyNameIsIgor:

Цитата Flex Ferrum @ 19.12.13, 14:11

Вот здесь

А оно чем-то заменяется?

Delphi vs C++ vs C#

Flex Ferrum — Thu, 19 Dec 2013 14:11:28 +0000

Flex Ferrum:

Цитата Qraizer @ 19.12.13, 13:48

Я где-то неправ?

Вот здесь:

Цитата Qraizer @ 19.12.13, 13:48

std::nested_exception - не заменяется, но непонятно, а занафик нужно, окромя редчайших моментов отладки.

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 19 Dec 2013 13:59:58 +0000

MyNameIsIgor:

Цитата Qraizer @ 19.12.13, 13:48

делегирующий конструктор - метод

Метод требует, чтобы все поля класса были сконструированы, делегирующий конструктор - нет.

Цитата Qraizer @ 19.12.13, 13:48

пользовательские литералы- #defines

Цитата Qraizer @ 19.12.13, 13:48

override - улучшенная диагностика многих компиляторов

Цитата Qraizer @ 19.12.13, 13:48

noexcept - throw();

Нет. Я могу написать

template<class T>

void foo(T t) noexcept(noexcept(T(t)) { /*...*/ }

Цитата Qraizer @ 19.12.13, 13:48

std::nested_exception - не заменяется, но непонятно, а занафик нужно, окромя редчайших моментов отладки

Цитата Qraizer @ 19.12.13, 13:48

Я где-то неправ?

Мне кажется, что по всем пунктам.

Delphi vs C++ vs C#

Qraizer — Thu, 19 Dec 2013 13:48:26 +0000

Qraizer:

Цитата MyNameIsIgor @ 18.12.13, 20:33

Цитата Qraizer @ 18.12.13, 19:54

Делегирующие конструкторы, пользовательские литералы, override, , noexcept, может быть даже std::nested_exception. Не полный список. Это всё сахар,

Можете звать это сахаром, но это не синтаксический сахар просто по его определею - всё это новые возможности, которых раньше не было, особенно noexcept.

Я где-то неправ?

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 19 Dec 2013 13:18:56 +0000

MyNameIsIgor:

Цитата D_KEY @ 19.12.13, 12:19

Думаю, что да. По крайней мере каждое конкретное применение await можно сделать руками.

Ну, там же ещё автоматом за локальными переменными хранится, что тоже придётся делать руками, если попытаться воспроизвести такую stackless coroutine. Это всё же разная семантика.

Цитата D_KEY @ 19.12.13, 12:19

Я ошибаюсь?

Ну, виртуальные методы - это сахар или нет? Руками сделать можно. Степень поддержки со стороны компилятора будет такой же, как и для async.

Delphi vs C++ vs C#

D_KEY — Thu, 19 Dec 2013 12:19:40 +0000

D_KEY:

Цитата MyNameIsIgor @ 19.12.13, 10:18

Цитата D_KEY @ 19.12.13, 08:10

Эм, а что же это?

Т.е. ты без async можешь сделать всё то же самое?

Думаю, что да. По крайней мере каждое конкретное применение await можно сделать руками. Но подробно не смотрел на это дело. Я ошибаюсь?

Delphi vs C++ vs C#

Romkin — Thu, 19 Dec 2013 12:04:32 +0000

Romkin:

Цитата treeS @ 19.12.13, 11:18

Средствами shell в делфи есть спецальный компонент.

Загрузился. Облазил палитру. Поискал в исходниках. Для разнообразия в 2010. Где оно есть?

Delphi vs C++ vs C#

treeS — Thu, 19 Dec 2013 11:18:58 +0000

treeS:

Цитата OpenGL @ 19.12.13, 10:11

Цитата Romkin @ 19.12.13, 09:55

Сдается мне, что-то тут перепутано с точностью до наоборот.

Кстати да, скорей всего. Как удалить в корзину надо будет гуглить :)

Средствами shell в делфи есть спецальный компонент.

Добавлено 19.12.13, 11:19
И поверте. Ничего не перепутанно

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 19 Dec 2013 10:18:30 +0000

MyNameIsIgor:

Цитата D_KEY @ 19.12.13, 08:10

Эм, а что же это?

Т.е. ты без async можешь сделать всё то же самое?

Delphi vs C++ vs C#

OpenGL — Thu, 19 Dec 2013 10:11:43 +0000

OpenGL:

Цитата Romkin @ 19.12.13, 09:55

Сдается мне, что-то тут перепутано с точностью до наоборот.

Кстати да, скорей всего. Как удалить в корзину надо будет гуглить :)

Delphi vs C++ vs C#

Romkin — Thu, 19 Dec 2013 09:55:26 +0000

Romkin:

Цитата treeS @ 19.12.13, 09:14

Но средствами делфи происходит перемещения в корзину, целый день он с этим мучался, и на следующий день, он узнал о Win API функции DeleteFile

Фигасе "средства Delphi". В корзину - это функцию оболочки пользовать надо. А DeleteFile является исторически оберткой в SysUtils, подается строка туда.
Сдается мне, что-то тут перепутано с точностью до наоборот. Мне вот вроде вспоминается что я искал как удалить файл в корзину когда-то.

Delphi vs C++ vs C#

OpenGL — Thu, 19 Dec 2013 09:46:58 +0000

OpenGL: Значит это хреновый программист. Я наверняка уже через полгода программирования на дельфе (когда писал всякую хрень для себя в школе) знал, как оно делается :D

Delphi vs C++ vs C#

treeS — Thu, 19 Dec 2013 09:14:27 +0000

treeS: О!!! в тему.
Недавно у нашего делфи программиста с десятилетним стажем появилась серьезная проблема которую он решал 2 дня, задача была удалить файл. Но средствами делфи происходит перемещения в корзину, целый день он с этим мучался, и на следующий день, он узнал о Win API функции DeleteFile и у него ушло 6 часов что бы он понял как засунуть в нее указатель на строку))) И он решил эту проблему!!! С гордостью потом всем рассказывал!

Delphi vs C++ vs C#

D_KEY — Thu, 19 Dec 2013 08:10:31 +0000

D_KEY:

Цитата MyNameIsIgor @ 18.12.13, 17:50

Цитата D_KEY @ 18.12.13, 16:02

MyNameIsIgor, а если таки добавят твой "любимый" async?

Я не буду его юзать. Но async - не сахар.

Эм, а что же это?

Добавлено 19.12.13, 08:25

Цитата korvin @ 18.12.13, 19:49

Цитата D_KEY @ 18.12.13, 16:02

Чтобы не переписывать проекты

Зачем переписывать? F# доступен давно, надо было сразу на нем писать то что удобней.

Нельзя просто так взять и начать писать на F# ;)

Надо было... Кому надо было и зачем?

Delphi vs C++ vs C#

MyNameIsIgor — Wed, 18 Dec 2013 20:33:35 +0000

MyNameIsIgor:

Цитата Qraizer @ 18.12.13, 19:54

Delphi vs C++ vs C#

Qraizer — Wed, 18 Dec 2013 19:54:19 +0000

Qraizer:

Цитата MyNameIsIgor @ 18.12.13, 15:37

Цикл по коллекциям и auto? Всего то

Не только. Делегирующие конструкторы, пользовательские литералы, override, , noexcept, может быть даже std::nested_exception. Не полный список. Это всё сахар, который удобен, и я не вижу других причин его стандартизации. Вот многопоточность, атомарные операции, семантика перемещения, decltype, лямбды, новые символьные типы, контейнеры, регэкспы итп - это не сахар, и такого больше. И это хорошо.

Delphi vs C++ vs C#

korvin — Wed, 18 Dec 2013 19:49:22 +0000

korvin:

Цитата D_KEY @ 18.12.13, 16:02

Чтобы не переписывать проекты

Зачем переписывать? F# доступен давно, надо было сразу на нем писать то что удобней.

Delphi vs C++ vs C#

MyNameIsIgor — Wed, 18 Dec 2013 17:50:59 +0000

MyNameIsIgor:

Цитата D_KEY @ 18.12.13, 16:02

MyNameIsIgor, а если таки добавят твой "любимый" async?

Я не буду его юзать. Но async - не сахар.

Delphi vs C++ vs C#

Wound — Wed, 18 Dec 2013 16:15:48 +0000

Wound:

Цитата korvin @ 18.12.13, 16:00

Зачем это что-то вводить, если уже есть F# например?

Ну на счет F# я ничего не скажу, слышал о таком, но не щупал. Там в коментах вроде как плачут что у них там констант нет толковых, а тут аж такие изменения. Я просто диву даюсь, люди так рады что им придется писать на 2 строчки меньше кода, это при том что он станет менее понятным. Неужели им так тяжело было придумать имена для параметров конструктора отличные от имен мемберов, ну или на крайний случай инициализировать еретиковым способом через this, как они все любят это делать?
Или вот новшество:

Цитата

Использование статических классов в директиве using

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

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

Delphi vs C++ vs C#

D_KEY — Wed, 18 Dec 2013 16:02:50 +0000

D_KEY: MyNameIsIgor, а если таки добавят твой "любимый" async?

Добавлено 18.12.13, 16:03

Цитата korvin @ 18.12.13, 16:00

Цитата Wound @ 18.12.13, 13:00

Я спрашиваю им что уже больше нечего вводить кроме как вот этого голого синтаксического сахара?

Зачем это что-то вводить, если уже есть F# например?

Чтобы не переписывать проекты :)

Delphi vs C++ vs C#

korvin — Wed, 18 Dec 2013 16:00:01 +0000

korvin:

Цитата Wound @ 18.12.13, 13:00

Я спрашиваю им что уже больше нечего вводить кроме как вот этого голого синтаксического сахара?

Зачем это что-то вводить, если уже есть F# например?

Delphi vs C++ vs C#

MyNameIsIgor — Wed, 18 Dec 2013 15:37:59 +0000

MyNameIsIgor:

Цитата Qraizer @ 18.12.13, 15:34

Справедливости ради следует отметить и сахар в новом Стандарте Плюсов

Цикл по коллекциям и auto? Всего то :)

Delphi vs C++ vs C#

Qraizer — Wed, 18 Dec 2013 15:34:28 +0000

Qraizer: Справедливости ради следует отметить и сахар в новом Стандарте Плюсов. Но ведь помимо сахара там и мяса дофига.

Delphi vs C++ vs C#

Wound — Wed, 18 Dec 2013 13:59:36 +0000

Wound:

Цитата IL_Agent @ 18.12.13, 13:48

Без ?. приходится извращаться с if'ами или монадными велосипедами вроде .With

И в чем извращение состоит? Проверить явно объет на Null перед его использованием - это проблема? :huh:

Цитата IL_Agent @ 18.12.13, 13:48

Без возможности объявления переменных при передаче как out их приходится объявлять отдельно - лишняя строка неизбежна.

Огоспади!!! Лишняя строка!!! У вас что там на строках экономить принято? :D

Цитата IL_Agent @ 18.12.13, 13:48

Без вывода типа в конструкторе дженерика приходится городить фабрику.

Так у вас же там встроеные фабрики искоропки, разве нет?

А по поводу остального? Остальное я так полагаю, даже тебе не интересно?

Цитата IL_Agent @ 18.12.13, 13:48

Wound, ты сам не знаешь чего хочешь.

Да я понять хотел, чего синтаксический сахар представляют как будущее C#. :-?

Delphi vs C++ vs C#

IL_Agent — Wed, 18 Dec 2013 13:48:47 +0000

IL_Agent:

Цитата Wound @ 18.12.13, 12:47

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

Без ?. приходится извращаться с if'ами или монадными велосипедами вроде .With
Без возможности объявления переменных при передаче как out их приходится объявлять отдельно - лишняя строка неизбежна.
Без вывода типа в конструкторе дженерика приходится городить фабрику.

Wound, ты сам не знаешь чего хочешь.

Delphi vs C++ vs C#

Wound — Wed, 18 Dec 2013 13:00:36 +0000

Wound:

Цитата D_KEY @ 18.12.13, 12:53

Так я и прошу пример такой важной вещи. Что тебе не хватает?

Да вы меня может быть не так поняли? Я не говорю что они не ввели чего то, что я ждал, а ввели вот эту косметику. Я спрашиваю им что уже больше нечего вводить кроме как вот этого голого синтаксического сахара? И даже если так, то какой смысл в этом нововведении? Судя по тому как было, и как будет, я не вижу особой принципиальной разницы. Какой смысл тогда тянуть это в язык?
Я просто вот решил на C# попробовать перевестись в проект, но такие нововедения меня както смущают, такое ощущение что навязывают людям какую то свою систему, максимум лени, или както так.

Добавлено 18.12.13, 13:02

Цитата D_KEY @ 18.12.13, 12:53

Так это изначально их путь.

Голый синтаксический сахар? Да вроде сколько источников видел, нигде про такое не слышал. :-?

Delphi vs C++ vs C#

D_KEY — Wed, 18 Dec 2013 12:53:34 +0000

D_KEY:

Цитата Wound @ 18.12.13, 12:47

Цитата D_KEY @ 18.12.13, 12:40

Например?

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

Так я и прошу пример такой важной вещи. Что тебе не хватает?

Цитата

А тут голый синтаксический сахар

Так это изначально их путь.

Delphi vs C++ vs C#

Wound — Wed, 18 Dec 2013 12:47:27 +0000

Wound:

Цитата D_KEY @ 18.12.13, 12:40

Например?

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

Ну просто почитай статью, потом почитай хотя бы первые 10 коментов, такое ощущение что пихают туда всякое, а народ то как рад, первая необходимость прям, как они без этого жили? :D Я просто не пойму в чем смысл этого? Ввести в язык все мыслимые и не мыслимые конструкции на любой вкус?

Delphi vs C++ vs C#

D_KEY — Wed, 18 Dec 2013 12:40:53 +0000

D_KEY:

Цитата Wound @ 18.12.13, 12:03

Я бы хотел увидеть какие то действительно полезности

Например?

Delphi vs C++ vs C#

IL_Agent — Wed, 18 Dec 2013 12:17:27 +0000

IL_Agent:

Цитата Wound @ 18.12.13, 12:03

Я бы хотел увидеть какие то действительно полезности, а не какие то ненужные вещи

Имхо ?. и объявление переменных в out - вполне полезный сахарок. Вывод типов в конструкторе - тоже нужно.

Delphi vs C++ vs C#

Wound — Wed, 18 Dec 2013 12:03:32 +0000

Wound:

Цитата IL_Agent @ 18.12.13, 10:49

А ты чего бы хотел увидеть ?

Я бы хотел увидеть какие то действительно полезности, а не какие то ненужные вещи, которые и так делаются без особых проблем.
Ну вот взять хотя бы эти конструкторы, C# программисты не могут придумать имена переменным? Или какой смысл у первичных конструкторов? Остальное тоже, както больше смахивает на никому не нужную косметику. Зачем ее туда столько пихать? Только чтобы было?

Delphi vs C++ vs C#

MyNameIsIgor — Wed, 18 Dec 2013 10:56:47 +0000

MyNameIsIgor:

Цитата Wound @ 18.12.13, 10:45

Какое то будущее у C# унылое совсем, если это самые смаки из того что будет

Они следуют своему кредо :)

Сахарозы уже столько, что всю её выучить уже не менее сложно, чем постичь все тонкости C++.

Delphi vs C++ vs C#

IL_Agent — Wed, 18 Dec 2013 10:49:59 +0000

IL_Agent:

Цитата Wound @ 18.12.13, 10:45

Какое то будущее у C# унылое совсем, если это самые смаки из того что будет

А ты чего бы хотел увидеть ?

Delphi vs C++ vs C#

Wound — Wed, 18 Dec 2013 10:45:56 +0000

Wound: Какое то будущее у C# унылое совсем, если это самые смаки из того что будет -> Будущее С#
:ph34r:

Delphi vs C++ vs C#

jack128 — Sat, 23 Feb 2013 23:17:18 +0000

jack128:

Цитата Keepun @ 23.02.13, 15:35

А надо?

ради лямбд конечно не надо. А вот например ПМ - это да.

Delphi vs C++ vs C#

D_KEY — Sat, 23 Feb 2013 16:34:05 +0000

D_KEY:

Цитата Keepun @ 23.02.13, 15:35

Цитата D_KEY @ 18.02.13, 21:36

А на Scala с F# совсем не смотришь?

А надо?

Я бы советовал.

Delphi vs C++ vs C#

korvin — Sat, 23 Feb 2013 16:04:31 +0000

korvin:

Цитата Keepun @ 23.02.13, 15:35

А надо?

Конечно.

Delphi vs C++ vs C#

Keepun — Sat, 23 Feb 2013 15:35:47 +0000

Keepun:

Цитата D_KEY @ 18.02.13, 21:36

А на Scala с F# совсем не смотришь?

А надо?

Delphi vs C++ vs C#

--Ins-- — Tue, 19 Feb 2013 07:49:53 +0000

--Ins--:

Цитата D_KEY @ 18.02.13, 21:36

А на Scala с F# совсем не смотришь?

Никак. По мере надобности можно и посмотреть будет

Delphi vs C++ vs C#

D_KEY — Mon, 18 Feb 2013 21:36:03 +0000

D_KEY: А на Scala с F# совсем не смотришь?

Delphi vs C++ vs C#

--Ins-- — Mon, 18 Feb 2013 20:04:01 +0000

--Ins--:

Цитата D_KEY @ 18.02.13, 18:23

Ты на что, кстати, больше смотришь? На шарп или яву?

Примерно одинаково

Delphi vs C++ vs C#

D_KEY — Mon, 18 Feb 2013 18:23:43 +0000

D_KEY:

Цитата --Ins-- @ 18.02.13, 17:45

в том же шарпе

Ты на что, кстати, больше смотришь? На шарп или яву?

Delphi vs C++ vs C#

--Ins-- — Mon, 18 Feb 2013 17:45:52 +0000

--Ins--:

Цитата leo @ 18.02.13, 17:28

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

Кстати, лично мне это решение не очень нравиться с csDesigning. Код, которые может быть выполнен только в редакторе, оказывается в скомпилированном приложении. Мелочь конечно как правило, но в том же шарпе этого избежали

Delphi vs C++ vs C#

leo — Mon, 18 Feb 2013 17:28:29 +0000

leo:

Цитата trainer @ 18.02.13, 10:20

csDesigning, если я правильно помню, нужен только для обеспечения design-time функционала - визуализации в редакторе форм

Delphi vs C++ vs C#

KILLER — Mon, 18 Feb 2013 10:48:51 +0000

KILLER:

Цитата Shaggy @ 14.02.13, 21:54

Цитата

А зачем их занулять?

в целях безопасности
вот придёт к тебе злой хакер, подключится к компу по FireWire, и сольёт дамп всей физ. памяти к себе на диск :)

А как тебе зануление поможет? Ты ведь зануляешь не кусок памяти, а тупо переменной-указателю присваиваешь 0. Кусок памяти так и останется с инфой, пока его не перетерет что то другое. И злой хакер получит инфу. Чтоб не получил, нужно наверное вызывать какой нибудь memset указывая размер заполняемой нулями памяти еще до попытки освобождения памяти и вызова деструкторов, а не после. После - это уже не твоя память.
Так зачем занулять то? :unsure:

Добавлено 18.02.13, 10:59

Цитата Shaggy @ 14.02.13, 21:54

и почему затычка? ты удаление объекта, например, тоже рассматриваешь как затычку к утечке ресурсов?

Так ты удаляешь руками тогда, когда выделяешь руками. А не тупо всегда. В остальных случаях, ты не удаляешь руками. Что тут нелогично и рассматривать как затычку?

Цитата Shaggy @ 14.02.13, 23:12

появился вирт метод -> поправили деструктор

Так это и есть костыль. Тебе постоянно нужно помнить, что если появился вирт. метод -> поправили деструктор. Иначе fail...

Цитата Shaggy @ 14.02.13, 23:12

речь шла о указателе на область памяти, а не о объектах
и зануление памяти, а не указателя на неё

А как ты занулишь память после того как она уже не твоя? Что то ты не договариваешь. Память можно занулить только до того как ее осободили, в противном случае это уже будет грязным хаком. А вот указатель вполне себе можно занулить и после удаления. Так о чем речь там шла? Или может в делфи после освобождения объекта и вызова деструкторов, та память которой он владел еще не помечена как свободная и все еще принадлежит этому, уже удаленому объекту? :wacko:

Delphi vs C++ vs C#

trainer — Mon, 18 Feb 2013 10:20:21 +0000

trainer:

Цитата leo @ 17.02.13, 12:24

по крайней мере проверка особого состояния визуального проектирования csDesigning встречается о-очень часто

csDesigning, если я правильно помню, нужен только для обеспечения design-time функционала - визуализации в редакторе форм.

Delphi vs C++ vs C#

leo — Sun, 17 Feb 2013 12:24:32 +0000

leo:

Цитата Qraizer @ 14.02.13, 20:41

Так что там у вас с Clear из деструкторов?

Если в общем, то, видимо, "мат в 3 хода" ;)
А если по Алёхински развернуть шахматную доску и посмотреть на ситуацию глазами "противника"? Я лично считаю, что внутренняя кухня дельфийской объектной модели заточена конкретно (можно сказать исключительно) под VCL и ее расширения (и в качестве отдельного штриха - на поддержку интерфейсов), а возможность использования этой модели для других, общих задач - это типа бонуса, побочного продукта VCL-технологии. Этим по идее можно объяснить и косяк с вызовом TList.Clear из деструктора - ребята создавали иерархию TList под свои внутренние нужды и не думали, что кому-то придет в голову использовать TList для чего-то более сложного. В самой же VCL ес-но все продумано и "схвачено", и те же базовые классы TComponent и TControl имеют собственные "инварианты" состояния типа ComponentState и ControlState, предусматривающие в т.ч. и различные промежуточные "недоделанные" состояния (csCreating, csLoading, csReading, csDestroying и т.п.). Поэтому, уж точно, чем "кишат" исходники VCL, так это проверками этих состояний (по крайней мере проверка особого состояния визуального проектирования csDesigning встречается о-очень часто, если не сказать "на каждом шагу"). Соотв-но, если мы "на свой страх и риск" пытаемся наследоваться от неких стандартных VCL-клаcсов или их обслуги (типа TList), то либо нужно действовать по установленным правилам, либо "пенять на себя".
Можно конечно обсуждать и мусолить грабли, на которые попался Chow. Но ведь он же сам признался, что пытался наследоваться от ветки TComponent, а значит и сам создавал очередного наследника TComponent, и соотв-но должен был соблюдать "внутренние правила игры" этой ветки, в частности проверять "кое-где" флаг csDestroying. Конечно остается вопрос, а где "кое-где", и почему именно в Clear. Но что поделаешь, "неразборчивые связи" всегда чреваты сюрпризами ;). К тому же и плюсовые стандарты напичканы не только примерами явных error, но и ill-formed - все ли из них компилятор способен отследить и предупредить?

Delphi vs C++ vs C#

D_KEY — Fri, 15 Feb 2013 07:40:59 +0000

D_KEY:

Цитата Shaggy @ 14.02.13, 23:12

ты не перекрываешь вирт методы в потомке(вообще ни одного)
=
тебе поровну, появится вызов или нет

А как только решили перекрыть - бежим смотреть деструктор?

Цитата

ты перекрываешь вирт методы в потомке
->

begin

inherited;

// удаление полей, с кот. ты работаешь в виртуальных методах

end;

и не надо ни в чём убеждаться

А при переписывании реализации виртуальных методов, проверяем, не сломался ли деструктор? Здорово.

Цитата

появился вирт метод -> поправили деструктор

:facepalm:

Цитата

либо для всех вариантов писать деструктор так
и вообще не напрягаться

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

Добавлено 15.02.13, 07:46

Цитата Shaggy @ 14.02.13, 23:12

логируй в BeforeDestruction

Кстати, а разве для обеспечения полиморфной пост-инициализации не достаточно было бы AfterConstruction?

Delphi vs C++ vs C#

MyNameIsIgor — Fri, 15 Feb 2013 05:16:41 +0000

MyNameIsIgor:

Цитата Shaggy @ 14.02.13, 21:54

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

Ну, сделаю я аллокатор, зануляющий память, и отдам его контейнеру - делов то :)

Delphi vs C++ vs C#

Shaggy — Thu, 14 Feb 2013 23:12:11 +0000

Shaggy:

Цитата Chow @ 14.02.13, 22:39

в беседе с тобой надо иметь стальные нервы.

это хорошо

Цитата Chow @ 14.02.13, 22:39

Вызов, вызов появится, а не сам метод! Метод давно есть, я давно его перекрыл. Убедился что в родительских деструкторах он не вызывается. Где гарантии что он потом не начнет вызываться?!

вариант 1
ты не перекрываешь вирт методы в потомке(вообще ни одного)
=
тебе поровну, появится вызов или нет

вариант 2
ты перекрываешь вирт методы в потомке
->

begin

inherited;

// удаление полей, с кот. ты работаешь в виртуальных методах

end;

и не надо ни в чём убеждаться
появился вирт метод -> поправили деструктор
либо сразу писать деструктор так
=
и тебе опять поровну

либо для всех вариантов писать деструктор так
и вообще не напрягаться

Цитата Chow @ 14.02.13, 22:39

Как я могу залоггировать значение поля класса будучи в деструкторе этого класса (а не будучи в деструкторе его поля!) если у меня нет гарантии что после этого значение поля не изменится в родительских деструкторах?

первой строкой деструктора и точка

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

Цитата Chow @ 14.02.13, 22:39

Что за бред? Даже если и потеоретизировать - то хакеру пофигу зануление указателей на объекты т.к. это не зануление самих объектов на которые они указывали.
Так что все хакер прекрасно увидит. Какая безопастность?

речь шла о указателе на область памяти, а не о объектах
и зануление памяти, а не указателя на неё

Delphi vs C++ vs C#

Chow — Thu, 14 Feb 2013 22:39:11 +0000

Chow: Shaggy, в беседе с тобой надо иметь стальные нервы.

Цитата Shaggy @ 14.02.13, 21:54

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

Я хочу сохранить значение всех полей (членов-данных) класса на момент удаления объекта (этого класса) - т.е. сохранить сам класс (его образ, так сказать, перед смертью).
Я не сохраняю объект в процессе удаления. Я сохраняю объект в процессе удаления другого объекта который его аггрегирует (находится в композиции).
Как я могу залоггировать значение поля класса будучи в деструкторе этого класса (а не будучи в деструкторе его поля!) если у меня нет гарантии что после этого значение поля не изменится в родительских деструкторах?

Цитата Shaggy @ 14.02.13, 21:54

зачем смотреть всю цепочку? ты в свой деструктор смотри

Зачем? Что я там не видел?

Цитата Shaggy @ 14.02.13, 21:54

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

:wall:
Вызов, вызов появится, а не сам метод! Метод давно есть, я давно его перекрыл. Убедился что в родительских деструкторах он не вызывается. Где гарантии что он потом не начнет вызываться?!

Цитата Shaggy @ 14.02.13, 21:54

в целях безопасности
вот придёт к тебе злой хакер, подключится к компу по FireWire, и сольёт дам всей физ. памяти к себе на диск

Вы про FreeAndNil полей класса в его деструкторе? Даже если и потеоретизировать - то хакеру пофигу зануление указателей на объекты т.к. это не зануление самих объектов на которые они указывали.
Так что все хакер прекрасно увидит. Какая безопастность?

Delphi vs C++ vs C#

Shaggy — Thu, 14 Feb 2013 21:54:42 +0000

Shaggy:

Цитата leo @ 14.02.13, 17:32

Сравни рекомендацию вызывать inherited Destroy как last action, со своим прямо противоположным вариантом решения "всех проблем". Или ты его рассматриваешь только как затычку в частном случае?

не всех, а вполне конкретной
[добавлено]
хотя нет, я всё больше склоняюсь к такой конструкции

constructor ...

begin

// создание своего

// настройка своего

// ...

// вызов унаследованного

// переопределение настроек унаследованного

end;

ну и наоборот в деструкторе
[/добавлено]
и почему затычка? ты удаление объекта, например, тоже рассматриваешь как затычку к утечке ресурсов?

Цитата leo @ 14.02.13, 17:32

Я когда-то пробовал (на заре перехода с TP\BP на дельфю) и нарвался на аналогичный косяк - хорошо, что сорцы под рукой и сразу все стало ясно. Между прочим, с тех пор у меня привычка выработалась (праноидальная ) в сырцы заглядывать - и косяки поискать, ну и поичиться кое-чему заодно

я его рассматриваю как аналог таких классов с++, как map, vector, string, etc. который можно допилить до юзабельного состояния с помощью наследования, при отсутствии шаблонов и дженериков

Цитата Chow @ 14.02.13, 19:29

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

Цитата Chow @ 14.02.13, 19:29

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

зачем смотреть всю цепочку? ты в свой деструктор смотри

Цитата Chow @ 14.02.13, 19:29

Откуда мне знать что в том обновлении нигде в деструкторе не появился вызов вирутального метода? Опять все цепочки перепроверять? Для всех проектов которые хочу пересобрать используя новую библиотеку/среду шерстить код вручную?

Цитата MyNameIsIgor @ 14.02.13, 18:37

А зачем их занулять?

в целях безопасности
вот придёт к тебе злой хакер, подключится к компу по FireWire, и сольёт дамп всей физ. памяти к себе на диск :)
но это так... я просто пытался придумать какую-нибудь доп. работу в классе, ради которой пришлось бы создавать деструктор
но похоже это тоже не покатит

Delphi vs C++ vs C#

Qraizer — Thu, 14 Feb 2013 20:41:20 +0000

Qraizer: leo вообще-то дело говорит, хотя, похоже, сам этого не понимает. Это как раз то, на предмет чего я просил напомнить. Спасибо, leo.
Ваша дискуссия лишний раз подтверждает тот факт, что процессы создания и разрушения объекта являются весьма щепетильными промежутками времени его (полу)существования. В плюсовой объектной модели поэтому и было решено во избежание прецедентов считать, что время жизни объекта не начинается, пока его конструктор полностью не завершит работу, и перестаёт существовать в момент вызова его деструктора, а также, что производные классы никак не должны влиять на щепетильные процессы базовых классов. Из этого и следует законодательно устаканенный порядок вызова конструкторов и деструкторов подобъектов. За этим следит компилятор, априори он не ошибается. Это даёт все необходимые гарантии для отношений между базовыми и производными классами - базовые классы защищены от влияния производных, производные имеют полное право полагаться на инварианты контрактов базовых. В Дельфи принято (ИМХО избыточно) демократическое решение, которое позволяет при необходимости вытворять очень клёвые вещи¹⁾. К сожалению в подавляющем большинстве практических ситуации, когда такой необходимости нет, за эту демократию приходится платить.
Конструкторы и деструкторы не даром называются "специальными методами классов". Они вынуждены работать с неким нечто, что вроде бы объект, но пока ещё или уже таковым не является. Ничего удивительного, в этом их предназначение - из мусора сделать объект с инвариантами или наоборот превратить объект в кучу шлака, который безболезненно может быть слит в утиль. И в объектной модели плюсов этими спец.методами и ограничивается набор мест в коде, где вместо объекта можно встретить шлак. В результате все остальные методы (все! без исключения) самого объекта имеет полное право рассчитывать на инварианты, созданные конструктором и ещё не уничтоженные деструктором. Никаких проверок, никаких ~~костылей~~ страховочных подстилок в лице хоть тех же занулений, никаких неожиданностей от базовых классов производным и наоборот. Нет инварианта -> исключение из конструктора -> нет объекта. Есть объект -> не было исключения -> конструктор завершился -> объект заинвариантен.
Вот основная причина, почему конструкторы и деструкторы обычно просты. Т.к. они не являются методами, манипулирующими состоянием объекта, поэтому пользователю класса они не нужны никогда, кроме крайних моментов времени существования его экземпляров. Поэтому они выполняют действия, практически никогда не нужные в другие моменты времени существования экземпляров класса. Поэтому они редко нуждаются в дальнейшей декомпозиции в пределах своей ответственности - области видимости своего класса. Однако иногда в такой декомпозиции потребность возникает. Например, если несколько конструкторов выполняют однотипные действия, или сходные действия понадобились в перегруженной операции присваивания. Никто не запрещает ввести методы для этого. Ради бога, почему нет. Но! В этом случае такие методы тоже следует отнести к спец.методам, ведь они тоже работают в щепетильные моменты времени, и вне этих моментов в них нет нужды. Вывод? ... Правильно! этим методам нечего делать в интерфейсе класса. Другими словами: методы, используемые конструкторами или деструкторами, обязаны быть приватными. Это решает все проблемы. Ну или по крайней мере эти проблемы не покидают пределов класса.
Так что там у вас с Clear из деструкторов?

Добавлено 14.02.13, 20:47

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

Delphi vs C++ vs C#

Chow — Thu, 14 Feb 2013 19:29:20 +0000

Chow:

Цитата Shaggy @ 14.02.13, 16:32

каких конструкторов? мы в деструкторе находимся

Деструкторов. Извините - опечатался.

Цитата Shaggy @ 14.02.13, 16:32

и каким образом изменится? запись в лог повлияет на состояние объекта что-ли?

Цитата Shaggy @ 14.02.13, 16:32

перекрыл виртуальный метод, посмотри в деструктор
по моему просто...

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

Delphi vs C++ vs C#

MyNameIsIgor — Thu, 14 Feb 2013 18:37:52 +0000

MyNameIsIgor:

Цитата Shaggy @ 14.02.13, 16:32

например добавляется указатель на сырые данные
которые надо перед удалением занулить

А зачем их занулять?