Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C as a Subset of C++ (or C++ as a superset of C)

Reply
Thread Tools

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

 
 
Ansel
Guest
Posts: n/a
 
      08-26-2012
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).


 
Reply With Quote
 
 
 
 
Johannes Bauer
Guest
Posts: n/a
 
      08-26-2012
On 26.08.2012 11:57, Ansel wrote:

> 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

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> 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 <hidbv3$om2$(E-Mail Removed)>
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      08-26-2012
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

 
Reply With Quote
 
Ansel
Guest
Posts: n/a
 
      08-26-2012
jacob navia wrote:
> 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>
>


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


 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      08-26-2012
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
 
Reply With Quote
 
Varun Tewari
Guest
Posts: n/a
 
      08-26-2012
As long as libraries like POSIX etc are willing to migrate, I vouch for single standard to cover both, ++ anyway is superset of C.
 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      08-26-2012
On Sun, 26 Aug 2012 03:57:30 -0600, "Ansel"
<(E-Mail Removed)> wrote:

>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?

--
Remove del for email
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      08-26-2012
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...
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-26-2012
Johannes Bauer <(E-Mail Removed)> writes:
> On 26.08.2012 11:57, Ansel wrote:
>> 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?


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

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-26-2012
David Brown <(E-Mail Removed)> writes:
[...]
> 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.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C as a Subset of C++ (or C++ as a superset of C) Ansel C++ 130 09-04-2012 01:10 PM
Newbie: Are Ruby regexp's a subset, superset, or equal to Perl's? Harry Ruby 12 09-23-2009 09:45 PM
Function to apply superset of arguments to a function Andrey Fedorov Python 9 09-10-2009 03:36 AM
subset of data using dataview?? Guoqi Zheng ASP .Net 2 01-19-2004 01:54 PM
Frighteners superset, any news? Grand Inquisitor DVD Video 0 11-20-2003 03:02 AM



Advertisments