Pull to refresh
-3
0
Send message

Знание структур и академических алгоритмов безусловно необходимо, но вторично для инженера. Тем более, что в реальной работе, базовые структуры и алгоритмы не используются в чистом виде, а покрыты толстым слоем оберток и фреймворков фирменного изготовления. А вот знание паттернов программирования и понимание условий их примененимости — это ежедневная рутина, которая нужна как для чтения чужого кода, так и для разработки собственного. Однако на собеседовании разыскивают людей, которые, по всей видимости, каждый рабочий день будут писать по хешсету, а не бизнеслогику приложения. По большому счету ни одно собеседование не проверяет знания, которые нужны именно для работы инженером, но проверяют чисто академические сведения. Углубляться на собеседовании в дебри их устройства — пустая трата времени обеих сторон.

У вас фигурные скобки не сбалансированы.

В данном конкретном случае все решается ленивыми свойствами.


class Document : virtual public Object
{
    shared_ptr<Node> m_root;
public:
    virtual ~Document()
    {}
    Document()
    {
        m_root = make_shared<Node>(dynamic_pointer_cast<Document>(shared_from_this()));
    }
    shared_ptr<Node> GetRoot()
    {
        if (!m_root)
        {
            m_root = make_shared<Node>(dynamic_pointer_cast<Document>(shared_from_this()));
        }
        return m_root;
    }
};

Но, понятно, что это не панацея.

Не до конца понятно чем не подошел std::make_shared. Он как раз и предназначен для локализации памяти control block с памятью объекта. Ну и проблемы его тоже известны — пока хоть одна слабая ссылка будет удерживаться, вся память под объект и control block не вернется в систему.

Стоит на $20k дороже. Запас хода на 25% меньше. Цена электроэнергии вообще не приведен, хотя может для теслы есть дотации. Экономия топлива окупится за ± 5 лет. Ну такое.

Как курсовая — отлично, как способ разобраться в clang — великолепно, как штука для практического применения — ненужно.
Попробую конструктивно покритиковать.
1) время компиляции увеличивается кратно.
2) код раздувается, его оптимизация ломается.
3) время выполнения кода увеличивается (об этом упомянуто).
4) ошибки будут найдены либо случайно (если дойдет ветвление, если подберутся условия ub), либо их нужно искать целенаправлено (читай — писать тесты). Т.е. добавление проверок никак не помогает обнаружить ошибку, но помогает ее быстрее локализовать в ходе случайного или целенаправленого возникновения.
5) согласно описанию, анализ и птсинг кода слишком примитивен. Для большинства мест в коде, можно доказать отсутствие ub, но, похоже, алгоритм все равно вставит патч. Например, for(auto i = 0; i < array.size(); i++) array[I];

Хотя у кутешников опять какое-то раздвоение личности. То говорили, что прекратят разработку в 2019 (https://www.qt.io/blog/2018/10/29/deprecation-of-qbs), теперь оказывается, что все-таки поддерживают до сих пор (https://download.qt.io/official_releases/qbs/1.17.0/). В общем непонятно и стремно.

Qbs уже давно не поддерживается. Нет смысла смотреть.

Самое лучшее сжатие без потерь обеспечивает magnet ссылка.

Было бы максимально полезно иметь возможность группировать команды, хотя бы с глубиной 2. Сейчас, если команд больше пары десятков, плоский список уже трудно использовать.
Можно было бы в секции profiles добавить groups, а в в командах из list добавить идентификатор группы, к которой она принадлежит.

Что-то вроде
    "profiles":
    {
        "list":
        [
            {
                "commandline": E:\\Tool_1.exe",
                "guid": "{e78112e0-d63c-4dcf-b2b5-35824a9192d9}",
                "groupid": "{0969C231-5C29-4642-ABB7-BFA10B462587}",
                "name": "Tool 1"
            }
        ],
        "groups":
        [
            {
                "name": "Stuff",
                "guid": "{0969C231-5C29-4642-ABB7-BFA10B462587}",
            }
        ]
    }
2

Information

Rating
Does not participate
Registered
Activity