Re: Struct members -> Array elements

wade@stoner.com wrote:
 > kanze wrote:

 >> And what would that buy us?

 > An ability to interface with other languages at a higher level.

 > I'm communicating with Fortran. Some interface tells me that
 > the floating point values associated with a particular pipe
 > live at a particular location, ndx, in a large floating point
 > array, d[]. For instance, the pipe's outside diameter is
 > stored at an offset of -10, and the pipe's minimum elevation
 > is stored at offset +54.

This is sort of an argument. Of course, anything you do to
interface with Fortran will be implementation dependant, so you
don't need any additional guarantees from the standard. And I
sort of think that some sort of wrapper interface would be the
preferred solution.

     [...]
 > However, a much better solution (for us) assumed that floats
 > were adjacent in memory

 > struct PipeD
 > {
 > .
 > float ODiameter;
 > .
 > float MinElev;
 > .
 > };

 > with a factory that uses placement-new or reinterpret_cast to
 > "interpret" a hunk of the array as a PipeD. (Placement new
 > has the advantage of being standard-conforming.
 > reinterpret_cast has the advantage that it better expresses
 > the intent. Neither generates any code, since the
 > construction of a POD-struct is a no-op).

And what's the problem? I do this myself, in some of my code.
It's undefined behavior according to the standard, and it is
neither guaranteed by the standard nor portable. But it works
in the implementation I'm targetting, and since it is being used
to implement things that are very implementation specific
anyway, that's sufficient.

 > The main advantages of PipeD are:

 > 1) In the debugger, it is nice to be able to see named struct data
 > members.
 > 2) When C++ becomes the "source" development platform, you don't have
 > to maintain those magic integers (the "54" associated with MinElev) by
 > hand.

I'm not sure that maintaining those "magic integers" is any
worse than ensuring the alignment of the two structs. (I'm not
familiar with modern Fortran, but in the old days, the
specification in Fortran would use magic integers. And in such
cases, I'd almost certainly write a mini-parser to generate the
C++ classes based on the Fortran code.)

     [...]
 > I currently use implementations which pack POD elements
 > tightly, and have found that to be a useful feature to
 > exploit. I'm not yet convinced that the feature is so useful
 > that it should be standardized. However, it does seem to be
 > existing practice.

I currently have code which counts on the fact that the Solaris
ABI forbids padding between char arrays in a struct. The code
is very Solaris dependant in many ways, however, so this doesn't
bother me too much. I can see the utility in implementation
specific situations, such as the one you describe. I just don't
see any necessity, or even any advantage, of making it a
standard requirement.

--
James Kanze kanze.james@neuf.fr
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 ]