标准化2D/3D向量/坐标类

6

问题
这是一件困扰我已经有些时间的事情,但我无法找到一个明确的答案:

  • 是否有人知道引入标准2D和/或3D向量(具有x、y和z成员的结构)的提议?
  • 如果没有,除了自己编写一个完整且完美的提案之外,还有没有现实的方法将这样的类引入到下一个标准版本中?
  • 此外,除了没有人有时间之外,是否有任何充分的理由,为什么这件事还没有完成?

我肯定愿意做出贡献,但我相信我缺乏足够的经验来产生高质量的东西以被接受(我不是专业程序员)。

推理/背景
到目前为止,我已经看过数十个库和框架(无论是用于图形、物理、数学、导航、传感器融合...),它们基本上都会实现自己的版本

struct Vector2d {
    double x,y;
    //...
};
/* ...
 * operator overloads
 */

以及/或其3D等效物——更不用说在我实现自己的版本之前,所有场合都要实现它。显然,这并不困难,我也不担心次优的实现,但每当我想要结合两个库或重用来自另一个项目的代码时,我都必须小心地将一个版本转换为另一个版本(通过强制转换或者如果可能的话-文本替换)。

现在,委员会力图显着扩展c++17的标准库(特别是使用2D图形框架),我真的希望从一开始就将通用的2D向量嵌入到所有接口中,这样我就可以写:

drawLine(transformCoordinates(trackedObject1.estimatePos(),params), 
         transformCoordinates(trackedObject2.estimatePos(),params));

而不是
MyOwnVec2D t1{trackedObject1.estimatePosX(), trackedObject1.estPosY()};
MyOwnVec2D t2{trackedObject2.estimatePosX(), trackedObject2.estPosY()};

t1 = transformCoordinates(t1,params);
t2 = transformCoordinates(t2,params);

drawLine(t1.x,t1.y,t2.x,t2.y);

这个例子可能有点夸张,但我认为它表明了我的观点。
我知道std::valarray已经朝着正确的方向发展,因为它允许像加法和乘法这样的标准操作,但如果你只需要两个或三个坐标,它会带来太多负担。我认为一个具有固定大小且没有动态内存分配的valarray(例如基于std::array)将是一种可接受的解决方案,特别是因为它将提供一个微不足道的迭代器实现,但我个人更喜欢一个具有x、y(和z)成员的类。
备注:如果这个主题已经被讨论过了(如果没有,我会很惊讶),那么我很抱歉,但每次我搜索2d向量时,我都会得到关于std::vector>之类的结果,或者如何实现某个转换,但没有关于标准化的内容。

有没有现实的方法可以让这样一个类进入标准的下一个版本 - 除了自己撰写完整且完美的提案之外?说服其他人去做。这就是C++发展的方式。 - Bartek Banachewicz
@BartekBanachewicz:有什么提示或在哪里寻求帮助撰写建议书的建议(如果您不在软件公司工作)? - MikeMB
1
我会从阅读现有的提案开始。 - Bartek Banachewicz
2个回答

4
除了没有时间之外,是否有其他好的理由解释为什么还没有完成这项任务?
实际上没有任何理由。
创建一个包含两个或三个元素的类型是非常简单的,所有操作也可以轻松定义。此外,C++标准库并不旨在成为通用数学工具套件:如果您真的需要超出可以在半小时内组合的函数和运算符的数学类型和结构,请使用专门的第三方库。
我们不会标准化不需要标准化的东西。
如果C ++获得某种标准化的3D图形API,那么我可以看到这种情况发生变化,但在那之前不会。希望C ++永远不会获得任何类型的标准化3D图形API,因为它不是为此而设计的。
但是,如果您对此有强烈的感觉,可以在std-discussion上开始一次讨论,在那里所有专家(以及一些肯定不是专家的人)都生活;有时这样的对话会导致提案的形成,而且不一定是您最终编写提案。

如果C++能够获得某种标准化的3D图形API,那么它肯定会被通用化,以适用于您选择的坐标类型。C++只愿意为您所需的付费,而不是在每个API边界收取“税收”。 - sehe
@sehe:也许我完全没有理解你的意思,但是怎么做呢?一种实现方法使用普通数据成员,另一种使用setter和getter方法。一个可能将坐标命名为x、y、z,另一个可能为x1、x2、x3,第三个可能需要使用数组样式访问。 - MikeMB
@MikeMB 请参阅Boost Geometry设计原理,例如整个**Boost Propertymap**库。在灵活的C++ API设计中,泛化访问是一个重要工具。 - sehe
1
@Lightness 感谢您的解释和建议。我的观点是,仅仅因为某些东西容易实现,并不意味着没有一个标准化版本的价值,这个标准化版本可以被所有人使用。正如问题中所述,向量在许多不同的应用程序中使用,我认为一个标准化的向量可能会减轻来自不同库的功能组合的难度。顺便说一下,我刚刚意识到,目前的2D图形提案(N4073)有一个点类(我只看了一个旧版本)。 - MikeMB
@MikeMB 没错。我并不是在争论这个问题是否有可能被标准化。我只是在反驳你说这样做没有用的说法。(关于“如果你只想传递2-3个双精度作为参数” - 适配器/访问器层会隐藏这一点;标准API不应该犯这种接口错误:makeRect({1,13},{3,14}) 几乎和 makeRect(1,13,3,14) 一样简洁,但更加描述性。 这基本上就是算法采用迭代器而不是范围的同样问题。我们从中吸取了教训) - sehe
显示剩余2条评论

1
如果有其他人对此感兴趣,我想指出2014年7月版的"向C++添加2D图形渲染和显示的提案"包括一个2D点类/结构(我的问题基于2014年1月的初稿)。因此,可能至少会在c++1z中有一个简单的标准2D向量。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接