none
Why does VB.NET and C# return different sizes for System.Boolean and System.Decimal types? RRS feed

  • Question

  • If all languages are the same under .NET why does Visual Basic return 2 bytes for Len( System.Boolean ) and 8 bytes for Len( System.Boolean ) while returning 1 byte for sizeof( System.Boolean ) and 16 bytes for sizeof( System.Decimal )? If any geniuses out there could help, it would be appreciated.
    Friday, November 8, 2013 12:48 PM

Answers

  • sizeof is doing what you think it does: it gives you the size of the type.

    Len is a legacy monstrosity.  Provided that the argument is not a String, or an Object, then Len is defined to give you the number of bytes that FilePut (another legacy monstrosity) will use to encode the variable in a binary file.  The implementation of Len is the way it is so that it doesn't break old Visual basic programs, so Len(True) and Len(False) are still 2 because FilePut of a Boolean will still write 00 00 for False and FF FF for true.  That's two bytes, hence Len of a Boolean is 2.  FilePut is still the way it is for the same reason, it's the way the old implementation did it. I think once upon a time it may have been to keep a minimum record size of 2 and get some alignment benefits, but I'm not 100% certain.

    Now my unofficial guess about Len of a System.Decimal is that FilePut was created long before we had the 128-bit Decimal data type.  And you may be interested to know that FilePut will actually throw an exception if the value of your Decimal variable doesn't fit into a 64-bit (8 byte) long value.  (This seems really bogus to me, but again, it's all about legacy stuff.)  The largest whole number System.Decimal value that you can FilePut is 922337203685477D. (The largest fractional decimal value you can write is actually 922337203685477.5807499999999D which is encoded by FilePut as FF FF FF FF FF FF FF 7F)  But Decimals are 16 bytes long in memory, and can easily represent every whole number up to 79228162514264337593543950335D, and can actually represent numbers much larger (with less precision).  Yet FilePut needs to fit it into a long to write it for legacy reasons.  Stupid.

    So FilePut is dumb which means Len is dumb.  And Visual Basic .NET is...well...let's just say it still smells like ye olde Visual Basic.

    Friday, November 8, 2013 3:48 PM

All replies

  • VB's 'Len' function and C#'s 'sizeof' method are not equivalent.

    'sizeof' and System.Runtime.InteropServices.Marshal.SizeOf will return the same value as VB Len for numeric types and char only.


    Convert between VB, C#, C++, & Java (http://www.tangiblesoftwaresolutions.com)
    Instant C# - VB to C# Converter
    Instant VB - C# to VB Converter


    Friday, November 8, 2013 3:26 PM
  • sizeof is doing what you think it does: it gives you the size of the type.

    Len is a legacy monstrosity.  Provided that the argument is not a String, or an Object, then Len is defined to give you the number of bytes that FilePut (another legacy monstrosity) will use to encode the variable in a binary file.  The implementation of Len is the way it is so that it doesn't break old Visual basic programs, so Len(True) and Len(False) are still 2 because FilePut of a Boolean will still write 00 00 for False and FF FF for true.  That's two bytes, hence Len of a Boolean is 2.  FilePut is still the way it is for the same reason, it's the way the old implementation did it. I think once upon a time it may have been to keep a minimum record size of 2 and get some alignment benefits, but I'm not 100% certain.

    Now my unofficial guess about Len of a System.Decimal is that FilePut was created long before we had the 128-bit Decimal data type.  And you may be interested to know that FilePut will actually throw an exception if the value of your Decimal variable doesn't fit into a 64-bit (8 byte) long value.  (This seems really bogus to me, but again, it's all about legacy stuff.)  The largest whole number System.Decimal value that you can FilePut is 922337203685477D. (The largest fractional decimal value you can write is actually 922337203685477.5807499999999D which is encoded by FilePut as FF FF FF FF FF FF FF 7F)  But Decimals are 16 bytes long in memory, and can easily represent every whole number up to 79228162514264337593543950335D, and can actually represent numbers much larger (with less precision).  Yet FilePut needs to fit it into a long to write it for legacy reasons.  Stupid.

    So FilePut is dumb which means Len is dumb.  And Visual Basic .NET is...well...let's just say it still smells like ye olde Visual Basic.

    Friday, November 8, 2013 3:48 PM
  • Thanks mate, it brings some perspective to the weird inconsistency.
    Saturday, November 9, 2013 3:44 AM
  • Thanks mate, it brings some perspective to the weird inconsistency.
    Saturday, November 9, 2013 3:44 AM