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: 0xc000010028
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 <jue...@gmail.com> 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.
