> дело в том что по своей природе сущность "Elevator" не является "ButtonControlled"
А с точки зрения ваших Button? А зачем вы тогда Button отделили в отдельный класс? Чем они управляют?
> Иначе говоря мне интересно как бы это было реализовано средствами Java
В Java класс может реализовывать несколько интерфейсов. В данном случае ButtonControlled -- это как раз интерфейс.
> Как я понял, плюс равномерно темперированного строя - можно играть произведение на разных октавах, т.е. изменив частоты всех нот в 2 (или любую другую степень двойки) раза мы не потеряем "благозвучность".
Нет. Это свойство есть у любого строя. В равномерно темперированном можно сдвинуться на произвольное число полутонов и не потерять благозвучность.
> не было компилятора под рукой тогда. Писал с калькулятора Evsign: вот вам компилятор для калькулятора: gcc.godbolt.org
> я думал, что [][n][m] - становится частью типа
Становится частью типа, да.
> нельзя адрес типа int(*)[n][m] сохранить в указателе типа int*
Стандарты С и С++ разрешают это действие, но в обоих случаях результат -- implementation-defined. Однако, в моём примере такого сохранения нигде не происходит: я честно беру адрес объекта типа int. И наоборот, в вашем примере с приведением типа ((int*)p) это происходит.
> а разве можно так передавать многомерный массив как во-втором способе? Evsign: в памяти элементы массива лежат друг за другом, непрерывно, в порядке роста индексов: p[0][0][0], p[0][0][1], ..., p[0][0][29], p[0][1][0], p[0][1][1], ..., p[0][19][29], p[1][0][0], p[1][0][1], ..., p[9][19][29].
Т.е. при желании область памяти занятую многомерным массивом можно рассматривать как одномерный массив элементов того же типа. Индексы в таком одномерном массиве и в исхдном многомерном преобразуются друг в друга взаимно однозначно.
> я c++ учу. Там если таким образом передавать многомерный массив, то в месте вызова функции не скомпилируется (или я ошибаюсь).
Вы ошибаетесь и это было легко проверить практически. Почему вы этого не сделали?
&p[0][0][0] -- это &(p[0][0][0]) -- указатель на первый элемент массива, int *, как и ожидает функция f.
> Только если передать как (int*)p
Это, я бы сказал, "запись для продвинутых", для тех кто не путается в звёздочках и скобочках. В этой записи массив преобразуется в указатель на массив (int p[10][20][30] -> int (*p')[20][30]), который дальше приводится к типу int*. В результате -- да, получается то же самое.
> Разве не должно быть int (*p)[20][30]
В прототипе функции? Можно записать и так, но это просто другая запись первого способа.
> как это сделать
скопировать с похожей машины и поправить. Доки на beaglebone вроде открыты.
Вот тут народ пишет, что загрузили ядро на машине beaglexm, у меня, правда, этот топик вызывает определённые вопросы.
Кроме того, если всё что вам нужно работает в юзерспейсе и не лезет напрямую в железо, то вам должно быть всё равно, на какой платформе крутится ваш angstroem. Выберите какую-нибудь платформу поудобнее, соберите под неё ядро и пользуйтесь ею.
> для beagleboard.org/black ничего не подойдет из обоих qemu, на сколько я понимаю
похоже на то. Однако, базовую поддержку для машины не так сложно сделать самому.
> Значит придется искать другой способ
Я не понял, из чего это следует. Если величина задержки между записью и воспроизведением в ваших руках, можно поставить её такой, чтобы за её время набиралось сэмплов хотя бы на один период воспроизведения, а всё остальное хранить в буфере.
Я вижу тут только два варианта: либо у вас реальное время (и тогда опоздавшие данные с микрофона надо выкидывать и заполнять тишиной), либо -- нет.
И я не понимаю, что за T у вас на картинке, фактически задержка от приёма звука до отправки будет близка к длине отдного периода между playback IRQ.
> GCC не принимает объектные файлы от другой версии GCC
Это не так.
gcc сам по себе вообще с объектными файлами не работает. Он запускает ассемблер чтобы сделать объектный файл из ассемблерного и линкер чтобы слинковать несколько объектников.
> Если бы была тотальная стандартизация, компоновщик от VisualStudio мог бы съесть объектные файлы от GCC
Я не говорил о том, что стандарт один. Их несколько. gcc ориентирован на ELF. майкрософт -- на COFF.
А с точки зрения ваших Button? А зачем вы тогда Button отделили в отдельный класс? Чем они управляют?
> Иначе говоря мне интересно как бы это было реализовано средствами Java
В Java класс может реализовывать несколько интерфейсов. В данном случае ButtonControlled -- это как раз интерфейс.