Re: [Toon-members] Re: STL containers with TooN

[E. Rosten]

On Wed, 13 Jan 2010, Gerhard Reitmayr wrote:

> > just from reading docs, one needs default, copy constructors and assignment to 
> > work. that makes sense for example with the following code:
> >
> > vector<Vector<Dynamic> > v(10); // 10 dynamic vectors
> > v[0] = Vector<Dynamic>(10);     // set first to a vector with 10 els
> > v[1] = Vector<Dynamic>(20);     // set second to a vector with 20 els
> >
> > Resizable makes sense, i guess that assignment on a Resizable should always 
> > work (and resize as necessary)

Ok. Presumably then it should also resize on assignment from a sized 
operator, eg:

Vector<Resizable> v;
v = Zeros(10);
v = Zeros(20);


> > For Dynamic, how about making it stateful and have the default constructor set 
> > a sentinel that allows it to be resized with the first assignment ? (and 
> > assert, if it is assigned from another Dynamic in the same state )? a copy 
> > constructor or explicit size constructor will not allow further resizing, 
> > similarly after the first resize. that way the code above would work and one 
> > would still have the same runtime safety...
>
>
> just got bitten again by the missing default constructor for Vector<Dynamic>. 
> How about the above suggestion ? this we could have them default constructed and 
> fixed on first assignment ?

That could work. Either my_data could be NULL or my_size equal to 0 or 
something. Of course, then they have to be non-const. I don't know if that 
matters much. I suspect not.

By the way, this would of course mean there will be an extra if in each 
assignment from vectors or operators.

I implemented such a system for Vector<Resizable> which I subsequently 
removed.

cvs up -D 20090926

should get you there. Each allocator implements a try_resize() member. 
This may do nothing (for static and Dynamic), or it may do something 9for 
Resizable). This member is called at the beginning of operator=. Then the 
size checks occur. This system could be reinstated so that try_resize 
works first time on Vector<Dynamic> and is a noop all other times.


However, STL vector can call operator=

#include <vector>
#include <iostream>
using namespace std;

struct Foo
{
        Foo()
        {}

        Foo(const Foo&)
        {
                cout << "copy\n";
        }

        Foo& operator=(const Foo&)
        {
                cout << "assign\n";
                return *this;
        }
};


int main()
{
        vector<Foo> v(3);
        cout << "Erase\n";
        v.erase(v.begin());
}


prints out:
copy
copy
copy
Erase
assign
assign

If Vector<Resizable> supported resize on assignment as it used to, then I 
think it would be OK to use in a std::vector.

-Ed


> cheers,
>  Gerhard
>
> > cheers,
> >  Gerhard
> >
> > > Thoughts, anyone?
> > >
> > > -Ed
> > >
> > >
> > >
> > > > Thanks!
> > > >
> > > > Am 10.01.2010 um 21:37 schrieb Gabriel Nützi:
> > > >
> > > > > Hello again
> > > > > Sorry for my questions, but I am using TooN permanently, with all its 
> > > > > advantages... (LU,SymEigen....)
> > > > > I was wondering, because I need a container which is as fallowing
> > > > > list < Vector<Dynamic,double> >   myList;
> > > > > Why does it give RunTime problems and segmentation errors when I try to use the 
> > > > > list by inserting and deleting Vectors, it happens also when the Vector is not 
> > > > > dynamic ...
> > > > > Is there any troubles with the containers and TooN?
> > > > > This crashed in Runtime:
> > > > > //===================================
> > > > > list < Vector<Dynamic,double> >   myList;
> > > > > myList.push_back( makeVector (1,1,1) );
> > > > > myList.push_back( makeVector (2,1,1) );
> > > > > myList.push_back( makeVector (3,1,1) );
> > > > > list < Vector<Dynamic,double> > ::iterator it;
> > > > > it = myList.begin();
> > > > > it++;
> > > > > myList.erase(it);
> > > > > //=================================
> > > > > Thanks a lot
> > > > > Gabriel!
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Toon-members mailing list
> > > > address@hidden
> > > > http://lists.nongnu.org/mailman/listinfo/toon-members
> > >
> > > --
> > > (You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)
> > >
> > > /d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
> > > r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
> > >   d f pop 235 420 translate 0 0 moveto 1 2 scale show 
> > > showpage_______________________________________________
> > > Toon-members mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/toon-members
>
> --
> Gerhard Reitmayr
> Institute for Computer Graphics and Vision
> http://www.icg.tugraz.at/Members/gerhard
> tel: ++43 316 873 5082
>
>
>
>
>
> _______________________________________________
> Toon-members mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/toon-members

--
(You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)

/d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
    d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage