Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed go header code #139

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Fixed go header code #139

wants to merge 2 commits into from

Conversation

alexanderoster
Copy link

No description provided.

w.Writeln(" // Injected Components")
for _, subComponent := range(component.ImportedComponentDefinitions) {
subNameSpace := subComponent.NameSpace
w.Writeln(" \"../%s\"", subNameSpace)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Relative imports does not work when using modules, which is the standard go dependency managment. More info

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, how would we integrate this then? Just leave away the ".."?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing the .. don't work, all imports that are not from the standard library needs to be prefixed with the name of the module, even if the package is in the same module. Therefor the name of the module should be known at generation time if you want to import another package.

Another approach would be to define an interface that is fulfilled by the injected component and use it instead of importing it, this way the generated code is decoupled from the location of the injected code. This is possible in Go but not in other languages because a struct doesn't need to specify that it is implementing an interface to be used as so.

Example using the calculator example:

// NumberVariable is infered from Numbers.xml
type NumberVariable interface {
  GetValue() float64
  SetValue(float64)
}

type Calculator struct {
  ...
}
func (c *Calculator) GetEnlistedVariable(index uint32) NumberVariable {
  ...
}

@@ -724,7 +749,7 @@ func getGoType(paramType, namespace, paramClass, paramName string, isPtr bool) (
tp.Type = ptrStr + "string"
tp.CType = ptrStr + "*C.char"
tp.CToGo = ""
tp.GoToC = fmt.Sprintf("(%s)(unsafe.Pointer(&[]byte(%s)[0]))", tp.CType, paramName)
tp.GoToC = fmt.Sprintf("C.CString(%s)", paramName)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

C.CString is allocated in the C heap using malloc and it should be freed after used, so this change will leak all string casts.
I believe there is no need to allocate a new c string when a c function requires one and it should be safe to just pass the reference to the memory backing the go string, it won't be relocated nor freed at least until the go wrapper function finishes.
When casting a string from c to go we are just taking a temporary

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue with the old code was the the string was not nullterminated, causing a lot of memory issues.

Copy link

@qmuntal qmuntal Aug 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I didn't remember that go string are not null-terminated. There are two option then:

  • Append a null termination char to the end of the string: tp.GoToC = fmt.Sprintf("(%s)(unsafe.Pointer(&[]byte(%s+"\x00")[0]))", tp.CType, paramName). I´m not sure that this would work on all cases.
  • Use C.CString(...) and defer C.free(...) in the next line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants