|
|
Some of the info was missing, it was meant to say 6 stone per chin
Disclaimer: No offence meant to any real mothers, Pompey's or otherwise.
modified 9-Dec-19 9:13am.
|
|
|
|
|
So C# has "as" which is like an attempted cast. If the cast fails no error is thrown, but the target value is set to null, such like:
string str = obj as string;
A) It's faster than a cast
B) it lets you do two things in one - cast an object and check the object's type.
So it's more efficient than a cast, in .NET
However, it leads to code patterns like
var cc = obj as CodeComment;
if (null != cc)
{
_VisitComment(cc,args, action);
return;
}
var ccu = obj as CodeCompileUnit;
if (null != ccu)
{
_VisitCompileUnit(ccu,args, action);
return;
}
var cd = obj as CodeDirective;
if (null != ccu)
{
_VisitDirective(cd, args, action);
return;
}
C#8? introduced a switch style pattern for this but it's still ugly.
That's why I don't like it.
However,in Slang it is not supported, nor can it be, because the only way to emulate that particular operator (which resolves to a specific IL instruction) is using minor reflection (Type.IsAssignableFrom()), which is unacceptable here.
And so a lot of my code simply won't parse. 
Curse the CodeDOM for being so sparse. I really wish it supported more operators. There are no unary operators, no try-cast (like above) and most of the assign operators are gone as are maybe half the binary expressions available in most languages. It's kind of a bad joke but there's nothing to be done about it now. Microsoft made the standard. Others adhere to it, broken as it is.
I mean, the CodeDOM is useful but it's bloody limited. I wish Roslyn had pluggable support for additional compilers like F# but as far as I know it's strictly C# and VB
Still, it might be useful eventually to make a Roslyn version of slang once it too can run on a phone. But for now I'm stuck with the stodgy old CodeDOM. Though working with Roslyn would mean most of what my code does wouldn't be necessary in the first place.
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.
|
|
|
|
|
And now there is in the newer version:
if (obj is string str)
{
...
}Which - now I've got used to it - I like; it's a good way to limit the scope.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yup, that's also how I roll now! 
|
|
|
|
|
I like that.
I get crap from some people for my for loops that limit my count vars like:
for(int ic=list.Count,i=0;i<ic;++i)
But I'm big on limiting scope.
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'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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
