RE: [Vxl-maintainers] Inexpensive vnl_vector_fixed

[Andrew F. <aw...@ro...>]

PS:

The sizeofs for that code were 8,12,12  (gcc on x86)

The cost is probably the same because n() was evaluated outside
the loop -- can they do that?

Can others check on their machines?

> -----Original Message-----
> From: vxl...@li... 
> [mailto:vxl...@li...] On 
> Behalf Of Ian Scott
> Sent: 01 October 2002 12:10
> To: 'Amitha Perera'
> Cc: Vxl-maintainers (E-mail)
> Subject: RE: [Vxl-maintainers] Inexpensive vnl_vector_fixed
> 
> 
> 
> 
> > The question: is it okay to increase the size of vnl_vector by
> > sizeof(bool) in order to reduce the size of vnl_vector_fixed by
> > sizeof(int)+sizeof(data*)? (Actually, this may only be necessary for
> > certain broken compilers, which includes gcc.)
> 
> We would prefer not. There are packing/alignment problems. 
> sizeof(bool) = 1
> on VC++. We accept that from a global point of view the cost is more
> bearable by users such as ourselves who most use large variable length
> vectors - That doesn't mean we like it :(
> 
> >
> > At the recent VXL meeting in Providence, we agreed that I and Brad
> > King from Kitware will consult and try to come with a strategy to
> > elimate the extra 8 bytes of storage currently required by
> > vnl_vector_fixed. (See a previous message to this list by 
> Bill Hoffman
> > from Kitware.)
> >
> > In my preparations for our (Brad and I) meeting tomorrow, I 
> have found
> > that it may be necessary to increase the size of vnl_vector 
> (dynamic)
> > by sizeof(bool) if we are to avoid code-rewrites.
> >
> > I am jumping the gun here, and asking the question before 
> Brad has had
> > a chance to air his solutions. My reason is that an answer to this
> > question will help Brad and I choose the best alternatives for
> > decoupling vnl_vector and vnl_vector_fixed.
> >
> > For those interested, the code below illustrates a "free" way of
> > decoupling vnl_vector_fixed and vnl_vector. "Free" in that 
> conversion
> > from vnl_vector_fixed to vnl_vector happens via a cheap
> > vnl_vector_ref.
> >
> > ----code----
> > #include <iostream>
> >
> > class Vec
> > {
> > public:
> >   Vec( int ) { std::cout << "Vec(int) constructor\n"; }
> >   Vec( const Vec& ) { std::cout << "Vec(const Vec&) copy
> > constructor\n"; }
> >   virtual ~Vec() { };
> > };
> 
> Note this isn't anymore free that the extra bool. The virtual function
> pointer table will take up space (possible more than the 
> bool). I should
> point out that a solution using virtual destructor and resize 
> looks a lot
> easier to understand (i.e. better) than one involving bool.
> 
> 
> >
> > class VecRef : public Vec
> > {
> > public:
> >   VecRef( double ) : Vec(1) { std::cout << "VecRef(double)
> > constructor\n"; }
> >   VecRef( const VecRef& ) : Vec(0) { std::cout <<
> > "VecRef(const VecRef&) copy constructor\n"; }
> > };
> >
> > class VecFixed
> > {
> > public:
> >   VecFixed() { std::cout << "VecFixed() default constructor\n"; }
> >   VecFixed( const VecFixed& ) { std::cout << "VecFixed(const
> > VecFixed&) copy constructor\n"; }
> >   operator const VecRef() { std::cout << "Vec::const VecRef()
> > conversion\n"; return VecRef(1.0); }
> > };
> >
> > int main()
> > {
> >   VecFixed a;
> >   const Vec& ref = a;
> >
> >   return 0;
> > }
> > ----code----
> >
> > The expected result is that "a" will be converted to a 
> VecRef and that
> > will be bound to the Vec& reference. I believe this is what the
> > standard says should happen. Indeed, with MIPSpro 7.3 and 
> Sun Workshop
> > 5.0, the output is
> >
> >   VecFixed() default constructor
> >   Vec::const VecRef() conversion
> >   Vec(int) constructor
> >   VecRef(double) constructor
> >
> > Unfortunately, the output from gcc 2.95.3 and 3.0.4 is
> >
> >   VecFixed() default constructor
> >   Vec::const VecRef() conversion
> >   Vec(int) constructor
> >   VecRef(double) constructor
> >   Vec(const Vec&) copy constructor   (***)
> 
> ???? What ....
> Where is this last call coming from? I don't even see how a 
> slightly buggy
> compiler could invoke this call.
> 
> 
> >
> > The extra copy constructor is too expensive, since it involves a
> > malloc and a copy. I think gcc is broken, but it is nonetheless an
> > important target compiler, so we have to work around this problem.
> It is also  prblem becasue if you pass a non-const VecFixed 
> into a function
> by pointer or reference, the function wil presumably operate 
> on the copy and
> not the referenced vector data. This means that you cannot modify such
> return parameters - a massive problem.
> 
> 
> >
> > An alternative could be to have a ./configure detection of compiler
> > details, and add the extra bool cost only if the compiler cannot do
> > the above reference initialization correctly.
> 
> No....
> Think of the IO problems this would cause. I guess you could 
> use the version
> mechanism to keep the cross platform nature working. But to 
> keep vsl IO
> smooth your really need to have all compilers using the same 
> format. That
> being said I suspect that outputing a vec which was really a 
> VecRef isn't
> going to maintain correct ownership relations under any circumstances.
> 
> Ian (and Tim)
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> Linux or FreeBSD, FREE setup, FAST network. Get your own server 
> today at http://www.ServePath.com/indexfm.htm
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>