Могу ответить за Венгрию, в Будапеште никаких проблем в магазинах электроники. Как раз в них почти всегда англоговорящие продавцы. А вот во всех остальных местах - да, только венгерский. И это не шовинизм, они просто не знают английского. Ситуаций, когда бы английский знали и принципиально не использовали не встречал. Большинство готовы даже на языке жестов общаться, в основном народ очень дружелюбен к иностранцам.
Это никак не меняет того, запрет на ввоз телефона может быть очень неприятным. Из аэропорта вы доберётесь и без телефона, и новый купить сможете, но это дополнительные приключения и траты на ровном месте.
Утверждение неимоверно сильное и поэтому ложное. Я писал на всём "современном": Go, C#, даже чуть на TypeScript и Rust, а на D не только писал, но и преподавал. Особенно сильно у меня пригорело с C#, потому что я думал, что язык продвинутее и современнее старого C++, а по большинству моментов выяснилось обратное. Мы с коллегой даже начинали подборку "WTF это появилось сейчас, а не 15 лет назад", когда супер базовые (с нашей точки зрения) функции и классы появлялись только в самых последних версиях стандарта.
Есть не мало областей, в которых C++ практически на передовой дизайна языков. Да, своеобразно, да сложно, да тонна наследия и обратной совместимости, но после LINQ std::range выглядит как манна небесная.
Есть множество областей, где действительно можно поругать C++ за отсталость: отсутствие пакетного менеджера (CMake FetchContent для меня решает проблему, но не идеально), слабые гарантии безопасности с повсеместным UB, и так далее. Но почему-то я чаще вижу, что его ругают необосновано те, кто не осилил даже синтаксис.
Я каждый раз удивляюсь, когда говорят, что в C++ слабая стандартная библиотека. Да, там нет встроенных сокетов, json, http или 3D движка, но зачем, если для этого есть сторонние библиотеки? Зато есть stl, который даст фору станадртным библиотекам любых популярных языков (не уверен про Rust разве что). Каждый раз, когда я пишу на других языках, я удивляюсь тому насколько мне не хватает stl. И это касается и разнообразия контейнеров, и алгоритмов, и деталей вроде возможности итерироваться по ключам и значениям map одновременно. Stl не совершенен, но в большинстве других языков всё ещё гораздо хуже.
P.S. Ranges деалют stl не только мощной, но и выразительной, за что им большое спасибо.
Физика строит матмодель, математика делает выводы из этой модели. Дробление до бесконечности числа, стоящего за расстоянием, совершенно не означает реального дробления расстояния. В реально мире нет отрицательных длин или мнимых значений, но это не значит, что мы не можем их использовать в изучении матмодели.
Уже отметили выше, но переформулирую. Из бесконечности последовательности шагов Ахилеса на конечной не следует и квантование пространства и времени. Как раз наоборот, если члены последовательности с какого-то момента перестанут ументшаться, то ряд разойдётся и дистанция будет бесконечной. Из того, что мы можем вообразить бесконечную делимость чего-либо совершенно не следует ни бесконечный размер, ни квантование. Апории Зенона отлично решаются матанализом, если вас интресует именно логическая сторона вопроса.
Что-то вы написали какие-то очень несовременные банальности, которые и без авто в языке были проблемами. Авто внёс свои, но ни одну из них вы не затронули. А вся эта игра с числами была всегда, например
float half = 1/2;
Вас же не удивляет, что здесь будет ноль?
Ну а противиться фиче через 12 лет после её внедрения, когда уже со всех сторон разобраны хорошие и плохие её применения, это как-то странно. У меня есть много кода, который без авто либо не написать вообще (сложные шаблоны), либо он будет выглядеть настолько ужасно, что читать его невозможно.
Я сам не люблю, когда авто используют слишком часто, или вообще рекоомендуют использовать везде. Слишком падает читаемость, IDE не всегда спасает. Но совсем отрицать - перебор. Моё личное требование - тип должен быть
либо написан в этой же строке кода, условно auto o = new Object();
либо быть сложным для написания, но очевидным (auto iter = vec.begin()),
либо быть очень сложным или невозможным для написания (сложные шаблонные выводы)
Имеет смысл рассматривать вопросы читаемости, не всем очевидные правила отбросывания ссылок, работу с промежуточными типами вроде vector<bool>::reference, а не вот эти наличия буковки f.
Простите, что докапываюсь до слов, а не содержимого, но очередь точно конкурентная, а не потокобезопасная или многопоточная? Если в английском concurrent (одновременный) тут применимо, то созвучное русское слово ну вообще же не в тему. Это не прямой перевод, не устоявшийся в русском термин.
Напомнило мне вопрос для собесов "Что происходит после того как вы набираете адрес сайта в браузере и жмёте enter". Очень глубокий вопрос, который подходит как новичкам, так и матёрым. При чём хорошо подсвечивает, чем именно человек занимался и на чём фокусировался. Условно админ больше расскажет про резолвинг имён, процесс подключения, JS программист про то, как сайты динамически подгружают сами себя, я вот могу больше про HTTP протокол и SSL handshake. То есть показывает глубину, ширину и область знаний.
Спасибо за статью, как раз то, что хотел почитать, но руки не доходили.
Я правильно понимаю, что можно дообучить таким образом ту же LLaMA на какой-нибудь большой доке и она начнёт ориентироваться в предмете? Или дать очень большой текст (условную войну и мир) и дальше сделать сокращённый пересказ и уточнить детали, пропущенные в нём? Если да, то буду рад разбору задач в будущем, ну или просто ссылкам по теме.
Очередной раз в С++ придумали, как сделать новую фичу на основе уже существующих, вообще для этого не задуманных. Это же почти static exceptions, которые может быть будут в следующих стандартах. И не поймите меня не правильно, мне очень понравилась идея и я даже ею воспользуюсь при необходимости, но почему-то весь С++ состоит из таких вот вещей, что настораживает.
Есть ли бенчмарки или разбор того, как компилятор это оптимизирует? Теоретически это всё сводится примерно к тому же коду, что был на ифах, но осиливает ли компилятор такие оптимизации? Не вносят ли корутины слишком много накладных расходов?
И почему Дейстра сделает 1 653 963 операций? Если в графе всего 5 ребёр, то это максимум 5 итераций, сотоящих из поиска минимума в очереди из не более 5 элементов и вставок в неё же. Это 5 * (log(5) + log(5)), что не более 30 базовых сравнений, а никак не миллион. Формулы же на худший случай, если случай лучше, то это не значит, что будет впустую молотить.
А почему |E| = 5? |E| - общее количество рёбер в графе, а не среднее на вершину. Так что для случая, когда есть хотя бы по одному ребру на вершину у вас не лучше |V|^2. Ну а если граф настолько уж разрежен, то и Дейкстра с нормальной очердью будет очень быстр. В очереди же лежат достижимые вершины, а не все, поэтому он быстро переберёт все достижимые и выйдет. За то же время количество посещённых вершин, что и у вас, только выбирать наименьший вес будет много быстрее, чем линейный поиск по всем рёбрам в графе.
Если вы утверждаете, что в каких-то случаях ваш алгоритм быстрее, то показали бы бенчмарки на этих примерах и сравнили бы с какой-нибудь готовой реализацей Дейкстры.
Соглашусь с вами, но не про данную модель. Горный велосипед - спортивный инвентарь. На нём можно ездить по городу и использовать как транспорт, но для этого гораздо лучше подходит городской велосипед: шоссейник, гибрид, да даже гравел. В городе MTB выглядит как прокаченный внедорожник (которые несомненно встречаются).
А в качестве горного и внедорожного у электрического есть большой минус - он тяжёлый, что очень плохо для маневренности и отработки неровностей. Единственное известное мне применение - полный привод для грязи и снега. Сам хотел поставить передний привод для глубокого снега зимой.
Запрещено. В силу требований потоковой безопасности в первую очередь. Вот только не всем она нужна, особенно с учётом её цены. Такой же пример - std::shared_ptr, его атомарный счётчик слишком уж дорог для многих применений. Имхо, это нарушение базового принципа "не платить за то, что не используешь". Поэтому мы отказались от этих довольно слабых гарантий (класс в целом всё равно не thread-safe) в пользу производительности в одном потоке.
P.S. Струкутуру проекта поправили, ссылка изменилась panda::string
Сложно утвержать сразу про все реализации std, но скорее нет, чем да. На 64-битной архитектуре sizeof(panda::string) == 40. Стандартная у меня 32 (Debian 11, GCC 10.2). То есть просто так передавать по значению тоже может быть чуть-чуть дороговато, лучше бы по ссылке. Но скопировать себе для хранения - ни о чём на фоне аллокации и копии в std.
Шёл 2023 год, а в статьях GCC 6.3. Не удивительно при оригинале статьи из 2017 года. При этом ни про устройство, ни про гарантии и потенциальный UB от повисших указателей. `string_view` - замечательная вещь, но хоть какие-нибудь размышления и сравнения с char* не помешали бы.
Ну и воспользуюсь случаем и порекламмирую panda::string. CopyOnWrite(CoW), все те же substr тоже без копирований и аллокаций, но с полной гарантией безопасности. Тот же SSO на 23 байта. Цена полной безопасности дешёвого subbstr - CoW не лучшим образом дружит с потоками. Но если не шарить стейт и передавать копии данных аккуратно, ну или как мы вообще не использовать потоки, то это совсем не цена.
Я так понял, что в векторе вы взяли magic_get (который нынче Boost.PFR) и развернули массив структур в структуру массивов. Интересное упражнение.
А что насчёт индексов и выборок? Для ECS же важно уметь выбирать наборы компонент. Типа для всех, содержащих компоненту Health и Collision, запустить систему нанесения урона при столкновении.
Немецкие власти запретили в школах земли Гессен Office 365 ещё в 2019 году. В июле текущего года Microsoft представила облачную услугу, которая позволит клиентам из государственного сектора использовать сервисы в соответствии с политикой ЕС.
Вот так, например? Да, французы ещё не сделали, но явно не в вакууме решение принимали.
Могу ответить за Венгрию, в Будапеште никаких проблем в магазинах электроники. Как раз в них почти всегда англоговорящие продавцы. А вот во всех остальных местах - да, только венгерский. И это не шовинизм, они просто не знают английского. Ситуаций, когда бы английский знали и принципиально не использовали не встречал. Большинство готовы даже на языке жестов общаться, в основном народ очень дружелюбен к иностранцам.
Это никак не меняет того, запрет на ввоз телефона может быть очень неприятным. Из аэропорта вы доберётесь и без телефона, и новый купить сможете, но это дополнительные приключения и траты на ровном месте.
Утверждение неимоверно сильное и поэтому ложное. Я писал на всём "современном": Go, C#, даже чуть на TypeScript и Rust, а на D не только писал, но и преподавал. Особенно сильно у меня пригорело с C#, потому что я думал, что язык продвинутее и современнее старого C++, а по большинству моментов выяснилось обратное. Мы с коллегой даже начинали подборку "WTF это появилось сейчас, а не 15 лет назад", когда супер базовые (с нашей точки зрения) функции и классы появлялись только в самых последних версиях стандарта.
Есть не мало областей, в которых C++ практически на передовой дизайна языков. Да, своеобразно, да сложно, да тонна наследия и обратной совместимости, но после LINQ std::range выглядит как манна небесная.
Есть множество областей, где действительно можно поругать C++ за отсталость: отсутствие пакетного менеджера (CMake FetchContent для меня решает проблему, но не идеально), слабые гарантии безопасности с повсеместным UB, и так далее. Но почему-то я чаще вижу, что его ругают необосновано те, кто не осилил даже синтаксис.
Я каждый раз удивляюсь, когда говорят, что в C++ слабая стандартная библиотека. Да, там нет встроенных сокетов, json, http или 3D движка, но зачем, если для этого есть сторонние библиотеки? Зато есть stl, который даст фору станадртным библиотекам любых популярных языков (не уверен про Rust разве что). Каждый раз, когда я пишу на других языках, я удивляюсь тому насколько мне не хватает stl. И это касается и разнообразия контейнеров, и алгоритмов, и деталей вроде возможности итерироваться по ключам и значениям map одновременно. Stl не совершенен, но в большинстве других языков всё ещё гораздо хуже.
P.S. Ranges деалют stl не только мощной, но и выразительной, за что им большое спасибо.
Физика строит матмодель, математика делает выводы из этой модели. Дробление до бесконечности числа, стоящего за расстоянием, совершенно не означает реального дробления расстояния. В реально мире нет отрицательных длин или мнимых значений, но это не значит, что мы не можем их использовать в изучении матмодели.
Уже отметили выше, но переформулирую. Из бесконечности последовательности шагов Ахилеса на конечной не следует и квантование пространства и времени. Как раз наоборот, если члены последовательности с какого-то момента перестанут ументшаться, то ряд разойдётся и дистанция будет бесконечной. Из того, что мы можем вообразить бесконечную делимость чего-либо совершенно не следует ни бесконечный размер, ни квантование. Апории Зенона отлично решаются матанализом, если вас интресует именно логическая сторона вопроса.
Что-то вы написали какие-то очень несовременные банальности, которые и без авто в языке были проблемами. Авто внёс свои, но ни одну из них вы не затронули. А вся эта игра с числами была всегда, например
Вас же не удивляет, что здесь будет ноль?
Ну а противиться фиче через 12 лет после её внедрения, когда уже со всех сторон разобраны хорошие и плохие её применения, это как-то странно. У меня есть много кода, который без авто либо не написать вообще (сложные шаблоны), либо он будет выглядеть настолько ужасно, что читать его невозможно.
Я сам не люблю, когда авто используют слишком часто, или вообще рекоомендуют использовать везде. Слишком падает читаемость, IDE не всегда спасает. Но совсем отрицать - перебор. Моё личное требование - тип должен быть
либо написан в этой же строке кода, условно auto o = new Object();
либо быть сложным для написания, но очевидным (auto iter = vec.begin()),
либо быть очень сложным или невозможным для написания (сложные шаблонные выводы)
Имеет смысл рассматривать вопросы читаемости, не всем очевидные правила отбросывания ссылок, работу с промежуточными типами вроде vector<bool>::reference, а не вот эти наличия буковки f.
Простите, что докапываюсь до слов, а не содержимого, но очередь точно конкурентная, а не потокобезопасная или многопоточная? Если в английском concurrent (одновременный) тут применимо, то созвучное русское слово ну вообще же не в тему. Это не прямой перевод, не устоявшийся в русском термин.
Напомнило мне вопрос для собесов "Что происходит после того как вы набираете адрес сайта в браузере и жмёте enter". Очень глубокий вопрос, который подходит как новичкам, так и матёрым. При чём хорошо подсвечивает, чем именно человек занимался и на чём фокусировался. Условно админ больше расскажет про резолвинг имён, процесс подключения, JS программист про то, как сайты динамически подгружают сами себя, я вот могу больше про HTTP протокол и SSL handshake. То есть показывает глубину, ширину и область знаний.
Спасибо за статью, как раз то, что хотел почитать, но руки не доходили.
Я правильно понимаю, что можно дообучить таким образом ту же LLaMA на какой-нибудь большой доке и она начнёт ориентироваться в предмете? Или дать очень большой текст (условную войну и мир) и дальше сделать сокращённый пересказ и уточнить детали, пропущенные в нём? Если да, то буду рад разбору задач в будущем, ну или просто ссылкам по теме.
Стоит отметить, что 9 это не рекорд, они уже делали 12. https://en.wikipedia.org/wiki/List_of_Falcon_9_first-stage_boosters#Booster_1051
Upd. Рекорд судя по всему 15. https://en.wikipedia.org/wiki/List_of_Falcon_9_first-stage_boosters#B1058
Очередной раз в С++ придумали, как сделать новую фичу на основе уже существующих, вообще для этого не задуманных. Это же почти static exceptions, которые может быть будут в следующих стандартах. И не поймите меня не правильно, мне очень понравилась идея и я даже ею воспользуюсь при необходимости, но почему-то весь С++ состоит из таких вот вещей, что настораживает.
Есть ли бенчмарки или разбор того, как компилятор это оптимизирует? Теоретически это всё сводится примерно к тому же коду, что был на ифах, но осиливает ли компилятор такие оптимизации? Не вносят ли корутины слишком много накладных расходов?
И почему Дейстра сделает 1 653 963 операций? Если в графе всего 5 ребёр, то это максимум 5 итераций, сотоящих из поиска минимума в очереди из не более 5 элементов и вставок в неё же. Это 5 * (log(5) + log(5)), что не более 30 базовых сравнений, а никак не миллион. Формулы же на худший случай, если случай лучше, то это не значит, что будет впустую молотить.
А почему |E| = 5? |E| - общее количество рёбер в графе, а не среднее на вершину. Так что для случая, когда есть хотя бы по одному ребру на вершину у вас не лучше |V|^2. Ну а если граф настолько уж разрежен, то и Дейкстра с нормальной очердью будет очень быстр. В очереди же лежат достижимые вершины, а не все, поэтому он быстро переберёт все достижимые и выйдет. За то же время количество посещённых вершин, что и у вас, только выбирать наименьший вес будет много быстрее, чем линейный поиск по всем рёбрам в графе.
Если вы утверждаете, что в каких-то случаях ваш алгоритм быстрее, то показали бы бенчмарки на этих примерах и сравнили бы с какой-нибудь готовой реализацей Дейкстры.
Соглашусь с вами, но не про данную модель. Горный велосипед - спортивный инвентарь. На нём можно ездить по городу и использовать как транспорт, но для этого гораздо лучше подходит городской велосипед: шоссейник, гибрид, да даже гравел. В городе MTB выглядит как прокаченный внедорожник (которые несомненно встречаются).
А в качестве горного и внедорожного у электрического есть большой минус - он тяжёлый, что очень плохо для маневренности и отработки неровностей. Единственное известное мне применение - полный привод для грязи и снега. Сам хотел поставить передний привод для глубокого снега зимой.
Запрещено. В силу требований потоковой безопасности в первую очередь. Вот только не всем она нужна, особенно с учётом её цены. Такой же пример - std::shared_ptr, его атомарный счётчик слишком уж дорог для многих применений. Имхо, это нарушение базового принципа "не платить за то, что не используешь". Поэтому мы отказались от этих довольно слабых гарантий (класс в целом всё равно не thread-safe) в пользу производительности в одном потоке.
P.S. Струкутуру проекта поправили, ссылка изменилась panda::string
Сложно утвержать сразу про все реализации std, но скорее нет, чем да. На 64-битной архитектуре sizeof(panda::string) == 40. Стандартная у меня 32 (Debian 11, GCC 10.2). То есть просто так передавать по значению тоже может быть чуть-чуть дороговато, лучше бы по ссылке. Но скопировать себе для хранения - ни о чём на фоне аллокации и копии в std.
Шёл 2023 год, а в статьях GCC 6.3. Не удивительно при оригинале статьи из 2017 года. При этом ни про устройство, ни про гарантии и потенциальный UB от повисших указателей. `string_view` - замечательная вещь, но хоть какие-нибудь размышления и сравнения с char* не помешали бы.
Ну и воспользуюсь случаем и порекламмирую panda::string. CopyOnWrite(CoW), все те же substr тоже без копирований и аллокаций, но с полной гарантией безопасности. Тот же SSO на 23 байта. Цена полной безопасности дешёвого subbstr - CoW не лучшим образом дружит с потоками. Но если не шарить стейт и передавать копии данных аккуратно, ну или как мы вообще не использовать потоки, то это совсем не цена.
Меня тоже не порадовал этот момент. Самокат тем и отличается от скутера или мотоцикла, что его легко занести домой. Где ещё его заряжать?
Я так понял, что в векторе вы взяли magic_get (который нынче Boost.PFR) и развернули массив структур в структуру массивов. Интересное упражнение.
А что насчёт индексов и выборок? Для ECS же важно уметь выбирать наборы компонент. Типа для всех, содержащих компоненту Health и Collision, запустить систему нанесения урона при столкновении.
Вот так, например? Да, французы ещё не сделали, но явно не в вакууме решение принимали.