А почему вы, собственно, решили, что порядок байт будет именно LE, а не BE? Стандарт это никак не регламентирует и ваш >> окажет совсем не тот эффект, что вы ожидаете.
strtok, действительно,имеет ограниченный спектр применения, так как требует крайне аккуратного применения, что для однопоточных программ при грамотном проектировании (большинство из coreutils), впрочем - не проблема (с strtok_s по производительности не сравнивал). tmpfile, действительно, с ходу не вспомнить, где встречалось, но идея-то понятна: можно подсунуть библиотекам, которые умеют работать только с файлами такой вот "файл". С натяжкой можно сравнить это с подходом интерфейсов Reader и Writer в Go.
Абсолютно верно, тот самый случай, когда важно поставить правильную задачу, а не вот это вот "10 запросов на бекенд", хотя случаи всякие бывают, конечно. Думаю, именно из-за подобных проблем и родился GraphQL.
Тоже писал что-то похожее для своего проекта, для разрешения блокировок добавил возможность указать время ожидания, по истечении которого запись в конкретный канал слушателя будет пропущена и выплюнута ошибка в канал ошибок (до этого иногда все приложение "вставало колом", если буфер канала на слушающей стороне переполнялся или если просто горутина там подвисала).
И каналы тоже передает подписчик, либо он может создаваться автоматически. В общем, интересное резюме для себя получил )) Спасибо за статью и за комментарий.
Тимофей Тиунов:“В данном примере async не нужен. Вот пример, где как бы есть await, но в конце возвращается promise:
Полагаю, что в примере, к которому написано это замечание, могут быть асинхронные вопросы, результат которых возвращается, например, что-то вроде этого (пример условный):
async function loadData(id) {
let response;
try {
response = await fetch(`/data/${id}`);
} catch (e) {
console.error('request failed by the reason:', e);
return null;
}
return response;
}
Эта функция возвращает Promise, хотя сам по себе объект response таковым и не является.
Честно говоря, не понятно, зачем было тогда переводить статью, если у вас к ней столько замечаний? Может, лучше было написать свою с правильными примерами, а оригинал указать в качестве источника вдохновения, а то выглядит как попытка касаться умнее какого-то автора в интернете.
Основная проблема NFT в том, что все гарантии обеспечиваются кем угодно. Сегодня этот кто-то есть, а завтра сервис остановили (никогда такого не было, и вот опять), и эти токены превратились в тыкву. А сравнение с Netflix и Steam вообще некорректно, да, продукт сдается в аренду, но у него есть практическая польза - его можно потребить (развлечение), а на NFT только, простите, фапать.
А вот марки лежат себе и лежат, никто эти "фантики" не превратит в тыкву удаленно отключением рубильника.
Если не трудно, поясните, пожалуйста, свою точку зрения, а то я хоть и не часто на плюсах пишу, но с автором согласен в целом, и что такого хорошего дают заголовочные файлы - не могу представить.
Она не нравится или не нравится, а просто ограничивает применимость в некоторых коммерческих проектах. Если вы пишете только открытое ПО ещё и получаете за это деньги, то искренне рад за вас.
Ну и так немного почитал - пока не понял - можно ли там провернуть все, что нужно - смутило то, что список аргументов для метода Call имеет тип ...uintptr, а в примере передается просто число 7 константой, но пока спишу на то, что нужно поглубже вникнуть.
Надеюсь, вы дочитали до конца, потому что согласен с вами почти полностью. Единственное, что хотелось бы сказать: приложения на Go не обязаны быть open source.
Про KeepAlive, вроде, в issue написано, что эта штука не защищает от сборщика мусора, поправьте, если ошибаюсь. Пробовали cgo.NewHandle? Он как раз для этих целей. И никаких проблем с гонкой не должно быть. Правда, сохранять нужно ссылку на сам слайс.
За то, что решения подаются, как серебрянная пуля без недостатков/ограничений области применимости, что, очевидно, не так. Да и сами по себе решения не являются изобретениям (подобное и ранее встречал, и реализовывал в том или ином виде - тоже).
Попробуйте KDE Neon, да rolling release, но там самая свежая плазма, которая прям сильно личше как визуально, так и функционально. Пару лет как перешел и не жалею, главное, не ставить глобальные обновления версий сразу после их выхода (ну знаете, лучше дожаться версии X.X.Y, чем ставить X.X.0).
Правильно ли я понимаю, что вы предлагаете вместо слабой связности между представлением и моделью использовать сильную связность? Если так, то позволю себе с вами не согласиться. Для небольших проектов ваш подход может быть даже более предпочтительным, как раз ввиду малого количества абстракций, но вот любой достаточно сложный проект превратится в неподдерживаемый, ведь:
Теперь невозможно без боли реализовать отличающиеся интерфейсы для разных платформ с учётом их специфики, просто написав несколько различных представлений одной и той же части интерфейса
Любое изменение в интерфейсе модели будет требовать изменения ваших умных виджетов, ведь они отвечают не только за представление, но и за получение данных из модели
Не раз замечал, как разработчики начинают путать логику UI и логику взаимодействия с моделью. Как по мне, логику UI (фокус, цветовые акценты, эффекты и т.д.) нужно оставлять в представлении, все остальное должно быть внедрено в представление изве. Тогда изменение модели и представления могут происходить независимо (до определенного момента, конечно).
Начнем с того, что в Go есть ООП, почти что самый классический, разве что можно методы вызывать, а не передавать объекту сообщения на обработку. interface{} - это выстрел себе в ногу и ломание статической типизации (весьма строгой замечу) через колено. Этот тип нужен, когда мы реально не знаем - что там (скажем, map[string]interface{}), в большинстве же случаев известен либо конкретный конкретный тип, либо набор типов. И передавая значение в функцию, я хочу знать, что передано значение неподходящего типа на этапе компиляции, а не во время отладки.
Есть некоторые подозрения, что вы не писали библиотек на go. Есть масса обобщенных алгоритмов, которые, ввиду отсутствия дженериков, кочуют из проекта в проект в виде копипасты кода с подстановкой типов. Только не говорите мне про кодогенерацию, пожалуйста. А вот исключения, действительно, не нужны, хотя какой-то альтернативный метод обработки ошибок вроде Maybe хотелось бы иметь, не спорю.
А почему вы, собственно, решили, что порядок байт будет именно LE, а не BE? Стандарт это никак не регламентирует и ваш >> окажет совсем не тот эффект, что вы ожидаете.
strtok, действительно,имеет ограниченный спектр применения, так как требует крайне аккуратного применения, что для однопоточных программ при грамотном проектировании (большинство из coreutils), впрочем - не проблема (с strtok_s по производительности не сравнивал). tmpfile, действительно, с ходу не вспомнить, где встречалось, но идея-то понятна: можно подсунуть библиотекам, которые умеют работать только с файлами такой вот "файл". С натяжкой можно сравнить это с подходом интерфейсов Reader и Writer в Go.
Абсолютно верно, тот самый случай, когда важно поставить правильную задачу, а не вот это вот "10 запросов на бекенд", хотя случаи всякие бывают, конечно. Думаю, именно из-за подобных проблем и родился GraphQL.
Тоже писал что-то похожее для своего проекта, для разрешения блокировок добавил возможность указать время ожидания, по истечении которого запись в конкретный канал слушателя будет пропущена и выплюнута ошибка в канал ошибок (до этого иногда все приложение "вставало колом", если буфер канала на слушающей стороне переполнялся или если просто горутина там подвисала).
И каналы тоже передает подписчик, либо он может создаваться автоматически. В общем, интересное резюме для себя получил )) Спасибо за статью и за комментарий.
Полагаю, что в примере, к которому написано это замечание, могут быть асинхронные вопросы, результат которых возвращается, например, что-то вроде этого (пример условный):
Эта функция возвращает Promise, хотя сам по себе объект
responseтаковым и не является.Честно говоря, не понятно, зачем было тогда переводить статью, если у вас к ней столько замечаний? Может, лучше было написать свою с правильными примерами, а оригинал указать в качестве источника вдохновения, а то выглядит как попытка касаться умнее какого-то автора в интернете.
Основная проблема NFT в том, что все гарантии обеспечиваются кем угодно. Сегодня этот кто-то есть, а завтра сервис остановили (никогда такого не было, и вот опять), и эти токены превратились в тыкву. А сравнение с Netflix и Steam вообще некорректно, да, продукт сдается в аренду, но у него есть практическая польза - его можно потребить (развлечение), а на NFT только, простите, фапать.
А вот марки лежат себе и лежат, никто эти "фантики" не превратит в тыкву удаленно отключением рубильника.
Meta (Super) или Alt+F2, а дальше вводим "kwr" - в списке уже kwrite. Что я делаю не так?
Спасибо, рад, что кому-то моя работа принесла пользу.
Если не трудно, поясните, пожалуйста, свою точку зрения, а то я хоть и не часто на плюсах пишу, но с автором согласен в целом, и что такого хорошего дают заголовочные файлы - не могу представить.
Она не нравится или не нравится, а просто ограничивает применимость в некоторых коммерческих проектах. Если вы пишете только открытое ПО ещё и получаете за это деньги, то искренне рад за вас.
Ну и так немного почитал - пока не понял - можно ли там провернуть все, что нужно - смутило то, что список аргументов для метода Call имеет тип ...uintptr, а в примере передается просто число 7 константой, но пока спишу на то, что нужно поглубже вникнуть.
Спасибо за ссылку - интересное решение. Только лицензия расстроила. Надо будет сравнить в аналогичных тестах.
Надеюсь, вы дочитали до конца, потому что согласен с вами почти полностью. Единственное, что хотелось бы сказать: приложения на Go не обязаны быть open source.
Про KeepAlive, вроде, в issue написано, что эта штука не защищает от сборщика мусора, поправьте, если ошибаюсь. Пробовали cgo.NewHandle? Он как раз для этих целей. И никаких проблем с гонкой не должно быть. Правда, сохранять нужно ссылку на сам слайс.
А почему не стали смотреть в сторону gRPC/protobuf?
За то, что решения подаются, как серебрянная пуля без недостатков/ограничений области применимости, что, очевидно, не так. Да и сами по себе решения не являются изобретениям (подобное и ранее встречал, и реализовывал в том или ином виде - тоже).
Попробуйте KDE Neon, да rolling release, но там самая свежая плазма, которая прям сильно личше как визуально, так и функционально. Пару лет как перешел и не жалею, главное, не ставить глобальные обновления версий сразу после их выхода (ну знаете, лучше дожаться версии X.X.Y, чем ставить X.X.0).
Не зависит. OS Android работает на ядре linux, но не является системой семейства GNU/Linux. Тут все однозначно.
Правильно ли я понимаю, что вы предлагаете вместо слабой связности между представлением и моделью использовать сильную связность? Если так, то позволю себе с вами не согласиться. Для небольших проектов ваш подход может быть даже более предпочтительным, как раз ввиду малого количества абстракций, но вот любой достаточно сложный проект превратится в неподдерживаемый, ведь:
Теперь невозможно без боли реализовать отличающиеся интерфейсы для разных платформ с учётом их специфики, просто написав несколько различных представлений одной и той же части интерфейса
Любое изменение в интерфейсе модели будет требовать изменения ваших умных виджетов, ведь они отвечают не только за представление, но и за получение данных из модели
Не раз замечал, как разработчики начинают путать логику UI и логику взаимодействия с моделью. Как по мне, логику UI (фокус, цветовые акценты, эффекты и т.д.) нужно оставлять в представлении, все остальное должно быть внедрено в представление изве. Тогда изменение модели и представления могут происходить независимо (до определенного момента, конечно).
Начнем с того, что в Go есть ООП, почти что самый классический, разве что можно методы вызывать, а не передавать объекту сообщения на обработку.
interface{}- это выстрел себе в ногу и ломание статической типизации (весьма строгой замечу) через колено. Этот тип нужен, когда мы реально не знаем - что там (скажем,map[string]interface{}), в большинстве же случаев известен либо конкретный конкретный тип, либо набор типов. И передавая значение в функцию, я хочу знать, что передано значение неподходящего типа на этапе компиляции, а не во время отладки.Есть некоторые подозрения, что вы не писали библиотек на go. Есть масса обобщенных алгоритмов, которые, ввиду отсутствия дженериков, кочуют из проекта в проект в виде копипасты кода с подстановкой типов. Только не говорите мне про кодогенерацию, пожалуйста. А вот исключения, действительно, не нужны, хотя какой-то альтернативный метод обработки ошибок вроде Maybe хотелось бы иметь, не спорю.