Coding confession/brag/rfc on something i just wrote
-
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
means that something changes constantly, i.e. without manual intervention to change it.
The opposite of "manual" is not "constant." Do you even vocabulary, bro?
I saw it. It made no sense. "If you care about
Add
"? You will put things into your list, right? Unless you're adding items to it in some non-linear order, you care aboutAdd
, because that's how you will add items to the list.Why do you persist in conflating arrays with lists? You do realize there are plenty of other uses for an array than to constantly add things to, right?
It's not like I'm just making this up. "Dynamic array" is a well-defined thing in computing... the thing that makes a "dynamic array" different from a regular array is that a dynamic array includes the code to resize it when necessary, without the programmer having to worry about that.
Ugh. What idiot wrote that article? A dynamic array is an array whose size is not static. They're describing a completely different data structure that's not an array at all, though it may be backed by an array as an implementation detail.
-
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
The opposite of "manual" is not "constant." Do you even vocabulary, bro?
Explained in my post. Do you even read, bro?
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
Ugh. What idiot wrote that article?
It's Wikipedia. Go
vandalizeahem, correct it and get yourself banned, if you care that much.@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
They're describing a completely different data structure that's not an array at all, though it may be backed by an array as an implementation detail.
Different how? It describes an array, plus code to automatically resize it when needed; that's what makes it a dynamic array. It specifically mentioned .NET's
List
as an example of what it's talking about.
-
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
Why do you persist in conflating arrays with lists? You do realize there are plenty of other uses for an array than to constantly add things to, right?
I've got a bunch arrays which are indexed by ASCII characters. Those don't change size a lot.
-
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
It specifically mentioned .NET's
List
as an example of what it's talking about.And
List
is not an array.A dynamic array is an array whose size is not static. If it has an
Add
method, it's not an array at all; it's a list data structure, most likely backed by a dynamic array.
-
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
If it has an
Add
method, it's not an array at all; it's a list data structure, most likely backed by a dynamic array.
-
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
It's Wikipedia. Go
vandalizeahem, correct it and get yourself banned, if you care that much.I added a note to the Talk page, where there's already a bunch of controversy as to whether the article should exist at all.
-
@masonwheeler just FYI, your experience with Delphi may not be typical of computing in general. A link that's specific to Delphi may not be as applicable as you'd like when we're specifically talking about C++.
-
@anotherusername C++? Where? I thought we were talking about C#. (Which was created by the same guy who created Delphi.)
-
@masonwheeler my bad. C# is more similar to C++ than it is to Delphi, though.
-
@anotherusername Syntactically, maybe. Semantically, not even close.
C# 1.0 was essentially Delphi rewritten to look-and-feel like Java. The two have diverged significantly since then, but not in the direction of C++. (For either language!)
-
@masonwheeler Technically, a dynamic array is an array plus extra operations (e.g., the ability to append an element). Which is fine and dandy, but not a true array. And a C# list is the same sort of animal. Oh, and lots of other languages have The. Same. F'ing. Concept even if they use all sorts of names for it. It's really useful, works well, is easy to make reliable, can be largely understood by a junior dev in a few hours, etc.
But a plain array is just a fixed-size block of (usually writable) cells that can be indexed into efficiently, usually via the magic of address arithmetic. Modern computers have been optimised to heck and back for handling arrays efficiently; almost all large storage comes down to arrays (and their cousins structures). The downside is that most languages can't really resize arrays. (The outlier is C, which can sort of do it. Sometimes.)
-
@masonwheeler actually, I think the discrepancy is that you're using the "all non-static arrays are dynamic arrays" approach, and it's damn near pointless to use really static arrays anymore; you almost have to go out of your way to do it, because an array is typically just a pointer to a block of memory, and unless the pointer is in the form of a known offset from the stack pointer (which is a known constant at compile time) there's really no reason why you can't allocate a new chunk of memory, move data to it (if you need to), update the pointer to point to it instead, and free the original array's memory. Bam, your array is dynamic.
Since it's nearly pointless to use "dynamic" to refer to arrays in that respect (virtually all arrays are dynamic), it came to mean "array that has some extra code bolted on to transparently increase the array's size when you need to, transferring stuff from the old array to the new one and updating your pointer". That's substantially different from a standard array that you'd have to manually resize (even if you have a function that does it) and it made sense to differentiate between them. So now you have "normal" arrays (can typically be resized, but manually; you're actually creating a brand-new array and destroying the old one) and "dynamic" arrays (can resize itself, automatically) and they aren't the same thing.
-
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
you're actually creating a brand-new array and destroying the old one
meaning it actually can't be resized, you're making a brand new one.
-
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
it's damn near pointless to use really static arrays anymore; you almost have to go out of your way to do it
const char hexchars[] = "0123456789ABCDEF";
-
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
it's damn near pointless to use really static arrays anymore
Actually they're used pretty heavily. It's just that they're often wrapped up in some higher-level API. It's all about the level of abstraction.
-
@pleegwat said in Coding confession/brag/rfc on something i just wrote:
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
it's damn near pointless to use really static arrays anymore; you almost have to go out of your way to do it
const char hexchars[] = "0123456789ABCDEF";
I mentioned that actually.
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
unless the pointer is in the form of a known offset from the stack pointer (which is a known constant at compile time)
Anyway, you did have to go out of your way by adding
const
to the declaration. All that does is tell the compiler that you, the programmer, aren't allowed to change it later. There's no particular reason why those bytes can't be changed aside from the simple fact that you declared that you don't want the ability to change them.
-
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
Anyway, you did have to go out of your way by adding
const
to the declaration. All that does is tell the compiler that you, the programmer, aren't allowed to change it later. There's no particular reason why those bytes can't be changed aside from the simple fact that you declared that you don't want the ability to change them.const
does not affect where this memory is placed. This array would probably have global scope, so it would be in a fixed location in the memory image. If I had not used const then the size of the array would still be fixed compile-time, but I could safely modify those 17 bytes. I just can't add an 18th.
-
@pleegwat said in Coding confession/brag/rfc on something i just wrote:
const
does necessarily not affect where this memory is placed.The compiler might put the data in a section that's placed in read-only memory. It's not guaranteed, of course, but it's OK for the compiler to do so.
-
@dkf True. Whether a non-zero default value is set also affects placement of global arrays.
-
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
The opposite of "dynamic" is not "manual"; it's "static" (ie. unchanging; the size is fixed from the moment of creation).
Immutable?
-
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
@anotherusername Yes, and if you care about
Add
, you definitely wantList
rather than an array. But the original context said nothing aboutAdd
; it said thatList
can be dynamically resized and arrays can't, which is false.Isn't resizing arrays just creating a new array and copying all the stuff to the new one? Then, can we really say it's resized?
ETA ah, 'd by a whole week. Kudos, @Yamikuronue ! :)
-
@kt_ said in Coding confession/brag/rfc on something i just wrote:
Isn't resizing arrays just creating a new array and copying all the stuff to the new one? Then, can we really say it's resized?
It's semantically equivalent to doing so, and can be implemented that way, but doesn't necessarily have to be, depending on the size of the array vs. the block size of the memory that it was allocated from.
-
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
@kt_ said in Coding confession/brag/rfc on something i just wrote:
Isn't resizing arrays just creating a new array and copying all the stuff to the new one? Then, can we really say it's resized?
It's semantically equivalent to doing so, and can be implemented that way, but doesn't necessarily have to be, depending on the size of the array vs. the block size of the memory that it was allocated from.
Could you elaborate?
-
@kt_ In a garbage collected system, you allocate everything exactly the size of memory that you need, and then when the GC runs, it can compact the heap and move things around to keep fragmentation down. This has its advantages and disadvantages, and there are other ways to do it.
On a non-GC system with no heap compaction, you can deal with fragmentation by using a bucketed memory manager. Instead of allocating everything out of one big block of memory, it divides it up into "buckets" containing several blocks of various sizes, and every allocation gives you a block of memory of the smallest size that will fit the request.
If you want to expand a dynamic array, it's possible that the existing array wasn't using the entirety of the block assigned to it, and that the new one won't either, in which case the memory manager simply updates its bookkeeping and the array can be resized in-place.
-
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
memory manager simply updates its bookkeeping
That's garbage collection. A non-GC system doesn't have a memory manager.
-
@djls45 ... ???
-
@djls45 said in Coding confession/brag/rfc on something i just wrote:
That's garbage collection. A non-GC system doesn't have a memory manager.
An allocator is a memory manager.
malloc
andnew
ask the memory manager for memory, andfree
anddelete
tell the memory manager you are done with the memory. Who do you think is giving you your memory?
-
@kian said in Coding confession/brag/rfc on something i just wrote:
Who do you think is giving you your memory?
Jesus.
-
In Go, arrays have sizes known at compile time and slices are 3-tuples of (pointer to array, length of slice, capacity of array). For bonus points, strings are 2-tuples of (pointer to array of bytes, size of array), so you can write a 2-word-long byte buffer implementation if you want to reallocate the entire buffer every time you write to it.
-
@kian said in Coding confession/brag/rfc on something i just wrote:
@djls45 said in Coding confession/brag/rfc on something i just wrote:
That's garbage collection. A non-GC system doesn't have a memory manager.
An allocator is a memory manager.
malloc
andnew
ask the memory manager for memory, andfree
anddelete
tell the memory manager you are done with the memory. Who do you think is giving you your memory?You don't even need to have malloc/free to have a memory manager. There's at least one built into every modern CPU, and every OS kernel.
-
@dkf said in Coding confession/brag/rfc on something i just wrote:
@anotherusername @masonwheeler You two are agreeing violently…
-
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
If you want to expand a dynamic array, it's possible that the existing array wasn't using the entirety of the block assigned to it, and that the new one won't either, in which case the memory manager simply updates its bookkeeping and the array can be resized in-place.
Unless the compiler can somehow guarantee that, it can't optimize two simultaneous copies of the array away.
-
@anotherusername ...huh?
-
@anotherusername said in Coding confession/brag/rfc on something i just wrote:
@masonwheeler said in Coding confession/brag/rfc on something i just wrote:
If you want to expand a dynamic array, it's possible that the existing array wasn't using the entirety of the block assigned to it, and that the new one won't either, in which case the memory manager simply updates its bookkeeping and the array can be resized in-place.
Unless the compiler can somehow guarantee that, it can't optimize two simultaneous copies of the array away.
It's a runtime check. He described what
realloc
tries to do.
-
I'm feeling happy with this, and it isn't something I wrote by myself, but we've just got an “accurate” power measurement instrumentation system written at work. It's pretty neat, and generates a nice report at the end of the simulation describing how many Joules of energy were used at each stage of the processing. Right now, we're still in the process of validating it (because we were initially checking with a trivial example simulation so that tests would be very quick) but it's looking good. It'll replace our previous system for doing this, which was a board with an Arduino bolted on the side to do power measurement, which would be fine except that it doesn't sample nearly often enough to catch meaningful detail (also there's only one such board and it appears to have some minor hardware faults).
I wrote the part that actually measures the power usage of the CPUs, taking into account all the tricky bits like possible systematic sampling errors and running at a high enough frequency to be actually able to detect the detailed behaviour of our simulation engine. Which sounds trivial, and sort of is, but tends to cause problems if you don't plug in code to ensure that you do it right.
We're planning to totally brag about this capability in our future papers.