В простых случаях это отлично работает. Но признаться я сдался, когда потребовалось асинхронно пушить сообщения от сервера одному или нескольким из N клиентов. Не хотите такой случай тестами покрыть? :)
Ничего личного, но "dotnet ef migrations add XXX" и "dotnet ef database update" делают вроде тоже самое, но работают из коробки и кажутся мне проще.
Про угадывание субд тоже не понял, что имеется в виду
А поменяйте в вашем примере в настройках Postgres на какой-нибудь T-SQL ;) В dotnet всё, что придётся сделать, это поменять пакет. Код править не придётся. В Spring, насколько я помню, я должен знать, у кого там в sql update на самом деле upsert, а у кого merge, или как получить автоинкрементированный номер только что вставленой записи.
Ну или попробуйте поддерживать пару разных разных СУБД в одном проекте со всеми этими миграциями.
Литералы тут не у дел, в одном файле можно смешать хоть все 4 типа (про LE/BE в UTF-16/32 промолчу). Никакой BOM тут не поможет. Более того, стандарт С++23 раздел 5.2.1 требует распознавания файлов UTF-8 независимо от их содержания, а 5.2.2 впридачу игнорировать BOM с порядком байтов в юникоде.
Юникод в идентификаторах поддерживается, раздел 5.10
К сожалению я не внимательно слежу за развитием С++ в последние годы, но приведите пожалуйста ссылку на стандарт где написано, что исходный текст С++ перестал быть ASCII и стал каким-то юникодом.
Уже упомянутый драйвер печати в PDF умеет не только делить документы на страницы, но и страницы на части. Чтоб, например, разделить страницу на две волне достаточно. Если ещё и с полями поиграться, то можно разбить страницу на несколько документов, один и будет нужным прямоугольником.
Из преимуществ в результате получаем настоящий PDF, а не картинку. Плюс можно наглядно объяснить шефу, как можно заработать больше денег если не жаться на лицензию для нормального продукта :)
Трогательно. Но Qt худо-бедно поддерживает не только MS, но и Linux, и вроде даже Mac. Там у Вас тоже с++ версии для них есть? И это только десктоп, а сегодня всем подавай мобайл. Андроид, Эппл там.
И всё это покрывают Web приложения безо всяких хлопот с нынешними и будущими версиями, и эффективность бекенда уже не так и волнует. Это про бизнес
Впрочем, если Вы работаете по цене электричества, так KDE под BSD, вроде так толком до сих пор и не портировали :)))
Ой как интересно, расскажите поподробнее. Я как раз такие штуки программирую. Взамен пообещаю выложить для забаненых, очевидно, на гугле кул хацкеров из постов выше картинки той же дверной ручки от abloy в разборе. Спойлер: ни одной батарейки АА
Ах, потратьте выходные хотя бы на поверхностное ознакомление с template c++. И "магия" и "ограничения и языка и платформы" сразу пропадут. Ни джава, ни котлин, ни c# generics и близко не лежали.
Помню когда после белой и пушистой Windows 95 вышла 98, которая, по слухам, тоже была ничуть не лучше, но имела проблемы с обратной совместимостью и впридачу занимала больше места на диске, тут же набежала куча павликов, которые рассказывали какие dll надо скопировать из 98 в 95, чтоб все оставалось как раньше. Потом естественно начались синие экраны и проблемы с обновлениями, и тема была позабыта.
Удивительно что этой ерундой кто-то занимается и сегодня, когда хотя бы тех же дистрибутивов Линукса для хилого железа как грязи, и браузеры там отлично работают.
Но за статью спасибо. ИДА, Руссинович... Вспомнил молодость :)
Кто на самом деле использует asp.net чтобы запустить поверх swagger, чтоб был REST API, а потом пишет клиент на React, чтоб показать примитивную страничку? Притом что сборка клиентского кода (мне было нечего делать, взял yml из проекта) потребовала больше 2Гб "зависимостей", результат был 300К однострочного js "кода"
И притом что ASP может то же самое из коробки уже добрых 20 лет безо всех этих хлопот?
Я спросил шефа зачем, он ответил "сейчас все так делают" Привыкайте ;)
Нужно? От железа зависит. Помню программировал на старых AXIS чипах, так там DMA каналы повсюду можно было использовать, не только как ext<->RAM, но и как RAM<->RAM тоже. Примеры и рекомендации, когда такой memcpy лучше, были сразу в документации.
Всякое бывает. Структуры в реальности не только из целых состоят, там ещё строки бывают и плавающая точка и всё прочее.
Так что ради только целых заморачиваться не приходилось. В любом случае, если для канала мегабайты уже проблема, а время нет, так сериализируйте как умеете, а дальше b/g/lzip куда проще будет, чем свой велосипед изобретать
Хотел было тоже самое написать, но не успел
Типичный КГАМ.
Про curl знаю, про два других не слышал ни разу. И как мне этот креативный текст помог мне понять разницу?
В простых случаях это отлично работает. Но признаться я сдался, когда потребовалось асинхронно пушить сообщения от сервера одному или нескольким из N клиентов. Не хотите такой случай тестами покрыть? :)
Ничего личного, но "dotnet ef migrations add XXX" и "dotnet ef database update" делают вроде тоже самое, но работают из коробки и кажутся мне проще.
А поменяйте в вашем примере в настройках Postgres на какой-нибудь T-SQL ;) В dotnet всё, что придётся сделать, это поменять пакет. Код править не придётся. В Spring, насколько я помню, я должен знать, у кого там в sql update на самом деле upsert, а у кого merge, или как получить автоинкрементированный номер только что вставленой записи.
Ну или попробуйте поддерживать пару разных разных СУБД в одном проекте со всеми этими миграциями.
Литералы тут не у дел, в одном файле можно смешать хоть все 4 типа (про LE/BE в UTF-16/32 промолчу). Никакой BOM тут не поможет. Более того, стандарт С++23 раздел 5.2.1 требует распознавания файлов UTF-8 независимо от их содержания, а 5.2.2 впридачу игнорировать BOM с порядком байтов в юникоде.
Юникод в идентификаторах поддерживается, раздел 5.10
К сожалению я не внимательно слежу за развитием С++ в последние годы, но приведите пожалуйста ссылку на стандарт где написано, что исходный текст С++ перестал быть ASCII и стал каким-то юникодом.
Чем мне нравится .net, там не надо изобретать велосипедов для простой миграции. И да, угадывать СУБД тоже не надо ;)
Уж не знаю что вы там делали с Windows, но экран смерти Линукс нагугливается по linux kernel panic на два счета, если правда не ни разу не видели ;)
Уже упомянутый драйвер печати в PDF умеет не только делить документы на страницы, но и страницы на части. Чтоб, например, разделить страницу на две волне достаточно. Если ещё и с полями поиграться, то можно разбить страницу на несколько документов, один и будет нужным прямоугольником.
Из преимуществ в результате получаем настоящий PDF, а не картинку. Плюс можно наглядно объяснить шефу, как можно заработать больше денег если не жаться на лицензию для нормального продукта :)
Так Inline тоже уже давно не требование, попробуйте напрмер экспортировать такую функцию из .so или .dll
В некоторых языках возможна и кодогенерация во время исполнения, Expression в C# живой пример
Простой ответ: нисколько. Ни один существующий стандарт С++ не предусматривает компиляции в runtime
Трогательно. Но Qt худо-бедно поддерживает не только MS, но и Linux, и вроде даже Mac. Там у Вас тоже с++ версии для них есть? И это только десктоп, а сегодня всем подавай мобайл. Андроид, Эппл там.
И всё это покрывают Web приложения безо всяких хлопот с нынешними и будущими версиями, и эффективность бекенда уже не так и волнует. Это про бизнес
Впрочем, если Вы работаете по цене электричества, так KDE под BSD, вроде так толком до сих пор и не портировали :)))
Ой как интересно, расскажите поподробнее. Я как раз такие штуки программирую. Взамен пообещаю выложить для забаненых, очевидно, на гугле кул хацкеров из постов выше картинки той же дверной ручки от abloy в разборе. Спойлер: ни одной батарейки АА
Ах, потратьте выходные хотя бы на поверхностное ознакомление с template c++. И "магия" и "ограничения и языка и платформы" сразу пропадут. Ни джава, ни котлин, ни c# generics и близко не лежали.
Помню когда после белой и пушистой Windows 95 вышла 98, которая, по слухам, тоже была ничуть не лучше, но имела проблемы с обратной совместимостью и впридачу занимала больше места на диске, тут же набежала куча павликов, которые рассказывали какие dll надо скопировать из 98 в 95, чтоб все оставалось как раньше. Потом естественно начались синие экраны и проблемы с обновлениями, и тема была позабыта.
Удивительно что этой ерундой кто-то занимается и сегодня, когда хотя бы тех же дистрибутивов Линукса для хилого железа как грязи, и браузеры там отлично работают.
Но за статью спасибо. ИДА, Руссинович... Вспомнил молодость :)
Кто на самом деле использует asp.net чтобы запустить поверх swagger, чтоб был REST API, а потом пишет клиент на React, чтоб показать примитивную страничку? Притом что сборка клиентского кода (мне было нечего делать, взял yml из проекта) потребовала больше 2Гб "зависимостей", результат был 300К однострочного js "кода"
И притом что ASP может то же самое из коробки уже добрых 20 лет безо всех этих хлопот?
Я спросил шефа зачем, он ответил "сейчас все так делают" Привыкайте ;)
Я про etrax 100 отсюда https://en.m.wikipedia.org/wiki/ETRAX_CRIS
Тогда ни видео ни японцев ещё не было ;)
Как-то ни о чём статья.
Можно? Да, можно.
Нужно? От железа зависит. Помню программировал на старых AXIS чипах, так там DMA каналы повсюду можно было использовать, не только как ext<->RAM, но и как RAM<->RAM тоже. Примеры и рекомендации, когда такой memcpy лучше, были сразу в документации.
SignalR? grpc? Это из того, чем пользовался кроме/в смеси с REST
Всякое бывает. Структуры в реальности не только из целых состоят, там ещё строки бывают и плавающая точка и всё прочее.
Так что ради только целых заморачиваться не приходилось. В любом случае, если для канала мегабайты уже проблема, а время нет, так сериализируйте как умеете, а дальше b/g/lzip куда проще будет, чем свой велосипед изобретать