-
Notifications
You must be signed in to change notification settings - Fork 22
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
base: develop
Are you sure you want to change the base?
Fixed go header code #139
Conversation
w.Writeln(" // Injected Components") | ||
for _, subComponent := range(component.ImportedComponentDefinitions) { | ||
subNameSpace := subComponent.NameSpace | ||
w.Writeln(" \"../%s\"", subNameSpace) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 ".."?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(...)
anddefer C.free(...)
in the next line.
No description provided.