I have found the usual answer for determining the size on an array - 'variable = sizeof buffer/sizeof *buffer;' or similar which gives the declared size
Other than passing a counter variable around when an array is 'filled', is there a way (a command or function - something similar to the above 1 liner) to find the used number of elements in a given array?
And I don't mean searching for an end of line character or implementing a circular buffer. I only expect between 5 and 25 Bytes in any given transaction.
Edit:- for omissions in original post (as requested)
Language C (via Atmel Studio)
8bit Bytes (non characters)
I don't know the meaning of 'strong-typed' and 'associative', but eventually it will be semi random bytes from a device and not fixed numbers like in a string
Fixed size declared array (ultimately volatile)
Thanks
The C standard generally does not provide any way for tracking or determining which or how many elements of an array are used.
Related
I have coded a program that reads an integers & tells if it's greater or not. I have done it with an array & initialized it with some numbers(As a test if the program works). Now I have to read it from a File with a lot of integers, but I don't know the length of the File. How can I determinate the size of the Array if I don't know the length?
Either you do it on the fly (read and process one line at a time -> one number at a time), or you need to allocate memory dynamically as you read the file as described here: Dynamically expanding array using realloc
Do you need to use an array? I think using list is your best option here. Than you can just use something like myList.add(newElement) or myList.append(newElement) depending on the language you are using.
I've seen many answers online saying that checking the size of a list is constant time, but I don't understand why.
My understanding was that a list isn't stored in contiguous memory chunks (like an array), meaning there is no way of getting the size of a list (last element index + 1), without first traversing through every element.
Thoughts?
I've seen many answers online saying that checking the size of a list is constant time.
This fallacy may originate in a fundamental flaw in the Python language: arrays are called lists in Python. As Python gains popularity, the word list has become ambiguous.
Computing the length of a linked list is an O(n) operation, unless the length has been stored separately and maintained properly.
Retrieving the size of an array is performed in constant time if the size is stored along with the array, as is the case in Python, so a=[1,2,3]; len(a) is indeed very fast.
Computing the length of an array may be an O(n) operation if the array must be scanned for a terminating value, such as a null pointer or a null byte. Thus strlen() in C, which computes the number of bytes in a C string (a null terminated array of char) operates in linear time.
The only way to find the length of a list without holding the locations before hand is iterating through the list. They are not stored in chunks so it requires iterating until reaching the last element. Therefore the time complexity is O(n). Of course if you store a variable holding the length and increment it every time an element is added (and decrement when an element is removed), you would not need to iterate through it which would make it constant as you would only need the first element, or retrieve the data from wherever the length is stored. Perhaps one could use the root element to hold the length therefore making it unnecessary to loop through it to get the length. In short, you are correct. The reason one might say constant is if it is stored beforehand.
This is probably a simple question. However I am simply wondering how to I create a string or array in ruby so that I know that it is 1MB large. Or any size for that matter.
This is not possible. The Ruby Language Specification only specifies the behavior of strings, not how they are stored. It is perfectly legal, for example, for an implementation to compress strings (in which case the size of the string in memory will be smaller than you think), to de-duplicate them (in which case the size will be 0). Rubinius, for example, stores strings as ropes, as far as I know, which means that parts of strings may be shared with parts of other strings, so the notion of "size" isn't even well-defined in that case.
To create a million-character string:
"a" * 10**6
If you want it to read well and are using Rails or don't mind requiring active_support/core_ext then you can do the following:
"a" * 1.megabyte
"a" * 10.megabytes
This uses the traditional definition of megabyte (power of 2 instead of 10).
Note that this is assuming you're sending ASCII characters to a service, not trying to estimate how Ruby stores them.
You can set the size of the internal String buffer these days with the capacity: keyword argument. It's great if you know the size of a String up front, since you'll then not need reallocs as you shovel on repeatedly.
String.new(capacity: 10**6)
I'm trying to construct an two dimensional array on an arduino uno which uses an atmega328. I want an array of booleans with the size of 256 * 18. This is to big for the 2KB RAM so i wanted to save it to the PROGMEM(avr). how can i do this and how can i acces the variables? i found some tutotials about doing th same with chars or strings but there is no data type for booleans. what is the best way zo save and extract booleans in/from chars.
As you have likely read about using program space (aka flash). It is necassary to use special macro's that work on the pointers, as detailed at avr-libc/user-manual.
That said, see my example of a 2D matrix in program space example of storing the 2D array along with the example of calling the data from the 2D array
It should work for larger scale.
Where you sneak a second question at the end, about booleans. Note booleans while treated as 0 or 1 really consume a full byte.
You may want to consider #include and using the vector< bool > type as this will consume only a single bit per unit. As each element occupies a single bit.
In other languages like C++, you have to keep track of the array length yourself - how does Delphi know the length of my array? Is there an internal, hidden integer?
Is it better, for performance-critical parts, to not use Length() but a direct integer managed by me?
There are three kinds of arrays, and Length works differently for each:
Dynamic arrays: These are implemented as pointers. The pointer points to the first array element, but "behind" that element (at a negative offset from the start of the array) are two extra integer values that represent the array's length and reference count. Length reads that value. This is the same as for the string type.
Static arrays: The compiler knows the length of the array, so Length is a compile-time constant.
Open arrays: The length of an open array parameter is passed as a separate parameter. The compiler knows where to find that parameter, so it replaces Length with that a read of that parameter's value.
Don't forget that the layout of dynamic arrays and the like would change in a 64-bit version of Delphi, so any code that relies on finding the length at a particular offset would break.
I advise just using Length(). If you're working with it in a loop, you might want to cache it, but don't forget that a for loop already caches the terminating bounds of the loop.
Yes, there are in fact two additional fields with dynamic arrays. First is the number of elements in the array at -4 bytes offset to the first element, and at -8 bytes offset there's the reference count. See Rudy's article for a detailed explanation.
For the second question, you'd have to use SetLength for sizing dynamic arrays, so the internal 'length' field would be available anyway. I don't see much use for additional size tracking.
Since Rob Kennedy gave such a good answer to the first part of your question, I'll just address the second one:
Is it better, for performance-critical parts, to not use Length() but a direct integer managed by me?
Absolutely not. First, as Rob mentioned, the compiler does it's thing to access the information extremely quickly, either by reading a fixed offset before the start of the array in the case of dynamic ones, using a compile-time constant in the case of static ones, and passing a hidden parameter in the case of open arrays, you're not going to gain any improvement in performance.
Secondly, the direct integer managed by you wouldn't be any faster, but would actually use more memory (an additional integer allocated along with the one Delphi already provides for dynamic and open arrays, and an extra integer entirely in the case of static arrays).
Even if you directly read the value Delphi stores already for dynamic arrays, you wouldn't gain any performance over Length(), and would risk your code breaking if the internal representation of that hidden header for arrays changes in the future.
Is there an internal, hidden integer
Yes.
to not use Length() but a direct integer managed by me?
Doesn't matter.
See Dynamic arrays item in Addressing pointers article by Rudy Velthuis.
P.S. You can also hit F1 button.