Re: the c# return statement
From: Ian Hilliard (nospam_at_hilliardtech.com)
Date: 04/09/04
- Next message: RonsVB_Q_and_A: "SMTP Mail authentication with a login and password"
- Previous message: Mad Scientist Jr: "Re: anyone programming MIDI apps in .NET (DOT NET) ? ?"
- In reply to: Milo T.: "Re: the c# return statement"
- Next in thread: Milo T.: "Re: the c# return statement"
- Reply: Milo T.: "Re: the c# return statement"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 09 Apr 2004 21:03:10 +0200
On Fri, 09 Apr 2004 16:26:05 +0000, Milo T. wrote:
> On Fri, 9 Apr 2004 13:57:04 +0000 (UTC), Donovan Rebbechi wrote:
>> switch is one of my least favourite constructs in code. It can always be
>> replaced with table lookup or polymorphism. Both of these would better
>> address the "bad switch value" issue.
>
> Oh, and the other reason to use a switch:
>
> Object* ConstructMeAnObject(unsigned short idvalue)
> {
> switch (idvalue)
> {
> case Square:
> return new Square();
> case Circle:
> return new Circle();
> case Pentagon:
> return new Pentagon();
> case Sheep:
> return new Sheep();
> }
> }
>
> ... which is the kind of code that gets important pretty quickly once you
> start worry about serialization of data over a network, or to and from
> files.
>
> Sure, you can craft your own table of values and function pointers, but
> it's not as readable - and will never be as readable until C++/C/C# gets
> better support for table-driving data structures.
>
> Although I'd find better table-driven support a bit of a boon right now. At
> the moment I have to tie a UI control to an internal lookup ID, to a member
> on a network serialized structure, to a scaling ID, to an output data
> structure.
>
> Sure would be nice to be able to just fill in a table, and get that to
> spill out all of the interconnections instead of having to hack them in
> manually.
This is a good one. If the idvalue is other than Square, Circle, Pentagon
or Sheep, then you have no return. To that I have to say that one of the
tennits of good coding, states that I cannot trust an object where I do
not control the memory in which it resides. The returned object is not in
the callers control and hence may be invalid. This may be fast but it is
very dangerous. There are far better patterns were reliability is required
and isn't that all the time.
Ian
- Next message: RonsVB_Q_and_A: "SMTP Mail authentication with a login and password"
- Previous message: Mad Scientist Jr: "Re: anyone programming MIDI apps in .NET (DOT NET) ? ?"
- In reply to: Milo T.: "Re: the c# return statement"
- Next in thread: Milo T.: "Re: the c# return statement"
- Reply: Milo T.: "Re: the c# return statement"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
