FAQ
The slice implementation is correctly written to expand by a
multiplicative factor instead of an additive one.

Oh, really? Nice! The book I read did not explain it that way.

So this is (more or less) completely redundant code?

https://gist.github.com/moraes/2141121#file-gistfile1-go-L60
I guess it comes from having used Pascal as a college freshman
I did that - Turbo Pascal and Delphi... never had to do much pointer
juggling, and that was one of the reasons I stuck with it for many years.
Never had to use pointers to pointers :-)
Using Go effectively often requires knowing the language as a whole, and
not marking off pieces of it as scary

Understood :-)

Arguably using pointers to pointers is not a feature of the language
though, but a developer choice - Go is making me comfortable with pointers
in a way C and C++ never did, but pointers to pointers still conceptually
don't make a lot of sense to me, and I avoid them if possible. It requires
too much reasoning about the resulting code for my taste. I like simple
things - which is another big reason I like Go :-)



On Thu, Jan 2, 2014 at 1:04 PM, Thomas Bushnell, BSG
wrote:
On Thu, Jan 2, 2014 at 9:54 AM, Rasmus Schultz wrote:

If you want simple short stacks or queues in Go, why not just use a
slice and be done with it?

That was my first impulse, but slices (that have reached capacity) get
copied every time you append an item, right?
No. The slice implementation is correctly written to expand by a
multiplicative factor instead of an additive one.

I'm going to have lots of queues and some will have (much) more heavy
traffic than others - I don't want to waste memory by making room for 100
items in thousands of queues when 90% of those will have 1-3 items at a
time before getting flushed. And I definitely do not want lengthy code
(such as I saw written by a third party) that checks to see if the slice
has reached it's limit, reallocates and copies it to a new slice to double
it's capacity. (ideally that's what I need, but I don't want that code
replicated in every type.)
So you need to know whether a queue should use one implementation or the
other: there are two strategies. Which to choose depends on the case. This
is another argument against a single function for all of them.

Also: pointers to pointers... I know this is totally common for people
who worked in C or C++ and it may seem like a ridiculous reason, but it
makes my head spin, and it was one of the main reasons C or C++ never
caught on for me personally. It's one of the reasons I like Go - I can
think of pointers as references, conceptually, and it "just works", without
my getting distracted by low-level technical thinking when I'm trying to
solve high-level problems.
It's part of the language. Pointers are not a "low-level" concept; I guess
it comes from having used Pascal as a college freshman and then having done
advanced data structures in FORTRAN: you learn what pointers are, and
become really happy with them. But "low-level" they certainly aren't; don't
think of them as "addresses".

Using Go effectively often requires knowing the language as a whole, and
not marking off pieces of it as scary. I understand that with C++ or
Javascript you have to ignore most of the language to get work done, but Go
was thought through with the intention of providing what you need, and not
a lot of extra stuff you should ignore.

Thomas
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2022 Grokbase