Если сервер будет падать на любую ошибку выделения памяти, значит через функцию malloc можно уничтожить такой сервер, подставив в параметр заведомо большое значение.
Это же рай для злоумышленника. Из UserMode можно уничтожить систему.
А если функция возвращает объект, который должен быть сохранён в дереве или графе, и используется в нескольких местах. Кто должен удалить объект? «Тот кто создал — тот и удаляет», то есть та самая функция CreateObject? Я даже не представляю какова должна быть сигнатура функции CreateObject, которая одновременно и возвращает объект, и применяется для удаления, вводя в заблуждение одним своим названием.
RSS это просто XML‐файл на диске, он не может масштабироваться по определению.
сервис должен выдерживать нагрузку около 1000 запросов в секунду! популярный сервис с 1 млн. подписчиков
Ваш вебсервер не может держать 1000 соединений — смените вебсервер.
Если на вас вебсервер зайдёт весь этот миллион подписчиков чтобы посмотреть страницу index.html, вы тоже обвините язык разметки гипертекста, что он не масштабируется?
Насколько я помню множественное наследование в С++ было разрешено
Двойное наследование — это когда от одного и того же интерфейса дважды наследуешься. В C++ это невозможно. Поэтому приходится переименовывать IUnknown, чтобы иметь две VTable с одинаковыми методами.
можно считать что вы согласились хотя бы с тем, что делегирование возможно?
В описанном вами варианте — нет. Вы пишете, что в QueryInterface можно возвращать какой хочу интерфейс, это не так. Вы можете возвращать только те интерфейсы, от которых унаследованы, а если хотите возвращать чужие интерфейсы, то вам необходимо создать агрегат, о чём в вашей статье не сказано.
Для того, чтобы работало агрегирование, необходимо:
Специальным образом создавать класс. Обратите внимание на параметр pUnkOuter у метода CreateInstance интерфейса IClassFactory. Ваш DirectShow поддерживает агрегацию?
Агрегация компонентов должна быть прозрачной для вызывающей стороны. Следовательно, агрегат должен предоставлять единый IUnknown интерфейс, при этом агрегированный компонент зависит от реализации внешнего компонента. В противном случае вызывающий увидел бы два разных IUnknown в одном и том же агрегате. Так как в C++ двойное наследование невозможно, то приходится придумывать пути с переименованием IUnknown в делегирующую и неделегирующую версию.
Как видно, для агрегации совершенно недостаточно возвращать интерфейс внутреннего объекта.
Эта ситуация до косточек разобрана в книге Дейла Роджерсона «Основы COM», глава 8 «Повторная применимость компонентов: включение и агрегирование».
он может, даже получить такой интерфейс из какой-то частной ДЛЛ-ки, но будет возвращать его как "часть себя" по сути
Не может. Иначе у вас нарушаются правила QueryInterface:
«Для любого экземпляра объекта вызов QueryInterface с IID_IUnknown всегда должен возвращать одно и то же значение физического указателя». То есть запросив IID_IUnknown из чужого интерфейса мы получим другой указатель, а надо — наш.
«Должен быть возможен успешный запрос для любого интерфейса в объекте из любого другого интерфейса». Если мы из IFoo получили IBar, то должна быть верна и обратная операция: из IBar мы также должны получить IFoo. Из чужого объекта мы не можем получить себя, потому что чужой объект ничего про нас не знает.
А почему я не имею права назвать запрос интерфейса делегированием?
Да, не имеете права. Через QueryInterface вы можете возвращать только те интерфейсы, которые сами реализуете. Следовательно, делегация самих себя не может быть по определению.
Я правильно понимаю, что так называемый цифровой рубль — это всего лишь банковский счёт, открытый в центральном банке? Казалось бы, такая простая операция как открытие счёта, но для которой понадобилось менять федеральное законодательство.
Это когнитивное искажение, и называется оно «Вера в справедливый мир». Вера в то, что мир устроен справедливо и люди в жизни получают то, что заслуживают в соответствии со своими личными качествами и поступками: хорошие люди награждаются, а плохие — наказываются.
Можно, конечно, передать параметрами, но параметров таких может оказаться неоправданно много.
Замыкаемые переменные тоже надо указывать, поэтому выигрыш тут может быть только в том, что не нужно указывать типы данных.
Но это довольно сомнительное преимущество. Потому что экономя на осмысленном названии функции из нескольких символов получаем необходимость зубрить N страниц стандарта со всякими std::function, шаблонами, подводными камнями и нюансами применения.
Я очень надеюсь, что вы с пользой потратили эти сэкономленные 100 миллисекунд?
Выделение памяти разного размера бывает. Например, под буфер 500 мегабайт памяти может не быть, а под объект в 10 килобайт будет.
Или сейчас памяти недостаточно, а потом один из клиентов отключился, память освободилась — и теперь памяти стало хватать.
Неправильно думать что однажды получив ошибку выделения памяти мы будем получать её всегда. Не хватает памяти — это преходящее явление.
Если сервер будет падать на любую ошибку выделения памяти, значит через функцию malloc можно уничтожить такой сервер, подставив в параметр заведомо большое значение.
Это же рай для злоумышленника. Из UserMode можно уничтожить систему.
Не может для новых клиентов, а для старых память уже выделена, и клиенты работают.
Сервер как минимум продолжает обслуживать текущих клиентов. Это полезно.
Нет, упасть — это очень плохая идея. Сервер не должен падать под нагрузкой.
Это приведёт к созданию другого объекта, а не оригинального. И если кто‐то, держащий ссылку на оригинал, изменит его, это не отразится на копии.
А если функция возвращает объект, который должен быть сохранён в дереве или графе, и используется в нескольких местах. Кто должен удалить объект? «Тот кто создал — тот и удаляет», то есть та самая функция CreateObject? Я даже не представляю какова должна быть сигнатура функции CreateObject, которая одновременно и возвращает объект, и применяется для удаления, вводя в заблуждение одним своим названием.
Конечно пропитаются. Макароны мягкие становятся от того, что в них вода попадает.
RSS это просто XML‐файл на диске, он не может масштабироваться по определению.
Ваш вебсервер не может держать 1000 соединений — смените вебсервер.
Если на вас вебсервер зайдёт весь этот миллион подписчиков чтобы посмотреть страницу index.html, вы тоже обвините язык разметки гипертекста, что он не масштабируется?
Вы меня простите, но зачем в каждый заголовок добавлять визуальный мусор из символа «▍»?
Двойное наследование — это когда от одного и того же интерфейса дважды наследуешься. В C++ это невозможно. Поэтому приходится переименовывать
IUnknown, чтобы иметь две VTable с одинаковыми методами.В описанном вами варианте — нет. Вы пишете, что в
QueryInterfaceможно возвращать какой хочу интерфейс, это не так. Вы можете возвращать только те интерфейсы, от которых унаследованы, а если хотите возвращать чужие интерфейсы, то вам необходимо создать агрегат, о чём в вашей статье не сказано.Для того, чтобы работало агрегирование, необходимо:
Специальным образом создавать класс. Обратите внимание на параметр
pUnkOuterу методаCreateInstanceинтерфейсаIClassFactory. Ваш DirectShow поддерживает агрегацию?Агрегация компонентов должна быть прозрачной для вызывающей стороны. Следовательно, агрегат должен предоставлять единый
IUnknownинтерфейс, при этом агрегированный компонент зависит от реализации внешнего компонента. В противном случае вызывающий увидел бы два разныхIUnknownв одном и том же агрегате. Так как в C++ двойное наследование невозможно, то приходится придумывать пути с переименованиемIUnknownв делегирующую и неделегирующую версию.Как видно, для агрегации совершенно недостаточно возвращать интерфейс внутреннего объекта.
Эта ситуация до косточек разобрана в книге Дейла Роджерсона «Основы COM», глава 8 «Повторная применимость компонентов: включение и агрегирование».
Не может. Иначе у вас нарушаются правила QueryInterface:
«Для любого экземпляра объекта вызов QueryInterface с IID_IUnknown всегда должен возвращать одно и то же значение физического указателя». То есть запросив IID_IUnknown из чужого интерфейса мы получим другой указатель, а надо — наш.
«Должен быть возможен успешный запрос для любого интерфейса в объекте из любого другого интерфейса». Если мы из IFoo получили IBar, то должна быть верна и обратная операция: из IBar мы также должны получить IFoo. Из чужого объекта мы не можем получить себя, потому что чужой объект ничего про нас не знает.
Правила реализации QueryInterface
Именно поэтому вы можете возвращать только те интерфейсы, которые реализуете. А возвращать самого себя — это никакая не делегация.
Да, не имеете права. Через QueryInterface вы можете возвращать только те интерфейсы, которые сами реализуете. Следовательно, делегация самих себя не может быть по определению.
Откуда такие сведения?
Я правильно понимаю, что так называемый цифровой рубль — это всего лишь банковский счёт, открытый в центральном банке?
Казалось бы, такая простая операция как открытие счёта, но для которой понадобилось менять федеральное законодательство.
Это когнитивное искажение, и называется оно «Вера в справедливый мир». Вера в то, что мир устроен справедливо и люди в жизни получают то, что заслуживают в соответствии со своими личными качествами и поступками: хорошие люди награждаются, а плохие — наказываются.
await разве не ждёт результата?
Замыкаемые переменные тоже надо указывать, поэтому выигрыш тут может быть только в том, что не нужно указывать типы данных.
Но это довольно сомнительное преимущество. Потому что экономя на осмысленном названии функции из нескольких символов получаем необходимость зубрить N страниц стандарта со всякими std::function, шаблонами, подводными камнями и нюансами применения.