This question already has answers here:
Type converting slices of interfaces
(9 answers)
Closed 10 months ago.
I need some clearance of golang behavior. Imagine we have an interface with some method, and we have a type that implements that method. If we assign pointer to type to variable defined as interface, golang allows us to do it.
But when we try to assign slice of pointers to type to the variable defined to contain slice of interfaces, golang panics...
Can anyone explain why?
Here is an example
as it came in here:
they do not have the same representation in memory.
Related
This question already has answers here:
How do I express mutually recursive data structures in safe Rust?
(4 answers)
How to model complex recursive data structures (graphs)?
(1 answer)
Why can't I store a value and a reference to that value in the same struct?
(4 answers)
Closed 6 days ago.
I need to implement a tree-like data structure, in which each node possibly has 2 children, and each child node has a reference to its parent (except root node).
Here is a sketch:
strcut Node {
parent: Option< ??? >,
child_1: Option<Box<Node>>,
child_2: Option<Box<Node>>
}
As you can see I don't know what type should a parent field be. Can it be just a plain unsafe pointer? What is the proper way of implementing it?
This question already has answers here:
Pointers vs. values in parameters and return values
(5 answers)
Closed 7 years ago.
I'm new to the Go Language, and have only minimal background in C/C++, so naturally I'm struggling with the idea of when to use pointers and when not to use pointers. Although this question might be considered open-ended, I'm wondering what some guidelines on when to return structs and when to return pointers, (and equivalently when to accept structs / pointers as arguments).
From what I can guess, the following statements hold true:
structs are passed into functions by value. That is, a copy of a structure is made when passing it into a function.
if I want to pass a structure by reference, then I would instead use a pointer argument in the function definition, and use the addressof operator when calling the function.
The reason why I would want to pass in a structure by reference is because either the structure I'm passing in is large, and it would be taxing on memory to pass it by value (unlikely) or if I want to make changes to the copy that I'm passing in (more likely).
As a corollary to 3.), I should pass by value unless I have one of the reasons above to pass by reference.
Are my assumptions correct? Or am I missing the mark on pointers?
Your assumptions are correct. About #3, Go is concurrent language and passing by reference in goroutines make them all read same structure which is safe, but also make them modify same structure which is dangerous.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Simplified Question:
Is it practical for a programmer to keep track of the addresses of variables, so that a variable's address can be used as a point of data on that variable?
Original Question:
I am attempting to wrap my head around how variables are stored and referenced by address using pointers in Go.
As a general principal, is it ever useful to assign a variable's address directly? I can imagine a situation in which data could be encoded in the physical (virtual) address of a variable, and not necessarily the value of that variable.
For instance, the 1000th customer has made a 500 dollars of purchases. Could I store an interger at location 1000 with a value of 500?
I know that the common way to do something like this is with an array, where the variable at position 999 corresponds to the 1000th customer, but my question is not about arrays, it's about assigning addresses directly.
Suppose I'm dealing with billions of objects. Is there an easy way to use the address as part of the data on the object, and the value stored at that location as different data?
for instance, an int at address 135851851904 holds a value of 46876, 135851851905 holds 123498761, etc. I imagine at this point an array or slice would be far too large to be efficient.
Incidentally, if my question due to a misunderstanding, is there a resource someone can provide which explains the topic in deep, but understandable detail? I have been unable to find a good resource on the subject that really explains the details.
is it ever useful to assign a variable's address directly?
You can use the unsafe package to achieve that but the idea is that you don't do it unless you have a concrete and otherwise unsolvable use-case that requires it.
Could I store an interger at location 1000 with a value of 500?
As mentioned before it is possible but choosing an arbitrary address won't get you far because it may not even be mapped. If you write to such a location you'll get a access violation (and your program will crash). If you happen to hit a valid address number you'll likely be overwriting other data that your program needs to run.
Is there an easy way to use the address as part of the data on the object, and the value stored at that location as different data?
In general no.
If you managed to build some kind of algebraic structure closed under the operations by which your own pointer-arithmetic is defined in a finite set of addresses which you can guarantee to always be a valid virtual memory segment then yes but it defeats the purpose of using a garbage collected language. Additionally it would be hell to read such a program.
The Go docs say (emphasis added):
Programs using times should typically store and pass them as values, not pointers. That is, time variables and struct fields should be of type time.Time, not *time.Time. A Time value can be used by multiple goroutines simultaneously.
Is the last sentence (about using a Time value in multiple goroutines simultaneously) the only reason that they should "typically" be stored and passed as a value, rather than a pointer? Is this common to other structs as well? I tried looking for any logic that specifically enables this in the time.Time declaration and methods, but didn't notice anything special there.
Update: I often have to serve JSON representations of my structs, and I'd rather omit empty/uninitialized times. The json:",omitempty" tag doesn't work with time.Time values, which appears to be the expected behavior, but the best workaround seems to be to use a pointer, which goes against the advice in the docs quoted above.
It's common for many kind of simple values.
In Go, when some value isn't bigger than one or two words, it's common to simply use it as a value instead of using a pointer. Simply because there's no reason to use a pointer if the object is small and you don't pass it to be changed.
You might have to unlearn the practice of languages where everything structured couldn't be handled as values. It's probably natural for you to use integers or floating point numbers as values, not pointers. Why not do the same for times ?
Regarding your precise problem with JSON and assuming you don't want to write a specific Marshaller just for this, there's no problem in using a *time.Time. In fact this issue was already mentioned in the golang-nuts list.
I am reading the ARM procedure call standard:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0041c/Cegbidie.html
It says:
Only APCS variants that do not require a frame pointer register are supported. APCS variants that require a frame pointer register are obsolete. These variants are documented for backwards compatibility only.
Can someone tell me why? I thought one needs the frame pointer if the stack frame size is unknown at the compile time.
Assuming that the calling convention specifies how the stack gets cleaned up on function exit, you only need to have the stack pointer. The compiler can keep track of all the stack manipulation within the function, so there is no need to keep that information around in a separate register.
It certainly is convenient, but it's not strictly necessary.