Думаю, что если у вас есть желание написать подобную статью, то не стоит себя останавливать. Я показал свои варианты реализации хранения деревьев в БД, а вы покажите свои. Соглашусь, что ORM Hibernate не идеальный фреймворк для работы с деревьями, но и реляционные БД тоже не заточены для работы с ними. Одна из причин использования нативных SQL запросов - это ограниченные и не всегда эффективные возможности самого ORM Hibernate. К примеру на данный момент Hibernate не генерирует рекурсивные запросы, а также этот запрос пока нельзя сделать с помощью JPQL. Если полагаться только на средства\возможности Hibernate, то при обходе дерева (Adjacency List) фреймворк сгенерирует множество SQL запросов, когда можно было бы решить эту задачу одним рекурсивным запросом. К тому же, я не вижу каких-либо проблем в использовании нативных SQL запросов, так как этот язык стандартизирован и если придерживаться ANSI стандарта, то не будет проблем с переносимостью в будущем, если возникнет необходимость поменять РСУБД. Полагаться же безукоризненно на ORM фреймворк и не использовать SQL - это тоже не саммый лудший подход, так как фреймворки тоже не идеальны. В статье, я приводил SQL запросы и они местами получились громоздкими, так как я старался сделать так, чтоб произвести операцию (получение потомков, получение родителей, добавления узла и т.д) над деревом минимальным числом запросов в БД и при этом подсчитывать ещё и уровень вложенности. Если громоздкие запросы разбить и обернуть в функции PostgreSQL, то естественно читабельность кода улучшиться, но я не старался привязыватся только к конкретной БД PostgreSQL, поэтому и представил всё SQL запросами. Чиатель же может взять SQL запрос и в зависимости от БД обернуть в функцию PostgreSQL или хранимую процедуру Sybase ASE или же оставить в ввиде именнованого SQL запроса, как в статье. Не отрицаю, что при детальном просмотре запросов, возможно где-то можно сделать улучшения, повысить читабельность. В целом же не вижу каких-либо препятствий или ограничений, если будет несколько статей на подобную тематику. Возможно ваши варианты реализации будут лучше. К тому же, всегда хорошо, если есть несколько вариантов решений подобных задач, будет из чего выбрать:).
Грубая ошибка для C++. Много где встречал, что это является плохим тоном. Для базовых числовых типов не желательно использовать массив из указателей и использовать new, если переменная локальная!
Самое обычное выделение памяти под динамический массив в C++. Объявляется указатель на участок памяти, где будет располагаться массив не указателей, а целочисленных значений. В данном случае, конечно, new использовать было совсем не обязательно, т.к. размер необходимого массива нам заранее известен (в данном случае ваш пример с кодом приведен корректно). Но это никак не зависит от того глобальная переменная или локальная. Зависит от того, известна нам размерность или нет.
Основная проблема, что при указателях C++ может разместит массив в куче, а не в кэше(на стеке)
new говорит о выделении динамической памяти, а это всегда только куча, если не применены оптимизации компилятора. Указатели тут не при чем.
Кэш != стек. Помещение данных в стек не гарантирует его кэширование процессором.
Вторая причина компилятор может векторизовать циклы при работе с массивом, а с указателями нет.
В данном случае векторизовывать нечего, т.к. представленный в тесте цикл не параллелится.
Проблема системная и она обычно в головах, а не в компьютерах. Подобные вопросы - отдельный рынок консалтинговых услуг. И рынок этот только растёт. До тех пор пока:
заказывают одни, а работают другие (большие боссы пишут требования от лица пользователя для системы и процесса, в котором они не работали)
платят за красиво (вот деньги и сделайте мне хорошо, я сам не хочу это понимать)
от разработчиков ожидают внедрения (вот вы систему сделали, теперь сделайте чтоб все ей пользовались)
сделай новое по старому (like for like легаси системы, подражание оффлайновым процессам)
мы платим - вы танцуете (нам всё равно какие бизнес и технические проблемы - клиент всегда прав, так что делайте облако на моём заводе и чтоб ключ от сервера был у меня)
левая голова не знает что делает правая (начальники отделов ведут конкурирующую или параллельную политику)
То цирк будет продолжаться. Потому как система - инструмент и не более. Вместо молотка всем выдали шуроповёрт и всё те же гвозди - прироста производительности или уменьшения усталости работника ждать не стоит.
Рассказывать про Entity Framework, и ни разу не упомянуть про миграции и code-first подход - очень странно для туториала. Также при вставке кода рекомендуется выбирать язык для подсветки синтаксиса.
Зачем пересказывать в очередной раз то, что уже отлично расписано на docs.microsoft.com, в частности:
Ален Голуб "Веревка достаточной длины, чтобы выстрелить себе в ногу" - концептуальная книга не только о С++, содержит глубокие мысли о программировании в общем.
Шень. "Программирование - теоремы и задачи", 1995. Краткое и в тоже время интенсивное введение в алгоритмы. Почти все книги уже выкинул и раздал, эту оставил.
Вообще, список можно накидать на пару страниц. Хороших книг очень много.
Угу, в моем случае книгами сильно изменившими представления о программировании (я самоучка) оказались:
«Совершенный код» Макконела;
«Чистый код»/«Чистая архитектура» дядюшки Боба;
«Код. Тайный язык информатики» Петцольда.
Круто, спасибо. Много лет занимаюсь с картами. OSM + Leaflet + Chromium пока что лучшая связка которую можно вменяемо использовать. Гугл мапс платный же с некоторого времени. Для OSM нужен свой сервер конечно-же (для некоторых сценариев), но и возможностей больше в разы.
У нас работает много лет и трафик там иногда тысячи событий в секунду на машинах с десятками ядер.
Это если вам надо проблему решить, а не архитектурно что-то менять =)
Сегодня утром, просматривая почту, я обнаружил ваше письмо, уведомлявшее о невозможности приема меня на работу в вашу компанию.
Я внимательно изучил ваш ответ и с сожалением должен сообщить, что в настоящее время не имею возможности принять ваш отказ. В течение последних месяцев мною было получено множество отказов в трудоустройстве, поэтому, как вы понимаете, у меня имеется широкий выбор, но удовлетворить их все я, к сожалению, не могу.
Несмотря на ваши квалификацию и богатый опыт в области отбора персонала, я вынужден констатировать, что данный отказ слабо аргументирован и противоречит моим интересам, кроме того, никоим образом не соответствует моим планам на ближайшее будущее.
Исходя из вышеизложенного, я считаю необходимым приступить к своим обязанностям в вашей компании, начиная со следующей недели.
Ха!.. Такие смешные комментарии…
А не ваши ли родители в 90-е работали за 50$?
А не от ваших ли дедушек и бабушек всю жизнь воняло навозом и прокисшим молоком?
Если надо будет — будете работать инженерами за кусок маргарина и пачку сахара…
Смешные такие… Вы лучше радуйтесь!
Немного дополню:
1. Отличный FAQ по ConfigureAwait — devblogs.microsoft.com/dotnet/configureawait-faq
2. Если асинхронные вызовы внутри метода поддерживают CancellationToken — обязательно добавляйте
, CancellationToken cancellationToken = default
последним параметром метода и передавайте его внутрь этих методов.
3. Для асинхронных методов интерфейсов всегда указывайте
, CancellationToken cancellationToken = default
как последний параметр.
4. При отмене с помощью CancellationToken ловить исключение отмены нужно с помощью OperationCanceledException — это базовый класс для всех исключений после отмены.
5. Если нужно добавить тайм-аут или отмену, используйте CancellationTokenSource в дополнение к уже переданному токену-аргументу с помощью такого кода:
using var registration = cancellationToken.Register(() => cancellationTokenSource.Cancel());
Этот код также отменит регистрацию после вызова Dispose()
6. В сложных асинхронных классах имеет смысл добавлять реализацию
IAsyncDisposable.DisposeAsync()
, если нужно что-то ждать для очищения ресурсов.
Использование возможно с помощью конструкции await using вместо обычного using.
await using var registration = cancellationTokenSource.Token.Register(() => completionSource.TrySetCanceled());
Откройте для себя Fody с плагином ConfigureAwait, который делает всё это автоматом в готовой сборке, без мусора в коде. В чём смысл заниматься обезьяньим трудом, да ещё и заставлять заниматься обезьяньим трудом себя и других с помощью инструментов?
Думаю, что если у вас есть желание написать подобную статью, то не стоит себя останавливать. Я показал свои варианты реализации хранения деревьев в БД, а вы покажите свои. Соглашусь, что ORM Hibernate не идеальный фреймворк для работы с деревьями, но и реляционные БД тоже не заточены для работы с ними. Одна из причин использования нативных SQL запросов - это ограниченные и не всегда эффективные возможности самого ORM Hibernate. К примеру на данный момент Hibernate не генерирует рекурсивные запросы, а также этот запрос пока нельзя сделать с помощью JPQL. Если полагаться только на средства\возможности Hibernate, то при обходе дерева (Adjacency List) фреймворк сгенерирует множество SQL запросов, когда можно было бы решить эту задачу одним рекурсивным запросом. К тому же, я не вижу каких-либо проблем в использовании нативных SQL запросов, так как этот язык стандартизирован и если придерживаться ANSI стандарта, то не будет проблем с переносимостью в будущем, если возникнет необходимость поменять РСУБД. Полагаться же безукоризненно на ORM фреймворк и не использовать SQL - это тоже не саммый лудший подход, так как фреймворки тоже не идеальны. В статье, я приводил SQL запросы и они местами получились громоздкими, так как я старался сделать так, чтоб произвести операцию (получение потомков, получение родителей, добавления узла и т.д) над деревом минимальным числом запросов в БД и при этом подсчитывать ещё и уровень вложенности. Если громоздкие запросы разбить и обернуть в функции PostgreSQL, то естественно читабельность кода улучшиться, но я не старался привязыватся только к конкретной БД PostgreSQL, поэтому и представил всё SQL запросами. Чиатель же может взять SQL запрос и в зависимости от БД обернуть в функцию PostgreSQL или хранимую процедуру Sybase ASE или же оставить в ввиде именнованого SQL запроса, как в статье. Не отрицаю, что при детальном просмотре запросов, возможно где-то можно сделать улучшения, повысить читабельность. В целом же не вижу каких-либо препятствий или ограничений, если будет несколько статей на подобную тематику. Возможно ваши варианты реализации будут лучше. К тому же, всегда хорошо, если есть несколько вариантов решений подобных задач, будет из чего выбрать:).
Самое обычное выделение памяти под динамический массив в C++. Объявляется указатель на участок памяти, где будет располагаться массив не указателей, а целочисленных значений. В данном случае, конечно, new использовать было совсем не обязательно, т.к. размер необходимого массива нам заранее известен (в данном случае ваш пример с кодом приведен корректно). Но это никак не зависит от того глобальная переменная или локальная. Зависит от того, известна нам размерность или нет.
new говорит о выделении динамической памяти, а это всегда только куча, если не применены оптимизации компилятора. Указатели тут не при чем.
Кэш != стек. Помещение данных в стек не гарантирует его кэширование процессором.
В данном случае векторизовывать нечего, т.к. представленный в тесте цикл не параллелится.
Проблема системная и она обычно в головах, а не в компьютерах. Подобные вопросы - отдельный рынок консалтинговых услуг. И рынок этот только растёт. До тех пор пока:
заказывают одни, а работают другие (большие боссы пишут требования от лица пользователя для системы и процесса, в котором они не работали)
платят за красиво (вот деньги и сделайте мне хорошо, я сам не хочу это понимать)
от разработчиков ожидают внедрения (вот вы систему сделали, теперь сделайте чтоб все ей пользовались)
сделай новое по старому (like for like легаси системы, подражание оффлайновым процессам)
мы платим - вы танцуете (нам всё равно какие бизнес и технические проблемы - клиент всегда прав, так что делайте облако на моём заводе и чтоб ключ от сервера был у меня)
левая голова не знает что делает правая (начальники отделов ведут конкурирующую или параллельную политику)
То цирк будет продолжаться. Потому как система - инструмент и не более. Вместо молотка всем выдали шуроповёрт и всё те же гвозди - прироста производительности или уменьшения усталости работника ждать не стоит.
Рассказывать про Entity Framework, и ни разу не упомянуть про миграции и code-first подход - очень странно для туториала. Также при вставке кода рекомендуется выбирать язык для подсветки синтаксиса.
Зачем пересказывать в очередной раз то, что уже отлично расписано на docs.microsoft.com, в частности:
Туториал по blazor
Туториал по Entity Framework Core
P.S. Немного саморекламы. Собрал в одном месте материалы для обучения C# и ASP.NET Core с сопутстсвующими темами: https://github.com/navferty/dotnet-learning
Ален Голуб "Веревка достаточной длины, чтобы выстрелить себе в ногу" - концептуальная книга не только о С++, содержит глубокие мысли о программировании в общем.
Шень. "Программирование - теоремы и задачи", 1995. Краткое и в тоже время интенсивное введение в алгоритмы. Почти все книги уже выкинул и раздал, эту оставил.
Вообще, список можно накидать на пару страниц. Хороших книг очень много.
«Совершенный код» Макконела;
«Чистый код»/«Чистая архитектура» дядюшки Боба;
«Код. Тайный язык информатики» Петцольда.
Ну и подборка по тестированию от меня:
Деконструкция TDD
Фрактальное тестирование
Концепции автоматического тестирования
Заблуждения об автоматическом тестировании
Круто, спасибо.
Много лет занимаюсь с картами. OSM + Leaflet + Chromium пока что лучшая связка которую можно вменяемо использовать. Гугл мапс платный же с некоторого времени. Для OSM нужен свой сервер конечно-же (для некоторых сценариев), но и возможностей больше в разы.
flibusta.is/b/616837
переведена, издана, и уже (бесплатно) доступна…
я еще в свое время угорал по «Добыче» — книге про историю нефтяной отрасли
У нас работает много лет и трафик там иногда тысячи событий в секунду на машинах с десятками ядер.
Это если вам надо проблему решить, а не архитектурно что-то менять =)
Сегодня утром, просматривая почту, я обнаружил ваше письмо, уведомлявшее о невозможности приема меня на работу в вашу компанию.
Я внимательно изучил ваш ответ и с сожалением должен сообщить, что в настоящее время не имею возможности принять ваш отказ. В течение последних месяцев мною было получено множество отказов в трудоустройстве, поэтому, как вы понимаете, у меня имеется широкий выбор, но удовлетворить их все я, к сожалению, не могу.
Несмотря на ваши квалификацию и богатый опыт в области отбора персонала, я вынужден констатировать, что данный отказ слабо аргументирован и противоречит моим интересам, кроме того, никоим образом не соответствует моим планам на ближайшее будущее.
Исходя из вышеизложенного, я считаю необходимым приступить к своим обязанностям в вашей компании, начиная со следующей недели.
Побег был единственным способом эмиграции из СССР. И не нам осуждать Беленко, что он его использовал.
А не ваши ли родители в 90-е работали за 50$?
А не от ваших ли дедушек и бабушек всю жизнь воняло навозом и прокисшим молоком?
Если надо будет — будете работать инженерами за кусок маргарина и пачку сахара…
Смешные такие… Вы лучше радуйтесь!
1. Отличный FAQ по ConfigureAwait — devblogs.microsoft.com/dotnet/configureawait-faq
2. Если асинхронные вызовы внутри метода поддерживают CancellationToken — обязательно добавляйте последним параметром метода и передавайте его внутрь этих методов.
3. Для асинхронных методов интерфейсов всегда указывайте как последний параметр.
4. При отмене с помощью CancellationToken ловить исключение отмены нужно с помощью OperationCanceledException — это базовый класс для всех исключений после отмены.
5. Если нужно добавить тайм-аут или отмену, используйте CancellationTokenSource в дополнение к уже переданному токену-аргументу с помощью такого кода:
Этот код также отменит регистрацию после вызова Dispose()
6. В сложных асинхронных классах имеет смысл добавлять реализацию , если нужно что-то ждать для очищения ресурсов.
Использование возможно с помощью конструкции await using вместо обычного using.
Откройте для себя Fody с плагином ConfigureAwait, который делает всё это автоматом в готовой сборке, без мусора в коде. В чём смысл заниматься обезьяньим трудом, да ещё и заставлять заниматься обезьяньим трудом себя и других с помощью инструментов?