proposal: fmt: add a %*T verb #26262
Comments
|
For almost any type, the cost of the syscall and terminal io will be much greater than boxing a copy of a inside an interface value.
I don’t thing this is necessary
… On 7 Jul 2018, at 22:28, Go101 ***@***.***> wrote:
Sometimes, I want to print the type of a value (not for debug purpose).
If the size of the value is large, then the fmt.Printf call is inefficient. For example:
package main
import "fmt"
var a [100]int
func main() {
fmt.Printf("My type is %T \n", a) // a will be copied.
}
So I proposal add a %*T verb, so that I can pass the address of the large value as argument instead.
package main
import "fmt"
var a [100]int
func main() {
fmt.Printf("My type is %*T \n", &a) // a will be copied.
}
BTW, is %& an undocumented verb?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
How about the type of |
|
Your example is contrived. This is an unnecessary change.
… On 7 Jul 2018, at 22:33, Go101 ***@***.***> wrote:
How about the type of a is [10000000]int.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
So a copy is inevitable? |
|
In the scenario you have described, yes. I argue your scenario is contrived and this is a really edge case optimisation.
… On 7 Jul 2018, at 22:50, Go101 ***@***.***> wrote:
So a copy is inevitable?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Yes, it is a little edge. In fact, sometimes I also want |
|
I think you are over focused on the copy. Copy’s happen all the time, every assignment in go is a copy, every function call. Every return, is a copy. Copying is something CPU’s are *really* good at, esp3cially if the thing being copied is large. Copying isn’t usually a problem unless you’re doing it in the centre of a hot loop, and as I said before, printing is far more expensive.
… On 7 Jul 2018, at 23:16, Go101 ***@***.***> wrote:
Yes, it is a little edge.
In fact, sometimes I also want %*v and %*#v, which would be used more frequently than the%*T`.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
For most Go values, copying is not a problem. But for copying large sized arrays and structs, it is possible a problem. |
|
If you really had this in a hot path, you could use the |
|
Reflection is a workable. It is just that the |
|
You seem to expect |
|
I admit it is a micro-optimization. It is just a little more beautiful and efficient than the current alternative ways. |
|
Today for debugging you could print the pointer type directly and mentally remove the star, or else you could use It seems to me unfair to claim that "Go is to satisfy 99% use cases, but not good for the other 1% use cases." For the other 1% use cases Go is still good but you might have to write some code instead of assuming everything you need is built-in. That's what keeps Go small, because everyone's 1% is different and adds up to about 1,000,000%. |
Sometimes, I want to print the type of a value (not for debug purpose).
If the size of the value is large, then the
fmt.Printfcall is inefficient. For example:So I propose to add a
%*Tverb, which represents the element or base type of the corresponding argument, so that the address of the large value can be passed as argument instead.BTW, is
%&an undocumented verb?[edit]
%*vand%*#vare also wanted.The text was updated successfully, but these errors were encountered: