Yes, the suggestion to use **parseutils** and **strscans** is not a bad one,
and thanks for the code example. But I did consider both of those before
proceeding.
First, I couldn't figure out how `parseBiggestInt` works. It is very important
to specify the size of integer. I don't want a machine-dependent solution. It
drives me crazy that I cannot specify the size that the input format provides.
Second, I saw that **strscans** provides a weird `$w`, which is just the wrong
thing. I want _any_ non-whitespace. There is an inversion matcher, but I wasn't
sure how to use it. I couldn't figure out the "user-definable matchers".
Basically, I just had much more confidence in the API for `sscanf` than for
**strscans**. Maybe examples would help.
+({'a'..'z', 'A'..'Z', '_', '0'..'9', '/'} -> buf0.add($_)),
Run
I would never have guessed that. As Vindaar commented in his code, "this is
kinda ugly". Yes it is.
Third, I have trouble telling when memory allocations will occur. That's a big
problem with Nim strings around to the parsers. Just look at the disaster in
`streams.FileStream`, which is incredibly slow. (And don't get me started on
**threadpool** ). I need to know what is going on at a pretty low level.
Finally, on avoiding low-level code, I think people in this forum misunderstand
the niche for Nim. There are tons of good languages these days. I need
something specifically for:
1. rapid prototyping
2. easy glue logic
3. speedy interfacing with C/C++
Python is better at (1). Python is _almost_ as good at (2), but I want a
language with static-typing and fast compilation, instead of an interpreted
language. (3) is where Python fails. Static-typing is absolutely required for C
interfaces because so many things can go wrong.
I included in my broken code only the minimum needed for debugging. It's
actually a lot of code, growing all the time, and calling various C and C++
libraries. That's not even up for discussion. Without the C/C++ interfacing, I
would use a different language. And what I'm saying is that I _still_ need to
be able to debug. I will have low-level bugs in my code. I need ways to detect
them. The "newruntime" seems to be critical for that. Araq is right.
