Re: [Libclc-developers] An alternative clc_list approach + an iterator.

[Hallvard B F. <h.b...@us...>]

Bj=F8rn Augestad writes:
>Hallvard B Furuseth wrote:
>>=20
>> clc_stl.h says:
>>=20
>>   typedef struct clc_list_tag* clc_list;
>>   typedef struct clc_iterator_tag* clc_iterator;
>>=20
>> I think typedefs to pointers like this is a bad idea.
>> (...) I'd rather see
>>=20
>>   typedef struct clc_list_tag     clc_list;
>>   typedef struct clc_iterator_tag clc_iterator;
>>=20
>> (...)
>=20
> Thanks for the feedback. The general concensus on c.l.c seems to be that=
=20
> it's OK to typedef the pointer if no struct members are available=20
> outside the implementation.

That's not what c.l.c said last time.  They said one should normally not
typedef a struct at all, but it's OK if no struct members are available
outside the implementation.  While typedefs to pointers are evil.  See:

http://groups.google.com/groups?selm=3Dnewscache%2405mrbh%24jt1%241%40tomat=
o.pcug.org.au
http://groups.google.com/groups?selm=3Db553pt%245f8%241%40sunnews.cern.ch

> That's my opinion as well.
>=20
> We can compromise by dropping the _tag suffix,
> 	typedef struct foo* foo;

Absolutely not!  If we have a struct tag and a typedef with the same
name, they should be the same type.

> How about the iterator concept? Do you think it can be applied to all
> the containers we want to add?

Personally I expect I'll think it's overkill, but let me look at the
actual containers and their built-in ways to iterate first...

> Performance issues?

That's another thing, yes.  A built-in list walker need only take the
previous object as an argument and return the next, or vice versa.

> Will it be too complex to use for beginners?

Don't think so.

> Does the design easily create mem leaks?

Maybe.  It would be safer with
  struct clc_iterator iter;
  clc_iterator_init(&iter, ...);
because then many iterators would not need to be freed at all.

--=20
Hallvard