Re: the c# return statement
From: Milo T. (fantastical_at_malaprop.net)
Date: 04/09/04
- Next message: Milo T.: "Re: the c# return statement"
- Previous message: John Eikanger [MSFT]: "Re: Finding Posts"
- In reply to: Ian Hilliard: "Re: the c# return statement"
- Next in thread: Ian Hilliard: "Re: the c# return statement"
- Reply: Ian Hilliard: "Re: the c# return statement"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 09 Apr 2004 20:54:52 GMT
On Fri, 09 Apr 2004 21:03:10 +0200, Ian Hilliard wrote:
> 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.
Well, I wasn't trying to write solid and robust code, I was trying to spend
5 seconds coming up with examples where switch statements would be useful.
However, I appreciate your willingness in becoming a code reviewer for me,
though I would like to point out that the correct way to solve the above
problem is merely to add a default: return NULL; or default: throw
exception("Unknown object type in deserialization"); to the bottom of the
statement.
In future, I will remember to provide you with a fully compiled, zipped up
source tree with a make file instead of just a quick off the cuff example.
By the way, you missed the fact that I was missing a main() function as
well.
-- People in the killfile (and whose posts I won't read) as of 4/9/2004 1:52:27 PM: Peter Kohlmann, T.Max Devlin. Matt Templeton (scored down)
- Next message: Milo T.: "Re: the c# return statement"
- Previous message: John Eikanger [MSFT]: "Re: Finding Posts"
- In reply to: Ian Hilliard: "Re: the c# return statement"
- Next in thread: Ian Hilliard: "Re: the c# return statement"
- Reply: Ian Hilliard: "Re: the c# return statement"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
