one_eight_seven

Да, постоянно с этим борюсь. Почти никто не обращает внимания на такие несущественные для рабочего изделия моменты как: Питание Тактирование Сброс А потом возникают "необъяснимые проблемы, которые невозможно воспроизвести для отладки: устройство может на столе работать полгода и не заглючить, а на объекте глючит в первые же пару недель".

Конечно же вы можете поднять у себя сервер Redmine. Как и прикрутить к нему множество дополнений (если нужно)

Нет. Там вы делаете модель изделия. А адвокат этот - просто кульман, в котором создатели даже не смогли сами для себя решить, где масштаб задавать. Если хочется именно автокадом обмазаться - то лучше библии ничего не встречал, но с тех пор, когда мне приходилось этим мучиться лет 6 уже прошло, сейчас может и получше есть. http://www.ellenfinkelstein.com/events/autocad-bible-companion-website-downloads.html

Диаграмм Гантта много, например, planner с открытым кодом. А вот учёт времени - это сложнее. Redmine - точно можно настроить, но это нужно поддерживать сервер. Если не хочется возиться с администрированием, то битрикс, планфикс - недороги.

у вас не объявлен reg_upload_data_o Он виден только внутри module_top. Но если вы создадите wire [7:0] upload_data, и подключите его к выходам модулей, то получите другую ошибку - соединение двух выходов.

Ну, тогда стоит ждать c++20, там обещают возможность использования виртуальных методов в качестве constexpr. Правда, это всё-равно может потребовать явного указания размера для правильной работы, но можно будет создать ссылку на объект внутри класса без явного указания размера. В том смысле, что для инициализации массива array<typename T, size_t S>, размер S всё-равно нужно будет указывать в явной форме, и автоматически он не вычислится (как и сейчас). А без явного указания std::size() и sizeof() с таким массивом работать не будут. Значит, нужен или терминатор, или какая-то структура, где данные о размере структуры будут храниться внутри объекта, а заполняться автоматически эта структура не может - нужен какой-то метод, который работает только в рантайме.

Here you go: Если вам не нужен произвольный доступ (метод access в базовом классе в примере), то можно использовать std::set, вместо std::map, тем более, я не интересовался насколько быстрым будет этот самый произвольный доступ. P.S. И без указателей, которые тут почему-то не любят, что странно, ведь "под капотом" у всех этих контейнеров - всё-равно указатели.

В с++17, кстати, это можно сделать с помощью std::size().

Тогда тем более непонятно, что даёт список. Никакой же пользы, кроме вреда. P.S. Если вы не хотите в явной форме задавать размер массива, а хотите, чтобы он определялся автоматически, то есть такая вещь, как нуль-терминированный массив.

Вы понимаете, что сложность доступа к драйверу будет в случае списка O(N) вместо O(1) в случае массива? А плюсы списка - динамическая сущность и удобство переупорядочивания вы не будете использовать? Или вам это и не нужно?

Если взять ссылку с хабры, то там, буквально разворот того, что у меня свёрнуто в цикл, никто не мешает его развернуть и сделать индивидуальные присваивания (более того, скорее всего у вас так и было бы). И вы поймите, то, что я показываю - это тоже псевдокод. Просто тип данных выбран - инт, и способ объединить инт - массив. Собственно, что бы вы не использовали, для вызова одинакового метода всех экзепляров в массиве/списке/кортеже, будет одно и то же - итеративный проход по этой структуре данных и вызов требуемого вам метода, либо без использования итератора - прямое обращение к элементам структуры данных, если это возможно (в случае списка - это невозможно). А "красиво" - это прилагательное. Для каждого оно своё.

Так замените тип. А массив и указатель - это одно и то же. От этого в рамках C++ не уйти. Вопрос в том, что если размер члена класса заранее неизвестен, то данный код не соберётся, поскольку невозможно создать экземпляр класса. И все размеры должны быть известны на момент инстанциирования.

Компилятор не будет рассчитывать, более того, код типа: type * m_array[] -- это, на самом деле type* m_array[0];

#include <iostream> using namespace std; class Base { public: Base() {} ~Base() {} void open_all_drivers() { size_t size = get_size(); int * p = get_array(); for (size_t i = 0; i<size; ++i){ cout << dec << i << "'th element is: " << hex << p[i] << endl; } } private: virtual int * get_array() = 0; virtual int get_size() = 0; }; class Derived : public Base { public: Derived() { size_t size = get_size(); int * p = get_array(); for (size_t i = 0; i<size; ++i){ p[i] = 0x100 + i; } } ~Derived() {} private: int m_array[12]; virtual int * get_array() final { return m_array; } virtual int get_size() final { return sizeof(m_array)/sizeof(int); } }; static Derived tst; int main(){ Base * p = &tst; p->open_all_drivers(); return 0; }

Прочитал. Массив родительского класса изменяется в дочернем. Размер определён и соберётся во время компиляции. Если в конструктор добавить инициализацию полей - тоже будет сделано компилятором. Никакого динамического создания. Всё по ТЗ. Показать по-другому? Его нет в базовом. Он у вас появляется в дочернем.