In our previous episode, Florian Kl?mpfl said:
> >>> Indeed, but the additions should follow a common goal and as far as I
> >>> understood, fcl-stl shall provide opaque containers which is not the
> >>> case for a tree implementation.
> >>
> >> ? Why not ? I see no difference with a list or collec
> So: A graph is also mathematically defined. And a tree is just a
specialized graph.
Indeed :)
I just realized that if you add an already existing node to other part of my
tree such that it create a circular path, you have a graph, and both
traversal algorithm will end up in infinite loop! (well
>
> Like I said, I didn't mean to argue.
>
> For me there is no difference, but then I have no affinity with Generics.
See the link in my other mail ;)
>
> Just to say that I am not suitable to maintain fcl-stl. But someone
> should definitely take care of it.
Yes, but keeping in mind how to
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 15:37, schrieb Michael Van Canneyt:
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 15:16, schrieb Michael Van Canneyt:
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 14:47, schrieb Michael Van Canneyt:
Am 20.01.2013 15:37, schrieb Michael Van Canneyt:
>
>
> On Sun, 20 Jan 2013, Florian Klämpfl wrote:
>
>> Am 20.01.2013 15:16, schrieb Michael Van Canneyt:
>>>
>>>
>>> On Sun, 20 Jan 2013, Florian Klämpfl wrote:
>>>
Am 20.01.2013 14:47, schrieb Michael Van Canneyt:
>>>
>>> ? Why not
Hmm... I guess fcl-stl has to be renamed to fcl-gcl (generic container
library) and we could have another fcl-gdsl (generic data structure library)
for different purposes because the name standard template library used as
container only library sounds inefficient.
--
View this message in context
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 15:16, schrieb Michael Van Canneyt:
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 14:47, schrieb Michael Van Canneyt:
? Why not ? I see no difference with a list or collection ?
A tree is something implementation sp
Am 20.01.2013 15:21, schrieb leledumbo:
>> For good reasons. As said before a tree is an implementation detail.
> When having a fully implemented C++ STL one really seldomly needs an
> explicit tree implementation. Of course, there are special cases which
> are speed/memory sensitive which requi
Am 20.01.2013 15:16, schrieb Michael Van Canneyt:
>
>
> On Sun, 20 Jan 2013, Florian Klämpfl wrote:
>
>> Am 20.01.2013 14:47, schrieb Michael Van Canneyt:
>
> ? Why not ? I see no difference with a list or collection ?
A tree is something implementation specific while the fpc-s
> For good reasons. As said before a tree is an implementation detail.
When having a fully implemented C++ STL one really seldomly needs an
explicit tree implementation. Of course, there are special cases which
are speed/memory sensitive which require to implement explicitly a tree
but in this
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 14:47, schrieb Michael Van Canneyt:
? Why not ? I see no difference with a list or collection ?
A tree is something implementation specific while the fpc-stl is only
about opaque data structures. E.g. the fpc-stl supports TSet: but
Am 20.01.2013 15:03, schrieb leledumbo:
>> Where does the C++ STL expose a tree? It might be used internally by a
> map or set but I'am not aware of any tree class in the C++ STL.
>
> No, no, I was saying this data structure is even missing from C++ stl.
For good reasons. As said before a tree
> Where does the C++ STL expose a tree? It might be used internally by a
map or set but I'am not aware of any tree class in the C++ STL.
No, no, I was saying this data structure is even missing from C++ stl. In
the end, we often need to write again and again that depth first, breadth
first, iter
Am 20.01.2013 14:25, schrieb Marco van de Voort:
> In our previous episode, Michael Van Canneyt said:
No, but adding things from time to time shows it is not dead code :-)
>>>
>>> Indeed, but the additions should follow a common goal and as far as I
>>> understood, fcl-stl shall provide o
Am 20.01.2013 14:39, schrieb leledumbo:
>> Indeed, but the additions should follow a common goal and as far as I
> understood, fcl-stl shall provide opaque containers which is not the
> case for a tree implementation.
>
> I thought a better goal would be to have arbitrary data structures that's
Thanks, Michael. I haven't put the documentation though and I guess since
there are a lot of algorithms running on k-ary tree I'll add more...
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/State-of-fcl-stl-generics-lib-tp5712537p5712600.html
Sent from the Fre
Am 20.01.2013 14:47, schrieb Michael Van Canneyt:
>>>
>>> ? Why not ? I see no difference with a list or collection ?
>>
>> A tree is something implementation specific while the fpc-stl is only
>> about opaque data structures. E.g. the fpc-stl supports TSet: but the
>> whole implementation is hidde
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 14:22, schrieb Michael Van Canneyt:
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 11:15, schrieb Michael Van Canneyt:
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 06:17, schrieb leledumbo:
No one seem
> Indeed, but the additions should follow a common goal and as far as I
understood, fcl-stl shall provide opaque containers which is not the
case for a tree implementation.
I thought a better goal would be to have arbitrary data structures that's
commonly used with generic content, and tree is o
Am 20.01.2013 14:22, schrieb Michael Van Canneyt:
>
>
> On Sun, 20 Jan 2013, Florian Klämpfl wrote:
>
>> Am 20.01.2013 11:15, schrieb Michael Van Canneyt:
>>>
>>>
>>> On Sun, 20 Jan 2013, Florian Klämpfl wrote:
>>>
Am 20.01.2013 06:17, schrieb leledumbo:
> No one seems to see: http://bu
> I do see another redudancy. gset already has a red-black implementation.
(even if it is called a set)
Problem: The tree is invisible, it can't be used as a generic red-black tree
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/State-of-fcl-stl-generics-li
In our previous episode, Michael Van Canneyt said:
> >>
> >> No, but adding things from time to time shows it is not dead code :-)
> >
> > Indeed, but the additions should follow a common goal and as far as I
> > understood, fcl-stl shall provide opaque containers which is not the
> > case for a tr
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 11:15, schrieb Michael Van Canneyt:
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 06:17, schrieb leledumbo:
No one seems to see: http://bugs.freepascal.org/view.php?id=23654 :(
Well, it's a new feature: just slappin
Am 20.01.2013 11:15, schrieb Michael Van Canneyt:
>
>
> On Sun, 20 Jan 2013, Florian Klämpfl wrote:
>
>> Am 20.01.2013 06:17, schrieb leledumbo:
>>> No one seems to see: http://bugs.freepascal.org/view.php?id=23654 :(
>>>
>>
>> Well, it's a new feature: just slapping another piece of code into
>
On Sun, 20 Jan 2013, Florian Klämpfl wrote:
Am 20.01.2013 06:17, schrieb leledumbo:
No one seems to see: http://bugs.freepascal.org/view.php?id=23654 :(
Well, it's a new feature: just slapping another piece of code into
fpc-stl not improving existing stuff.
No, but adding things from tim
On Sat, 19 Jan 2013, leledumbo wrote:
No one seems to see: http://bugs.freepascal.org/view.php?id=23654 :(
As I have explained several times on the mailing lists, the core team
does not really use generics. That means that issues/bugs with generics
are given less attention than other bugs.
Am 20.01.2013 06:17, schrieb leledumbo:
> No one seems to see: http://bugs.freepascal.org/view.php?id=23654 :(
>
Well, it's a new feature: just slapping another piece of code into
fpc-stl not improving existing stuff.
___
fpc-pascal maillist - fpc-pa
No one seems to see: http://bugs.freepascal.org/view.php?id=23654 :(
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/State-of-fcl-stl-generics-lib-tp5712537p5712588.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
28 matches
Mail list logo
