Mail Archives: djgpp/1998/01/13/20:16:47
HI Johannes,
Before I will try to say something useful about your questions I want
to propose some sort of mailing list of djgpp STL questions on which
implementors and users(like me and you) meet in an attempt to
understand and enhance djgpp STL. Reasons is that documentation
on this part for djgpp is not totally up to date, that STL is not the
easiest part for programmers, and that maybe djgpp STL has some
limitations/specifics/bugs too. I don't know how to do it, but
something like a mailing list seems a nice start maybe..??
unjl AT ab251 DOT rz DOT uni-karlsruhe DOT de (Johannes Dieterich) wrote:
>I've experienced several problems using the C++-Containers as described in
>the book of Stroustrup with DJGPP.
>1. stack<custom datatype> doesn't work. Is this a bug ? Or am I doing
> something wrong ?
No. stack<vector<custom>> or stack<list<custom>> or
stack<deque<custom>> however does work. Although. I got always
errors on stack<deque<whatever>>. But they are probably mine;-(
But as said, stack<vector/list<custom>> works.
>2. vector<T>::resize(n) is missing. This is crucial if you want to use vectors
> as multidimensional arrays.
Why is that ? I thought that the vector would be automatically
resized when needed..? Can you give an example ??
>3. list<T>::find(k) is missing. I wrote a specialized function myself by
> now. Am I allowed to alter the DJGPP libraries ? (legal stuff)
Shouldn't that be a simple one to include in the list header ??
Although. When I come to think about it: find is a GENERIC ALGORITHM.
Meaning is IMHO that it should not be tight to any container, but
instead can be implied to array's lists vectors deques strings equally
alike...Then it is impossible to dissolve find(5) because there is no
way the function does know on which container to find!
Of course you COULD make some header listfind or even containerfind,
which include both iterator.h and all container vectors, which will
refer to find as a member(much like the stringclass does).
Any way there is no need to change the lib.
>4. list<T>::clear() ist missing. Well, erase(begin(),end()) is a
> workaround...
Same as above for generalizability.
kludge of including a member clear(), like void list<T>::clear().
to work this way:
Just below erase(ifdef GNU) added void clear(){erase(begin(),end()}
Just below else(not GNU)added void clear(); and added the same
function as above below the definition of erase later on.
That was it. Although probably this thing should be done by one of
the original implementors.( like the find, find_if things).
>Aren't these functions (at least draft-) standard ? I've found them in the
>ANSI/C++ - workingpaper...
>Is there a patch to include the missing features? I'd appreciate any help.
>Thanx
>Joe
>--
>Johannes Dieterich *** eMail unjl AT rz DOT uni-karlsruhe DOT de
Probably there are some really difficult design things involved
in excluding a few members, but I can't see which ones..
STL comes from generic algorithms. Thats why often begin and end
iterators are given to the algorithms. I view that as some sort of
pay-off for the generic nature.
Rick
- Raw text -