Ну вот вы упорный. И объясните, почему? и Какие альтернативы для гуи фреймоврка под Windows? Или вы считаете что если у меня приложение вин-специфичное, я должен изкорёживаться чтобы все под wine тестировать? Какой-то сильно вычурный способ разработки под винду, извините
Ну вот я перед тем как это инструкцию составить, попробовал install qt-base. сборка зафейлилась. я попробовал руками убрать pg-sql (который по неизвестной причине вылазит). Дальше порт упал на сборке чего-то из msys2. Короче... оно конечно прикольно, но явно не нубас френдли) сам я предпочитаю conan, с ним вообще всё гладенько.
Допишите про это в статью :) зря наверное упростили. Из благих побуждений с водой выплеснули дитя, видите, я тупой, чего-то важного от вас не уловил.
Теперь вопрос, а почему у вас реализация-то, m ,, а не mm? вы делаете эпл онли код. пимпл, все дела. хедер - C++ файл с методами.
Зачем сами методы писать НЕ С++ кодом, вот в чем мой вопрос? я как разработчик кроссплатформенной кодовой базы, хочу как можно меньше видеть специфичного кода. платформенного кода. objective-c кода. поэтому в mm файле я пишу обычные плюсовые методы и фигачу вызовы objective-c объектов (да, сами объекты из NextStep и прочих API можно разместить в pimpl).
разница только в том что инкапсулированный код так же пишется на С++ с objc вставками ,а не целиком файл на objc, вот и все
касаемо компиляции какой-то единицы в виде objc++ только под эппл я вообще в 1 комменте и написал. не про разделение файлов речь, а про использование С++ синтаксиса по максимуму. Зачем методы оформлять в этом одном mm файле у вас, вот что я в толк не возьму
Ладно, не буду уже по три раз повторять одну и ту же мысль, не донёс да не донёс.
код который написаный на С++ мог использовать Objective-C в macOS среде для определенного хєдера,
Я что-то не понял, и как он не может использовать?
ну так и мое предложение соответствует 1 и 2.
разница только в том что инкапсулированный код так же пишется на С++ с objc вставками ,а не целиком файл на objc, вот и все. и Pimpl я ровно так же предлагаю
Тут у меня явного ответа нету, скажу лишь что когда я хочу писать на С++ и использовать инструменты которые написаны на Objective-C последнее что я хочу видеть, это миграцию всего проекта на Objective-C++ и замена .cpp на .mm.
Ничего не понятно.
Вот есть проект, 1000 cpp файлов. на -x c++. добавляем 1001 файл, .mm или .cpp, не важно, -x objective-c++, либо весь проект собираем как objective-c++ и используем его фичи только в .mm не важно.
В общем, получаем 1001-й файл в котором у нас Objective-C++. ну и используем для него плюсовый хедер и эппловое Objective-C апи. все отлично. платоформо специфичные штуки живут в отдельном файле.
У нас в проекте используется чет около 40 фрейморков из Apple SDK, пока вообще не видел проблем с такой схемой.
При этом сам код в mm файлах имеет базовую структуру С++ кода, с плюшками objective-c только там где без вызова сигналов прям уже ваще никак. Так получаем код который могут сопровождать разработчики которые знают C++, а objc не очень. А ваше решение, ну не знаю. Если вы 1 его и поддерживаете, то вроде как и норм
Ну вот лично для меня не важно - работает ли компания на оборонку и только на неё, либо оборонка лишь один из нескольких заказчиков - в любом случае это сразу черный список.
Причем в древнем посте по ссылке как раз есть вещи из серии "нифига себе", а вот в этом посте (я в курсе что это перевод) вещи которые не то что программист, наверное каждый окончивший школу и не прогуливавший географию знает. Ну ладно, исключение про часовой сдвиг в 6 минут в Китае, который практически для разработчика бесполезен.
Это что за некропостинг такой, что теперь этот пост хабра на главной странице у меня показывается? я могу в любой 10 летний пост пойти коммент написать и пост будет в "горячем"?
А, ну просто прозвучало как-то слегка уничижительно, мол «много ли в 2022 используют new/delete» я уж думал это кошмарный ужас) так да, я понимаю что это zero overhead а не zero cost — нас cost устраивает.
да, уже писали про сайт 1кб с гугл аналитикой на нём :) у меня noscript вот в режиме «блокировать по дефолту», так все сайты на удивление быстро грузятся :D
Но много ли людей использует виртуальное наследование в 2022 году?
Ну вот в нашем проекте используется и повсеместно, для всех наследований от интерфейсов. (т.к. класс может реализовать несколько интерфейсов, не хочется включать несколько баз, когда эти интерфейсы имеют общего предка).
Да, и насколько я помню даже есть API для «легковесных» процессов (т.к. родные процессы Windows «тяжелее» своих аналогов из Unix). Про это даже статейка была несколько лет назад.
Я правда сам не ковырял но чет подозреваю что это документировано мягко говоря не очень. Т.к. эти все штуки не подразумеваются для использования Win32 разработчиками)
Ну вот вы упорный. И объясните, почему? и Какие альтернативы для гуи фреймоврка под Windows? Или вы считаете что если у меня приложение вин-специфичное, я должен изкорёживаться чтобы все под wine тестировать? Какой-то сильно вычурный способ разработки под винду, извините
Ну вот я перед тем как это инструкцию составить, попробовал install qt-base. сборка зафейлилась. я попробовал руками убрать pg-sql (который по неизвестной причине вылазит). Дальше порт упал на сборке чего-то из msys2. Короче... оно конечно прикольно, но явно не нубас френдли) сам я предпочитаю conan, с ним вообще всё гладенько.
тоже самое, "
list index out of range" и все тут.я попробовал сделать такой вот конфиг
И команда запуска выдает ошибку
Впервые слышу про aqtinstall . Подскажете как сделать такую же установку как в статье, через него?
Допишите про это в статью :) зря наверное упростили. Из благих побуждений с водой выплеснули дитя, видите, я тупой, чего-то важного от вас не уловил.
Теперь вопрос, а почему у вас реализация-то, m ,, а не mm? вы делаете эпл онли код. пимпл, все дела. хедер - C++ файл с методами.
Зачем сами методы писать НЕ С++ кодом, вот в чем мой вопрос? я как разработчик кроссплатформенной кодовой базы, хочу как можно меньше видеть специфичного кода. платформенного кода. objective-c кода. поэтому в mm файле я пишу обычные плюсовые методы и фигачу вызовы objective-c объектов (да, сами объекты из NextStep и прочих API можно разместить в pimpl).
разница только в том что инкапсулированный код так же пишется на С++ с objc вставками ,а не целиком файл на objc, вот и все
касаемо компиляции какой-то единицы в виде objc++ только под эппл я вообще в 1 комменте и написал. не про разделение файлов речь, а про использование С++ синтаксиса по максимуму. Зачем методы оформлять в этом одном mm файле у вас, вот что я в толк не возьму
Ладно, не буду уже по три раз повторять одну и ту же мысль, не донёс да не донёс.
Я что-то не понял, и как он не может использовать?
ну так и мое предложение соответствует 1 и 2.
разница только в том что инкапсулированный код так же пишется на С++ с objc вставками ,а не целиком файл на objc, вот и все. и Pimpl я ровно так же предлагаю
Ничего не понятно.
Вот есть проект, 1000 cpp файлов. на -x c++. добавляем 1001 файл, .mm или .cpp, не важно, -x objective-c++, либо весь проект собираем как objective-c++ и используем его фичи только в .mm не важно.
В общем, получаем 1001-й файл в котором у нас Objective-C++. ну и используем для него плюсовый хедер и эппловое Objective-C апи. все отлично. платоформо специфичные штуки живут в отдельном файле.
У нас в проекте используется чет около 40 фрейморков из Apple SDK, пока вообще не видел проблем с такой схемой.
При этом сам код в mm файлах имеет базовую структуру С++ кода, с плюшками objective-c только там где без вызова сигналов прям уже ваще никак.
Так получаем код который могут сопровождать разработчики которые знают C++, а objc не очень. А ваше решение, ну не знаю. Если вы 1 его и поддерживаете, то вроде как и норм
Ну вот лично для меня не важно - работает ли компания на оборонку и только на неё, либо оборонка лишь один из нескольких заказчиков - в любом случае это сразу черный список.
Причем в древнем посте по ссылке как раз есть вещи из серии "нифига себе", а вот в этом посте (я в курсе что это перевод) вещи которые не то что программист, наверное каждый окончивший школу и не прогуливавший географию знает. Ну ладно, исключение про часовой сдвиг в 6 минут в Китае, который практически для разработчика бесполезен.
Ну имхо стоило бы разработчикам хабра там поставить threshold комментария так на 3 хотя бы, чтобы от 1-2 комментов оно туда не попадало.
Это что за некропостинг такой, что теперь этот пост хабра на главной странице у меня показывается? я могу в любой 10 летний пост пойти коммент написать и пост будет в "горячем"?
Не уверен что это прям супер сильно вам помогло :)
Ну вот в нашем проекте используется и повсеместно, для всех наследований от интерфейсов. (т.к. класс может реализовать несколько интерфейсов, не хочется включать несколько баз, когда эти интерфейсы имеют общего предка).
А что плохого в виртуальном наследовании?
Я правда сам не ковырял но чет подозреваю что это документировано мягко говоря не очень. Т.к. эти все штуки не подразумеваются для использования Win32 разработчиками)