将静态二维数组的行分配给另一个数组的行
这是我到目前为止所得到的:
typedef const float Chord[6];
static Chord progressionOne[] = {
{5.0f / 6.0f, 1.0, 1.25, 5.0f / 3.0f, 2.0, 2.5}, // i
{5.0f / 6.0f, 2.0f / 3.0f, 1.0, 4.0f / 3.0f, 5.0f / 3.0f, 2.0}, // VI
{0.75, 1.0, 1.25, 1.5, 2.0, 2.5}, // III
{1.125, 1.5, 1.875, 2.25, 3.0, 3.75} // VII
};
static Chord progressionTwo[] = {
progressionOne + 1, //VI
progressionOne + 3, //VII
progressionOne + 0, // i
progressionOne + 0,
};
这似乎是我在几轮调整我的符号、交换星号和调整 typedef 的过程中能得到的最接近的结果。我想要的(希望在上下文中很清楚)是重新排列 progressionTwo
的行,产生 progressionTwo
。我不介意数据重复或繁琐的符号——我只是想DRY 足以避免输入两次实际值。
...我真的需要抽出时间来阅读标准:/
Here's what I have so far:
typedef const float Chord[6];
static Chord progressionOne[] = {
{5.0f / 6.0f, 1.0, 1.25, 5.0f / 3.0f, 2.0, 2.5}, // i
{5.0f / 6.0f, 2.0f / 3.0f, 1.0, 4.0f / 3.0f, 5.0f / 3.0f, 2.0}, // VI
{0.75, 1.0, 1.25, 1.5, 2.0, 2.5}, // III
{1.125, 1.5, 1.875, 2.25, 3.0, 3.75} // VII
};
static Chord progressionTwo[] = {
progressionOne + 1, //VI
progressionOne + 3, //VII
progressionOne + 0, // i
progressionOne + 0,
};
This seems to be the closest I can get in several rounds of massaging my notation, swapping around asterisks and adjusting the typedef. What I want, which is hopefully clear in context, is to rearrange progressionTwo
's rows, yielding progressionTwo
. I don't mind data duplication or hairy notation--I'd just like to be DRY enough to avoid typing the actual values twice.
...I really need to get around to reading the standard :/
如果您确实希望这些是简单的数组,您可以简单地为和弦创建#define 宏(预处理器定义),并使进行引用这些和弦:
预处理器定义很混乱,尽管。
如果将 Chord 转换为成熟的类,则可以以相同的方式将它们定义为局部变量或静态变量,但具有更高的类型安全性和灵活性。然后,您可以引用
progressionOne
,同时按照您想要的方式定义progressionTwo
(至少可以使用局部变量。使用全局变量,您可能会遇到 "静态订单初始化惨败")If you really want these to be simple arrays, you could simply create
#define
macros (pre-processor definitions) for the chords, and make the progressions reference those chords:Pre-processor definitions are are messy, though.
If you turn
Chord
into a full-blown class, you can define them as locals or static variables in the same way, but with more type safety, and more flexibility. Then you could referenceprogressionOne
while definingprogressionTwo
the way that you want (at least you can with locals. With globals, you might run into a "static order initialization fiasco")