int Points[2][10]; //Объявляем в глобальной области.//---------------------//цикл по точкам для вычесления расстояний между ними:
//---------------------
for(int i = 0; i < 9; i++)
{
int x_dist = Points[0][i + 1] - Points[0][i];
int y_dist = Points[1][i + 1] - Points[1][i];
}
//--------------------------
我以为即使是少量的点，这也是很明显的。如果有成千上万的人，而且他们组成了更复杂的形状，那么优势将更大。
你已经展示了编写数据和处理数据的 "句法技术"。这些是技术，而不是OOP的概念。在简单的问题中，用数组工作比从每个结构和类中掏出实体更方便，不清楚为什么要把它们塞进解决方案中。
有这样一个概念：机制效率。
简单任务中的OOP会降低效率和可读性。你需要一把锤子来敲打钉子，如果它有一个带打孔计数器和测力计的显示屏，这并不重要。
你已经展示了编写数据和处理数据的 "句法技术"。这些是技术，而不是OOP的概念。在简单的任务中，用数组工作比从每个结构和类中建立实体更方便，不清楚为什么把它们塞进解决方案中。
有这样一个概念：机制效率。
简单任务中的OOP会降低效率和可读性。敲打钉子，你需要一把锤子，如果它有一个带打孔计数器和测力计的显示屏，那也没有关系。
在我的例子中，可读性要好得多，效率也一样好。
我不知道 "OOP概念 "是什么。
我是一个程序员，不是一个哲学家。
在我的例子中，可读性要好得多，效率也一样好。
我不知道OOP的概念是什么。
我是一个程序员，不是一个哲学家。
将OOP语法技术转移到小问题上，会在解决方案中产生不必要的实体。
首先，你必须学会如何用最少的语法和 "客观性 "做出高效的解决方案。看一下与颜色有关的算法。 那里没有任何多余的东西。裸露的机制。就是说，锤子和钉子。当事情变得更加复杂时，就转向 "对象"、"类 "的概念...
这就是我想做的。但是，我不会妨碍你的工作。
将OOP语法技术转移到小问题上，会在解决方案中产生不必要的实体。
首先，你必须学会如何用最少的语法和 "客观性 "做出高效的解决方案。看一下与颜色有关的算法。那里没有任何多余的东西。裸露的机制。就是说，锤子和钉子。当事情变得更加复杂时，就转向 "对象"、"类 "的概念...
这就是我想做的。但是，我不会妨碍你的工作。
在这个问题上，我要求的是具体的例子，而不是抽象的推理。POINT 结构对你做了什么？
你也没有打扰到我。这条线也是为了你。
它能改变什么吗？
语法发生变化。
obj.val=1；或obj.val(1)。
反之亦然。
x=obj.val；或者x=obj.val()。
语法发生变化。
obj.val=1；或obj.val(1)。
反之亦然。
x=obj.val；或者x=obj.val()。
我与那些知道如何不失礼的人交流。
然后你就可以离开了。
我与那些知道如何不失礼的人交流。
而你，出去吧。
你太过分了，是吗？
是的......成员们真的不喜欢被浸泡在他们自己的废话中。
基本上没有。
事情是这样的：他们也喜欢互相舔。
--
现在，想象一下，如果我说的是关于获取者和设定者的那些东西......。
--
Koldun Zloy，将话题改名为 "小学生LLC from schoolboy"。
在这个问题上，我要求的是具体的例子，而不是抽象的推理。你对POINT 结构的问题是什么？
你也没有打扰到我。这条线也是为了你。
好了，让我们继续讨论代码。
为它设定的任务是什么？- 存储点的坐标。为了什么？- 为了快速访问。
如果任务只是为了快速访问数据，那么POINT 结构及其实例在解决方案中是不必要的实体。看看通过矩阵的访问是多么容易。
你说你不是哲学家，但 "结构 "是一个哲学概念，它在解决方案中的存在必须有理由。
好了，让我们继续讨论代码。
其目的是什么？- 为了方便地存储点的坐标。为了什么？- 对于快速访问。
如果任务只是为了快速访问数据，那么POINT结构及其实例在解决方案中是不必要的实体。 看看通过矩阵的访问是多么容易。
你说你不是哲学家，但 "结构 "是一个哲学概念，它在解决方案中的存在必须有理由。
这只是不方便 - 你需要知道哪个元素有x，哪个元素有y。然而，当使用该结构时，一切都很清楚，它消除了错误，减少了代码量。
现在想象一下，如果我给出了那个关于获取者和设定者的废话。
什么是胡言乱语？打开getter 的定义并 阅读。
一种特殊的方法来检索直接限制的数据