C as a Subset of C++ (or C++ as a superset of C)

A

Ansel

Isn't it a lame use of human time and effort to maintain completely separate
C and C++ standards? As in the words of Betty White about Facebook: "It
seems like an incredible waste of time". Why don't the two standards groups
get together and agree on a common specification for the ground which both
standards cover? There would still be two separate standards, but they'd
both be exactly the same for the common ground. The common ground document
could be referred to by both standards instead of being maintained by both
groups in individual efforts resulting in different verbage in separate
specifications for the same functionality. This should happen after both
groups agree to completely align the C subset functionality on the next
realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
of cooperation going forward).
 
J

Johannes Bauer

This should happen after both
groups agree to completely align the C subset functionality on the next
realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
of cooperation going forward).

Ever heared of printf?

Best regards,
Johannes

--
Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <[email protected]>
 
J

jacob navia

Le 26/08/12 11:57, Ansel a écrit :
Isn't it a lame use of human time and effort to maintain completely separate
C and C++ standards? As in the words of Betty White about Facebook: "It
seems like an incredible waste of time". Why don't the two standards groups
get together and agree on a common specification for the ground which both
standards cover? There would still be two separate standards, but they'd
both be exactly the same for the common ground. The common ground document
could be referred to by both standards instead of being maintained by both
groups in individual efforts resulting in different verbage in separate
specifications for the same functionality. This should happen after both
groups agree to completely align the C subset functionality on the next
realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
of cooperation going forward).

You said in a message posted just 3 hours ago:

<quote>
It's hard to be enthusiastic about boring old C though. Yeah, it may be
the simplest way to deliver a library of simple functions, but so what?

Why bother worrying about the lonely C standard when C++ is almost a
superset of it and you're using a C++ compiler anyway?
<end quote>

Take you own advice dude and stop trolling
 
A

Ansel

jacob said:
Le 26/08/12 11:57, Ansel a écrit :

You said in a message posted just 3 hours ago:

<quote>
It's hard to be enthusiastic about boring old C though. Yeah, it may
be the simplest way to deliver a library of simple functions, but so
what?
Why bother worrying about the lonely C standard when C++ is almost a
superset of it and you're using a C++ compiler anyway?
<end quote>

But this new topic is an adjunct to that thought (which was meant in the 3rd
person). Go to bed if you are crabby.
 
J

Jens Gustedt

Am 26.08.2012 11:57, schrieb Ansel:
Isn't it a lame use of human time and effort to maintain completely
separate C and C++ standards?
yes

The common ground document could be referred to by both standards
instead of being maintained by both groups in individual efforts
resulting in different verbage in separate specifications for the
same functionality. This should happen after both groups agree to
completely align the C subset functionality on the next realease of
standards (e.g., VLAs? No one using them? Drop 'em in the name of
cooperation going forward).

I don't know all the history, but maybe one of the reasons that it
didn't work so far is because some people bring their axe to the
discussion instead of burying it outside? I already sense the flames
from the people heating up and not recognizing that this is a thread
in two different news groups.

There already is a large corpus of standards that use the C standard
as their base, namely POSIX. It has some general clause that
everything that is described there and that is in contradiction with
the C standard is unintentional. (Don't know how this will work out in
future since C adopted the same thread extension as C++ which is
not completely interface compatible with POSIX. They really receive a
warm greeting from us all.)

POSIX avoided to *use* the parts of C that don't seem of their liking,
such as e.g variably modified types, that's all, and it works
satisfactory, I think. C has swallowed the pill already and declared
parts optional. For the variably modified types part, unfortunately it
only has made VLA optional as a whole, instead of distinguishing
between the possibility of instantiations of VLA and pointers to VLA
(VM types) which have a much more general use.

As the languages have evolved now, there are technical issues that
really would need a lot of compromise such that they could work out
well enough for both communities, you probably all know them,
different concepts of lvalues and rvalues, different sizeof of
literals, different default initializers, different concepts of
compile-time constants, different concepts of union, etc etc

Doing so would need people with good technical and social skills from
both communities. Not the kind of self-opinionated "experts" that we
often meet in discussions like this one.

Jens
 
V

Varun Tewari

As long as libraries like POSIX etc are willing to migrate, I vouch for single standard to cover both, ++ anyway is superset of C.
 
B

Barry Schwarz

Isn't it a lame use of human time and effort to maintain completely separate
C and C++ standards? As in the words of Betty White about Facebook: "It
seems like an incredible waste of time". Why don't the two standards groups
get together and agree on a common specification for the ground which both
standards cover? There would still be two separate standards, but they'd
both be exactly the same for the common ground. The common ground document
could be referred to by both standards instead of being maintained by both
groups in individual efforts resulting in different verbage in separate
specifications for the same functionality. This should happen after both
groups agree to completely align the C subset functionality on the next
realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
of cooperation going forward).

What is your recommended compromise for malloc?

Should C++ give up its strict type checking and no longer require
a cast of the return value?

or

Should C now require the cast and break more than 20 years of
existing code?
 
J

jacob navia

Le 26/08/12 11:57, Ansel a écrit :
Isn't it a lame use of human time and effort to maintain completely separate
C and C++ standards? As in the words of Betty White about Facebook: "It
seems like an incredible waste of time". Why don't the two standards groups
get together and agree on a common specification for the ground which both
standards cover? There would still be two separate standards, but they'd
both be exactly the same for the common ground. The common ground document
could be referred to by both standards instead of being maintained by both
groups in individual efforts resulting in different verbage in separate
specifications for the same functionality. This should happen after both
groups agree to completely align the C subset functionality on the next
realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
of cooperation going forward).

sizeof('b') is sizeof(int) int C, 1 in C++

Which one would you compromise on?

You do not know what you are talking about dude...
 
K

Keith Thompson

David Brown said:
Most of the features of C that are not in C++ are either old styles
(such as omitting prototypes, or "implicit int") which are best avoided,
or they are features that could be happily included in C++ (such as
"long long", designated initialisers, etc.)

Implicit int was dropped by C99. Old-style (non-prototype) function
declarations have been "obsolescent" since 1989, but as of 2011 the
committee hasn't gotten around to removing them from the language;
*if* there were an effort to make C a struct subset of C++, requiring
prototypes wouldn't be a major obstacle.

C++11 added long long. It didn't add designated initializers,
compound literals, "restrict", or VLAs (the latter are optional
in C11).

But I'm not at all convinced that redefining C as a strict subset
of C++ would be worth the effort. In particular, C permits a void*
expression to be implicitly converted to another pointer type;
C++ does not. Making C adopt the C++ rule would break tons
of existing code (struct foo *ptr = malloc(N * sizeof *ptr)).
I'm less sure about the consequence of making C++ adopt the C rule,
but I suspect it would break something having to do with templates
and/or overloading.

The two committees do make some effort to avoid too many
incompatibilities -- and I'd *like* to see C++ adopt a few more
C99 and C11 features than it has so far.
 
J

Jens Gustedt

Am 26.08.2012 23:19, schrieb Keith Thompson:
The two committees do make some effort to avoid too many
incompatibilities
definitively

-- and I'd *like* to see C++ adopt a few more
C99 and C11 features than it has so far.

on my wish list would be

- variably modified types (not necessarily VLA but pointers to VLA are
nice)
- restrict
- designated initializers
- compound literals
- type punning through unions
- compatible complex types

the other way round there would probably also be some things from C++
that would be worth considering in C. Simple things such as {} for
default initializers, a larger concept of compile time constants, the
same possibilities for declarations inside control structures (static
objects, and extend the concept to "if" and "while", not only
"for"). But I probably don't know enough of modern C++ to completely
appreciate what this could offer to C.

Then the two could come together to enforce some revolutionary new
things like fixing signed integer representations to two's complement,
disallowing padding bits for integral types, disallowing trap
representations, force definition of intptr_t and other crude stuff
like that.

Jens
 
J

Jens Gustedt

Am 26.08.2012 23:38, schrieb David Brown:
I'd also like to see the committees working together when they are doing
the same thing. It is just silly that C11 has "_Static_assert" while
C++11 has "static_assert".

They are working successfully working together, here. C has
"static_assert", too, only that it is a macro defined in a header
file. All new keywords that are introduced to C are first introduced in
form of identifiers that had been reserved before, such that the
introduction doesn't break existing code. If you want to have
"static_assert" or "bool" you'd have to include the corresponding
header, and you'll see immediately where a particular incompatibility
came from.

Jens
 
A

Adrian Ratnapala

C++ does not. Making C adopt the C++ rule would break tons
of existing code (struct foo *ptr = malloc(N * sizeof *ptr)).

Yes. I recently wrote a little windows utility in C, but had to translate the brains so it could be used as a C++ module. The C++ void* insanity was biggest problem.
I'm less sure about the consequence of making C++ adopt the C rule,
but I suspect it would break something having to do with templates

and/or overloading.


Yep. At the end o the day, this kind of incompatibility is only a minor nuisance. Changing fundamental things in either language would be much worse. Especially if the change is to C++, because nobody understands how that thing works.
 
B

BGB

Isn't it a lame use of human time and effort to maintain completely separate
C and C++ standards? As in the words of Betty White about Facebook: "It
seems like an incredible waste of time". Why don't the two standards groups
get together and agree on a common specification for the ground which both
standards cover? There would still be two separate standards, but they'd
both be exactly the same for the common ground. The common ground document
could be referred to by both standards instead of being maintained by both
groups in individual efforts resulting in different verbage in separate
specifications for the same functionality. This should happen after both
groups agree to completely align the C subset functionality on the next
realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
of cooperation going forward).

IMHO:
C++ could adopt C99 or C11 as its C subset (and make "void *" support
implicit conversion to other pointer types, formally allow "#include
<stdio.h>" and friends, adopt the "((void *)0)" definition of NULL, ...);
and C could discourage use of C++ reserved words as identifiers, or
maybe even have compilers generate warnings about it ("Foo *this;" ->
"warning: 'this' is a reserved word in C++", ...).

similarly, when possible/reasonable, APIs could be defined in C-friendly
ways, such that it is not necessary to have redundant versions of an
API, so the C API is the canonical one, and the C++ version is mostly
just syntax sugar (wrapper classes and templates).


or such...
 
L

lovecreatesbeauty

Isn't it a lame use of human time and effort to maintain completely separate

C and C++ standards? As in the words of Betty White about Facebook: "It

C isn't subset of C++.
C++ isn't superset of C.
They are different.
C++ is a new language.

Now I somewhat agree with a similar opinion thrown long time ago:

C++ has no relationship with C except its name stolen from C
 
A

Ansel

David said:
I think requiring an explicit cast in C would help avoid errors in
code - but obviously you want to be careful introducing a feature
that would break so much existing code. Equally, you don't want to
remove the feature from C++ - so this would have to stand as a
difference.

Well, there is "standard" and "de facto standard". Once embarked upon the
path toward greater compatibility, one need not stop at the ISO level.
Beyond that, there is the implementation (vendor) level, and it appears (to
me) that a few "de facto standard" compiler switches might be the solution
to issues where C and C++ cannot "get it together". Of course, that is not
to be used as a crutch for not making some "painful" changes, but it is
another dimension of the project. That said, there is nothing stopping some
compiler vendor(s) from bypassing all the formalities and "just doing it!"
that way and letting users decide. It may even be the best way to go about
it, for it could "happen overnight" instead of next year.

Compiler switches: ye or nay?
Vendor-driven approach: ye or nay?
 
A

Ansel

Keith said:
You mean the standard C++ function declared in <cstdio>?
Yes, I've heard of it; why do you ask?

(I was "afraid" of asking. I thought he was on the warpath, and I didn't get
what he was after either.)
 
K

Keith Thompson

lovecreatesbeauty said:
C isn't subset of C++.
C++ isn't superset of C.
They are different.
C++ is a new language.

True (but I'd say "newer" rather than "new").
Now I somewhat agree with a similar opinion thrown long time ago:

C++ has no relationship with C except its name stolen from C

I completely disagree with that. C++ is clearly derived from C.
It's *nearly* a superset of C. Almost the entire standard C library
is included in C by reference. The C and C++ committees coordinate
with each other to avoid unnecessary incompatibilities.

It's not difficult (though sometimes a bit tricky) to write
substantial programs that are valid C and valid C++ with the same
semantics. Try that with two languages that have "no relationship"
(say, C and Fortran).
 
A

Andrew Smallshaw

As long as libraries like POSIX etc are willing to migrate, I vouch for single standard to cover both, ++ anyway is superset of C.

That isn't true. It IS true that code can be written that is
acceptable to either relatively easy, but a true superset it isn't:

int *number = malloc(sizeof(int));

is perfectly valid C but needs an explicit typecast in the "superset".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top