In regards to cdome's original question, I think tricking the compiler to
ignore side effects for a certain function is the wrong way to go about this.
If the memoization table was passed as a function parameter, the function would
have no side effects, with no tricks involved.
Also, in my opinion, violating the strict aliasing rule is a code smell, and so
I think we should avoid accommodating bad code with the "-fno-strict-aliasing"
flag.
I read a bit about the strict aliasing rule, and it seems that the only code
that would be broken by "-fno-strict-aliasing" is code that declares two
pointers to the same block of memory, and simultaneously uses both pointers to
access the memory. I'd say that most programs, especially Nim progr
**@ivanitto**: I agree with Varriount that it's best to declare the types in
Nim along with the correct C type pragmas. You don't have to define the entire
type, just enough to indicate its semantics to Nim and to identify it in the C
type system:
type
BoxOfStuff {.final, i
Haha, yep, it's a pretty comprehensive project and is bigger than a lot of Nim
projects. The code makes use of Nim features such as async and macros. Imagine
how large the program would be if Nim didn't have those features!
I've open sourced and published my InfluxDB-to-MySQL protocol converter to
[https://github.com/philip-wernersbach/influx-mysql](https://github.com/philip-wernersbach/influx-mysql).
It is written in Nim, and is being used in production to power a big data
solution. This is a great example of prod