Sender | Message | Time |
---|---|---|
1 Nov 2024 | ||
leorize | so stuff like this are expected | 19:20:43 |
leorize | this is more akin to Rust's | 19:21:11 |
graveflo | sink seems to do this just fine in a more sane way. Why use move that just puts the "use after move" scenario in a state of uninitialize memory rather then it's current state | 19:23:44 |
fabric.input_output | more like c++ std::move | 19:23:49 |
graveflo | Just trying to get the rational of what to use this for. iirc sink will not make a copy as long as you do not mutate the object after it was sunk (barring situations where a copy is inevitable) | 19:24:13 |
graveflo | and by that I mean mutate it in the calling context after giving it away. Not the context where is was given to | 19:25:05 |
guzba8 |
take a long list of big things, add them to a set of smaller chunks without copying memory | 19:26:10 |
guzba8 | in this case int would be something huge like a big string | 19:26:22 |
graveflo | right I think if you did this it should be the same (since add is annotated with sink ): | 19:27:59 |
guzba8 | nope you need to explicitly steal it from the big seq | 19:28:21 |
guzba8 | i just did add(i) but it really is add(move bigseq[i]) | 19:28:32 |
guzba8 | it partially works | 19:28:50 |
graveflo | I see what you are getting at with that | 19:31:05 |
guzba8 |
does nim actually sink chunk in this case? it is referenced later, even tho just to reinitialize | 19:31:15 |
guzba8 | it should be but ive not tested that | 19:31:20 |
graveflo | there is the issue of bigseq having a hole in it after that happens, which does seem to be linked to this type of situation in general, but eh | 19:31:26 |
graveflo | I'm actually not sure | 19:32:10 |
graveflo | well it always sinks it.. question is, is nim smart enough to know that resetting the value ensures that it is not mutated after the sink | 19:32:44 |
graveflo | | 19:35:18 |
guzba8 | i look at this and still have no idea if it avoids a copy | 19:38:20 |
guzba8 | but this is the right thing to check ofc | 19:38:47 |
graveflo | if you don't re-initialize it you get a dep which is what I would expect:
so yea.. done spamming the chat for now. sry. Pretty sure this means that it is not making a copy. wasMoved and sink shouldn't create a copy | 19:43:16 |
graveflo | * if you don't re-initialize it you get a dup which is what I would expect:
so yea.. done spamming the chat for now. sry. Pretty sure this means that it is not making a copy. wasMoved and sink shouldn't create a copy | 19:43:24 |
Muhammad Rehan Khan joined the room. | 21:11:57 | |
Clonkk | Is there a way to automatically import from C header identifier that can either be an enum or a macro pointing to that enum, without having to re-calculate the enum value | 23:07:55 |
Elegantbeef | Futhark? | 23:11:20 |
Clonkk | Wouldn't that gives me all the symbol from the headers ? | 23:14:07 |
Clonkk | I guess dead code will be eliminated on compilation | 23:14:20 |
leorize | unless your header is gigantic (which would meant slower compile time), I'd say that the dead code wouldn't be too much of an issue | 23:38:48 |
pmunch | Yes it would, but as you mention dead code elimination makes this a non issue, | 23:47:02 |