On Fri, Jul 1, 2016 at 9:51 PM, <charras...@gmail.com> wrote: > > How does the compiler know sizeof(T)? >> > > > interesting question. About obtaining sizeof(T). The sizeof(T) is known > from the call site calling the generic function, in particular from the > type of variable that's passed to the generic function. >
When the compiler is compiling the generic function, it doesn't know anything about the call-sites. Because they could be in a different compilation unit. Unless you are suggesting, that the compiler compiles it into a generic version, which is then put into the object file and instantiated to a concrete version at link time. In that case the answer is "I am favoring the C++ way". Which is fine. But you need to justify why that is the way you are favoring. > After obtaining sizeof(T), it needs to be passed to the function. I'm no > call convention expert so In my experiment I've did the stupid simplest > thing to make it work, Before a call to a generic function, I emitted > runtime setter to store it, then in function i get it from runtime. there > is race, sure but can be swept under the rug by putting it to thread > specific place, maybe G(goroutine) . > This scheme, in it's essence ends up being the "box everything" java version (not the least because of what ian is saying about interfaces). i.e. the only thing you may be gaining by this scheme over the java way, is that the compiler can do an unboxing optimization at the "root" of the call-stack (after inlining and everything). Java does that too. You are talking about the Java path. And that's okay, but you need to justify why you think the Java path is the correct one. > If it's passed as an argument or saved together with the struct or >> something in that regard, you end up with the "java approach", if you have >> the compiler specializes the function per size, you end up with the "C++ >> approach" (also, in either case, there is no need for the "only pointers >> are allowed" kludge), from >> > > > If go goes the Java way but does it somehow differently. Something clever > but very practical. I believe this is possible. > > Perhaps modify Golang's 2.0 calling convention, that EVERY function must > get upon compilation one extra invisible-to programmer argument that is > pointer that > when said function is generic, points to sizeof(T) storage place . > If you're calling to non-generic function it's just NULL, and it seems > like a waste? but does it slow it down everything so much?? > As explained above, you are re-phrasing the Java way. Whether the box is attached to the data or "passed as a parameter", at the end it'll be the same size and will have the same disadvantages, like cache locality, additional indirections and the need to do arithmetic, instead of folding constants. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
