Open davidhesselbom opened 8 years ago
It was introduced in https://github.com/fasterthanlime/rock/commit/4f6d871407e2e683b023e464b0b395780d34a796 (Jan 25, 2010)
Other codes at that time use init
.
Maybe the compiler uses Range new
to unwrap a..b
and the compiler was not smart enough to start more rounds to resolve init
to new
at 2010, I guess ?
it was written at a time when covers didn't have constructors
this
Other codes at that time use init.
yes, but not covers afaik?
Okay, so if I make a PR where I change it to
init: func@ (=min, =max)
, you won't mind?
@davidhesselbom if it works, I'd be all for it! It's cleaner.
However, in the generate code, that means one more call + pointer dereferences.
The current code generates this:
struct Range Range_new(int min, max) {
struct Range r;
r.min = 0;
r.min = 24;
return r;
}
Your proposed change will generate this:
struct Range Range_new(int min, int max) {
struct Range r;
Range_init(&r, int, min)
return r;
}
void Range_init(struct Range *range, int min, int max) {
range->min = min;
range->max = max;
}
Nothing a good compiler can't optimize, perhaps I used to think Range was performance-critical. Not sure.
Having new directly as a static func
is perfectly valid ooc, definitely less funky than trying to cull the GC off of the sdk :)
Okay, I didn't mean to suggest it's invalid or anything, it's just... longer, and a bit unusual. I hadn't thought about performance, but otoh, I seem to remember you saying someting along the lines of "ooc wasn't designed for speed", and like you, I doubt the change proposed will have any significant effect.
About the GC, ripping it out wasn't my idea, I swear.
@davidhesselbom once upon a time I was pretty happy that ooc had "the speed of raw C", but that was before String became a class, before many other changes...
Back then I also had a very bad instinct on what did and did not matter performance-wise. As the generated code grew in complexity, it became harder and harder to get useful info out of profilers like cachegrind.
Anyway, as far as performance goes, instincts lie, measure all the things! :8ball:
as far as performance goes, instincts lie, measure all the things!
True...
ooc needs help speed-wise. Once when I wrote a BF interpreter in ooc, it was slower than Julia, PyPy, and gasp JavaScript...
ooc generics are slow
ftfy
I can think of reasons why
Range
doesn't have a normal (init
) constructor:Are there other reasons?