Named arguments, optional arguments, and default values

home
c#
view story

5 Kicks

Kick It.

Drop Kick

Named arguments, optional arguments, and default values (blogs.msdn.com)

submitted by samng(130) 1 year ago

C# 4.0 introduces the concept of optional parameter values into the language. Now, this has been a controversial subject in the past, and we have had many requests for the feature, but have traditionally stayed away from it. So, why now? Well, before we get into the philosophy of why we decided to add it this time (which we will! I promise!), first lets discuss the feature itself.

1 comment | category: C# | Views: 20

tags: C# another

Everyones tags:

Your Tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

Jemm(9400) -

pmbrown(0) -

samng(130) -

grenade(85) -

taenia(0)

Comments:

posted by RobertGBryan(0) 10 months, 12 days ago

Sam,

Can you comment as to why a default argument can't be a Ref or Output type? In C++, the compiler simply does not care. When I made the suggestion for this improvement, I really thought that the MS development team would implement it the way C++ does. The main benefit as I see it is that in large projects when a new feature needs to be added to a function such that the calling sequence needs to be changed because of a new argument, only the actual function calls that need to use the new argument need to be changed. I have found that in large C++ projects that adding a default argument means that I don't have to go change the calling sequence in hundreds of different spots, only the few calls that need to use the new argument. It is a great time saver. Don't understand why this can't be applied to output or ref arguments as well. C++ certainly has no problem with that.

My other recommendation that MS chose not to implement was to treat intrinsic data types as true class objects. I have written a C++ app that provides the capability for a developer to register an int, float, real, string, etc. variable with a class of mine by passing a pointer to it. So, when that value is updated in his code, no update calls are necessary to inform my class of the new value since my class already has the pointer to the object. In C#, this functionality works the same with any type of object defined as a class since class objects are passed by ref, which in reality is a type of pointer. But, this is not the case for C# intrinsic data types like int, float, double, string, datetime, etc. These data types can only be passed by value (at least in safe mode - which is the only code I'm writing at the moment).. This means that if I port my C++ app to C#, I will have to find some other way of handling the registration of intrinsic types. The only thing I can think of is to tell the developer to call a set function every time he updates one of these types - which is less efficient. I believe that Java used to treat intrinsic types the same way in that they could only be passed by value, but this was changed a few years ago (by adding new intrinsic data types that could be passed by ref?). In any case, can you please investigate why intrinsic data types can't be created on the heap instead of the stack and then passed by ref? A special syntax could be added to provide this capability or perhaps a new heap int, float, char, etc. datatypes could be added.

Everyones tags:

Your Tags:

Most Active Users