one_eight_seven

В данном случае не поможет. Да, вынесен за область while'а. Время "жизни" k и sender_iterator - разное. Поэтому, печать происходит в разных дельта-циклах. k обрабатывается за время своей жизни, и печатается, sender_iterator - за время своей. Стоит перенести `wait fork` в ту же область видимости, где этот fork порождается, и всё заработает иначе, так, как ожидается (и, кстати, одинаково для automatic и не automatic). Могу быстро накидать тест и показать это. Пожалуй, объясню подробнее и пошагово. Симулятор входит в forever, обнуляет sender_iterator, в цикле while спавнит два процесса, инкрементирует sender_iterator, и так делает пока sender_iterator не достигнет количества транзакций, выходит из цикла while, и исполняет наспавленные процессы, но в каждом процессе - своя переменна k, но общая sender_iterator, уже достигшая максимума. Если что-то недостаточно доступно объяснил, прошу, скажите.

Потому что у вас какой-то омск с fork'ами. Попробуйте хорошенько проработать функционал таска. Пока выглядит, что вы пытаетесь вместо продумывания решения задачи добиться результата героической отладкой. Не должно помочь. Хотя, дейтвительно, непонятно, ради чего автоматики.

Они там с самого начала Они и так нормальные. т.е. импульсы - это событие строго синхронное?

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

Вам не понравится. Это только движок с cli интерфейсом. Т.е. всё текстом на языке spice.

оупенсорсный ngspice Российский - симика. Сам не пользовал, коллеги не пользовали, ничего сказать по поводу его качества/доступности не могу.

Если бесплатно, то и LTSpice, и TinaTI вполне работают. Если не ограничиваетесь бесплатностью - Synopsys'овский hspice (очень дорогой и сейчас недоступный) вроде как является золотым стандартом. Для силовых цепей возможно, вообще отойти от SPICE и смотреть посмотреть на SIMPLIS.

Где вы в git увидели клиент-серверную модель? или cd - это сервер смены директории? mkdir - сервер создания директории? Ну и ещё раз, неспособность создать нормальный инструмент для своего сервиса не говорит, что такой сервис - нормальный или даже хотя бы рабочий. Понятно, что сам гит (не сервер, а просто программа, просто СКВшка) перед пушем проверяет состояние удалённого репозитория, и если удалённого репозитория ещё нет, то ничего не выйдет. Ну так об этом и речь, это ненужный продукт. Эту особенность нужно переработать, что и сделано в ОБЫЧНЫХ гит серверах, таких, как gitlab, github, ну или если вы ненавидите деньги и любите баги, то можно и от атлассиана что-нибудь посмотреть. Ну так и кто сказал, что тривиальнейший пример из scm-book - это достаточное решение? Это же просто костыль, как обеспечить синхронизацию репозиториев с центральным доступом с помощью единственного нерутового пользователя git. А git-shell - это не для того, чтобы хоть что-то работало, это для того, чтобы убрать интерактивный shell; Т.е. чтобы пользователи не могли сами создавать/удалять что-либо. Другими словами - это вообще к git и работе с git'ом отношения не имеет. Это способ оградить доступ через SSH (кстати, ssh, в отличие от git - это сервер). Ну и, продолжая разговор, gitflic окостылили же свой сервер дальше, позволив создание репозиториев кликами мышкой, сумели же. Почему через командную строку не смогли?

А что такое обычный гит сервер? Просто гит? Так там и авторизации нет, и пользователей в смысле разграничения прав доступа, в том числе и рута. А обсуждается замена гитхабу, гитлабу и возможность переноса туда уже имеющихся репозиториев.

На всякий случай скриптик "невозможного" $ git remote add newpushrepo [email protected]:my_account/delete-this-repo.git $ git push newpushrepo --all Enumerating objects: 18, done. Counting objects: 100% (18/18), done. Delta compression using up to 8 threads Compressing objects: 100% (18/18), done. Writing objects: 100% (18/18), 2.98 KiB | 2.98 MiB/s, done. Total 18 (delta 7), reused 0 (delta 0), pack-reused 0 remote: remote: remote: The private project my_account/delete-this-repo was successfully created. remote: remote: To configure the remote, run: remote: git remote add origin [email protected]:my_account/delete-this-repo.git remote: remote: To view the project, visit: remote: https://gitlab.com/my_account/delete-this-repo remote: remote: remote: To gitlab.com:my_account/delete-this-repo.git * [new branch] master -> master Это кому вопрос?

Чего? Вы может сначала попробуете что-то сделать, прежде чем охинею писать?

Ну, вот как-то так: $ git remote -v gitflic [email protected]:my_account/my-repo.git (fetch) gitflic [email protected]:my_account/my-repo.git (push) gitlab [email protected]:my_account/my-repo.git (fetch) gitlab [email protected]:my_account/my-repo.git (push) $ git push gitflic master fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $ git push gitlab Everything up-to-date А вот так получается работать, если создать репозиторий кликая мышкой: $ git clone [email protected]:my_account/test-to-delete.git Cloning into 'test-to-delete'... warning: You appear to have cloned an empty repository. Т.е. с ключами всё в порядке. Но пациент серьёзно болен.

Ну, например, процесс регистрации. Следующее - создание репозитория через пуш не работает. Просто не работает и все. Понятно, что можно все решить через жеппу. Но в этом случае отсутствие гитфлика даже лучше, чем его наличие

Да, спасибо. О нем Я и написал, что проблемы с ним прямо со старта. И классика - ноль документации.

Я же не совсем Уга-Буга. Я прекрасно знаю, как работают СКВ. Вопрос был про то, есть ли наша альтернатива гитхабам и гитлабам.

А куда? Я попробовал, в качестве эксперимента, gitflic, который вроде как отечественный. Так на него нельзя запушить уже имеющийся репозиторий. Только новые там создавать. Понятно, что не беда, и так можно сделать. Но опыт говорит, что если проблемы - с самого начала, с самой базовой работы, то ничего хорошего и дальше не будет.

Это если вы распечатываете код на бумаге. На компьютере поиск выполняется иначе.

Ну, работать всё-равно остаются те, кто способен понять: "если со скобками работает правильно, а без скобок - ошибки, то лучше Я сам буду ставить скобки всегда",- и это не под страхом увольнения. Кроме того, если из этого кода убрать скобки, он не перестанет быть хернёй, а вот работать будет уже по-другому. И то, что вы этого не видите - это печально. Вы прямо как Мамаду и Таня - Азов не знаете, при всём своём опыте. Ну и та [censored], которую вы написали может быть сделана более читаемой таким непостижимым для вас инструментом, как форматирование.

Вот, бл... ЧЁ! Прямо в стандарте же описано. Даже ссылку ведь дал. Но читать нынче умеют, видимо, не только лишь все. Вот здесь: А иначе оно будет помещено либо в .bss, либо в .data и будет инициализировано. Но, думаю, вы уже из ответов других товарищей это прочитали.

Конструкторы будут. aligned_storage - это класс, динамический объект, создаётся с помощью new, уничтожается delete'ом. Это не декларируется стандартом. В стандарте дан тривильный пример реализации (https://en.cppreference.com/w/cpp/types/aligned_storage), в нём неинициализированность обеспечивается тем, что место для буфера выделяется на куче. Но вы раньше писали, что никаких динамических выделений памяти не приемлете, поэтому, тривиальная реализация не подойдёт, и нужно смотреть реализацию в конкретном компиляторе.

Ой ли? Вы видели эти наши российские IP? Их поддержку? Конфигурируемость, и самое важное - наличие VIP, и соответствие стандартам? Это большей частью поделка, частично соответствующая стандарту, который разработчики даже единожды не удосужились прочитать полностью, и решившие, что если скомпилировалось, то всё непременно правильно. Система патентов давно дискредитировала себя. Имеющие деньги и влияние патентуют умножение в столбик, прямоугольники, перелистывание страниц. У меня была идея запатентовать всего 10 цифр, пару алфавитов и колесо... Может быть стоит?

Если вы чего-то не понимаете, это не значит, что это невозможно. А если это важно только в младшем бите, при этом, любой из старших должен запустить ветку else? Вы в мире не один. Более того, вы не один даже в команде разработчиков, если хотя бы более-менее большой проект. Если разработчик не может работать в команде и принять её правила, пусть поищет применение своему говнокоду в другом месте, зачем мучаться? Причём, и ему, и людям. Естественно, с операцией '&' это невозможно, но есть '^' (тоже побитовая). Но историческую суть я выше изложил. В тот исторический момент добавили логические операции ||, &&, но в языках, применявшихся до этого, не было таких операций, а были операции &, |, и их прецедентность оставили прежней. Никто бы не пострадал, если бы приоритет побитовых операций был выше, чем операций сравнения. Но историческая ситуация пятьдесят лет назад была другой.

Переформулируйте. Вообще непонятно, что вы сказать хотели. Вот если бы я не находил ошибки в прецедентности операций, я бы не требовал скобки. Потому что если код работает правильно, то вообще нет разницы, как он написан. А если неправильно, то разница есть. Как заставил ставить скобки, ошибки с прецедентностью прекратились. И чьи-то терзания по поводу "не слишком красивого кода", сопровождаются просьбой писать заявление по собственному желанию. Да, про C. И что? Именно в Си делают ошибки с прецедентностью операций. И именно в Си скобки решают эти проблемы.

Глупость несусветная. Вы никогда не работали в коллективах с длинной цепочкой, верно? В разных языках приоритеты операций разные. И, если вы производите что-то посложнее драйвера светодиодов, то лучше думать над решением задачи в проблемной области, а не над приоритетами операций. Более того, ваш код могут пользовать люди, которые пишут, например, на SystemVerilog или Python. И у них от зубов отлетает совем другая прецедентность операций. Опять глупость. Есть возможности форматирования для группировки. Есть возможность применения промежуточных переменных, которые ещё и покажут смысл промежуточных вычислений (а очень часто этот смысл есть). Ну и сли шком длинные выражения, которые не читаемы со скобками являются нечитаемыми и без скобок, но, кроме того, они ещё и не показывают, что именно программист хотел сделать.

Нет. Первое не ошибочно, и второе - не корректно. Вы упускаете то, что в них никак не выражено намерение разработчика, а оно выражается однозначно именно скобками, вне зависимости от приоритета операций. Я от своих ребят всегда требую ставить скобки, спрашивая: "Как мне узнать, что именно ты тут хотел сделать? Как проверить, ты правильно скобки опустил или ошибочно?"