*Looking for some Answers*
Woah VB 2005 is taking off.
If anybody could answer these questions before 3pm GMT, would be great.
- 1. How come the decimal type uses 16 bytes whereas the double only uses 8 bytes although the double allows for much larger numbers ?
- 2. Is OO programming overrated, it is just somebody’s abstract idea on things, VB 6 must be regarded as being at least 50% OO due to the fact that the objects are just classes of methods / properties / variables etc ?
- 3. So the .Net framework is completely independent of the win32 API - if so how do you call / declare a function / sub from a non-framework dll ?
- 4. Could the framework essentially being seen as a mini OS ?
- 5. How do VB 2005, C# and managed C++.NET compare to say VB 6 , C++ and Delphi in terms of speed, you have this extra MSIL that .NET has to compile to first before its compiled to x86 language, so does this slow things down much if at all ?
- 6. Is saying Ctype(value, Datetype) the same as the shorthand version etc, Cdbl(), Cint() , i.e i'm not missing anything here. ?
- 7. If you had an Integer and wanted it converted to a string, would you,
VB Code:
CType(MyInteger,String) <--/--> CStr(MyInteger)
versus
Convert.String(MyInteger)
?
Cheers for any help!
Re: *Looking for some Answers*
1. The Decimal type is fixed point, while the Double is floating point. While a Double can contain larger values it has lower precision, i.e. number of significant figures, than the Decimal. Decimals are not susceptible to round-off errors the way Doubles are.
2. OOP has great potential but that potential is often not realised because project scale is either too small or developers are two lazy to make a stitch in time to save nine later.
3. All Windows programming uses the Windows API. The .NET Framework is a layer between us and that API. If you need to use the Windows API directly then you use the DllImport attribute to declare an external, unmanaged method. In VB you can also use the Declare statement, which is a little easier but less flexible. It is basically a hold-over from VB6. The DllImportAttribute class is the more .NET way to do it.
4. No.
5. JIT compilation of managed code is barely noticeable on relatively up-to-date systems in most applications. Unmanaged C++ will always be king in terms of raw speed but you've got to be a little masochistic to actually want to code unmanaged C++ these days. ;)
6. Yes, they are the same.
7. Although they can be used to perform conversions it is my opinion that CType, CStr, etc. should only be used to cast. If the underlying object is a String but it is being accessed via an Object variable then use CStr to cast the reference as type String. If the underlying object is not a String then use Convert.ToString or else the object's own ToString method to convert the object to type String. Think of it this way: if you're changing the actual type of the object then you're converting so you should not use CType, CStr, CInt, etc. If the object is not changing but only the type of the reference by which you're accessing it then you're casting and DirectCast, CType, CStr, CInt, etc. should be used.
So, did I just help you get a job or pass an exam?
Re: *Looking for some Answers*
Quote:
Originally Posted by jmcilhinney
So, did I just help you get a job or pass an exam?
I have an interview at 3pm, your answers are obviously pretty slick so they can only help!
thanks.
