Re: [boost] [GSOC] proposal for Trie

Subject: Re: [boost] [GSOC] proposal for Trie
From: Hardy (hzithlony_at_[hidden])
Date: 2013-04-23 08:03:32

On 2013/4/23 16:52, Antony Polukhin wrote:
> 2013/4/23 Michael Marcin <mike.marcin_at_[hidden]>:
>> On 4/23/2013 1:37 AM, Antony Polukhin wrote:
>>>
>>>
>>> May be I'm missing something
>>
>>
>> Unfortunately I feel the same.
>>
>>
>>>
>>> But when we have access to internals it is a totally different situation:
>>> * If we develop a non-intrusive container, we are free to split its
>>> implementation to resource management and intrusive logic.
>>
>>
>> By doing this split aren't you making an intrusive container and then
>> layering the resource management ontop of it exactly as I suggested?
>>
>>
>>> * If we develop an intrusive container - we need to add resource
>>> management to make a non-intrusive container.
>>>
>>
>> Isn't this the same thing?
>>
>>
>>> In both situations we achieve same results - we have intrusive and
>>> non-intrusive containers.
>>>
>>> So it works both ways *when we have access to internals* .
>>>
>>
>> Right if you have a non-intrusive container and access to the source code
>> you can, most likely, refactor it to be an intrusive container but I don't
>> see how that is comparable to being able to layer an non-intrusive interface
>> over top an intrusive container without changing the implementation.
>>
>> To put it another way if there was only intrusive_trie in boost. And a boost
>> user using boost burned to a cd (read-only) she should be able to make trie
>> in user code by writing a simple non-intrusive adapter.
>>
>> If there was only trie in boost in the same scenario she would not be able
>> to make use of boost trie to implement intrusive_trie in user code short of
>> copy-paste-modify.
>
> Now I get it...
>
> I was talking about intrusive/non-intusive with full access to sources
> (in my head Boosters were doing one container from another), you were
> talking about user that has no access to internals of implementation.
>
>  From your point of view intrusive containers provide better code
> reuse, from my point of view Boosters/GSOC will do both
> implementations and there is no big difference from where to start.
>
> Using your point of view: Code reuse is times better, but users
> (including me) are usually lazy and more of them will prefer to work
> with non-intrusive container, which makes intrusive less popular.
>
> --
> Best regards,
> Antony Polukhin
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

Your discussion above help me understand the design of libraries better, 
but meanwhile I am a little confused about how I can give a good 
addition to my proposal as your early advice -
"A good addition to proposal will be some sketch of trie interface:
methods and constructors that Trie class will contain."
Could you give me some examples or more advices on that?
What I think out now are something like STL set, map, and with some 
specific methods and variables of Trie.