|
I'll admit, I don't like that - but I see what you are doing.
It kinda depends on what Count is: if it's a field-backed property then I'd probably just use the property directly:
for(i = 0; i < list.Count; i++) because it's a load more readable, and thus more maintainable.
If it isn't, then I'd probably split it and to heck with the scope:
int itemsCount=list.Count;
for(i = 0; i < itemsCount; i++) Or just use a foreach instead.
For me, readability is foremost: code that makes the reader reader stop and have to backtrack to work out what he just read is intrinsically "bad" - it makes for less maintainable (and thus reliable long term) code in my opinion. Performance is important, yes - but readability is way more so!
But I don't do code reviews on your stuff, so you can roll your way all you want!
And thanks for dumping the var from the loop!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
By the way as for performance, a getter that only returns a field almost always gets inlined (so there is no call, but probably still a load, but loads can get floated up out of loops sometimes so..), for example summing a List<int> while getting the Count property every time is like this: (Core 2.1)
00007FF8646F1807 xor edx,edx
00007FF8646F1809 mov r8d,dword ptr [rcx+18h]
00007FF8646F180D test r8d,r8d
00007FF8646F1810 jle 00007FF8646F1830
00007FF8646E1812 cmp edx,r8d
00007FF8646E1815 jae 00007FF8646E183A
00007FF8646E1817 mov r9,qword ptr [rcx+8]
00007FF8646E181B cmp edx,dword ptr [r9+8]
00007FF8646E181F jae 00007FF8646E1863
00007FF8646E1821 movsxd r10,edx
00007FF8646E1824 add eax,dword ptr [r9+r10*4+10h]
00007FF8646E1829 inc edx
00007FF8646E182B cmp edx,r8d
00007FF8646E182E jl 00007FF8646E1812
Storing the Count before does .. about the same thing, with a slightly different start but not in a way that matters, and different register allocation. So it just doesn't matter, at all.
Other than that there is plenty to critique about Core 2.1's codegen..
|
|
|
|
|
I don't find it less readable, but then i'm so used to the pattern by now I'm maybe not the best judge of that.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I actively avoid learning new language features, and I'm unlikely to use that, but is there something similar for TryParse ?
if ( System.Int32.TryParse ( s , out int i ) ...
To likewise limit the scope.
|
|
|
|
|
I believe that was added at C# 7 - and it should work exactly as you show.
The
if (obj is string str)
{ is really handy when you write event handlers, where you want to use a control:
private void AnEventHandler(object sender, EventArgs e)
{
if (sender is TextBox tb)
{
...
}
} Instead of
private void AnEventHandler(object sender, EventArgs e)
{
if (sender is TextBox)
{
TextBox tb = (TextBox) tb;
...
}
} Or
private void AnEventHandler(object sender, EventArgs e)
{
TextBox tb = sender as TextBox;
if (tb != null)
{
...
}
}
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Ah, yeah, OK I see it. I don't like the syntax, but it's something I would use... were I not limited to VS 2013 (due to SSIS 2014).
|
|
|
|
|
Oh, by the way: the TryParse declaration - I just checked and it doesn't limit the scope the way I assumed it would.
private void MyMethod()
{
{
if (System.Int32.TryParse("666", out int i))
{
Console.WriteLine(i);
}
Console.WriteLine(i);
}
Console.WriteLine(i);
}
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
So it's... a love hate relationship?!
Pink would say, you hate it so much it can only mean true love!
|
|
|
|
|
Yes, like with anonymous methods, awaitable methods, iterators, but for different reasons.
(By iterators i means C#'s yield "coroutine" capabilities, not the related IEnumerable nonsense - can't stand that)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
This as operator is faster than a C# cast?! It seems to work like dynamic_cast , which is C++'s slowest one (use the vptr to verify the type). Other C++ casts are fast because they just assume the target is of the desired type, perhaps after a compile-time check.
|
|
|
|
|
Yep it's faster in .NET. Go figure. I guess verification the cast is successful is a separate step or something. .Net Tips - using as vs casting in C# | theburningmonk.com[^]
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Now can you add an isnt or (aint) operator?
if ( v isnt string ) ...
|
|
|
|
|
It parses fast enough, but it takes so long to resolve what it parsed though. I need to figure out how to optimize this thing.
Still, the parser is getting more and more stable. It already parses better than that ANTLR C#6 grammar did.
Technically, it can usually convert to VB without going through the resolution process, but it's kind of a hack. It just so happens that in VB there's no difference in syntax between a delegate invocation and a method call, nor a field access and a property access so it happens to work, but it's not proper to resolve method invocations as delegate invocations and all member access as field access which is what the parser has to do, since it doesn't have type info.
Overall I'm happy with the project but I need to figure on something to make it more speedy so it will be generally useful.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Awesome work (and best of luck with the optimising)
cheers
Chris Maunder
|
|
|
|
|
Thanks. The articles bombed so far but I think that's either because it's so preliminary, or people don't understand it, or nobody has a use for it. Or a combination of those things. Still, *I* have a couple of uses for it and I understand it so that's a start.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
There are no lines.
Something I keep wondering about your Slang system is whether or not it can be used to implement a language extension similar to Oracle's PRO*C or Microsoft's ESQL -- SQL statements embedded in C programs (or C# now I suppose).
|
|
|
|
|
LINQ already kind of provides that, but yes. You can use this as a starting point to implement a Domain Specific Language.
If I was real clever I might make it so you could extend the language through the language itself. Adding keywords and such but that's out of the scope of this for now.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: LINQ already kind of provides that
It does no such thing.
|
|
|
|
|
Then i misunderstood what you meant. LINQ provides SQL like syntax over disparate datasources, including databases.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
Then I must be using a magic feature of an as of yet unheard of version of C# with magical embedded sql like syntax that nobody else has access to.
Gosh thanks microsoft. Boy, I feel speshul.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Unstoppable force, may I introduce immovable object.
ESQL and Pro*C aren't "SQL Like".
They are embedded SQL.
|
|
|
|
|
Wow... are you trying to impress us?
well.... it might work!
you need to make an article with some cool nifty example! :P
|
|
|
|
|
The 2 articles i posted on it so far bombed LOL
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|