Re: [go-nuts] How to generalize parameters for a function
Well, that didn't go very far: https://go.dev/play/p/UtsrRar9J0Q
Fails with the messages
./prog.go:15:11: invalid operation: cannot index p_Map (variable of type
MAP constrained by DataMap)
./prog.go:16:26: cannot range over p_Map (variable of type MAP constrained
by DataMap) (MAP has no core type)
I think i have to to some more research here - or just copy and paste three
different typed functions…
Best regards from Charleston (WV),
Frank/2
Frank Jüdes schrieb am Mittwoch, 15. März 2023 um 05:51:10 UTC-4:
> Hi Kurtis,
> good to know that a map will always be "kind of" passed by reference to
> functions. I have verified that with a short test-program on the playground
> -> https://go.dev/play/p/HxdgpM-QozM
> So in the next code-review all those *[maptype] references will be
> removed. Things are very different in this case in other programming
> languages…
>
> I understand the misconception and that a map[type]interface{} won't
> automagically convert the data-type from the parameter into anything else.
> My intention was to explain the compiler to just accept whatever is fed
> into the function and just pass the data through to a function that uses
> interface{} for a single parameter. That's all this function needs to do:
> Accept a map of "something", get single values of "something" and pass them
> on to another function that accepts a single parameter of "something".
>
> I think i have found a solution in using a "generic" interface, stumbled
> upon this web-site:
> https://www.geeksforgeeks.org/generics-in-golang/?ref=rp
>
> And created a little test-program: https://go.dev/play/p/mOu1pmmfdX8
>
> This should allow me to pass different types of maps - actually i only
> need three types - to a generic function that passes the values on to
> another (generic) function.
>
> Thank you very much for your help.
>
> Best regards from Charleston (WV),
> Frank/2
>
> Kurtis Rader schrieb am Dienstag, 14. März 2023 um 22:57:13 UTC-4:
>
>> On Tue, Mar 14, 2023 at 7:07 PM Frank Jüdes wrote:
>>
>>> Thank you very much Ian!
>>> I am using a pointer to the map because i want to pass the map by
>>> reference, not by value.
>>> Those maps can become pretty large and are being handed down through a
>>> couple of function calls and i don't want them to be copied over and over
>>> again.
>>>
>>
>> Maps are a special-case. You can't pass them "by value" in the sense you
>> mean because a "map" value is a very tiny structure that contains a pointer
>> to the actual map. Possibly the oldest public discussion of the fact maps
>> are reference type is this blog post: https://go.dev/blog/maps. Using a
>> pointer does, in fact, avoid copying that very small data structure but is
>> not necessary to keep from copying the entire map.
>>
>>
>>> I read the document you referenced, but am not able to understand…
>>> So i can use interface{} or any just to generalize simple types?
>>> Why is the compiler accepting then a p_Values map[string]interface{} as
>>> a parameter of a function? - What would be a compatible data-type to pass
>>> as this parameter?
>>>
>>
>> The compiler accepts a type of "map[string]interface{}" because that is
>> well defined and obviously useful, Functions, such as those in the fmt
>> package, would not be useful if a function could not deal with the
>> "interface{}" type directly or indirectly. Your confusion is very common
>> and arises from the misconception that the Go map implementation will
>> magically convert map values from a concrete type (e.g., "int") to the
>> "any" type if that is what is needed in a particular context. One reason it
>> doesn't do so is the same reason it doesn't auto-magically convert any
>> other map value type; e.g., "int" to "float".
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/abd2cfe9-b651-46a3-bacf-5695446a06d5n%40googlegroups.com.
Re: [go-nuts] How to generalize parameters for a function
Hi Kurtis,
good to know that a map will always be "kind of" passed by reference to
functions. I have verified that with a short test-program on the playground
-> https://go.dev/play/p/HxdgpM-QozM
So in the next code-review all those *[maptype] references will be removed.
Things are very different in this case in other programming languages…
I understand the misconception and that a map[type]interface{} won't
automagically convert the data-type from the parameter into anything else.
My intention was to explain the compiler to just accept whatever is fed
into the function and just pass the data through to a function that uses
interface{} for a single parameter. That's all this function needs to do:
Accept a map of "something", get single values of "something" and pass them
on to another function that accepts a single parameter of "something".
I think i have found a solution in using a "generic" interface, stumbled
upon this web-site: https://www.geeksforgeeks.org/generics-in-golang/?ref=rp
And created a little test-program: https://go.dev/play/p/mOu1pmmfdX8
This should allow me to pass different types of maps - actually i only need
three types - to a generic function that passes the values on to another
(generic) function.
Thank you very much for your help.
Best regards from Charleston (WV),
Frank/2
Kurtis Rader schrieb am Dienstag, 14. März 2023 um 22:57:13 UTC-4:
> On Tue, Mar 14, 2023 at 7:07 PM Frank Jüdes wrote:
>
>> Thank you very much Ian!
>> I am using a pointer to the map because i want to pass the map by
>> reference, not by value.
>> Those maps can become pretty large and are being handed down through a
>> couple of function calls and i don't want them to be copied over and over
>> again.
>>
>
> Maps are a special-case. You can't pass them "by value" in the sense you
> mean because a "map" value is a very tiny structure that contains a pointer
> to the actual map. Possibly the oldest public discussion of the fact maps
> are reference type is this blog post: https://go.dev/blog/maps. Using a
> pointer does, in fact, avoid copying that very small data structure but is
> not necessary to keep from copying the entire map.
>
>
>> I read the document you referenced, but am not able to understand…
>> So i can use interface{} or any just to generalize simple types?
>> Why is the compiler accepting then a p_Values map[string]interface{} as a
>> parameter of a function? - What would be a compatible data-type to pass as
>> this parameter?
>>
>
> The compiler accepts a type of "map[string]interface{}" because that is
> well defined and obviously useful, Functions, such as those in the fmt
> package, would not be useful if a function could not deal with the
> "interface{}" type directly or indirectly. Your confusion is very common
> and arises from the misconception that the Go map implementation will
> magically convert map values from a concrete type (e.g., "int") to the
> "any" type if that is what is needed in a particular context. One reason it
> doesn't do so is the same reason it doesn't auto-magically convert any
> other map value type; e.g., "int" to "float".
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/35a85e3c-be23-4e61-8b59-fcdd2f93a4ecn%40googlegroups.com.
Re: [go-nuts] How to generalize parameters for a function
Thank you very much Ian!
I am using a pointer to the map because i want to pass the map by
reference, not by value.
Those maps can become pretty large and are being handed down through a
couple of function calls and i don't want them to be copied over and over
again.
I read the document you referenced, but am not able to understand…
So i can use interface{} or any just to generalize simple types?
Why is the compiler accepting then a p_Values map[string]interface{} as a
parameter of a function? - What would be a compatible data-type to pass as
this parameter?
Thank you very much in advance for your help.
Best regards from Charleston (WV),
Frank/2
Ian Lance Taylor schrieb am Dienstag, 14. März 2023 um 21:40:27 UTC-4:
> On Tue, Mar 14, 2023 at 6:27 PM Frank Jüdes wrote:
> >
> > i still somewhat new with Go and need a little tutoring: I have to
> create Excel files, using the excelize package and wrote a little function
> to store data from a map[string]int64 into a column within the worksheet:
> >
> > //
> -
> > // Store a slice of int64 data items into the cells of a column
> > //
> -
> > func SetColumnValuesInt64(xf *excelize.File,
> > p_SheetName string,
> > p_StartRow int,
> > p_Column rune,
> > p_CellStyle *excelize.Style,
> > p_Keys *UTL_StringSlice.T_StringSlice,
> > p_Values *map[string]int64) {
> > Row := p_StartRow
> > StyleID,_ := xf.NewStyle(p_CellStyle)
> > for _,Key := range(*p_Keys) {
> > CellAddress := fmt.Sprintf("%c%d",p_Column,Row)
> > xf.SetCellValue(p_SheetName,CellAddress,(*p_Values)[Key])
> > xf.SetCellStyle(p_SheetName,CellAddress,CellAddress,StyleID)
> > Row++
> > } // END for
> > } // END SetColumnValuesInt64
> >
> > Basically the function iterates through a slice of strings, containing
> the key-values for the data-map and then calls the SetCellValue function
> from the excelize package to store the number into the cell.
> > Now i have another set of data, stored into a map[string]float64 …
> > So i duplicated the above function, just replacing the red line with
> > p_Values *map[string]float64) {
> >
> > Basically it is the same code, just the parameter-type is different. I
> looked into the definition of the function SetCellValue and saw that it is
> using the empty interface as parameter for the value, so i tried to define
> my function with
> > p_Values *map[string]interface{}) {
> >
> > The function compiles fine, but if i try to use it with a
> *map[string]int64 as a parameter, the compiler objectst with the message
> »cannot use Amounts (variable of type *map[string]int64) as type
> *map[string]interface{} in argument to ExcelFormats.SetColumnValues«
> >
> > Can somebody please give me hint what i am doing wrong?
>
> First I'll note that it's quite unusual to use a pointer to a map.
> Maps are reference types. If you pass a map to a function, and that
> function adds values to the map, the caller will also see the new map
> entries.
>
> That said, the error message seems clear enough: a function that
> expects a pointer to map[string]any can't take an argument that is a
> pointer to map[string]int64. The types any and int64 are different
> types. You can't interchange them. See
> https://go.dev/doc/faq#covariant_types for a related issue.
>
> Ian
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/48a30be4-9229-4c6c-9503-12cbaa90c35an%40googlegroups.com.
[go-nuts] How to generalize parameters for a function
Hi Friends,
i still somewhat new with Go and need a little tutoring: I have to create
Excel files, using the *excelize* package and wrote a little function to
store data from a map[string]int64 into a column within the worksheet:
//
-
// Store a slice of int64 data items into the cells of a column
//
-
func SetColumnValuesInt64(xf *excelize.File,
p_SheetName string,
p_StartRow int,
p_Column rune,
p_CellStyle *excelize.Style,
p_Keys *UTL_StringSlice.T_StringSlice,
p_Values *map[string]int64) {
Row := p_StartRow
StyleID,_ := xf.NewStyle(p_CellStyle)
for _,Key := range(*p_Keys) {
CellAddress := fmt.Sprintf("%c%d",p_Column,Row)
xf.SetCellValue(p_SheetName,CellAddress,(*p_Values)[Key])
xf.SetCellStyle(p_SheetName,CellAddress,CellAddress,StyleID)
Row++
} // END for
} // END SetColumnValuesInt64
Basically the function iterates through a slice of strings, containing the
key-values for the data-map and then calls the *SetCellValue* function from
the *excelize* package to store the number into the cell.
Now i have another set of data, stored into a map[string]*float64 …*
So i duplicated the above function, just replacing the red line with
p_Values *map[string]float64) {
Basically it is the same code, just the parameter-type is different. I
looked into the definition of the function *SetCellValue *and saw that it
is using the empty interface as parameter for the value, so i tried to
define my function with
p_Values *map[string]interface{}) {
The function compiles fine, but if i try to use it with a *map[string]int64
as a parameter, the compiler objectst with the message »*cannot use Amounts
(variable of type *map[string]int64) as type *map[string]interface{} in
argument to ExcelFormats.SetColumnValues*«
Can somebody please give me hint what i am doing wrong?
Thank you very much in advance for your help.
Best regards from Charleston (WV),
Frank/2
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/ff6cbe1d-df62-42c3-aff0-e62b6631f772n%40googlegroups.com.
Re: [go-nuts] How does the go compiler treat initialized string variables?
Just had an idea: I printed the address of the initialized variable, and
for comparison another variable that was created in the heap:
Address of package variable: 0x818710
Address of Program variable: 0xc10028
Imho it is a safe assumption that the initialized data-structure is not
located in the heap, but somewhere in a text-segment.
Frank Jüdes schrieb am Dienstag, 1. November 2022 um 22:15:27 UTC-4:
> Thank you very much for the answer! - It actually turns out that my
> structure is a bit more complex than i though. The test-cases themself are
> a structure of seven strings and one in64 which are organized as a
> test-case list into a map[string] and those lists are organized into groups
> also as maps[strings]… 勞
> I am generating the variable that holds all this data straight out of two
> Database-tables, it looks like this
> var TestCaseGroup = T_TestCaseGroup {
> "cn=config": {
> "ds-cfg-add-missing-rdn-attributes": {
> RecommendedValue: "true",
> MessageClass: "Recommendation",
> MessageType: "Compatibility",
> MessageText: "It is recommended to enable this feature to make OUD
> more compatible to older applications."},
> "ds-cfg-allow-attribute-name-exceptions": {
> RecommendedValue: "false",
> MessageClass: "Severe Warning",
> MessageType: "Data-Quality",
> MessageText: "This feature should be disabled, to prevent the
> directory-schema to become incompatible with LDAP standards."},
> …
> And i have no idea how to figure out if these strings are being copied
> into the heap.
> But: The good news is, that the compiler is performing a string
> de-duplication, for example the string "Mild Error" appears in hundred of
> test-cases but appears only once in the whole program-code. - Tested with
> strings | grep 'Mild Error'. I think that's a good sign.
> Jan Mercl schrieb am Dienstag, 1. November 2022 um 15:47:47 UTC-4:
>
>>
>>
>> On Tue, Nov 1, 2022, 20:36 Frank Jüdes wrote:
>>
>>> I have to write a program that should verify the content of
>>> configuration-servers. It will need a lot of pre-initialized data to verify
>>> the actual content of a server, so it has to initialize many strings. What
>>> i know from other C-style languages is, that code like
>>>
>>> var MyString *string = 'Hello World!';
>>>
>>> Will result in having two identical copies of the string »Hello World!«
>>> in the memory: The first one within the program-code itself and a second
>>> copy somewhere in the heap-memory.
>>>
>>
>> I think the string backing array will be in the text segment as in C. The
>> string header will end in the data segment, provided it's a package scoped
>> variable, but the header has no direct equivalent in C.
>>
>> How will the go-compiler handle something like this:
>>>
>>> package main
>>> import ("fmt")
>>> type MyStruct struct {
>>> Text string
>>> Count int32
>>> }
>>> func main() {
>>> MyVar := MyStruct{Text: "Hello World!", Count: 20 }
>>> fmt.Printf("%#v\n",MyVar) }
>>>
>>> Will there be two copies of the string »Hello World!" in the memory or
>>> just one?
>>>
>>
>> The backing string array will exist only once, again in the text
>> segment, I believe, because there's no reason for making any copies of it
>> in this case.
>>
>>>
>> Not tested/verified
>>
>>>
>>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/535a5550-1c8c-4eaf-9d17-baa5a8d73e8bn%40googlegroups.com.
[go-nuts] Once again: Include files in go?
Hi friends, i have found a couple of threads about how to include c-headers into go-programs, but nothing that i could use for my rather unique challenge: I have an SQL-Database in which test-cases are being defined in a couple of tables. Those test-cases will be exported by a PL/SQL program as *go source-code*. Basically the Database is writing a piece of go source-code in which a single variable, representing a large data-structure is being initialized. This variable should be part of a package, defining functions on that structure. For now i am just copying and pasting the generated file into the go-package using an editor, but that will not be practical for much longer, as the amount of data is increasing rapidly… So what i am looking for is the classic c-style include: package package_name import ( … ) type … #include GeneratedDataFromDB func()… it is not something my life is depending on, i can always use Linux tools to *cat* some files together, but a simple #include - or similar would be more elegant. Thank you very much in advance for your help. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7c1524a5-6c45-4ca8-862e-84f0b620b18fn%40googlegroups.com.
Re: [go-nuts] How does the go compiler treat initialized string variables?
Thank you very much for the answer! - It actually turns out that my
structure is a bit more complex than i though. The test-cases themself are
a structure of seven strings and one in64 which are organized as a
test-case list into a map[string] and those lists are organized into groups
also as maps[strings]… 勞
I am generating the variable that holds all this data straight out of two
Database-tables, it looks like this
var TestCaseGroup = T_TestCaseGroup {
"cn=config": {
"ds-cfg-add-missing-rdn-attributes": {
RecommendedValue: "true",
MessageClass: "Recommendation",
MessageType: "Compatibility",
MessageText: "It is recommended to enable this feature to make OUD
more compatible to older applications."},
"ds-cfg-allow-attribute-name-exceptions": {
RecommendedValue: "false",
MessageClass: "Severe Warning",
MessageType: "Data-Quality",
MessageText: "This feature should be disabled, to prevent the
directory-schema to become incompatible with LDAP standards."},
…
And i have no idea how to figure out if these strings are being copied into
the heap.
But: The good news is, that the compiler is performing a string
de-duplication, for example the string "Mild Error" appears in hundred of
test-cases but appears only once in the whole program-code. - Tested with
strings | grep 'Mild Error'. I think that's a good sign.
Jan Mercl schrieb am Dienstag, 1. November 2022 um 15:47:47 UTC-4:
>
>
> On Tue, Nov 1, 2022, 20:36 Frank Jüdes wrote:
>
>> I have to write a program that should verify the content of
>> configuration-servers. It will need a lot of pre-initialized data to verify
>> the actual content of a server, so it has to initialize many strings. What
>> i know from other C-style languages is, that code like
>>
>> var MyString *string = 'Hello World!';
>>
>> Will result in having two identical copies of the string »Hello World!«
>> in the memory: The first one within the program-code itself and a second
>> copy somewhere in the heap-memory.
>>
>
> I think the string backing array will be in the text segment as in C. The
> string header will end in the data segment, provided it's a package scoped
> variable, but the header has no direct equivalent in C.
>
> How will the go-compiler handle something like this:
>>
>> package main
>> import ("fmt")
>> type MyStruct struct {
>> Text string
>> Count int32
>> }
>> func main() {
>> MyVar := MyStruct{Text: "Hello World!", Count: 20 }
>> fmt.Printf("%#v\n",MyVar) }
>>
>> Will there be two copies of the string »Hello World!" in the memory or
>> just one?
>>
>
> The backing string array will exist only once, again in the text segment,
> I believe, because there's no reason for making any copies of it in this
> case.
>
>>
> Not tested/verified
>
>>
>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a7d42a59-aafe-4fad-8988-940301aa8db5n%40googlegroups.com.
[go-nuts] How does the go compiler treat initialized string variables?
I have to write a program that should verify the content of
configuration-servers. It will need a lot of pre-initialized data to verify
the actual content of a server, so it has to initialize many strings. What
i know from other C-style languages is, that code like
var MyString *string = 'Hello World!';
Will result in having two identical copies of the string »Hello World!« in
the memory: The first one within the program-code itself and a second copy
somewhere in the heap-memory.
How will the go-compiler handle something like this:
package main
import ("fmt")
type MyStruct struct {
Text string
Count int32
}
func main() {
MyVar := MyStruct{Text: "Hello World!", Count: 20 }
fmt.Printf("%#v\n",MyVar) }
Will there be two copies of the string »Hello World!" in the memory or just
one? As said, mMy code will contain a gazillion of pre-defined string
variables and having each string allocate two copies of itself in memory
would be bad for small systems.
Thank you very much in advance for your help.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20c9e775-fee8-4ac4-90e7-032ce37909e9n%40googlegroups.com.
