The semantics of when stuff is copied, moved, or passed by reference are all over the place in language design. C started with the idea that functions returned one int-sized value in a register. This led to classic bugs where the function returns a pointer to a local value. Compilers now usually catch this. C eventually got structure return by copy. Then C++ added return value by move, and automatic optimization for…
Well, that's another nice thing with Rust. Maybe it's not the saviour language but at least it brings clarity to ownership of values.
Go structs are copied on assignment (and other things about Go I'd missed)
101–110 of 176 posts
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#102[0] https://en.cppreference.com/w/cpp/language/copy_assignment
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#103Earlier quoted context omitted.
Python copies references by value. $ python3 Python 3.12.3 (main, Jul 31 2024, 17:43:48) [GCC 13.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def x(): ... v = 1 ... y(v) ... print(v) ... >>> def y(val): ... val += 1 ... >>> x() 1 A pass-by-reference language would print 2. Everything in a modern language is passed by copy. Exactly what is copied varies and can easily be poi…
C++ is a live language, C# has out parameters.... there's stuff out there. The classic example of "pass by copy-reference is less expressive" is you can't have pass a reference to number and have the caller modify it. You have to explicitly box it. I understand you understand this, but it's worth considering when thinking about whether the distinction means absolutely nothing at all.
This is really not true. Depending on how your language implements pass-by-reference, you can pass a reference to an int without boxing in one of two ways: either pass a pointer to the stack location where the int is stored (more common today), or simply arrange the stack in such a way that the local int in the caller is at the location of the corresponding parameter in the callee (or in a register).
The second option basically means that the calling convention for reference parameters is different from the calling convention for non-reference parameters, which makes it complicated. It also doesn't work if you're passing a heap variable by reference, you need extra logic to implement that. But, for local variables, it's extremely efficient, no need to do an extra copy or store a pointer at all.
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#104Earlier quoted context omitted.
C# can call it that specifically if it likes, because the general computer science term is dead, but under the hood you're passing a reference by value. Look to the generated assembler in a non-inlined function. You'll find a copy of a pointer. You did not in true pass-by-refernce langauges. The fact that is a sensible thing to say in a modern language is another sign the terminology is dead.
C#'s ref parameters, same as C++' s reference types, have true pass-by-reference semantics. Whether this gets compiled to pass-by-pointer or not is not observable from the language semantics. That is, the following holds true: int a = 10; foo(ref a) ; Assert(a == 100); void foo(ref int a) { a = 100; } There's also a good chance that in this very simple case that the compiler will inline foo, so that it will not ever…
So if one invokes low-level implementation details, Forth is also a pass-by-pointer-value in the same way as C# "ref" and others, at least on x86.
However I don't think appealing to implementation details is useful, what matters is what is observed through the language, with the results you point out.
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#105The semantics of when stuff is copied, moved, or passed by reference are all over the place in language design. C started with the idea that functions returned one int-sized value in a register. This led to classic bugs where the function returns a pointer to a local value. Compilers now usually catch this. C eventually got structure return by copy. Then C++ added return value by move, and automatic optimization for…
Actually Go is always pass by value. Even when you pass the pointer you’ll get a copy of it.
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#106One of the many things I find inspiring about Julia is how quick she is to admit to mistakes she has made or things that she hasn't understood. If she didn't understand it, I can 100% guarantee that there are large numbers of people out there who also didn't understand it - many of whom were probably too embarrassed to ever admit it. I think this is a useful trait for senior software engineers generally. If you're a…
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#107This sometimes catches out people C#/.Net too, it's a big difference between Class and Struct, Class is reference type and Struct is value type. (see fiddle below), but in practice people very rarely reach for structs, so people don't tend to build up the muscle memory of using them, even if they intuitively understand the difference between reference types and value types from general use of other types. (Fiddle dem…
This isn't something that unsual though, from some oldies to newer ones, Delphi, Oberon variants, Modula-3, Common Lisp, Eiffel, D, Swift, and eventually Java (when value class and value record finally lands, EA available) It is the focus on managed scripting languages, that trips people up, when they finally change to one of those compiled ones.
> and eventually Java
Wait, it's been a looong time since I did Java. What am I missing here; what does Java do differently from C#?(C# is my daily driver so I'm quite familiar with its handling of value and reference types)
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#108One of the many things I find inspiring about Julia is how quick she is to admit to mistakes she has made or things that she hasn't understood. If she didn't understand it, I can 100% guarantee that there are large numbers of people out there who also didn't understand it - many of whom were probably too embarrassed to ever admit it. I think this is a useful trait for senior software engineers generally. If you're a…
This kind of downplaying of hard skills and trying to argue that one can help by admitting gaps in their knowledge is at best weird.
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#109The semantics of when stuff is copied, moved, or passed by reference are all over the place in language design. C started with the idea that functions returned one int-sized value in a register. This led to classic bugs where the function returns a pointer to a local value. Compilers now usually catch this. C eventually got structure return by copy. Then C++ added return value by move, and automatic optimization for…
> This led to classic bugs where the function returns a pointer to a local value. Compilers now usually catch this. C eventually got structure return by copy. Then C++ added return value by move, and automatic optimization for that. Jesus Christ. Can we now get “return fruit by vegetable?” Some speedups may not be worth having to memorize standards documents.
Re: Go structs are copied on assignment (and other things about Go I'd missed)
#110One of the many things I find inspiring about Julia is how quick she is to admit to mistakes she has made or things that she hasn't understood. If she didn't understand it, I can 100% guarantee that there are large numbers of people out there who also didn't understand it - many of whom were probably too embarrassed to ever admit it. I think this is a useful trait for senior software engineers generally. If you're a…
Agreed. I think 90%+ of the complaints people have about technical blog posts would go away if authors were more willing to admit what their blog post is really for and what their limitations are.
Writing an "Ultimate Guide to X" as a learning experience is fine if you admit that (and, ideally, use a more humble title) but pretending to be a long time expert in framing when someone isn't leads to problems and a poor reputation. You, too, are fantastic at framing your content properly, and have a great reputation amongst people I know for it.