Jump to content

    

one_eight_seven

Участник
  • Content Count

    1027
  • Joined

  • Last visited

Everything posted by one_eight_seven


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

    Нет. Там вы делаете модель изделия. А адвокат этот - просто кульман, в котором создатели даже не смогли сами для себя решить, где масштаб задавать. Если хочется именно автокадом обмазаться - то лучше библии ничего не встречал, но с тех пор, когда мне приходилось этим мучиться лет 6 уже прошло, сейчас может и получше есть. http://www.ellenfinkelstein.com/events/autocad-bible-companion-website-downloads.html
  3. Диаграмм Гантта много, например, planner с открытым кодом. А вот учёт времени - это сложнее. Redmine - точно можно настроить, но это нужно поддерживать сервер. Если не хочется возиться с администрированием, то битрикс, планфикс - недороги.
  4. у вас не объявлен reg_upload_data_o Он виден только внутри module_top. Но если вы создадите wire [7:0] upload_data, и подключите его к выходам модулей, то получите другую ошибку - соединение двух выходов.
  5. Ну, тогда стоит ждать c++20, там обещают возможность использования виртуальных методов в качестве constexpr. Правда, это всё-равно может потребовать явного указания размера для правильной работы, но можно будет создать ссылку на объект внутри класса без явного указания размера. В том смысле, что для инициализации массива array<typename T, size_t S>, размер S всё-равно нужно будет указывать в явной форме, и автоматически он не вычислится (как и сейчас). А без явного указания std::size() и sizeof() с таким массивом работать не будут. Значит, нужен или терминатор, или какая-то структура, где данные о размере структуры будут храниться внутри объекта, а заполняться автоматически эта структура не может - нужен какой-то метод, который работает только в рантайме.
  6. Here you go: Если вам не нужен произвольный доступ (метод access в базовом классе в примере), то можно использовать std::set, вместо std::map, тем более, я не интересовался насколько быстрым будет этот самый произвольный доступ. P.S. И без указателей, которые тут почему-то не любят, что странно, ведь "под капотом" у всех этих контейнеров - всё-равно указатели.
  7. Тогда тем более непонятно, что даёт список. Никакой же пользы, кроме вреда. P.S. Если вы не хотите в явной форме задавать размер массива, а хотите, чтобы он определялся автоматически, то есть такая вещь, как нуль-терминированный массив.
  8. Вы понимаете, что сложность доступа к драйверу будет в случае списка O(N) вместо O(1) в случае массива? А плюсы списка - динамическая сущность и удобство переупорядочивания вы не будете использовать? Или вам это и не нужно?
  9. Если взять ссылку с хабры, то там, буквально разворот того, что у меня свёрнуто в цикл, никто не мешает его развернуть и сделать индивидуальные присваивания (более того, скорее всего у вас так и было бы). И вы поймите, то, что я показываю - это тоже псевдокод. Просто тип данных выбран - инт, и способ объединить инт - массив. Собственно, что бы вы не использовали, для вызова одинакового метода всех экзепляров в массиве/списке/кортеже, будет одно и то же - итеративный проход по этой структуре данных и вызов требуемого вам метода, либо без использования итератора - прямое обращение к элементам структуры данных, если это возможно (в случае списка - это невозможно). А "красиво" - это прилагательное. Для каждого оно своё.
  10. Так замените тип. А массив и указатель - это одно и то же. От этого в рамках C++ не уйти. Вопрос в том, что если размер члена класса заранее неизвестен, то данный код не соберётся, поскольку невозможно создать экземпляр класса. И все размеры должны быть известны на момент инстанциирования.
  11. Компилятор не будет рассчитывать, более того, код типа: type * m_array[] -- это, на самом деле type* m_array[0];
  12. #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; }
  13. Прочитал. Массив родительского класса изменяется в дочернем. Размер определён и соберётся во время компиляции. Если в конструктор добавить инициализацию полей - тоже будет сделано компилятором. Никакого динамического создания. Всё по ТЗ. Показать по-другому? Его нет в базовом. Он у вас появляется в дочернем.
  14. В коде же работает. Написано же just for lulz. для тех, кто не понимает, что массив, объявленный в базовом классе - это тот же массив, что и в наследующем. Собственно, это и демонстрируется. Если хочется другого и без "не надо говорить очевидные вещи", так прекращайте говорить на омском языке, и излагайте мысли на русском. Топикстартеру: Если размер массива заранее неизвестен, то в базовом классе можно объявить два виртуальных (можно и чистых виртуальных) метода - взятия массива и его размера. И эти методы переопределить в наследующих классах (их можно сделать хоть публичными, хоть защищёнными, хоть приватными). А сам массив объявлять и определять в дочерних. Или с VMT тоже не хочется связываться?
  15. #include <iostream> class Base { public: Base() {} ~Base() {} void * m_array[13]; }; class Derived : public Base { public: Derived() {} ~Derived() {} /* Just for lulz */ void ** get_base_array_pointer (void) { return Base::m_array; } void ** get_derived_array_pointer (void) { return this->m_array; } }; int main(){ Derived tst_obj; std::cout << "Derived class array pointer address (via access) is:" << std::hex << size_t(tst_obj.m_array) << std::endl; std::cout << "Derived class array pointer address (via method) is:" << std::hex << size_t(tst_obj.get_base_array_pointer()) << std::endl; std::cout << "Base class array pointer address (via method) is:" << std::hex << size_t(tst_obj.get_derived_array_pointer()) << std::endl; Base * p = &tst_obj; p->m_array[12] = NULL; std::cout << "element is is:" << std::hex << size_t(tst_obj.m_array[12]) << std::endl; tst_obj.m_array[12] = (void*)42; std::cout << "element is is:" << std::hex << size_t(p->m_array[12]) << std::endl; } Результат: $ g++ tst.cpp $ ./a.out Derived class array pointer address (via access) is:7ffef69e5680 Derived class array pointer address (via method) is:7ffef69e5680 Base class array pointer address (via method) is:7ffef69e5680 element is is:0 element is is:2a Вызов приложения после компиляции пропал. Его съел элемент форума Code.
  16. Его нельзя перегружать. Перегружаются методы. Данные можно изменять, инициализировать и т.п. И это можно сделать в наследующем классе. P.S. а даст это доступ к массиву извне объектов (Внутри объектов этот доступ и так уже есть безо всяких дополнительных указателей)
  17. ага. и int - тоже. Господи... Go get some education. массив в базовом классе.
  18. Так сделайте его public. или просто любовь к тривиальным методам? Первый пост:
  19. Но списки - крайне неудачный тип данных для создания во время компиляции. А кто-нибудь может мне объяснить, зачем сложности с указателем на массив? Наследующий класс - это унаследованные члены наследуемого класса плюс собственные. При этом доступ к членам при публичном наследовании имеется к public и protected членам. То есть, конструктор для базового класса создаёт массив из базового класса наряду с другими членами базового класса, а конструктор наследующего - создаёт члены наследущего, он не создаёт новый массив, унаследованный из базового. Это один и тот же массив.
  20. А не в советских? Смотрели что-нибудь в ISO, ANSI, IEEE, или, может быть в российских ГОСТах? Сейчас ещё же есть набор гостов с электронной моделью устройства - может там что-то есть? Я спрашиваю, потому что сам не искал, а если это есть, учесть уже сделанный материал - было бы неплохо.
  21. Катушка управления и замыкаемые (размыкаемые) контакты могут быть отдельно изображены на схеме.
  22. Вложенные if'ы - это тоже сущность плодящая ошибки и ухудшающая читаемость. Выше уже не один раз написали, что в примере код читаемый.
  23. Ну так попробуйте синтезировать эти два варианта и сравните. Как по мне, так не стоит тащить методики из гвидопыха, который настолько медленный, что в нём не имеет смысла бороться за производительность, в RTL, где коммутатор вставленный вместо пары AND-OR'ов прекрасно улучшит читаемость за счёт времени пропагации.