认真看了一下~似乎用用哈希这个称呼不太标准~还是叫26叉树比较生动形象~

看看我吃完饭回来修好bug没有~如果还没有我再具体看看~

PS

建议不要用new作为变量名~那是个C++的关键字~

先吃饭~

一样的嘛，new只要后缀是.c，不会造成冲突，我试过的vs没有冲突。

但Dev估计有冲突，因为曾经this这个变量名，Dev就不准我用，我靠。

BUG已经解决。但我怀疑有内存泄漏，你帮我看下吧，我下午不知道有时间没，希望下午继续下雨，好不上班。

第一个节点是哑节点正常啊~那个是总索引~内存泄露暂时没怎么发现~

PS~本来打算建立B树模型的~不过对于B树却不太熟悉~可以看看字典树~这个操作比较简单~

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

我写的这个结构，效率怎样，不知道，但好玩就够了。

http://

上网搜了一下字典树~

看到真的有写了个类似的模板~

在工作地了，我的小手机不太方便，等下班再看。

原来有人这么感了，哈哈。

还是看了下你贴的链接，他说比散列快耶，表示怀疑，不过我不懂散列，算啦，先不深究这个。

感觉你那个空间消耗还是太大了~

想到了一个改进方法~
可以缩小一个几何级别的空间开销~

还记得位数组么？~

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

这样有字母的位表示1~没有字母的位表示0~

就没有必要一个字母独立占用一个节点空间了~
相对而言~这样最后一层字母就没有必要另外再展开一层空间了~还有头节点也有利用价值了~~

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

我没用倒字母占用节点呀，每个节点都是一个完整的单词。只是现在还是初级版本。而且单词是否合法，由另外的函数检查更好。

在查找大量单词的时候的确相比散列表有优势~
因为散列表会有满表的时候~所以散列表只能在一定查询信息范围内有优势~
不过……散列表可以扩容调整……这个另外再说~~~~

这种结构的字典树相当于多个子散列表~一个散列表的关键词是另一个散列表~正应和你那贴<<链表的值是另一个链表>>~
当然还是存在空间利用率不高这个基本问题~~