Compare the generated code. let probably puts the pointer somewhere that
valgrind considers accessible.
Maybe, it's a problem with valgrind, if I run it with \--show-leak-kinds=all I
can see the leak in both cases, even if is considered 'definitely lost' in the
discard case and 'still reachable' in the let case (which still I do not fully
understand but I will search on Valgrind documentation the
yes, that' basically what happen.. I'll just add that the above example can be
simply rewritten in this way
import libcurl
discard global_init(GLOBAL_DEFAULT)
let curl = easy_init()
with the same results depending on the presence of the discard keyword in spite
o
Udiknedormin, nice trick thanks for sharing
Thank you for responses, I created an issue on Github:
[https://github.com/nim-lang/Nim/issues/7000](https://github.com/nim-lang/Nim/issues/7000)
Does somebody knows of a workaround to this issue? For now the only thing I can
do is probably to just remove the default values.
That's definately odd. So, as I understand, it doesn't leak when a let binding
is used?
@monster, you can easily find information and even youtube video, how to setup
Visual Studio 2017 to compile assembler files. Microsoft Macro Assembler is a
part of Visual Studio by default.
@Udiknedormin I can't say 100% for sure, because now I get some error that it
cannot find the required "Interlocked" function (maybe wrong version of Visual
Studio installed?), but at least the original error message is gone, so I think
your solution worked.
# Replace:
proc atomicIncRelaxed*[T: AtomType](p: VolatilePtr[T], x: T = 1): T
# with:
proc atomicIncRelaxed*[T: AtomType](p: VolatilePtr[T], x: T = 1.int32): T
Note it will still work for int64 thanks to the conversion.
The reason of this problem is that int32 is int at the
@cheatfate So, I _could_ still code something like
interlockedExchangeAddNoFence64() in ASM, and use it both in 32-bits and
64-bits with MSVC, but I have to put it in a separate ASM file? And maybe
explicitly "compile" (not sure if this is the right term) it with some ASM
tool? I currently have
Well, the whole problem is that = can't be AST-overloaded. That would be the
best and most nimish solution. However, I found three other solutions as well,
one of which I will quote. Sadly, all three require patterns so if you use
\--patterns:off, the checks will be disabled. Here it comes, the
@doofenstein, I think your issue is worth reporting. Your code looks pretty
valid.
In fact, I consider it a bug in the compiler that the following doesn't work:
proc button*[W, H: UILength = UIAbsLength](self: UISystem,
buttonLabel = none(string),
width = W(0.0),
Inline assembler works only for 32bit target architecture in MSVC, 64bit is not
supported, but you still able to make asm file and compile it for both 32/64bit
architectures.
> No, I can't! It has nothing to do with the input file name!
You mean that it has nothing to do with the output file name, surely. I don't
know why Ar would think his suggestion was relevant.
The error message seems strange, but you really can't expect this to work. At
compile time, width and height are UILength, not UIAbsLength, so your when
tests will fail. You need a template if you want to generate different code
depending on the type at the call site. And if you want the decisio
if you're ok with a var object, you can do:
type Person = object
first, last: string
proc init(self: var Person, first, last: string) =
self.first = first
self.last = last
proc `=`*[T](d: var Person; src: Person) {.error.} =
discard
va
I have a procedure which should accept two units(absolute width and width
relative to the parent widget). For this purpose I created two distinct types
and a typeclass which contains both:
type
UIAbsLength = distinct float32
UIRelLength = distinct float32
18 matches
Mail list logo
