From -1799043908228696261
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,94e9c2bbb0060b48
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 2002-08-12 09:44:01 PST
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail
From: schnitker@sigma-c.com (Uwe Schnitker)
Newsgroups: comp.std.c++
Subject: Re: Proposals for small vectors?
Date: Mon, 12 Aug 2002 16:43:44 GMT
Organization: http://groups.google.com/
Approved: Fergus Henderson <fjh@cs.mu.oz.au>, moderator of comp.std.c++
Message-ID: <aec458c5.0208112235.3024aa2b@posting.google.com>
References: <87wurryywb.fsf@grue.ucsd.edu> <3D38FB4F.1020909@animats.com> <877kjnpg3p.fsf@grue.ucsd.edu> <3d4f850b.146537@news.iperbole.bologna.it> <aec458c5.0208070435.473a4e80@posting.google.com> <3d538392.2753209@news.iperbole.bologna.it>
X-Trace: mail2news.demon.co.uk 1029170629 mail2news:18813 mail2news mail2news.demon.co.uk
X-Complaints-To: abuse@demon.net
X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au
X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
Delivered-To: std-c++@ncar.ucar.edu
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
NNTP-Posting-Date: 12 Aug 2002 06:35:03 GMT
Lines: 95
Xref: archiver1.google.com comp.std.c++:13209

ros0230@iperbole.bologna.it (Natale Fietta) wrote in message news:<3d538392.2753209@news.iperbole.bologna.it>...
> On Wed,  7 Aug 2002 23:07:53 GMT, schnitker@sigma-c.com (Uwe
> Schnitker) wrote:
> 
> >My question: Is it also important to you to be able to pass a lot of those
> >small matrices or vectors to a C-API which requires array-like storage? 
> 
> Often It is necessarty to be able to pass an array of valvectors to a
> C-API and often it is necessary to use array of structs containing one
> or more valvectors plus other datas (for example colors and/or texture
> informations),

Ok, you confirmed my suspicion and provided further evidence. With regard
to the rank 1 - vector - case, at least.

> in both cases i think valvectors must be POD.

Well, "must" is a strong word. If you don't care about what the C++
standard guarantees, you could use a class which is only "almost" a
POD. It is, e.g., hard to imagine why and how a C++ compiler would
change the data layout of a POD if you just add a simple constructor.
But I'd care enough not to rely on such undefined, or at best
implementation-defined, behavior.
 
> Instead it is not so common to pass arrays of matrixes, so i think
> matrixes can be non-POD (if this buy some advantage)
> with a fast member function to access the underlying representation.

Of course it does. You can use contructors. You may even design them as
base classes, or derive them from other classes. You can use "canonic" 
policies ... ...

So this would be one reason not to regard the vector case as just the 1xn
or mx1 case of the matrix.

> >I could imagine that you might have hardware specific functions, e.g. to 
> >multiply one transformation matrix with a lot of vectors.
> 
> Yes, there is a wide variety of specific hardware functions, but
> sometimes (often) they work only on specific memory, and in this case
> it is very slow to retrive results, so when results are need for
> further software processing (instead of further hardware processing)
> it is usual to transform them in software.
> 
> >Please read my other posting in this thread were I consider whether to make
> >the small matrix / vector class a POD. There I describe a usage example.
> >
> >I'd really like to know if my example is based on a realistic scenario.
> 
> Well, as i explained in previous paragraphs your example is not the
> more frequent situation i see...

OK, now I understand. I was trying to imagine whether such hardware issues
would make the C-array compatibillity even more important. But, as you 
explained above, it is important anyway. (For valvectors, not valmatrices.)

> [cut&paste from your other message]
> > Also note that I mentioned writing things like
> >   valmatrix<double,1,3> vm = {2.0,3.0,4.0};
> > which requires valmatrix<double,1,3> to be an aggregate.
> 
> I've never had the need to inizialize matrixes this way (instead it is
> important to be able to do this for vectors),

Here we have again the difference between the matrix and the vector case.
It's quite interesting. More than I'd imagined.

> in my apps tipically
> matrixes are inizialized reading from data files or using some
> function to construct the representation of a specific basic
> transformation, for example very often i do
> m.SetRotationMatrix(axis,angle) or something similar.
> 
> Regards,
> Natale Fietta
> 

Thank you. I consider using small (not val-) vectors/matrices as part of a
case study. It wouldn't really cover the topic we discussed (, it's more
about using STl with such small vectors,) but I wanted to know a bit more
about the implications of certain simple design decisions.

Hmm, the valmatrix, -vector topic would also make for a nice case study, on
a very different level. Someday ...

Thanks again,

Uwe

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]



