[M3devel] zero sized structs?

[Jay K]

 > (of course the report also says that "The reference returned by NEW is distinct from all existing references") Aha. Good.And doesn't it seem kind of nice and correct if that same sort of thing applied to locals and globals?More consistent that way? Really I wouldn't mind if ARRAY [0..0] or ARRAY [0..-1] was just plain illegal.The following are not legal standard C/89/90:int a[-1];int a[0];  Though int a[0] may be a popular extension -- in both gcc and Visual C++ -- and many other compilers are forced to follow their lead.  I know we don't in general "do what C does" but C is not really a set of all bad decisions that should all be avoided, and in fact, Modula-3 is almost trivially isomorphic to C. The main differences are 1) it disallows some operations 2) it adds optional garbage collection via inserted barrier checks 3) generics and vtables which are a fairly simple layering 4) strict interface separation which is just enforcing what people can do do in C, but it is important that it is strict, since it allows for faster compilation.)  In the face of my own ignorance, I think considering what C and C++ do is not a bad option. They avoid the existance of zero sized things. On the other hand, C++ compilers then do work hard to "reoptimize" because of this. By "reoptimize" I mean, removal of zero sized things can actually be a significant deoptimization, that you then have to be pretty clever to optimize..when..if only zero size was ok in the first place, it would have been easy to keep optimal.In particular: struct A { };  struct B : A { };  struct C : B { };  struct D : C { };  struct E : D { };   what is the sizeof(E)? If zero size was ok, then the sizeof(A) and B and C and D and E would all be zero and the compiler's  job would be easy. In reality keeping the sizeof(E) "small" isn't trivial.  Perhaps perhaps multiple inheritance is needed to make the point. Let's see..hm..I need to research this..the "empty base optimization"..the problem doesn't seem that bad..without multiple inherirtance, the size was only 1.   struct A1 { }; 
 struct A2 { };  struct B1 : A1, A2 { }; 
 struct B2 : A1, A2 { };  struct C1 : B1, B2 { }; 
 struct C2 : B1, B2 { };  struct D : C1, C2 { };  struct E : D { };  
extern int a = sizeof(E);
 Only with a "mess" could I blow it up e.g. 7:  F:\>type 1.cpp && cl -c -FAsc 1.cpp && more 1.cod
 struct A1 { };
 struct A2 { }; struct B1 : A1, A2 { };
 struct B2 : A1, A2 { }; struct C1 : B1, B2 { };
 struct C2 : B1, B2 { }; struct D : C1, C2 { }; struct E : D { };
extern int a = sizeof(E);
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.278 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.1.cpp
; Listing generated by Microsoft (R) Optimizing Compiler Version 14.00.50727.278
include listing.incINCLUDELIB LIBCMT
INCLUDELIB OLDNAMESPUBLIC  ?a@@3HA                                         ; a
_DATA   SEGMENT
?a@@3HA DD      07H                                     ; a
_DATA   ENDS
END 
   - Jay
 > To: jay.krell at cornell.edu
> Date: Thu, 4 Oct 2012 13:37:33 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] zero sized structs?
> 
> 
> Well as a user I'm quite happy to see the two objects have different
> addresses, if it makes your life easier as a compiler writer.  However
> it's certainly not documented---so I'd better not depend on it!
> You're not supposed to be taking the ADR of stuff on the stack.
> It's UNSAFE, caveat emptor, etc...  I'm just saying that if you are
> doing that you're not writing programs that Modula-3 was intended for.
> If you want to pass something by reference, use VAR!
> 
> I find that when you have trouble with zero-sized anything, you've usually
> used the wrong abstraction....  In any case the fact that the language
> allows certain things to be zero sized is very helpful when you are writing
> programs that have to generate Modula-3 code.  You don't have to keep
> track and insert dummies in various places.  But sure I can't think of any
> reason the compiler couldn't implement zero-sized things as being one-sized
> or four-sized, or whatever it/you want/s.  It looks like they take 16 bytes
> when you NEW them... (of course the report also says that "The reference
> returned by NEW is distinct from all existing references")
> 
>      Mika
> 
> 
> Jay writes:
> >Same address & same size implies same object & same type. But the types can v=
> >ary. Please check also variables in sub-blocks. I think NT/x86 backend doesn=
> >'t always put them at same place. Then again, that is probably ok too -- in g=
> >eneral not all zero sized objects can be located -- they could be locals in d=
> >ifferent functions or globals in different modules.
> >
> >
> >You say use a different language, but 1) they are exceedingly rare so ok to w=
> >aste space 2) as small & simple Modula-3 is, it is still really isn't small o=
> >r simple, there are surprising number & level of detail to understand and de=
> >al with. Adding a notion of a zero sized thing isn't necessarily so obviousl=
> >y simple and free of complexity down the line.=20
> >
> >
> >
> > - Jay (briefly/pocket-sized-computer-aka-phone)
> >
> >On Oct 4, 2012, at 11:23 AM, <mika at async.caltech.edu> wrote:
> >
> >> It seems that CM3 puts them at the "same address"....
> >>=20
> >> UNSAFE MODULE Main;
> >> IMPORT IO, Fmt;
> >>=20
> >> TYPE
> >>   T =3D  ARRAY [1..-1] OF INTEGER;
> >>=20
> >> VAR t :=3D NEW(REF T); u :=3D NEW(REF T);
> >>    v : T;
> >>    w : T;
> >> BEGIN
> >>  IO.Put(Fmt.Int(LOOPHOLE(t,INTEGER), base :=3D 16) & "\n");
> >>  IO.Put(Fmt.Int(LOOPHOLE(u,INTEGER), base :=3D 16) & "\n");
> >>  IO.Put(Fmt.Int(LOOPHOLE(ADR(v),INTEGER), base :=3D 16) & "\n");
> >>  IO.Put(Fmt.Int(LOOPHOLE(ADR(w),INTEGER), base :=3D 16) & "\n");
> >> END Main.
> >>=20
> >> (114)async:~/ttt/src>../AMD64_LINUX/prog
> >> 2269030
> >> 2269040
> >> 602218
> >> 602218
> >>=20
> >> I don't see a problem with it.  Whoever thinks he needs to check whether
> >> ADR(v) equals ADR(w) should be using a different programming language...
> >>=20
> >>     Mika
> >>=20
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121004/90cfc81a/attachment-0002.html>