locked
legacy funcitons RRS feed

  • General discussion

  • Hi,

    Recently, I have read that the followings in VB should be avoided where I used to used them without any hesitation where some of them I can't find a direct equivalent in .NET framework (they may exist, but difficult to find them).

             1) Legacy functions in Microsoft.VisualBasic.dll.

             2) On Error ...  'This can do much that Try-Catch cannot do

             3) Exit Sub, Exit For, Exit While ...

             4) Option Strict Off. 'I only turned it ON when I feel of some danger.

             5) Casting using Cint, Cdbl... 'They suggest to use System.Convert

    I use these even in new projects when I feel convenient. Can anybody help me whether to use these or not, and what to use and what to avoid?

    Thanks in advance.

    Wednesday, August 8, 2012 11:57 AM

All replies

  • 1) http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/48925a83-ca2f-47bc-b6c6-c714d4707c4b#04427e9d-0697-42df-8a4c-b051b8b12cef

    http://social.msdn.microsoft.com/Forums/en-US/vblanguage/thread/dfc59cfe-6c1c-4d71-ab21-b3298814d0cc/#49331ebb-558c-4f9d-9cf9-3777b92d4ba8   (starting with "If you have a Framework layer..."

    2) SEH is even implemented deep in the operating system. On Error... simulates this behavior internally. SEH is better structured. You can write different handlers for different kinds of exceptions, and it has a "Finally" part also. You can rethrow exceptions or nest exceptions (InnerException property).

    3) Why not use them? It's ok. However, I use "Return" instead of Exit Function/Exit Sub because I can write it consistently with Functions and Subs.

    4) The question is not why turn it on. The question is why turn it off. I've given so many reasons in so many threads that I won't repeat it all again. So let me please just insert my favorite text template here: With Option Strict Off, your code may fail because you've activated unsafe programming, disabled compiler checks and enabled the automatic and unattended generation of implicit conversions that may fail or not, or may give unexpected or undesirable results. In addition, it enables late-binding which is slow at run-time and steals the ability of verifying the existence of type members from the compiler. It is often hard for people trying to help if the code is not compilable and errors have to be fixed first. Data type awareness and correct data type handling are most essential for every programmer.

    5) Cint, Cdbl are ok. However, they either cast or convert. What to choose depends on the purpose. If you want to cast, I'd only use DirectCast because it only works if the target type matches and doesn't hide a type mismatch due to an unintended conversion.



    Armin


    Wednesday, August 8, 2012 12:37 PM
  • What about some legacy functions that do not have direct equivalents in the Framwork such as financial functions?
    Wednesday, August 8, 2012 8:29 PM
  • Good point. I'd still use them. I've always tried to say most of the legacy functions are useless because I can't claim knowing them all.


    Armin

    Wednesday, August 8, 2012 8:59 PM
  • Bear in mind that CInt, CDate, CDbl, CDec, etc are VB keywords and are part of the language.  I see no reason not to use them.
    Wednesday, August 8, 2012 9:26 PM
  • Hi,

    Recently, I have read that the followings in VB should be avoided where I used to used them without any hesitation where some of them I can't find a direct equivalent in .NET framework (they may exist, but difficult to find them).

             1) Legacy functions in Microsoft.VisualBasic.dll.

             2) On Error ...  'This can do much that Try-Catch cannot do

             3) Exit Sub, Exit For, Exit While ...

             4) Option Strict Off. 'I only turned it ON when I feel of some danger.

             5) Casting using Cint, Cdbl... 'They suggest to use System.Convert

    I use these even in new projects when I feel convenient. Can anybody help me whether to use these or not, and what to use and what to avoid?

    Thanks in advance.

    As Chris said, "CInt", "CDbl", etc are VB's casting approach and are part of the language.

    For Exit For and Exit While - this is the way to do this in VB.  Like Armin, I would use "Return" instead of "Exit Sub" but it's not more correct.

    Functionality such as the financial functions in Microsoft.VisualBasic are very useful - if you feel you can do better, then good luck.  They have been extensively road-tested.

    Option Strict Off - not setting this to 'On' is just careless - you're basically asking VB to try to make sense of stuff that makes no sense - you can't be sure that the result is what you intended.


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

    Wednesday, August 8, 2012 11:38 PM
  • Bear in mind that CInt, CDate, CDbl, CDec, etc are VB keywords and are part of the language.  I see no reason not to use them.

    Not only that, they are specially tuned for VB and may outperform the CLR equivelants:

    "These functions are compiled inline, meaning the conversion code is part of the code that evaluates the expression. Sometimes there is no call to a procedure to accomplish the conversion, which improves performance. Each function coerces an expression to a specific data type....  As a rule, you should use the Visual Basic type conversion functions in preference to the .NET Framework methods such as ToString(), either on the Convert class or on an individual type structure or class. The Visual Basic functions are designed for optimal interaction with Visual Basic code, and they also make your source code shorter and easier to read. In addition, the .NET Framework conversion methods do not always produce the same results as the Visual Basic functions, for example when converting Boolean to Integer. For more information, see Troubleshooting Data Types (Visual Basic)."

    From: http://msdn.microsoft.com/en-us/library/s2dy91zy


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Thursday, August 9, 2012 8:53 PM
    Moderator
  • Yesterday I've played with the conversion functions and put some information together, but then I let it be. Though, since this thread has been revived....:

    I was interested in the current implementation (the compile result) of these functions. Unfortunatelly, not even the language specs explicitly mention which expression types are allowed with CInt(<expression>) etc. The documentation mentions a lot but it's IMO not a perfect technical documentation. For example, while CInt(Double) and CInt(Object) are valid, CInt(Form) is not. That makes sense, but it's not stated anywhere. (If it is, just let me know.) Few examples regarding CInt():

    CInt(Single):

    1. Convert to Double
    2. Call Math.Round
    3. Convert to Integer

    CInt(Double):

    1. Call Math.Round
    2. Convert to Integer

    CInt(Decimal):

    1. Call Convert.ToInt32(Decimal)  (pretty much asm code inside mscorwks.dll involved btw)

    CInt(Object):

    1. Call Microsoft.VisualBasic.CompilerServices.Conversions.ToInteger(object), which performs this:
      - If the reference is Nothing, zero is returned.
      - If the object does not implement IConvertible, an exception is raised.
      - Depending on the object's implementation of IConvertible.GetTypeCode, conversions are performed. The pattern for each type code, using the example of Boolean: 
      Is the object of type Boolean? If so, unbox the value and convert. Otherwise call the object's implementation of IConvertible.ToBoolean and convert the result. With Boolean, True becomes -1 and False 0.

    BTW, usually I make a distinction between converting and casting. Converting creates a new object, Casting only changes the type of the reference. However, the VB language specification (chapter 1.85) considers them all as "Cast expressions". Dunno if I have to agree...


    Armin


    • Edited by Armin Zingler Thursday, August 9, 2012 9:20 PM typo typo typo
    Thursday, August 9, 2012 9:17 PM
  • I see that no one mentioned DirectCast's Brother, Ctype...

    http://msdn.microsoft.com/en-us/library/4x2877xb%28v=vs.100%29.aspx


    If you want something you've never had, you need to do something you've never done. If you believe something to be true, then one day you will be called upon to demonstrate that truth.


    • Edited by Paul Ishak Thursday, August 9, 2012 10:07 PM
    Thursday, August 9, 2012 10:06 PM
  • I see that no one mentioned DirectCast's Brother, Ctype...

    Perhaps because there's no replacement, i.e. you have no choice. 


    Armin

    Thursday, August 9, 2012 10:16 PM
  • Uh,

    It seems that there is something I don't understand.

    What is the difference between Conversion and Casting?

    Friday, August 10, 2012 1:44 PM
  • Uh,

    It seems that there is something I don't understand.

    What is the difference between Conversion and Casting?

    Note that this is my own definition only (though I think it makes sense). The official VB language specification does not necessarily use the same terminology.

    As I said: "Converting creates a new object, Casting only changes the type of the reference."

    Example:

          Dim d As Double
          Dim i As Integer
          Dim o As Form = New MyForm
          Dim f As MyForm
    
          i = CInt(d)
          f = DirectCast(o, MyForm)
    

    • CInt creates a new Integer object from the Double object. That's a conversion. The assignment "i = ..." overwrites the Integer object stored in i.
    • DirectCast does not create a new Form object. It only changes the type of the reference from "Form" to "MyForm".


    Armin

    Friday, August 10, 2012 2:35 PM
  • Thank you all for your replies.

    From the above replies, can we summarize the issue like that?

    1) For legacy functions, .NET equivalents should be used if available.

    2) Structured error handling should be used in favor of "On error".

    3) No problem to use Exit For, Exit While, Exit Sub...

    4) Option strict should be turned ON.

    5) Use Cint, Cdbl, ... instead of the functions in the Convert class.

    Is that OK?

    Saturday, August 11, 2012 2:11 PM
  • Thank you all for your replies.

    From the above replies, can we summarize the issue like that?

    1) For legacy functions, .NET equivalents should be used if available.

    2) Structured error handling should be used in favor of "On error".

    3) No problem to use Exit For, Exit While, Exit Sub...

    4) Option strict should be turned ON.

    5) Use Cint, Cdbl, ... instead of the functions in the Convert class.

    Is that OK?

    IMO yes.

    5) It depends. I'd favor Int32.Parse over CInt(String) becauses the latter has some historic behavior. Convert.ToInt32(String) just calls Int32.Parse, so I don't use it. Also I'd not use CInt(Object). I haven't looked at all the other possible conversions.


    Armin

    Saturday, August 11, 2012 2:47 PM
  • Thank you very much
    Sunday, August 12, 2012 4:04 PM