Re: Struct members -> Array elements
Seungbeom Kim wrote:
kanze wrote:
"Tom1s" wrote:
However, I propose that the Standard guarantee that there
be no padding between members of the same type within a POD
struct.
And what would that buy us?
Suppose you have a struct with members named x, y, and z, and
you could want to refer to them sometimes by names, and
sometimes by indices.
So that x and a[0] are the same object? Sounds like obfuscation
to me.
The former because it's more natural and closer to the problem
domain, and the latter because it's better suited for
across-the-board operations (and can even benefit from
standard algorithms such as std::for_each, std::transform,
etc.).
I can see a class making both interfaces more or less available.
I can't see any use of it at the lowest, data representation
level, however. What's wrong with simply:
class Point3D
{
public:
double getX() const { return coords[ 0 ] ; }
double getY() const { return coords[ 1 ] ; }
double getZ() const { return coords[ 2 ] ; }
double* getXYZ() const { return coords ; }
// Since you mention STL...
double* begin() const { return coords ; }
double* end() const { return coords + 3 ; }
size_T size() const { return 3 ; }
// ...
private:
double coords[ 3 ] ;
} ;
(or just x(), y(), z() and xyz(), if you prefer).
The functions are small enough that even the worst compiler will
inline them, and you end up with the interface that you want.
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ 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.comeaucomputing.com/csc/faq.html ]