7 ms·

1. You are assuming here that a and b will not be used anymore and are optimizing for a special case. 2. The general problem that I was trying to illustrate is

1. You are assuming here that a and b will not be used anymore and are optimizing for a special case. 2. The general problem that I was trying to illustrate is that shared ownership requires either reference counting or avoiding it through copying if you don't have automatic memory management.

lossolo 10y ago
Your example didn't had any assumptions. What you are assuming then? If you need to reuse variable in Go then it will also copy it inside the map so your point is even more invalid in that case.
- rbehrends 10y ago
  No. In a GCed language, both the map and the original code can safely share a reference without having to worry about coordinating lifetime.
  - lossolo 10y ago
    > In a GCed language, both the map and the original code can safely share a reference without having to worry about coordinating lifetime. Go is GCed language. Show me the code that will do what you claim (map[var1] = var2 and use var1(type string) and var2(type string) in later code) in Go.
    - rbehrends 10y ago
      I'll give you OCaml: let addr s = 2 * (Obj.magic s) + 1 let main () = let table = Hashtbl.create 0 in let key = "foo" and value = "bar" in Hashtbl.add table key value; Hashtbl.iter (fun key' value' -> Printf.printf "%b %b %x %x %x %x\n" (key == key') (value == value') (addr key) (addr key') (addr value) (addr value') ) table let () = main () This prints: true true 10cbd2490 10cbd2490 10cbd2378 10cbd2378 The exact addresses may vary from run to run. Note that == is reference equality in OCaml. I'm honestly baffled why you think that there is a need to copy the variables or why you can't use them later or whatever you believe there.
      - lossolo 10y ago
        I don't know OCaml but I asked you for Go code in thread about Go and you didn't deliver. You wrote that I am covering only special case in my C++ code but you are doing exactly the same. What I see in your code are pointers to static part of memory as you are using string literals, show me code+asm of function that takes unknown values of strings at compile time and then it mutate (with third string supplied to function not known at compile time) and return those values later in the function. > I'm honestly baffled why you think that there is a need to copy the variables or why you can't use them later or whatever you believe there. What you wrote is SPECIAL case in SOME of the GC'd languages that have immutable strings. If you have language with mutable strings then this will not work. I know it will not work in Go also and they have immutable strings (so even not all gc'd languages with immutable strings optimize this) that's why I've asked for Go code in Go thread.
        rbehrends 10y ago
        > I don't know OCaml but I asked you for Go code in thread about Go and you didn't deliver. I don't really use Go and made a general comment about GC that was not limited to Go in a subthread about fairly general observations about GC, because somebody made a general statement about GC that was not limited to Go. The language is not relevant for the observation I made. Nor does it really matter if we're storing strings or other heap-allocated objects. It's a question of lifetime management. > What you wrote is SPECIAL case in SOME of the GC'd languages that have immutable strings. OCaml strings are mutable, actually. But you seem to be confusing lifetime issues with aliasing issues, anyway. The underlying problem is that without copying C++ would not know when to free the strings. It would be whenever they went out of scope in the calling function or when they were deleted from the map, whichever is later; the alternative is reference counting (also expensive, and not used by std::string). A GCed language can avoid that because the garbage collector will only free them when they are no longer reachable from either (or any other location).
        lossolo 10y ago
        I wrote that I disagree to what you wrote because what you wrote was special case. Then I wrote specifically about Go in this comment: https://news.ycombinator.com/item?id=14116435 https://news.ycombinator.com/item?id=14116435 You replied "No" to that what I wrote about Go which is not true. I never even once wrote about lifetimes. Don't you see it? Look closely again what I wrote in my comments. I think you are confused about what I was disagreeing because you didn't read carefully what I wrote. I agree with what you wrote about lifetimes 100% and I was before that discussion started because I write C++ and those things are basic knowledge. But it wasn't about lifetimes from the beginning... > The language is not relevant for the observation I made. Nor does it really matter if we're storing strings or other heap-allocated objects. No, because what you wrote is only true depending on the language and depending on where those strings are stored and in which language, because in some cases they will be copied so what you wrote at the beginning would not be entirely true. And I disagreed with that only, I didn't mention lifetimes even once. If instead of what you wrote you would write (big letters to show diff): - in C++, m[a] = b, IN SPECIAL CASE where m is a map, and a and b are strings AND A AND B OUTLIVE MAP ASSIGNMENT requires that both a and b are being copied UNLESS YOU USE SHARED OWNERSHIP. This is not necessary in SOME OF GCed languages in SPECIAL CASES. Then I would have no reason to disagree with you in the first place.

lossolo 10y ago

Your example didn't had any assumptions. What you are assuming then? If you need to reuse variable in Go then it will also copy it inside the map so your point is even more invalid in that case.

rbehrends 10y ago
No. In a GCed language, both the map and the original code can safely share a reference without having to worry about coordinating lifetime.
- lossolo 10y ago
  > In a GCed language, both the map and the original code can safely share a reference without having to worry about coordinating lifetime. Go is GCed language. Show me the code that will do what you claim (map[var1] = var2 and use var1(type string) and var2(type string) in later code) in Go.
  - rbehrends 10y ago
    I'll give you OCaml: let addr s = 2 * (Obj.magic s) + 1 let main () = let table = Hashtbl.create 0 in let key = "foo" and value = "bar" in Hashtbl.add table key value; Hashtbl.iter (fun key' value' -> Printf.printf "%b %b %x %x %x %x\n" (key == key') (value == value') (addr key) (addr key') (addr value) (addr value') ) table let () = main () This prints: true true 10cbd2490 10cbd2490 10cbd2378 10cbd2378 The exact addresses may vary from run to run. Note that == is reference equality in OCaml. I'm honestly baffled why you think that there is a need to copy the variables or why you can't use them later or whatever you believe there.
    - lossolo 10y ago
      I don't know OCaml but I asked you for Go code in thread about Go and you didn't deliver. You wrote that I am covering only special case in my C++ code but you are doing exactly the same. What I see in your code are pointers to static part of memory as you are using string literals, show me code+asm of function that takes unknown values of strings at compile time and then it mutate (with third string supplied to function not known at compile time) and return those values later in the function. > I'm honestly baffled why you think that there is a need to copy the variables or why you can't use them later or whatever you believe there. What you wrote is SPECIAL case in SOME of the GC'd languages that have immutable strings. If you have language with mutable strings then this will not work. I know it will not work in Go also and they have immutable strings (so even not all gc'd languages with immutable strings optimize this) that's why I've asked for Go code in Go thread.
      - rbehrends 10y ago
        > I don't know OCaml but I asked you for Go code in thread about Go and you didn't deliver. I don't really use Go and made a general comment about GC that was not limited to Go in a subthread about fairly general observations about GC, because somebody made a general statement about GC that was not limited to Go. The language is not relevant for the observation I made. Nor does it really matter if we're storing strings or other heap-allocated objects. It's a question of lifetime management. > What you wrote is SPECIAL case in SOME of the GC'd languages that have immutable strings. OCaml strings are mutable, actually. But you seem to be confusing lifetime issues with aliasing issues, anyway. The underlying problem is that without copying C++ would not know when to free the strings. It would be whenever they went out of scope in the calling function or when they were deleted from the map, whichever is later; the alternative is reference counting (also expensive, and not used by std::string). A GCed language can avoid that because the garbage collector will only free them when they are no longer reachable from either (or any other location).
        lossolo 10y ago
        I wrote that I disagree to what you wrote because what you wrote was special case. Then I wrote specifically about Go in this comment: https://news.ycombinator.com/item?id=14116435 https://news.ycombinator.com/item?id=14116435 You replied "No" to that what I wrote about Go which is not true. I never even once wrote about lifetimes. Don't you see it? Look closely again what I wrote in my comments. I think you are confused about what I was disagreeing because you didn't read carefully what I wrote. I agree with what you wrote about lifetimes 100% and I was before that discussion started because I write C++ and those things are basic knowledge. But it wasn't about lifetimes from the beginning... > The language is not relevant for the observation I made. Nor does it really matter if we're storing strings or other heap-allocated objects. No, because what you wrote is only true depending on the language and depending on where those strings are stored and in which language, because in some cases they will be copied so what you wrote at the beginning would not be entirely true. And I disagreed with that only, I didn't mention lifetimes even once. If instead of what you wrote you would write (big letters to show diff): - in C++, m[a] = b, IN SPECIAL CASE where m is a map, and a and b are strings AND A AND B OUTLIVE MAP ASSIGNMENT requires that both a and b are being copied UNLESS YOU USE SHARED OWNERSHIP. This is not necessary in SOME OF GCed languages in SPECIAL CASES. Then I would have no reason to disagree with you in the first place.