Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-27 Thread mratsim
No, they are not, it would work only if seq[YourConcept] is not needed or only of homogeneous concrete type.

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-27 Thread Udiknedormin
@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).

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-27 Thread mratsim
Also could concepts fit your need?

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-27 Thread monster
The number of message types is not fixed. I'm trying something else now, using composition instead of inheritance.

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-27 Thread Udiknedormin
@monster Is the number of different kinds of messages fixed? If it is, you can use variant types.

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-24 Thread monster
> 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

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-24 Thread Jehan
> 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

atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-24 Thread monster
@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.

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-15 Thread mikra
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

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-13 Thread Araq
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".

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-13 Thread monster
@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

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-13 Thread Araq
Thank you, you rock!

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-13 Thread jwollen
Had various issues with the vcc version too. Just made a [pull-request](https://github.com/nim-lang/Nim/pull/6735)

Re: atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-12 Thread cdome
Actually _InterlockedCompareExchange8 does exist, It was added in VS2012 silently and it is not mentioned in the docs.

atomics: Why is interlockedCompareExchange8 "safe"?

2017-11-12 Thread monster
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