>> I would also like to point out again that I am not arguing in favor or
against the C++ or the Java way. I am simply trying to get you to answer
the question which of the two you are proposing.
Neither one nor the other.
Only the "Go way".
And I am did not propose.
I am only try bring underst
>> That there is an indirection in the struct doesn't mean that a function
doesn't need to know the size of the memory it is allocating for a bucket.
Your judgement are now incorrect.
Obtaining the size of the of the type is not so hard at runtime.
It always known from `rtype`
This is how map al
Can I ask the question out of turn?
Ok. I ask.
What wrong in Java way?
What wrong in C# way?
Of course, they have a boxing/unboxing concepts.
Does this means that boxing/unboxing is very, very, very slow operations
and should not be used even in Java or in C#?
But they used. They used at least in
>> How does the generic function know the size of the return value?
All your judgement are not correct only because you ask not a correct
questions.
They return pointers to appropriate values.
Or you really think that the `map` also returns a value instead of pointer?
How it (map) can know the s
>> Go has to run in environments where runtime code-generation /
modification is not allowed.
Where you find that I wrote about that?
The generic code (not a parametrized code) executed in the same manner as
the reflection works.
But with a single and very big differnce.
The reflection is slow b
>> The generic dilemma is this: *do you want slow programmers, slow
compilers and bloated binaries, or slow execution times?*
(The Java approach.) Box everything implicitly.
This slows execution.
I just want to add some clarification.
This does not slows a whole execution.
All that works fast
>> I believe you've made a mistake here, elem needs to be *T , not T
This was just an abstract example.
I just wanted to say that if someone want to try implement a transpiller of
the "Go.next" to the "Go" then the better way to represent the data of the
different types (which are specified by t
>> Now imagine that T=int8
Generic struct always has the same size only because it uses pointers.
type S struct {
elem T
arr []T
}
Is the same as the following struct.
type S struct {
elem unsafe.Pointer
arr []unsafe.Pointer
}
This is because it is designed to be universal.
You may
>> it can be done with using unsafe
This is the only available method (and very suitable).
The same method used throughout in the Go language the runtime.
It's very easy to do that.
Problem only to find appropriate syntax for the current Go grammar for to
be look as idiomatic Go.
I still not fou
>> If you set the var statement outside the main func, the issue is gone
because err is then a "global" var.
Not quite correct.
This is how it work and why `err` is used:
package main
import "fmt"
type closure03 struct {
err *error
f func() error
}
func (c *closure03) fn() {
But what you want if it (`err`) really not used in your example?
func main() {
var err error
err = f()
}
--
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
>> So, how exactly does this method work with Linux shared libraries?
It does not work on Linux.
On Linux you should use the methods:
dlclose, dlopen, dlmopen - open and close a shared object
http://man7.org/linux/man-pages/man3/dlopen.3.html
--
You received this message because you are subsc
>> But when I try this on linux I get:
Linux does not have a `LoadLibrary`
Also Linux does not have `kernel32.dll` and so on.
P.S.
The `LoadLibrary` also in `kernel32.dll` library which are only on Windows.
https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms684175(v=vs.85).aspx
--
You r
>> The fact still remains that unlike a lot of other proposed languages
additions that are immediately dropped, generics are still open for
discussion by the language developers themselves.
I think that the problerm only in the Go developers brcause them even does
try to implement them experim
>> The version without generics is necessary to compare how well a
particular generics approach improves the current language and code.
I am sorry but this is obviously that any useful feature (in the context of
solving problems) improves the current language and code.
Another question: how new
>> You are not bringing anything new to the table here, except the attempt
to insult my intelligence, apparently.
>
>
I do not have any claims to anyone personally.
I only defend my own point of view.
P.S.
Also I don't love to see or use some (not my own) code which written like a
mess.
If I ca
>> And my point is and was: It doesn't *need* to be both type safe *and*
reusable, unless you are focusing your energy on writing frameworks or
treating type safety as a goal solely for it's own sake.
It does NEED to be BOTH type safe and reusable.
1. Type safety prevent the programmers to make
Sorry for typo and possible spam but correct example here:
type Foo interface {
Get(key K) V
Set(key K, val V)
}
func foo() (int, Foo) {
// Typo: foo := &Foo{}
foo := &fooStruct{}
// ...
foos := []Foo{}
// ...
k := "London"
// ...
return 55, foo2(foos, 55, k)
}
// This code is
>> perfectly type safe.
Perfectly type safe but not perfectly reusable.
What If we slightly complicate the task?
Now is my code and I want to see on your code exampe (perfectly type safe
but and perfectly reusable)
type Foo interface {
Get(key K) V
Set(key K, val V)
}
func foo() (int, Foo)
>> The issue is, that a "KeyValuePair" (no matter if you implemented
it via generics or like you mention via interfaces) is a fundamentally
useless type and generics encourage people to add useless types. A
"KeyValuePair" is a "struct { Key K, Value V }", plain and simple.
It's not an interface
>> What I mean is that most people who have followed the past generics
discussions already know it's possible to implement them with efficient
memory use and performance. So they don't need to worry much about that.
Thank you for explanation.
>> can they be implemented without making Go a much
>> increase in cognitive load to decipher chains of type definitions.
Sorry, but who are members of this mail lists?
This is a first time when I hear about such loads such as the `cognitive
load`.
Also I am possible here a single person who does not know anything about
the `cognitive load to dec
>> I am not saying that generics is bad, but I am questioning whether
generics is necessary.
Please, do not panic.
If you worry about the following things:
- Generated code will grow when used generics
- Generated code will be more complex when used generics
- Execution performance will slow down
>> I was one of the generics supporters for Go in this forum, but now I am
not so sure.
But why?
Generic types is the same types as and the regular types.
Difference only in that the regular types does not have a parameters but
generic types are always have at least one parameter.
This is why th
>> While later I realized that we still need some parameter check in the
callee code to satisfy the interface matching (the generic version of each
function in my proposal).
A am sorry but your judgements is not correct.
Here is a proofs:
1. It is redundant to perform check of the correctness of
Overhead at runtime will be not very big;
1. Generate each time an instance of specific generic type with arguments
2. Perform generic specific type checks before any kind of an assignements
1. The first overhead can be reduced (eleminated) by the static code
generation of specified generic types
As for me then everything is much more simple if Go language (as the
starting point) will introduce a non-reified generics.
Non reified generics does not requires a complex runtime support (static
code which was generated by the compiler will be enough).
Type checking of the type arguments perfo
In Go arguments (function parameters) passed by value.
This means that when you call function you pass copy of the instances.
If you modify (received copy) then original instance remains unchanged.
Pointer points to the storage of the instance.
When you pass pointer as an argument then you pass a
>> Keeping a a pointer in a uintptr as a "reference" to something is safe
iff it will never be casted back to a pointer. I think this means that the
safe case is useless.
Storing any reference (read: address) of Go instance is unsafe because
after when this operation ends then a stored address
29 matches
Mail list logo
