C++: Should I use a reference member here?

Started by
20 comments, last by grekster 14 years, 1 month ago
Oh, ok. I misunderstood the problem. Something along the lines of this:

Quote:Original post by CodeCriminal
all you want to do is 'cast' your vector class into an array of floats right?


is a similar solution and would have been my next suggestion, had CodeCriminal not offered it first.

(x, y, z) is the standard notation for vectors, but in mathematics, the unit vectors are i = <1, 0, 0>, j = <0, 1, 0> and k = <0, 0, 1>, and so vectors are commonly written with i, j, and k looking like axis labels, when it is actually just scalar multiplication and addition at work.

As such, I certainly would not be uncomfortable using i, j and k as labels for the vector components.
Advertisement
CodeCriminal, I think that is what Promit was suggesting, although that is again dependent on the guarantee that those members (x,y,z) will always be contiguous in memory, and I wasn't aware that that was true.
[size=2]My Projects:
[size=2]Portfolio Map for Android - Free Visual Portfolio Tracker
[size=2]Electron Flux for Android - Free Puzzle/Logic Game
Quote:Original post by karwosts
CodeCriminal, I think that is what Promit was suggesting, although that is again dependent on the guarantee that those members (x,y,z) will always be contiguous in memory, and I wasn't aware that that was true.


True, he did suggest it first, but i didnt realise until after i had written my post (my apologies). And your right about (x,y,z) needing to be contiguous in memory for this solution to work.

However, this approach is used in Microsofts very own D3DX library to pass matrices and colors (among other things i may not be aware of) to functions/methods in Direct3D, and since many people use D3DX you would think someone would have spotted a problem by now if they were not contiguous in memory. So I can only assume that they are guaranteed to be, until my assumption is proven to be false.

Quote:If it were me, I would just go ahead and return &i for your float*. (And ijk for a vector? Wtf?) Appropriate use of pragma should control the structure layout appropriately, and a BOOST_STATIC_ASSERT can seal the deal.


One question though, which pragma directive are you refering to?

[Edited by - CodeCriminal on March 6, 2010 8:41:10 PM]
Quote:Original post by CodeCriminal
So I can only assume that they are guaranteed to be, until my assumption is proven to be false.

It's not. See section 9.2 paragraph 12 in the C++ Standard for the relevant verbage. However, it would take a seriously messed up implementation for the variables not to be contiguous. If the lack of guarantee bothers you, put a static assert on it and worry about it if it ever trips.
Quote:Original post by SiCrane
Quote:Original post by CodeCriminal
So I can only assume that they are guaranteed to be, until my assumption is proven to be false.

It's not. See section 9.2 paragraph 12 in the C++ Standard for the relevant verbage. However, it would take a seriously messed up implementation for the variables not to be contiguous. If the lack of guarantee bothers you, put a static assert on it and worry about it if it ever trips.


Ah, thanks for the heads-up SiCrane, though I've never had any problems with it before I'll keep that in mind.
Quote:Original post by karwosts
Quote:(And ijk for a vector? Wtf?)

Isn't this pretty common notation?


For mathematicians, sure. For computer programmers, not so much. :) xyz is much more common.
Since the OP has been answered...
Quote:
For mathematicians, sure. For computer programmers, not so much. :) xyz is much more common.


I have reservations about this statement because it seems to suggest that computer programmers are either game/graphics people or language students instead of real people solving real problems. A mathematician writing a math program IS a computer programmer. Excuse me if you meant it as a joke ( and the derail but... )

I believe Bjarne Stroustrup has bemoaned this notion:
http://itmanagement.earthweb.com/features/article.php/12297_3789981_3/Bjarne-Stroustrup-on-Educating-Software-Developers.htm

Quote:
Actually, I think the ultimate aim is to make programming more of an engineering discipline, more mathematical or scientific; “craft” and “art” are both needed, but there ought to be a scientifically based core on which people can base their craft and art. Software design and implementation is more than a craft; there is more math, science and engineering to know and apply than is customary for fields we call “crafts.” Incidentally, I find it appalling that you can become a programmer with less training than it takes to become a plumber.


http://www.artima.com/cppsource/cpp0x.html
Quote:
...Many C++ users quite reasonably don't want to become C++ experts—they are experts in their own fields (e.g., physicists, graphics specialists, or hardware engineers) who use C++. In my opinion, C++ has become too "expert friendly"...
That's true, and why I feel my explanation in a post further above is more thorough. However, I don't think that differing notation in mathematics being different than notation in C++ should imply such a thing. Notation differs between programming languages and APIs (think left-handed vs right-handed coordinate systems).

In this case, however, the standard notation in both math (i.e. Calculus) and C++ is (x, y, z) for vectors, or <x, y, z> in some cases of math. The confusion comes my above explanation (for example, x = m*i where m is a scalar value and i is the unit vector in the positive direction of the x-axis).
It seems like a lot of mathematical literature names vector coordinates of a vector v as (v1, v2...vn) so perhaps the operator[] is the closest best conventional representation that generalizes access for inter-disciplinary uses?

I wish the C++ standard library had just named "std::vector" "std::array" instead.
Quote:Original post by m3mb3rsh1p
It seems like a lot of mathematical literature names vector coordinates of a vector v as (v1, v2...vn) ...

Similar to me: I'm used to index the component kind, e.g. { s0, s1, ... } for the (scalar) components of vector, { v0, v1, ... } for the (vector) components of matrices, ... and so suppressing any notional dependence on whether the structure works in RGB color space, XYZ spatial space, UV texture space, or whatever. Its just my personal preference.

This topic is closed to new replies.

Advertisement