🚀 go-pugleaf

In article <49r5vc$pk2@news.aloha.com> jching@aloha.com (Jimen Ching)
writes:

|> 	Since we're on the subject, I have another feature I would like
|> some opinions.  This feature is based on the following premise:

|> 	C++ allows the programmer to deal with user defined types like
|> 	any other types, including internal types.

|> The above is what I understood the advantage of C++ over C.  Now, in C/C++
|> we can do the following:

|> typedef char internal_type;
|> f(internal_type it)
|> 	{
|> 	switch(it)
|> 		{
|> 		case '0' /* or any other constant of internal_type */:
|> 			/* do something here */
|> 			break;
|> 		case /* ... */
|> 		}
|> 	}

|> This is valid for C and C++.  So for the above premise of C++, I should
|> also be able to do the following as well:

|> class internal_type
|> 	{
|> 	friend bool operator==(const internal_type &lhs, const internal_type &rhs)
|> 		{ return lhs.data == rhs.data; }
|> public:
|> 	internal_type(char c = '0') : data(c) {}
|> private:
|> 	char data;
|> 	};

|> internal_type const a('a');
|> internal_type const b('b');
|> internal_type const c('c');

|> f(internal_type &it)
|> 	{
|> 	switch (it)
|> 		{
|> 		case a: /* do something... */ break;
|> 		case b: /* do something... */ break;
|> 		default: /* do something... */ break;
|> 		}
|> 	}

|> If C++ lived up to its promise, why can't I do the above?

For the same reasons, roughly speaking, that you cannot do it in C.
The control expression of a switch must be an integral type, not an
arbitrary type for which == just happens to be defined.  (It doesn't
work with internal_type typedef'ed to a double in C, either.)

True integral types are special, both in C and C++ (and in most other
languages, I think).  They are special because, at a hardware level,
they can be used in address arithmetic.  Thus, they permit *rapid*
indexing into an array.  (You cannot declare an array indexed with
anything but an integral type, either.)  And the permit special
implementations of the switch, which are also significantly more rapid
than just chaining if's.  (And in C/C++, be used in explicit address
arithmetic.)  In this regard, the switch is no more a special case
than are array indexes.

|>  You might
|> wonder where I got this idea.  Well, I was working on a project which
|> needs to model register states, such as logic low, logic high, high
|> impedance and don't care.  So I have a class called 'logic'.  But
|> instead of using a switch for each logic state, I have to use a bunch
|> of 'if', 'else if' statements.  This is not a problem for 4 states, but
|> many digital circuits can test for 'strengths' in logic levels, and 
|> with 'char' type, I can support upto 256 states.  Also, what if I
|> wanted to do the same thing for a special sequence of states, such
|> as 1,5,9,15,77,99.  I would have to test for each one of these.  Not
|> a problem if the sequence is small, but what if it was over 50 values?
|> I understand why C couldn't do this, but why can't C++?

Why are chained if's a problem, and switch not?  I fail to see a
significant difference in the two.  (Note that for all types except
the integral types, the compiler would basically have to generate the
same code.)  Or: why not provide a function in your type to return the
switch control as an int?

An even cleaner possibility might be to have an abstract base class
State, and derive the actual states from it.  The state of an actual
logic point would be represented by a pointer to the actual state
object (probably a singleton), and instead of a switch, each actual
state would provide the necessary virtual functions.  In this case,
your function above would simply be:

	f( internal_type& it )
	{
	    it.state()->doIt() ;
	}

(I wonder if you even need a special function for this.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]