[Yetanotherclib-devel] Library future.

[darek <ch...@wp...>]

Hello!!!
I was on vacation last week so I can't reply to your emails. I have some 
new ideas about future development of  library.
1. I think we should start from scratch, that is we should start writing 
everything from beginnig and try to stay close to STL as much as possible.
2. What coding conventions we should use??
I think that for containers  functions could have name:

container_method_name(container *This,/* rest of parameters */);

For example:
list_size(list *This);
list_sort(list *This);
vector_size(vector *This);
vector_begin();
etc.??
Eventually:
yacl_list_size(list *This);
but I don't know that with this coding convention(with prefix 
yacl_container) function names wouldn't be too long??
I think that this is a good idea to make typedefs to struct rather than 
writing struct word before every function parameter.
If defines is simulating containers method it still should be in low 
letters for example:
vector_size()
in future it could be implemented as inline function.
What do you think about my new ideas??
If you like it please let me know and if you don't please let me know 
why you don't like it.

3. I think we should start from implementing containers in STL:
- list,
- vector,
- deque,
- set,
- multiset,
- map,
- multimap.
- string.

I've started implementing list container, I think it will be ready till 
next month.
I think that every developer should declare what kind of  container he 
would like to implement. Please send to list
email with such declaration. The sooner we get such declarations the 
sooner work can be done. In next week
I post some code on the list so you will have better picture of my ideas.

After that we could start to implement stack, queue, priority_queue.
After that we could start to implement algorithms.

4. I like very much idea with error codes as enumerations and I think 
error codes should have prefix yacl.

5. ChangeLog also good idea, I think we should remove all logs from 
source files to ChangeLog.

6. We should rename tab.c to vector.c.

7. If  I've forgotten something or you have some other ideas about 
future development of library please let me know.

8. Every comment about portability is very welcome I know two operating 
systems(Windows and Linux various compilers on them) and I feel that
some developers are more experienced with other OSes, so let us know if 
you've found some problems(dprintf is a good example).

Best and thanks for involvment in developing library.
Darek Ostolski