Guys,
What are you talking about, overloading being depreciated or not modern OO - and lazy? I'm not advocating overloading in any way, shape or form, but your arguments are simply incorrect.
Have you taken a look at Delphi or .Net? .Net uses function overloading all throughout the BCL (Base Class Library). The Delphi VCL uses function overloading too. Both of these are neither C++/C or depreciated frameworks and are very object oriented in design. Sure they have their floors, but overloading is not one of them.
Convert.ToUInt64 has about 18 overloads. Also it is safe. C# does no explicit casting, so you know that your byte will only be called by the method taking a byte parameter, or a compiler error will result. You must explicitly cast. Even in C++ if there are ambiguities, a compiler error will result.
See Convert.ToUInt64 Method
Cheers,
Stu
What are you talking about, overloading being depreciated or not modern OO - and lazy? I'm not advocating overloading in any way, shape or form, but your arguments are simply incorrect.
Have you taken a look at Delphi or .Net? .Net uses function overloading all throughout the BCL (Base Class Library). The Delphi VCL uses function overloading too. Both of these are neither C++/C or depreciated frameworks and are very object oriented in design. Sure they have their floors, but overloading is not one of them.
Convert.ToUInt64 has about 18 overloads. Also it is safe. C# does no explicit casting, so you know that your byte will only be called by the method taking a byte parameter, or a compiler error will result. You must explicitly cast. Even in C++ if there are ambiguities, a compiler error will result.
See Convert.ToUInt64 Method
Cheers,
Stu