@Udiknedormin: I meant right now, since VTable are not available of course.
@monster: It is not safe as is, you must ensure your chain of Msg and MsgBase
pointers have the same lifetime (by putting them in a seq for example).
Otherwise if they are created in different functions, the previous Msg
I want to not only send those messages between threads, but also across the
network. Anything containing additional pointers would just make things more
complicated. Atm, I'm trying something like this (not entirely sure if
toMsgBasePtr() is safe):
type
QueueID* = distinct ui
That is not true. Vtable pointers can be elements of a seq, just like any ptr
or ref type.
No, they are not, it would work only if seq[YourConcept] is not needed or only
of homogeneous concrete type.
@mratsim Vtptrs are not ready yet, as I've heard? If they were, I guess they
would solve the problem (it is how it would probably be solved in Rust,
actually).
Also could concepts fit your need?
The number of message types is not fixed. I'm trying something else now, using
composition instead of inheritance.
@monster Is the number of different kinds of messages fixed? If it is, you can
use variant types.
> No. It means that the object gains a type header that allows for dynamic
> dispatch, RTTI, and such.
@Jehan Thank you for pointing that out! I thought the {.inheritable.} pragma
was the solution to my question, but if it adds a "dynamic dispatch" pointer to
the object, than I cannot use it. S
> Does the {.inheritable.} pragma convert an object into a pointer or keep it
> as a normal object with copy semantics?
No. It means that the object gains a type header that allows for dynamic
dispatch, RTTI, and such.
> Should the compiler warn that putting an Obj2 into a seq of Obj1 will drop
@coffeepot I _think_ what you pointed out is _by design_. This is also how I
would expect it to work. OTOH, I guess a compiler warning in the first case
would be good.
@monster yep; I digged also into the m$docs a bit. here is a overview (see the
concurrency part):
[https://msdn.microsoft.com/en-us/library/hh567368.aspx](https://msdn.microsoft.com/en-us/library/hh567368.aspx)
If you like to compile with cpp "just" include :
[https://docs.microsoft.com/de-de/c
@mikra Well, I'll eat a broom! M$ is too lazy to provide any kind of specific
fences on x64 Windows except "full fences" (read-write). I (stupidly) wasted
hours trying to replicate the pthread atomic API using functions that only
exist on ARM/Itanium Windows. A search shows there are some pthre
@monster you are absolutely right. The or-solution is much better for the
atomicLoad substitution. For your question: have a look at:
[https://docs.microsoft.com/en-us/cpp/intrinsics/intrinsics-available-on-all-architectures](https://docs.microsoft.com/en-us/cpp/intrinsics/intrinsics-available-on
@monster you are absolutely right. The or-solution is much better for the
atomicLoad substitution. For your question: have a look at:
[https://docs.microsoft.com/en-us/cpp/intrinsics/intrinsics-available-on-all-architectures](https://docs.microsoft.com/en-us/cpp/intrinsics/intrinsics-available-on
@mikra I can't say yet if my code will work, as I have to get Nim to use vcc
first (found [this thread](https://forum.nim-lang.org/t/2770)), but my approach
is somewhat different. Firstly, I tried to always use the "right size" call, by
delegating to the appropriate Windows method using "when si
@monster agree the windows api is weird . Unfortunately I have not much
experience with the vcc(thread model and so on) I just need atomicLoad and
atomicStore. Also I don´t know what happens if you use the Nim compiler (built
with gcc) and then the vcc to compile your app. It works for me actual
@mikra That is basically what I was trying to do; have a single API for all
platforms. I could share it, once it works, but having a unified API in the
standard library would surely be beneficial to many users.
On second thought, I'm not sure I want anyone to think I have any clue about
the Win
within the atomics.nim the gcc-api is very different (and better) than the vcc
ones. a consolidation would be nice. AtomicLoad could be replaced by atomicInc
or atomicDec but unfortunately not AtomicStore. And doing cas is not the same
as AtomicStore. If you need two atomics for a specific opera
Can't really remember but it was likely something like "argh this needs to
compile **now** and I know my data is aligned at an 8 byte boundary".
@cdome Great!
@Araq So, is/was (I'm assuming the '8' version is going to be used in the
future), the call safe? I cannot imagine it would have been used at all, if it
caused random memory overwrite. Maybe the 'compare' part of the call makes this
safe? But then, why even bother offering 8/16/32
Thank you, you rock!
Had various issues with the vcc version too. Just made a
[pull-request](https://github.com/nim-lang/Nim/pull/6735)
Actually _InterlockedCompareExchange8 does exist, It was added in VS2012
silently and it is not mentioned in the docs.
Hi,
I'm trying to understand what goes on in "lib\system\atomics.nim". This is in
part because I'm missing atomicLoadN/atomicStoreN on Windows, and I'm trying to
work out how to implement that myself. I've just stumbled upon this declaration
(atomics.nim, line #220):
interlockedC
25 matches
Mail list logo
