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

Discussion in 'C++' started by Ansel, Aug 26, 2012.

  1. Ansel

    Ansel Guest

    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).
    Ansel, Aug 26, 2012
    #1
    1. Advertising

  2. 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$>
    Johannes Bauer, Aug 26, 2012
    #2
    1. Advertising

  3. Ansel

    jacob navia Guest

    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
    jacob navia, Aug 26, 2012
    #3
  4. Ansel

    Ansel Guest

    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.
    Ansel, Aug 26, 2012
    #4
  5. Ansel

    Jens Gustedt Guest

    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
    Jens Gustedt, Aug 26, 2012
    #5
  6. On Sun, 26 Aug 2012 03:57:30 -0600, "Ansel"
    <> 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
    Barry Schwarz, Aug 26, 2012
    #6
  7. Ansel

    jacob navia Guest

    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...
    jacob navia, Aug 26, 2012
    #7
  8. Johannes Bauer <> 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.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"
    Keith Thompson, Aug 26, 2012
    #8
  9. David Brown <> 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) <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"
    Keith Thompson, Aug 26, 2012
    #9
  10. Ansel

    Jens Gustedt Guest

    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
    Jens Gustedt, Aug 26, 2012
    #10
  11. Ansel

    Jens Gustedt Guest

    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
    Jens Gustedt, Aug 26, 2012
    #11
  12. Ansel

    BGB Guest

    On 8/26/2012 4:57 AM, Ansel 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).
    >
    >


    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...
    BGB, Aug 27, 2012
    #12
  13. Ansel

    Ansel Guest

    David Brown wrote:
    > On 26/08/2012 23:19, Keith Thompson wrote:
    >> David Brown <> writes:


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

    >
    > 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?
    Ansel, Aug 27, 2012
    #13
  14. Ansel

    Ansel Guest

    Keith Thompson wrote:
    > Johannes Bauer <> 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?


    (I was "afraid" of asking. I thought he was on the warpath, and I didn't get
    what he was after either.)
    Ansel, Aug 27, 2012
    #14
  15. Ansel

    Öö Tiib Guest

    On Monday, August 27, 2012 6:26:19 AM UTC+3, Ansel wrote:
    > David Brown wrote:
    > > On 26/08/2012 23:19, Keith Thompson wrote:
    > >> 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.

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


    That is wishful thinking. In reality there are vendors like Microsoft
    that do not implement something from C99 for decades, nothing to talk
    of accepting it 'as extension' by C++ compiler as well.

    Why is that? Because the vendors compete with each other. They do not
    want the code written for their platform to compile and run on other
    platform. They even detect the competing platform and run worse there
    like is case with ICC.

    Open source solves it only slightly. There are always related
    operating system or platform vendors who participate or pay to
    squeeze their 'extension' into compiler. If they can not agree about
    fair play behind board of standards then there is snowball's chance
    in hell that it happens outside.
    Öö Tiib, Aug 27, 2012
    #15
  16. On Aug 26, 11:28 am, Johannes Bauer <> wrote:
    > 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?


    yes, why? Does it use VLAs?
    Nick Keighley, Aug 27, 2012
    #16
  17. Ansel

    Jens Gustedt Guest

    Am 27.08.2012 09:43, schrieb David Brown:
    > On 26/08/2012 23:50, Jens Gustedt wrote:
    >> 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.
    >>

    >
    > I understand this (and in fact knew it was the case). But that doesn't
    > stop it being silly!
    >
    > The C committee should learn - as the C++ committee apparently knows -
    > that backwards compatibility is only "important", not "critical". It is
    > /okay/ to introduce a new "static_assert" keyword in the new version of
    > a language, as long as people can continue to use their compilers with
    > older standards. This is not a new idea - consider K&R style function
    > declarations, for example.


    This is your opinion and the C committee seem to have a different
    one. Calling it silly is not very constructive, in any case it is not
    going to change soon, I guess.

    Important fact is that for these features code will equally well
    compile in both frameworks.

    > Failing that, what is to stop the C++ people following the C people here?
    >
    > Anyway, this is just one example that is easy to see, where the two
    > committees added the same feature to the two languages but with
    > differing details.
    >
    > The more annoying issue, as I see it, is the increasing gap of C
    > features that are missing in C++. There are steadily more features
    > being added to C for embedded use, such as fixed point formats. But C++
    > doesn't get that sort of thing, because it could all be implemented in a
    > class. I understand the principle that you should not add something to
    > the core library if it can be done just as well in a class - but the C++
    > committee doesn't seem to realise that compatibility with C is important
    > here.


    I completely agree on that point, and BTW there are equal points in
    the other direction from C++ to C.

    Best example for something completely trivial is "{}" as a default
    initializer. What the hell does C gain by imposing that there is at
    least a 0 in it à la "{0}" ?

    Or that C adopted declarations in "for" loops but doesn't allow
    "static" declarations or "enum" declarations, and doesn't allow
    declarations in "if" or "while" ?

    These things look just as if somebody was voluntarily seeking to
    introduce incompatibilities, instead of reducing them.

    Jens
    Jens Gustedt, Aug 27, 2012
    #17
  18. Ansel

    Jens Gustedt Guest

    Am 27.08.2012 10:40, schrieb David Brown:
    > If someone is making a wish list here, I'd add support for defining
    > endianness (allowing code to explicitly define and use variables and
    > types as big endian or little endian independently of the architecture)



    > and bit field ordering.


    I think this is more strictly defined for C already than for C++,
    perhaps the definition that C has would be sufficient for your needs?

    > That would be great for portable code.
    >
    > Support for types bigger than "char" which are "can always alias" would
    > be a big help whenever you need to move data around, and an 8-bit type
    > that does not alias would be nice for small systems.


    I am not sure that I understand this one. C has the optional uintXX_t
    that are guaranteed to have a fixed width no padding etc, if they
    exist. Would it for your purpose just suffice to make some of these
    types mandatory e.g for 8, 16, 32 and 64 bit integers?

    > Proper, standardised memory barriers of different types and granularity
    > would be a help for some low-level programming.


    My understanding is that these are included in C11 atomics, and since
    this part basically identical to C++11, it should be there, too.

    > Generally speaking, it would be nice to be able to do more C++ in
    > low-level and embedded code, and cut out some more of the last remnants
    > of assembly that is still needed.


    The atomics extension (optional in C11) should already do a lot in
    that direction.

    Jens
    Jens Gustedt, Aug 27, 2012
    #18
  19. Ansel

    BGB Guest

    On 8/27/2012 1:01 PM, Kenneth Brody wrote:
    > On 8/26/2012 1:54 PM, 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

    > [...]
    >>
    >> 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...

    >
    > Simple. Require sizeof(int)==1. Problem solved. :)
    >


    wouldn't work out well or make much sense on most common architectures.

    better would probably be: pick one way or the other.
    BGB, Aug 27, 2012
    #19
  20. Ansel

    Guest

    Jens Gustedt <> wrote:
    >
    > on my wish list would be
    >
    > - variably modified types (not necessarily VLA but pointers to VLA are
    > nice)


    What good are pointers to VLAs without VLAs? What would they point
    to???
    --
    Larry Jones

    I'm so disappointed. -- Calvin
    , Aug 27, 2012
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guoqi Zheng

    subset of data using dataview??

    Guoqi Zheng, Jan 19, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    2,005
    Miha Markic
    Jan 19, 2004
  2. Andy
    Replies:
    0
    Views:
    413
  3. Andrey Fedorov
    Replies:
    9
    Views:
    282
    Carl Banks
    Sep 10, 2009
  4. Harry
    Replies:
    12
    Views:
    293
    Simon Krahnke
    Sep 23, 2009
  5. Ansel
    Replies:
    191
    Views:
    2,959
    Ian Collins
    Dec 17, 2012
Loading...

Share This Page