-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|83|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
SoCoder -> Snippet Home -> Text and GUI's


 
HoboBen
Created : 16 October 2019
 
Language : Go / Golang

Text wrapping in Go




 

Comments


Wednesday, 16 October 2019, 08:22
Jayenkai
Hmm.
Not sure about having to append() strings. Seems like a bit of a superfluous command... Even php had the . operand to concatenate strings.
Wednesday, 16 October 2019, 09:02
HoboBen
It's appending to a list, not to a string - and then joining (concatenating) the list at the end.

You can do "string" + "string" in Go - but in a tight loop you're concatenating two strings, then throwing away the result when you concatenate the next one where it has to allocate another big string. So it saves that until the end when it can do it efficiently!

Like most languages, strings in Go are immutable. If this was C, I'd be tempted to just create a string big enough for the worst case and then mutate it as I go along.
Wednesday, 16 October 2019, 18:49
Jayenkai
Q. Am I right in thinking the "results" is defined as a 16 item array?
..but there's no code to stop the appends going beyond 16 lines?

How does Go cope with such circumstances?
Error: Out of Bounds: Crash?
Or does it just keep adding things and making space like JavaScript/PHP would?
Wednesday, 16 October 2019, 20:07
HoboBen
I can see why you would read it that way!

That 16 is just a "suggestion" for the initial capacity of the array.

When you do `array = append(array, item)`, it either appends it directly, or else it resizes the array to something bigger (probably twice as big, or to the next Mersenne prime or something), copies the elements over, and then appends it.

That's why you do "array = append(array, item)" and not just "append(array, item)": just like realloc in C, the result might point to somewhere else.

I could have left the 16 out completely, but I figured if you're using the function you're bound to want to wrap at least 16 words, and if you don't, well it's not that much memory to waste.

For comparison, I *think* lists in CPython default to an initial capacity of something like 7 elements?

Advanced: it's not actually an "array", its a slice of an underlying array. But the difference is subtle and you normally only use slices. So don't worry about the difference!
Wednesday, 16 October 2019, 20:20
Jayenkai
Truly baffling!!
Thursday, 17 October 2019, 10:11
HoboBen
RE: your comment about the underscore in the for loop in the newletter

Functions (and keywords like range) in Go can return multiple values.

Range over an array/slice returns two values: an index and an element:



This prints:



In my case, I didn't need the index.

Go doesn't let you define an unused variable - similar to the optional C compiler warning that does the same thing for C - because this is usually an error or just useless code that does nothing except confuse readers.

But, you can tell Go "I really mean for this variable to be unused - I don't care about this result".

To do that, you prefix with an underscore. Or just use an underscore alone.

This style is quite idiomatic (but not mandatory) in other languages - I've seen it used in Python and Haskell. It's common anywhere where the language supports the concept of a tuple (an immutable, fixed length list) and "unpacking" to several variables at once, and you don't always care about all of the entries.

Go is actually really easy to learn. It's a small, simple language like C. Some people say it "ignored everything that happened in language design since the 1980s". I consider that a plus, honestly!

There's an excellent Go tutorial at tour.golang.org
Thursday, 17 October 2019, 10:21
Jayenkai
I'm used to the word "each" being used to traverse a collection.
Just having a symbol. How odd!!!
Thursday, 17 October 2019, 15:27
Tricky
Go is full of oddities.... Like this one:

Now I would never code things like that if this wasn't just some sample code, but using "for" where a "while" is more common confuses me, and even had a downside in other things with Go.
For me Go is handy for small programs, and I like the easiness in which you can get stuff to work on Mac, Windows *and* Linux... The syntax of Go, leaves some things to be desired for me, tbh..... Working with Append is one of things that I don't fully like (in fact, I don't like that at all).
Thursday, 17 October 2019, 15:36
HoboBen
You could get really creative with pointers:



Probably doesn't optimise as well though.
Thursday, 17 October 2019, 15:40
Tricky
Still memory is newly allocated and released with every Append or myappend done, so in terms of speed I think this will still have some issues.
Also I work a lot with dupe references and then Append kills everything, of course a struct can fix that, but mesa still not happy.
Thursday, 17 October 2019, 15:42
Jayenkai
🤯
Thursday, 17 October 2019, 15:45
Tricky
And then they say Go is easy, eh?
Thursday, 17 October 2019, 15:47
Jayenkai
I don't think they do say that, though!
They used to say it's FAST..
Is it still as fast as it used to be, or has it suffered from years of bloat-creep?
Thursday, 17 October 2019, 16:17
HoboBen
Not every append! The specification doesn't promise how tgis is done, but it at least used to be:

  • if there's less than 1024 capacity, it doubles the size
  • otherwise, it increases the size by something like 25%

So the majority of the time, append returns the same value.
Friday, 18 October 2019, 01:11
Tricky
Really? Thanks for enlightening me on that one. Still a struct could prevent dupe references to go haywire, but at least no needless memory allocations.

And when it comes to Go being fast... Yeah, that pained me, as even a high load of fully interpreted languages I worked with were faster than Go. I would actually like Go to have a feature like BlitzMax has. The possibility to create a debug build, where every possible programming mistake is being checked (leading to slowdowns), and a release build were errors may lead to "Segmentation Fault" in Unix and "EXCEPTION ACCESS VIOLATION" in Windows, but winning a lot of speed in the process.