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

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

但是~

Root->Word==NULL也是占用一个节点啊~

其实Root->Word可以理解成是由一个一个节点的关键字凑合起来的单词~

abc占用3个节点
abd和abc一起占用4个节点~
不过如果用位数组记录判断单词是否存在以及具体信息

abc和abd一起也是占用3个节点~~~

忘记提及一点了~

struct s
{
    struct* s[26];
    char v[4];//v表示位数组--0代表该位没有单词~1代表有--4个字节刚好相当于1个char*指针大小~
}node;

还可以优化成
struct s
{
    struct** s;
    char v[4];//v表示位数组--0代表该位没有单词~1代表有--4个字节刚好相当于1个char*指针大小~
}node;

struct** s; 这里可以根据有没有后缀来判断是否开辟空间~

如果该单词没有后缀就没必要再开辟空间了(当然这样结构比较复杂~维护难度上升)~


这样输入

abc
abd
就只占用两个节点+一个没有分配索引空间的节点了~

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

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

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

这个问题我也想想先~
感觉能优化的除了能在最后一层尽量节省空间外在遍历链中间优化难度比较大了~

当然如果真的修改结构还是可以优化的~
不过……除了要考虑空间和时间复杂度外~还需要考虑算法复杂度以及维护复杂度~那些以后再说吧~
感觉楼主的程序不深究细节方面的话……已经可以了~~~

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

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

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

空间过得去就好~想了一下~发现这效率还是不错的~每个节点输出是108个字节(如果你没有改结构的话)~这空间开销还可以~

接下来试试完成字典树的删除操作~

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

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

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

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

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

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

其实关键在于随机查找的平均速度有巨大的优势~free掉整棵树也是用递归遍历的形式啊~和Print函数的结构差不多~
我也设想到一种AVL树或者红黑树结构储存关键字~用逐字二分法查找~不过那树有三个节点~中间节点为下一级查找~旋转当普通二叉树处理就可以了~那个可以最大限度节约空间~当然这只是设想~现阶段不打算弄出来了~