>- see footer for list info -<
Right, and I'd pointed to that blog post already. When you get to my note
(perhaps delivered later to you but I saw it on the last 30 minutes ago),
you'll see that I point out that the original issue is not necessarily about
strings at all. We may be confusing matters by discussing this, which was
about order of cases.
But it seems you're asserting that the string bug DOES have an affect on
order of cases. I think that's mistaken, too. It points out that the extra
(unexpected and buggy effort) is in the evaluation of the EXPRESSION in the
CFSWITCH. Here's the relevant text:
"Under the covers, ColdFusion attempts to convert the switch
expression to a floating point number, using Java's parseDouble method. If
the conversion works, then ColdFusion uses the expression as a number. If
the conversion fails, however, then an exception is thrown, and an exception
stack is generated, but then ColdFusion handles the exception and uses the
expression as a string. The problem is, that exception throwing and stack
generation gets very, very expensive under load."
So, again, I think the order of cases (JGG's original question) is still on
the table. I've proposed my understanding. All this discussion of strings
aside, I am awaiting a reply from my engineer contacts at Adobe.
/charlie
http://www.carehart.org/blog/
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Snake
Sent: Monday, August 07, 2006 2:36 PM
To: 'Coldfusion Development'
Subject: RE: [CF-Dev] CFSwitch... Aren't all cases evaluated?
>- see footer for list info -<
Yes, but it still has to evaluate all cases up to including the matching
one.
Here are the details regarding cfswitch/case being slower than if/else
http://www.webapper.net/index.cfm?fuseaction=Fuseblog.showcomments&ArticleID
=20060727042244
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Charlie Arehart
Sent: 07 August 2006 18:33
To: 'Coldfusion Development'
Subject: RE: [CF-Dev] CFSwitch... Aren't all cases evaluated?
>- see footer for list info -<
Snake, are you agreeing or disagreeing that a switch is faster than a series
of if/elseifs? I'm afraid I'd have to dust off my Assembler book from 23
years ago to try to understand what you were implying. :-)
My point was that under the covers the switch for cfcase value="value1",
cfcase value="value2", and cfcase value="value3,value4" would become, in
effect:
If value1, jump to case for value1
If value2, jump to case value2
If value3 or value4, jump to case
And because it's a jump to a specific case (or in some languages, a goto),
it would not ever evaluate any other of the cases. And when a given case is
found and done, it jumps to the end of the switch. Again, I don't know this
to be the case, but the fact that it doesn't permit a duplicate value tells
me it is.
Actually, that tells me it's creating instead an associative array that has
the smarts to not allow more than one element of a given name (the values in
the cases) and the value of each element is the case to jump to. Again,
maybe someone with more knowledge of internals of CFML can confirm the
specifics, but I would conclude from the inability to have a duplicate value
that it DOES NOT evaluate each case one by one. If it did that, it wouldn't
need to enforce uniqueness.
I'll certainly welcome hearing from anyone with internals knowledge. In
fact, I'll pass this along to some engineers at Adobe to see if they have a
thought.
/charlie
http://www.carehart.org/blog/
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go to
http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
>- Hosting provided by www.cfmxhosting.co.uk -<
>- Forum provided by www.fusetalk.com -<
>- DHTML Menus provided by www.APYCOM.com -<
>- Lists hosted by www.Gradwell.com -<
>- CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<
