Как альтернативу dns Resolver в k8s можно использовать kuberesolver как легковесное решение без дополнительных sidecar-ов при использование Istio с xDS
Отличная статья! В реализации от gRPC updateSubConnState записывается в опцию при создания sc, в вашей же реализации функция являться частью интерфейса Balancer, не знаете с чем связано это изменение? Так же вопрос, для каких целей может понадобиться свой Balancer отличающийся от base.Balancer, в ум приходят лишь ситуации когда требуется передать Picker что-либо кроме connectivity.Ready SubConn? Возможно стоит добавить в статью описание стейтов из connectivity, чтобы вся эта Стейт машина, которую прийдется реализовывать в своем Balancer, была более понятной :)
Наверное у меня работает наоборот, я это все намудрил потому что хочу видеть Objective-C API исключительно в свойственной для него среде (Objective-C). И использовать Objective-C++ чисто как адаптер между Objective-C и C++.
Да и скорее всего когда человек отркывает .m файл он наверное ожидает видеть там Objective-C код а не Си с вызовами Objective-C API (Тоже самое и с Objective-C++ и С++).
Реальной кодовой базы с примерами подобных патеров у меня нету, по этому это исключительно мое собственное мнение и видиние
Я кажется вас понял :), это я для примера все в один mm засунул, в реальности есть еще хедер в котором интерфейс уже (Objective-C) класса, и .m файл с implementation
Давайте разберемся, может я вас не правильно понял. У меня есть хэдер файл который должен печатать строчку следующим образом: 1) Для Linux должна быть реализация которая вызывает std::cout 2)Для MacOS соответственно NSLog 3)Реализация должна хранить в себе поле (std::string, NSString соответсвенно)
Этот хедер вызывается из с++ кода (который должен работать и на Linux и на macOS)
Ограничения: Linux абсолютно не может компилировать Objective-C/Objective-C++ код Никаких #ifdef APPLE, все решается на этапе сборки (Как в файле ниже, не важно Make, CMake) Makefile:
Опять таки, ваше решение не подходит для поставленной мною задачи: Мне нужно чтоб код который написаный на С++ мог использовать Objective-C в macOS среде для определенного хєдера, и c++ в Linux среде (Там где нету доступа к Objective-C и AppleSDK) для того же хєдера. Если я перепишу весь проект на .mm файлы он не соберется на линуксе.
Так получаем код который могут сопровождать разработчики которые знают C++, а objc не очень
Мне наоборот кажется что мое решение очень хорошо разграничивает C++ и Objective-C, так как: 1) Objective-C имплементация полностью инкапсулирована PIMPL-ом 2) Это код который может собирается отдельным обьектником (библиотекой если там много файлов)
Я имею ввиду что в системе которой нету Objective-C ваша программа не скомпилируется: ```gcc: fatal error: cannot execute ‘cc1obj```, а моя (если я ей скажу) чтобы вместо .mm для macOS, я использовал какой-то другой .cpp, для одного и того же хедера - скомпилируется.
Только если использовать 2 разных main для Linux (main.cpp и другой принтер .cpp) для macOS (main.mm и принтер .mm)
К вашему примеру и не придерешься, но все таки тут немного другая суть, из-за ARC получается что мы используем С++ в Objective-C, а у меня стояла задача именно Objective-C в С++. Что я конкретно имею ввиду: Если у меня сборка под macOS, я нахожу компилятор objective-C и линкую Objective-C обьектник, если же под Линукс (к примеру) то я даже не думаю про Objective-C, а просто забиваю на компиляцию данного обьектника и использую какой-то другой. В вашем же примере мне и под MacOS и под Linux, стоит иметь Objective-C, да и проект становится написанным на Objective-C а не на С++ по факту. Но ваш пример определенно красивый.
Хех, а с шаблонной магией и forwarding ссылками вообще красота). Мне кажется что любая статья где хоть как-то участвует с++, сводится к какому-то недопониманию и непринятию :), в том числе это и тема оптимизации. Эх **неуверено говорит** раньше было лучше (и добавляет флаг std=c++20) :)
Практическое применение второго конструктора с rvalue, все же есть, но наверное оно больше для того чтобы показать что вызывающая сторона больше не владеет обьектом. В класических примерах я бы все таки рассчитывал на оптимизации (такие как Copy elision).
А что если я на вход передам lvalue и эта строка будет потом использоваться в других объектах и классах (везде ее перемещать?), напоминаю, перемещение Не бесплатно.
Спасибо за развернутый комментарий! На счет С++, я с вами согласен, но частично. Углубляться в тему ссылок и перемещения можно вечно и дискуссия не потухнет еще долго, оставлю лишь ссылку на отличный материал по этой теме http://scrutator.me/post/2018/07/30/value_vs_reference.aspx (тут каждый делает выводы сам, очевидного ответа там нету). На счет интерфейса класса я с вами согласен, что было б правильней передавать аргумент сообщения напрямую в Print, но я хотел свести все к "финальной версии", где у нас должно существовать именно поле которое является обьектом Objective-C и функции которые должны взаимодействовать с этим полем, по этому пример и не совсем правильный по дизайну.
На счет, управлением памяти, вы действительно правы и ваше предложение с retain действительно имеет место быть. Но указателем на PrinterImpl, теоретически владеть кто-то еще может, но фактически он под unique_ptr, что означает если ты достаешь от туда сырой указатель unique_ptr::get() то ты получишь "не владеющий" указатель, unique_ptr для того и создан чтобы не было двух владеющих указателей на один участок памяти. Среду с автоматическим подсчетом ссылок я действительно не брал в расчет, так как подразумевал что С++ классы будут вызываться и использоваться только в среде С++, когда я писал статью я не рассматривал что другой Objective-C++ код будет их использовать.
Смотря что вы имеете ввиду под проблемами. Использовать С++ код в Objective-C можно без проблем, это будет, как вы и написали, Objective-C++. А если стоит задача использовать Objective-C++ в существующем C++ коде, то тогда уже появляются проблемы описание в статье.
Как альтернативу dns Resolver в k8s можно использовать kuberesolver как легковесное решение без дополнительных sidecar-ов при использование Istio с xDS
Отличная статья! В реализации от gRPC updateSubConnState записывается в опцию при создания sc, в вашей же реализации функция являться частью интерфейса Balancer, не знаете с чем связано это изменение? Так же вопрос, для каких целей может понадобиться свой Balancer отличающийся от base.Balancer, в ум приходят лишь ситуации когда требуется передать Picker что-либо кроме connectivity.Ready SubConn? Возможно стоит добавить в статью описание стейтов из connectivity, чтобы вся эта Стейт машина, которую прийдется реализовывать в своем Balancer, была более понятной :)
Это хороший вопрос, на него у меня ответа нету :)
Наверное у меня работает наоборот, я это все намудрил потому что хочу видеть Objective-C API исключительно в свойственной для него среде (Objective-C). И использовать Objective-C++ чисто как адаптер между Objective-C и C++.
Да и скорее всего когда человек отркывает .m файл он наверное ожидает видеть там Objective-C код а не Си с вызовами Objective-C API (Тоже самое и с Objective-C++ и С++).
Реальной кодовой базы с примерами подобных патеров у меня нету, по этому это исключительно мое собственное мнение и видиние
Я кажется вас понял :), это я для примера все в один mm засунул, в реальности есть еще хедер в котором интерфейс уже (Objective-C) класса, и .m файл с implementation
Давайте разберемся, может я вас не правильно понял. У меня есть хэдер файл который должен печатать строчку следующим образом:
1) Для Linux должна быть реализация которая вызывает std::cout
2)Для MacOS соответственно NSLog
3)Реализация должна хранить в себе поле (std::string, NSString соответсвенно)
Этот хедер вызывается из с++ кода (который должен работать и на Linux и на macOS)
Ограничения:
Linux абсолютно не может компилировать Objective-C/Objective-C++ код
Никаких #ifdef APPLE, все решается на этапе сборки (Как в файле ниже, не важно Make, CMake)
Makefile:
Как ваш код решит такую проблему ? (как по мне достаточно классическая проблема для кросплатформенного кода который использует Apple SDK)
Опять таки, ваше решение не подходит для поставленной мною задачи: Мне нужно чтоб код который написаный на С++ мог использовать Objective-C в macOS среде для определенного хєдера, и c++ в Linux среде (Там где нету доступа к Objective-C и AppleSDK) для того же хєдера. Если я перепишу весь проект на .mm файлы он не соберется на линуксе.
Мне наоборот кажется что мое решение очень хорошо разграничивает C++ и Objective-C, так как:
1) Objective-C имплементация полностью инкапсулирована PIMPL-ом
2) Это код который может собирается отдельным обьектником (библиотекой если там много файлов)
Я имею ввиду что в системе которой нету Objective-C ваша программа не скомпилируется: ```gcc: fatal error: cannot execute ‘cc1obj```, а моя (если я ей скажу) чтобы вместо .mm для macOS, я использовал какой-то другой .cpp, для одного и того же хедера - скомпилируется.
Только если использовать 2 разных main для Linux (main.cpp и другой принтер .cpp) для macOS (main.mm и принтер .mm)
К вашему примеру и не придерешься, но все таки тут немного другая суть, из-за ARC получается что мы используем С++ в Objective-C, а у меня стояла задача именно Objective-C в С++. Что я конкретно имею ввиду: Если у меня сборка под macOS, я нахожу компилятор objective-C и линкую Objective-C обьектник, если же под Линукс (к примеру) то я даже не думаю про Objective-C, а просто забиваю на компиляцию данного обьектника и использую какой-то другой. В вашем же примере мне и под MacOS и под Linux, стоит иметь Objective-C, да и проект становится написанным на Objective-C а не на С++ по факту.
Но ваш пример определенно красивый.
Хех, а с шаблонной магией и forwarding ссылками вообще красота). Мне кажется что любая статья где хоть как-то участвует с++, сводится к какому-то недопониманию и непринятию :), в том числе это и тема оптимизации. Эх **неуверено говорит** раньше было лучше (и добавляет флаг std=c++20) :)
Спасибо, да, примерно так я себе и представлял класс, после того как начал изучать вопрос по вашим референсам.
Практическое применение второго конструктора с rvalue, все же есть, но наверное оно больше для того чтобы показать что вызывающая сторона больше не владеет обьектом. В класических примерах я бы все таки рассчитывал на оптимизации (такие как Copy elision).
Спасибо за источники (будут обязательные к прочтению :) ), ваше замечание с release абсолютно коректно
А что если я на вход передам lvalue и эта строка будет потом использоваться в других объектах и классах (везде ее перемещать?), напоминаю, перемещение Не бесплатно.
ARC - нет
Спасибо за развернутый комментарий! На счет С++, я с вами согласен, но частично. Углубляться в тему ссылок и перемещения можно вечно и дискуссия не потухнет еще долго, оставлю лишь ссылку на отличный материал по этой теме http://scrutator.me/post/2018/07/30/value_vs_reference.aspx (тут каждый делает выводы сам, очевидного ответа там нету).
На счет интерфейса класса я с вами согласен, что было б правильней передавать аргумент сообщения напрямую в
Print, но я хотел свести все к "финальной версии", где у нас должно существовать именно поле которое является обьектом Objective-C и функции которые должны взаимодействовать с этим полем, по этому пример и не совсем правильный по дизайну.На счет, управлением памяти, вы действительно правы и ваше предложение с retain действительно имеет место быть. Но указателем на
PrinterImpl, теоретически владеть кто-то еще может, но фактически он подunique_ptr, что означает если ты достаешь от туда сырой указательunique_ptr::get()то ты получишь "не владеющий" указатель,unique_ptrдля того и создан чтобы не было двух владеющих указателей на один участок памяти.Среду с автоматическим подсчетом ссылок я действительно не брал в расчет, так как подразумевал что С++ классы будут вызываться и использоваться только в среде С++, когда я писал статью я не рассматривал что другой Objective-C++ код будет их использовать.
Смотря что вы имеете ввиду под проблемами. Использовать С++ код в Objective-C можно без проблем, это будет, как вы и написали, Objective-C++. А если стоит задача использовать Objective-C++ в существующем C++ коде, то тогда уже появляются проблемы описание в статье.