I’m just starting to read into the Go programming language, as I wanted to try a bit of programming. I first looked at Python, but Go caught my eye, and it looked like a nice starting point. Tidy, capable, and quick enough for my purposes.
Allright, a question then…what I want to achieve (after I’m done fiddling with the examples) is to size an array based on the amount of lines in a .csv file. AFAIK you can only set the initial size of an array, and I guess it’s a bit overkill to set the size to the maximum amount of memory (it would make unnecessary resource reservations that way, right?), and then work with slices to use just a little bit of that space.
So, can someone show me an example how to check the amount of lines in a certain file, and use that information to size the array (as the information in those lines would be ‘loaded’ into the array)? I’m planning on filling that array with info from file A, then read file B line by line, and then using the information in the array to let the program categorize each line in file B it encounters.
Thanks for your response. So the number 10 in the ‘for…’ line would be set to the amount of lines in the file I’m trying to ‘load’ into the array, right?
Out of curiosity: AFAIK slices are built on top (or are basically a viewport) of an array, so I would have to define an array beforehand, but that doesn’t seem to be the case then? Also, setting the ‘size’ of the slice to ‘float64’, wouldn’t that reserve an enormous amount of (mostly unused) space or resources?
Just trying to get my head around the mechanics of Go
AFAIK slices are built on top (or are basically a viewport) of an array, so I would have to define an array beforehand, but that doesn’t seem to be the case then?
append manages the underlying array.
Also, setting the ‘size’ of the slice to ‘float64’, wouldn’t that reserve an enormous amount of (mostly unused) space or resources?
I’m not sure exactly what you mean, so I will explain both lines that seem relevant.
var data []float64
Means: There is a slice that contains items of type float64 called data.
data = append(data, float64(i))
Means: Set data to the result of appending i (converted to float64) to data. i must be converted to float64 because the inferred type when it was declared i := 0 was int (because 0 looks like an int).
For this small example, it does seem wasteful to store ints as float64s. Given no other context (e.g., a reason to use float64) a more space efficient and less cumbersome to work with example would be:
var data []int
for i := 0; i < 10; i++ {
data = append(data, i)
}
Note, however, that the size of int is architecture dependent. For most efficient memory use, use an int sized for the values it will contain and the operations that need to be done on it (e.g., int8 or uint8).
Use slices.
After reading csf -> file -> line, append the required content to the slice.
In GO Slices increase the length of the structure automatically. Until 1024 records it doubles (100%) the array size based on initial size, after that it 25% increase in the size.
@Subbu_subbu: Ok, so slices can automatically increase the size of the array? I didn’t know that!
That would mean I can create an array of…let’s say 1024 records, and then not worry about it anymore if the csv entries grow beyond that. Nice!
I tend to not worry about slice capacity until I have to. I usually use append when I don’t know how much data will be in the slice.
Taking csv as an example. Since you can’t know how many entries there are in a csv file until it is loaded, any initial slice capacity will almost always be wrong. That is, you will either allocate too much space or too little. Since you don’t know how many entries there will be, the only way to allocate the correct amount is by chance.
Since any choice will be incorrect (i.e., allocates too much or too little space), I start by using the default. In this case that would be something like:
var entries []entry
I use defaults to defer the work required to make a better decision. In many cases the default is good enough and using the default eliminates the possibility of me making a choice that is worse than the default.
If you find out the default isn’t good enough, you will know what “not good enough” means (e.g., too many allocations) and therefore what better means (e.g., fewer allocations). You will also have situational knowledge (e.g., the csvs processed by this function have, on average, 1000 entries) or the means to get it (e.g., add a metric to record the number of csv entries per file).
