准备信奥吗

【 在 il15 的大作中提到: 】
:
: 发现她们老师对数组的处理都是从下标1开始了，可能便于理解和不容易出错。
: 想想看也是个不错的方法...

#发自zSMTH@MIX 2S
--
FROM 124.64.17.*

就是有沟通成本，因为别的用C语言的都是从0开始，然后少数人是从1开始，这两拨人之间沟通会有问题。
虽然最终还是会达成一致，既然最终要统一，为啥不从一开始就统一。而且从1开始，并不能表明从1开始的这拨人跟别人相比有什么突出之处。同样，从0开始的这拨人难道思想上真有什么束缚/狭隘的，以至于不知道下标还可以是负数等等内容吗？从0开始只是C这个语言的一个约定而已。

在C语言圈子里，从1开始的这拨人，在从0开始的这波人眼里估计就是异类/业余。
不信的话，谁在自己项目/产品的C代码中写点从1开始的代码试试。

【 在 softsongs 的大作中提到: 】
: 这会不会不利于以后孩子拓展思路吧？比如更复杂的二维三维数组。毕竟要和别人合作的话，没法跟别人说我的数组第0位不用。
:
: :
: ...................
--
修改:z16166 FROM 114.245.195.*
FROM 114.245.195.*

用Matlab保平安：）
- 来自 水木社区APP v3.5.3
【 在 milksea 的大作中提到: 】
: 这是一种错误的教学倾向。更极端的是部分信息学竞赛选手还会养成分配数组总是多分配5个10个甚至100个的奇怪习惯，目的是为了防止越界，而不是自己想清楚程序下标的边界——越界访问经常伴随着算法也有问题。
:
: 如果确实非常想用从1开始的下标，还有一种办法是分配arr[n]，使用时则用ptr=arr-1来做下标访问，这样ptr的下标范围就是1到n。这个技巧来自numeric recipe，我揣测目的是为了方便匹配数学文献的公式（下标一般从1开始）。但必须指出这种技巧也是不妥的，在C/C++中是undefined bahavior，因为不能保证数组前一个元素的地址是存在的或者可访问的，尽管绝大多数情况这办法能用。
:
: 无论如何，习惯了闭开区间记法后，其实是利大于弊的。比如把n个元素的数组均分，那就是 [0,n/2) 和 [n/2,n) 两块。用双闭区间下标 1 开始就变成了 [1, n/2] 和 [n/2+1, n]。这种 +1 运算太频繁了，其实很容易出问题。数学文献中就因为用闭区间下标导致频繁出现 +1，其实是很烦的。
--
FROM 183.179.53.*

现在学到字符串了。然后发现在做一个叫“大数加减法”的题目的时候，切换到从0 开始了...
不过不知道是娃自己做的 还是我老婆帮忙的。

【 在 il15 的大作中提到: 】
: 发现她们老师对数组的处理都是从下标1开始了，可能便于理解和不容易出错。
: 想想看也是个不错的方法...
--
FROM 14.150.164.*

【 在 misslost 的大作中提到: 】
: 怎么说呢，自然界也不存在1的数字的。
: 数字本身就是符号逻辑，是抽象的产物。1，2，0都是。
: 数组从0还是1开始，本身不重要，但是，养成良好的习惯重要。习惯就是从0开始。不适应也得适应。长痛不如短痛。c语言的数组从1开始，这么教学，肯定是路有点歪，不过也不算什么大事，应该是猜想今后（也许）能改过来的吧。
: ...................
0比1、2、3要难理解，因为0没有对应的场景，而1、2、3都是有的。
计算机语言中，Pascal就很自然，它甚至不从0或者1开始，而是用户说了算，甚至不是按数字来进行数组的索引，这样或许更容易理解，也就是索引就是编号的意思。当然它也不是哈希值。
或者说，生活中更多的是枚举型。
--
FROM 106.39.151.*