Это зависит от конструкции датчика.
- если он простой, вы не отличите импульсы "вперед" от импульсов "назад"
-если в нем есть стопор, он будет игнорировать импульсы "назад"
-если в нем квадратурный энкодер, направление можно будет понять по разнице фаз.
kaw1994, Обычно приходится ставить браузер с поддержкой Java, в особо постылых случаях старых версий HP iLO, придется ставить IE старых версий с Java и дотнетом, а иногда и Flash(!) (потому что гении в HP придумали сделать админку EVA6200 на флеше, Карл!)
Короче, все зависит от парка барахла. Для мониторинга традиционно рекомендуют zabbix и grafana, но лично я пользуюсь nagios и rrdtool
2low4, Ну, тут и так и так нужны денежные вливания - или на отбойники, или на шлюз. Но отбойники - это лотерейное решение, глюки которого ушлое руководство вероятнее всего повесит персонально на вас.
В некоторых шлюзах VoIP функция переполюсовки встроенная - не ваш ли это случай?
Еще есть карточки от Digium, у них тоже есть polarity swap
Denis, зайдем с другой стороны:
Термин "виртуальная машина" применяется в двух случаях
1) Виртуальная машина некоторых языков программирования (JVM, Python, PHP) - в этих языках текст программы транслируется в байт-код, который выполняется виртуальной машиной-интерпретатором. (Тонкости про JIT-компиляцию временно отставим в сторону)
2) Виртуальная машина как способ запуска нескольких экземпляров различных операционных систем на одном железе. В таком случае, железо компьютера частично (все современные гипервизоры) или полностью (bochs, dosbox, epxe) эмулируется виртуальной машиной.
Более того, такая виртуальная машина позволяет запускать программы, написанные для других процессоров и архитектур - например, программы для Commodore64, написанные под процессор MOS6502 на Intel x86_64.
При работе же процесса в современных операционных системах происходит не виртуализация, а абстракция - программе подсовывается API, которое не имеет привязки к конкретному железу, а разработчику железа требуется со своей стороны реализовать именно это API.
Ключевое отличие абстракции от виртуализации - для реализации первой, требования API должны соблюдаться с двух сторон - как программой, так и операционной системой.
При виртуализации же мы создаем такую среду, чтобы запускаемая программа, находящаяся в ней, "думала" что находится в оригинальных для себя условиях (например, что DOOM 1993 года выпуска работает под DOS, на 486 процессоре, хотя фактически вы его запустили на процессоре ARM на андроиде с ядром Линукс). При этом, вмешательства в программу не происходит.
Денис Загаевский, у вас странное представление о процессе обучения как о чем-то одностороннем. Даже учебник матана особо одаренные студенты могут понять криво с понятным результатом в виде тройбана, это не значит, что Фихтенгольц плохой или студент плохой, просто у них взаимно не сложилось.
Но так как я не Фихтенгольц и могу вести диалог, я могу поправить вопрошающего прямо на месте.
И заодно указать ему еще раз на фундаментальный недостаток выбранного способа изучения C++:
-не следовало брать книгу именитого автора, которая с первой главы вываливает 101 способ присваивания инта
-следует начинать с реализации несложных алгоритмов и решения типовых задач для C++ - матрицу перемножить, гистограмму картинки найти, повернуть картинку на некоторый угол, а теперь через библиотеку, а теперь через OpenGL и так далее
-теоретическое вбивание в башку правил работы с указателями никак не обучает тому, как этими указателями пользоваться на деле. Это аналогично выучиванию всех правил взятия неопределенных интегралов (их примерно столько же, сколько правил для указателей), но при этом полной неспособности найти первообразную.
Игорь Журавлёв, вот почему после объяснений нужно обязательно перепроверять правильность усвоения знаний. И то и другое вы поняли неверно.
1) Про указатели. Пока вы конвертируете типы указателей между собой, у вас все хорошо и ничего не портится. Тип указателя влияет только на то, как его интерпретирует компилятор при разыменовании и на то, на сколько байт указатель будет сдвигаться при адресной арифметике с ним.
А вот как только вы начнете пытаться преобразовывать указатели во что-то кроме указателей, у вас начнутся нюансы.
Как только вы начнете пытаться менять тип объекта, путем каста указателя на объект в другой тип - у вас начнутся другие нюансы, на этот раз, с алиасингом:
float a=3.14;
uint32_t b = *reinterpret_cast(&a); /// алярм, алиасинг поехал
Поэтому тут только практика поможет, одних только теоретических знаний тут достаточно только на то, чтобы покивать, как вам все понятно. А вот решите 20-30 кейсов с указателями, напишете пару парсеров-сериализаторов бинарей - тогда и появится реальное понимание.
2) Про инкременты
a++ - работает так - вернуть значение a, сделать инкремент
++a -сделать инкремент, вернуть значение.
Никакого мухлежа с порядком выполнения операций тут нет.
Денис Загаевский, если у вас есть замечания к тексту, у вас есть два экологичных способа заявить об этом:
1) Написать свою версию ответа.
2) Конкретно указать мне на мои ошибки.
Прочие методы, вроде намеков, экивоков, тайных подмигиваний, применения риторики Сократа, я не рассматриваю как валидные способы ведения со мной диалога на профессиональную тему.
Денис Загаевский, нет, если я буду заниматься в уме синтаксическим анализом, у меня не останется ресурсов на решение реальных задач. Упражнения на поиск синтаксических ошибок без компилятора давайте оставим токсичным компаниям, офисы которых будем обходить стороной.
Извините, вы меня хотите проэкзаменовать? У меня нет желания в этом участвовать. Как правило, void* сразу после получения конвертируют в нужный тип и работают с этим типом. Например, указатель, у которого есть тип при инкременте будет смещаться на размер этого типа, что очень удобно. А еще у него будут работать квадратные скобки.
Про связь между разработчиками компилятора, которые как правило, являются и разработчиками стандартной библиотеки, можно почитать в стандарте. Там говорится, что при определенных условиях (например, непойманное исключение в деструкторе, return из main) должны быть вызваны определенные функции и описывается поведение этих функций, а реализацию предлагается написать разработчикам реализации стандартной библиотеки.
Иногда эти функции даже можно переопределить путем замены на свои - но этого в стандарте языка нет.
Это ресурс в первую очередь о программировании, не о физике. Так что вам желательно начать с проблем с кодом, а физику убрать куда подальше.
Вместо тонны физики, выложите конечное уравнение и метод, которым вы его решаете, распишите алгоритм. Код из зипуна выложите на гитхаб, а если там меньше 1к строк - прямо в вопрос.
Эталонный пример, который надо показывать разного рода директорам, которые жмут средства на строительство СКС и одобряют натыкивание 8 портовых мыльниц по углам офиса, причем иногда гирляндой.
Остается только ходить (иногда со стремянкой) и резетить хабы по очереди.
- если он простой, вы не отличите импульсы "вперед" от импульсов "назад"
-если в нем есть стопор, он будет игнорировать импульсы "назад"
-если в нем квадратурный энкодер, направление можно будет понять по разнице фаз.