I would like to get the size of a structure in GAE/Go.
I read this post and wrote the code as below.
import (
"reflect"
"unsafe"
)
func GetSize(T interface{}) {
size := reflect.TypeOf(T).Size()
return int((*int)(unsafe.Pointer(size)))
}
But this code does not work because GAE does not allow to import unsafe.
How can I do this in GAE/Go?
Your proposed solution is not valid code, it has multiple errors.
For example GetSize() has no result type, so you couldn't return anything.
Next, the expression you return is also a syntax error, it attempts to convert an *int pointer to int which is not valid.
You need to dereference the pointer first, so the correct syntax would be:
func GetSize(T interface{}) int {
size := reflect.TypeOf(T).Size()
return int(*(*int)(unsafe.Pointer(size)))
}
But. It makes no sense. reflect.Type.Size() already returns the size (the number of bytes needed to store a value of the given type), so there is no need of that unsafe magic. What may be confusing is that its return type is uintptr, but you may simply use that value after converting it to int for example.
Simply use:
func GetSize(v interface{}) int {
return int(reflect.TypeOf(v).Size())
}
Testing it:
fmt.Println("Size of int:", GetSize(int(0)))
fmt.Println("Size of int64:", GetSize(int64(0)))
fmt.Println("Size of [100]byte:", GetSize([100]byte{}))
Output (try it on the Go Playground):
Size of int: 4
Size of int64: 8
Size of [100]byte: 100
One thing you must not forget: this GetSize() will not recurisvely examine the size of the passed value. So for example if it's a struct with a pointer field, it will not "count" the size of the pointed value, only the size of the pointer field.
Constructing a GetSize() that recurisvely counts the total size of a complex data structure is non-trivial due to types like map. For details, see How to get variable memory size of variable in golang?
Related
This is well known code to compute array length in C:
sizeof(array)/sizeof(type)
But I can't seem to find out the length of the array passed as an argument to a function:
#include <stdio.h>
int length(const char* array[]) {
return sizeof(array)/sizeof(char*);
}
int main() {
const char* friends[] = { "John", "Jack", "Jim" };
printf("%d %d", sizeof(friends)/sizeof(char*), length(friends)); // 3 1
}
I assume that array is copied by value to the function argument as constant pointer and reference to it should solve this, but this declaration is not valid:
int length(const char**& array);
I find passing the array length as second argument to be redundant information, but why is the standard declaration of main like this:
int main(int argc, char** argv);
Please explain if it is possible to find out the array length in function argument, and if so, why is there the redundancy in main.
sizeof only works to find the length of the array if you apply it to the original array.
int a[5]; //real array. NOT a pointer
sizeof(a); // :)
However, by the time the array decays into a pointer, sizeof will give the size of the pointer and not of the array.
int a[5];
int * p = a;
sizeof(p); // :(
As you have already smartly pointed out main receives the length of the array as an argument (argc). Yes, this is out of necessity and is not redundant. (Well, it is kind of reduntant since argv is conveniently terminated by a null pointer but I digress)
There is some reasoning as to why this would take place. How could we make things so that a C array also knows its length?
A first idea would be not having arrays decaying into pointers when they are passed to a function and continuing to keep the array length in the type system. The bad thing about this is that you would need to have a separate function for every possible array length and doing so is not a good idea. (Pascal did this and some people think this is one of the reasons it "lost" to C)
A second idea is storing the array length next to the array, just like any modern programming language does:
a -> [5];[0,0,0,0,0]
But then you are just creating an invisible struct behind the scenes and the C philosophy does not approve of this kind of overhead. That said, creating such a struct yourself is often a good idea for some sorts of problems:
struct {
size_t length;
int * elements;
}
Another thing you can think about is how strings in C are null terminated instead of storing a length (as in Pascal). To store a length without worrying about limits need a whopping four bytes, an unimaginably expensive amount (at least back then). One could wonder if arrays could be also null terminated like that but then how would you allow the array to store a null?
The array decays to a pointer when passed.
Section 6.4 of the C FAQ covers this very well and provides the K&R references etc.
That aside, imagine it were possible for the function to know the size of the memory allocated in a pointer. You could call the function two or more times, each time with different input arrays that were potentially different lengths; the length would therefore have to be passed in as a secret hidden variable somehow. And then consider if you passed in an offset into another array, or an array allocated on the heap (malloc and all being library functions - something the compiler links to, rather than sees and reasons about the body of).
Its getting difficult to imagine how this might work without some behind-the-scenes slice objects and such right?
Symbian did have a AllocSize() function that returned the size of an allocation with malloc(); this only worked for the literal pointer returned by the malloc, and you'd get gobbledygook or a crash if you asked it to know the size of an invalid pointer or a pointer offset from one.
You don't want to believe its not possible, but it genuinely isn't. The only way to know the length of something passed into a function is to track the length yourself and pass it in yourself as a separate explicit parameter.
As stated by #Will, the decay happens during the parameter passing. One way to get around it is to pass the number of elements. To add onto this, you may find the _countof() macro useful - it does the equivalent of what you've done ;)
First, a better usage to compute number of elements when the actual array declaration is in scope is:
sizeof array / sizeof array[0]
This way you don't repeat the type name, which of course could change in the declaration and make you end up with an incorrect length computation. This is a typical case of don't repeat yourself.
Second, as a minor point, please note that sizeof is not a function, so the expression above doesn't need any parenthesis around the argument to sizeof.
Third, C doesn't have references so your usage of & in a declaration won't work.
I agree that the proper C solution is to pass the length (using the size_t type) as a separate argument, and use sizeof at the place the call is being made if the argument is a "real" array.
Note that often you work with memory returned by e.g. malloc(), and in those cases you never have a "true" array to compute the size off of, so designing the function to use an element count is more flexible.
Regarding int main():
According to the Standard, argv points to a NULL-terminated array (of pointers to null-terminated strings). (5.1.2.2.1:1).
That is, argv = (char **){ argv[0], ..., argv[argc - 1], 0 };.
Hence, size calculation is performed by a function which is a trivial modification of strlen().
argc is only there to make argv length calculation O(1).
The count-until-NULL method will NOT work for generic array input. You will need to manually specify size as a second argument.
This is a old question, and the OP seems to mix C++ and C in his intends/examples. In C, when you pass a array to a function, it's decayed to pointer. So, there is no way to pass the array size except by using a second argument in your function that stores the array size:
void func(int A[])
// should be instead: void func(int * A, const size_t elemCountInA)
They are very few cases, where you don't need this, like when you're using multidimensional arrays:
void func(int A[3][whatever here]) // That's almost as if read "int* A[3]"
Using the array notation in a function signature is still useful, for the developer, as it might be an help to tell how many elements your functions expects. For example:
void vec_add(float out[3], float in0[3], float in1[3])
is easier to understand than this one (although, nothing prevent accessing the 4th element in the function in both functions):
void vec_add(float * out, float * in0, float * in1)
If you were to use C++, then you can actually capture the array size and get what you expect:
template <size_t N>
void vec_add(float (&out)[N], float (&in0)[N], float (&in1)[N])
{
for (size_t i = 0; i < N; i++)
out[i] = in0[i] + in1[i];
}
In that case, the compiler will ensure that you're not adding a 4D vector with a 2D vector (which is not possible in C without passing the dimension of each dimension as arguments of the function). There will be as many instance of the vec_add function as the number of dimensions used for your vectors.
int arsize(int st1[]) {
int i = 0;
for (i; !(st1[i] & (1 << 30)); i++);
return i;
}
This works for me :)
length of an array(type int) with sizeof:
sizeof(array)/sizeof(int)
Best example is here
thanks #define SIZE 10
void size(int arr[SIZE])
{
printf("size of array is:%d\n",sizeof(arr));
}
int main()
{
int arr[SIZE];
size(arr);
return 0;
}
I am new to LeetCode and am trying to improve upon my problem solving techniques. I am attempting to solve the Two Sum Problem in C and have run into trouble with the final return statement. The code initially provided to me by LeetCode was a function called "int* twoSum" and the goal is to find the two indices in an array that produce the target number. The function lists a couple parameters that I assumed were provided in main since it was not shown.
I changed the name of the function to just "int twosum" and removed the int* returnSize because I am not a big fan of unnecessary pass by address instead of by value and felt it wouldn't have a significant impact. However, after trying to run my code I run into the warning error: "returning 'int *' from a function with return type 'int' makes integer from pointer without a cast"
Could someone who understands this issue or has solved the problem before on LeetCode please provide insight as to what I need to correct? Thank you.
int twoSum(int *nums, int numsSize, int target){
int outerCount; //loop control variable for outer loop
int innerCount; //loop control variable for inner loop
int array[2]; //array that stores indices of numbers that produce target
for(outerCount = 0; outerCount < numsSize; outerCount++)
for(innerCount = outerCount + 1; innerCount < numsSize; innerCount++)
{
if(nums[outerCount] + nums[innerCount] == target)
{
array[0] = outerCount;
array[1] = innerCount;
}
}
return array;
}
The problem asks you to return two integers (indices), so a return type of int is pretty clearly incorrect. int is a single integer; two return two integers you need to return an array of int, or struct containing two integer members. C doesn't allow you to return arrays by value, so if you need to return an array, you need to return an int*. That's just the way C is.
Note that since you cannot return an array by value, you also cannot return a pointer to an automatically allocated array, since that object's lifetime will end when the function returns. So you need to dynamically allocate the array (unless it is passed to your function as an argument, which is a very common style). In this case, it is pretty clear that a dynamically allocated return value is desired, based on the comment:
/* Note: The returned array must be malloced, assume caller calls free(). */
Whether or not you like this style, you will need to conform to it for this exercise, since it is pretty clear that the caller will call free()on the returned pointer, and calling free() on a pointer not originally returned by malloc is Undefined Behaviour (and very likely to crash your program). (You can free(NULL), but that's also a violation of the calling contract, which will segfault when the caller tries to examine the non-existent return values.)
C does let you return structs by value, but if you are going to return a struct, you and the caller need to agree on its declaration (the names of its members, for example).
This question already has answers here:
How to find the size of an array (from a pointer pointing to the first element array)?
(17 answers)
Closed 4 years ago.
EDIT: while someone thought this question is the same as the one they posted a link to. It is a very different question.
consider the following:
#define HUNDRED 100
typedef WCHAR BUFFER_SPACE[HUNDRED];
the type BUFFER_SPACE is an array with a size of 200 bytes (assume UTF16)
In most cases, declaring a variable such as:
BUFFER_SPACE abuffer = { 0 };
wprintf(L"sizeof abuffer : %zd\n", sizeof(abuffer));
will result in wprintf outputting 200 (as expected.)
Now, consider the following simple sample program:
#include "stdafx.h"
#include <Windows.h>
#include <WinNt.h>
#define HUNDRED 100
typedef WCHAR BUFFER_SPACE[HUNDRED];
void Function(BUFFER_SPACE abuffer)
{
BUFFER_SPACE anotherbuffer = { 0 };
wprintf(L"sizeof abuffer : %zd\n", sizeof(abuffer)); // 8
wprintf(L"sizeof *abuffer : %zd\n", sizeof(*abuffer)); // 2
wprintf(L"sizeof anotherbuffer : %zd\n", sizeof(anotherbuffer)); // 200
// a highly undesirable solution is to apply sizeof to the type but, if the
// type of the parameter changes, the programmer has to be aware that the
// original/old type is being used in sizeof() someplace else in the
// function/program
wprintf(L"sizeof BUFFER_SPACE : %zd\n", sizeof(BUFFER_SPACE)); // 200
getchar();
}
int main()
{
BUFFER_SPACE abuffer = { 0 };
WCHAR anotherbuffer[HUNDRED] = { 0 };
wprintf(L"sizeof abuffer : %zd\n", sizeof(abuffer));
wprintf(L"sizeof anotherbuffer : %zd\n", sizeof(anotherbuffer));
wprintf(L"\n");
Function(abuffer);
return 0;
}
I wanted to get the entire size of the buffer parameter in the function. Using VC++ and compiling for 64 bit,
sizeof(abuffer) is 8 which makes sense since it is a pointer to the array
sizeof(*abuffer) is 2 which I consider rather questionable but, it is not something I want to debate.
sizeof(BUFFER_SPACE) is 200 as it should be.
My question is: Is there a way to get the value of 200 from the parameter (abuffer in this case) or is using the type the only way to get it ?
Let us start by looking at how arrays are passed to functions -
Quoting C11, chapter ยง6.7.6.3p7
A declaration of a parameter as "array of type" shall be adjusted to "qualified pointer to type", where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation. ...
This means the prototype of your function effectively becomes -
void Function(WCHAR *abuffer);
In the body of this function, the compiler doesn't have the type information any more. It could be WCHAR[100], WCHAR[200] or even WCHAR[].
I think you already understand why sizeof(abuffer) is 8 -- because it is a pointer.
Now coming to sizeof(*abuffer). The type of abuffer is WCHAR*, so the type of *abuffer will be WCHAR and hence sizeof(*abuffer) == sizeof(WCHAR) == 2.
To answer your main question, is there a way for the function to know the size of the buffer, there are 2 ways -
You pass along the information as a second parameter. But this is not required, since the size will always be sizeof(BUFFER_SPACE).
You pass a pointer to BUFFER_SPACE instead of BUFFER_SPACE. You can change your prototype as -
void Function(BUFFER_SPACE *abuffer);
and use *abuffer instead of abuffer everywhere. sizeof(*abuffer) will now also return 200, because the type information is rightly preserved.
To complete the answer by Ajay Brahmakshatriya: in your particular case, you know the size (actually the dimension) of the array, and you could use the preprocessor constant HUNDRED.
But in general (and notably for pointers to heap-allocated arrays) there is no automatic way to get their size, and you should adopt some convention regarding array sizes. A very usual one is to pass the dimension of the array as another parameter to functions. A typical example is the fwrite standard function, or the qsort one, or the snprintf.
You could also consider using structures with flexible array members, with the convention that some fixed field gives the size of that flexible array member.
Then you could think in terms of some abstract data type. I gave a simple Matrix example here. But you still need conventions.
Notice that C is such a low-level language that coding conventions are really important (in particular when you deal with pointers to heap allocated -malloc-ed or calloc-ed- data: you should define and document some convention explaining who and how these pointers should be free-d, and what is the size of the pointed data).
Remember than in C arrays decay into pointers (e.g. when you pass them as parameters, like to your Function), and the sizeof some pointer is always fixed (on my x86-64 Linux system it is always 8) and does not depend of the pointed memory region (and of it allocated size, if any).
is there a way to get the value of 200 from the parameter
No, not in general. You need conventions to deal with that. Very often you pass the dimension as some additional parameter (even your main should have both an argc & the argv, for example). Sometimes it is known differently (thru some field in some structure, some global variable, etc...).
I'm writing a library and I want to return an array (or write to an array) of an unspecific type to the caller. The type can vary, depending on who calls - I can, however, create as many objects of said type from within my function. One way would be that the caller creates an array and the callee fills that - however, there is no way of telling how long this array is going to be. (Is there a way that the callee makes the caller's array bigger? Remember, the callee only sees x interface{}...)
The other way which I chose because I don't see how above is possible, is that the caller gives me the pointer of his specific type and I redirect it to the array of objects which I created.
Below is my solution. My question: why is the array empty after the function call? They are pointing to the same array after my operation, they should be the same. Am I overlooking something? I thought about GC, but it couldn't be that fast, could it?
http://play.golang.org/p/oVoPx5Nf84
package main
import "unsafe"
import "reflect"
import "log"
func main() {
var x []string
log.Printf("before: %v, %p", x, x)
manipulate(&x)
log.Printf("after: %v, %p", x, x)
}
func manipulate(target interface{}) {
new := make([]string, 0, 10)
new = append(new, "Hello", "World")
log.Printf("new: %v, %p", new, new)
p := unsafe.Pointer(reflect.ValueOf(target).Pointer())
ptr := unsafe.Pointer(reflect.ValueOf(new).Pointer())
*(*unsafe.Pointer)(p) = ptr
}
First of all, unsafe is usually a bad idea. So is reflection, but unsafe is at least an order of magnitude worse.
Here is your example using pure reflection (http://play.golang.org/p/jTJ6Mhg8q9):
package main
import (
"log"
"reflect"
)
func main() {
var x []string
log.Printf("before: %v, %p", x, x)
manipulate(&x)
log.Printf("after: %v, %p", x, x)
}
func manipulate(target interface{}) {
t := reflect.Indirect(reflect.ValueOf(target))
t.Set(reflect.Append(t, reflect.ValueOf("Hello"), reflect.ValueOf("World")))
}
So, why didn't your unsafe way work? Unsafe is extremely tricky and at times requires understanding the internals. First, some misconceptions you have:
You are using arrays: you are not, you are using slices. Slices are a view of an array. They contain within them a pointer to the data, a length, and a capacity. They are stucts internally and not pure pointers.
Pointer returns the pointer only if it is a pointer: it can actually return a value for many types like a slice.
From http://golang.org/pkg/reflect/#Value.Pointer:
If v's Kind is Slice, the returned pointer is to the first element of the slice. If the slice is nil the returned value is 0. If the slice is empty but non-nil the return value is non-zero.
Arrays are pointers: in Go, arrays are actually values. That means they are copied when passed to other functions or assigned. It also means the .Pointer method wouldn't work.
You are assigning a pointer to an array to a slice type. By luck, the implementation of slices used internally has the data pointer first so you are actually setting the internal array pointer used by the slice. I must stress that is is effectively pure accident. Even still, you are not setting the length and capacity of the slice so it still prints zero elements.
Unsafe lets you do things at such a low level that the actual results aren't really defined. It is best to stay away from it unless you really know what you are doing. Even then, be aware that things can can change and what works today may not work in the next version of Go or another implementation.
I am trying to interface with a Windows dll using Go. The dll function I want to use accepts a pointer to a byte array. Therefore I need to give it that byte array.
I am using the syscall libary to call the dll, as demonstrated here. My basic requirements are:
I am given the required size for the byte array
I create the byte array
I must get a pointer to the byte array
I then pass the pointer to the Windows dll
I can't figure out how to create a byte array in go, and get a pointer to it. This is obviously an unsafe operation, and the unsafe library can be helpful, but I need to create a dynamic-length byte array in the first place. Creating a slice with "make" doesn't help me, unless I can get a pointer to the slice's backing array.
Has anyone else encountered this or have any ideas?
I think syscall.ComputerName implementation https://golang.org/src/syscall/syscall_windows.go#395 would be a good example. It uses uint16s, not bytes, but otherwise ...
In your case it would be ptr := &myslice[0].
Alex
Well I found one gross solution. Apparently the structure of a slice contains a pointer to the backing byte array, the length of the backing byte array, and then the capacity of the backing byte array.
I am only interested in a pointer to the byte array, so I only need the first member of the slice's internal data.
Go's unsafe.Pointer will not cast a slice to an unsafe pointer, but it will cast a pointer to a slice as an unsafe pointer. Since I can cast an unsafe pointer to any old type of pointer I want, I can cast it to a pointer-to-a-pointer, which recovers the first member of the slice's internal data.
Here's a working example. I wanted a uintptr but you could cast it to any pointer type.
package main
import (
"fmt"
"unsafe"
)
func main() {
// Arbitrary size
n := 4
// Create a slice of the correct size
m := make([]int, n)
// Use convoluted indirection to cast the first few bytes of the slice
// to an unsafe uintptr
mPtr := *(*uintptr)(unsafe.Pointer(&m))
// Check it worked
m[0] = 987
// (we have to recast the uintptr to a *int to examine it)
fmt.Println(m[0], *(*int)(unsafe.Pointer(mPtr)))
}
If you wanted a *int instead, you could do mPtr := *(**int)(unsafe.Pointer(&m))
This works as long as a slice maintains this internal data structure. I am definitely open to a more robust solution that doesn't depend on the structure of Go's internals.