6 ms·
The author is obviously new to Go, and that's fine.... here's a clarification of interfaces: Interface Pointers Note that the author of a type that fulfills a
by NateDad 14y ago
The author is obviously new to Go, and that's fine.... here's a clarification of interfaces:
Interface Pointers
Note that the author of a type that fulfills an interface and the consumer of a function that takes an interface both have full control over how much data is copied on a call to the function. You can control whether a type fulfills an interface, or whether a pointer to the type fulfills the interface. In Go, it is always easy to tell how much memory is being copied for any function call.
type Jumper interface {
Jump()
}
func MakeItJump(j Jumper) {
// this function doesn't know what's wrapped inside the Jumper interface
// and doesn't need to care
j.Jump()
}
type Foo struct {
data [10]int64 // array of 10 8 byte numbers = 80 bytes on a copy
}
func (f *Foo) Jump() {
// we define Jump on Foo to take a copy of a pointer to a Foo.
// this means that when we pass a *Foo into MakeItJump,
// just a single pointer value is copied into the interface, \
// not the whole array inside Foo
}
type Bar uint8
func (b Bar) Jump() {
// we define Jump on Bar as taking a copy of the value of Bar
// since we know it only needs to copy an 8 bit integer to do so
}
- matthavener 14y agoI didn't quite "get" the point of the pointer/copy option on interfaces, but this makes it crystal clear. This works around such a common problem in writing C++ templates (which is really the only equivalent polymorphism if you want to dispatch a function on a native type): template <class T> void doSomething(const T &expensiveCopy); Versus: template <class T> void doSomething(T cheapCopy); As usual, boost provides another crazy template hack to work around this issue: http://boost.sourceforge.net/libs/utility/call_traits.htm http://boost.sourceforge.net/libs/utility/call_traits.htm
- esrauch 14y agoCan you explain why this is actually a problem? Why not just always have a const T&, is there some negative in the "cheap copy" case to not copy?
- matthavener 14y agoI'm making some assumptions about the compiler optimization: If T is something like "int", then passing by reference can be more costly, because a value that was once stored in a register now needs a real memory address and must be deferenced to read.