Все эти пункты, тот кто использует API должен сам проверять
Тогда зачем нужна ваша "обертка" если она ничего не делает?
Если вы уж так хотите защиту от дурака, просто добавляет пару if
Ну так добавьте и потом уже сравнивайте эквивалентный код
А если вдруг false, то достаточно вызвать GetLastError
Для этого люди и пишут обертки, чтобы скрыть от клиентского кода детали реализации.
Дальше, как вы собрались проверять адрес куда записывать
Лично я бы делал семантические типы вроде Process и ProcessMemory, которые оборачивали бы хэндлеры и поинтеры вместо порнографии с HANDLE hProcess, LPVOID address Потому что HANDLE может быть от чего угодно, а нам нужен именно от процесса.
И в теории при спец. задачах, по нему можно записать и считать
Нет таких задач, вы не можете в вин-апи писать в память процесса по nullptr и из nullptr.
Ну разве что кол-во данных.. будет странно что оно равно нулю
А что начет количества данных меньше передаваемого размера? Авось не случится, да?
НАША API НЕ ДОЛЖНА СВЯЗЫВАТЬ РУКИ
Ваше апи должна делать хоть что-то полезное, например вносить сематинтику и позволять избегать ошибок при использовании, иначе это не апи и враппер, а в лучше случае превдоним для вин-апи функции, а в худшем просто мусор.
Не нужно из-за своего скудомия
Скудоумие это не понимание разницы между оберткой и алиасом, не понимание что такое защищеное программирование, не понимание как выразить семантику программы в коде, не понимание какие проблемы могут быть при работе с прямыми указателями и как их избегать и не понимание чем С отличается от С++(ваш код это чистый С).
Но особенным скудоумием является невозможность осознать свою ошибку даже после того как несколько человек вам все разжевали с примерами кода и подробными объяснениями.
Ничего он не решает, это трейд-офф между ценной и качеством, как и все такие решения. У qt свой рендер стек, а значит можете забыть про нативный UI, про плавную инерционную прокрутку, про быстрый отклик на кастомных жестах и т.д. Scoped Storage, runtime permissions, bluetooth, камера в специфических сценариях, новые фичи Android/iOS, ARKit, расширенные возможности клавиатуры - все это принесет вам кучу головной боли и в конце концов вы все равно обнаружите себя пишущим JNI/Objective-C код для решения проблемы.
Так вот код раста это проверяет, там не просто так Result и знак вопроса после вызова, а ваш код нет. Вы напишите на С++ полноценную обертку, с обработкой ошибок, с гарантией осмысленного результата, с гарантией что в api не передаётся nullptr или буфер размера меньше чем size, что буфер точно не деаллоцирован в момент передачи и точно инициализирован и так, чтобы на уровне компилятора все это проверялась, как это происходит в вашем же примере на раст. А потом уже сравним код.
Код на расте это безопасная обертка над апи, к примеру гарантирующая согласованость передаваемые данных и размера. Ваш код на С(а это не С++) это просто прокси, который прокидывает все как есть, оставляя все проблемы вышестоящему коду, включая обработку ошибок.
Так в этом и проблема, что есть платформы под которые llvm не собирает бинари, какой-нибудь специфичный микроконтроллер. Теперь в таких случаях можно писать на расте, транслировать в С и дальше собирать С-компилятором.
Никто ничего не забыл. Согласно GWI ноутбук или десктоп хотя бы иногда используют только 60% пользователей интернета. Так что выбрав десктоп приложение вместо веба вы сужаете свою потенциальную клиентскую базу в 1.5 раза. Не говоря уже о том, что в случае веб-приложения вам нужна одна команда и одно приложение, а под десктоп придется делать разные версии под каждую платформу. В большинстве случае подобные экономические потери никак не оправданы.
Причём тут язык если все время уходит на llvm? И причём тут Free Pascal? Тут уж надо сравнивать с С++ с большим количеством вычислений на шаблонах
Тогда зачем нужна ваша "обертка" если она ничего не делает?
Ну так добавьте и потом уже сравнивайте эквивалентный код
Для этого люди и пишут обертки, чтобы скрыть от клиентского кода детали реализации.
Лично я бы делал семантические типы вроде Process и ProcessMemory, которые оборачивали бы хэндлеры и поинтеры вместо порнографии с
HANDLE hProcess, LPVOID addressПотому чтоHANDLEможет быть от чего угодно, а нам нужен именно от процесса.Нет таких задач, вы не можете в вин-апи писать в память процесса по nullptr и из nullptr.
А что начет количества данных меньше передаваемого размера? Авось не случится, да?
Ваше апи должна делать хоть что-то полезное, например вносить сематинтику и позволять избегать ошибок при использовании, иначе это не апи и враппер, а в лучше случае превдоним для вин-апи функции, а в худшем просто мусор.
Скудоумие это не понимание разницы между оберткой и алиасом, не понимание что такое защищеное программирование, не понимание как выразить семантику программы в коде, не понимание какие проблемы могут быть при работе с прямыми указателями и как их избегать и не понимание чем С отличается от С++(ваш код это чистый С).
Но особенным скудоумием является невозможность осознать свою ошибку даже после того как несколько человек вам все разжевали с примерами кода и подробными объяснениями.
но они при этом производят реальные новые продукты, в отличии от яндекса.
С чего вдруг то - crustc создает исходники на С, вы можете их комплировать любым существующим С компилятором.
В яндексе может и не слышали, а в бигтех компаниях не просто так создаются свои новые языки.
Она и на С++ будет выглядеть примерно как на расте, если написать эквивалентной по функционалу.
Ничего он не решает, это трейд-офф между ценной и качеством, как и все такие решения. У qt свой рендер стек, а значит можете забыть про нативный UI, про плавную инерционную прокрутку, про быстрый отклик на кастомных жестах и т.д. Scoped Storage, runtime permissions, bluetooth, камера в специфических сценариях, новые фичи Android/iOS, ARKit, расширенные возможности клавиатуры - все это принесет вам кучу головной боли и в конце концов вы все равно обнаружите себя пишущим JNI/Objective-C код для решения проблемы.
Так вот код раста это проверяет, там не просто так Result и знак вопроса после вызова, а ваш код нет. Вы напишите на С++ полноценную обертку, с обработкой ошибок, с гарантией осмысленного результата, с гарантией что в api не передаётся nullptr или буфер размера меньше чем size, что буфер точно не деаллоцирован в момент передачи и точно инициализирован и так, чтобы на уровне компилятора все это проверялась, как это происходит в вашем же примере на раст. А потом уже сравним код.
А ещё много плохого. Вопрос наличия альтернатив - то, что в СССР много людей ездело на запорожце не делает его хорошим автомобилем.
Код на расте это безопасная обертка над апи, к примеру гарантирующая согласованость передаваемые данных и размера. Ваш код на С(а это не С++) это просто прокси, который прокидывает все как есть, оставляя все проблемы вышестоящему коду, включая обработку ошибок.
Если вам нужен стриминг данных, то самое подходящее это веб-сокеты, нет?
Так в этом и проблема, что есть платформы под которые llvm не собирает бинари, какой-нибудь специфичный микроконтроллер. Теперь в таких случаях можно писать на расте, транслировать в С и дальше собирать С-компилятором.
В чем троллинг, в том что теперь на расте можно писать еще под более широкий класс устройств(по сути любое где есть компилятор с89)?
Никто ничего не забыл. Согласно GWI ноутбук или десктоп хотя бы иногда используют только 60% пользователей интернета. Так что выбрав десктоп приложение вместо веба вы сужаете свою потенциальную клиентскую базу в 1.5 раза. Не говоря уже о том, что в случае веб-приложения вам нужна одна команда и одно приложение, а под десктоп придется делать разные версии под каждую платформу. В большинстве случае подобные экономические потери никак не оправданы.
С ростом веба и мобильных платформ
конечно не денется - будете получать лицензию разработчика на свои документы.
Да, конечно, под айфон же не существует разработки. Будут получать доступ через аккаунт разработчика с kyc процедурой.
Если его сравнивать с egui, в чем отличие?
речь про 700к рублей. Казна пустеет, милорд(с)
Не знаю что у вас там, но судя по "goto-driven state loops" код действительно специфичный.