From -3935301781540257431 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,94e9c2bbb0060b48 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-06 08:35:08 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: wlandry@ucsd.edu (Walter Landry) Newsgroups: comp.std.c++ Subject: Re: Proposals for small vectors? Date: Fri, 6 Sep 2002 15:35:07 +0000 (UTC) Organization: Univ of Calif San Diego Lines: 47 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <87n0qvc1xp.fsf@grue.ucsd.edu> References: <87d6rxwoti.fsf@grue.ucsd.edu> <3D7300EE.8030504@animats.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: mail2news.demon.co.uk 1031326507 1839 10.0.0.1 (6 Sep 2002 15:35:07 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 6 Sep 2002 15:35:07 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 17nL8U-0000TL-00 for mail2news@news.news.demon.net; Fri, 06 Sep 2002 15:35:06 +0000 X-Received: by mulga.cs.mu.OZ.AU id BAA19311; Sat, 7 Sep 2002 01:34:26 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Fri, 6 Sep 2002 02:00:18 +0000 (UTC) X-User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.std.c++:13649 John Nagle writes: > Yes. My point was not that I wanted to change the meaning of > operations. It's that I wanted the ability to change the > underlying representation easily to match lower-level APIs. > Users of these objects don't see the underlying representation > unless they explicitly ask for it. Well, I've updated my tensor library so that Tensor2's (matrices, for those who don't think in terms of tensors) can have the storage order optionally specified. It was a lot easier than I initially feared. > I'm also trying not to get sucked into the "POD" morass. > My general position is that these small matrix/vector objects > need not be PODs, but should, on request, return a pointer to > a POD. Think of how STL "string" offers a ".data()" member > function, which returns a C string. Agreed. To get the pointer to the data, you just do &v(0) for Tensor1's (vectors), and &m(0,0) for Tensor2's (matrices). > (For example, I have an application which has a graphics > API, an interface to an animation system, a collision detection > system, a convex hull system, and a physics system, all of which > have incompatible representations for small vectors and matrices. > This is all too common in game, animation, and simulation work.) Would the tensor library be useful for you, or does the extra complication seem like too much overhead? I'm still trying to get a feel for whether it is useful to pursue it as a standard. I haven't gotten a lot of good feedback. No bad feedback, just no "This is great and solves all of my problems" kind of feedback. If the graphics people are not happy with it, then it probably doesn't have a chance of getting standardized. By the way, does anyone know whether this sort of thing is standardized for Java or C#? Thanks, Walter Landry wlandry@ucsd.edu --- [ 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 ]