I have trouble with “<<=” and “>>” operators with VB,
I have this code in c#, that works:
public float GetTemperature()
{
byte[] readBuffer = new byte[2];
// Get MSB and LSB together
int temp = readBuffer[0];
temp <<= 8;
temp |= readBuffer[1];
// Negative value test (subzero temperature)
temp -= (readBuffer[0] >= 0x80) ? 65536 : 0;
// Get the temperature in Celsius
return (float)((temp >> 4) * 0.0625);
}
and code with VB.Net, that can’t be compiled, because of ?unsupported? operators? :
Public Function CorretedTemp(readBuffer As Byte()) As Single
' Get MSB and LSB together
Dim temp As Integer = readBuffer(0)
temp <<= 8
temp = (temp Or readBuffer(1))
' Negative value test (subzero temperature)
temp -= If((readBuffer(0) >= &H80), 65536, 0)
' Get the temperature in Celsius
Return CSng((temp >> 4) * 0.0625)
End Function
At desktop vb.net app operators and functions works.
@ cyberh0me - Thanks for answer, but I work with VB for years and with c# everything is more comlicated for me, with VB, I’m at home
@ reply -
I found these solution, do you think it’s correct?
<System.Runtime.CompilerServices.Extension>
Public Function RightShift(integerToShift As Integer, bitsToShift As Integer) As Integer
Return CInt(integerToShift / 2 ^ bitsToShift)
End Function
<System.Runtime.CompilerServices.Extension>
Public Function LeftShift(integerToShift As Integer, bitsToShift As Integer) As Integer
Return CInt(integerToShift * 2 ^ bitsToShift)
End Function
Remember, vb.net is a stepping stone/training wheels language to help the transition from vb to c#. One shouldn’t linger too long in vb.net. Once you get your head around the the ‘.net’ part, you should graduate to c#.
Any missing features in vb.net should just spur you to graduate to c# that much faster.
Hi at all,
apart from the incompatibility of VS2015 with the latest 2 SDK (prerelease 2016 1 and 2) where app transfer to not work in no way,
in VS2015 with latest 2015 SDK (applying the changes to each .vbproj file for the Microsoft.VisualBasic library ) the VB.NET bit shift operators magically reappeared and works …
I look forward that we do something about it.
A programming language is just a syntax to express the logic. The logic is the hard part, not the syntax. Concentrate on what you are trying to accomplish, not how it is written in a certain language. I have used VB for a number of years, and I started in earnest on C# for .NETMF. Both are fine languages and both are equally powerful. There is not enough difference between how you use them to be hesitant to change between them.
These days I work with C# and C++ a lot (and LUA too). Sometimes I forget the proper syntax in one of them but what I want to do is the same. How is the Switch/Case formatted in C++ again? It is easy to do a quick search online and find the answer. Or some built in this like String.Split in C# are not in the C++ Standard Library and a quick Bing search turned up Tokenize (which has been around since C) which did the same job for me.
As a VB programmer for, since HP basic on the HP9845 showed how much easier basic was than Fortran, I find it irritating that the community reaction to VB issues is to tell the user to switch to C#. NETMF is advertised and marketed to operate with both VB and C#. Currently you are seriously limited in debugging options of operating in VB (see [url]https://www.ghielectronics.com/community/forum/topic?id=19600[/url]) not to mention the “missing operators”.
There are many discussions on the internet about one language or the other, but the fact remains that a significant number of folks work in VB. It is also generally acknowledged that there are few differences in the two in speed or what you can do, and for me, VB is much easier to read.
I believe there is value to keeping VB as an option, as the underlying engine is the same. If so, let’s correct the deficiencies. If not, lets kick it out of the NETMF and Win10 family. Otherwise, there will be lots of frustrated newbies who are not aware of the few defects, but like the debugging issue that crashes VC, can turn the user away…
Another option for MSFT and GHI to both have notes on their sites that acknowledge the limitations, in an effort to reduce frustration. Then the user can evaluate if it is worth learning a new syntax. As one that has a huge multdecade investment in visual basic, I will stick with VB.
@ rockybooth - and the great thing about .NET is that once compiled the DLL (whatever the compiler) make an import and not very care if C # or VB.NET… is a puzzle of different language libraries … but who cares? If you have the sources you have to learn to use them and both.
I should also have pointed out that one of the great things of VS and NETMF is that multi-project solutions are a great way to include libraries of previously developed code with a new project, and those libraries can be VB or C#, or a mixture of both. This of course means that operators missing from VB can be include in a very short project written in C# where they do exist, and thus used in VB by including that project in your solution. Its a little cumbersome, but gets the job done.
There are also several code translators on the net that you can feed C# into that will produce VB - in my experience they work almost 100% of the time. Its another way to learn the other language, and works quite well to take examples in C# and turn it into VB which we know is easier to read.
Now if the VB debugging issue was fixed in 4.4…
