|
|
Now we must talk about the Oracle at Delphi. Sheesh.... 
|
|
|
|
|
|
I'm just glad Delphi wasn't at (from) Oracle.
|
|
|
|
|
I just mentioned that, before reading your post.
|
|
|
|
|
which means ... we are both correct - that's great 
Regards,
|
|
|
|
|
Yeah. I was wondering what Anders would say about VB being C#'s progenitor.
|
|
|
|
|
Applause ! Finally Delphi is mentioned.
And, can we not give Anders, Mads, Eric L., Eric T., and others, some credit for bring geniuses who created something remarkable ?
«Differences between Big-Endians, who broke eggs at the larger end, and Little-Endians gave rise to six rebellions: one Emperor lost his life, another his crown. The Lilliputian religion says an egg should be broken on the convenient end, which is now interpreted by the Lilliputians as the smaller end. Big-Endians gained favor in Blefuscu.» J. Swift, 'Gulliver's Travels,' 1726CE
|
|
|
|
|
|
Was happy that they finally updated the switch in C# to have be as flexible as the Visual Basic Select Case. Waited a long time for that one.
|
|
|
|
|
|
Well your certainly have the right to not use the new features. How about something about why you do not like the changes to the switch statement.
|
|
|
|
|
One of the "beauties" of the stock C# switch statement was that using integer case qualifiers it compiled to a mean and lean jump-table in CIL. I assume it still does; have yet to see any performance comparisons of use of the new features and other techniques for switch-a-roo.
I like the new features.
«Differences between Big-Endians, who broke eggs at the larger end, and Little-Endians gave rise to six rebellions: one Emperor lost his life, another his crown. The Lilliputian religion says an egg should be broken on the convenient end, which is now interpreted by the Lilliputians as the smaller end. Big-Endians gained favor in Blefuscu.» J. Swift, 'Gulliver's Travels,' 1726CE
|
|
|
|
|
Note that this is not at all set by the language defintion, but 100% decided by the compiler writer. I have seen compilers (not C#) that generate completely different code depending on the optimization switches: If you optimize for speed, and the case alternatives are sparse, you may end up with a huge jump table. If you optimize for code size and the number of specific cases is small, it might compile like an if ... elseif ... elseif ... When you switch on strings, hash methods are sometimes used to reduce the number of string comparisons that must be done.
Compilers may try out several different methods of compiling a switch statements, and assign scores to each alternative based on the compiler options, such as optimization and target architecture. The one with the highest score wins, and is passed on to later compiler stages. This sure slows down compilation, but is generally worth it.
A small sidetrack, but closely related: Contrary to common belief, modern standards for sound and image processing, such as MP3 and JPEG, does not specify how the compression is to be done, only how a compressed file is decompressed. A good compressor may try out a handful of different ways to compress the original (sometimes varying wildly in compressed encoding), decompress according to the standard and do a diff with the source material. The alternative with the smallest diff result is selected. (Or, the size of the diff result gives that alternative fewer or more points on the scoreboard, together with e.g. compressed size). The compress-decompress-diff-evaluate sure takes CPU power, but today we have plenty of that, at least for sound and still images.
|
|
|
|
|
I think that is the reason that it took so long to upgrade the switch statement. I would expect that you are right an it still with do that. Of course could also do a string which would be a little more complex, and I am sure there is a different implementation for a int and string. swtich statements are a bad smell, so I look to see if there is a better implementation than a swtich.
|
|
|
|
|
Why didn't they make it multivariable as well, like in CHILL?
switch (a, b, c) {
(1, 'a', 4.3): ...code;
(2, 'A', 0.0): ...code;
(2, ELSE, pi): ...code;
(3, 'C', *): ...code;
ELSE: ...code;
}
* for a value means "don't care". ELSE for a value means "any value not used in any other switch alternative for this variable.
Yes, you CAN make it very messy if you exploit the flexibility for all that it is worth. But a diciplined use can be far more readable than a 20-way switch, each alternative with a 7-15 way (varying among the 20) switch, each of those again with a 2-15 way (varying) switch. Then I'd rather prefer the single, clean, 3-dimensional switch.
|
|
|
|
|
Did not have exposure to that. Interesting. Not sure how often it would be useful, but if it helps....
|
|
|
|
|
The CHILL language, providing this, was essentially developed to program network switches. If you have been much in contact with communication guys, you have certainly noted that they love designing protocols as state machines:
Any entity is at any time in one of a limited number of states. Whatever happens in the interface is modeled as an atomic event; the event ID being one of a limited set of values. The processing of the event depends on the current state and the event ID. Processing is (conceptually) atomic, and changes the entity state into a new value. So a very common usage would be like (in quasi-C syntax, Chill was somewhat different)
switch (state, eventID) {
(disconnected, setupReq): ... code to handle a call setup request...
(transferMode, dataPacket): ...
... more state/event combinations, with their specific handling ...
(transferMode, ELSE): ... error hadling, protocol error, not allowed in transferMode state...
ELSE: ... general error handling for illegal event in current state, not treated as a specific case...
Now, some protocols are so complex that a "pure" state machine would end up with thousands of states. So the protocol spec defines from one up to a small handful of state variables, which may be thought of as sub-states in most cases (not always, but "sort of like"). So you could add one or more of those state variables as the third switch field, if they should lead to distinctly different handling. (For many switch cases, the switch label would be "Don't care" for that state/eventID combination.)
So, for protocols defined as state machines, the multidimensional switch statement is a perfect match.
I love that kind of protocol specification! It is terse, lucid, unambiguous, and most of all: It pinpoints all protocol error situations and makes it very clear to you where you should define an error handler, and the reasons for raising this error condition.
|
|
|
|
|
Anders Hejlsberg came from Borland/Delphi/Pascal to Microsoft to develop C#. The idea was to sunk Delphi, the only real competitor in the RAD arena.
Well, they almost did.
|
|
|
|
|
This is the truth. C# has a lot of Java influence. Sure it borrows from bits and pieces in places from everywhere, but its main influence is from Java. It was created by Java people. This is the truth. If the book says otherwise it's just wrong.
C Sharp (programming language) - Wikipedia[^]
Now, where VB comes into play a lot... the VB IDE. When .NET first came out Dev Studio for C++ and Dev Studio VB were two different apps. Entirely different. What Microsoft did at first was take the IDE for VB and use it as the basis for the .NET IDE and tossed the old C++ one out the door. So, it had a VBish feel and inspection on it with tools like Spy++ had VB all over the place with class names, etc.
This is not to say C# didn't have "some" VB influences, I'm sure it did. But the truth is, most of it's influence is from Java. And the largest VB knock off I've seen with it was with the IDE itself.
My source? About a quarter century of programming stuff.
Oh, and if this was a joke, then I completely missed it. 
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: C# has a lot of Java influence.
Never implied otherwise. But you don't seem to be the only one taking it that way. If you look closely at what the book says, it reads "many of C#’s syntactic constructs" come from VB influence. Not that the entire language does.
Jeremy Falcon wrote: if this was a joke,
No, but I think some of you are hastily reading the message.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
RyanDev wrote: No, but I think some of you are hastily reading the message.
It's how we roll up in this joint.
Jeremy Falcon
|
|
|
|
|
Indeed. 
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
many of C#’s syntactic constructs are modeled after various aspects of Visual Basic (VB) and C++.
"Modeled after" sometimes means "things that were intentionally avoided".
|
|
|
|
|
Could be.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
