memscp — забавная опечатка. Вроде как «scp» — unix-утилита «secure copy» (связь защищена SSH), и в то же времям «mem» — не на другую машину, а из памяти в память, по зашифрованному туннелю :)
1. Контейнер — такой же сервис (используемый для получения сервисов). Поэтому его можно положить в контейнер, т.е. в себя же. Чем это хорошо? Ссылку на контейнер можно объявить dependency-свойством и тогда обращение к контейнеру не придётся делать через singleton, класс получит контейнер, как любой другой сервис.
2. DI-контейнер, который используется у нас (Microsoft Unity), позволяет строить дерево контейнеров. Child-контейнер можно отпочковать от Parent и переопределить лишь некоторые реализации. Как использовать? Например, контроллер от своего контейнера отпочковывает ветку, делает изменения (убирает/добавляет логгер, заменяет какие-то сервисы, настройки) и сервисы, порождённые в этой ветке, уже имеют свой Environment. Никаких статиков, глобальных конфигов и синглетонов.
Ах, я понял, почему так нельзя.
В с++ есть превосходный способ передать ссылку на класс-контейнер в конструктор члена, при этом базовый класс гарантировано построен:
Понятно. Метод, который не имеет доступа к полям, не очень полезен.
Но можно было бы поменять порядок инициализации. В c#, например, сначала инициализируются члены классов (в произвольном порядке), а потом вызываются конструкторы (от предка к потомку).
Интересно, почему компилятор заполняет vtable после вызова конструктора, а не до? Неужели ошибка дизайнера языка и последующее бремя совместимости?
В c#, например, кусок кода с классами B и C из статьи работает.
Да это и удобно, в конструкторе базового класса окна вызвать виртуальный GetTitle(), который определён в потомке, чтобы заполнить заголовок создаваемого окна.
«Не хочет никого подставлять», хех. человек в курсе, что в i2p есть преступные сообщества. рано или поздно его оборудование будет использовано для их коммуникации, вопрос времени. так что либо он не понимает, как работает i2p, либо врёт
насчёт адреса есть такое соображение:
оборудование может работать в режиме бриджа, и без экспертизы невозможно установить, где находится интерфейс с этим ip-адресом. так что логично по цепочке конфисковать всё оборудование, пока следы не стёрлись ))
насчёт адреса вообще не аргумент. у оборудования же есть владелец, он и несёт отвественность за него.
1. Контейнер — такой же сервис (используемый для получения сервисов). Поэтому его можно положить в контейнер, т.е. в себя же. Чем это хорошо? Ссылку на контейнер можно объявить dependency-свойством и тогда обращение к контейнеру не придётся делать через singleton, класс получит контейнер, как любой другой сервис.
2. DI-контейнер, который используется у нас (Microsoft Unity), позволяет строить дерево контейнеров. Child-контейнер можно отпочковать от Parent и переопределить лишь некоторые реализации. Как использовать? Например, контроллер от своего контейнера отпочковывает ветку, делает изменения (убирает/добавляет логгер, заменяет какие-то сервисы, настройки) и сервисы, порождённые в этой ветке, уже имеют свой Environment. Никаких статиков, глобальных конфигов и синглетонов.
Results
— tests: 1010
NAT present: 1
first preserved port: 1
preserves port: 0
type: Port restricted NAT
mapped ports: 62251 62251 62251 62251
RouterOS (Mikrotik RB433):
Results
— tests: 1010
NAT present: 1
first preserved port: 1
preserves port: 1
type: Port restricted NAT
mapped ports: 52219 52219 52219 52219
Наш областной ретранслятор заменяет некоторую рекламу на местную, не вручную же переключают.
забыл уже, когда последний раз кастил object к string или decimal ))
В с++ есть превосходный способ передать ссылку на класс-контейнер в конструктор члена, при этом базовый класс гарантировано построен:
Поэтому про члены нельзя сказать, что они ничего не знают о классе и их можно инициализировать в любом порядке до конструкторов.
Но можно было бы поменять порядок инициализации. В c#, например, сначала инициализируются члены классов (в произвольном порядке), а потом вызываются конструкторы (от предка к потомку).
В c#, например, кусок кода с классами B и C из статьи работает.
Да это и удобно, в конструкторе базового класса окна вызвать виртуальный GetTitle(), который определён в потомке, чтобы заполнить заголовок создаваемого окна.
diff так или иначе покажет изменения
насчёт адреса есть такое соображение:
оборудование может работать в режиме бриджа, и без экспертизы невозможно установить, где находится интерфейс с этим ip-адресом. так что логично по цепочке конфисковать всё оборудование, пока следы не стёрлись ))
насчёт адреса вообще не аргумент. у оборудования же есть владелец, он и несёт отвественность за него.