From -6424901617223387100 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,94e9c2bbb0060b48 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-08-02 08:51:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!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: Fri, 2 Aug 2002 15:50:02 GMT Organization: http://groups.google.com/ Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <87wurryywb.fsf@grue.ucsd.edu> <3D38FB4F.1020909@animats.com> <3D3CB3C6.20106@animats.com> <23b84d65.0207301527.38062bdd@posting.google.com> <3D475BF7.1060602@animats.com> <3D4966AD.9080709@animats.com> X-Trace: mail2news.demon.co.uk 1028303412 mail2news:16143 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) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit NNTP-Posting-Date: 2 Aug 2002 06:13:50 GMT Lines: 71 Xref: archiver1.google.com comp.std.c++:12984 John Nagle wrote in message news:<3D4966AD.9080709@animats.com>... > Uwe Schnitker wrote: > > > John Nagle wrote in message news:<3D475BF7.1060602@animats.com>... > > > To achieve this a "valmatrix" must be a POD. > > > Actually, no. "valmatrix" does not have to be > a POD. It just has to have an access function that > returns a POD with the underlying numerical data > as a dense, built-in array. Depends on what you want to do with it. I'd like to be able to write: vector vec(100); // label cvm* cvmp = (cvm*) &vec[0]; manipulate(cvmp, cvmp + vec.size()); if cvm is a struct layout-compatible with valmatrix and manipulate is a C function taking two pointers which have to delimit an array of cvm's. If valmatrix is not a POD, but allows you to get at the data in POD form, e.g. by declaring a friend function/functor makePOD, you would need a copy operation to achieve the above: // label vector cvmVec(vec.size()); transform(vec.begin(),vec.end(),cvmVec.begin(),makePOD); cvm* cvmp = &cvmVec[0]; manipulate(cvmp, cvmp + cvmVec.size()); Also note that I mentioned writing things like valmatrix vm = {2.0,3.0,4.0}; which requires valmatrix to be an aggregate. I do not claim that this usages are necessary for an effective "valmatrix" design. But if you want to support them, you need to make valmatrix a POD. To give an example: On PowerPC systems with an Altivec unit you could define a small vector to consist not of three or four doubles, but of just one xxx (I don't remember the exact name of the hardware-specific data type). Then manipulate could call one of the intrinsic functions which works on an array of xxx with fast vector processing. If this valmatrix/valvector were a POD, then you could operate directly on an array or std::vector of them both with C++ standard library algorithms and with hardware-specific intrinsic functions. Maybe it would be worth the trouble of making them POD's. Regards, 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 ]