Assume that i have a proc like this
proc myProc( a : auto) =
#need to check what the type of a, I am expecting an int, float, string.
# do some operations
How can i check the type of a ? proc myProc1(a: int) =
echo "int: ", a
proc myProc1(a: float) =
echo "float: ", a
proc myProc1(a: string) =
echo "string: ", a
proc myProc(a: auto) =
myProc1(a)
myProc(1)
myProc(2.0)
myProc("hello")
# Passing other than int, float and string result in compile error
#myProc((3,4))
Or
proc myProc(a: int) =
echo "int: ", a
proc myProc(a: float) =
echo "float: ", a
proc myProc(a: string) =
echo "string: ", a
myProc(1)
myProc(2.0)
myProc("hello")
But you sad you need to know the type at runtime. That means parameter a is actually pointer or Any in typeinfo module?
It's typeinfo not typetraits and instead of auto you'd need to use the Any type. I recommend you don't use this module and simplify your code to not use types at runtime. Do note that if you want to check at compile time all you need to do is use when.
proc myProc[T](a: T) =
when T is int:
echo "int: ", a
elif T is string:
echo "string: ", a
which you can just turn into overloads since you can't use dynamic dispatch.
proc myProc(a: int) =
echo "int: ", a
proc myProc(a: string) =
echo "string: ", a
Maybe the following is sufficient:
proc myProc(a : auto) =
when a is int: echo "got an int"
elif a is string: echo "got a string"
elif a is float: echo "got a float"
proc myProc2(a : int | float | string) = discard
myProc(1)
myProc("abc")
myProc(2.0)
You can use an object variant if you only know the type at runtime.
proc myProc2(a : int | float | string) = discard
Thats a great work around. Thanks for it. One question. This gave me error.
var mySeq : seq[ int | float | string]
Any work around for this ?I will sure consider the other opinions about this issue. But before that, i would like to do some experiments.
But how do you do the bookkeeping? For this, i have a work around like this.
3. All of my controls have a unique type id. Which is actually an enum.
cType* {. pure .} = enum
Button, CheckBox, ComboBox, GroupBox, Label, ListBox, ListView, ProgressBar,
RadioButton, TextBox
Instead you can use what @demotomohiro proposed or :
proc foo[T](a: T) =
when a is int: doInt()
elif float: doFloat()
else: doElse()
Sorry for disturbing you with my questions. Next time, when i face any obstacles in nim coding, i will insist myself to not to ask in this forum.
Please read the wiki article I linked. Not only that you shouldn't react like I was personally attacking you, but you you should see that the article might be beneficial to you and it was posted to help you.
It's not the first time on this forum that somebody has posted a link to help you after you asked a question, and you instantly dismiss it. Not cool, man.
The reason why I posted that link is because it seems to me that you're asking the wrong questions (as @mratsim correctly recognized). It's not that questions are forbidden, but — if you asked a bit more general question with a detailed "I want to do this and that" maybe we could give you a better answer which more elegantly/idiomatically solves the problem you have.
Currently it feels that we're solving problems which are the results of some wrong decisions several steps before.
I did not meant that you attacked me. May be you are right. I am asking questions in the wrong way. I think i was little Impatient at that time. I should need to try the trial and error method instead of asking in the forum.
It's not the first time on this forum that somebody has posted a link to help you after you asked a question, and you instantly dismiss it. Not cool, man.
Well, that was not my intention. May be i dont know how to react when i think those links are not really going to help me. I cant express my intention more clearly because, there is language barrier exists since English is not my first language. Sorry if i hurt you with my words. I am not intended to do that.
Feel free to ask on IRC then.
The only way to progress fast in Nim is by trying and then asking otherwise you will lose time. I remember learning like throwing eggs on a wall a see what sticks (and then raising bug reports for static and generic types).
Now from all your posts, I think the biggest barrier you have is static typing (types known at compile-time). And you will be able to break through by understanding the core differences, for example here is a super short article.
The main advice regarding that is that it's probably better to keep sequence of floats, int, strings separate unless the benefits trump the ergonomic and performance costs. In the former case, refer to the containers of heterogenous type discussion.