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

S>Претензии к Wikipedia. Почему я привел ссылку на Wikipedia я уже объяснял, перечитайте если до вас не дошло.

я уже понял, что у тебя wishfull thinking в отношении википедии

S>Вы ввязались в разговор о парадигмах. В частности о том, что именно подразумевается под полиморфизмом в объектно-ориентированной парадигме. a7d3 не верит, что в классическом
я ввязался в разговор о late binding, потому что этот термин употреблён не к месту, и тот же кей говорил об "extreme late binding", а именно о диспетчеризации по имени в рантайме, потому что смоллток — только единственная правильная имплементация ООП, а Кей — пророк его (по мнению Кея)

>ООП есть только динамический полиморфизм. Тогда как в классическом ООП именно динамический полиморфизим, реализуемый посредством позднего связывания (late binding). Подтвержения этому и приводились, в том числе и цитатами из Кея, Мейера и Буча.

наша песня хороша, начинай с начала

S>То, что вы слишком молоды и для вас late binding -- это нечто тесно завязанная на COM и DLL штука можно понять. Но это не мои проблемы.

тогда, старпёр, это твои проблемы, т.к. уже выросло поколение, которое понимает late binding именно так, как его понимаю я:

https://stackoverflow.com/questions/484214/early-and-late-binding/484247#484247
https://softwareengineering.stackexchange.com/questions/301919/object-oriented-late-binding

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

S>>Претензии к Wikipedia. Почему я привел ссылку на Wikipedia я уже объяснял, перечитайте если до вас не дошло.

МГ>я уже понял, что у тебя wishfull thinking в отношении википедии

Еще раз: Wikipedia была приведена как легкодоступный источник, в котором говорится про взаимосвязь динамический полиморфизм и late binding.

S>>То, что вы слишком молоды и для вас late binding -- это нечто тесно завязанная на COM и DLL штука можно понять. Но это не мои проблемы.

МГ>тогда, старпёр, это твои проблемы, т.к. уже выросло поколение, которое понимает late binding именно так, как его понимаю я:

Да, этого я не учел.

МГ>https://stackoverflow.com/questions/484214/early-and-late-binding/484247#484247

Нетрудно увидеть, что обсуждаемое для C# деление на early binding и late binding не походит к C++.
Кроме того, в Интернете есть и другие взгляды на late binding в C# (эта ссылка так же уже была в обсуждении ранее): https://www.c-sharpcorner.com/article/concept-of-polymorphism-late-binding-in-c-sharp/

Compile Time Binding and 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.

Выделение курсивом мое.

МГ>https://softwareengineering.stackexchange.com/questions/301919/object-oriented-late-binding

Эта ссылка чем-то лучше ссылок на Wikipedia?

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

МГ>в твоей же ссылке на википедию первой же строкой написано:
>>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 итд

Это на каждый чих что ли по холдеру? Стандартные смартпоинтеры как раз избавят тебя от размножения сущностей.

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

Ops>Это на каждый чих что ли по холдеру? Стандартные смартпоинтеры как раз избавят тебя от размножения сущностей.

Как? И причём тут поинтеры, если нам нужна стековая сущность, держащая DC?

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

C0x>То есть тебе не кажется странным использовать объект с именем unique_ptr для совершенно другой цели — выполнить логику удаления? Это я и называю костылями — использования не по назначению типов. Что касается врапперов над хэндлами все ок,пока логика — просто удалить хэндл, а если чуть сложнее то уже придется городить ещё кучу объектов непонятного назначения.

Так проблема в названии класса? Ну сделай алиас и используй его.

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

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

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


подсказываю KISS подход к работе с ресурсами — заворачиваешь каждый ресурс требующий удалять его в деструкторе в unique_ptr и не пишешь больше деструкторы, т.к. компилятор будет генерировать деструкторы за тебя, про HANDLE компилятор ничего не знает, это сущность, время жизни которой в коде не выражена явно, а куча неявных assumptions в коде усложняет его

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


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

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

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

отвратительно!

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

TB>Как? И причём тут поинтеры, если нам нужна стековая сущность, держащая DC?

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

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

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

TB>>Как? И причём тут поинтеры, если нам нужна стековая сущность, держащая DC?

Ops>Так смартпоинтеры — это только название такое, они могут что угодно держать.

Название кривое.
По поводу сущностей — какая разница они один фиг создают новый тип с соотвествющим деструктором. И разве не короче написать

struct T {
  #NOCOPY
  HDC dc;
  T(HDC dc): dc(dc) {}
  ~T() { ReleaseDC(dc);}
}

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

M>>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.

AN>Какая идея хорошая для обработки ошибок в конструкторе?

Есть такая книжка хорошая, только не помню как называется, что-то типа "С++ для профессионалов", что-то то там про количество советов было в названии.
Конструктор не должен бросать исключений принципиально. Можно статическую функцию-конструктор запилить, которая конструирует объект и кидает исключение, если что не так, освобождая ресурсы. Любо. Но тут мы выходим в анлайк ТС. Он не хочет никакие Опены и Клоузы. Так что это не тема для разговора. "Надо, Федя, надо!" (с)

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

TB>Название кривое.

Что выросло — то выросло. Странно, что все не привыкли.

TB>По поводу сущностей — какая разница они один фиг создают новый тип с соотвествющим деструктором. И разве не короче написать

TB>

TB>struct T {
TB>  #NOCOPY
TB>  HDC dc;
TB>  T(HDC dc): dc(dc) {}
TB>  ~T() { ReleaseDC(dc);}
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>Вызов деструктора в конструкторе это нормально?

Какой ещё вызов деструктора в конструкторе ?
Как можно вызвать деструктор для объекта, который не смог быть сконструированным ?

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


M>>Вызов деструктора в конструкторе это нормально?

_NN>Какой ещё вызов деструктора в конструкторе ?
_NN>Как можно вызвать деструктор для объекта, который не смог быть сконструированным ?

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

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

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

M>>>Вызов деструктора в конструкторе это нормально?

_NN>>Какой ещё вызов деструктора в конструкторе ?
_NN>>Как можно вызвать деструктор для объекта, который не смог быть сконструированным ?

M>про это и речь. Если конструктор не смог отработать, какие освобождения ресурсов в деструкторе, которые ещё и конструктор должен вызывать. Ты меня сиплюсплюсника с двадцатилетним стажем не путай, плиз. Тут же ещё new с выделением на стеке нужно не путать.

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

P.S.
Мерятся стажем не имеет смысла, я встречал достаточно людей со стажем 10-ти лет и не знающими что такое исключения.
Если что у меня тоже двадцать лет стажа =0