#C++ types
16 messages in this thread
Greg,
I notice that the Zortech compiler treats enums as distinct data types
while another 2.0 compiler does not. The other treats them as int
equivalents. With Zortech you can overload an operator by specifying
different enum types just as you can with classes. With the other one you
cannot do that.
Which way is "standard" C++? How does CFRONT 2.0 handle it?
Al Stevens
Enums are distinct types. They are distinct from each other, and distinct
from ints. You can overload functions based on different enum typed
parameters. You can implicitly convert an enumeration constant to an int,
but not vice-versa. The type of an enumeration is the enumeration type.
Order a reference manual from AT&T. $25 well spent. Then see sections 7.2
(enum types) and 13.1 (overloading).
As long as I looked it up, I'll quote: "Each enumeration defines an
integral type that is different from all other integral types. The type of
an enumerator is its enumeration. The value of an enumerator or an object
of an numeration type is converted to an integer nu integral promotion
(see4.1)"
Doest that other compiler have a command line switch? Try -b-, since -b is
"on" by default incorrectly.
–John
For the last time, John, I HAVE THE REFERENCE MANUAL. (Read my caps.) It
was free. The author gave it to me. Please stop answering every question
with "get the reference manual." It sounds patronizing. Besides, my
question was not about what is in the manual. I can read the manual when I
can find what I want in the sparse index. My question was about what CFRONT
2.0 does.
Other than that, thanks for the answer.
Al Stevens
sorry, now I remember a thread dealing with navigational problems in the
DRM.
Just replace my previous detailed message with "RTFM".
Just kidding… I'll remember that you have a manual, and just point you in
the right direction. As for this question in particular, I just looked up
"enumeration" in the index and got
enum
overloading and 75
size of 32
type of 32
enumeration
constant 32
example of 32
Clearly page 32 is where the action is! I read your question not as "what
does Cfront do" (I'll let Greg answer that one) but "what is right"?
–John
I was playing with enum's and cfront 2.0 about 2 months ago and I'm pretty
sure it do' d pretty sure it do'd what the DRM said (except that int
assignments to enum objects gave warnings not errors I expect as a way of
staying compatible with older C programs).
John,
The difference between "what does cfront do" and "what is right" is moot
when you are teaching. Why teach what the RM says if the software doesn't
work that way? New C++ programmers want to know what to expect when they
code and run programs, not what some AT&T manual says. When the X3J16
committee is done with its work (sometime in the 21st century), we'll have
a standard to write about. Until then, it's folklore and prior art.
Al
Which Cfront are you teaching? Your readers will have 2.1, a bug-fix
version, pretty soon. So if you teach the bugs the compiler will not match
any more. I prefer to say what is right, and then discuss various
compiler's beefs with it. Such a feature is to be avoided in general use.
It's only the nitty-gritty details that have such problems. Not much to
worry about for a beginner's book.
–John
In the absence of a standard, there are no bugs, only implementations. The
bugs are in the eyes of the creator, not the user. What the user sees is
how it works. Even with a moving target, you must teach beginners about the
real world. Ivory tower stuff might be OK in a college classroom but not on
the job. When the real world changes, you change what you teach.
>I prefer to say what is right….
Who is to say what is right when there is no standard? Us? That would only
be our presumptuous interpretation of the unsanctioned existing
documentation. Say your idea of "what is right" if you care, but stand back
when the student/reader's code doesn't work.
It is often better to orient a lesson to a targeted implementation and say
so. You eliminate the myriad and complicated qualifications of the
many-compiler, many-version, all-things-to-all-people-at-all-times
approach. I learned that lesson by writing two books that had compile-time
conditionals so the code would compile with every obscure pre-ANSI C
compiler I could get my hands on. The header files were unreadable, there
were too many makefiles, and by the time the books got into print, a lot of
the methods had changed. Some of the compilers had faded into the
baseboard, too. De Smet? Eco-C? Let's C? Wizard C? CI C-86? Some of them
might still be out there, but they aren't contenders. We are fortunate that
C++ hasn't gotten into that kind of mess yet, but it could. Particularly
with class libraries.
Al Stevens
Hmm, if I may interject: Agreed we don't have a standard in the sense of
ANSI C++ yet, however we do have three things at this date: an ANSI C
standard, a reasonable C++ document, and Bjarne Stroustrup (and not
necessarily in that order that puts us in a very very good postition in
terms of why we are fortunate that C++ hasn't gotten into a mess). That's
why I don't think it's folklore and prior art. On the other hand, it ain't
perfect either. WIth that in mind, although most people, myself included,
will use cfront to see how something works, it should really only be used
as a guide as it is only an implementation, albeit a very popular one.
Agreed that with much that's all we have to work with in some lights,
however the RM does rule.
Agreed, when viewed from the perspective of the compiler developer/purveyor
such as yourself, the RM should be the guiding light. But from the
perspective of the working programmer or the teacher of programmers, the
way things work should prevail. You've got to use what's out there.
Bjarne is a commanding influence, but I'll bet you will see his role
diminish when ANSI gets hold of it. Ask Dennis Ritchie. Bjarne will not
have the time to dominate X3J16, and the committee will …, well, you know
committees.
Not sure I'm with that totally. For instance, in the case of C, I always
followed the current guiding light (K&R, then H&S, then the drafts, now the
standard) with secondary attention given to the given implementation I'm
working with. I agree the given implementation must be given valid
concern, but I would only use the given implementation to comment on and
never as law (lots of bad things can happen that way). Differences should
surely be noted.
As to Bjarne and Dennis, you are probably right: Bjarne will not dominate
X3J16. However, Dennis didn't dominate anything and is still alive and
hence one must question lack of influence in his case (except until
recently). X3J16 is starting off much differently than X3J11… is some
ways better and in some ways worse….
The point I'm making is that you have to teach what works if the student is
going to write code that has to run. If what the manual says differs with
how the compiler works, you have to teach the compiler. What choice do you
have? The code has to run. Of course, you should always teach that things
can change.
With C we have an easy road now. Build an exercise that complies with the
standard and make sure it works on two or three conforming compilers.
I don't know what you mean by "lack of influence." Dennis Ritchie says he
kept out of X3J11 because he did not want to commit the time and effort.
That's his official reason. I suspect that privately he also did not want
to get embedded in the inevitable committee dynamics and politics. But he
kept watch. When the committee was about to make a really dumb move, he
stepped in and voiced a strong opinion, which they heeded.
Al Stevens
I guess we're coming from two different worlds. I'm working on defining
the language, and have studied the language long before I could actually
compile it. I see the _bugs_ in the compiler then when I try to use them.
So your book is specific to Zortech 1.06's implementation of C++, or do you
point out things that may be "implementation specific", or what? And how
do you explain overloading? ZTC 1.07 rules, C++ 1.2 rules, ZTC's 2.06
rules (almost got the 1.2 stuff right), C++ 2.0 rules, cfront's
implementaion (2.0 or 2.1?) or "what he meant"? That is a thorny issue.
In my beginner's book I'm teaching 2.0, but am explaining the ideas and
pointing out that fine points are implementation specific, so you have to
avoid doing anything too tricky.
–John
No, my book is not Zortech specific. It is a C programmer's C++ tutorial
and is about C++ 2.0, and avoids anything "tricky" if I can help it. It has
many compilable exercises, some of which do not work with Zortech 2.0,
particularly the chapter on iostreams.
I asked a question about cfront 2.0 behavior because I did not have a
cfront 2.0 to try the thing out with. The code in the book must *compile*
not just appear as fragments of example code such as you see in most other
C++ books. That's how I work. Readers will not find a book credible if they
cannot compile and run the code.
The thread then turned from my original question to the philosophy of what
one should teach to whom and the difference between how something works and
how it is documented. Now it has turned to what my book and your book are
about. Likely we'll soon lose the interest of the other members here. You
may respond to this message and have the last word if you like 8-).
Al Stevens
Yea, ANSI drafts ahve been a wonderful boost to C programmers. My toolbox
compiles under many brands, with only slight hanges in 1 header file.
–John
John's answer is accurate. Note that there was a change from 1.2 to 2.0 in
some of this though so if you've got a cfront 1.2 things may not be
accurate.