Re: [boost] Geometry/Vector Lib
In-Reply-To: <45252C77.3050708@yar.nu> macke@yar.nu (Marcus Lindblom) wrote (abridged):
So, we need to support three different styles of access, at least, to make everyone happy?
- vec[0] - vec.x - vec[_x]
I won't be happy if vec.x is supported, no matter how many other styles of access we add. A class like this should not expose its representation so directly. (Not that my opinion should carry any weight; I'm just saying the conflict here is deeper than your message suggests.) -- Dave Harris, Nottingham, UK.
Dave Harris wrote:
In-Reply-To: <45252C77.3050708@yar.nu> macke@yar.nu (Marcus Lindblom) wrote (abridged):
So, we need to support three different styles of access, at least, to make everyone happy?
- vec[0] - vec.x - vec[_x]
I won't be happy if vec.x is supported, no matter how many other styles of access we add. A class like this should not expose its representation so directly.
Ok. I, OTOH, really likes that kind of notation, since I write a lot of GLSL as well. The point I'm trying to make is that there is as almost much opinion on member-access on vectors as there are on code indent size. So, whatever we make ought to support everything, if we want it to be acceptable to a large audience? Perhaps we can make it so that you can decouple access style from the general algorithms? We might need that anyway, if we want to support things like rgba, stqr, etc, for the small 1-4 element vectors. Cheers, /Marcus
Marcus Lindblom said: (by the date of Sun, 08 Oct 2006 13:28:56 +0200)
Perhaps we can make it so that you can decouple access style from the general algorithms? We might need that anyway, if we want to support things like rgba, stqr, etc, for the small 1-4 element vectors.
interesting idea, compare: - iterators <-> continers - member access <-> vectors maybe with MPL it's possible to define that 'custom' access method. -- Janek Kozicki |
Janek Kozicki wrote:
Marcus Lindblom said: (by the date of Sun, 08 Oct 2006 13:28:56 +0200)
Perhaps we can make it so that you can decouple access style from the general algorithms? We might need that anyway, if we want to support things like rgba, stqr, etc, for the small 1-4 element vectors.
interesting idea, compare:
- iterators <-> continers - member access <-> vectors
maybe with MPL it's possible to define that 'custom' access method.
It would be very cool if you could swizzle the components for small vectors cheaply into views ala high level shader languages. I.E. geom::vector<float,4> vec( 1, 0, 0, 0 ); // replicate x to all channels vec = vec.xxxx; // vec = { 1, 1, 1, 1 } or // convert the result of 3rd party geometry lib based function // that uses +y up to a result that a +z up application can use geom::vector<float,3> some_function(); geom::vector<float,3> app_vec( some_function().xzy ); - Mike
Michael Marcin wrote:
Janek Kozicki wrote:
Marcus Lindblom said: (by the date of Sun, 08 Oct 2006 13:28:56 +0200)
Perhaps we can make it so that you can decouple access style from the general algorithms? We might need that anyway, if we want to support things like rgba, stqr, etc, for the small 1-4 element vectors.
interesting idea, compare:
- iterators <-> continers - member access <-> vectors
maybe with MPL it's possible to define that 'custom' access method.
It would be very cool if you could swizzle the components for small vectors cheaply into views ala high level shader languages. I.E.
The syntax might be a bit tricky to get right. I'm fairly sure it's not possible to do exactly the same thing, but we might be able to get something similar. /Marcus
Marcus Lindblom wrote:
Dave Harris wrote:
In-Reply-To: <45252C77.3050708@yar.nu> macke@yar.nu (Marcus Lindblom) wrote (abridged):
So, we need to support three different styles of access, at least, to make everyone happy?
- vec[0] - vec.x - vec[_x]
I won't be happy if vec.x is supported, no matter how many other styles of access we add. A class like this should not expose its representation so directly.
Ok. I, OTOH, really likes that kind of notation, since I write a lot of GLSL as well.
The point I'm trying to make is that there is as almost much opinion on member-access on vectors as there are on code indent size. So, whatever we make ought to support everything, if we want it to be acceptable to a large audience?
Perhaps we can make it so that you can decouple access style from the general algorithms? We might need that anyway, if we want to support things like rgba, stqr, etc, for the small 1-4 element vectors.
If we made a "geom-vector" concept similar to boost::range, then we could make a lib that could use anyone's current vectors. (Boost would of course define their own, a couple of variants that pleases everyone). I think it could have some merit to do something that's "pluggable" into existing vector/point/matrix classes. /Marcus
participants (4)
-
brangdon＠cix.compulink.co.uk -
Janek Kozicki -
Marcus Lindblom -
Michael Marcin