树的缺点之一了，空间利用率低下，只是我这个将这一缺点发挥到了一个极点。

要空间还是时间，很难有两全的办法。

我想想先，这话题以后再说。

[此贴子已经被作者于2017-6-4 14:50编辑过]

慢慢来呗，反正是临时想到的，不着急，先一点点完成基础。优化什么的，想到灵感了，再来也不迟，这些东西也急不来。

我读取了一个639kb的文本文档，内存占用是3780。
而我用记事本打开同一个文本文档，内存占用是2320。
内存占用似乎并没有想象中的那么多。

[此贴子已经被作者于2017-6-4 17:39编辑过]

删除很简单啊，不需要删除链接，只需要free掉值域就可以了。

唯一我还没想到的东西就是怎么删除掉整颗树。

效率非常不错的，我读取600+kb的文本，瞬间完成并且输出有序的单词，当然，我忘记用别的结构测试了，是否别的结构也能这样快（我用我的那个链表测试，会有大概1秒的卡顿，然后才完成输出）。

在初期，链接占用的确很大，但是当插入的数据多了之后，链接占用就比较少了。

可惜数据还是太小了，更大的英语文本还真不好找。

[此贴子已经被作者于2017-6-4 18:48编辑过]

当然知道啊，但是没有深究（以后再去了解这个，先专注眼前的东西），我看的书里面，森林也仅仅是作为一个定义出现。

你说的一棵树的值是另一棵树，这很容易实现，但问题在于应用在什么地方呢？

减少1级搜索的时间没有什么意义，毕竟就26个字母，无论什么结构，都能飞一般的完成。
减少二级搜索的时间才是关键。

因此树套树，同样会面临空间浪费，只是很少而已，只比链表多一个指针。

其实，为什么不链表套树，或者更直接的数组套树。

是哦，我那个链表，为社么不用数组呢？我傻。。。。。。。。。。。。。

[此贴子已经被作者于2017-6-4 19:28编辑过]

我说的很容易实现，意思是，只要写一个接口和实现，就可以直接调用，用这一套函数完成所有操作。
就像我那个链表一样。
唯一需要处理的只有一些细节而已。

我的意思是用数组做索引。
数组的每一个元素都是一个对应首字母的树。