In article <3vq3b6$2l5@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) writes
& ....
& But I do not decide the standards committee's orientation in this
& regard.  All I can say is that by accepting ++ for bool, the C++
& standard is following in the footsteps of C....

If we are stuck with 'bool' in C (not C++), then I want "bool++" and
"bool--" even though, as it has been pointed out, when the code is open
to "setjmp" or other interrupting it is unsafe.

Richard A. O'Keefe (ok@goanna.cs.rmit.edu.au) wrote:
|> I wrote:
|> |> Let INT_MAX be 32767  (taken from a real limits.h file)
|> |> Let ARG_MAX be 1048320  (taken from a real limits.h file)
|> |> Do you see the problem here?  Increment your "boolean" often enough and
|> |> SIGFPE from an integer overflow is a real possibility, and
|> |> incrementing all the way back to 0 IS A REAL POSSIBILITY.

|> kanze@gabi-soft.fr (J. Kanze) writes:
|> >Except that in C++, boolean++ is defined as `boolean = true', not as
|> >incrementation.

|> You missed the point.  People keep on claiming that bool++ is going to be
|> allowed in order to support existing code.  _My_ point is simply that the
|> code in question has never been correct, has always been a breeding ground
|> of bugs just waiting for a chance to bite.

I, and I think many others, agree with you.

However, all (C) code which uses gets is also broken.  This didn't stop
the C standards committee from adapting `gets' as a standard function.
There is just too much code that uses it.  The fact that this code is
broken doesn't stop people from using it every day, and there is a large
faction which would scream loudly if it didn't compile anymore, because
the standard forbid it.

My own personal opinion would be for the standard to do the right thing,
and let the implementors (and quality of implementation issues) decide
how far they want to go with regards to backward compatibility.  I
definitly do not like having a function like gets in the standard; it
seems to me that this is explicit approval by the standards committee
for using it.

But I do not decide the standards committee's orientation in this
regard.  All I can say is that by accepting ++ for bool, the C++
standard is following in the footsteps of C.  More generally, my
opinions notwithstanding, this seems to be what the majority of people
want:-(.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

I wrote:
|> Let INT_MAX be 32767  (taken from a real limits.h file)
|> Let ARG_MAX be 1048320  (taken from a real limits.h file)
|> Do you see the problem here?  Increment your "boolean" often enough and
|> SIGFPE from an integer overflow is a real possibility, and
|> incrementing all the way back to 0 IS A REAL POSSIBILITY.

kanze@gabi-soft.fr (J. Kanze) writes:
>Except that in C++, boolean++ is defined as `boolean = true', not as
>incrementation.

You missed the point.  People keep on claiming that bool++ is going to be
allowed in order to support existing code.  _My_ point is simply that the
code in question has never been correct, has always been a breeding ground
of bugs just waiting for a chance to bite.

>Similarly, Bjarne Stroustrup proposed deprecating value `narrowing'
>implicit casts (int -> char, double -> float, etc.).  I withdrew the
>proposal when he found an overwhelming majority of the committee against
>him.

My opinion of C++ has never been high, and looking at the current draft
standard has been a _very_ depressing experience.  However, I have a lot
of respect for Bjarne Stroustrup, and this attempt of his to genuinely
help people fix broken code merely confirms me in that opinion.

--
"conventional orthography is ... a near optimal system for the
 lexical representation of English words." Chomsky & Halle, S.P.E.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

pete@borland.com (Pete Becker) writes:
>The reason for this was to make conversion of existing applications easy.
>One example is a command-line parser, which increments the p-counter every
>time it encounters -p on the command line. Since the only issue after the
>parsing has been done is 0 vs. non-0, it sure looks like a boolean value.

Let INT_MAX be 32767  (taken from a real limits.h file)
Let ARG_MAX be 1048320  (taken from a real limits.h file)

Do you see the problem here?  Increment your "boolean" often enough and
SIGFPE from an integer overflow is a real possibility, and
incrementing all the way back to 0 IS A REAL POSSIBILITY.

I still remember the day things went wrong for me because the counter I
was using to tell me if there were errors incremented back up to 0.
Never again!  C programmers who do this should be re-trained, not pandered to.
--
"conventional orthography is ... a near optimal system for the
 lexical representation of English words." Chomsky & Halle, S.P.E.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

If there shall be a new C-type 'bool' (I hope not!), then there is nothing
wrong with this,
 bool b, c, d;
 ...
 d = b++;
 ...
 d = c--;
if "++" means that "d" gets "b" s former valu, and therafter "b" is made 1
("true"), and "--" means that "d" gets "c" s former valu and therafter "c"
is made 0 ("false"), even if it is based on a bad habit.

In article <3v7080$48n@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes
> "conventional orthography is ... a near optimal system for the
>  lexical representation of English words." Chomsky & Halle, S.P.E.
I guess that thei mean this in the sens that if all English words
are listed in order of frequensie, commonest first, and the first is
numberd "A", and the second "B", ... the twentiesevventh "AA", 28th
"AB", ... that is *the* optimal system.

In article <3v7080$48n@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) says:
>
>pete@borland.com (Pete Becker) writes:
>>The reason for this was to make conversion of existing applications easy.
>>One example is a command-line parser, which increments the p-counter every
>>time it encounters -p on the command line. Since the only issue after the
>>parsing has been done is 0 vs. non-0, it sure looks like a boolean value.
>
>Let INT_MAX be 32767            (taken from a real limits.h file)
>Let ARG_MAX be 1048320          (taken from a real limits.h file)
>
>Do you see the problem here?  Increment your "boolean" often enough and
>SIGFPE from an integer overflow is a real possibility, and
>incrementing all the way back to 0 IS A REAL POSSIBILITY.

Yes, the problem is obvious. The writer of the original C code made an
assumption that may not be valid. Funny thing, in C++ it also may not
be valid. The code will probably work as well when compiled as C++ as it
did when compiled as C.
 -- Pete

Richard A. O'Keefe (ok@goanna.cs.rmit.edu.au) wrote:
|> pete@borland.com (Pete Becker) writes:
|> >The reason for this was to make conversion of existing applications easy.
|> >One example is a command-line parser, which increments the p-counter every
|> >time it encounters -p on the command line. Since the only issue after the
|> >parsing has been done is 0 vs. non-0, it sure looks like a boolean value.

|> Let INT_MAX be 32767  (taken from a real limits.h file)
|> Let ARG_MAX be 1048320  (taken from a real limits.h file)

|> Do you see the problem here?  Increment your "boolean" often enough and
|> SIGFPE from an integer overflow is a real possibility, and
|> incrementing all the way back to 0 IS A REAL POSSIBILITY.

Except that in C++, boolean++ is defined as `boolean = true', not as
incrementation.

|> I still remember the day things went wrong for me because the counter I
|> was using to tell me if there were errors incremented back up to 0.
|> Never again!  C programmers who do this should be re-trained, not pandered to.

I agree, but then we wouldn't have C, we'd have some other language:-).
I was very disappointed when the deprecation of the implicit
conversions concerning bool was removed from the proposal in the C++
committee.  But the proposal wouldn't have passed with the deprecation.
Similarly, Bjarne Stroustrup proposed deprecating value `narrowing'
implicit casts (int -> char, double -> float, etc.).  I withdrew the
proposal when he found an overwhelming majority of the committee against
him.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

> In article <3tusmn$mk@rover.village.org>, Warner Losh <imp@village.org> wrote:
>
> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
> >big pain in the butt due the all the restrictions in their use that
> >have recently been added to them (relative to a liberal reading of the
> >ARM).

These restrictions were not intended as the last word, but rather as
the most which the committee could agree upon at the time.

At the most recent standards meeting one of the work groups voted
unamimously to reopen this issue and recommended a return to the semantics
as specified in the ARM.  A formal vote will be taken in November.

The work group also voted to make casts of pointers to members across
virtual inheritance ill-formed, on the grounds that there is little or
no existing practice (since most compilers don't implement it anyway)
and it has surprising ramifications for the size of pointers to members
and the cost (in code space and speed) of pointer to member casts.

--
Bill Gibbons
bgibbons@taligent.com

In article <KANZE.95Jul19113619@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
> The traditional C cast is in
> fact overloaded: cast a double to int, and you get a conversion
> (static_cast in the new C++ cast syntax).  On the other hand, in
> traditional C, casting a pointer would not change the bit pattern, but
> was simple type punning (reinterpret_cast in the new C++ cast syntax).

This is a common misconception, but it's just plain wrong.  *All* C
casts cause a conversion (except when you're casting to the same type).
Just because there are some occasions where the two types have the same
representation, that doesn't mean that no conversion has occurred.  For
example, on a machine where int and long have the same representation,
casting an int to long doesn't change the bit pattern, but it does
change the type.  Similarly, casting an int * to a char * where all
pointers have the same representation doesn't change the bit pattern,
but the type changes.  There's still a conversion, it just doesn't
require any code.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
He's just jealous because I accomplish so much more than he does. -- Calvin

In article <3tusmn$mk@rover.village.org>, Warner Losh <imp@village.org> wrote:
>In article <DBK0I1.Fon@crdnns.crd.ge.com>,
>Christopher R. Volpe <volpe@ausable.crd.ge.com> wrote:
>>I don't think this is an appropriate analogy. Offsetof is just as useful for
>>C++ as it is for C.

 Only because C++ messed up the model of pointers to members
badly. IMHO.

>However, C++'s does have pointers to member DATA.  They are quite
>useful and make things more typesafe if you want to initialize
>elements of a class from a data table.  That sounds like a replacement
>to me.

 They are NOT a replacement at present. The C++ ptm
system is functionally incomplete and provided invalid facilities.
See below.

>C++ also has pointers to member FUNCTIONS which are, quite frankly, a
>big pain in the butt due the all the restrictions in their use that
>have recently been added to them (relative to a liberal reading of the
>ARM).

 I voted IN FAVOUR of those restrictions. I object
to the hijacking of pointers to members to provide
dynamic binding facilities which ought to have been provided
by a mechanism designed for that.

 My model of ptms is "A ptm is a typed offset".
 NEITHER the ARM or WG21 model implements that.

 You can regard the restrictions as damage control --
restricting the semantics to that which enables any one of the
several ptm models as an extension.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3uofeb$er0_003@news.dnai.com> vbazarov@imsisoft.com
(Victor Bazarov) writes:

|> In article <KANZE.95Jul20104341@slsvhdt.lts.sel.alcatel.de>,
|>    kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
|> >If C is to adapt a bool type, I see two alternatives:
|> >
|> >1. Adapt the C++ bool type, with eventual deprecation of the implicit
|> >type conversions.

|> What is "C++ bool type"? I missed it somehow...

A boolean type.  The results of the comparison operators, and
operators `&&' and `||'.  The type used by `if', `while' and `do
... while'.

In C, only the latter is a boolean type, although since you cannot
write an expression of boolean type, you have to depend on implicit
conversions to get it.

|> >2. Create a real bool type, with no legal type conversions, implicit
|> >or otherwise.

|> Once it was a perfect language -- called "C". Someone has come and added type
|> called "bool". Language lost it's perfection. Just like that!

If you consider C perfect, then I suspect that you hold it in higher
estime than its authors.

|> The less types, the better!

|> Long live AWK! :-)

I love AWK myself, but...  I only put up with its lack of a boolean
type because it only has one type (and thus, no declarations, etc.).
This is not the case with C.

The languages are both generally adequate (AWK is actually superb),
but they address different problems.
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <3uu4c8$o5l@info1.sdrc.com> larry.jones@sdrc.com writes:

|> In article <KANZE.95Jul19113619@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> > The traditional C cast is in
|> > fact overloaded: cast a double to int, and you get a conversion
|> > (static_cast in the new C++ cast syntax).  On the other hand, in
|> > traditional C, casting a pointer would not change the bit pattern, but
|> > was simple type punning (reinterpret_cast in the new C++ cast syntax).

|> This is a common misconception, but it's just plain wrong.  *All* C
|> casts cause a conversion (except when you're casting to the same type).
|> Just because there are some occasions where the two types have the same
|> representation, that doesn't mean that no conversion has occurred.  For
|> example, on a machine where int and long have the same representation,
|> casting an int to long doesn't change the bit pattern, but it does
|> change the type.  Similarly, casting an int * to a char * where all
|> pointers have the same representation doesn't change the bit pattern,
|> but the type changes.  There's still a conversion, it just doesn't
|> require any code.

This is why I said `traditional' C, instead of simply C or standard C.
Most people have traditionally (albeit incorrectly) considered pointer
casts in C to be simple type punning, and not conversion.  (Even
considering the cast to be type punning on the type pointed too is not
strictly correct; the result of casting a char* to an int* may not
point to the same physical byte.)

I'm still looking for a good, short way of explaining the difference
between static_cast and reinterpret_cast (to use the C++ syntax) when
applied to a pointer.  (Add inheritance to C, and it will potentially
have the same problem.)
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <KANZE.95Jul20104341@slsvhdt.lts.sel.alcatel.de>,
   kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
>If C is to adapt a bool type, I see two alternatives:
>
>1. Adapt the C++ bool type, with eventual deprecation of the implicit
>type conversions.

What is "C++ bool type"? I missed it somehow...

>
>2. Create a real bool type, with no legal type conversions, implicit
>or otherwise.

Once it was a perfect language -- called "C". Someone has come and added type
called "bool". Language lost it's perfection. Just like that!

The less types, the better!

Long live AWK! :-)

Victor.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If it's stupid, but works, it isn't stupid.
                                            Murphy
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

In <KANZE.95Jul20104341@slsvhdt.lts.sel.alcatel.de>, James Kanze
          US/ESC 60/3/141 #40763 (kanze@lts.sel.alcatel.de) wrote

[snip]

: 2. In a real sense, `++' is not a valid operator for a bool type.  It
: is a `tolerated' operator, for reasons of compatibility with old code.
: (I know that the standard doesn't have this type of distinction, but I
: think it helps put the actual situation in perspective.)

[snip]

(Others have made similar comments,)

I don't understand this at all.  At present there is no boolean type
in C, so how can there be any issue of compatibility with old code?
Of course there is lots of code that simulates a boolean type using
existing C facilities, but that code has to be changed regardless if
it is to be used with any new type.  There are all sorts of problems
doing this, but why pick on the "++" operator as one the standard
should worry about, and ignore all the others (e.g. the problems
that will result whenever a new keyword is introduced)?

IMHO, if a boolean type is introduced into C, it should be done in a
way that makes most sense in its own right.  (e.g. NO ++/-- operators,
as far as I'm concerned.)  Any existing code that doesn't like this
new type as defined doesn't have to use it - the worst result is that
the name of it's boolean type has to be changed to avoid conflict with
the new keyword (and that will be obvious in most cases, such as in a
typedef statement, will cause compile errors.)

Anyhow, my point, I don't understand how compatibility with old code
is an issue when discussing an entirely new feature.

--
Peter Curran                                        pcurran@isgtec.com
ISG Technologies, Inc                              (905) 672-2100 X315
6509 Airport Road,        http://www.isgtec.com     Fax (905) 672-2307
Mississauga, Ontario, Canada                   Usual disclaimers apply

In article <KANZE.95Jul20104341@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
> 1. 0 and 1 are *not* legal values for a bool type.  The only legal
> values are true and false.  When cast to an int (implicitly or
> explicitly), false must yield 0 and true 1, and I suspect that most
> implementations will in fact use 0 an 1 to implement bool at the
> hardware level (but this is not required).

Wouldn't `b = 1' be implicitly `b = (bool) 1' and thus `b = true'?
Or are casts from int to bool undefined, despite the asymmetry?

> If C is to adapt a bool type, I see two alternatives:
>
> 1. Adapt the C++ bool type, with eventual deprecation of the implicit
> type conversions.
>
> 2. Create a real bool type, with no legal type conversions, implicit
> or otherwise.
>
> From the point of view of language theory and elegance, there is no
> doubt that 2 would be the better solution.  From a practical point of
> view, adapt 2 and you no longer have C.  (It is hard to imagine an
> existing C program which wouldn't break.)

I assume that by `break' you mean `not be able to use the new boolean
type just as they used to use integers'.  I don't see this as a flaw;
if the boolean type is just a plug-in replacement for int, it has no
advantages over int.  And existing code with `bool' typedefs wouldn't
break if another name is used, say `logical' or `tf'.

Someone else said "the fewer types, the better".  I think the real wish
is for *simplicity* in the type structure.  A clean boolean type would
avoid reinventing int.
--
Shields.

In article <3uhj3n$dn9@rover.village.org> imp@village.org (Warner
Losh) writes:

|> In article <KANZE.95Jul18160836@slsvhdt.lts.sel.alcatel.de>,
|> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
|> >|> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
|> >|> >big pain in the butt due the all the restrictions in their use that
|> >|> >have recently been added to them (relative to a liberal reading of the
|> >|> >ARM).
|> >|> Such as? (Just curious)

|> >I suspect that the original poster was referring to various
|> >restrictions concerning casting of member pointers.  Basically, the
|> >ARM allowed casting from one class to another, *but* it did not define
|> >the semantics of such a cast.  In practice, the compilers I had access
|> >to either did not allow the cast, or gave it reinterpret_cast syntax,
|> >which basically made it useless, so I don't know why the poster
|> >actually complaining.  (Of course, without multiple inheritance,
|> >reinterpret_cast and static_cast, which might have been useful,
|> >actually generate the same code for most implementations.  So if you
|> >like to count on such chances...)

|> Excuse me, but I'm the original poster.  And most compilers allowed
|> it.  At least *ALL* of the compilers that I threw the OI library
|> against in the five years that I was working on it.  These included
|> cfront, HP's compiler, DEC's cxx, IBM's xlC, GNU g++, a couple of
|> different Microsoft compilers and one or two others that have slipped
|> my mind (Lucid and Centerline maybe).

My experience is more limited, but g++ was the precise example of a
compiler which allowed it, but gave it useless semantics (those of
reinterpret_cast).

Since this is in comp.std.c, perhaps I should explain the
reinterpret_cast/static_cast business.  The traditional C cast is in
fact overloaded: cast a double to int, and you get a conversion
(static_cast in the new C++ cast syntax).  On the other hand, in
traditional C, casting a pointer would not change the bit pattern, but
was simple type punning (reinterpret_cast in the new C++ cast syntax).
When I refer to *_cast semantics, I am simply using a short-hand to
specify the semantics of the (C-style) cast: does it do an actual
conversion, or is it simply type-punning.

In C++, pointer casts within an inheritance hierarchy are
reinterpret_cast's, not static_casts.  In particular, casting a
pointer to a derived class into a pointer to a base class will *not*
necessarily result in a pointer to the same physical bytes.

Similarly, the offset of an element relative to the base class may be
different from the offset of the same element relative to the derived
class.  Thus, casting a `pointer to member' should be a static_cast.
The actual layout used by g++ (and most other compilers) make this
distinction unimportant in the case of single derivation, but it is
never the less there.

|> These casts were years before all the *_cast that are now in draft
|> versions of the standard.  Member function pointers were quite useful
|> if you steered clear of MI, especially virtual base classes, but were
|> otherwise quite "robust", given that virtual functions had to work.

I agree, and would probably have preferred allowing them (and defining
the old cast syntax to have static_cast semantics).  My contention is
simply that this was *not* existing practice; the compilers that
allowed them (most, I admit) implemented reinterpret_cast semantics.

You mention yourself the necessity of steering clear of MI; on all
implementations I am familiar with, there is no difference between a
static_cast and a reinterpret_cast except when MI is used, so I can
understand your statement that `they work'.  On the other hand, I find
MI far more useful than pointers to members; in practice, the implemented
semantics of pointer to member casts made them useless as far as I was
concerned.  (How can I be sure that my class will never participate in
multple inheritance.)
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

> deprecation really
> only means that the standards organization thinks that the feature is
> a bad thing, and is encouraging compiler writers to generate warnings.
                      ^^^^^^^^^^^

Could a C/C++ standard _require_ that a conforming compiler must
diagnose deprecated features?  (And that the program would still be
compiled after the diagnostics.)
         ++sja

In article <3tv3gv$bhc@yage.tembel.org>, shields@tembel.org (Michael Shields) writes
>It depends on the semantics you want.  Personally, I'd like to say that
>bool can only be 0 or 1, so that `foo--' will always set it false, and

In article <DBpJAL.Lus@crdnns.crd.ge.com>, volpe@bart.crd.ge.com (Christopher R. Volpe) writes
> If the bool type can be only zero or one, I'm not sure I'd want "--" to be a
> valid operator for the type.

And I, if it is thus limited, want "--" and "++" to be the same,
and make 0 1 and 0 1

In article <3ubhk3$mu8@cnn.Princeton.EDU>, tim@handel.Princeton.EDU (Tim Hollebeek) writes
> It shouldn't be strictly possible to 'add' booleans, etc.  add is an operation
> on integral types, not booleans.  However, one can obviously do it
> through a conversion to (int), so true + true == 2, and (bool)5 +
> (bool)12 == 2.

Nothing wrong with adding them: 0 = 0 + 0 = 1 + 1 --- 1 = 1 + 0 = 0 + 1 .
Quite all right.  Note that this is equivalent to "not equal".

The trouble with the traditional logical operations is that thei are not
operations in the programming sens.  Thei are static formulations of eternal
truths.  It is better to take for a model the operations that electronic
engineers uze.

By the wai, I nevver liked, and nevver uzed, "++" for setting; instead
alwais " = 1 ".  It is not enough for me that "++" is implemented with a
simple operation on the PDP-11.  I suspect that this was the chief grounds
for this bad hack.

In article 95Jul19182448@gamma.hut.fi, sja@gamma.hut.fi (Sakari Jalovaara) writes:
>> deprecation really
>> only means that the standards organization thinks that the feature is
>> a bad thing, and is encouraging compiler writers to generate warnings.
>                      ^^^^^^^^^^^

Deprecation really means that the feature might become invalid in the
next version of the standard, and programmers are warned not to use
the features in code intended to be used for a while.

>Could a C/C++ standard _require_ that a conforming compiler must
>diagnose deprecated features?  (And that the program would still be
>compiled after the diagnostics.)

It _could_, but it probably won't. Ill-formed programs require a diagnostic.
Programs using deprecated features are not necessarily ill-formed.

The standard would then be in the position of requiring a diagnostic for
some categories of well-formed programs. That in turn means that the
standard ought to require two kinds of diagnostic messages. That is
the nose of a rather smelly camel poking into the tent, and so far the
C++ Committee has declined to invite it in.

You can lobby your favorite compiler vendors to provide warnings of the
sort you want. Most implementors are happy to satisfy reasonable requests,
and a warning about a deprecated feature sounds reasonable to me.
---
Steve Clamage, stephen.clamage@eng.sun.com

In article <SJA.95Jul19182448@gamma.hut.fi> sja@gamma.hut.fi (Sakari
Jalovaara) writes:

|> > deprecation really
|> > only means that the standards organization thinks that the feature is
|> > a bad thing, and is encouraging compiler writers to generate warnings.
|>                       ^^^^^^^^^^^

|> Could a C/C++ standard _require_ that a conforming compiler must
|> diagnose deprecated features?  (And that the program would still be
|> compiled after the diagnostics.)

I suppose that a standard could mandate just about anything that the
standardization committee wanted:-).  In practice, this has always
been treated as a quality of implementation issue.

I suspect that this is correct.  Basically, the current standards
divide programs into three large categories (for a given
implementation):

1. Those which are correct.  The implementation must compile and run
them correctly (within the bounds of the implementations resource
limits).  Note that even for these programs, the implementation is
allowed to generate diagnostic messages.

2. Those which have an error requiring a diagnostic.  The
implementation must generate an error message.  It may or may not
compile them, allow them to run, or anything else.

3. Those with undefined behavior.  No further comment necessary.

Since the quality of the diagnostic messages is not mandated, and a
diagnostic is only required for the first error, a compiler which
*always* outputs the string "?" and always generates some program is,
strictly speaking, conforming.

Requiring warnings would, basically, introduce an additional category
between 1 and 2.  But since in fact, a compiler is free to treat cases
1 and 2 exactly the same today, I don't think it is worth the effort.
(In practice, most compilers *do* try and distinguish between
diagnostics generated in case 1 and those in case 2, and most not
generate executable code in case 2.  But the same market forces that
impose this will effectively mandate warnings for deprecated behavior,
without any additional requirements in the standard.  I hope.)
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <KANZE.95Jul20104341@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes
> Just to clarify a little:
>
> 1. 0 and 1 are *not* legal values for a bool type.  The only legal
> values are true and false.  When cast to an int (implicitly or
> explicitly), false must yield 0 and true 1, and I suspect that most
> implementations will in fact use 0 an 1 to implement bool at the
> hardware level (but this is not required).
This behavior is not appropriat for C.  Indeed, "true" and "false" are gilded
lilie for C.  One who wants them can doo this:
 enum { false = 0, true = 1 };

> 2. In a real sense, `++' is not a valid operator for a bool type....

One is free to make it mean anithing that one wants it to mean, and there
is nothing wrong with the meaning that ++ makes a 'bool' 1 and -- makes
it fals.  From the practical point of programming this is an extreemlie
useful operation.  Restricting the operators to the ones found in logic
greatlie lessens the type s usefulness.  The mathematical viewpoint
and the programming-viewpoint of two-state variables barelie overlap.
Mathematical logic deals with truth (and therefore more states than
twain are alloud in modern logic) and programming deals with state.

In article <3uk2p4$lg@caip.rutgers.edu> halasz@caip.rutgers.edu
writes:

|> In article <3tv3gv$bhc@yage.tembel.org>, shields@tembel.org (Michael Shields) writes
|> >It depends on the semantics you want.  Personally, I'd like to say that
|> >bool can only be 0 or 1, so that `foo--' will always set it false, and

|> In article <DBpJAL.Lus@crdnns.crd.ge.com>, volpe@bart.crd.ge.com (Christopher R. Volpe) writes
|> > If the bool type can be only zero or one, I'm not sure I'd want "--" to be a
|> > valid operator for the type.

|> And I, if it is thus limited, want "--" and "++" to be the same,
|> and make 0 1 and 0 1

Just to clarify a little:

1. 0 and 1 are *not* legal values for a bool type.  The only legal
values are true and false.  When cast to an int (implicitly or
explicitly), false must yield 0 and true 1, and I suspect that most
implementations will in fact use 0 an 1 to implement bool at the
hardware level (but this is not required).

2. In a real sense, `++' is not a valid operator for a bool type.  It
is a `tolerated' operator, for reasons of compatibility with old code.
(I know that the standard doesn't have this type of distinction, but I
think it helps put the actual situation in perspective.)

If C is to adapt a bool type, I see two alternatives:

1. Adapt the C++ bool type, with eventual deprecation of the implicit
type conversions.

2. Create a real bool type, with no legal type conversions, implicit
or otherwise.

In article <3ujhe9$gsl@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM
(Steve Clamage) writes:

    [The following quote is actually from me...]
|> >> deprecation really
|> >> only means that the standards organization thinks that the feature is
|> >> a bad thing, and is encouraging compiler writers to generate warnings.
|> >                      ^^^^^^^^^^^

|> Deprecation really means that the feature might become invalid in the
|> next version of the standard, and programmers are warned not to use
|> the features in code intended to be used for a while.

Deprecation *theoretically* means that the feature might become
invalid in the next version of the standard.

What is the status of arithmetic if (deprecated in 1966, if I'm not
mistaken) in Fortran 90?

In practice, deprecated features *don't* get removed from later
versions of the standard (counter-examples, anyone?).  Which was the
point of my original comment quoted above.

(And of course, in theory at least, the next version of the standard
could also remove features that weren't deprecated.  It won't, of
course.  Or...  There seems a non-negligible chance that the next
version of the C standard will remove the "feature" of allowing a user
symbol to be named `bool'.  This feature was not deprecated in the
current C standard.  So maybe the practical rule is that only
deprecated features are guaranteed to remain in the next version of
the standard:-).)
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <3ud0ie$g5u@myntti.helsinki.fi>, wirzeniu@cc.Helsinki.FI (Lars Wirzenius) writes:
|>
|> Personally, I see no point in using "p++" instead of "p = 1" or "p = YES"
|> (or "p = TRUE", for those who prefer that spelling), even in C.

This is *not* equivalent, as the following shows:

 bool p = FALSE;
 if(p++)
  print("executed once");

versus:

 bool p = FALSE;
 if(p = true)
  print("never, ever executed");


It is *this* idiom that is broken by not having ++ defined for bool.
I can think of no other way of doing this that does not involve one more
statement.
|>
|> There are likely to be other places that might need to be changed if
|> the type of p is changed.  I can't imagine that it would be very costly
|> to have to change "p++".

Well, having to add curly braces and an embedded "p = true" to replace
the simple post-increment in the above example is, at least, tedious.

--
swf@elsegundoca.attgis.com  sarima@netcom.com

The peace of God be with you.

Lars Wirzenius (wirzeniu@cc.Helsinki.FI) wrote:
: Personally, I see no point in using "p++" instead of "p = 1" or "p = YES"
: (or "p = TRUE", for those who prefer that spelling), even in C.  "p++"
: is not intuitive, and gives a creepy feeling that something is going
: to break if p grows too large.[1]  Creepy feelings are something to
: avoid when coding.

I agree

: Making a boolean type work with ++ (but not with --) is not going to
: buy all that much.  If the old code is something like this:

:  int p = 0;

:  if (some_condition)
:   ++p;

: then, if someone changes p to be a boolean, the compiler could easily
: diagnose every instance of ++ used with p.  That would make it easier
: to fix the program.

: There are likely to be other places that might need to be changed if
: the type of p is changed.  I can't imagine that it would be very costly
: to have to change "p++".

If you want to add extra boolean functionality for this case, then add
something realy useful ie ||= and &&= then the above code can be
written:

   p ||= some_condition;

: > If you want to set a bool to be true, use bool = true.  If you want to
: > flip it, use bool = ~bool or bool ^= true (granted, that second one
: > looks a bit counterintuitive, but it's sound from a mathematical standpoint).

: I'd prefer these:

:  bool = true; // set it
:  bool = false; // clear it
:  bool = !bool; // flip it

I agree, though I would also support (adding ^^ and ^^= to the language)

        bool ^^= true;  /* to flip it */

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom

In article <DBCJ12.5s4@akropolis.malmo.trab.se> dag@net.dynasim.se
(Dag Bruck) writes:

|> In article <...>, Shankar Unni <shankar@engr.sgi.com> wrote:
|> >
|> >I'm torn on the "bool" data type (nah... - it can be done trivially with a
|> >header file).

|> It's worth pointing out that this is a significant difference between C and
|> C++; in C a simple typedef will do fine:

|>  typedef int bool;

Not really.  Ideally, conditional expressions (in `if', `while', etc.)
would require a bool type, and the compiler would generate an error if
any other type were provided.

Practically, of course, this would break so many C programs that it
has absolutely no chance of being adapted.  With the exception of
function overloading (which Dag mentions below), the `bool' type as
defined in C++ doesn't really buy much more than the typedef (except
that compilers could generate warnings about dangerous conversions).

|> in C++ this is not good enough, because that will not allow us to overload
|> a function on both int and bool.

|> I think C should make bool a pre-defined typedef (i.e., no header file),
|> otherwise C++ should have a corresponding empty header file.

I think that C should do it correctly.  Just take the original
proposal (which Dag co-authored with Andy Koenig), and adapt it
completely (with the type conversions *deprecated*).
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <DBv64J.3r8@research.att.com>, ark@research.att.com says...
>
>In article <3u1113$pjs@fido.asd.sgi.com> shankar@engr.sgi.com writes:
>
>> I guess the intent was that implementations can quietly implement bool as
>> "unsigned char" and do nothing else, but that's clearly silly, since they
>> would still have to guard against 256 ++'s in a row.
>
>The intent is to allow programmers who use int values as booleans
>and set them to true by applying ++ to them to change them to type bool
>without changing alll the places they're used.
>
>Wise or not, the practice of using ++ to make a variable "true"
>is widespread.
>--
>                                --Andrew Koenig
>                                  ark@research.att.com
@@@@@@@@@@@

I guess this means that C++ is not just an incremental step past C...

 ...it could mean..."The *true* C"...or making C true...

I guess that C++ is "The right choice" after all...:)

@@@@@@@@@@@

For anyone that has followed C++ from day one, clearly everyone knows that
the designers and developers had a very tough job. C was (or is) a classic
and to add OO extensions to any language is a very difficult task. As I
have mentioned, this is like combining chess and checkers on the same
board and trying to explain the rules.

When C++ was started in the late 70's and early 80's, things were different.
We did not have low-cost 64 bit processors operating at over 100 MHz on
32 Meg memories. C++ was designed (or C was extended) with efficiency in
mind and assumed that all knowledge of the software engineering process
would be thrown away in the execution environment. Static was selected over
dynamic and C++ software is now brittle and difficult to reuse.

Things have now changed. It is now possible for a 747 to carry an on-board
computer that continues to be part of the software engineering environment.
Does this mean that 747 software is not tested, of course not, it simply
means that software engineers can now get feed-back from their creations
and this feed-back can be used to improve the software. (In theory, you
could probably imagine fixing a critical bug and updating it in flight,
but that level of theatrics is probably best left for the Space Shuttle
and telephone switches.

As more and more people discover the beauty, and classic lines of C, they
begin to see (no pun intended) that C++ provides a path to object-oriented
programming. Unfortunately, the path leads to a difficult approach and
the classic lines of C are lost. As mentioned above, they find themselves
playing checkers and chess on the same board, and they easily end up with
a mess.

Others (like the C+@ developers and Java developers see http://java.sun.com)
have taken a different path. They have taken the classic game of checkers
(which is like C) and have designed a new game like chess. The boards are
kept separate and very well-defined rules have been written to allow the
classic world of C to inter-work with the world of C+@ (or Java).

C is like checkers...it is now (in comparison) to C++ easy to learn...
C+@ is like chess...it offers new challenges, greater power, and some
 checker players can step up to these challenges...
 ...also, some people can learn C+@ directly, without knowing
 anything about C (or checkers)...

I know...I know...you have only one 8x8 board and your company (or school)
has said all of the pieces must be placed on one board...this is unfortunate
but is a marketing reality that exists...if you are in this situation, I
recommend that the best thing you can do is continue to play checkers (C) on
part of the board and try to play a limited game of chess (C++) on another
part of the board...if possiblem, try not to mix the pieces and the
paradigms...someday, your company may be able to add another board...it
makes both checkers and chess, much more fun...programming should be fun...

 If you are just learning checkers (C)...stick with that...
 You might be able to learn chess (C++) without understanding
  checkers (C), but this is hard...

As C programmers know...there are several ways to increment a c...
 c++;
 c += 1;
 c = c + 1;
 c = 1 + c;
...there is only one way to "skin a C+@"...:)

 ...have a cup of Hot Java...it is FREE...!!!
 ...while you are waiting for the ANSI C++ standard...

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article <3uaknh$2ri@calum.csclub.uwaterloo.ca>
rridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:

|> Shankar Unni <shankar@engr.sgi.com> wrote:
|> > bool-- is an undefined operation, and is not guaranteed to set the boolean
|> > to zero. bool++ will, however, set it to true.

|> Michael Shields <shields@tembel.org> wrote:
|> >Is there a rationale given?
|> >
|> >I'm pretty sure ISO Pascal worked the same way, but that's not a reason.

|> My guess is that "bool++" is common C idiom, "bool--" isn't.  Going
|> further would only constrain implementations and encourage (what I at
|> least would call) a bad programming style.

Your guess is correct.

In the original proposal, the ++ operator and the (silent) conversions
to int, from int/pointer/float were deprecated.  The deprecation
somehow got lost in the adaption process.

Concerning deprecation: officially, deprecation means that the feature
is slated for removal in a future version of the standard.
Practically, well...  Fortran 90 still has arithmetic if, which was
deprecated (if I'm not mistaken) 25 years ago.  So deprecation really
only means that the standards organization thinks that the feature is
a bad thing, and is encouraging compiler writers to generate warnings.
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <DBpJM1.MCD@crdnns.crd.ge.com> volpe@bart.crd.ge.com
(Christopher R. Volpe) writes:

|> In article <3tusmn$mk@rover.village.org>, imp@village.org (Warner Losh) writes:
|> >In article <DBK0I1.Fon@crdnns.crd.ge.com>,
|> >Christopher R. Volpe <volpe@ausable.crd.ge.com> wrote:
|> >>I don't think this is an appropriate analogy. Offsetof is just as useful for
|> >>C++ as it is for C. C already allows you to take the address of structure
|> >>members. The result is a pointer to the type of the data member, and it works
|> >>exactly the same way as in C++. The "pointer to member" of C++ is actually a
|> >>"pointer to member FUNCTION", which is necessary in C++ due to the extra
|> >>"this" pointer that C++ member functions have. There is no analog of this in C.
|> >
|> >However, C++'s does have pointers to member DATA.  They are quite
|> >useful and make things more typesafe if you want to initialize
|> >elements of a class from a data table.

|> Thanks. I wasn't aware of that. How are they more typesafe? And what type does
|> the "&" operator yield when applied to a class member of type int? Does it
|> yield "pointer to int" or "pointer to class member of type  int"?

Pointer to class member of type int.  Compare the following:

C (using offsetof):

 struct S { int a ; int b ; } ;

 size_t              pi = offsetof( S , b ) ;
 S*                  ps = &someS ;

 *((int*)((char*)ps + pi)) = 1 ;

C++ (using pointer to member):

 struct S { int a ; int b ; } ;

 int S::*            pi = &S::b ;
 S*                  ps = &someS ;
 ps->*pi = 1 ;

Note the casts in the C version.  (For that matter, note the
complexity of the expression needed to access the value in C.)

|> >  That sounds like a replacement
|> >to me.

|> Not to me. It doesn't seem to me that pointer to data member gives you
|> anything towards making offsetof obsolete that simply taking the address of a
|> struct field gives you. In C, the offsetof macro is useful despite the ability
|> to generate a pointer to a struct member. Whatever uses offsetof has in C
|> should still apply in C++ despite the existence of a more typesafe pointer
|> type.

What *is* the use of offsetof, other than the above?  (To be truthful,
I've never used offsetof in C.  I cannot say that pointers to member
data in C++ are that frequent in my code, either.)

|> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
|> >big pain in the butt due the all the restrictions in their use that
|> >have recently been added to them (relative to a liberal reading of the
|> >ARM).

|> Such as? (Just curious)

I suspect that the original poster was referring to various
restrictions concerning casting of member pointers.  Basically, the
ARM allowed casting from one class to another, *but* it did not define
the semantics of such a cast.  In practice, the compilers I had access
to either did not allow the cast, or gave it reinterpret_cast syntax,
which basically made it useless, so I don't know why the poster
actually complaining.  (Of course, without multiple inheritance,
reinterpret_cast and static_cast, which might have been useful,
actually generate the same code for most implementations.  So if you
like to count on such chances...)
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <KANZE.95Jul18160836@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
>|> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
>|> >big pain in the butt due the all the restrictions in their use that
>|> >have recently been added to them (relative to a liberal reading of the
>|> >ARM).
>|> Such as? (Just curious)
>
>I suspect that the original poster was referring to various
>restrictions concerning casting of member pointers.  Basically, the
>ARM allowed casting from one class to another, *but* it did not define
>the semantics of such a cast.  In practice, the compilers I had access
>to either did not allow the cast, or gave it reinterpret_cast syntax,
>which basically made it useless, so I don't know why the poster
>actually complaining.  (Of course, without multiple inheritance,
>reinterpret_cast and static_cast, which might have been useful,
>actually generate the same code for most implementations.  So if you
>like to count on such chances...)

Excuse me, but I'm the original poster.  And most compilers allowed
it.  At least *ALL* of the compilers that I threw the OI library
against in the five years that I was working on it.  These included
cfront, HP's compiler, DEC's cxx, IBM's xlC, GNU g++, a couple of
different Microsoft compilers and one or two others that have slipped
my mind (Lucid and Centerline maybe).

These casts were years before all the *_cast that are now in draft
versions of the standard.  Member function pointers were quite useful
if you steered clear of MI, especially virtual base classes, but were
otherwise quite "robust", given that virtual functions had to work.

Basically, the code looks like (I no longer have access to the sources
in question, so there may be a couple of minor syntax errors in the
folowing):

 class B
 { public: B(); ~B();
  virtual void f();
 };

 typedef (B::*foo_memfnp)(void *, void *);

Now, if you derive a class D from class B that has a function that
takes two void *'s as parameters, then you could have code that looks
like the following:

 class D : public B { void foo( void *, void *); };
 D *d;

 set_callback( d, (foo_memfnp) &D::foo );

where set_callback looks something like:
 void set_callback( B * b, foo_memfnp )
 {
  cb = new cb( b, foo_memfnp );
 }

and then later you can make a generic callback through cb as follows:
 void * x;
 void * y;

 cb->callback( x, y )

 void CB::Callback( void *a, void *b) {
  (b->*mfp)( a, b );
 }

(where b and mfp are members of class CB).

Notice that this method is allowed in the ARM, but it is unclear what
some of the language in the ARM means.  One way of reading it is to
allow the above casting and calling.  Another way of reading it is to
not allow it.  The current standard, however, makes it clear that
calling through mfp produces undefined results.

That's the sort of change that I was complaining about :-).  The
entire generic callbacks code in the OI library will have undefined
results when the standard is accepted and will need to be changed.
The OI library is a large hunk of code (on the order of 200K lines of
code, with callbacks strewn thoughout the entire code base).

I've moved on from the OI project, as have most people that know
enough about these problems to be concerned about the direction that
standarization is taking in this area.  I just bring it up as an
example where the standards group, in their efforts to produce a
better language, broke existing practices.  And these existing
practices were due to a more informal spec, which is why informal
specs are bogus (or am I confusing this thread with the HotJava
thread :-)?)

Warner
--
Warner Losh  "VMS Forever"  home: imp@village.org
Cyberspace Development, Inc   work: imp@marketplace.com
Makers of TIA, The Internet Adapter.  http://marketplace.com/

In article <KANZE.95Jul18160836@slsvhdt.lts.sel.alcatel.de>,
kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:

>C (using offsetof):
>
> struct S { int a ; int b ; } ;
>
> size_t              pi = offsetof( S , b ) ;
> S*                  ps = &someS ;
>
> *((int*)((char*)ps + pi)) = 1 ;
>

>What *is* the use of offsetof, other than the above?  (To be truthful,
>I've never used offsetof in C.  I cannot say that pointers to member
>data in C++ are that frequent in my code, either.)

I checked some recent code and found two uses with variable messages.
Consider a list of possible messages defined by structs (yes, I know
that the exact allocation is implementation-defined):

  struct M1 { ... ; unsigned short crc; } m1;
  struct M2 { ... ; unsigned short crc; } m2;    /* different len */

  AddCRC (&m1, offsetof(struct M1, crc));
  AddCRC (&m2, offsetof(struct M2, crc));

Here AddCRC calculates the CRC of the message, for the given length
and places it at that offset.

Second use:

 struct M3 { ...; unsigned char len; char data[16];} m3;
 m3.len = messageLen;
 SendMessage (&m3, offsetof (struct M3, data) + messageLen);

Here the data is the last element of M3 and is variable in length.
The second parameter of SendMessage specifies how many characters to
send (the message recipient knows how to handle variable length
messages).

Thad


>
>|> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
>|> >big pain in the butt due the all the restrictions in their use that
>|> >have recently been added to them (relative to a liberal reading of the
>|> >ARM).
>
>|> Such as? (Just curious)
>
>I suspect that the original poster was referring to various
>restrictions concerning casting of member pointers.  Basically, the
>ARM allowed casting from one class to another, *but* it did not define
>the semantics of such a cast.  In practice, the compilers I had access
>to either did not allow the cast, or gave it reinterpret_cast syntax,
>which basically made it useless, so I don't know why the poster
>actually complaining.  (Of course, without multiple inheritance,
>reinterpret_cast and static_cast, which might have been useful,
>actually generate the same code for most implementations.  So if you
>like to count on such chances...)
>--
>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 en informatique industrielle --
>                              -- Beratung in industrieller Datenverarbeitung
>
>

shankar@sgi.com (Shankar Unni) writes:

>Michael Shields (shields@tembel.org) wrote:
>
>> It depends on the semantics you want.  Personally, I'd like to say that
>> bool can only be 0 or 1, so that `foo--' will always set it false, and
>> `tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.

In C++, a bool can only be `true' or `false'.
In an integer context, `true' converts to 1, `false' converts to 0.

>Hahahaha. (sorry). Check out the C++ draft:
>
>bool-- is an undefined operation, and is not guaranteed to set the boolean
>to zero.

Wrong.  It's not undefined, it's ill-formed.  The compiler must issue
a diagnostic if you use `--' on a bool.

>bool++ will, however, set it to true.
>
>I guess the intent was that implementations can quietly implement bool as
>"unsigned char" and do nothing else, but that's clearly silly, since they
>would still have to guard against 256 ++'s in a row.

You guess wrong.

I'm pretty sure that the reason `++' was defined for bools is to allow
easy conversion of old dusty-deck code which has been observed to use
`++' on variables whose type is a typedef or macro called `bool' or
something similar.

--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh

In article <3u701n$f17@news0.rain.rg.net>, Paul Long  <plong@perf.com> wrote:
>pete@borland.com (Pete Becker) wrote:
>>The reason for this was to make conversion of existing applications easy.
>>One example is a command-line parser, which increments the p-counter every
>>time it encounters -p on the command line.
>
>If p were boolean, wouldn't p|=1 be more intuitive in this situation
>than p++?

Probably.  On the other hand, what have people always used? Answer: p++.
Backwards compatibility is a hairy subject that is seldom logical.

>>Since the only issue after the
>>parsing has been done is 0 vs. non-0, it sure looks like a boolean value.
>
>Sounds like the question is whether or not a boolean type should be a
>_modulo-2_ integral type. I think it should.

Unfortunately, that implies p++ is XOR, not SET, contrary to current
usage, regardless of what is "should" be.  IMHO, the answer (ignoring
the backwards compatibility question since you seem to be ignoring it)
is obvious: p++ is nonsensical.  Limit operations on booleans to the
'traditional' mathematical operations, which are the only sanely
defined ones.

If you want to set a bool to be true, use bool = true.  If you want to
flip it, use bool = ~bool or bool ^= true (granted, that second one
looks a bit counterintuitive, but it's sound from a mathematical standpoint).

It shouldn't be strictly possible to 'add' booleans, etc.  add is an operation
on integral types, not booleans.  However, one can obviously do it
through a conversion to (int), so true + true == 2, and (bool)5 +
(bool)12 == 2.

That's the _sensible_ way to do it.  Of course, there are other
practical issues lurking in the corners here which can't be ignored.

--
---
Tim Hollebeek                   'There will be a better sig when I have time'

Shankar Unni <shankar@engr.sgi.com> wrote:
> bool-- is an undefined operation, and is not guaranteed to set the boolean
> to zero. bool++ will, however, set it to true.

Michael Shields <shields@tembel.org> wrote:
>Is there a rationale given?
>
>I'm pretty sure ISO Pascal worked the same way, but that's not a reason.

My guess is that "bool++" is common C idiom, "bool--" isn't.  Going
further would only constrain implementations and encourage (what I at
least would call) a bad programming style.

       Ross Ridge

--
 l/  //   Ross Ridge -- The Great HTMU, Ook                    +1 519 883 4329
[oo][oo]  rridge@csclub.uwaterloo.ca      http://csclub.uwaterloo.ca/u/rridge/
-()-/()/
 db  //

Someone wrote way upthreads:
> >>The reason for this was to make conversion of existing applications easy.
> >>One example is a command-line parser, which increments the p-counter every
> >>time it encounters -p on the command line.

Then the p-counter is not a boolean, and should not be made to have a
boolean type.  If the p-counter is intended to be a boolean, it shouldn't
be incremented.

tim@handel.Princeton.EDU (Tim Hollebeek) wrote (not directly in response
to the above):
> Probably.  On the other hand, what have people always used? Answer: p++.
> Backwards compatibility is a hairy subject that is seldom logical.

Personally, I see no point in using "p++" instead of "p = 1" or "p = YES"
(or "p = TRUE", for those who prefer that spelling), even in C.  "p++"
is not intuitive, and gives a creepy feeling that something is going
to break if p grows too large.[1]  Creepy feelings are something to
avoid when coding.

Making a boolean type work with ++ (but not with --) is not going to
buy all that much.  If the old code is something like this:

 int p = 0;

 if (some_condition)
  ++p;

then, if someone changes p to be a boolean, the compiler could easily
diagnose every instance of ++ used with p.  That would make it easier
to fix the program.

There are likely to be other places that might need to be changed if
the type of p is changed.  I can't imagine that it would be very costly
to have to change "p++".

> If you want to set a bool to be true, use bool = true.  If you want to
> flip it, use bool = ~bool or bool ^= true (granted, that second one
> looks a bit counterintuitive, but it's sound from a mathematical standpoint).

I'd prefer these:

 bool = true; // set it
 bool = false; // clear it
 bool = !bool; // flip it

Again, I see no reason to "taint" a boolean type so that it works with
operands that lack the boolean nature.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
NEW: Publib version 0.5: ftp://ftp.cs.helsinki.fi/pub/Software/Local/Publib/

[1] What do you mean, it is known not to grow too large.  Did you
prove it?  If so, wouldn't it have been easier to just use "p=1"?

In article <3u1113$pjs@fido.asd.sgi.com> shankar@engr.sgi.com writes:

> I guess the intent was that implementations can quietly implement bool as
> "unsigned char" and do nothing else, but that's clearly silly, since they
> would still have to guard against 256 ++'s in a row.

The intent is to allow programmers who use int values as booleans
and set them to true by applying ++ to them to change them to type bool
without changing alll the places they're used.

Wise or not, the practice of using ++ to make a variable "true"
is widespread.
--
    --Andrew Koenig
      ark@research.att.com

volpe@bart.crd.ge.com (Christopher R. Volpe) writes:

>maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>> C++ basically adds three features to C -- user defined
>>types (classes), exceptions, and templates. It also soups
>>up the safety of a couple of things -- casts, offsetof is replaced
>                                               ^^^^^^^^^^^^^^^^^^^^
>>by pointers to members.  And it adds "inline" functions for
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
>I don't think this is an appropriate analogy.

It's not perfect, but I think it is closer than you make out.

>Offsetof is just as useful for C++ as it is for C.

Well... not quite.  In C++, offsetof() isn't guaranteed to work
for all fields - it is only guaranteed to work for fields of PODs,
i.e. C-like structs.  You can't (portably or reliably) use offsetof()
on classes with virtual functions, virtual base classes, etc.

>C already allows you to take the address of structure
>members. The result is a pointer to the type of the data member, and it works
>exactly the same way as in C++. The "pointer to member" of C++ is actually a
>"pointer to member FUNCTION", which is necessary in C++ due to the extra
>"this" pointer that C++ member functions have. There is no analog of this in C.

But in C++, pointers to members can point to data, they don't have to
point to functions.  John Skaller should have said "offsetof is replaced
by pointers to data members" (as opposed to pointers to function members).

--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F

Michael Shields (shields@tembel.org) wrote:

> It depends on the semantics you want.  Personally, I'd like to say that
> bool can only be 0 or 1, so that `foo--' will always set it false, and
> `tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.

Hahahaha. (sorry). Check out the C++ draft:

bool-- is an undefined operation, and is not guaranteed to set the boolean
to zero. bool++ will, however, set it to true.

I guess the intent was that implementations can quietly implement bool as
"unsigned char" and do nothing else, but that's clearly silly, since they
would still have to guard against 256 ++'s in a row.

In practice, I guess most implementations would actually implement bool as
an unsigned char, with bool++ being changed to bool=true, and bool-- to
bool=false;

However, tzname[isdst] will work regardless of the implementation, because
the conversion of a bool to an int must always yield a 0 or a 1..
--
Shankar Unni    E-Mail: shankar@sgi.com
Silicon Graphics Inc.   Phone: +1-415-390-2072
URL: http://reality.sgi.com/employees/shankar

In article <3u1113$pjs@fido.asd.sgi.com>,
Shankar Unni <shankar@engr.sgi.com> wrote:
> Michael Shields (shields@tembel.org) wrote:
>
> > It depends on the semantics you want.  Personally, I'd like to say that
> > bool can only be 0 or 1, so that `foo--' will always set it false, and
> > `tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
>
> Hahahaha. (sorry). Check out the C++ draft:
>
> bool-- is an undefined operation, and is not guaranteed to set the boolean
> to zero. bool++ will, however, set it to true.

Is there a rationale given?

I'm pretty sure ISO Pascal worked the same way, but that's not a reason.
--
Shields.

In article <3tv3gv$bhc@yage.tembel.org>, shields@tembel.org (Michael Shields) writes:
>Personally, I'd like to say that
>bool can only be 0 or 1, so that `foo--' will always set it false, and
>`tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.

Close.  You'd have to say that bool can only be 0, 1, or Maybe, so that
tzname[isdst] will index correctly :-)
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer

In article <3u1s4v$j9u@usenet.pa.dec.com>,
Norman Diamond <diamond@jrd.dec.com> wrote:
> In article <3tv3gv$bhc@yage.tembel.org>, shields@tembel.org (Michael Shields) writes:
> >Personally, I'd like to say that
> >bool can only be 0 or 1, so that `foo--' will always set it false, and
> >`tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
>
> Close.  You'd have to say that bool can only be 0, 1, or Maybe, so that
> tzname[isdst] will index correctly :-)

Perhaps there should be a new `quantum' type; you would be able to take
its address or value, but not both simultaneously.
--
Shields.

In article <3u1113$pjs@fido.asd.sgi.com>, shankar@sgi.com (Shankar Unni) says:
>
>Michael Shields (shields@tembel.org) wrote:
>
>> It depends on the semantics you want.  Personally, I'd like to say that
>> bool can only be 0 or 1, so that `foo--' will always set it false, and
>> `tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
>
>Hahahaha. (sorry). Check out the C++ draft:
>
>bool-- is an undefined operation, and is not guaranteed to set the boolean
>to zero. bool++ will, however, set it to true.
>
>I guess the intent was that implementations can quietly implement bool as
>"unsigned char" and do nothing else, but that's clearly silly, since they
>would still have to guard against 256 ++'s in a row.
>

The reason for this was to make conversion of existing applications easy.
One example is a command-line parser, which increments the p-counter every
time it encounters -p on the command line. Since the only issue after the
parsing has been done is 0 vs. non-0, it sure looks like a boolean value.
 -- Pete

In article <3tv3gv$bhc@yage.tembel.org>, shields@tembel.org (Michael Shields) writes:
>In article <3thkkk$437@fido.asd.sgi.com>,
>Shankar Unni <shankar@engr.sgi.com> wrote:
>>  - inline functions.
>
>I'd also like to see ways to declare that a function has no side effects,
>and that it does not return.
>
>> I'm torn on the "bool" data type (nah... - it can be done trivially with a
>> header file).
>
>It depends on the semantics you want.  Personally, I'd like to say that
>bool can only be 0 or 1, so that `foo--' will always set it false, and

If the bool type can be only zero or one, I'm not sure I'd want "--" to be a
valid operator for the type.

--

Chris Volpe    Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D   Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301  Email: volpecr@crd.ge.com

In article <3tusmn$mk@rover.village.org>, imp@village.org (Warner Losh) writes:
>In article <DBK0I1.Fon@crdnns.crd.ge.com>,
>Christopher R. Volpe <volpe@ausable.crd.ge.com> wrote:
>>I don't think this is an appropriate analogy. Offsetof is just as useful for
>>C++ as it is for C. C already allows you to take the address of structure
>>members. The result is a pointer to the type of the data member, and it works
>>exactly the same way as in C++. The "pointer to member" of C++ is actually a
>>"pointer to member FUNCTION", which is necessary in C++ due to the extra
>>"this" pointer that C++ member functions have. There is no analog of this in C.
>
>However, C++'s does have pointers to member DATA.  They are quite
>useful and make things more typesafe if you want to initialize
>elements of a class from a data table.

Thanks. I wasn't aware of that. How are they more typesafe? And what type does
the "&" operator yield when applied to a class member of type int? Does it
yield "pointer to int" or "pointer to class member of type  int"?

>  That sounds like a replacement
>to me.

Not to me. It doesn't seem to me that pointer to data member gives you
anything towards making offsetof obsolete that simply taking the address of a
struct field gives you. In C, the offsetof macro is useful despite the ability
to generate a pointer to a struct member. Whatever uses offsetof has in C
should still apply in C++ despite the existence of a more typesafe pointer
type.

>
>C++ also has pointers to member FUNCTIONS which are, quite frankly, a
>big pain in the butt due the all the restrictions in their use that
>have recently been added to them (relative to a liberal reading of the
>ARM).

Such as? (Just curious)

--

Chris Volpe    Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D   Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301  Email: volpecr@crd.ge.com

In article <3tgsog$2gc@citadel.evolving.com>,
Todd Blanchard <tblancha@evolving.com> wrote:
>Marc Shepherd (shepherd@debussy.sbi.com) wrote:
>
>You'd need a more compelling reason than longer types for a language review.

 Irrelevant. The reason there is a language review is that 5 years
is up from the last Standard. Its normal procedure.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3tmdgp$kmm@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>In article <1995Jul2.162927.55200@cc.usu.edu>,
>Paul Hepworth <sl65r@cc.usu.edu> wrote:
>>> Also, I would be curious at what point C++ and C converge and the
>>> need for two standards disappears.
>>
>>I don't think this will ever happen.  C++ has taken the kitchen-sinking
>>approach to features whereas C retains a keep-it-simple philosophy.
>
> I'm not sure if that is a fair description of C++, and
>I wouldn't count on the C committee -- which is current reviewing
>the C Standard -- keeping C all that simple -- or indeed,
>making it simpler. (I hope it does, however).
>
> C++ basically adds three features to C -- user defined
>types (classes), exceptions, and templates. It also soups
>up the safety of a couple of things -- casts, offsetof is replaced
                                               ^^^^^^^^^^^^^^^^^^^^
>by pointers to members.  And it adds "inline" functions for
 ^^^^^^^^^^^^^^^^^^^^^^^^

I don't think this is an appropriate analogy. Offsetof is just as useful for
C++ as it is for C. C already allows you to take the address of structure
members. The result is a pointer to the type of the data member, and it works
exactly the same way as in C++. The "pointer to member" of C++ is actually a
"pointer to member FUNCTION", which is necessary in C++ due to the extra
"this" pointer that C++ member functions have. There is no analog of this in C.

--

Chris Volpe    Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D   Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301  Email: volpecr@crd.ge.com

In article <3tsqb5$e3q@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au
says...
>
>In article <3tgsog$2gc@citadel.evolving.com>,
>Todd Blanchard <tblancha@evolving.com> wrote:
>>Marc Shepherd (shepherd@debussy.sbi.com) wrote:
>>
>>You'd need a more compelling reason than longer types for a language
review.
>
>        Irrelevant. The reason there is a language review is that 5 years
>is up from the last Standard. Its normal procedure.
>--
>        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
@@@@@@@@@@@@@@@@@@@@@@@@@@@@

I am not sure that this is accurate. Just because the 5 years are up, that
does _not_ trigger an automatic rework of the language. I think that the
process has at least two steps.

As I understand the process, *after* 5 years, there are three doors to
choose:

 Door #1 - The standard stands with no changes
 Door #2 - The standard is reworked (this was selected)
 Door #3 - The standard is abandoned because of irrelevance

According to the August issue of Dr. Dobb's Journal, P. J. Plauger asked
the committee in 1994 (a year early) to consider the above three choices.
Door #2 was selected. It is not clear why the early request was made, but
the rework process has been started.

After 5 years, it is hard to imagine that Door #1 could have been selected.
Door #3 is certainly not an option because clearly, there is still a lot
of C code being written...at least the last time I looked...:-)

The question now is, how much review/rework/rewriting etc. is required
and how will that dove-tail with the C++ Standards work...???

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article <DBK0I1.Fon@crdnns.crd.ge.com>,
Christopher R. Volpe <volpe@ausable.crd.ge.com> wrote:
>I don't think this is an appropriate analogy. Offsetof is just as useful for
>C++ as it is for C. C already allows you to take the address of structure
>members. The result is a pointer to the type of the data member, and it works
>exactly the same way as in C++. The "pointer to member" of C++ is actually a
>"pointer to member FUNCTION", which is necessary in C++ due to the extra
>"this" pointer that C++ member functions have. There is no analog of this in C.

However, C++'s does have pointers to member DATA.  They are quite
useful and make things more typesafe if you want to initialize
elements of a class from a data table.  That sounds like a replacement
to me.

C++ also has pointers to member FUNCTIONS which are, quite frankly, a
big pain in the butt due the all the restrictions in their use that
have recently been added to them (relative to a liberal reading of the
ARM).

Warner
--
Warner Losh  "VMS Forever"  home: imp@village.org
Cyberspace Development, Inc   work: imp@marketplace.com
Makers of TIA, The Internet Adapter.  http://marketplace.com/

In article <3thkkk$437@fido.asd.sgi.com>,
Shankar Unni <shankar@engr.sgi.com> wrote:
>  - inline functions.

I'd also like to see ways to declare that a function has no side effects,
and that it does not return.

> I'm torn on the "bool" data type (nah... - it can be done trivially with a
> header file).

It depends on the semantics you want.  Personally, I'd like to say that
bool can only be 0 or 1, so that `foo--' will always set it false, and
`tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
--
Shields.

In article <1995Jul2.162927.55200@cc.usu.edu>,
Paul Hepworth <sl65r@cc.usu.edu> wrote:
>> Also, I would be curious at what point C++ and C converge and the
>> need for two standards disappears.
>
>I don't think this will ever happen.  C++ has taken the kitchen-sinking
>approach to features whereas C retains a keep-it-simple philosophy.

 I'm not sure if that is a fair description of C++, and
I wouldn't count on the C committee -- which is current reviewing
the C Standard -- keeping C all that simple -- or indeed,
making it simpler. (I hope it does, however).

 C++ basically adds three features to C -- user defined
types (classes), exceptions, and templates. It also soups
up the safety of a couple of things -- casts, offsetof is replaced
by pointers to members.  And it adds "inline" functions for
efficiency.

 Almost all the other "features" turn out to be necessary
to support these things, including constructors, overloading,
references and inheritance.

 Unfortunately, C turns out not to be a nice simple
language at all. If it were, extending it would be easy and
the result relatively simple.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Jim Fleming <jim.fleming@bytes.com> wrote:
> People who do not have these same restrictions, blindly
> follow the leaders who clearly have no interest in the public having
> knowledge of what is going on until they are ready for the "market".

ANSI X3J11, being a subgroup of the Trilateral Commission, has very
strict rules about how and when it is allowed to disseminate information
to the public.  This has the side-effect of-- whoops, I've said too much
already.

dave
--
Dave Mooney | IBM Toronto Lab | "We see the fish below the ice sometimes."

In article <3tmdgp$kmm@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au
says...
>
>In article <1995Jul2.162927.55200@cc.usu.edu>,
>Paul Hepworth <sl65r@cc.usu.edu> wrote:
>>> Also, I would be curious at what point C++ and C converge and the
>>> need for two standards disappears.
>>
>>I don't think this will ever happen.  C++ has taken the kitchen-sinking
>>approach to features whereas C retains a keep-it-simple philosophy.
>
>        I'm not sure if that is a fair description of C++, and
>I wouldn't count on the C committee -- which is current reviewing
>the C Standard -- keeping C all that simple -- or indeed,
>making it simpler. (I hope it does, however).
>
>        C++ basically adds three features to C -- user defined
>types (classes), exceptions, and templates. It also soups
>up the safety of a couple of things -- casts, offsetof is replaced
>by pointers to members.  And it adds "inline" functions for
>efficiency.
>
>        Almost all the other "features" turn out to be necessary
>to support these things, including constructors, overloading,
>references and inheritance.
>
>        Unfortunately, C turns out not to be a nice simple
>language at all. If it were, extending it would be easy and
>the result relatively simple.
>
>--
>        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
@@@@@@@@@@@@@@@@@@@@@@@@@@@@

This sounds like C is going to "buy cancer". As soon as classes are
added to C, then the rest comes along for the ride.

If ANSI C inherits (not OO inheritance) most of the features of C++,
then why have two standards?

I currently meet people all of the time that claim that they are programming
in C++. I ask them if they are doing object-oriented programming. They
answer, "Yep!". I ask them if they use classes, they usually say, "No, I
have not gotten that far into the language".

In my opinion, C has lost it's heritage to C++. While this might be viewed
as a major marketing coup by language designers, I think that it is a
disservice to the C programming community. It is also a disservice to the
field of object technology, because we now have educated people running
around that think they know what OO is about...but, they "have not gotten
that far into the language"...and therefore, have not scratched the surface
of OO...

Can you imagine a lawyer saying, I use English but I have not mastered
contracts because I have not gotten that far into the language? The
language should be easy to master, the various usages (like contract law)
should build upon the simple language base. If English had to have
extensions to support certain domains, then it would die under the
weight of the extensions.

I predict that C++ will die under the weight of it's OO extensions. I
hope that it does not take C with it...

Maybe C++ needs to be renamed...then it would not impact C....
 ...we could call it DOOG...or D+OO+G...or D+OO+Gnu...:)

C+@ could remain as CAT...:)
 ...then C could remain as C...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@
--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article ngf@citadel.evolving.com, tblancha@evolving.com (Todd Blanchard) writes:
>: The ANSI C standard was completed in 1990 and on the 5th anniversary
>: all standards are considered for review. According to the article in
>: Dr. Dobb's Journal, in 1994, P.J. Plauger (one of the copyright holders
>: of the ANSI C++ standard) convened an *early* effort to begin evaluating
>: the need to revise the ISO/ANSI C standard. This effort resulted in
>: recommending that the ANSI C standard be revised.
>
>Well that would suck.  C is what it is.  C++ is what it is.  I use both.
>I like C for what it does.  Small is beautiful, simple is elegant.
>C++ is feature packed and I would not welcome the current standards committees
>group think mentality mucking about with something that has served me so
>well for so long.

Don't overreact.  The objective of revising C is *not*, so far as I know,
to make it more like C++.  There are a number of important extensions having
nothing at all to do with C++, that warrant attention.  The ability to
represent new, longer integral types (e.g. 64, 128 bit) is one frequently-
mentioned example.

---
Marc Shepherd
Salomon Brothers Inc
shepherd@schubert.sbi.com The opinions I express are no one's but mine!

Marc Shepherd (shepherd@debussy.sbi.com) wrote:
: In article ngf@citadel.evolving.com, tblancha@evolving.com (Todd Blanchard) writes:
: >: recommending that the ANSI C standard be revised.
: >
: >Well that would suck.  C is what it is.  C++ is what it is.  I use both.

: Don't overreact.  The objective of revising C is *not*, so far as I know,
: to make it more like C++.  There are a number of important extensions having
: nothing at all to do with C++, that warrant attention.  The ability to
: represent new, longer integral types (e.g. 64, 128 bit) is one frequently-
: mentioned example.

That's hardly worthy of a language review.  The current standard covers that
anyhow.  From K&R 2nd:
"The intent is that short and long should provide different lengths of integers
where practical; int will normally be the natural size for a particular
machine.  short is often 16 bits, long 32 bits, and int either 16 or 32
bits.  Each compiler is free to choose appropriate sizes for its own hardware,
subject only to the restriction that shorts and ints are at least 16 bits,
longs are at least 32 bits, and short is no longer than int which is no
longer than long."

So a compiler could define:

sizeof(short) == 32
sizeof(int)   == 64
sizeof(long)  == 128

You'd need a more compelling reason than longer types for a language review.

Todd Blanchard

In article <3tgsog$2gc@citadel.evolving.com> tblancha@evolving.com (Todd Blanchard) writes:
> Marc Shepherd (shepherd@debussy.sbi.com) wrote:
> : Don't overreact.  The objective of revising C is *not*, so far as I know,
> : to make it more like C++.  There are a number of important extensions having
> : nothing at all to do with C++, that warrant attention.  The ability to
> : represent new, longer integral types (e.g. 64, 128 bit) is one frequently-
> : mentioned example.
>
> That's hardly worthy of a language review.  The current standard covers that
> anyhow.  From K&R 2nd:
[..]
>
> You'd need a more compelling reason than longer types for a language review.

There is some need for _sized_ types, say int<k> (or int:k or whatever
syntax one could come up with), with a semantics of "an integer type having
at least <k> bits" (*). Such an extension to C could improve portability,
both of new and of old programs (when porting from an old machine with,
say, 36-bit longs, one could simply #define long as int(36) to approximate
the old behaviour). As a side benefit, >32-bit-values could be used without
resorting to horrors like "long long".

-- Markus

(* I know, there are dozens of minor open issues wrt the precise behaviour
of shifting and overflow, argument widening, maximum implementation-provided
<k> and whatnot. But hey, working out these details is what standards
committees are for, no? ;-)

Todd Blanchard (tblancha@evolving.com) wrote:

> That's hardly worthy of a language review.  [...]
> So a compiler could define:
> sizeof(short) == 32
> sizeof(int)   == 64
> sizeof(long)  == 128

Actually, it *is* worthy of review, because the model is restrictive. For
instance, it doesn't address the following needs:

 - types of known size (smallest type that's at least 32 bits wide)
 - more than 3 natural word sizes (the next generation of machines is
   likely to make this necessary).

There are excellent proposals out there that would allow such extensions in
a standard fashion without adding a major burden to the language.  (Of
course, I haven't made my mind up about this particular "extension", but
the proposal is worthy of consideration).

Other good extensions for consideration are:

 - "//" comments
 - declarations inside "for" and "while" controlling expressions (that have
      a scope extending to the end of the dependent statement only, as in
      the ANSI C++ draft).
 - inline functions.
 - integral and floating-point named constants without storage.

(The last two remove 90% of the uses for macros, which I consider to be a
Good Thing To Do(tm) - tagless enum's are a gross and tasteless hack for
named integral constants without storage).

All these can make code more readily understandable to the maintainers and
writers (and encourage good programming style) without adding a significant
burden on the language or its implementors (which is one of the most
important considerations for C).  And all of them need review, obviously.

I'm torn on the "bool" data type (nah... - it can be done trivially with a
header file).  Allowing bitfields of any integral type is, however, also a
good extension - everyone does it anyway, why make it nonstandard?
--
Shankar Unni    E-Mail: shankar@sgi.com
Silicon Graphics Inc.   Phone: +1-415-390-2072
URL: http://reality.sgi.com/employees/shankar

In article <1995Jul2.162927.55200@cc.usu.edu>
sl65r@cc.usu.edu (Paul Hepworth) wrote:

>> Also, I would be curious at what point C++ and C converge and the
>> need for two standards disappears.
>
> I don't think this will ever happen.  C++ has taken the kitchen-sinking
> approach to features whereas C retains a keep-it-simple philosophy.
> It was proposed months ago that classes be added to C, but the C standards
> commitee was strongly opposed to templates, operator overloading, and
> automatic constructor/destructor invokation;  these are my favorite
> features of C++!  I don't think the day will ever come when the C die-hards
> accept all the kitchen-C++, nor will us C++ lovers ever part with our
> more complex features.  (Of course, those who don't like the complex
> features may still use C++, but employ only the subset with which they
> are comfortable.
>
>
> Paul
>
> (references:  numerous articles in C/C++ Users Journal)

Well, if the standard writers have their way, you won't even have the
option of employing the subset with which you are comfortable.  They
have taken the approach that templates are a Good Thing and practically
mandated them whith their outrageous string class with its kitchen sink
interface (basic_string template, see 'The Header <string>' by P.J. Plauger
in the 07/95 issue of the C/C++ Journal) .  Because it is implemented
as a template, compiling the simplest program that includes it will involve
re-compiling several thousands of lines of code that most likely will not
be needed.  Don't use their string class, you say?  Well, according to
Plauger, they have modified iostreams to use it, so if you use iostreams,
you will include this code bloat whether you want it or not.
In my very humble view, using templates in a library is a very very
ill advised thing to do.  The whole idea of a library is to have at your
disposal standard, pre-compiled utility functions/classes that you merely
have to link in to your program to make use of them.  Templates by their very
nature are not pre-compiled, so you need to compile the library every
time you use it!  Imagine C users re-compiling the C library every time
they wanted to use strcpy()??  Preposterous!  Why a template? So that
library writers could save a few man-hours providing us with a wchar_t
string class, thats why.  The time the rest of us waste waiting on our
compilers to grind through a template compile every time we need an
itty bitty string apparently does not matter to the standard writers.
Just My type<T>.02 (insert your currency here... and re-compile!)


Ray

In article <3thcck$co2@solitaire.cv.nrao.edu> rcreager@nrao.edu (Ramon E. Creager) writes:

> Well, if the standard writers have their way, you won't even have the
> option of employing the subset with which you are comfortable.  They
> have taken the approach that templates are a Good Thing and practically
> mandated them whith their outrageous string class with its kitchen sink
> interface (basic_string template, see 'The Header <string>' by P.J. Plauger
> in the 07/95 issue of the C/C++ Journal) .  Because it is implemented
> as a template, compiling the simplest program that includes it will involve
> re-compiling several thousands of lines of code that most likely will not
> be needed.

Bear in mind that library headers are special.  The basic_string class
is required to behave (almost) as if it's a class template, but it is
not required to be implemented that way.  Compiler vendors do not have
to provide a text file called string.h that contains a template
definition, and putting #include <string> in your program does not
necessarily result in the textual inclusion of anything.  Compiler
vendors are allowed to (and encouraged to) treat library functions and
classes as special.

Initially, most compiler vendors probably will implement most of the
standard library classes as ordinary classes written in C++ and will
put their declarations in header files---that's certainly the easiest
implementation.  As Ramon points out, though, an implementation like
that has problems.  Eventually, I expect that compiler vendors will
pay attention to the needs of their customers and will treat common
classes (basic_string<T>, list<T>, vector<T>, complex<T>, and so on)
as built-in parts of the language.  It's an obvious optimization, and
it's surely possible to generate better code if the compiler has
special knowledge about vector<T> than if it thinks that vector<T> is
just the same as any old user-defined class.
--
Matt Austern          matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

In article <3thcck$co2@solitaire.cv.nrao.edu>, rcreager@nrao.edu (Ramon E. Creager) writes:
>In my very humble view, using templates in a library is a very very
>ill advised thing to do.  The whole idea of a library is to have at your
>disposal standard, pre-compiled utility functions/classes that you merely
>have to link in to your program to make use of them.  Templates by their very
>nature are not pre-compiled, so you need to compile the library every
>time you use it!

The last assertion is not necessarily true.  It is possible to store
compiled template code in repositories so that they do not need to be
recompiled if the particular combination of template arguments has been
encountered before.  Most commercial C++ compilers already have this
capability although there appears to be room for improvement as far as
ease of use is concerned.  GNU C++ should acquire similar template
management capabilities in the fairly near future.

In the particular case of the proposed ISO/ANSI string class, vendors
ought to be able to supply the two fundamental template classes
basic_string<char> and basic_string<wchar_t> in precompiled form
using current technology.

--
------------------------------------------------------------------------------
Chris Flatters      cflatter@nrao.edu
------------------------------------------------------------------------------
Well, our problem stems from the fact that we, basically, allow every planet
and moon-base this side of Alpha Centauri to make their own version of Spam.
       "Mystery Meat"
       Man... or Astroman?

rcreager@nrao.edu (Ramon E. Creager) writes:

>Well, if the standard writers have their way, you won't even have the
>option of employing the subset with which you are comfortable.  They
>have taken the approach that templates are a Good Thing and practically
>mandated them whith their outrageous string class with its kitchen sink
>interface (basic_string template, see 'The Header <string>' by P.J. Plauger
>in the 07/95 issue of the C/C++ Journal) .  Because it is implemented
>as a template, compiling the simplest program that includes it will involve
>re-compiling several thousands of lines of code that most likely will not
>be needed.

Nonsense!

Implementations will supply string classes already specialized on
char and wchar_t, precompiled and already in the runtime library.
Using them will be no less efficient or more time-consuming than if
they were not declared as template classes.

Making the string class (for example) a template class has the
advantage of allowing you to have the identical string class
functionality based on other types (e.g., unsigned char), without
requiring you to write any additional code.

--
Steve Clamage, stephen.clamage@eng.sun.com

rcreager@nrao.edu writes:
>Well, if the standard writers have their way, you won't even have the
>option of employing the subset with which you are comfortable.  They
>have taken the approach that templates are a Good Thing and practically
>mandated them whith their outrageous string class with its kitchen sink
>interface (basic_string template, see 'The Header <string>' by P.J. Plauger
>in the 07/95 issue of the C/C++ Journal) .  Because it is implemented
>as a template, compiling the simplest program that includes it will involve
>re-compiling several thousands of lines of code that most likely will not
>be needed.

This is false.  For a demonstration that it is false, download the latest
g++/libg++.  You'll see that the standard string class and complex number
class are installed pre-instantiated.  You can pre-compile a specific
instantiation of a template class and store it in a library.  Since
the string class is just basic_string<char>, basic_string<char> is
pre-instantiated and already in the library.  It's just as efficient as
if it were a non-template.  Similarly for many other things.

Similarly for the iostream type based on strings.  No extra bloat or
compilation time involved.

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Anagrams for "information superhighway": Enormous hairy pig with fan
      A rough whimper of insanity

In article <3thcck$co2@solitaire.cv.nrao.edu>, rcreager@nrao.edu (Ramon E. Creager) writes:
>>...  Templates by their very
>>nature are not pre-compiled, so you need to compile the library every
>>time you use it!

cflatter@nrao.edu writes:
>The last assertion is not necessarily true.  It is possible to store
>compiled template code in repositories so that they do not need to be
>recompiled if the particular combination of template arguments has been
>encountered before.  Most commercial C++ compilers already have this
>capability although there appears to be room for improvement as far as
>ease of use is concerned.  GNU C++ should acquire similar template
>management capabilities in the fairly near future.

GNU C++ already can explicitly instantiate templates and store compiled
versions in libraries, and this is already done in the GNU class
library libstdc++.  Repository support isn't needed to do this.

>In the particular case of the proposed ISO/ANSI string class, vendors
>ought to be able to supply the two fundamental template classes
>basic_string<char> and basic_string<wchar_t> in precompiled form
>using current technology.

The current GNU library class library already has a preexpanded and
precompiled basic_string<char> in the library, also pre-expanded versions
of complex<double>, complex<long double> and complex<float>.

Any compiler vendor can do the same tricks.  While templates have to
be expanded to be compiled, specific template instantiations such as
basic_string<char> are completely specified and can be precompiled.


--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Anagrams for "information superhighway": Enormous hairy pig with fan
      A rough whimper of insanity

In article <...>, Shankar Unni <shankar@engr.sgi.com> wrote:
>
>I'm torn on the "bool" data type (nah... - it can be done trivially with a
>header file).

It's worth pointing out that this is a significant difference between C and
C++; in C a simple typedef will do fine:

 typedef int bool;

in C++ this is not good enough, because that will not allow us to overload
a function on both int and bool.

I think C should make bool a pre-defined typedef (i.e., no header file),
otherwise C++ should have a corresponding empty header file.

      -- Dag
--
Dynasim AB                            Phone:  +46 46 182500
Research Park Ideon                   Fax:    +46 46 129879
S-223 70 Lund                         E-mail: Dag@Dynasim.se
Sweden

In article <DB6L8p.Ctu@ukpsshp1.serigate.philips.nl>,
baynes@ukpsshp1.serigate.philips.nl says...
>
>Jim Fleming (jim.fleming@bytes.com) wrote:
>
>: Evidently a meeting was held recently (early June 1995?) in Copenhagen,
>: Denmark to review the various proposals for revising the ISO/ANSI C
>: standard. I don't recall anything being posted here regarding the
>: meeting such as an agenda or the meeting notes. One would expect that
>: this would be a good forum to discuss such a meeting.
>
>It is a shame if those working on the standard setting do not seem to
>publish what they are doing (or perhaps they just have not got round to
>writing up the minutes). Compare with comp.std.unix which often has
>progress reports from the various parts of the standard setting process.
>
>--
>Stephen Baynes
@@@@@@@@@@@@@@@

They publish, but they only do it in the forums that they control. They
carefully time their publications so that the general public has little
chance of becoming involved. In some cases, the publications are obsolete
before they hit the printer and the general public spends enormous amounts
of time trying to sort through the various versions and viewpoints. In
other cases historical documents are generated which gloss over the issues
and give the public the impression that everything is being handled as
an open and fair process.

What is really a shame is that the discussions and e-mail exchanges are
not part of these Usenet forums. Because some large companies have very
strict policies about their "researchers" engaging in commercial activities
(especially on company time and using company resources), it appears that
some people are not able to use these forums because their company would
discover the nature of their "academic" activities. Therefore, they come
up with convenient reasons why this forum is unacceptable for reporting
their results. People who do not have these same restrictions, blindly
follow the leaders who clearly have no interest in the public having
knowledge of what is going on until they are ready for the "market".

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

>
> C is what it is and C++ is what it is, but the C standards committee seems
> bent on making C more like C++ than I can stomach.  I have been considering
> developing an alternate C dialect I call "C without classes."
>
>      Sincerely,
>      Robert Corbett

I would support you.  Just make it look exactly like ANSI C circa 1994
I think the C++ committee has lost their collective mind in the last year.
And still no support for (optional) GC.  Instead we get bool (significant
non-value right there) and an auto_ptr with a copy constructor to
exacerbate the hidden reference problem.

Twain was right about committees.

Todd Blanchard

For people interested in getting more information on how the ANSI C++
and C standards work are related, you might want to check out the
August 1995 Issue of Dr. Dobb's Journal.

For those that have claimed (in this forum) that there is no movement
to have C++ features migrate to the C standard, you might want to
read this issue.

The ANSI C standard was completed in 1990 and on the 5th anniversary
all standards are considered for review. According to the article in
Dr. Dobb's Journal, in 1994, P.J. Plauger (one of the copyright holders
of the ANSI C++ standard) convened an *early* effort to begin evaluating
the need to revise the ISO/ANSI C standard. This effort resulted in
recommending that the ANSI C standard be revised.

Evidently a meeting was held recently (early June 1995?) in Copenhagen,
Denmark to review the various proposals for revising the ISO/ANSI C
standard. I don't recall anything being posted here regarding the
meeting such as an agenda or the meeting notes. One would expect that
this would be a good forum to discuss such a meeting.

The article in the magazine sheds some light on the proposed changes.
Since most magazines are edited three months in advance, some of these
proposals may have changed by this time. It is unfortunate that Usenet
is not used to report more up to date information.

Comments on the article, the meeting, and any other trends that show
that the ANSI C standard *may* be revised to include C++ features would
certainly be interesting.

Also, I would be curious at what point C++ and C converge and the
need for two standards disappears.

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

> Also, I would be curious at what point C++ and C converge and the
> need for two standards disappears.

I don't think this will ever happen.  C++ has taken the kitchen-sinking
approach to features whereas C retains a keep-it-simple philosophy.
It was proposed months ago that classes be added to C, but the C standards
commitee was strongly opposed to templates, operator overloading, and
automatic constructor/destructor invokation;  these are my favorite
features of C++!  I don't think the day will ever come when the C die-hards
accept all the kitchen-C++, nor will us C++ lovers ever part with our
more complex features.  (Of course, those who don't like the complex
features may still use C++, but employ only the subset with which they
are comfortable.


Paul

(references:  numerous articles in C/C++ Users Journal)

In article <1995Jul2.162927.55200@cc.usu.edu>, sl65r@cc.usu.edu says...
>
>> Also, I would be curious at what point C++ and C converge and the
>> need for two standards disappears.
>
>I don't think this will ever happen.  C++ has taken the kitchen-sinking
>approach to features whereas C retains a keep-it-simple philosophy.
>It was proposed months ago that classes be added to C, but the C standards
>commitee was strongly opposed to templates, operator overloading, and
>automatic constructor/destructor invokation;  these are my favorite
>features of C++!  I don't think the day will ever come when the C die-hards
>accept all the kitchen-C++, nor will us C++ lovers ever part with our
>more complex features.  (Of course, those who don't like the complex
>features may still use C++, but employ only the subset with which they
>are comfortable.
>
>
>Paul
>
>(references:  numerous articles in C/C++ Users Journal)
@@@@@@@@@@@@@

I hope that you are right. Maybe languages like Java (http://java.sun.com/)
and C+@ will illustrate to people that real OO languages can be developed
as companions to C without the need to add incremental features to C that
make it more complex than needed.

These companion languages can focus on the goals of the OO application
developer. I call them "languages for programming systems" as opposed to
"systems programming languages" (like C).

With companion languages, projects can have the traditional C programmers
working on the "hot", performance critical code that is referenced by
the "less hot" OO code that emphasizes reuse and extreme portability.
There is a nice separation of skill sets and the management can more
easily focus each group of programmers on the right objectives.

When the incremental (C++) approach is used, you end up with skilled,
unskilled, left-brain, and right-brain programmers all working in the
same language but potentially using different styles and paradigms.
This may sound eclectic and creative, but it turns out to be a mess.

The best analogy I have found for the companion language approach is
the three-dimensional chess/checker board description. Imagine that
you have a chess board above a checker board. Imagine that as you move
the chess pieces on the upper board things happen on the checker board
via well-defined interfaces. Also, imagine that when pieces are moved
on the checker board side-effects occur on the chess board above.

With a language like C+@ (more so than Java), C+@ programmers write
the rules for the chess game on the upper level while the C programmers
are handling the checker game on the lower level. Well defined interfaces
keep everything in synch.

It has been my experience that using C++ is like collapsing the two
boards into one with the chess pieces and checkers sharing squares, etc.
It is very difficult to see what is going on and the rules for the
combined game are very complex.

I hope that C remains as simple as checkers and I hope that companion
languages (like C+@) show people that a new game can be played on a
similar board and the rules can be simple, like chess, but the potential
can be greater than checkers.

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

: The ANSI C standard was completed in 1990 and on the 5th anniversary
: all standards are considered for review. According to the article in
: Dr. Dobb's Journal, in 1994, P.J. Plauger (one of the copyright holders
: of the ANSI C++ standard) convened an *early* effort to begin evaluating
: the need to revise the ISO/ANSI C standard. This effort resulted in
: recommending that the ANSI C standard be revised.

Well that would suck.  C is what it is.  C++ is what it is.  I use both.
I like C for what it does.  Small is beautiful, simple is elegant.
C++ is feature packed and I would not welcome the current standards committees
group think mentality mucking about with something that has served me so
well for so long.

Todd Blanchard

Jim Fleming (jim.fleming@bytes.com) wrote:

: Evidently a meeting was held recently (early June 1995?) in Copenhagen,
: Denmark to review the various proposals for revising the ISO/ANSI C
: standard. I don't recall anything being posted here regarding the
: meeting such as an agenda or the meeting notes. One would expect that
: this would be a good forum to discuss such a meeting.

It is a shame if those working on the standard setting do not seem to
publish what they are doing (or perhaps they just have not got round to
writing up the minutes). Compare with comp.std.unix which often has
progress reports from the various parts of the standard setting process.

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom