Jump to content
  • Advertisement
Sign in to follow this  
RKillian

[.net] Something about C++0x got me thinking about named parameters

This topic is 4702 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Slashdot has an article, wherein there was discussion about some of Bjourne and company's proposed changes to the standard. One poster had said something along the lines of wanting named parameters to avoid having to write so many constructors. Although I think a major shortcoming of C# (I know, only half related to C++) has been lack of _default_ parameters, this was something that slipped under my radar since I had quit using Pascal. Is there anything immediately preventing someone from writing a constructor like this?:
NewClass NC = new NewClass("Type=NewClass;ID=8;");

public NewClass (System.String ListOfParameters)
{
  System.Collections.Hashtable Temporary = new System.Collections.HashTable();
  System.String[] PairSets = ListOfParameters.Split(";");
  foreach (System.String NameValueSet in PairSets)
  {
    Temporary[NameValueSet.Split("=")[0]] = NameValueSet.Split("=")[1];
  }
  this.Type = Convert.ToString(Temporary["Type"]);
  this.Type = Convert.ToInt32(Temporary["ID"]);
  Temporary.Dispose();
}

Share this post


Link to post
Share on other sites
Advertisement
Your code isn't C++, it's managed C++ as far as I can see (but that doesn't matter in this discussion).

There is nothing that prevents you from writing such a constructor. Named parameters are more efficient, are statically checkable and less code to write though.

Edit: just noticed that this is the .NET forum, that explains the managed C++ ;)

Share this post


Link to post
Share on other sites
Obviously, yes you can. However, you lose all the compile time checks that proper argument lists provide. Instead, they become runtime errors, and may be completely missed until well after the code's been written. So you probably shouldn't do so.

CM

Share this post


Link to post
Share on other sites
Heh, yes, it's C#. Just replace . with :: and it's Managed C++ though.

Losing compile time type safety is unfortunate (and something I did overlook, thanks) but I think the time saved not writing 40 different constructors might be worth it for now so long as I check everything and throw the right exceptions as it's processed inside.

Share this post


Link to post
Share on other sites
I hope you exaggerating. An average fourty constructors for every class seems a bit much. It could depend on the size or type of the project, but I never felt that writing contructors was keeping me from making the dead line.
The proposed method looks like it's only going to cause confusion, which is never a good thing when it comes to productivity. Also using a HashTable seems a bit like overkill, but now I'm just nitpicking. ;)

To me, still the biggest (but small) shortcoming of C# is lack of decent sprintf/sprintf etc. methods (instead of the format crap it has now). But I digress...

Share this post


Link to post
Share on other sites
i prefer to wait for c# 3.0 to get that typesave, and till then, write the needed constructors, and for special cases, construct, and set fields with help of accessors afterwards..

i don't want string parsing, tokenising, analizing, and type conversions just to construct an object. thats a huge overhead for something simple.

Share this post


Link to post
Share on other sites
Quote:
Original post by RKillian
Heh, yes, it's C#. Just replace . with :: and it's Managed C++ though.

Losing compile time type safety is unfortunate (and something I did overlook, thanks) but I think the time saved not writing 40 different constructors might be worth it for now so long as I check everything and throw the right exceptions as it's processed inside.

That sounds great, but you're still postponing finding a compile time error until run time. This is icky. It also forces you into pass-by-value [or, perhaps, pass-by-tostring], which is quite contrary to what one would expect in C#.

In the mean time, you may look into the named constructor and the named parameter idioms. That site is intended for C++, but I'm sure something similar can be assembled for C#.

CM

Share this post


Link to post
Share on other sites
Quote:
Original post by WanMaster
I hope you exaggerating. An average fourty constructors for every class seems a bit much. It could depend on the size or type of the project, but I never felt that writing contructors was keeping me from making the dead line.
The proposed method looks like it's only going to cause confusion, which is never a good thing when it comes to productivity. Also using a HashTable seems a bit like overkill, but now I'm just nitpicking. ;)


I don't know, if you looked at my class heirarchy... :P

Seriosuly, at the leaf nodes there might be 20 or so properties. The closed engine from which I have taken some cues uses a scripting language with such a function to create it's objects. As I have control over the engine this time, I figured bypassing the middleman was an idea to pursue. The couple hashtables I use throughout the system are for matching properties up by name (it makes more sense with more properties than the example). Exaggerrating a little, yeah, still wanted to make the point though.

I suppose it's particularly appealing as a shortcut right now because at the earlier stages of a project you have so much stuff that depends on so much other stuff that needs done to even work that it's maddeningly circular. Not exactly sure what I'll go with now, hopefully I can get a grip before it spirals out of control. Appreciate the input from everyone though, it's given me some ideas to consider.

Quote:
Original post by davepermen
i prefer to wait for c# 3.0 to get that typesave, and till then, write the needed constructors, and for special cases, construct, and set fields with help of accessors afterwards


Or Microsoft could just stop with these half-completed runtimes. I hate to bash them because of the implications but I had to wait long enough for 2.0 to fix what was broken or missing in 1.1. Being locked into a particular version of the framework, as opposed to, say, regular C++ going straight to machine code every time no matter what compiler, is one of the biggest disadvantages of .NET.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!