Dnia 2020-11-10, o godz. 19:08:10
"'Kilos' via golang-nuts" napisał(a):
> I just copy the screenshot in this
Do not do that again. It is akin to saying:
"it is more convenient for me to hit two keys instead of selecting text and
paste it what would effect in four strokes for me".
"So now I am
On Tue, 2020-11-10 at 22:17 -0800, Kurtis Rader wrote:
> Jeebus. H. Christ! Yes, you can "safely" mutate a map while iterating
> over it. In as much as doing so will not result in a panic; although,
> I'm not convinced that is true. The point of the O.P. is that they
> expect the map mutation to al
On Tue, Nov 10, 2020 at 10:03 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Tue, 2020-11-10 at 20:28 -0800, 'Kilos' via golang-nuts wrote:
> > You cannot safely mutate a Go map while iterating over it with the
> > `range` operator.
>
> This is not true, depending o
On Wed, 2020-11-11 at 06:02 +, 'Dan Kortschak' via golang-nuts
wrote:
> So long as you take into account these caveats, mutating a map during
> a range will not corrupt the map or other data structure, and will
> cause your application to crash.
s/will cause/will not cause/
--
You received
On Tue, 2020-11-10 at 20:28 -0800, 'Kilos' via golang-nuts wrote:
> You cannot safely mutate a Go map while iterating over it with the
> `range` operator.
This is not true, depending on your definition of "safely". See
https://golang.org/ref/spec#For_statements "For statements with range
clause"
For Kurtis:
Thank you, I will remember this:
You cannot safely mutate a Go map while iterating over it with the `range`
operator.
I will not do this when programming, but when I learned about this, then I
want to know the underlying reason.
And now, I have known.
在2020年11月11日星期三 UTC+8 下午12:23
On Tue, Nov 10, 2020 at 8:12 PM 'Kilos' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> For Kurtis:
> I know the map will choose random hash seed to init itself, and the
> iterator will also choose random order to iterate map.
> And I know it is a bad idea to add or delete a key when iter
For Kurtis:
If my idea is correct, then my question has been solved, thank you for
replying.
在2020年11月11日星期三 UTC+8 下午12:16:26 写道：
> On Tue, Nov 10, 2020 at 7:57 PM 'Kilos' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> For Dan:
>> I have an idea that the cause is in the runtime funct
On Tue, Nov 10, 2020 at 7:57 PM 'Kilos' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> For Dan:
> I have an idea that the cause is in the runtime function mapiternext.
> The runtime calls mapiternext function to choose next bucket to iterate by
> index,
> if we put a key-value into a buc
For Kurtis:
I know the map will choose random hash seed to init itself, and the
iterator will also choose random order to iterate map.
And I know it is a bad idea to add or delete a key when iterating a map,
but I want to know what causes the inpredictable result, not the key's
iterating order,
For Dan:
I have an idea that the cause is in the runtime function mapiternext.
The runtime calls mapiternext function to choose next bucket to iterate by
index,
if we put a key-value into a bucket which already be iterated, then the
for-range will not iterate it again,
so the new key-value will n
On Tue, Nov 10, 2020 at 7:09 PM 'Kilos' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Thanks for reply, but I want to know the underlying reason about it, I
> think the reason is in how the runtime functions works.
> And I'm sorry about the empty picture, when I write this, I just copy
On Tue, 2020-11-10 at 19:08 -0800, 'Kilos' via golang-nuts wrote:
> Thanks for reply, but I want to know the underlying reason about it,
> I think the reason is in how the runtime functions works.
The direct cause is that the hash function used for the map
implementation is seeded from the system
13 matches
Mail list logo
