Перейти к содержанию
    

one_eight_seven

Участник*
  • Постов

    1 610
  • Зарегистрирован

  • Посещение

  • Победитель дней

    1

one_eight_seven стал победителем дня 12 марта

one_eight_seven имел наиболее популярный контент!

Репутация

3 Обычный

3 Подписчика

Информация о one_eight_seven

  • Звание
    Профессионал
    Профессионал
  • День рождения 11.11.1983

Контакты

  • Сайт
    Array

Информация

  • Город
    Array

Посетители профиля

11 032 просмотра профиля
  1. Да всем можно. Код так более читаем для большинства людей. Плюс не надо думать и запоминать правила - всегда пишешь одинаково, и думаешь о том, как правильнее назвать. Если занимаешься интересными вещами, то заниматься подсчётом строк, вспоминать как по разному оформлять одинаковые по своей сути сущности - отвлекает. Поэтому, в библиотеках, да и во многих программах просто пользуются минимальным набором правил. по оформлению. Типа всё константное - ALL_CAPS_SNAKE (и-то не обязательно), всё остальное - lower_case_snake, или вообще всё - lower_case_snake Код может быть написан читаемым и в lower_case и в CamelCase, в стиле кодирования важнее другие вещи - правильное именование, объединение того, что должно быть объединено, и разделение разных сущностей по естественным границам, малые методы, делающие одно действие, понятно и явно написанные; комментарии, описывающие намерение или предупреждающие о чём-либо, а не реализацию (будто реализацию из кода не видно)
  2. Это вы не поняли, что буковка e перед eEN1 или eEN2 - вообще ничего не поменяет. Более того, вы и читать не умеете. Я же сказал, компилятор - выругается, программист увидит, и поправит: test.cpp: In function ‘int main()’: test.cpp:12:13: error: ‘EN0’ was not declared in this scope 12 | int i = EN0; | ^~~ test.cpp:12:13: note: suggested alternatives: test.cpp:8:5: note: ‘B::EN0’ 8 | EN0, EN1 | ^~~ test.cpp:4:5: note: ‘A::EN0’ 4 | EN0, EN1 | ^~~ avi@mob:~/test$ Ещё раз призываю эволюционировать, сначала самому попробовать что-то сделать, а не постить влажные фантазии с апломбом гуру.
  3. И в чём проблема? компилятор это найдёт и сообщит, программист поправит. И дальше в коде будет всё ещё понятнее. Мы же не станем всерьёз обсуждать ситуацию, где надо читать и поддерживать код, который не то, что не работает - даже не компилируется!
  4. А зачем их отличать? Что то - константа, что другое. Вам - нет. Человеку, который будет этот код открывать - да. А не надо сразу понимать насколько она тривиальная и из чего она состоит. Важно - что она делает, и как ей пользоваться. Если инженер занимается поддержкой кода, то ему важно - как легко её найти, и да - ему будет важно знать, что внутри. Так он пойдёт в реализацию. Если ему надо использовать - то он посмотрит в API. А тут для человека в теме - rx_lane_injector - что-то инжектирует в RX Lane. Смотрит какой тип - понятно, что инжектирует пакеты. Английским по белому же написано. Уже понятно для чего это нужно. Ну и раз оно что-то делает, то это явно класс - есть же поведение. Но если надо узнать API, или поддерживать - то в определение - а там видно, что это класс, и видно, что это UVM компонент. Те, кто занимается верификацией из этого уже много чего вынесут - это основная библиотека. Это как вам std::string - уже всё понятно, и что нужно, и какие методы есть, и как этим пользоваться.
  5. класс и структура - это одно и то же. enum - ALL_CAPS. по хорошему, нет никакой разницы, что перед глазами - класс, юнион, енум, если им даны правильные названия, из которых понятно за что они отвечают и что они делают. А если нужны подробности - то всё-равно пойдёшь в объявление, а там, например: ethernet_channel_packet_injector rx_lane_injector; вроде уже понятнее. Если нужно ещё конкретику, тогда идёшь в определение, а там и вовсе нет сомнений class ethernet_packet_injector: public uvm::uvm_component { ... }
  6. А почему бы ему ментор переименовывать в PCB? У ментора основной набор продкутов был куда шире. Целый набор продуктов Questa, Catapult, Tessent, Calibre, конечно же. И все они не имеют ничего общего с PCB. А вот Mentor Graphics на Siemens - вполне себе поменяли.
  7. Через systemc. А systemc - через uvmc к любому симулятору, ну или можно через вендорозависимые TLI или UVM-ML.
  8. Пустые места OpenOCD по умолчанию тоже пропускает, если брать elf в качестве источника. Но именно пустые области памяти, а не те, которые заполнены единицами намеренно - в коде. А переписывать только несовпадающие места - это зависит от того, написано это в драйвере флэш памяти в OpenOCD, например, я, когда писал драйвера всегда делал так, чтобы пользователи всегда использоовали полное стирание памяти при прошивке, и очень часто заказчикам этого хватало, и они после не улучшали. Хотя, я не щупал самую последнюю версию OpenOCD, поэтому со 100% вероятностью утверждать не буду, может там есть уже более аккуратная версия работы с flash, но скорее всего до сих пор так, как я описываю.
  9. Да. В OpenOCD есть команда verify_image, по результатам которой можно определить, требуется ли прошивка.
  10. Можно обойтись и без компиляции в отдельную библиотеку, а скомпилировать в work. Вопрос в том, что скомпилирован пакет долен быть раньше, чем файл, в который он импортируется. А компиляция пакета не отличается от любой другой компиляции. Компилятору должно быть известно, где найти все файлы, необходимые для текущей компиляции.
  11. Если правильно помню, то "безопасность" Rust - это решение гонок при доступе к памяти. То, что в C++ тоже уже давно решённая проблема, но не средсствами языка, а архитектурно. В C++ это вообще проблема только для программистов с низкой квалификацией, которые даже не знают, что такая проблема была, и что решение - уже давно есть. Ещё пара вещей, которую решает rust - это использование после освобождения и переполнение буфера. В C++ тоже решается с помощью fortify и санитайзерами. Никакого волшебства.
  12. Как правило, все вендоры у меня нормально конвертировали, если схема проходит xml lint. Могло не хватать каких-то полей. И даже баги находили, которые вендор потом правил. Но на моей памяти, проблема была не в cadence, а в инженерах, которые не умеют читать.
  13. со стандартом 89 года. Си после этого тоже развивался, и уже со стандарта С99 не является подмножеством C++. Некоторые модные языки столько даже несуществуют.
  14. А я не правильно вопрос понял. Посмотрите в сторону SystemRDL. Обычно генераторы понимают также и CSV, только нужны определённые поля.
×
×
  • Создать...