Visual C++.Net - Alternative to Large Switch Case

[JSadleir]

Hi All I know little about Visual C++.net programming and would be grateful for any insights into solving the following problem. For one function, ideally I would like a Switch Case that has 10000 case entries as follows: Switch (Product_Case) { Case 1 : Price = 1.07; break; Case 2 : Price = 1.07; break; ... Default Case } Using a Switch case in this way would achieve my aim of being able to get a price corresponding to a product, but presumably a 10000 case switch would cause memory problems and and be slow. How would an experienced programmer handle this? Would they create an .mdb with the Product and corresponding Price entries and then read from that file using pointers and SQL? As I want this data embedded in an .XLL, what type of header/source/resource do I use in Visual C++.net? Any ideas would be gratefully accepted. Jeremy

[User 307386]

I would just do binary or plaintext file, put in resource, when needed load to memory and do something like Price=MemArray[index]. Igor Green http://www.grigsoft.com/ Compare It! + Synchronize It! - files and folders comparison never was easier!

[Mike Dimmick]

I don't think it would be particularly slow, actually, but the code would be really large. The compiler is likely to build a jump table rather than a sequence of if/else tests. As to how to implement it, it depends whether the data will change over time, and if so, whether you want to allow an administrator to make the changes (in which case some form of external file access is in order). If you think the data is fixed for all time, or if a recompile is acceptable to change the values, I'd create a lookup table. Since it's 10000 values I'd probably write a program to generate the C++ file containing the lookup table! Obviously if you do this it's harder to change values, but on the other hand you won't need to write file handling and validation code, nor have to handle situations where the file is not present or inaccessible. If you decide to go the external data route, I'd go with a file that fits in with the existing data access and the expected skill of the administrator. If data already comes from a SQL or Jet database, I'd place it there. If it's a flat file, I'd add this as an extra flat file, and so on. Finally, if the quantity can be computed from some equation, I'd just do the computation rather than the lookup. A few years ago I might have cached the values of computations, or used lookup tables. Now processors are so much faster than RAM that computing most quantities is often quicker than retrieving a precomputed value. Obviously you need to measure this with a profiling tool. Stability. What an interesting concept. -- Chris Maunder

[Ravi Bhavnani]

I recommend using a Product_Case to Price map. /ravi My new year's resolution: 2048 x 1536 Home | Articles | Freeware | Music ravib@ravib.com

[Blake Miller]

You still have to get the valuess INTO the map, so how does that provide any gains over the switch statement? Especially if the switch compiles into a jump table and not a series of if/else if type statements. However, I would accept that a MAP might be the way to go if reading of an external data source is implemented.

[Ravi Bhavnani]

Blake Miller wrote: You still have to get the valuess INTO the map, so how does that provide any gains over the switch statement? The gains are in the area of maintenance, not necessarily performance.

1. For large switch statements a map lookup is easier to understand and therefore easier to maintain.
2. A map lookup is more robust (i.e. less error-prone, dure to factoring) if the switch is needed more than once.
3. As you have already pointed out, a map allows run-time initialization and is therefore more flexible.

/ravi My new year's resolution: 2048 x 1536 Home | Articles | Freeware | Music ravib@ravib.com