Sizeof Operator

[silmaril]

There should be a LabVIEW primitive that returns the size of the connected data type in bytes, similar to sizeof() in C.

I know this can be done using "Flatten To String" and "String Length", but that's only a workaround since this way all the data has to be copied just to get the size information.

[GregR]

The Flatten to String approach actually does not provide the same answer that the C sizeof() would. Sometimes individual types are a different size in memory than they are when flattened. For example extendeds are flattened as 16 bytes but their size in memory varies depending on the platform. Sometimes aggregate types contain padding bytes in memory that are not included in flat data. For example a cluster of an int8 and an int32 would contain 3 bytes of padding between its elements in a 64-bit LabVIEW on Windows.

Another factor is variably sized data like strings and arrays. When flattened, the length of a string in a cluster would be included in the size. In memory the length of the string does not affect the size of the cluster because it is in a separate allocation.

I can imagine 3 different use cases that each call for different answers.

1. (top level in memory size) I want to get the in memory size of a cluster so I can pass it into a call library node and confirm in my C code that the size matches what I expect.

2. (total in memory size) I want to know how many bytes of memory a data structure is using in memory as a gauge of my memory requirements.

3. (flat size) I want to know how big my data will be when flattened so I can preallocate a file. 

Which are important? If you just need flat size, perhaps a length output  on Flatten to String would be sufficient. We could code it in such a way that the length can be computed without really flattening the data when the string is unwired.

[silmaril]

You are right. In fact we'd need three different variations of this.

From my point of view, you already ordered those variations after their priorities (1 most important .. 3 least).

[AristosQueue (NI)]

Regarding use 1: We publish the top-level data sizes for all objects in LV. Configuration of a Call Library node is a static thing. Why do you need to get this information programmatically?

Regarding use 2: The Profile VIs tool gives you a much better answer to this estimate than any single piece of data would.

Regarding use 3: Flatten the string and ask its length. Since you're going to be flattening the data anyway, you haven't lost anything by doing this. 

[silmaril]

use 1:

What do you mean with "publish"? Is there any way of dertermining the top-level data size of a cluster programmatically that I am not aware of?

I agree that using this in a DLL call is a static thing. Still, it would be good programming practice to use some kind of sizeof() in combination with a typedef cluster rather than calculating the size value yourself. This way the compiler would give me some feedback about the size, so I could check if my calculation was correct. If the cluster typedef changes for any reason, the rest of the code doesn't need any changes.

If you had to do this in C, would you even think about calculating the size of a struct yourself, or would you rather write "sizeof(my_struct)" in the appropriate place?

use 2:

The VI profiler has a huge impact on the way an application behaves (i.e. it slows down quite a bit). There are cases in which I don't want to profile my whole application, but still need exact information about a certain data structure. Getting the size of a data structure programmatically would also enable me to log it's memory usage over time and evaluate the log file later.

Another important thought: How am I supposed to do this profiling in an executable?

use 3:

This is the least important use case (from  my point of view). Still it would be nice to have a size output on the flatten to string primitive.

But this really is a "nice to have" feature, if use cases 1 and 2 are covered in other ways.

[Darren]

Any idea that has received less than 8 kudos within 8 years after posting will be automatically declined.