🚀 go-pugleaf

In article <ROLAND.90Aug20192216@wookumz.ai.mit.edu> roland@ai.mit.edu (Roland McGrath) writes:
+In article <1229@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
+
+   In the case of a constraint which would require compilers to maintain the
+   programmer-specified ordering of data fields, the implementation is trivially
+   easy.  (In fact, it is actually *harder* to do anything else!)
+
+So obviously lazy implementors will do what you want, and clever/hardworking
+implementors will do something more.

In a separate posting, I have scaled back my desires based upon your persuasive
arguments.  Let the clever/hardworking implementors do their best!  As long
as I have some way to get "as written" field ordering, I'll be happy.

+Although I think I consider { "as written" field ordering } less useful
+than you do, I am in favor of retaining a way to force a given field order.
+Using:
+
+extern "C"
+{
+  struct foo
+    {
+      char elt0;
+      int elt1;
+    };
+}
+
+does this quite well.

I agree 100%.  I hope the x3j16 membership is listening.

+   Are you suggesting that it may be possible to generate more efficient
+   executable code if arbitrary field re-ordering (by the compiler) is allowed?
+   If so, are you prepared to give realistic (not contrived) examples of such
+   improvements?
+
+I'm not so prepared.  Are you prepared to prove it impossible?

Nope.

+Where do you find these garden slugs with absolute prescience of all possible
+future computer architectures and C++ implementations?

In the garden, of course. :-) :-) :->

+   Right now, if I have the following C code:
+
+	   struct s {
+		   unsigned	field1:24;
+		   unsigned	field2:8;
+	   };
+
+   and this is in a program running on a 68000, I can get C compilers from at
+   least a dozen vendors that will lay this out *exactly* the same way.  Thus,
+   I have vendor independence.  That (and portability) are worth money to me.
+
+This is an excellent example.  Since we are speaking of C++, and the example is
+C code, you can simply put it within `extern "C"' and have all the guarantees
+you now have with the C code.

Well, I don't believe that I saw that stated in E&S, but I certainly would
*like* to see it in the ANSI C++ standard.

+You again presume foreknowledge of all possible future implementations.  I find
+such arrogance surprising from an otherwise reasonable person.

I have been accused of a lot of things, but never of being "otherwise
reasonable".  That's a first for me. :-)
-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.