It sounds like you are more asking a question about an inbuilt construct
for performing this conversion, not 'can this be done'. Some are talking
about the use of reflection, but I aver from this and absolutely avoid
reflection at all whenever possible, with the exception of its back-end use
in formatted print functions and json/etc parsers, which one should avoid
in high repetition loops.
No, there is no such method, as with everything in Go, many thtings that
are automatic, in other language syntax, must be explicitly declared.
Constructors, Destructors, type conversions. Note that, in this latter
case, which applies to your question, that regardless of the syntax any
language shows you, on the implementation level it is the same as how you
do it and as I showed in my snippet above.
I'd say that you will find a solution to your problem by changing the way
you approach the construction of these compound types. Two-plus dimensional
maps to me tend to be a red flag for the use of slices instead, and this is
confirmed if in any way the order of reading the elements out affects the
result. These also require for loops like I demonstrated, and are still
faster than dealing with maps for up to at least up to 100 possible members.
Maps have two important features for implementations, when considering
performance:
- they work by using hash tables, so every resolution of them to their
member value requires a hash function and a loop that iterates the hash
table, then returns the variable in the array of struct { int, interface{}
} in the actual underlying runtime that will execute.
- the order of iteration is entirely dictated by the scalar value of the
hash of the key, and it should thus be pointed out also that slice and
string keys cost more on hashing
The use of iota-based or manually created enumerators with arrays is a
better way of implementing some types of sets, but using maps is easier and
can be faster if you are only checking for membership of one or two in the
set. If you are iterating, the array will be faster and lets you define the
order in which they iterate (by either declaration or a sort in the
initialiser).
If I haven't covered relevant cases to your specific purpose, or not
adequately, you should be able to find more information in other places.
Common types of algorithm are covered in some of the beginner tour things
for go, some might be described in stackexchange or in here, and still
others it's worth checking rosettacode.com though more of the algorithms
there are for math than datatypes.
On Saturday, 2 March 2019 14:10:06 UTC+1, 김용빈 wrote:
>
> yes I can do this in a for loop. but that is not I want.
>
> what I really want to do is "create a function that returns sorted
> []string keys from any map[string]... in type safe way".
>
> when I said 'there is no easy way...' , I mean I cannot create that
> function easily.
>
> I did not very clarify. sorry for the confusion.
>
> 2019년 3월 2일 토요일 오후 8시 46분 50초 UTC+9, Louki Sumirniy 님의 말:
>>
>> Only an assigment to a pre-declared map[string]interface{} in a loop
>> walking the first layer of that complex map type is required to put the
>> values into that type, it's not complicated and doesn't have to touch the
>> template. Something like this:
>>
>> var MapStringInterface map[string]interface{}
>> for i,x := range MapStringMapStringThing {
>> MapStringInterface[i]=x
>> }
>>
>> On Saturday, 2 March 2019 11:01:10 UTC+1, 김용빈 wrote:
>>>
>>> Thank you, Mercl.
>>>
>>> So there isn't an easy way, you mean, right?
>>>
>>> 2019년 3월 2일 토요일 오후 6시 45분 8초 UTC+9, Jan Mercl 님의 말:
>>>>
>>>> On Sat, Mar 2, 2019 at 10:32 AM 김용빈 <kyb...@gmail.com> wrote:
>>>>
>>>> > but it seems the argument is not automatically converted.
>>>>
>>>> Things are automatically converted to a different type in Go only when
>>>> they are assigned to, or passed as arguments of, interface types.
>>>>
>>>> > manual type cast `map[string]interface{}(myMap)` also not working.
>>>> > is there a way of doing this?
>>>>
>>>> Go does not have casts. Conversion rules[0] do not allow a conversion
>>>> of different map types because the memory layouts are not compatible.
>>>>
>>>> [0]: https://golang.org/ref/spec#Conversions
>>>>
>>>> --
>>>>
>>>> -j
>>>>
>>>
--
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.
